* Re: [PATCH v2 0/3] fixup remaining cvsimport tests
From: Chris Rorvick @ 2013-01-12 7:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric S. Raymond
In-Reply-To: <7vr4lq9acu.fsf@alter.siamese.dyndns.org>
On Sat, Jan 12, 2013 at 12:36 AM, Junio C Hamano <gitster@pobox.com> wrote:
> I too noticed the droppage of "-a" support, which may not be a big
> deal (people can drop it from their script, run cvsimport and they
> can drop newer commits from the resulting Git history to emulate the
> old behaviour without "-a" that attempted to find a quiescent point
> if they really want to and suspect that the upstream CVS repository
> was not quiescent during the import).
Is there any value to -a when fuzz is exposed (-z)? I mean this is a
functional sense. I think there is a lot of value to maintaining the
interfaces of both cvsimport and cvsps where possible.
> Likewise for "-x". You said "no longer can be told" and that is
> technically true, but it is more like "no longer need to be told, as
> stale cache cannot get in the way", so it is probably not a big
> deal, either, for people to drop it from their script.
:-) I originally wrote "need" and then changed it to be clearer on
why it was being removed.
^ permalink raw reply
* [PATCH] regulator: lp8755: Don't show unrelated messags in lp8755_probe error paths
From: Axel Lin @ 2013-01-12 6:58 UTC (permalink / raw)
To: Mark Brown; +Cc: Daniel Jeong, Liam Girdwood, linux-kernel
Signed-off-by: Axel Lin <axel.lin@ingics.com>
---
drivers/regulator/lp8755.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/regulator/lp8755.c b/drivers/regulator/lp8755.c
index decb3ad..8c3f3f2 100644
--- a/drivers/regulator/lp8755.c
+++ b/drivers/regulator/lp8755.c
@@ -497,35 +497,36 @@ static int lp8755_probe(struct i2c_client *client,
if (!pchip->pdata)
return -ENOMEM;
ret = lp8755_init_data(pchip);
- if (ret < 0)
- goto err_chip_init;
+ if (ret < 0) {
+ dev_err(&client->dev, "fail to initialize chip\n");
+ return ret;
+ }
}
ret = lp8755_regulator_init(pchip);
- if (ret < 0)
+ if (ret < 0) {
+ dev_err(&client->dev, "fail to initialize regulators\n");
goto err_regulator;
+ }
pchip->irq = client->irq;
ret = lp8755_int_config(pchip);
- if (ret < 0)
+ if (ret < 0) {
+ dev_err(&client->dev, "fail to irq config\n");
goto err_irq;
+ }
return ret;
err_irq:
- dev_err(&client->dev, "fail to irq config\n");
-
for (icnt = 0; icnt < mphase_buck[pchip->mphase].nreg; icnt++)
regulator_unregister(pchip->rdev[icnt]);
err_regulator:
- dev_err(&client->dev, "fail to initialize regulators\n");
/* output disable */
for (icnt = 0; icnt < 0x06; icnt++)
lp8755_write(pchip, icnt, 0x00);
-err_chip_init:
- dev_err(&client->dev, "fail to initialize chip\n");
return ret;
}
--
1.7.9.5
^ permalink raw reply related
* Seperate metadata disk for OSD
From: Chen, Xiaoxi @ 2013-01-12 6:57 UTC (permalink / raw)
To: ceph-devel@vger.kernel.org
Hi list,
For a rbd write request, Ceph need to do 3 writes:
2013-01-10 13:10:15.539967 7f52f516c700 10 filestore(/data/osd.21) _do_transaction on 0x327d790
2013-01-10 13:10:15.539979 7f52f516c700 15 filestore(/data/osd.21) write meta/516b801c/pglog_2.1a/0//-1 36015~147
2013-01-10 13:10:15.540016 7f52f516c700 15 filestore(/data/osd.21) path: /data/osd.21/current/meta/DIR_C/pglog\u2.1a__0_516B801C__none
2013-01-10 13:10:15.540164 7f52f516c700 15 filestore(/data/osd.21) write meta/28d2f4a8/pginfo_2.1a/0//-1 0~496
2013-01-10 13:10:15.540189 7f52f516c700 15 filestore(/data/osd.21) path: /data/osd.21/current/meta/DIR_8/pginfo\u2.1a__0_28D2F4A8__none
2013-01-10 13:10:15.540217 7f52f516c700 10 filestore(/data/osd.21) _do_transaction on 0x327d708
2013-01-10 13:10:15.540222 7f52f516c700 15 filestore(/data/osd.21) write 2.1a_head/8abf341a/rb.0.106e.6b8b4567.0000000002d3/head//2 3227648~524288
2013-01-10 13:10:15.540245 7f52f516c700 15 filestore(/data/osd.21) path: /data/osd.21/current/2.1a_head/rb.0.106e.6b8b4567.0000000002d3__head_8ABF341A__2
If using XFS as backend file system and running xfs on top of traditional sata disk, it will introduce a lot of seeks and therefore reduce bandwidth, a blktrace is available here :( http://ww3.sinaimg.cn/mw690/6e1aee47jw1e0qsbxbvddj.jpg) to demonstrate this issue.( single client running dd on top of a new RBD volumes).
Then I tried to move /osd.X/current/meta to a separate disk, the bandwidth boosted.(look blktrace at http://ww4.sinaimg.cn/mw690/6e1aee47jw1e0qsadz1bij.jpg).
I haven't test other access pattern or something else, but it looks to me that moving such meta to a separate disk (ssd or sata with btrfs) will benefit ceph write performance, is it true? Will ceph introduce this feature in the future? Is there any potential problem for such hack?
Xiaoxi
^ permalink raw reply
* [PATCH 13/16] drivers: misc: add ARM CCI support
From: Santosh Shilimkar @ 2013-01-12 6:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1301111414390.6300@xanadu.home>
On Saturday 12 January 2013 12:52 AM, Nicolas Pitre wrote:
> On Fri, 11 Jan 2013, Santosh Shilimkar wrote:
>
>> On Thursday 10 January 2013 05:50 AM, Nicolas Pitre wrote:
>>> From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>>>
>>> On ARM multi-cluster systems coherency between cores running on
>>> different clusters is managed by the cache-coherent interconnect (CCI).
>>> It allows broadcasting of TLB invalidates and memory barriers and it
>>> guarantees cache coherency at system level.
>>>
>>> This patch enables the basic infrastructure required in Linux to
>>> handle and programme the CCI component. The first implementation is
>>> based on a platform device, its relative DT compatible property and
>>> a simple programming interface.
>>>
>>> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>>> ---
>>> drivers/misc/Kconfig | 3 ++
>>> drivers/misc/Makefile | 1 +
>>> drivers/misc/arm-cci.c | 107
>>> ++++++++++++++++++++++++++++++++++++++++++++++++
>>> include/linux/arm-cci.h | 30 ++++++++++++++
>> How about 'drivers/bus/' considering CCI is an interconnect bus (though
>> for coherency)
>
> Yes, I like that better.
>
Great.
>>> 4 files changed, 141 insertions(+)
>>> create mode 100644 drivers/misc/arm-cci.c
>>> create mode 100644 include/linux/arm-cci.h
>>>
>>> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
>>> index b151b7c1bd..30d5be1ad2 100644
>>> --- a/drivers/misc/Kconfig
>>> +++ b/drivers/misc/Kconfig
>>> @@ -499,6 +499,9 @@ config USB_SWITCH_FSA9480
>>> stereo and mono audio, video, microphone and UART data to use
>>> a common connector port.
>>>
>>> +config ARM_CCI
>> You might want add depends on ARM big.LITTTLE otherwise it will
>> break build for other arch's with random configurations.
>
> As far as this patch goes, this is buildable on other architectures too.
> The next patch changes that though.
>
Thanks.
>> [..]
>>
>>> diff --git a/drivers/misc/arm-cci.c b/drivers/misc/arm-cci.c
>>> new file mode 100644
>>> index 0000000000..f329c43099
>>> --- /dev/null
>>> +++ b/drivers/misc/arm-cci.c
>>> @@ -0,0 +1,107 @@
>>> +/*
>>> + * CCI support
>>> + *
>>> + * Copyright (C) 2012 ARM Ltd.
>>> + * Author: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2 as
>>> + * published by the Free Software Foundation.
>>> + *
>>> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
>>> + * kind, whether express or implied; without even the implied warranty
>>> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + */
>>> +
>>> +#include <linux/device.h>
>>> +#include <linux/io.h>
>>> +#include <linux/module.h>
>>> +#include <linux/platform_device.h>
>>> +#include <linux/slab.h>
>>> +#include <linux/arm-cci.h>
>>> +
>>> +#define CCI400_EAG_OFFSET 0x4000
>>> +#define CCI400_KF_OFFSET 0x5000
>>> +
>>> +#define DRIVER_NAME "CCI"
>>> +struct cci_drvdata {
>>> + void __iomem *baseaddr;
>>> + spinlock_t lock;
>>> +};
>>> +
>>> +static struct cci_drvdata *info;
>>> +
>>> +void disable_cci(int cluster)
>>> +{
>>> + u32 cci_reg = cluster ? CCI400_KF_OFFSET : CCI400_EAG_OFFSET;
>>> + writel_relaxed(0x0, info->baseaddr + cci_reg);
>>> +
>>> + while (readl_relaxed(info->baseaddr + 0xc) & 0x1)
>>> + ;
>>> +}
>>> +EXPORT_SYMBOL_GPL(disable_cci);
>>> +
>> Is more functionality going to be added for CCI driver. Having this
>> much of driver code for just a disable_cci() functions seems like
>> overkill.
>
> Yes. More code will appear here to provide pmu functionalities, etc.
>
Good to know.
Regards,
Santosh
^ permalink raw reply
* [PATCH 10/16] ARM: vexpress: introduce DCSCB support
From: Santosh Shilimkar @ 2013-01-12 6:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1301111408330.6300@xanadu.home>
On Saturday 12 January 2013 12:43 AM, Nicolas Pitre wrote:
> On Fri, 11 Jan 2013, Santosh Shilimkar wrote:
>
>> On Thursday 10 January 2013 05:50 AM, Nicolas Pitre wrote:
>>> This adds basic CPU and cluster reset controls on RTSM for the
>>> A15x4-A7x4 model configuration using the Dual Cluster System
>>> Configuration Block (DCSCB).
>>>
>>> The cache coherency interconnect (CCI) is not handled yet.
>>>
>>> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>>> ---
>>> arch/arm/mach-vexpress/Kconfig | 8 ++
>>> arch/arm/mach-vexpress/Makefile | 1 +
>>> arch/arm/mach-vexpress/dcscb.c | 160
>>> ++++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 169 insertions(+)
>>> create mode 100644 arch/arm/mach-vexpress/dcscb.c
>>>
[..]
>>> diff --git a/arch/arm/mach-vexpress/dcscb.c b/arch/arm/mach-vexpress/dcscb.c
>>> new file mode 100644
>>> index 0000000000..cccd943cd4
>>> --- /dev/null
>>> +++ b/arch/arm/mach-vexpress/dcscb.c
[..]
>>> +static void dcscb_power_down(void)
>>> +{
>>> + unsigned int mpidr, cpu, cluster, rst_hold, cpumask, last_man;
>>> +
>>> + asm ("mrc p15, 0, %0, c0, c0, 5" : "=r" (mpidr));
>>> + cpu = mpidr & 0xff;
>>> + cluster = (mpidr >> 8) & 0xff;
>>> + cpumask = (1 << cpu);
>>> +
>>> + pr_debug("%s: cpu %u cluster %u\n", __func__, cpu, cluster);
>>> + BUG_ON(cpu >= 4 || cluster >= 2);
>>> +
>>> + arch_spin_lock(&dcscb_lock);
>>> + rst_hold = readl_relaxed(dcscb_base + RST_HOLD0 + cluster * 4);
>>> + rst_hold |= cpumask;
>>> + if (((rst_hold | (rst_hold >> 4)) & 0xf) == 0xf)
>>> + rst_hold |= (1 << 8);
>>> + writel(rst_hold, dcscb_base + RST_HOLD0 + cluster * 4);
>>> + arch_spin_unlock(&dcscb_lock);
>>> + last_man = (rst_hold & (1 << 8));
>>> +
>>> + /*
>>> + * Now let's clean our L1 cache and shut ourself down.
>>> + * If we're the last CPU in this cluster then clean L2 too.
>>> + */
>>> +
>> Do you wanted to have C bit clear code here ?
>
> cpu_proc_fin() does it.
>
Yep. I noticed that in next patch when read the comment.
>>> + /*
>>> + * A15/A7 can hit in the cache with SCTLR.C=0, so we don't need
>>> + * a preliminary flush here for those CPUs. At least, that's
>>> + * the theory -- without the extra flush, Linux explodes on
>>> + * RTSM (maybe not needed anymore, to be investigated)..
>>> + */
>>> + flush_cache_louis();
>>> + cpu_proc_fin();
>>> +
>>> + if (!last_man) {
>>> + flush_cache_louis();
>>> + } else {
>>> + flush_cache_all();
>>> + outer_flush_all();
>>> + }
>>> +
>>> + /* Disable local coherency by clearing the ACTLR "SMP" bit: */
>>> + asm volatile (
>>> + "mrc p15, 0, ip, c1, c0, 1 \n\t"
>>> + "bic ip, ip, #(1 << 6) @ clear SMP bit \n\t"
>>> + "mcr p15, 0, ip, c1, c0, 1"
>>> + : : : "ip" );
>>> +
>>> + /* Now we are prepared for power-down, do it: */
>> You need dsb here, right ?
>
> Probably. However this code is being refactored significantly with
> subsequent patches. This intermediate step was kept not to introduce
> too many concepts at once.
>
Yes. I do see updates in subsequent patch.
Regards
Santosh
^ permalink raw reply
* [PATCH 08/16] ARM: bL_platsmp.c: make sure the GIC interface of a dying CPU is disabled
From: Santosh Shilimkar @ 2013-01-12 6:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1301111405590.6300@xanadu.home>
On Saturday 12 January 2013 12:37 AM, Nicolas Pitre wrote:
> On Fri, 11 Jan 2013, Santosh Shilimkar wrote:
>
>> On Thursday 10 January 2013 05:50 AM, Nicolas Pitre wrote:
>>> Otherwise there might be some interrupts or IPIs becoming pending and the
>>> CPU will not enter low power mode when doing a WFI. The effect of this
>>> is a CPU that loops back into the kernel, go through the first man
>>> election, signals itself as alive, and prevent the cluster from being
>>> shut down.
>>>
>>> This could benefit from a better solution.
>>>
>>> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>>> ---
>>> arch/arm/common/bL_platsmp.c | 1 +
>>> arch/arm/common/gic.c | 6 ++++++
>>> arch/arm/include/asm/hardware/gic.h | 2 ++
>>> 3 files changed, 9 insertions(+)
>>>
>>> diff --git a/arch/arm/common/bL_platsmp.c b/arch/arm/common/bL_platsmp.c
>>> index 0ae44123bf..6a3b251b97 100644
>>> --- a/arch/arm/common/bL_platsmp.c
>>> +++ b/arch/arm/common/bL_platsmp.c
>>> @@ -68,6 +68,7 @@ static void __ref bL_cpu_die(unsigned int cpu)
>>> pcpu = mpidr & 0xff;
>>> pcluster = (mpidr >> 8) & 0xff;
>>> bL_set_entry_vector(pcpu, pcluster, NULL);
>>> + gic_cpu_if_down();
>>
>> So for a case where CPU still don't power down for some reason even
>> after CPU interface is disabled, can not listen to and SGI or PPI.
>> Not sure if this happens on big.LITTLE but i have seen one such issue
>> on Cortex-A9 based SOC.
>
> Here the problem was the reverse i.e. a CPU wouldn't go down because
> some pending SGIs prevented that.
>
I understood that part. What I was saying is, with CPU IF disabled and
if CPU doesn't enter into the intended low power state and if the wakeup
mechanism on that CPU is SGI/SPI, CPU may never wakeup and can lead to
dead lock. I have seen this scenario on OMAP especially in CPUidle path.
It may not be relevant for switcher considering, you almost force CPU to
enter to low power state :-)
Regards,
Santosh
^ permalink raw reply
* [U-Boot] [PATCH 1/7] tegra: fdt: add apbdma node
From: Allen Martin @ 2013-01-12 6:49 UTC (permalink / raw)
To: u-boot
In-Reply-To: <50F0FDAD.2000502@wwwdotorg.org>
On Fri, Jan 11, 2013 at 10:07:41PM -0800, Stephen Warren wrote:
> On 01/11/2013 08:19 PM, Allen Martin wrote:
> > On Fri, Jan 11, 2013 at 04:08:55PM -0800, Stephen Warren wrote:
> >> On 01/11/2013 11:44 AM, Allen Martin wrote:
> >>> Add apbdma node for tegra20 and tegra30, copied directly from tegra
> >>> Linux dtsi files.
> >>
> >>> diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
> >>
> >>> + apbdma: dma {
> >>> + compatible = "nvidia,tegra20-apbdma";
> >>> + reg = <0x6000a000 0x1200>;
> >> ...
> >>> intc: interrupt-controller at 50041000 {
> >>
> >> Can the nodes be kept sorted by address?
> >>
> >
> > They're already unsorted. I'll add a new patch to sort them, then add
> > this one on top.
>
> Ah yes.
>
> You can use the kernel as a reference, but FYI the order I have
> attempted to impose there is:
>
> 1) Any nodes that already exist in any /include/d file, in the order
> they appear in the /include/d file.
>
> 2) Any nodes with a reg property, in order of their address.
>
> 3) Any nodes without a reg property, alphabetically by node name.
>
> If U-Boot follows the same rules, diff'ing the .dts files between U-Boot
> and the kernel should be easy.
Ok, thanks, I'll try to follow the same rules.
BTW: cache-controller and interrupt-controller are out of order in the
kernel dtsi files.
-Allen
--
nvpublic
^ permalink raw reply
* Re: [Qemu-trivial] [Qemu-devel] [PATCH] hw/pc.c: add ULL suffix in ioport80_read and ioportF0_read return value
From: Stefan Weil @ 2013-01-12 6:37 UTC (permalink / raw)
To: Julien Grall; +Cc: qemu-trivial, aliguori, qemu-devel
In-Reply-To: <1357922503-20202-1-git-send-email-julien.grall@citrix.com>
Am 11.01.2013 17:41, schrieb Julien Grall:
> The commit c02e1eac887b1b0aee7361b1fcf889e7d47fed9d broke the compilation
> for i386. ULL need to be specify for uint64_t value.
>
> Signed-off-by: Julien Grall <julien.grall@citrix.com>
> ---
> hw/pc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/pc.c b/hw/pc.c
> index dfa3144..ba1f19d 100644
> --- a/hw/pc.c
> +++ b/hw/pc.c
> @@ -105,7 +105,7 @@ static void ioport80_write(void *opaque, hwaddr addr, uint64_t data,
>
> static uint64_t ioport80_read(void *opaque, hwaddr addr, unsigned size)
> {
> - return 0xffffffffffffffff;
> + return 0xffffffffffffffffULL;
> }
>
> /* MSDOS compatibility mode FPU exception support */
> @@ -130,7 +130,7 @@ static void ioportF0_write(void *opaque, hwaddr addr, uint64_t data,
>
> static uint64_t ioportF0_read(void *opaque, hwaddr addr, unsigned size)
> {
> - return 0xffffffffffffffff;
> + return 0xffffffffffffffffULL;
> }
>
> /* TSC handling */
Better: use UINT64_MAX. Then reviewers don't have to count 'f's.
As this patch is a build fix, it should be committed directly without
waiting for a qemu-trivial pull request.
Stefan
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] hw/pc.c: add ULL suffix in ioport80_read and ioportF0_read return value
From: Stefan Weil @ 2013-01-12 6:37 UTC (permalink / raw)
To: Julien Grall; +Cc: qemu-trivial, aliguori, qemu-devel
In-Reply-To: <1357922503-20202-1-git-send-email-julien.grall@citrix.com>
Am 11.01.2013 17:41, schrieb Julien Grall:
> The commit c02e1eac887b1b0aee7361b1fcf889e7d47fed9d broke the compilation
> for i386. ULL need to be specify for uint64_t value.
>
> Signed-off-by: Julien Grall <julien.grall@citrix.com>
> ---
> hw/pc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/pc.c b/hw/pc.c
> index dfa3144..ba1f19d 100644
> --- a/hw/pc.c
> +++ b/hw/pc.c
> @@ -105,7 +105,7 @@ static void ioport80_write(void *opaque, hwaddr addr, uint64_t data,
>
> static uint64_t ioport80_read(void *opaque, hwaddr addr, unsigned size)
> {
> - return 0xffffffffffffffff;
> + return 0xffffffffffffffffULL;
> }
>
> /* MSDOS compatibility mode FPU exception support */
> @@ -130,7 +130,7 @@ static void ioportF0_write(void *opaque, hwaddr addr, uint64_t data,
>
> static uint64_t ioportF0_read(void *opaque, hwaddr addr, unsigned size)
> {
> - return 0xffffffffffffffff;
> + return 0xffffffffffffffffULL;
> }
>
> /* TSC handling */
Better: use UINT64_MAX. Then reviewers don't have to count 'f's.
As this patch is a build fix, it should be committed directly without
waiting for a qemu-trivial pull request.
Stefan
^ permalink raw reply
* Re: [PATCH v2 0/3] fixup remaining cvsimport tests
From: Junio C Hamano @ 2013-01-12 6:36 UTC (permalink / raw)
To: Chris Rorvick; +Cc: git, Eric S. Raymond
In-Reply-To: <1357971703-28513-1-git-send-email-chris@rorvick.com>
Chris Rorvick <chris@rorvick.com> writes:
> Reroll w/ sign-off.
>
> Chris Rorvick (3):
> t/lib-cvs.sh: allow cvsps version 3.x.
> t9600: fixup for new cvsimport
> t9604: fixup for new cvsimport
>
> t/lib-cvs.sh | 2 +-
> t/t9600-cvsimport.sh | 10 ++++------
> t/t9604-cvsimport-timestamps.sh | 5 ++---
> 3 files changed, 7 insertions(+), 10 deletions(-)
Thanks.
I too noticed the droppage of "-a" support, which may not be a big
deal (people can drop it from their script, run cvsimport and they
can drop newer commits from the resulting Git history to emulate the
old behaviour without "-a" that attempted to find a quiescent point
if they really want to and suspect that the upstream CVS repository
was not quiescent during the import).
Likewise for "-x". You said "no longer can be told" and that is
technically true, but it is more like "no longer need to be told, as
stale cache cannot get in the way", so it is probably not a big
deal, either, for people to drop it from their script.
About the changed behaviour regarding "origin", I suspect that it is
a change for the better, but we would probably need documentation
updates to cover it (and deleted options and (mis)features) before
this topic graduates.
^ permalink raw reply
* Quick Loans
From: gab.sgc @ 2013-01-12 4:32 UTC (permalink / raw)
Good Day,
Do you need a personal or business loan without stress and quick approval? If yes, contact us today as we are currently offering loans at superb interest rate. Our loan is secured and safe, our customers happiness is our strength. For more information and Application.
Sincerely,
Mrs Rosa Luna
SEC capitals Inc.
Public Relations Officer.
^ permalink raw reply
* Re: MODSIGN: Modules fail signature verification with -ENOKEY
From: Chris Samuel @ 2013-01-12 6:28 UTC (permalink / raw)
To: Josh Boyer; +Cc: linux-kernel, Rusty Russell, dhowells
In-Reply-To: <CA+5PVA5hCuTar1F=g5vgT2Cj1ZbF7w+HcWzhATUx7wFs_kuSWw@mail.gmail.com>
/* Please CC, not on LKML */
Hi Josh,
On 12/01/13 00:44, Josh Boyer wrote:
> Check the installed modules. A simple:
>
> hexdump -C <path to module> | tail -n 20
>
> should be enough to tell you if the installed modules at least look like
> they're signed. You should see the expected "~Module signature appended~"
> string. You could also check the modules in the kernel build tree for
> the same thing. [...]
Good call - neither the modules in the build tree, nor the installed
ones are signed. I did a "make mrproper", changed scripts/sign-file to
be verbose by default and rebuilt. That confirmed that the modules are
getting signed, which left the possibility of make-kpkg stripping the
modules after compiling as an option.
Google pointed me at the likely culprit, a patch from a certain Mr Ted
Ts'o in 2009 to make-kpkg so that it would strip kernel modules by default.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517290
I'll file a bug against it asking for the it to not strip if
CONFIG_MODULE_SIG is set.
Thanks for the pointer!
Chris
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
^ permalink raw reply
* [PATCH 3/4] ARM: imx: restore uncompress.h to a common place
From: Dirk Behme @ 2013-01-12 6:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355319945-3199-4-git-send-email-shawn.guo@linaro.org>
On 12.12.2012 14:45, Shawn Guo wrote:
> Restore arch/arm/plat-mxc/include/mach/uncompress.h removed by commit
> 3995eb8 (ARM: imx: merge plat-mxc into mach-imx) to a common place as
> arch/arm/include/debug/uncompress/imx.h.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
...
> +++ b/arch/arm/include/debug/uncompress/imx.h
...
> + * arch/arm/plat-mxc/include/mach/uncompress.h
In case you touch these patches again, you might check if the above
path and file name in the file header should be adapted to the new
file location, too.
Best regards
Dirk
^ permalink raw reply
* [PATCH v2 3/3] t9604: fixup for new cvsimport
From: Chris Rorvick @ 2013-01-12 6:21 UTC (permalink / raw)
To: git; +Cc: Eric S. Raymond, Junio C Hamano, Chris Rorvick
In-Reply-To: <1357971703-28513-1-git-send-email-chris@rorvick.com>
cvsps no longer writes a cache file and therefore no longer can be told
to ignore it with -x.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
---
t/t9604-cvsimport-timestamps.sh | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/t/t9604-cvsimport-timestamps.sh b/t/t9604-cvsimport-timestamps.sh
index 1fd5142..b1629b6 100755
--- a/t/t9604-cvsimport-timestamps.sh
+++ b/t/t9604-cvsimport-timestamps.sh
@@ -7,8 +7,7 @@ setup_cvs_test_repository t9604
test_expect_success 'check timestamps are UTC (TZ=CST6CDT)' '
- TZ=CST6CDT git cvsimport -p"-x" -C module-1 module &&
- git cvsimport -p"-x" -C module-1 module &&
+ TZ=CST6CDT git cvsimport -C module-1 module &&
(
cd module-1 &&
git log --format="%s %ai"
@@ -42,7 +41,7 @@ test_expect_success 'check timestamps with author-specific timezones' '
user3=User Three <user3@domain.org> EST5EDT
user4=User Four <user4@domain.org> MST7MDT
EOF
- git cvsimport -p"-x" -A cvs-authors -C module-2 module &&
+ git cvsimport -A cvs-authors -C module-2 module &&
(
cd module-2 &&
git log --format="%s %ai %an"
--
1.8.1.rc3.335.g88a67d6
^ permalink raw reply related
* [PATCH v2 2/3] t9600: fixup for new cvsimport
From: Chris Rorvick @ 2013-01-12 6:21 UTC (permalink / raw)
To: git; +Cc: Eric S. Raymond, Junio C Hamano, Chris Rorvick
In-Reply-To: <1357971703-28513-1-git-send-email-chris@rorvick.com>
cvsimport no longer supports -a (import all commits including recent ones)
and no longer uses the 'origin' branch by default for imports.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
---
t/t9600-cvsimport.sh | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/t/t9600-cvsimport.sh b/t/t9600-cvsimport.sh
index 4c384ff..14f54d5 100755
--- a/t/t9600-cvsimport.sh
+++ b/t/t9600-cvsimport.sh
@@ -44,7 +44,7 @@ EOF
test_expect_success PERL 'import a trivial module' '
- git cvsimport -a -R -z 0 -C module-git module &&
+ git cvsimport -R -z 0 -C module-git module &&
test_cmp module-cvs/o_fortuna module-git/o_fortuna
'
@@ -90,8 +90,7 @@ test_expect_success PERL 'update git module' '
(cd module-git &&
git config cvsimport.trackRevisions true &&
- git cvsimport -a -z 0 module &&
- git merge origin
+ git cvsimport -z 0 module
) &&
test_cmp module-cvs/o_fortuna module-git/o_fortuna
@@ -119,8 +118,7 @@ test_expect_success PERL 'cvsimport.module config works' '
(cd module-git &&
git config cvsimport.module module &&
git config cvsimport.trackRevisions true &&
- git cvsimport -a -z0 &&
- git merge origin
+ git cvsimport -z0
) &&
test_cmp module-cvs/tick module-git/tick
@@ -140,7 +138,7 @@ test_expect_success PERL 'import from a CVS working tree' '
$CVS co -d import-from-wt module &&
(cd import-from-wt &&
git config cvsimport.trackRevisions false &&
- git cvsimport -a -z0 &&
+ git cvsimport -z0 &&
echo 1 >expect &&
git log -1 --pretty=format:%s%n >actual &&
test_cmp actual expect
--
1.8.1.rc3.335.g88a67d6
^ permalink raw reply related
* [PATCH v2 1/3] t/lib-cvs.sh: allow cvsps version 3.x.
From: Chris Rorvick @ 2013-01-12 6:21 UTC (permalink / raw)
To: git; +Cc: Eric S. Raymond, Junio C Hamano, Chris Rorvick
In-Reply-To: <1357971703-28513-1-git-send-email-chris@rorvick.com>
Signed-off-by: Chris Rorvick <chris@rorvick.com>
---
t/lib-cvs.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/lib-cvs.sh b/t/lib-cvs.sh
index 44263ad..b55e861 100644
--- a/t/lib-cvs.sh
+++ b/t/lib-cvs.sh
@@ -15,7 +15,7 @@ export CVS
cvsps_version=`cvsps -h 2>&1 | sed -ne 's/cvsps version //p'`
case "$cvsps_version" in
-2.1 | 2.2*)
+2.1 | 2.2* | 3.*)
;;
'')
skip_all='skipping cvsimport tests, cvsps not found'
--
1.8.1.rc3.335.g88a67d6
^ permalink raw reply related
* [PATCH v2 0/3] fixup remaining cvsimport tests
From: Chris Rorvick @ 2013-01-12 6:21 UTC (permalink / raw)
To: git; +Cc: Eric S. Raymond, Junio C Hamano, Chris Rorvick
Reroll w/ sign-off.
Chris Rorvick (3):
t/lib-cvs.sh: allow cvsps version 3.x.
t9600: fixup for new cvsimport
t9604: fixup for new cvsimport
t/lib-cvs.sh | 2 +-
t/t9600-cvsimport.sh | 10 ++++------
t/t9604-cvsimport-timestamps.sh | 5 ++---
3 files changed, 7 insertions(+), 10 deletions(-)
--
1.8.1.rc3.335.g88a67d6
^ permalink raw reply
* Re: obscure out of space, df and fi df are way off
From: Chris Murphy @ 2013-01-12 6:20 UTC (permalink / raw)
To: linux-btrfs@vger.kernel.org BTRFS, cwillu
In-Reply-To: <CAE5mzvjGwnrYJUQJ97xuCm__hAE18cfLx8r5_NutFkA6dzONcQ@mail.gmail.com>
On Jan 11, 2013, at 11:04 PM, cwillu <cwillu@cwillu.com> wrote:
> On Fri, Jan 11, 2013 at 11:50 PM, Chris Murphy <lists@colorremedies.com> wrote:
>> Very low priority.
>> No user data at risk.
>> 8GB virtual disk being installed to, and the installer is puking. I'm trying to figure out why.
>>
>> I first get an rsync error 12, followed by the installer crashing. What's interesting is this, deleting irrelevant source file systems, just showing the mounts for the installed system:
>>
>> [root@localhost tmp]# df
>> Filesystem 1K-blocks Used Available Use% Mounted on
>> /dev/sda3 3746816 3193172 1564 100% /mnt/sysimage
>> /dev/sda1 495844 31509 438735 7% /mnt/sysimage/boot
>> /dev/sda3 3746816 3193172 1564 100% /mnt/sysimage/home
>>
>> So there's 1.5M of free space left according to conventional df. However:
>>
>> [root@localhost tmp]# btrfs fi show
>> Label: 'fedora_f18v' uuid: 0c9b2b62-5ec1-4610-ab2f-9f00c909428a
>> Total devices 1 FS bytes used 2.87GB
>> devid 1 size 3.57GB used 3.57GB path /dev/sda3
>>
>> [root@localhost tmp]# btrfs fi df /mnt/sysimage
>> Data: total=2.69GB, used=2.69GB
>> System, DUP: total=8.00MB, used=4.00KB
>> System: total=4.00MB, used=0.00
>> Metadata, DUP: total=438.94MB, used=183.36MB
>> Metadata: total=8.00MB, used=0.00
>>
>> And absolutely nothing in dmesg.
>>
>> This is confusing. fi show says 3.57GB available and used. Whereas fi df says 2.69 available and used. So is it 3.57GB? Or is it 2.69? I suppose the simple answer is, it doesn't matter, in either case it's full. But it seems like the installer is underestimating Btrfs requirements and should be more conservative, somehow so I'd like to better understand the allocation.
>
> There reporting is correct, but a bit obscure. We have a FAQ item on
> how to read the output on the wiki, but it's a known sore spot.
>
> btrfs fi show reports 3.57GB allocated to block groups (so everything
> is assigned to metadata or data); btrfs fi df reports how that 3.57GB
> is being used: of 2.69GB allocated to data block groups, 2.69GB (i.e.,
> all of it) is in use by file data; of 438.94MB of metadata (or 0.87GB
> after DUP), 183.36MB is in use by metadata (which may include small
> files that have been inlined).
So if I assume 2.7GiB for data, and add up the left side of fi df I get 3224MB rounded up, which is neither 3.57GB or 3.57GiB. I'm missing 346MB at least. That is what I should have said from the outset.
So is the Metadta DUP Total 438.94MB allocated value actually twice that, but only 438.94MB is displayed because that's what's available (since the metadata is duplicated)?
>
> In other words, the tools are saying that filesystem is basically full. :)
Right yes, very clear!
>
> Note that the -M option to mkfs.btrfs is intended for this use-case:
> filesystems where the size of a block allocation is large compared to
> the size of the filesystem. It should let you squeeze out most of the
> rest of that 400MB (200MB, DUP).
Is there a simple rule of thumb an installer could use to know when to use -M? I know mkfs.btrfs will do this for smaller filesystems than this. I'm thinking this is a testing edge case that a desktop installer shouldn't be concerned about, but rather should just gracefully fail from, or better yet, insist on a larger install destination than this in particular when Btrfs.
Chris Murphy
^ permalink raw reply
* [PATCH] udf: add extent cache support in case of file reading
From: Namjae Jeon @ 2013-01-12 6:13 UTC (permalink / raw)
To: jack
Cc: linux-fsdevel, linux-kernel, Namjae Jeon, Namjae Jeon,
Ashish Sangwan, Bonggil Bak
From: Namjae Jeon <namjae.jeon@samsung.com>
This patch implements extent caching in case of file reading.
While reading a file, currently, UDF reads metadata serially
which takes a lot of time depending on the number of extents present
in the file. Caching last accessd extent improves metadata read time.
Instead of reading file metadata from start, now we read from
the cached extent.
This patch considerably improves the time spent by CPU in kernel mode.
For example, while reading a 10.9 GB file using dd:
Time before applying patch:
11677022208 bytes (10.9GB) copied, 1529.748921 seconds, 7.3MB/s
real 25m 29.85s
user 0m 12.41s
sys 15m 34.75s
Time after applying patch:
11677022208 bytes (10.9GB) copied, 1469.338231 seconds, 7.6MB/s
real 24m 29.44s
user 0m 15.73s
sys 3m 27.61s
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com>
Signed-off-by: Bonggil Bak <bgbak@samsung.com>
---
fs/udf/ialloc.c | 2 ++
fs/udf/inode.c | 74 +++++++++++++++++++++++++++++++++++++++++++++++++-----
fs/udf/udf_i.h | 17 +++++++++++++
fs/udf/udfdecl.h | 10 ++++----
4 files changed, 92 insertions(+), 11 deletions(-)
diff --git a/fs/udf/ialloc.c b/fs/udf/ialloc.c
index 7e5aae4..7dd86a4a 100644
--- a/fs/udf/ialloc.c
+++ b/fs/udf/ialloc.c
@@ -117,6 +117,8 @@ struct inode *udf_new_inode(struct inode *dir, umode_t mode, int *err)
iinfo->i_lenAlloc = 0;
iinfo->i_use = 0;
iinfo->i_checkpoint = 1;
+ memset(&iinfo->cached_extent, 0, sizeof(struct udf_ext_cache));
+ mutex_init(&(iinfo->i_extent_cache_lock));
if (UDF_QUERY_FLAG(inode->i_sb, UDF_FLAG_USE_AD_IN_ICB))
iinfo->i_alloc_type = ICBTAG_FLAG_AD_IN_ICB;
else if (UDF_QUERY_FLAG(inode->i_sb, UDF_FLAG_USE_SHORT_AD))
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index cbae1ed..9980381 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -90,6 +90,7 @@ void udf_evict_inode(struct inode *inode)
}
kfree(iinfo->i_ext.i_data);
iinfo->i_ext.i_data = NULL;
+ udf_clear_extent_cache(iinfo);
if (want_delete) {
udf_free_inode(inode);
}
@@ -105,6 +106,7 @@ static void udf_write_failed(struct address_space *mapping, loff_t to)
truncate_pagecache(inode, to, isize);
if (iinfo->i_alloc_type != ICBTAG_FLAG_AD_IN_ICB) {
down_write(&iinfo->i_data_sem);
+ udf_clear_extent_cache(iinfo);
udf_truncate_extents(inode);
up_write(&iinfo->i_data_sem);
}
@@ -372,7 +374,7 @@ static int udf_get_block(struct inode *inode, sector_t block,
iinfo->i_next_alloc_goal++;
}
-
+ udf_clear_extent_cache(iinfo);
phys = inode_getblk(inode, block, &err, &new);
if (!phys)
goto abort;
@@ -1171,6 +1173,7 @@ set_size:
} else {
if (iinfo->i_alloc_type == ICBTAG_FLAG_AD_IN_ICB) {
down_write(&iinfo->i_data_sem);
+ udf_clear_extent_cache(iinfo);
memset(iinfo->i_ext.i_data + iinfo->i_lenEAttr + newsize,
0x00, bsize - newsize -
udf_file_entry_alloc_offset(inode));
@@ -1184,6 +1187,7 @@ set_size:
if (err)
return err;
down_write(&iinfo->i_data_sem);
+ udf_clear_extent_cache(iinfo);
truncate_setsize(inode, newsize);
udf_truncate_extents(inode);
up_write(&iinfo->i_data_sem);
@@ -1301,6 +1305,8 @@ static void udf_fill_inode(struct inode *inode, struct buffer_head *bh)
iinfo->i_lenAlloc = 0;
iinfo->i_next_alloc_block = 0;
iinfo->i_next_alloc_goal = 0;
+ memset(&iinfo->cached_extent, 0, sizeof(struct udf_ext_cache));
+ mutex_init(&(iinfo->i_extent_cache_lock));
if (fe->descTag.tagIdent == cpu_to_le16(TAG_IDENT_EFE)) {
iinfo->i_efe = 1;
iinfo->i_use = 0;
@@ -2156,11 +2162,12 @@ int8_t inode_bmap(struct inode *inode, sector_t block,
struct udf_inode_info *iinfo;
iinfo = UDF_I(inode);
- pos->offset = 0;
- pos->block = iinfo->i_location;
- pos->bh = NULL;
+ if (!udf_read_extent_cache(inode, bcount, &lbcount, pos)) {
+ pos->offset = 0;
+ pos->block = iinfo->i_location;
+ pos->bh = NULL;
+ }
*elen = 0;
-
do {
etype = udf_next_aext(inode, pos, eloc, elen, 1);
if (etype == -1) {
@@ -2170,7 +2177,8 @@ int8_t inode_bmap(struct inode *inode, sector_t block,
}
lbcount += *elen;
} while (lbcount <= bcount);
-
+ /* update extent cache */
+ udf_update_extent_cache(inode, lbcount - *elen, pos, 1);
*offset = (bcount + *elen - lbcount) >> blocksize_bits;
return etype;
@@ -2200,3 +2208,57 @@ long udf_block_map(struct inode *inode, sector_t block)
else
return ret;
}
+int udf_read_extent_cache(struct inode *inode, loff_t bcount,
+ loff_t *lbcount, struct extent_position *pos)
+{
+ struct udf_inode_info *iinfo = UDF_I(inode);
+ mutex_lock(&iinfo->i_extent_cache_lock);
+ if ((iinfo->cached_extent.lstart <= bcount) &&
+ (iinfo->cached_extent.valid)) {
+ /* Cache hit */
+ *lbcount = iinfo->cached_extent.lstart;
+ memcpy(pos, &iinfo->cached_extent.epos,
+ sizeof(struct extent_position));
+ mutex_unlock(&iinfo->i_extent_cache_lock);
+ return 1;
+ } else
+ udf_clear_extent_cache(iinfo);
+ mutex_unlock(&iinfo->i_extent_cache_lock);
+ return 0;
+}
+void udf_update_extent_cache(struct inode *inode, loff_t estart,
+ struct extent_position *pos, int next_epos)
+{
+ struct udf_inode_info *iinfo = UDF_I(inode);
+ mutex_lock(&iinfo->i_extent_cache_lock);
+ if (pos->bh != NULL)
+ /* Increase ref count */
+ get_bh(pos->bh);
+ memcpy(&iinfo->cached_extent.epos, pos,
+ sizeof(struct extent_position));
+ iinfo->cached_extent.lstart = estart;
+ iinfo->cached_extent.valid = 1;
+ if (next_epos)
+ switch (iinfo->i_alloc_type) {
+ case ICBTAG_FLAG_AD_SHORT:
+ iinfo->cached_extent.epos.offset -=
+ sizeof(struct short_ad);
+ break;
+ case ICBTAG_FLAG_AD_LONG:
+ iinfo->cached_extent.epos.offset -=
+ sizeof(struct long_ad);
+ }
+ mutex_unlock(&iinfo->i_extent_cache_lock);
+}
+
+/* This function should be called after i_data_sem is
+ * held for writing OR i_extent_cache_lock is taken.
+ */
+void udf_clear_extent_cache(struct udf_inode_info *iinfo)
+{
+ if (iinfo->cached_extent.valid) {
+ brelse(iinfo->cached_extent.epos.bh);
+ memset(&iinfo->cached_extent, 0, sizeof(struct udf_ext_cache));
+ }
+}
+
diff --git a/fs/udf/udf_i.h b/fs/udf/udf_i.h
index bb8309d..95e5e17 100644
--- a/fs/udf/udf_i.h
+++ b/fs/udf/udf_i.h
@@ -1,6 +1,20 @@
#ifndef _UDF_I_H
#define _UDF_I_H
+struct extent_position {
+ struct buffer_head *bh;
+ uint32_t offset;
+ struct kernel_lb_addr block;
+};
+
+struct udf_ext_cache {
+ /* Extent position */
+ struct extent_position epos;
+ /* Start logical offset in bytes */
+ loff_t lstart;
+ bool valid;
+};
+
/*
* The i_data_sem and i_mutex serve for protection of allocation information
* of a regular files and symlinks. This includes all extents belonging to
@@ -35,6 +49,9 @@ struct udf_inode_info {
__u8 *i_data;
} i_ext;
struct rw_semaphore i_data_sem;
+ struct udf_ext_cache cached_extent;
+ /* Mutex for protecting extent cache */
+ struct mutex i_extent_cache_lock;
struct inode vfs_inode;
};
diff --git a/fs/udf/udfdecl.h b/fs/udf/udfdecl.h
index de038da..db4a22e 100644
--- a/fs/udf/udfdecl.h
+++ b/fs/udf/udfdecl.h
@@ -113,11 +113,6 @@ struct ustr {
uint8_t u_len;
};
-struct extent_position {
- struct buffer_head *bh;
- uint32_t offset;
- struct kernel_lb_addr block;
-};
/* super.c */
@@ -164,6 +159,11 @@ extern int8_t udf_next_aext(struct inode *, struct extent_position *,
struct kernel_lb_addr *, uint32_t *, int);
extern int8_t udf_current_aext(struct inode *, struct extent_position *,
struct kernel_lb_addr *, uint32_t *, int);
+int udf_read_extent_cache(struct inode *inode, loff_t bcount, loff_t *lbcount,
+ struct extent_position *pos);
+void udf_update_extent_cache(struct inode *inode, loff_t estart,
+ struct extent_position *pos, int next_epos);
+void udf_clear_extent_cache(struct udf_inode_info *iinfo);
/* misc.c */
extern struct buffer_head *udf_tgetblk(struct super_block *, int);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v2 1/2] linux-yocto: added kernel configuration for KVM
From: lei yang @ 2013-01-12 6:08 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: meta-virtualization@yoctoproject.org
In-Reply-To: <CADkTA4Nh1b6oySSoz59oODeLyehSYdGsUrh3JMLK2C9=AOZaKg@mail.gmail.com>
On Fri, Jan 11, 2013 at 1:08 PM, Bruce Ashfield
<bruce.ashfield@gmail.com> wrote:
> On Fri, Jan 11, 2013 at 11:27 AM, Mihai Prica <mihai.prica@intel.com> wrote:
>>
>> Signed-off-by: Mihai Prica <mihai.prica@intel.com>
>> ---
>> recipes-kernel/linux/linux-yocto_3.4.bbappend | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/recipes-kernel/linux/linux-yocto_3.4.bbappend
>> b/recipes-kernel/linux/linux-yocto_3.4.bbappend
>> index 5b163ff..6fa02e8 100644
>> --- a/recipes-kernel/linux/linux-yocto_3.4.bbappend
>> +++ b/recipes-kernel/linux/linux-yocto_3.4.bbappend
>> @@ -6,3 +6,8 @@ SRC_URI += "file://xt-checksum.scc \
>> file://lxc.scc \
>> "
>>
>> +KERNEL_FEATURES_append = " kvm/qemu-kvm-enable"
>
>
> Have you confirmed that this is adding the option you want ? I would have
> expected this to be:
>
> KERNEL_FEATURES_append = " features/kvm/qemu-kvm-enable.scc"
>
>
Hi Bruce,
I also notice this, I did a serch in internal layer just found below
in wr-kernel use the same way
templates/feature/libhugetlbfs/template.conf:KERNEL_FEATURES_append +=
"features/hugetlb"
I don't know if there is defect for this, both work or not,or we like
.scc is there(coding style)
I'm glad to do a test later.
Lei
>>
>> +
>> +module_autoload_kvm = "kvm"
>> +module_autoload_kvm-amd = "kvm-amd"
>> +module_autoload_kvm-intel = "kvm-intel"
>
>
> This part looks fine though.
>
> Cheers,
>
> Bruce
>
>>
>> --
>> 1.7.9.5
>>
>> _______________________________________________
>> meta-virtualization mailing list
>> meta-virtualization@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-virtualization
>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at
> its end"
>
> _______________________________________________
> meta-virtualization mailing list
> meta-virtualization@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-virtualization
>
^ permalink raw reply
* [U-Boot] [PATCH 1/7] tegra: fdt: add apbdma node
From: Stephen Warren @ 2013-01-12 6:07 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20130112031900.GA27011@badger>
On 01/11/2013 08:19 PM, Allen Martin wrote:
> On Fri, Jan 11, 2013 at 04:08:55PM -0800, Stephen Warren wrote:
>> On 01/11/2013 11:44 AM, Allen Martin wrote:
>>> Add apbdma node for tegra20 and tegra30, copied directly from tegra
>>> Linux dtsi files.
>>
>>> diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
>>
>>> + apbdma: dma {
>>> + compatible = "nvidia,tegra20-apbdma";
>>> + reg = <0x6000a000 0x1200>;
>> ...
>>> intc: interrupt-controller at 50041000 {
>>
>> Can the nodes be kept sorted by address?
>>
>
> They're already unsorted. I'll add a new patch to sort them, then add
> this one on top.
Ah yes.
You can use the kernel as a reference, but FYI the order I have
attempted to impose there is:
1) Any nodes that already exist in any /include/d file, in the order
they appear in the /include/d file.
2) Any nodes with a reg property, in order of their address.
3) Any nodes without a reg property, alphabetically by node name.
If U-Boot follows the same rules, diff'ing the .dts files between U-Boot
and the kernel should be easy.
^ permalink raw reply
* [PATCH v2] bcma: fix bcm4716/bcm4748 i2s irqflag
From: Nathan Hintz @ 2013-01-12 6:07 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, hauke, Nathan Hintz
The default irqflag assignment for the I2S core on some Broadcom
4716/4748 devices is invalid and needs to be corrected (from the
Broadcom SDK).
Signed-off-by: Nathan Hintz <nlhintz@hotmail.com>
---
drivers/bcma/driver_mips.c | 28 ++++++++++++++++++++++++++++
include/linux/bcma/bcma_driver_mips.h | 1 +
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/drivers/bcma/driver_mips.c b/drivers/bcma/driver_mips.c
index a808404..9fe86ee 100644
--- a/drivers/bcma/driver_mips.c
+++ b/drivers/bcma/driver_mips.c
@@ -256,6 +256,32 @@ void bcma_core_mips_early_init(struct bcma_drv_mips *mcore)
mcore->early_setup_done = true;
}
+static void bcma_fix_i2s_irqflag(struct bcma_bus *bus)
+{
+ struct bcma_device *cpu, *pcie, *i2s;
+
+ /* Fixup the interrupts in 4716/4748 for i2s core (2010 Broadcom SDK)
+ * (IRQ flags > 7 are ignored when setting the interrupt masks)
+ */
+ if (bus->chipinfo.id != BCMA_CHIP_ID_BCM4716 &&
+ bus->chipinfo.id != BCMA_CHIP_ID_BCM4748)
+ return;
+
+ cpu = bcma_find_core(bus, BCMA_CORE_MIPS_74K);
+ pcie = bcma_find_core(bus, BCMA_CORE_PCIE);
+ i2s = bcma_find_core(bus, BCMA_CORE_I2S);
+ if (cpu && pcie && i2s &&
+ bcma_aread32(cpu, BCMA_MIPS_OOBSELINA74) == 0x08060504 &&
+ bcma_aread32(pcie, BCMA_MIPS_OOBSELINA74) == 0x08060504 &&
+ bcma_aread32(i2s, BCMA_MIPS_OOBSELOUTA30) == 0x88) {
+ bcma_awrite32(cpu, BCMA_MIPS_OOBSELINA74, 0x07060504);
+ bcma_awrite32(pcie, BCMA_MIPS_OOBSELINA74, 0x07060504);
+ bcma_awrite32(i2s, BCMA_MIPS_OOBSELOUTA30, 0x87);
+ bcma_debug(bus,
+ "Moved i2s interrupt to oob line 7 instead of 8\n");
+ }
+}
+
void bcma_core_mips_init(struct bcma_drv_mips *mcore)
{
struct bcma_bus *bus;
@@ -269,6 +295,8 @@ void bcma_core_mips_init(struct bcma_drv_mips *mcore)
bcma_core_mips_early_init(mcore);
+ bcma_fix_i2s_irqflag(bus);
+
switch (bus->chipinfo.id) {
case BCMA_CHIP_ID_BCM4716:
case BCMA_CHIP_ID_BCM4748:
diff --git a/include/linux/bcma/bcma_driver_mips.h b/include/linux/bcma/bcma_driver_mips.h
index 73c7f4b..0d1ea29 100644
--- a/include/linux/bcma/bcma_driver_mips.h
+++ b/include/linux/bcma/bcma_driver_mips.h
@@ -28,6 +28,7 @@
#define BCMA_MIPS_MIPS74K_GPIOEN 0x0048
#define BCMA_MIPS_MIPS74K_CLKCTLST 0x01E0
+#define BCMA_MIPS_OOBSELINA74 0x004
#define BCMA_MIPS_OOBSELOUTA30 0x100
struct bcma_device;
--
1.7.7.6
^ permalink raw reply related
* Re: [PATCH] t/t960[123]: remove leftover scripts
From: Chris Rorvick @ 2013-01-12 6:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric S. Raymond, git
In-Reply-To: <7v1udr9d0g.fsf_-_@alter.siamese.dyndns.org>
On Fri, Jan 11, 2013 at 11:38 PM, Junio C Hamano <gitster@pobox.com> wrote:
> By the way, Chris, we'll need your Sign-off on the three paches
> (t/lib-cvs.sh fix to allow cvsps v3, t9600 fix and t9604 fix).
Sure. I was just maintaining them for myself but thought I'd share
when I saw the follow-up patch. Didn't think to amend them.
Chris
^ permalink raw reply
* [PATCH V3 18/18] multipath: make path devices readonly again.
From: Benjamin Marzinski @ 2013-01-12 6:04 UTC (permalink / raw)
To: device-mapper development; +Cc: Christophe Varoqui
In-Reply-To: <1357970695-3396-1-git-send-email-bmarzins@redhat.com>
Path device fds were changed to be opened read/write when the
mpathpersist code was added. However, I have talked with Vijay, and
this doesn't appear to be necessary for mpathpersist to work correctly.
If the path fds are opened read/write, when the are closed a change
uevent is triggered, which was causing problems during shutdown with
LVM on top of multipath devices. This patch reverts them to being read-only
again.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
---
libmultipath/discovery.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libmultipath/discovery.c b/libmultipath/discovery.c
index 831cfef..8b6f74d 100644
--- a/libmultipath/discovery.c
+++ b/libmultipath/discovery.c
@@ -886,7 +886,7 @@ pathinfo (struct path *pp, vector hwtable, int mask)
* fetch info not available through sysfs
*/
if (pp->fd < 0)
- pp->fd = open(udev_device_get_devnode(pp->udev), O_RDWR);
+ pp->fd = open(udev_device_get_devnode(pp->udev), O_RDONLY);
if (pp->fd < 0) {
condlog(4, "Couldn't open node for %s: %s",
--
1.8.0
^ permalink raw reply related
* [PATCH V3 17/18] multipath: check for NULL from udev_device_get_*
From: Benjamin Marzinski @ 2013-01-12 6:04 UTC (permalink / raw)
To: device-mapper development; +Cc: Christophe Varoqui
In-Reply-To: <1357970695-3396-1-git-send-email-bmarzins@redhat.com>
The udev_device_get_* functions can return NULL, an occassionally do
so in the multipathd code. multipath needs to check if the result
is NULL before dereferencing it.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
---
libmultipath/discovery.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/libmultipath/discovery.c b/libmultipath/discovery.c
index b8a5cd1..831cfef 100644
--- a/libmultipath/discovery.c
+++ b/libmultipath/discovery.c
@@ -113,6 +113,7 @@ path_discovery (vector pathvec, struct config * conf, int flag)
udev_list_entry_foreach(entry,
udev_enumerate_get_list_entry(udev_iter)) {
+ const char *devtype;
devpath = udev_list_entry_get_name(entry);
condlog(4, "Discover device %s", devpath);
udevice = udev_device_new_from_syspath(conf->udev, devpath);
@@ -121,7 +122,8 @@ path_discovery (vector pathvec, struct config * conf, int flag)
r++;
continue;
}
- if(!strncmp(udev_device_get_devtype(udevice), "disk", 4))
+ devtype = udev_device_get_devtype(udevice);
+ if(devtype && !strncmp(devtype, "disk", 4))
r += path_discover(pathvec, conf, udevice, flag);
udev_device_unref(udevice);
}
@@ -459,7 +461,8 @@ scsi_sysfs_pathinfo (struct path * pp)
parent = pp->udev;
while (parent) {
- if (!strncmp(udev_device_get_subsystem(parent), "scsi", 4)) {
+ const char *subsys = udev_device_get_subsystem(parent);
+ if (subsys && !strncmp(subsys, "scsi", 4)) {
attr_path = udev_device_get_sysname(parent);
if (!attr_path)
break;
@@ -525,7 +528,8 @@ ccw_sysfs_pathinfo (struct path * pp)
parent = pp->udev;
while (parent) {
- if (!strncmp(udev_device_get_subsystem(parent), "ccw", 3))
+ const char *subsys = udev_device_get_subsystem(parent);
+ if (subsys && !strncmp(subsys, "ccw", 3))
break;
parent = udev_device_get_parent(parent);
}
@@ -581,7 +585,8 @@ cciss_sysfs_pathinfo (struct path * pp)
parent = pp->udev;
while (parent) {
- if (!strncmp(udev_device_get_subsystem(parent), "cciss", 5)) {
+ const char *subsys = udev_device_get_subsystem(parent);
+ if (subsys && !strncmp(subsys, "cciss", 5)) {
attr_path = udev_device_get_sysname(parent);
if (!attr_path)
break;
@@ -662,7 +667,8 @@ path_offline (struct path * pp)
parent = pp->udev;
while (parent) {
- if (!strncmp(udev_device_get_subsystem(parent), "scsi", 4))
+ const char *subsys = udev_device_get_subsystem(parent);
+ if (subsys && !strncmp(subsys, "scsi", 4))
break;
parent = udev_device_get_parent(parent);
}
--
1.8.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.