* Re: [PATCH] sdhci: highspeed: check for mmc as well as sd cards
From: Philip Rakity @ 2010-10-07 23:27 UTC (permalink / raw)
To: linux-mmc@vger.kernel.org
In-Reply-To: <41A82D88-6200-469C-986D-EF46B0C6A773@marvell.com>
validated code when testing eMMC dual data rate.
On Oct 6, 2010, at 11:57 AM, Philip Rakity wrote:
>
> when examining the code in the mmc directory the SD and MMC code
> set highspeed using a different constant. Change the sd driver
> to recognize this and switch to high speed.
>
> Signed-off-by: Philip Rakity <prakity@marvell.com>
> ---
> drivers/mmc/host/sdhci.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index d3f924b..1d3f4d8 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1194,8 +1194,9 @@ static void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
> else
> ctrl &= ~SDHCI_CTRL_4BITBUS;
>
> - if (ios->timing == MMC_TIMING_SD_HS &&
> - !(host->quirks & SDHCI_QUIRK_NO_HISPD_BIT))
> + if ((ios->timing == MMC_TIMING_SD_HS
> + || ios->timing == MMC_TIMING_MMC_HS)
> + && !(host->quirks & SDHCI_QUIRK_NO_HISPD_BIT))
> ctrl |= SDHCI_CTRL_HISPD;
> else
> ctrl &= ~SDHCI_CTRL_HISPD;
> --
> 1.6.0.4
>
^ permalink raw reply
* Re: [rtc-linux] RE: [PATCH 5/5] rtc: rtc-s3c: Fix debug message format on RTC
From: Andrew Morton @ 2010-10-07 23:28 UTC (permalink / raw)
To: Kukjin Kim
Cc: 'Wan ZongShun', rtc-linux, p_gortmaker, linux-samsung-soc,
linux-arm-kernel, 'Ben Dooks', a.zummo
In-Reply-To: <00c101cb6675$bb8e67f0$32ab37d0$%kim@samsung.com>
On Fri, 08 Oct 2010 08:16:44 +0900
Kukjin Kim <kgene.kim@samsung.com> wrote:
> Updated patch 1/5 has been tested on S3C24XX and its working fine.
> Its remained issue is that Ben was wondering its working on S3C24XX.
>
> And about the patch 4/5, I did address comments from Ben Dooks and Wan
> ZongShun.
ok...
> So could you please handle this series?
> If any problems, please kindly let me know.
>
> They are since commit cb655d0f3d57c23db51b981648e452988c0223f9:
> Linux 2.6.36-rc7 (2010-10-06 13:39:52 -0700)
>
> are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> next-rtc-s3c
Can you please email them all out in the old-fashioned way? Because a)
I don't manage patches with git and b) that way people will actually
look at the code.
Thanks.
^ permalink raw reply
* [rtc-linux] RE: [PATCH 5/5] rtc: rtc-s3c: Fix debug message format on RTC
From: Andrew Morton @ 2010-10-07 23:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <00c101cb6675$bb8e67f0$32ab37d0$%kim@samsung.com>
On Fri, 08 Oct 2010 08:16:44 +0900
Kukjin Kim <kgene.kim@samsung.com> wrote:
> Updated patch 1/5 has been tested on S3C24XX and its working fine.
> Its remained issue is that Ben was wondering its working on S3C24XX.
>
> And about the patch 4/5, I did address comments from Ben Dooks and Wan
> ZongShun.
ok...
> So could you please handle this series?
> If any problems, please kindly let me know.
>
> They are since commit cb655d0f3d57c23db51b981648e452988c0223f9:
> Linux 2.6.36-rc7 (2010-10-06 13:39:52 -0700)
>
> are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> next-rtc-s3c
Can you please email them all out in the old-fashioned way? Because a)
I don't manage patches with git and b) that way people will actually
look at the code.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] procfs: fix numbering in /proc/locks
From: Andrew Morton @ 2010-10-07 23:27 UTC (permalink / raw)
To: Jerome Marchand
Cc: Matthew Wilcox, Pavel Emelyanov, Linux Kernel Mailing List,
xiyou.wangcong
In-Reply-To: <4CAB1693.2080301@redhat.com>
On Tue, 05 Oct 2010 14:14:11 +0200
Jerome Marchand <jmarchan@redhat.com> wrote:
> On 09/30/2010 02:38 PM, Jerome Marchand wrote:
> >
> > The lock number in /proc/locks (first field) is implemented by a counter
> > (private field of struct seq_file) which is incremented at each call of
> > locks_show() and reset to 1 in locks_start() whatever the offset is. It
> > should be reset according to the actual position in the list.
> >
> > Moreover, locks_show() can be called twice to print a single line thus
> > skipping a number. The counter should be incremented in locks_next().
> >
> > Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
> > ---
> > locks.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/locks.c b/fs/locks.c
> > index ab24d49..49d7343 100644
> > --- a/fs/locks.c
> > +++ b/fs/locks.c
> > @@ -2166,19 +2166,19 @@ static int locks_show(struct seq_file *f, void *v)
> > list_for_each_entry(bfl, &fl->fl_block, fl_block)
> > lock_get_status(f, bfl, (long)f->private, " ->");
> >
> > - f->private++;
> > return 0;
> > }
> >
> > static void *locks_start(struct seq_file *f, loff_t *pos)
> > {
> > lock_kernel();
> > - f->private = (void *)1;
> > + f->private = (void *) (*pos + 1);
>
> That cast trigger a warning on some arch:
> "warning: cast to pointer from integer of different size"
>
> There is no real risk here. At worst /proc/locks will show wrong number
> if there is more than 2^32 locks, but should I mute the warning it with
> something like:
> f->private = (void *) (size_t) (*pos + 1);
> ?
Putting a loff_t into a void* is a pretty alarming thing to do. If
we're really going to do that then use a (long) cast and put a very
good comment at the code site explaining why the bug doesn't matter, so
people aren't misled.
But really, why sweat it? kmalloc the eight bytes, make ->private
point at that and we never have to think about it again. Bonus points
for doing this without any typecasts ;)
^ permalink raw reply
* Re: 2.6.36-rc5 i915 regression
From: Seblu @ 2010-10-07 23:24 UTC (permalink / raw)
To: Zhenyu Wang, Seblu, Chris Wilson, intel-gfx
In-Reply-To: <20101002090753.GB3265@zhen-devel.sh.intel.com>
On Sat, Oct 2, 2010 at 11:07 AM, Zhenyu Wang <zhenyuw@linux.intel.com> wrote:
> On 2010.10.01 22:27:45 +0200, Seblu wrote:
>> On Fri, Oct 1, 2010 at 3:22 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
>> > On Fri, 1 Oct 2010 12:55:56 +0000 (UTC), Seblu <seblu@seblu.net> wrote:
>> >> I've the same kind trouble with -rc6 and my dell e6410. When module i915 is
>> >> loaded screen become black and i loose the hand on the system.
>> >
>> > Nope, completely different bug. eDP being the issue here. Though I think
>> > the Dell 6410 is one of the few that Jesse has been able to get working
>> > (in drm-intel--next)
>>
>> You speek about eDP, but i don't use the external DisplayPort. Despite
>> that you think, this can be linked?
>
> eDP is embedded DP link to your laptop panel, it's an alternative replacement
> for LVDS.
thx
>
> I sent mail before to ask if ajax's eDP connector type change for PCH/eDP
> has caused regression for that, but one e6410 owner replied no effect by
> revert that patch. You may help by bisect drm/i915.
Ok i can try (first time). To understand correclty what you want, i
have to download linux 2.6.36-rc6 git, bisect, compile an run kernel
until i found the commit cause the issue?
I will test new rc7 in near time to show if my display come back.
--
Sébastien Luttringer
www.seblu.net
^ permalink raw reply
* Re: fallocate() on XFS clobbers S*ID-bits
From: Dave Chinner @ 2010-10-07 23:24 UTC (permalink / raw)
To: Andreas Wiese; +Cc: Linux Kernel Mailing List, Ciaran McCreesh, xfs
In-Reply-To: <20101007183418.GC5621@incendiary.meterriblecrew.net>
[ added xfs list on cc ]
On Thu, Oct 07, 2010 at 08:34:19PM +0200, Andreas Wiese wrote:
> Hello.
>
> I (with support from Cc'ed Ciaran) just noticed some odd behaviour with
> fallocate() on XFS. After open()ing some file and setting it S*ID via
> fchmod(), S*ID bits vanish after calling fallocate() — as supposed to
> for non-root users, but it also happens for root.
>
> Is this intended behaviour or did we spot a bug here?
>
> At least on ext2 it works as expected, thus I guess it's the latter one.
ext2 does not support the fallocate syscall. How does ext4 behave?
> I'm running v2.6.35.7 vanilla-kernel, but diffing fs/xfs to master
> doesn't seem to address this issue.
XFS has always cleared SUID/SGID bits when doing preallocation (via
XFS_IOC_RESVSP). Given that that XFS ioctl formed the model for
fallocate, I'd argue that the XFS behaviour is the on that should be
followed.
It'd be a bit silly for two different preallocation interfaces to
have different behaviour w.r.t. SUID bits, but it's not clear to me
which behaviour is correct. I'm happy to defer to whoever can say
what the behaviour is supposed to be here...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* [PATCH] ehea: simplify conditional
From: Nicolas Kaiser @ 2010-10-07 23:14 UTC (permalink / raw)
To: Breno Leitao; +Cc: netdev, linux-kernel
Simplify: ((a && b) || (!a && !b)) => (a == b)
Signed-off-by: Nicolas Kaiser <nikai@nikai.net>
---
drivers/net/ehea/ehea_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 190fb69..ef305f3 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -1914,7 +1914,7 @@ static void ehea_promiscuous(struct net_device *dev, int enable)
struct hcp_ehea_port_cb7 *cb7;
u64 hret;
- if ((enable && port->promisc) || (!enable && !port->promisc))
+ if (enable == port->promisc)
return;
cb7 = (void *)get_zeroed_page(GFP_ATOMIC);
--
1.7.2.2
^ permalink raw reply related
* Re: fallocate() on XFS clobbers S*ID-bits
From: Dave Chinner @ 2010-10-07 23:24 UTC (permalink / raw)
To: Andreas Wiese; +Cc: xfs, Linux Kernel Mailing List, Ciaran McCreesh
In-Reply-To: <20101007183418.GC5621@incendiary.meterriblecrew.net>
[ added xfs list on cc ]
On Thu, Oct 07, 2010 at 08:34:19PM +0200, Andreas Wiese wrote:
> Hello.
>
> I (with support from Cc'ed Ciaran) just noticed some odd behaviour with
> fallocate() on XFS. After open()ing some file and setting it S*ID via
> fchmod(), S*ID bits vanish after calling fallocate() — as supposed to
> for non-root users, but it also happens for root.
>
> Is this intended behaviour or did we spot a bug here?
>
> At least on ext2 it works as expected, thus I guess it's the latter one.
ext2 does not support the fallocate syscall. How does ext4 behave?
> I'm running v2.6.35.7 vanilla-kernel, but diffing fs/xfs to master
> doesn't seem to address this issue.
XFS has always cleared SUID/SGID bits when doing preallocation (via
XFS_IOC_RESVSP). Given that that XFS ioctl formed the model for
fallocate, I'd argue that the XFS behaviour is the on that should be
followed.
It'd be a bit silly for two different preallocation interfaces to
have different behaviour w.r.t. SUID bits, but it's not clear to me
which behaviour is correct. I'm happy to defer to whoever can say
what the behaviour is supposed to be here...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [PATCH 14/18] powerpc, of_serial: Endianness issues setting up the serial ports
From: Grant Likely @ 2010-10-07 23:23 UTC (permalink / raw)
To: Ian Munsie
Cc: linux-kernel, linuxppc-dev, benh, paulus, Stefan Weil,
Jiri Kosina, Sean MacLennan, Greg Kroah-Hartman, Michal Simek,
David S. Miller, devicetree-discuss
In-Reply-To: <1285916771-18033-15-git-send-email-imunsie@au1.ibm.com>
On Fri, Oct 01, 2010 at 05:06:07PM +1000, Ian Munsie wrote:
> From: Ian Munsie <imunsie@au1.ibm.com>
>
> The speed and clock of the serial ports is retrieved from the device
> tree in both the PowerPC legacy serial code and the Open Firmware serial
> driver, therefore they need to handle the fact that the device tree is
> always big endian, while the CPU may not be.
>
> Also fix other device tree references in the legacy serial code.
>
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
Applied, thanks.
I'm picking up this one because it is also needed by Microblaze.
Michal Simek also posted a patch that does the same thing, but this
one is better so I'm dropping his in favour of this one.
As for the other patches, they all look good to me (at least for the
bits that I care about), but I'll leave them for Ben to pick up so the
series doesn't get too fragmented.
g.
> ---
> arch/powerpc/kernel/legacy_serial.c | 22 +++++++++++-----------
> drivers/serial/of_serial.c | 12 ++++++------
> 2 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
> index c1fd0f9..c834757 100644
> --- a/arch/powerpc/kernel/legacy_serial.c
> +++ b/arch/powerpc/kernel/legacy_serial.c
> @@ -52,14 +52,14 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
> phys_addr_t taddr, unsigned long irq,
> upf_t flags, int irq_check_parent)
> {
> - const u32 *clk, *spd;
> + const __be32 *clk, *spd;
> u32 clock = BASE_BAUD * 16;
> int index;
>
> /* get clock freq. if present */
> clk = of_get_property(np, "clock-frequency", NULL);
> if (clk && *clk)
> - clock = *clk;
> + clock = be32_to_cpup(clk);
>
> /* get default speed if present */
> spd = of_get_property(np, "current-speed", NULL);
> @@ -109,7 +109,7 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
> legacy_serial_infos[index].taddr = taddr;
> legacy_serial_infos[index].np = of_node_get(np);
> legacy_serial_infos[index].clock = clock;
> - legacy_serial_infos[index].speed = spd ? *spd : 0;
> + legacy_serial_infos[index].speed = spd ? be32_to_cpup(spd) : 0;
> legacy_serial_infos[index].irq_check_parent = irq_check_parent;
>
> printk(KERN_DEBUG "Found legacy serial port %d for %s\n",
> @@ -168,7 +168,7 @@ static int __init add_legacy_soc_port(struct device_node *np,
> static int __init add_legacy_isa_port(struct device_node *np,
> struct device_node *isa_brg)
> {
> - const u32 *reg;
> + const __be32 *reg;
> const char *typep;
> int index = -1;
> u64 taddr;
> @@ -181,7 +181,7 @@ static int __init add_legacy_isa_port(struct device_node *np,
> return -1;
>
> /* Verify it's an IO port, we don't support anything else */
> - if (!(reg[0] & 0x00000001))
> + if (!(be32_to_cpu(reg[0]) & 0x00000001))
> return -1;
>
> /* Now look for an "ibm,aix-loc" property that gives us ordering
> @@ -202,7 +202,7 @@ static int __init add_legacy_isa_port(struct device_node *np,
> taddr = 0;
>
> /* Add port, irq will be dealt with later */
> - return add_legacy_port(np, index, UPIO_PORT, reg[1], taddr,
> + return add_legacy_port(np, index, UPIO_PORT, be32_to_cpu(reg[1]), taddr,
> NO_IRQ, UPF_BOOT_AUTOCONF, 0);
>
> }
> @@ -251,9 +251,9 @@ static int __init add_legacy_pci_port(struct device_node *np,
> * we get to their "reg" property
> */
> if (np != pci_dev) {
> - const u32 *reg = of_get_property(np, "reg", NULL);
> - if (reg && (*reg < 4))
> - index = lindex = *reg;
> + const __be32 *reg = of_get_property(np, "reg", NULL);
> + if (reg && (be32_to_cpup(reg) < 4))
> + index = lindex = be32_to_cpup(reg);
> }
>
> /* Local index means it's the Nth port in the PCI chip. Unfortunately
> @@ -507,7 +507,7 @@ static int __init check_legacy_serial_console(void)
> struct device_node *prom_stdout = NULL;
> int i, speed = 0, offset = 0;
> const char *name;
> - const u32 *spd;
> + const __be32 *spd;
>
> DBG(" -> check_legacy_serial_console()\n");
>
> @@ -547,7 +547,7 @@ static int __init check_legacy_serial_console(void)
> }
> spd = of_get_property(prom_stdout, "current-speed", NULL);
> if (spd)
> - speed = *spd;
> + speed = be32_to_cpup(spd);
>
> if (strcmp(name, "serial") != 0)
> goto not_found;
> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> index 2af8fd1..17849dc 100644
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -31,8 +31,8 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
> {
> struct resource resource;
> struct device_node *np = ofdev->dev.of_node;
> - const unsigned int *clk, *spd;
> - const u32 *prop;
> + const __be32 *clk, *spd;
> + const __be32 *prop;
> int ret, prop_size;
>
> memset(port, 0, sizeof *port);
> @@ -55,23 +55,23 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
> /* Check for shifted address mapping */
> prop = of_get_property(np, "reg-offset", &prop_size);
> if (prop && (prop_size == sizeof(u32)))
> - port->mapbase += *prop;
> + port->mapbase += be32_to_cpup(prop);
>
> /* Check for registers offset within the devices address range */
> prop = of_get_property(np, "reg-shift", &prop_size);
> if (prop && (prop_size == sizeof(u32)))
> - port->regshift = *prop;
> + port->regshift = be32_to_cpup(prop);
>
> port->irq = irq_of_parse_and_map(np, 0);
> port->iotype = UPIO_MEM;
> port->type = type;
> - port->uartclk = *clk;
> + port->uartclk = be32_to_cpup(clk);
> port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
> | UPF_FIXED_PORT | UPF_FIXED_TYPE;
> port->dev = &ofdev->dev;
> /* If current-speed was set, then try not to change it. */
> if (spd)
> - port->custom_divisor = *clk / (16 * (*spd));
> + port->custom_divisor = be32_to_cpup(clk) / (16 * (be32_to_cpup(spd)));
>
> return 0;
> }
> --
> 1.7.1
>
^ permalink raw reply
* Re: [PATCH 14/18] powerpc, of_serial: Endianness issues setting up the serial ports
From: Grant Likely @ 2010-10-07 23:23 UTC (permalink / raw)
To: Ian Munsie
Cc: Greg Kroah-Hartman, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
Sean MacLennan, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Stefan Weil,
Jiri Kosina, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, David S. Miller
In-Reply-To: <1285916771-18033-15-git-send-email-imunsie-8fk3Idey6ehBDgjK7y7TUQ@public.gmane.org>
On Fri, Oct 01, 2010 at 05:06:07PM +1000, Ian Munsie wrote:
> From: Ian Munsie <imunsie-8fk3Idey6ehBDgjK7y7TUQ@public.gmane.org>
>
> The speed and clock of the serial ports is retrieved from the device
> tree in both the PowerPC legacy serial code and the Open Firmware serial
> driver, therefore they need to handle the fact that the device tree is
> always big endian, while the CPU may not be.
>
> Also fix other device tree references in the legacy serial code.
>
> Signed-off-by: Ian Munsie <imunsie-8fk3Idey6ehBDgjK7y7TUQ@public.gmane.org>
Applied, thanks.
I'm picking up this one because it is also needed by Microblaze.
Michal Simek also posted a patch that does the same thing, but this
one is better so I'm dropping his in favour of this one.
As for the other patches, they all look good to me (at least for the
bits that I care about), but I'll leave them for Ben to pick up so the
series doesn't get too fragmented.
g.
> ---
> arch/powerpc/kernel/legacy_serial.c | 22 +++++++++++-----------
> drivers/serial/of_serial.c | 12 ++++++------
> 2 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
> index c1fd0f9..c834757 100644
> --- a/arch/powerpc/kernel/legacy_serial.c
> +++ b/arch/powerpc/kernel/legacy_serial.c
> @@ -52,14 +52,14 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
> phys_addr_t taddr, unsigned long irq,
> upf_t flags, int irq_check_parent)
> {
> - const u32 *clk, *spd;
> + const __be32 *clk, *spd;
> u32 clock = BASE_BAUD * 16;
> int index;
>
> /* get clock freq. if present */
> clk = of_get_property(np, "clock-frequency", NULL);
> if (clk && *clk)
> - clock = *clk;
> + clock = be32_to_cpup(clk);
>
> /* get default speed if present */
> spd = of_get_property(np, "current-speed", NULL);
> @@ -109,7 +109,7 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
> legacy_serial_infos[index].taddr = taddr;
> legacy_serial_infos[index].np = of_node_get(np);
> legacy_serial_infos[index].clock = clock;
> - legacy_serial_infos[index].speed = spd ? *spd : 0;
> + legacy_serial_infos[index].speed = spd ? be32_to_cpup(spd) : 0;
> legacy_serial_infos[index].irq_check_parent = irq_check_parent;
>
> printk(KERN_DEBUG "Found legacy serial port %d for %s\n",
> @@ -168,7 +168,7 @@ static int __init add_legacy_soc_port(struct device_node *np,
> static int __init add_legacy_isa_port(struct device_node *np,
> struct device_node *isa_brg)
> {
> - const u32 *reg;
> + const __be32 *reg;
> const char *typep;
> int index = -1;
> u64 taddr;
> @@ -181,7 +181,7 @@ static int __init add_legacy_isa_port(struct device_node *np,
> return -1;
>
> /* Verify it's an IO port, we don't support anything else */
> - if (!(reg[0] & 0x00000001))
> + if (!(be32_to_cpu(reg[0]) & 0x00000001))
> return -1;
>
> /* Now look for an "ibm,aix-loc" property that gives us ordering
> @@ -202,7 +202,7 @@ static int __init add_legacy_isa_port(struct device_node *np,
> taddr = 0;
>
> /* Add port, irq will be dealt with later */
> - return add_legacy_port(np, index, UPIO_PORT, reg[1], taddr,
> + return add_legacy_port(np, index, UPIO_PORT, be32_to_cpu(reg[1]), taddr,
> NO_IRQ, UPF_BOOT_AUTOCONF, 0);
>
> }
> @@ -251,9 +251,9 @@ static int __init add_legacy_pci_port(struct device_node *np,
> * we get to their "reg" property
> */
> if (np != pci_dev) {
> - const u32 *reg = of_get_property(np, "reg", NULL);
> - if (reg && (*reg < 4))
> - index = lindex = *reg;
> + const __be32 *reg = of_get_property(np, "reg", NULL);
> + if (reg && (be32_to_cpup(reg) < 4))
> + index = lindex = be32_to_cpup(reg);
> }
>
> /* Local index means it's the Nth port in the PCI chip. Unfortunately
> @@ -507,7 +507,7 @@ static int __init check_legacy_serial_console(void)
> struct device_node *prom_stdout = NULL;
> int i, speed = 0, offset = 0;
> const char *name;
> - const u32 *spd;
> + const __be32 *spd;
>
> DBG(" -> check_legacy_serial_console()\n");
>
> @@ -547,7 +547,7 @@ static int __init check_legacy_serial_console(void)
> }
> spd = of_get_property(prom_stdout, "current-speed", NULL);
> if (spd)
> - speed = *spd;
> + speed = be32_to_cpup(spd);
>
> if (strcmp(name, "serial") != 0)
> goto not_found;
> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> index 2af8fd1..17849dc 100644
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -31,8 +31,8 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
> {
> struct resource resource;
> struct device_node *np = ofdev->dev.of_node;
> - const unsigned int *clk, *spd;
> - const u32 *prop;
> + const __be32 *clk, *spd;
> + const __be32 *prop;
> int ret, prop_size;
>
> memset(port, 0, sizeof *port);
> @@ -55,23 +55,23 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
> /* Check for shifted address mapping */
> prop = of_get_property(np, "reg-offset", &prop_size);
> if (prop && (prop_size == sizeof(u32)))
> - port->mapbase += *prop;
> + port->mapbase += be32_to_cpup(prop);
>
> /* Check for registers offset within the devices address range */
> prop = of_get_property(np, "reg-shift", &prop_size);
> if (prop && (prop_size == sizeof(u32)))
> - port->regshift = *prop;
> + port->regshift = be32_to_cpup(prop);
>
> port->irq = irq_of_parse_and_map(np, 0);
> port->iotype = UPIO_MEM;
> port->type = type;
> - port->uartclk = *clk;
> + port->uartclk = be32_to_cpup(clk);
> port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
> | UPF_FIXED_PORT | UPF_FIXED_TYPE;
> port->dev = &ofdev->dev;
> /* If current-speed was set, then try not to change it. */
> if (spd)
> - port->custom_divisor = *clk / (16 * (*spd));
> + port->custom_divisor = be32_to_cpup(clk) / (16 * (be32_to_cpup(spd)));
>
> return 0;
> }
> --
> 1.7.1
>
^ permalink raw reply
* Re: [PATCH 14/18] powerpc, of_serial: Endianness issues setting up the serial ports
From: Grant Likely @ 2010-10-07 23:23 UTC (permalink / raw)
To: Ian Munsie
Cc: Michal Simek, Greg Kroah-Hartman, devicetree-discuss,
Sean MacLennan, linux-kernel, Stefan Weil, paulus, Jiri Kosina,
linuxppc-dev, David S. Miller
In-Reply-To: <1285916771-18033-15-git-send-email-imunsie@au1.ibm.com>
On Fri, Oct 01, 2010 at 05:06:07PM +1000, Ian Munsie wrote:
> From: Ian Munsie <imunsie@au1.ibm.com>
>
> The speed and clock of the serial ports is retrieved from the device
> tree in both the PowerPC legacy serial code and the Open Firmware serial
> driver, therefore they need to handle the fact that the device tree is
> always big endian, while the CPU may not be.
>
> Also fix other device tree references in the legacy serial code.
>
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
Applied, thanks.
I'm picking up this one because it is also needed by Microblaze.
Michal Simek also posted a patch that does the same thing, but this
one is better so I'm dropping his in favour of this one.
As for the other patches, they all look good to me (at least for the
bits that I care about), but I'll leave them for Ben to pick up so the
series doesn't get too fragmented.
g.
> ---
> arch/powerpc/kernel/legacy_serial.c | 22 +++++++++++-----------
> drivers/serial/of_serial.c | 12 ++++++------
> 2 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
> index c1fd0f9..c834757 100644
> --- a/arch/powerpc/kernel/legacy_serial.c
> +++ b/arch/powerpc/kernel/legacy_serial.c
> @@ -52,14 +52,14 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
> phys_addr_t taddr, unsigned long irq,
> upf_t flags, int irq_check_parent)
> {
> - const u32 *clk, *spd;
> + const __be32 *clk, *spd;
> u32 clock = BASE_BAUD * 16;
> int index;
>
> /* get clock freq. if present */
> clk = of_get_property(np, "clock-frequency", NULL);
> if (clk && *clk)
> - clock = *clk;
> + clock = be32_to_cpup(clk);
>
> /* get default speed if present */
> spd = of_get_property(np, "current-speed", NULL);
> @@ -109,7 +109,7 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
> legacy_serial_infos[index].taddr = taddr;
> legacy_serial_infos[index].np = of_node_get(np);
> legacy_serial_infos[index].clock = clock;
> - legacy_serial_infos[index].speed = spd ? *spd : 0;
> + legacy_serial_infos[index].speed = spd ? be32_to_cpup(spd) : 0;
> legacy_serial_infos[index].irq_check_parent = irq_check_parent;
>
> printk(KERN_DEBUG "Found legacy serial port %d for %s\n",
> @@ -168,7 +168,7 @@ static int __init add_legacy_soc_port(struct device_node *np,
> static int __init add_legacy_isa_port(struct device_node *np,
> struct device_node *isa_brg)
> {
> - const u32 *reg;
> + const __be32 *reg;
> const char *typep;
> int index = -1;
> u64 taddr;
> @@ -181,7 +181,7 @@ static int __init add_legacy_isa_port(struct device_node *np,
> return -1;
>
> /* Verify it's an IO port, we don't support anything else */
> - if (!(reg[0] & 0x00000001))
> + if (!(be32_to_cpu(reg[0]) & 0x00000001))
> return -1;
>
> /* Now look for an "ibm,aix-loc" property that gives us ordering
> @@ -202,7 +202,7 @@ static int __init add_legacy_isa_port(struct device_node *np,
> taddr = 0;
>
> /* Add port, irq will be dealt with later */
> - return add_legacy_port(np, index, UPIO_PORT, reg[1], taddr,
> + return add_legacy_port(np, index, UPIO_PORT, be32_to_cpu(reg[1]), taddr,
> NO_IRQ, UPF_BOOT_AUTOCONF, 0);
>
> }
> @@ -251,9 +251,9 @@ static int __init add_legacy_pci_port(struct device_node *np,
> * we get to their "reg" property
> */
> if (np != pci_dev) {
> - const u32 *reg = of_get_property(np, "reg", NULL);
> - if (reg && (*reg < 4))
> - index = lindex = *reg;
> + const __be32 *reg = of_get_property(np, "reg", NULL);
> + if (reg && (be32_to_cpup(reg) < 4))
> + index = lindex = be32_to_cpup(reg);
> }
>
> /* Local index means it's the Nth port in the PCI chip. Unfortunately
> @@ -507,7 +507,7 @@ static int __init check_legacy_serial_console(void)
> struct device_node *prom_stdout = NULL;
> int i, speed = 0, offset = 0;
> const char *name;
> - const u32 *spd;
> + const __be32 *spd;
>
> DBG(" -> check_legacy_serial_console()\n");
>
> @@ -547,7 +547,7 @@ static int __init check_legacy_serial_console(void)
> }
> spd = of_get_property(prom_stdout, "current-speed", NULL);
> if (spd)
> - speed = *spd;
> + speed = be32_to_cpup(spd);
>
> if (strcmp(name, "serial") != 0)
> goto not_found;
> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> index 2af8fd1..17849dc 100644
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -31,8 +31,8 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
> {
> struct resource resource;
> struct device_node *np = ofdev->dev.of_node;
> - const unsigned int *clk, *spd;
> - const u32 *prop;
> + const __be32 *clk, *spd;
> + const __be32 *prop;
> int ret, prop_size;
>
> memset(port, 0, sizeof *port);
> @@ -55,23 +55,23 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
> /* Check for shifted address mapping */
> prop = of_get_property(np, "reg-offset", &prop_size);
> if (prop && (prop_size == sizeof(u32)))
> - port->mapbase += *prop;
> + port->mapbase += be32_to_cpup(prop);
>
> /* Check for registers offset within the devices address range */
> prop = of_get_property(np, "reg-shift", &prop_size);
> if (prop && (prop_size == sizeof(u32)))
> - port->regshift = *prop;
> + port->regshift = be32_to_cpup(prop);
>
> port->irq = irq_of_parse_and_map(np, 0);
> port->iotype = UPIO_MEM;
> port->type = type;
> - port->uartclk = *clk;
> + port->uartclk = be32_to_cpup(clk);
> port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
> | UPF_FIXED_PORT | UPF_FIXED_TYPE;
> port->dev = &ofdev->dev;
> /* If current-speed was set, then try not to change it. */
> if (spd)
> - port->custom_divisor = *clk / (16 * (*spd));
> + port->custom_divisor = be32_to_cpup(clk) / (16 * (be32_to_cpup(spd)));
>
> return 0;
> }
> --
> 1.7.1
>
^ permalink raw reply
* Re: [PATCH] wireless: Set some stats used by /proc/net/wireless (wext)
From: Johannes Berg @ 2010-10-07 23:19 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless
In-Reply-To: <1286493275-18364-1-git-send-email-greearb@candelatech.com>
On Thu, 2010-10-07 at 16:14 -0700, greearb@candelatech.com wrote:
> @@ -468,6 +468,7 @@ struct rate_info {
> * @tx_packets: packets transmitted to this station
> * @tx_retries: cumulative retry counts
> * @tx_failed: number of failed transmissions (retries exceeded, no ACK)
> + * @rx_dropped_misc: Dropped for un-specified reason.
also need to use/adjust "filled" throughout.
johannes
^ permalink raw reply
* Re: [PATCH] Make it possible to set a uuid if one was not set during DM_DEV_CREATE.
From: Jonathan Brassow @ 2010-10-07 23:19 UTC (permalink / raw)
To: device-mapper development
In-Reply-To: <1286479718-18274-1-git-send-email-pjones@redhat.com>
Minor nits below
brassow
On Oct 7, 2010, at 2:28 PM, Peter Jones wrote:
> This makes it possible to use DM_DEV_RENAME to add a uuid to a
> device so
> long as one has not been previously set either with DM_DEV_CREATE or
> with DM_DEV_RENAME.
Seems like a sensible thing. Is there a reason this is coming up now?
>
> Also bump the minor number to 19.
> ---
> drivers/md/dm-ioctl.c | 113 +++++++++++++++++++++++++++++++
> +-------------
> include/linux/dm-ioctl.h | 9 +++-
> 2 files changed, 87 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c
> index 3e39193..bd76846 100644
> --- a/drivers/md/dm-ioctl.c
> +++ b/drivers/md/dm-ioctl.c
> @@ -298,7 +298,7 @@ retry:
> static struct mapped_device *dm_hash_rename(struct dm_ioctl *param,
>
<snip>
> /*
> @@ -333,19 +347,42 @@ static struct mapped_device
> *dm_hash_rename(struct dm_ioctl *param,
> DMWARN("asked to rename a non-existent device %s -> %s",
> param->name, new);
> up_write(&_hash_lock);
> - kfree(new_name);
> + kfree(new_data);
> return ERR_PTR(-ENXIO);
> }
>
> - /*
> - * rename and move the name cell.
> - */
> - list_del(&hc->name_list);
> - old_name = hc->name;
> - mutex_lock(&dm_hash_cells_mutex);
> - hc->name = new_name;
> - mutex_unlock(&dm_hash_cells_mutex);
> - list_add(&hc->name_list, _name_buckets + hash_str(new_name));
> + if (param->flags & DM_NEW_UUID_FLAG) {
> + /*
> + * Does this device already have a uuid?
> + */
> + if (hc->uuid) {
> + DMWARN("asked to change uuid of device with uuid "
> + "already set %s %s -> %s",
> + param->name, hc->uuid, param->uuid);
Message doesn't imply this is illegal... Perhaps "Unable to change...
set"?
> + up_write(&_hash_lock);
> + kfree(new_uuid);
Will patch compile? s/new_uuid/new_data/
> + return ERR_PTR(-EINVAL);
> + }
> + /*
> + * reuuid and move the uuid cell.
> + */
> + list_del(&hc->uuid_list);
> + old_data = hc->uuid;
> + mutex_lock(&dm_hash_cells_mutex);
> + hc->uuid = new_data;
> + mutex_unlock(&dm_hash_cells_mutex);
> + list_add(&hc->uuid_list, _uuid_buckets + hash_str(new_data));
> + } else {
> + /*
> + * rename and move the name cell.
> + */
> + list_del(&hc->name_list);
> + old_data = hc->name;
> + mutex_lock(&dm_hash_cells_mutex);
> + hc->name = new_data;
> + mutex_unlock(&dm_hash_cells_mutex);
> + list_add(&hc->name_list, _name_buckets + hash_str(new_data));
> + }
>
> /*
> * Wake up any dm event waiters.
> @@ -361,7 +398,7 @@ static struct mapped_device
> *dm_hash_rename(struct dm_ioctl *param,
>
> md = hc->md;
> up_write(&_hash_lock);
> - kfree(old_name);
> + kfree(old_data);
>
> return md;
> }
> @@ -774,21 +811,31 @@ static int invalid_str(char *str, void *end)
> static int dev_rename(struct dm_ioctl *param, size_t param_size)
> {
> int r;
> - char *new_name = (char *) param + param->data_start;
> + char *new_data = (char *) param + param->data_start;
> struct mapped_device *md;
>
> - if (new_name < param->data ||
> - invalid_str(new_name, (void *) param + param_size) ||
> - strlen(new_name) > DM_NAME_LEN - 1) {
> - DMWARN("Invalid new logical volume name supplied.");
> - return -EINVAL;
> - }
> + if (param->flags & DM_NEW_UUID_FLAG) {
> + struct hash_cell *hc;
Is this newly declared variable needed?
> + if (new_data < param->data ||
> + invalid_str(new_data, (void *) param + param_size) ||
> + strlen(new_data) > DM_UUID_LEN - 1) {
> + DMWARN("Invalid new logical volume uuid supplied.");
I wonder why we were using "logical volume" instead of "device" like
everywhere else... can we change it now?
> + return -EINVAL;
> + }
> + } else {
> + if (new_data < param->data ||
> + invalid_str(new_data, (void *) param + param_size) ||
> + strlen(new_data) > DM_NAME_LEN - 1) {
> + DMWARN("Invalid new logical volume name supplied.");
s/logical volume/device/
> + return -EINVAL;
> + }
>
> - r = check_name(new_name);
> - if (r)
> - return r;
> + r = check_name(new_data);
> + if (r)
> + return r;
> + }
>
> - md = dm_hash_rename(param, new_name);
> + md = dm_hash_rename(param, new_data);
> if (IS_ERR(md))
> return PTR_ERR(md);
>
> diff --git a/include/linux/dm-ioctl.h b/include/linux/dm-ioctl.h
> index 49eab36..e369460 100644
> --- a/include/linux/dm-ioctl.h
> +++ b/include/linux/dm-ioctl.h
> @@ -267,9 +267,9 @@ enum {
> #define DM_DEV_SET_GEOMETRY _IOWR(DM_IOCTL, DM_DEV_SET_GEOMETRY_CMD,
> struct dm_ioctl)
>
> #define DM_VERSION_MAJOR 4
> -#define DM_VERSION_MINOR 18
> +#define DM_VERSION_MINOR 19
> #define DM_VERSION_PATCHLEVEL 0
> -#define DM_VERSION_EXTRA "-ioctl (2010-06-29)"
> +#define DM_VERSION_EXTRA "-ioctl (2010-10-07)"
>
> /* Status bits */
> #define DM_READONLY_FLAG (1 << 0) /* In/Out */
> @@ -322,4 +322,9 @@ enum {
> */
> #define DM_UEVENT_GENERATED_FLAG (1 << 13) /* Out */
>
> +/*
> + * If set, rename operates on uuid, not name.
> + */
> +#define DM_NEW_UUID_FLAG (1 << 14) /* In */
> +
> #endif /* _LINUX_DM_IOCTL_H */
> --
> 1.7.2.2
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply
* task blocked for more than 120 seconds.
From: Shawn Bohrer @ 2010-10-07 23:18 UTC (permalink / raw)
To: linux-nfs; +Cc: linux-kernel
Hello,
I've got some machines with nfs mounted home directories and recently
had the machines lock up with the following output below from the
kernel logs. This machine was running 2.6.32.21 at the time, and
was locked up for at least 20 minutes before we rebooted. We've had
this happen to us twice now, so while I haven't tried I believe we can
reproduce it in about a day.
Does anyone have any insight on what may be happening here or any
suggestions for debugging?
Thanks,
Shawn
INFO: task java:24970 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
java D ffff88189c50e198 0 24970 24239 0x00000000
ffff88205b7339c8 0000000000000086 0000000000000000 000000005ae2d09c
0000000000000286 0000000000000030 ffff88205b733988 000000010174a797
ffff88205acd4a80 ffff88205b733fd8 000000000000e198 ffff88205acd4a80
Call Trace:
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff81419df3>] io_schedule+0x73/0xc0
[<ffffffffa03fe02e>] nfs_wait_bit_uninterruptible+0xe/0x20 [nfs]
[<ffffffff8141a61f>] __wait_on_bit+0x5f/0x90
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff8141a6c8>] out_of_line_wait_on_bit+0x78/0x90
[<ffffffff8107fe50>] ? wake_bit_function+0x0/0x40
[<ffffffff810e11ce>] ? find_get_page+0x1e/0xa0
[<ffffffffa03fe00f>] nfs_wait_on_request+0x2f/0x40 [nfs]
[<ffffffffa0403d77>] nfs_updatepage+0x107/0x4f0 [nfs]
[<ffffffffa03f3a6a>] nfs_write_end+0x5a/0x2c0 [nfs]
[<ffffffff8100c9ce>] ? common_interrupt+0xe/0x13
[<ffffffff810e0bb4>] generic_file_buffered_write+0x174/0x2a0
[<ffffffff810e25f0>] __generic_file_aio_write+0x240/0x470
[<ffffffff81047774>] ? __enqueue_entity+0x84/0x90
[<ffffffff8104f7d5>] ? enqueue_task_fair+0x45/0x90
[<ffffffff810e288f>] generic_file_aio_write+0x6f/0xe0
[<ffffffffa03f371a>] nfs_file_write+0xda/0x1e0 [nfs]
[<ffffffff8112fb7a>] do_sync_write+0xfa/0x140
[<ffffffff8107fe10>] ? autoremove_wake_function+0x0/0x40
[<ffffffff811bd246>] ? security_file_permission+0x16/0x20
[<ffffffff8112fe78>] vfs_write+0xb8/0x1a0
[<ffffffff81130711>] sys_write+0x51/0x90
[<ffffffff8100c11b>] system_call_fastpath+0x16/0x1b
INFO: task java:24982 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
java D ffff8800283ee198 0 24982 24239 0x00000000
ffff88104f6339c8 0000000000000086 0000000000000000 00000000ffffff10
0000000000000286 0000000000000030 0000000000000282 000000010174a681
ffff88105a592580 ffff88104f633fd8 000000000000e198 ffff88105a592580
Call Trace:
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff81419df3>] io_schedule+0x73/0xc0
[<ffffffffa03fe02e>] nfs_wait_bit_uninterruptible+0xe/0x20 [nfs]
[<ffffffff8141a61f>] __wait_on_bit+0x5f/0x90
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff8141a6c8>] out_of_line_wait_on_bit+0x78/0x90
[<ffffffff8107fe50>] ? wake_bit_function+0x0/0x40
[<ffffffff810e11ce>] ? find_get_page+0x1e/0xa0
[<ffffffffa03fe00f>] nfs_wait_on_request+0x2f/0x40 [nfs]
[<ffffffffa0403d77>] nfs_updatepage+0x107/0x4f0 [nfs]
[<ffffffffa03f3a6a>] nfs_write_end+0x5a/0x2c0 [nfs]
[<ffffffff810e0bb4>] generic_file_buffered_write+0x174/0x2a0
[<ffffffff810e25f0>] __generic_file_aio_write+0x240/0x470
[<ffffffff810e288f>] generic_file_aio_write+0x6f/0xe0
[<ffffffffa03f371a>] nfs_file_write+0xda/0x1e0 [nfs]
[<ffffffff8112fb7a>] do_sync_write+0xfa/0x140
[<ffffffff810ffef9>] ? do_wp_page+0x109/0x7c0
[<ffffffff8107fe10>] ? autoremove_wake_function+0x0/0x40
[<ffffffff811bd246>] ? security_file_permission+0x16/0x20
[<ffffffff8112fe78>] vfs_write+0xb8/0x1a0
[<ffffffff81130711>] sys_write+0x51/0x90
[<ffffffff8100c11b>] system_call_fastpath+0x16/0x1b
INFO: task hbitimestamp:23184 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
hbitimestamp D ffff88109c6ae198 0 23184 23175 0x00000000
ffff880855d179c8 0000000000000086 0000000000000000 000000005bb2d600
0000000000000282 0000000000000030 0000000000000282 00000001017445ab
ffff8808577bc640 ffff880855d17fd8 000000000000e198 ffff8808577bc640
Call Trace:
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff81419df3>] io_schedule+0x73/0xc0
[<ffffffffa03fe02e>] nfs_wait_bit_uninterruptible+0xe/0x20 [nfs]
[<ffffffff8141a61f>] __wait_on_bit+0x5f/0x90
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff8141a6c8>] out_of_line_wait_on_bit+0x78/0x90
[<ffffffff8107fe50>] ? wake_bit_function+0x0/0x40
[<ffffffff810e11ce>] ? find_get_page+0x1e/0xa0
[<ffffffffa03fe00f>] nfs_wait_on_request+0x2f/0x40 [nfs]
[<ffffffffa0403d77>] nfs_updatepage+0x107/0x4f0 [nfs]
[<ffffffffa03f3a6a>] nfs_write_end+0x5a/0x2c0 [nfs]
[<ffffffff810e0bb4>] generic_file_buffered_write+0x174/0x2a0
[<ffffffff810e25f0>] __generic_file_aio_write+0x240/0x470
[<ffffffff810e288f>] generic_file_aio_write+0x6f/0xe0
[<ffffffffa03f371a>] nfs_file_write+0xda/0x1e0 [nfs]
[<ffffffff8112fb7a>] do_sync_write+0xfa/0x140
[<ffffffff8107fe10>] ? autoremove_wake_function+0x0/0x40
[<ffffffff8100cb4e>] ? apic_timer_interrupt+0xe/0x20
[<ffffffff811bd246>] ? security_file_permission+0x16/0x20
[<ffffffff8112fe78>] vfs_write+0xb8/0x1a0
[<ffffffff81130711>] sys_write+0x51/0x90
[<ffffffff8141c74e>] ? do_device_not_available+0xe/0x10
[<ffffffff8100c11b>] system_call_fastpath+0x16/0x1b
INFO: task java:24970 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
java D ffff88189c50e198 0 24970 24239 0x00000000
ffff88205b7339c8 0000000000000086 0000000000000000 000000005ae2d09c
0000000000000286 0000000000000030 ffff88205b733988 000000010174a797
ffff88205acd4a80 ffff88205b733fd8 000000000000e198 ffff88205acd4a80
Call Trace:
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff81419df3>] io_schedule+0x73/0xc0
[<ffffffffa03fe02e>] nfs_wait_bit_uninterruptible+0xe/0x20 [nfs]
[<ffffffff8141a61f>] __wait_on_bit+0x5f/0x90
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff8141a6c8>] out_of_line_wait_on_bit+0x78/0x90
[<ffffffff8107fe50>] ? wake_bit_function+0x0/0x40
[<ffffffff810e11ce>] ? find_get_page+0x1e/0xa0
[<ffffffffa03fe00f>] nfs_wait_on_request+0x2f/0x40 [nfs]
[<ffffffffa0403d77>] nfs_updatepage+0x107/0x4f0 [nfs]
[<ffffffffa03f3a6a>] nfs_write_end+0x5a/0x2c0 [nfs]
[<ffffffff8100c9ce>] ? common_interrupt+0xe/0x13
[<ffffffff810e0bb4>] generic_file_buffered_write+0x174/0x2a0
[<ffffffff810e25f0>] __generic_file_aio_write+0x240/0x470
[<ffffffff81047774>] ? __enqueue_entity+0x84/0x90
[<ffffffff8104f7d5>] ? enqueue_task_fair+0x45/0x90
[<ffffffff810e288f>] generic_file_aio_write+0x6f/0xe0
[<ffffffffa03f371a>] nfs_file_write+0xda/0x1e0 [nfs]
[<ffffffff8112fb7a>] do_sync_write+0xfa/0x140
[<ffffffff8107fe10>] ? autoremove_wake_function+0x0/0x40
[<ffffffff811bd246>] ? security_file_permission+0x16/0x20
[<ffffffff8112fe78>] vfs_write+0xb8/0x1a0
[<ffffffff81130711>] sys_write+0x51/0x90
[<ffffffff8100c11b>] system_call_fastpath+0x16/0x1b
INFO: task java:24982 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
java D ffff8800283ee198 0 24982 24239 0x00000000
ffff88104f6339c8 0000000000000086 0000000000000000 00000000ffffff10
0000000000000286 0000000000000030 0000000000000282 000000010174a681
ffff88105a592580 ffff88104f633fd8 000000000000e198 ffff88105a592580
Call Trace:
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff81419df3>] io_schedule+0x73/0xc0
[<ffffffffa03fe02e>] nfs_wait_bit_uninterruptible+0xe/0x20 [nfs]
[<ffffffff8141a61f>] __wait_on_bit+0x5f/0x90
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff8141a6c8>] out_of_line_wait_on_bit+0x78/0x90
[<ffffffff8107fe50>] ? wake_bit_function+0x0/0x40
[<ffffffff810e11ce>] ? find_get_page+0x1e/0xa0
[<ffffffffa03fe00f>] nfs_wait_on_request+0x2f/0x40 [nfs]
[<ffffffffa0403d77>] nfs_updatepage+0x107/0x4f0 [nfs]
[<ffffffffa03f3a6a>] nfs_write_end+0x5a/0x2c0 [nfs]
[<ffffffff810e0bb4>] generic_file_buffered_write+0x174/0x2a0
[<ffffffff810e25f0>] __generic_file_aio_write+0x240/0x470
[<ffffffff810e288f>] generic_file_aio_write+0x6f/0xe0
[<ffffffffa03f371a>] nfs_file_write+0xda/0x1e0 [nfs]
[<ffffffff8112fb7a>] do_sync_write+0xfa/0x140
[<ffffffff810ffef9>] ? do_wp_page+0x109/0x7c0
[<ffffffff8107fe10>] ? autoremove_wake_function+0x0/0x40
[<ffffffff811bd246>] ? security_file_permission+0x16/0x20
[<ffffffff8112fe78>] vfs_write+0xb8/0x1a0
[<ffffffff81130711>] sys_write+0x51/0x90
[<ffffffff8100c11b>] system_call_fastpath+0x16/0x1b
INFO: task tail:22115 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
tail D ffff88189c4ee198 0 22115 14494 0x00000000
ffff88085b95bbd8 0000000000000086 0000000000000000 ffffffffa035d896
ffff88205be57cc8 ffff88205be57cc8 ffff88205be57cc8 000000010174d70e
ffff8808564fe400 ffff88085b95bfd8 000000000000e198 ffff8808564fe400
Call Trace:
[<ffffffffa035d896>] ? __rpc_execute+0xd6/0x2a0 [sunrpc]
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff81419df3>] io_schedule+0x73/0xc0
[<ffffffffa03fe02e>] nfs_wait_bit_uninterruptible+0xe/0x20 [nfs]
[<ffffffff8141a61f>] __wait_on_bit+0x5f/0x90
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff8141a6c8>] out_of_line_wait_on_bit+0x78/0x90
[<ffffffff8107fe50>] ? wake_bit_function+0x0/0x40
[<ffffffffa03fe00f>] nfs_wait_on_request+0x2f/0x40 [nfs]
[<ffffffffa04037d2>] nfs_sync_mapping_wait+0x122/0x260 [nfs]
[<ffffffffa0403aa9>] nfs_write_mapping+0x79/0xb0 [nfs]
[<ffffffffa0403afa>] nfs_wb_nocommit+0x1a/0x20 [nfs]
[<ffffffffa03f60f8>] nfs_getattr+0x128/0x140 [nfs]
[<ffffffff811351d1>] vfs_getattr+0x51/0x80
[<ffffffff8113548f>] vfs_fstat+0x3f/0x60
[<ffffffff811354d4>] sys_newfstat+0x24/0x40
[<ffffffff810841a4>] ? sys_nanosleep+0x74/0x80
[<ffffffff8100c11b>] system_call_fastpath+0x16/0x1b
INFO: task hbitimestamp:23184 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
hbitimestamp D ffff88109c6ae198 0 23184 23175 0x00000000
ffff880855d179c8 0000000000000086 0000000000000000 000000005bb2d600
0000000000000282 0000000000000030 0000000000000282 00000001017445ab
ffff8808577bc640 ffff880855d17fd8 000000000000e198 ffff8808577bc640
Call Trace:
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff81419df3>] io_schedule+0x73/0xc0
[<ffffffffa03fe02e>] nfs_wait_bit_uninterruptible+0xe/0x20 [nfs]
[<ffffffff8141a61f>] __wait_on_bit+0x5f/0x90
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff8141a6c8>] out_of_line_wait_on_bit+0x78/0x90
[<ffffffff8107fe50>] ? wake_bit_function+0x0/0x40
[<ffffffff810e11ce>] ? find_get_page+0x1e/0xa0
[<ffffffffa03fe00f>] nfs_wait_on_request+0x2f/0x40 [nfs]
[<ffffffffa0403d77>] nfs_updatepage+0x107/0x4f0 [nfs]
[<ffffffffa03f3a6a>] nfs_write_end+0x5a/0x2c0 [nfs]
[<ffffffff810e0bb4>] generic_file_buffered_write+0x174/0x2a0
[<ffffffff810e25f0>] __generic_file_aio_write+0x240/0x470
[<ffffffff810e288f>] generic_file_aio_write+0x6f/0xe0
[<ffffffffa03f371a>] nfs_file_write+0xda/0x1e0 [nfs]
[<ffffffff8112fb7a>] do_sync_write+0xfa/0x140
[<ffffffff8107fe10>] ? autoremove_wake_function+0x0/0x40
[<ffffffff8100cb4e>] ? apic_timer_interrupt+0xe/0x20
[<ffffffff811bd246>] ? security_file_permission+0x16/0x20
[<ffffffff8112fe78>] vfs_write+0xb8/0x1a0
[<ffffffff81130711>] sys_write+0x51/0x90
[<ffffffff8141c74e>] ? do_device_not_available+0xe/0x10
[<ffffffff8100c11b>] system_call_fastpath+0x16/0x1b
INFO: task java:24970 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
java D ffff88189c50e198 0 24970 24239 0x00000000
ffff88205b7339c8 0000000000000086 0000000000000000 000000005ae2d09c
0000000000000286 0000000000000030 ffff88205b733988 000000010174a797
ffff88205acd4a80 ffff88205b733fd8 000000000000e198 ffff88205acd4a80
Call Trace:
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff81419df3>] io_schedule+0x73/0xc0
[<ffffffffa03fe02e>] nfs_wait_bit_uninterruptible+0xe/0x20 [nfs]
[<ffffffff8141a61f>] __wait_on_bit+0x5f/0x90
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff8141a6c8>] out_of_line_wait_on_bit+0x78/0x90
[<ffffffff8107fe50>] ? wake_bit_function+0x0/0x40
[<ffffffff810e11ce>] ? find_get_page+0x1e/0xa0
[<ffffffffa03fe00f>] nfs_wait_on_request+0x2f/0x40 [nfs]
[<ffffffffa0403d77>] nfs_updatepage+0x107/0x4f0 [nfs]
[<ffffffffa03f3a6a>] nfs_write_end+0x5a/0x2c0 [nfs]
[<ffffffff8100c9ce>] ? common_interrupt+0xe/0x13
[<ffffffff810e0bb4>] generic_file_buffered_write+0x174/0x2a0
[<ffffffff810e25f0>] __generic_file_aio_write+0x240/0x470
[<ffffffff81047774>] ? __enqueue_entity+0x84/0x90
[<ffffffff8104f7d5>] ? enqueue_task_fair+0x45/0x90
[<ffffffff810e288f>] generic_file_aio_write+0x6f/0xe0
[<ffffffffa03f371a>] nfs_file_write+0xda/0x1e0 [nfs]
[<ffffffff8112fb7a>] do_sync_write+0xfa/0x140
[<ffffffff8107fe10>] ? autoremove_wake_function+0x0/0x40
[<ffffffff811bd246>] ? security_file_permission+0x16/0x20
[<ffffffff8112fe78>] vfs_write+0xb8/0x1a0
[<ffffffff81130711>] sys_write+0x51/0x90
[<ffffffff8100c11b>] system_call_fastpath+0x16/0x1b
INFO: task java:24982 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
java D ffff8800283ee198 0 24982 24239 0x00000000
ffff88104f6339c8 0000000000000086 0000000000000000 00000000ffffff10
0000000000000286 0000000000000030 0000000000000282 000000010174a681
ffff88105a592580 ffff88104f633fd8 000000000000e198 ffff88105a592580
Call Trace:
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff81419df3>] io_schedule+0x73/0xc0
[<ffffffffa03fe02e>] nfs_wait_bit_uninterruptible+0xe/0x20 [nfs]
[<ffffffff8141a61f>] __wait_on_bit+0x5f/0x90
[<ffffffffa03fe020>] ? nfs_wait_bit_uninterruptible+0x0/0x20 [nfs]
[<ffffffff8141a6c8>] out_of_line_wait_on_bit+0x78/0x90
[<ffffffff8107fe50>] ? wake_bit_function+0x0/0x40
[<ffffffff810e11ce>] ? find_get_page+0x1e/0xa0
[<ffffffffa03fe00f>] nfs_wait_on_request+0x2f/0x40 [nfs]
[<ffffffffa0403d77>] nfs_updatepage+0x107/0x4f0 [nfs]
[<ffffffffa03f3a6a>] nfs_write_end+0x5a/0x2c0 [nfs]
[<ffffffff810e0bb4>] generic_file_buffered_write+0x174/0x2a0
[<ffffffff810e25f0>] __generic_file_aio_write+0x240/0x470
[<ffffffff810e288f>] generic_file_aio_write+0x6f/0xe0
[<ffffffffa03f371a>] nfs_file_write+0xda/0x1e0 [nfs]
[<ffffffff8112fb7a>] do_sync_write+0xfa/0x140
[<ffffffff810ffef9>] ? do_wp_page+0x109/0x7c0
[<ffffffff8107fe10>] ? autoremove_wake_function+0x0/0x40
[<ffffffff811bd246>] ? security_file_permission+0x16/0x20
[<ffffffff8112fe78>] vfs_write+0xb8/0x1a0
[<ffffffff81130711>] sys_write+0x51/0x90
[<ffffffff8100c11b>] system_call_fastpath+0x16/0x1b
INFO: task hbitimestamp:24427 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
hbitimestamp D ffff88089c40e198 0 24427 24317 0x00000000
ffff88205a0b3c88 0000000000000082 0000000000000000 0000000000000000
ffff88205a0b3ca8 ffffffff814196a8 0000000000000000 00000001017777de
ffff88205a6ec8c0 ffff88205a0b3fd8 000000000000e198 ffff88205a6ec8c0
Call Trace:
[<ffffffff814196a8>] ? thread_return+0x4e/0x726
[<ffffffff8141aac1>] __mutex_lock_slowpath+0xf1/0x170
[<ffffffff8141a9ab>] mutex_lock+0x2b/0x50
[<ffffffff810e2879>] generic_file_aio_write+0x59/0xe0
[<ffffffffa03f371a>] nfs_file_write+0xda/0x1e0 [nfs]
[<ffffffff8112fb7a>] do_sync_write+0xfa/0x140
[<ffffffff810fcb91>] ? __do_fault+0x3e1/0x4c0
[<ffffffff8107fe10>] ? autoremove_wake_function+0x0/0x40
[<ffffffff8116a68f>] ? inotify_inode_queue_event+0x2f/0x120
[<ffffffff811bd246>] ? security_file_permission+0x16/0x20
[<ffffffff8112fe78>] vfs_write+0xb8/0x1a0
[<ffffffff81130711>] sys_write+0x51/0x90
[<ffffffff8141c74e>] ? do_device_not_available+0xe/0x10
[<ffffffff8100c11b>] system_call_fastpath+0x16/0x1b
^ permalink raw reply
* [PATCH] ehea: Fix a checksum issue on the receive path
From: leitao @ 2010-10-07 23:17 UTC (permalink / raw)
To: davem; +Cc: netdev, Breno Leitao, Jay Vosburgh
Currently we set all skbs with CHECKSUM_UNNECESSARY, even
those whose protocol we don't know. This patch just
add the CHECKSUM_COMPLETE tag for non TCP/UDP packets.
Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
---
drivers/net/ehea/ehea_main.c | 9 ++++++++-
drivers/net/ehea/ehea_qmr.h | 1 +
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 0471cae..45fd045 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -533,8 +533,15 @@ static inline void ehea_fill_skb(struct net_device *dev,
int length = cqe->num_bytes_transfered - 4; /*remove CRC */
skb_put(skb, length);
- skb->ip_summed = CHECKSUM_UNNECESSARY;
skb->protocol = eth_type_trans(skb, dev);
+
+ /* The packet was not an IPV4 packet so a complemented checksum was
+ calculated. The value is found in the Internet Checksum field. */
+ if (cqe->status & EHEA_CQE_BLIND_CKSUM) {
+ skb->ip_summed = CHECKSUM_COMPLETE;
+ skb->csum = csum_unfold(~cqe->inet_checksum_value);
+ } else
+ skb->ip_summed = CHECKSUM_UNNECESSARY;
}
static inline struct sk_buff *get_skb_by_index(struct sk_buff **skb_array,
diff --git a/drivers/net/ehea/ehea_qmr.h b/drivers/net/ehea/ehea_qmr.h
index f608a6c..3810473 100644
--- a/drivers/net/ehea/ehea_qmr.h
+++ b/drivers/net/ehea/ehea_qmr.h
@@ -150,6 +150,7 @@ struct ehea_rwqe {
#define EHEA_CQE_TYPE_RQ 0x60
#define EHEA_CQE_STAT_ERR_MASK 0x700F
#define EHEA_CQE_STAT_FAT_ERR_MASK 0xF
+#define EHEA_CQE_BLIND_CKSUM 0x8000
#define EHEA_CQE_STAT_ERR_TCP 0x4000
#define EHEA_CQE_STAT_ERR_IP 0x2000
#define EHEA_CQE_STAT_ERR_CRC 0x1000
--
1.6.5
^ permalink raw reply related
* + alpha-use-single-hae-window-on-t2-core-logic-gamma-sable.patch added to -mm tree
From: akpm @ 2010-10-07 23:16 UTC (permalink / raw)
To: mm-commits; +Cc: ink, mattst88, rth
The patch titled
alpha: use single HAE window on T2 core logic (gamma, sable)
has been added to the -mm tree. Its filename is
alpha-use-single-hae-window-on-t2-core-logic-gamma-sable.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: alpha: use single HAE window on T2 core logic (gamma, sable)
From: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
T2 are the only alpha SMP systems that do HAE switching at runtime, which
is fundamentally racy on SMP. This patch limits MMIO space on T2 to HAE0
only, like we did on MCPCIA (rawhide) long ago. This leaves us with only
112 Mb of PCI MMIO (128 Mb HAE aperture minus 16 Mb reserved for EISA),
but since linux PCI allocations are reasonably tight, it should be enough
for sane hardware configurations.
Also, fix a typo in MCPCIA_FROB_MMIO macro which shouldn't call set_hae()
if MCPCIA_ONE_HAE_WINDOW is defined. It's more for correctness, as
set_hae() is a no-op anyway in that case.
Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Richard Henderson <rth@twiddle.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/alpha/include/asm/core_mcpcia.h | 2
arch/alpha/include/asm/core_t2.h | 54 ++++++++-----------------
arch/alpha/kernel/core_t2.c | 11 +++--
arch/alpha/kernel/machvec_impl.h | 3 +
4 files changed, 30 insertions(+), 40 deletions(-)
diff -puN arch/alpha/include/asm/core_mcpcia.h~alpha-use-single-hae-window-on-t2-core-logic-gamma-sable arch/alpha/include/asm/core_mcpcia.h
--- a/arch/alpha/include/asm/core_mcpcia.h~alpha-use-single-hae-window-on-t2-core-logic-gamma-sable
+++ a/arch/alpha/include/asm/core_mcpcia.h
@@ -247,7 +247,7 @@ struct el_MCPCIA_uncorrected_frame_mchec
#define vip volatile int __force *
#define vuip volatile unsigned int __force *
-#ifdef MCPCIA_ONE_HAE_WINDOW
+#ifndef MCPCIA_ONE_HAE_WINDOW
#define MCPCIA_FROB_MMIO \
if (__mcpcia_is_mmio(hose)) { \
set_hae(hose & 0xffffffff); \
diff -puN arch/alpha/include/asm/core_t2.h~alpha-use-single-hae-window-on-t2-core-logic-gamma-sable arch/alpha/include/asm/core_t2.h
--- a/arch/alpha/include/asm/core_t2.h~alpha-use-single-hae-window-on-t2-core-logic-gamma-sable
+++ a/arch/alpha/include/asm/core_t2.h
@@ -1,6 +1,9 @@
#ifndef __ALPHA_T2__H__
#define __ALPHA_T2__H__
+/* Fit everything into one 128MB HAE window. */
+#define T2_ONE_HAE_WINDOW 1
+
#include <linux/types.h>
#include <linux/spinlock.h>
#include <asm/compiler.h>
@@ -19,7 +22,7 @@
*
*/
-#define T2_MEM_R1_MASK 0x07ffffff /* Mem sparse region 1 mask is 26 bits */
+#define T2_MEM_R1_MASK 0x07ffffff /* Mem sparse region 1 mask is 27 bits */
/* GAMMA-SABLE is a SABLE with EV5-based CPUs */
/* All LYNX machines, EV4 or EV5, use the GAMMA bias also */
@@ -85,7 +88,9 @@
#define T2_DIR (IDENT_ADDR + GAMMA_BIAS + 0x38e0004a0UL)
#define T2_ICE (IDENT_ADDR + GAMMA_BIAS + 0x38e0004c0UL)
+#ifndef T2_ONE_HAE_WINDOW
#define T2_HAE_ADDRESS T2_HAE_1
+#endif
/* T2 CSRs are in the non-cachable primary IO space from 3.8000.0000 to
3.8fff.ffff
@@ -429,13 +434,15 @@ extern inline void t2_outl(u32 b, unsign
*
*/
+#ifdef T2_ONE_HAE_WINDOW
+#define t2_set_hae
+#else
#define t2_set_hae { \
- msb = addr >> 27; \
+ unsigned long msb = addr >> 27; \
addr &= T2_MEM_R1_MASK; \
set_hae(msb); \
}
-
-extern raw_spinlock_t t2_hae_lock;
+#endif
/*
* NOTE: take T2_DENSE_MEM off in each readX/writeX routine, since
@@ -446,28 +453,22 @@ extern raw_spinlock_t t2_hae_lock;
__EXTERN_INLINE u8 t2_readb(const volatile void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr - T2_DENSE_MEM;
- unsigned long result, msb;
- unsigned long flags;
- raw_spin_lock_irqsave(&t2_hae_lock, flags);
+ unsigned long result;
t2_set_hae;
result = *(vip) ((addr << 5) + T2_SPARSE_MEM + 0x00);
- raw_spin_unlock_irqrestore(&t2_hae_lock, flags);
return __kernel_extbl(result, addr & 3);
}
__EXTERN_INLINE u16 t2_readw(const volatile void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr - T2_DENSE_MEM;
- unsigned long result, msb;
- unsigned long flags;
- raw_spin_lock_irqsave(&t2_hae_lock, flags);
+ unsigned long result;
t2_set_hae;
result = *(vuip) ((addr << 5) + T2_SPARSE_MEM + 0x08);
- raw_spin_unlock_irqrestore(&t2_hae_lock, flags);
return __kernel_extwl(result, addr & 3);
}
@@ -478,59 +479,47 @@ __EXTERN_INLINE u16 t2_readw(const volat
__EXTERN_INLINE u32 t2_readl(const volatile void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr - T2_DENSE_MEM;
- unsigned long result, msb;
- unsigned long flags;
- raw_spin_lock_irqsave(&t2_hae_lock, flags);
+ unsigned long result;
t2_set_hae;
result = *(vuip) ((addr << 5) + T2_SPARSE_MEM + 0x18);
- raw_spin_unlock_irqrestore(&t2_hae_lock, flags);
return result & 0xffffffffUL;
}
__EXTERN_INLINE u64 t2_readq(const volatile void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr - T2_DENSE_MEM;
- unsigned long r0, r1, work, msb;
- unsigned long flags;
- raw_spin_lock_irqsave(&t2_hae_lock, flags);
+ unsigned long r0, r1, work;
t2_set_hae;
work = (addr << 5) + T2_SPARSE_MEM + 0x18;
r0 = *(vuip)(work);
r1 = *(vuip)(work + (4 << 5));
- raw_spin_unlock_irqrestore(&t2_hae_lock, flags);
return r1 << 32 | r0;
}
__EXTERN_INLINE void t2_writeb(u8 b, volatile void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr - T2_DENSE_MEM;
- unsigned long msb, w;
- unsigned long flags;
- raw_spin_lock_irqsave(&t2_hae_lock, flags);
+ unsigned long w;
t2_set_hae;
w = __kernel_insbl(b, addr & 3);
*(vuip) ((addr << 5) + T2_SPARSE_MEM + 0x00) = w;
- raw_spin_unlock_irqrestore(&t2_hae_lock, flags);
}
__EXTERN_INLINE void t2_writew(u16 b, volatile void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr - T2_DENSE_MEM;
- unsigned long msb, w;
- unsigned long flags;
- raw_spin_lock_irqsave(&t2_hae_lock, flags);
+ unsigned long w;
t2_set_hae;
w = __kernel_inswl(b, addr & 3);
*(vuip) ((addr << 5) + T2_SPARSE_MEM + 0x08) = w;
- raw_spin_unlock_irqrestore(&t2_hae_lock, flags);
}
/*
@@ -540,29 +529,22 @@ __EXTERN_INLINE void t2_writew(u16 b, vo
__EXTERN_INLINE void t2_writel(u32 b, volatile void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr - T2_DENSE_MEM;
- unsigned long msb;
- unsigned long flags;
- raw_spin_lock_irqsave(&t2_hae_lock, flags);
t2_set_hae;
*(vuip) ((addr << 5) + T2_SPARSE_MEM + 0x18) = b;
- raw_spin_unlock_irqrestore(&t2_hae_lock, flags);
}
__EXTERN_INLINE void t2_writeq(u64 b, volatile void __iomem *xaddr)
{
unsigned long addr = (unsigned long) xaddr - T2_DENSE_MEM;
- unsigned long msb, work;
- unsigned long flags;
- raw_spin_lock_irqsave(&t2_hae_lock, flags);
+ unsigned long work;
t2_set_hae;
work = (addr << 5) + T2_SPARSE_MEM + 0x18;
*(vuip)work = b;
*(vuip)(work + (4 << 5)) = b >> 32;
- raw_spin_unlock_irqrestore(&t2_hae_lock, flags);
}
__EXTERN_INLINE void __iomem *t2_ioportmap(unsigned long addr)
diff -puN arch/alpha/kernel/core_t2.c~alpha-use-single-hae-window-on-t2-core-logic-gamma-sable arch/alpha/kernel/core_t2.c
--- a/arch/alpha/kernel/core_t2.c~alpha-use-single-hae-window-on-t2-core-logic-gamma-sable
+++ a/arch/alpha/kernel/core_t2.c
@@ -74,8 +74,6 @@
# define DBG(args)
#endif
-DEFINE_RAW_SPINLOCK(t2_hae_lock);
-
static volatile unsigned int t2_mcheck_any_expected;
static volatile unsigned int t2_mcheck_last_taken;
@@ -406,6 +404,7 @@ void __init
t2_init_arch(void)
{
struct pci_controller *hose;
+ struct resource *hae_mem;
unsigned long temp;
unsigned int i;
@@ -433,7 +432,13 @@ t2_init_arch(void)
*/
pci_isa_hose = hose = alloc_pci_controller();
hose->io_space = &ioport_resource;
- hose->mem_space = &iomem_resource;
+ hae_mem = alloc_resource();
+ hae_mem->start = 0;
+ hae_mem->end = T2_MEM_R1_MASK;
+ hae_mem->name = pci_hae0_name;
+ if (request_resource(&iomem_resource, hae_mem) < 0)
+ printk(KERN_ERR "Failed to request HAE_MEM\n");
+ hose->mem_space = hae_mem;
hose->index = 0;
hose->sparse_mem_base = T2_SPARSE_MEM - IDENT_ADDR;
diff -puN arch/alpha/kernel/machvec_impl.h~alpha-use-single-hae-window-on-t2-core-logic-gamma-sable arch/alpha/kernel/machvec_impl.h
--- a/arch/alpha/kernel/machvec_impl.h~alpha-use-single-hae-window-on-t2-core-logic-gamma-sable
+++ a/arch/alpha/kernel/machvec_impl.h
@@ -25,6 +25,9 @@
#ifdef MCPCIA_ONE_HAE_WINDOW
#define MCPCIA_HAE_ADDRESS (&alpha_mv.hae_cache)
#endif
+#ifdef T2_ONE_HAE_WINDOW
+#define T2_HAE_ADDRESS (&alpha_mv.hae_cache)
+#endif
/* Only a few systems don't define IACK_SC, handling all interrupts through
the SRM console. But splitting out that one case from IO() below
_
Patches currently in -mm which might be from ink@jurassic.park.msu.ru are
linux-next.patch
arch-alpha-kernel-systblss-remove-debug-check.patch
alpha-enable-arch_dma_addr_t_64bit.patch
alpha-use-single-hae-window-on-t2-core-logic-gamma-sable.patch
add-the-common-dma_addr_t-typedef-to-include-linux-typesh.patch
make-sure-nobodys-leaking-resources.patch
^ permalink raw reply
* [rtc-linux] RE: [PATCH 5/5] rtc: rtc-s3c: Fix debug message format on RTC
From: Kukjin Kim @ 2010-10-07 23:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20100910162354.9b96f1df.akpm@linux-foundation.org>
Andrew Morton wrote:
>
> On Fri, 10 Sep 2010 20:38:39 +0900
> Kukjin Kim <kgene.kim@samsung.com> wrote:
>
> > Wan ZongShun wrote:
> > >
> > > 2010/9/9 Kukjin Kim <kgene.kim@samsung.com>:
> > > > Ben Dooks wrote:
> > > >>
> > > >> On 07/09/10 06:29, Kukjin Kim wrote:
> > > >> > This patch fixes debug message format on rtc-s3c.
> > > >> >
> > > >> > Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
> > > >> > Cc: Ben Dooks <ben-linux@fluff.org>
> > > >> > ---
> > > >> > drivers/rtc/rtc-s3c.c | 18 +++++++++---------
> > > >> > 1 files changed, 9 insertions(+), 9 deletions(-)
> > > >> >
> > > >>
> > > >> how long has this lot been broken for?
> > > >>
> > > > Haha...we don't know :-)
> > > >
> > > >> Acked-by: Ben Dooks <ben-linux@fluff.org>
> > > >
> > > > Thanks for your ack...so...
> > > >
> > > > Hi Alessandro Zummo,
> > > > Is it possible to send this to upstream through your tree?
> > > > Or which tree is better to care this.
> > >
> > >
> > > Please get help from Andrew.
> > >
> > Ok ;-)
> >
> > Hello Andrew,
> >
> > Could you please handle following items which have been got Ben's ack?
> >
> >
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-September/025387.
html
> >
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-September/025388.
html
> >
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-September/025391.
html
> >
> > And it's available in the git repository at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
next-rtc-
> s3c
> >
> > If any problems, please let me know.
> >
>
> I'd prefer to handle the whole series rather than cherrypick a subset
> of it.
>
> Patch 1/5 has a question from Ben which hasn't been responded to yet.
>
> Patch 4/5 is due to be updated.
>
> So please let's fix those things up, resend the entire series and cc me
> on the emails?
Hi Andrew,
Sorry for late response.
Updated patch 1/5 has been tested on S3C24XX and its working fine.
Its remained issue is that Ben was wondering its working on S3C24XX.
And about the patch 4/5, I did address comments from Ben Dooks and Wan
ZongShun.
So could you please handle this series?
If any problems, please kindly let me know.
They are since commit cb655d0f3d57c23db51b981648e452988c0223f9:
Linux 2.6.36-rc7 (2010-10-06 13:39:52 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
next-rtc-s3c
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* Re: [dm-crypt] What happen if hard drive has a read error?
From: Arno Wagner @ 2010-10-07 23:16 UTC (permalink / raw)
To: dm-crypt
In-Reply-To: <4CAE3B9E.3060604@redhat.com>
On Thu, Oct 07, 2010 at 11:29:02PM +0200, Milan Broz wrote:
> On 10/07/2010 10:20 PM, octane indice wrote:
> > It's just a theorical question. I encrypted some data with dm-crypt on an
> > hard drive.
> > But what happens if the hard drive has an error? Not a kind of a big error
> > which cause the hard drive hangs, but just a small error that make the
> > system doesn't read the bytes all right?
> >
> > Obviously, dm-crypt won't decrypt the data. But what happens next?
>
> Basically the same like if you have IO error on plain disk - the
> IO operation returns IO error. Upper layer decides what to do next.
Just to clarify this a bit further: disk error correction
capability is limited, an unrecoverable read error is a real
possibility. The datasheets say once every 10^15 bits read,
which whould translate to an unreadable sector once every
125 TB read. I think this is realistic, but still a bit of a
worst case scenario. Also keep in mind that this is for a
healthy disk only.
The error detection capabilities of the coding uses is far, far
larger. An undetected unrecovrable error (i.e. you get wrong
data but no error even on retry) is something unlikely enough
that you can safely ignore the possibility. There are special
safeguards against this, as error correction by itself can
correct to the wrong value.
Nonetheless, you can find wrong data on disks without any
explanation or detected errors. The reason is typically
corruption in RAM or in busses before the data is written.
For a complex data aquisition system (compression ->
network -> disk-buffer -> tape-library), I have observed
something like one unexplained bit error every 5-10TB
written. This number may vary wildly in practice. Especially
overclocking and cheap non-ECC RAM may drive it up.
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
If it's in the news, don't worry about it. The very definition of
"news" is "something that hardly ever happens." -- Bruce Schneier
^ permalink raw reply
* RE: [rtc-linux] RE: [PATCH 5/5] rtc: rtc-s3c: Fix debug message format on RTC
From: Kukjin Kim @ 2010-10-07 23:16 UTC (permalink / raw)
To: 'Andrew Morton'
Cc: 'Wan ZongShun', rtc-linux, p_gortmaker, linux-samsung-soc,
linux-arm-kernel, 'Ben Dooks', a.zummo
In-Reply-To: <20100910162354.9b96f1df.akpm@linux-foundation.org>
Andrew Morton wrote:
>
> On Fri, 10 Sep 2010 20:38:39 +0900
> Kukjin Kim <kgene.kim@samsung.com> wrote:
>
> > Wan ZongShun wrote:
> > >
> > > 2010/9/9 Kukjin Kim <kgene.kim@samsung.com>:
> > > > Ben Dooks wrote:
> > > >>
> > > >> On 07/09/10 06:29, Kukjin Kim wrote:
> > > >> > This patch fixes debug message format on rtc-s3c.
> > > >> >
> > > >> > Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
> > > >> > Cc: Ben Dooks <ben-linux@fluff.org>
> > > >> > ---
> > > >> > drivers/rtc/rtc-s3c.c | 18 +++++++++---------
> > > >> > 1 files changed, 9 insertions(+), 9 deletions(-)
> > > >> >
> > > >>
> > > >> how long has this lot been broken for?
> > > >>
> > > > Haha...we don't know :-)
> > > >
> > > >> Acked-by: Ben Dooks <ben-linux@fluff.org>
> > > >
> > > > Thanks for your ack...so...
> > > >
> > > > Hi Alessandro Zummo,
> > > > Is it possible to send this to upstream through your tree?
> > > > Or which tree is better to care this.
> > >
> > >
> > > Please get help from Andrew.
> > >
> > Ok ;-)
> >
> > Hello Andrew,
> >
> > Could you please handle following items which have been got Ben's ack?
> >
> >
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-September/025387.
html
> >
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-September/025388.
html
> >
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-September/025391.
html
> >
> > And it's available in the git repository at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
next-rtc-
> s3c
> >
> > If any problems, please let me know.
> >
>
> I'd prefer to handle the whole series rather than cherrypick a subset
> of it.
>
> Patch 1/5 has a question from Ben which hasn't been responded to yet.
>
> Patch 4/5 is due to be updated.
>
> So please let's fix those things up, resend the entire series and cc me
> on the emails?
Hi Andrew,
Sorry for late response.
Updated patch 1/5 has been tested on S3C24XX and its working fine.
Its remained issue is that Ben was wondering its working on S3C24XX.
And about the patch 4/5, I did address comments from Ben Dooks and Wan
ZongShun.
So could you please handle this series?
If any problems, please kindly let me know.
They are since commit cb655d0f3d57c23db51b981648e452988c0223f9:
Linux 2.6.36-rc7 (2010-10-06 13:39:52 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
next-rtc-s3c
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
^ permalink raw reply
* Re: [PATCH,V2 0/6] libtool 2.4 upgrade
From: Graham Gower @ 2010-10-07 23:16 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <AANLkTinM3tq_0J-Jg5VsT3tLYiCd4w=U9-PtDwJCX8kE@mail.gmail.com>
On 8 October 2010 09:26, Graham Gower <graham.gower@gmail.com> wrote:
> I've done a bitbake -k world with this patch set. Below is a list of
> tasks that were found to fail with the patch, but succeeded in my last
> world build without the patch (about a week ago).
To clarify, this was done with:
LIBTOOL_HAS_SYSROOT = "yes"
LIBTOOL_VER = "2.4"
Also, there may be some false negatives here due to recipes having
things missing in their DEPENDS and the build order being semi random.
-Graham
^ permalink raw reply
* + memcg-reduce-lock-hold-time-during-charge-moving.patch added to -mm tree
From: akpm @ 2010-10-07 23:15 UTC (permalink / raw)
To: mm-commits; +Cc: kamezawa.hiroyu, balbir, gthelen, minchan.kim, nishimura
The patch titled
memcg: reduce lock hold time during charge moving
has been added to the -mm tree. Its filename is
memcg-reduce-lock-hold-time-during-charge-moving.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: memcg: reduce lock hold time during charge moving
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Presently during task migration among cgroups, memory cgroup scans page
tables and moves accounting if flags are properly set.
The core code, mem_cgroup_move_charge_pte_range() does
pte_offset_map_lock();
for all ptes in a page table:
1. look into page table, find_and_get a page
2. remove it from LRU.
3. move charge.
4. putback to LRU. put_page()
pte_offset_map_unlock();
for pte entries on a 3rd level? page table.
This pte_offset_map_lock seems a bit long. This patch modifies a rountine as
for 32 pages: pte_offset_map_lock()
find_and_get a page
record it
pte_offset_map_unlock()
for all recorded pages
isolate it from LRU.
move charge
putback to LRU
for all recorded pages
put_page()
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/memcontrol.c | 95 ++++++++++++++++++++++++++++------------------
1 file changed, 59 insertions(+), 36 deletions(-)
diff -puN mm/memcontrol.c~memcg-reduce-lock-hold-time-during-charge-moving mm/memcontrol.c
--- a/mm/memcontrol.c~memcg-reduce-lock-hold-time-during-charge-moving
+++ a/mm/memcontrol.c
@@ -276,6 +276,21 @@ enum move_type {
NR_MOVE_TYPE,
};
+enum mc_target_type {
+ MC_TARGET_NONE, /* used as failure code(0) */
+ MC_TARGET_PAGE,
+ MC_TARGET_SWAP,
+};
+
+struct mc_target {
+ enum mc_target_type type;
+ union {
+ struct page *page;
+ swp_entry_t ent;
+ } val;
+};
+#define MC_MOVE_ONCE (32)
+
/* "mc" and its members are protected by cgroup_mutex */
static struct move_charge_struct {
spinlock_t lock; /* for from, to, moving_task */
@@ -284,6 +299,7 @@ static struct move_charge_struct {
unsigned long precharge;
unsigned long moved_charge;
unsigned long moved_swap;
+ struct mc_target target[MC_MOVE_ONCE];
struct task_struct *moving_task; /* a task moving charges */
wait_queue_head_t waitq; /* a waitq for other context */
} mc = {
@@ -291,6 +307,7 @@ static struct move_charge_struct {
.waitq = __WAIT_QUEUE_HEAD_INITIALIZER(mc.waitq),
};
+
static bool move_anon(void)
{
return test_bit(MOVE_CHARGE_TYPE_ANON,
@@ -4479,16 +4496,7 @@ one_by_one:
*
* Called with pte lock held.
*/
-union mc_target {
- struct page *page;
- swp_entry_t ent;
-};
-enum mc_target_type {
- MC_TARGET_NONE, /* not used */
- MC_TARGET_PAGE,
- MC_TARGET_SWAP,
-};
static struct page *mc_handle_present_pte(struct vm_area_struct *vma,
unsigned long addr, pte_t ptent)
@@ -4565,7 +4573,7 @@ static struct page *mc_handle_file_pte(s
}
static int is_target_pte_for_mc(struct vm_area_struct *vma,
- unsigned long addr, pte_t ptent, union mc_target *target)
+ unsigned long addr, pte_t ptent, struct mc_target *target)
{
struct page *page = NULL;
struct page_cgroup *pc;
@@ -4591,7 +4599,7 @@ static int is_target_pte_for_mc(struct v
if (PageCgroupUsed(pc) && pc->mem_cgroup == mc.from) {
ret = MC_TARGET_PAGE;
if (target)
- target->page = page;
+ target->val.page = page;
}
if (!ret || !target)
put_page(page);
@@ -4601,8 +4609,10 @@ static int is_target_pte_for_mc(struct v
css_id(&mc.from->css) == lookup_swap_cgroup(ent)) {
ret = MC_TARGET_SWAP;
if (target)
- target->ent = ent;
+ target->val.ent = ent;
}
+ if (target)
+ target->type = ret;
return ret;
}
@@ -4763,26 +4773,42 @@ static int mem_cgroup_move_charge_pte_ra
struct vm_area_struct *vma = walk->private;
pte_t *pte;
spinlock_t *ptl;
+ int index, num;
retry:
pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl);
- for (; addr != end; addr += PAGE_SIZE) {
+ for (num = 0; num < MC_MOVE_ONCE && addr != end; addr += PAGE_SIZE) {
pte_t ptent = *(pte++);
- union mc_target target;
- int type;
+ ret = is_target_pte_for_mc(vma, addr, ptent, &mc.target[num]);
+ if (!ret)
+ continue;
+ mc.target[num++].type = ret;
+ }
+ pte_unmap_unlock(pte - 1, ptl);
+ cond_resched();
+
+ ret = 0;
+ index = 0;
+ do {
+ struct mc_target *mt;
struct page *page;
struct page_cgroup *pc;
swp_entry_t ent;
- if (!mc.precharge)
- break;
+ if (!mc.precharge) {
+ ret = mem_cgroup_do_precharge(1);
+ if (ret)
+ goto out;
+ continue;
+ }
+
+ mt = &mc.target[index++];
- type = is_target_pte_for_mc(vma, addr, ptent, &target);
- switch (type) {
+ switch (mt->type) {
case MC_TARGET_PAGE:
- page = target.page;
+ page = mt->val.page;
if (isolate_lru_page(page))
- goto put;
+ break;
pc = lookup_page_cgroup(page);
if (!mem_cgroup_move_account(pc,
mc.from, mc.to, false)) {
@@ -4791,11 +4817,9 @@ retry:
mc.moved_charge++;
}
putback_lru_page(page);
-put: /* is_target_pte_for_mc() gets the page */
- put_page(page);
break;
case MC_TARGET_SWAP:
- ent = target.ent;
+ ent = mt->val.ent;
if (!mem_cgroup_move_swap_account(ent,
mc.from, mc.to, false)) {
mc.precharge--;
@@ -4806,21 +4830,20 @@ put: /* is_target_pte_for_mc() gets th
default:
break;
}
+ } while (index < num);
+out:
+ for (index = 0; index < num; index++) {
+ if (mc.target[index].type == MC_TARGET_PAGE)
+ put_page(mc.target[index].val.page);
+ mc.target[index].type = MC_TARGET_NONE;
}
- pte_unmap_unlock(pte - 1, ptl);
+
+ if (ret)
+ return ret;
cond_resched();
- if (addr != end) {
- /*
- * We have consumed all precharges we got in can_attach().
- * We try charge one by one, but don't do any additional
- * charges to mc.to if we have failed in charge once in attach()
- * phase.
- */
- ret = mem_cgroup_do_precharge(1);
- if (!ret)
- goto retry;
- }
+ if (addr != end)
+ goto retry;
return ret;
}
_
Patches currently in -mm which might be from kamezawa.hiroyu@jp.fujitsu.com are
memcg-fix-thresholds-with-use_hierarchy-==-1.patch
linux-next.patch
vfs-introduce-fmode_neg_offset-for-allowing-negative-f_pos.patch
oom-add-per-mm-oom-disable-count.patch
oom-add-per-mm-oom-disable-count-protect-oom_disable_count-with-task_lock-in-fork.patch
oom-add-per-mm-oom-disable-count-use-old_mm-for-oom_disable_count-in-exec.patch
oom-avoid-killing-a-task-if-a-thread-sharing-its-mm-cannot-be-killed.patch
oom-kill-all-threads-sharing-oom-killed-tasks-mm.patch
oom-kill-all-threads-sharing-oom-killed-tasks-mm-fix.patch
oom-kill-all-threads-sharing-oom-killed-tasks-mm-fix-fix.patch
oom-rewrite-error-handling-for-oom_adj-and-oom_score_adj-tunables.patch
oom-fix-locking-for-oom_adj-and-oom_score_adj.patch
memory-hotplug-fix-notifiers-return-value-check.patch
memory-hotplug-unify-is_removable-and-offline-detection-code.patch
memory-hotplug-unify-is_removable-and-offline-detection-code-checkpatch-fixes.patch
tracing-vmscan-add-trace-events-for-lru-list-shrinking.patch
writeback-account-for-time-spent-congestion_waited.patch
vmscan-synchronous-lumpy-reclaim-should-not-call-congestion_wait.patch
vmscan-narrow-the-scenarios-lumpy-reclaim-uses-synchrounous-reclaim.patch
vmscan-remove-dead-code-in-shrink_inactive_list.patch
vmscan-isolated_lru_pages-stop-neighbour-search-if-neighbour-cannot-be-isolated.patch
writeback-do-not-sleep-on-the-congestion-queue-if-there-are-no-congested-bdis.patch
writeback-do-not-sleep-on-the-congestion-queue-if-there-are-no-congested-bdis-or-if-significant-congestion-is-not-being-encountered-in-the-current-zone.patch
writeback-do-not-sleep-on-the-congestion-queue-if-there-are-no-congested-bdis-or-if-significant-congestion-is-not-being-encounted-in-the-current-zone-fix.patch
memcg-fix-race-in-file_mapped-accouting-flag-management.patch
memcg-avoid-lock-in-updating-file_mapped-was-fix-race-in-file_mapped-accouting-flag-management.patch
memcg-use-for_each_mem_cgroup.patch
memcg-cpu-hotplug-aware-percpu-count-updates.patch
memcg-cpu-hotplug-aware-percpu-count-updates-fix.patch
memcg-cpu-hotplug-aware-quick-acount_move-detection.patch
memcg-cpu-hotplug-aware-quick-acount_move-detection-checkpatch-fixes.patch
memcg-generic-filestat-update-interface.patch
memcg-reduce-lock-hold-time-during-charge-moving.patch
^ permalink raw reply
* Re: [PATCH v2] memcg: reduce lock time at move charge (Was Re: [PATCH 04/10] memcg: disable local interrupts in lock_page_cgroup()
From: Andrew Morton @ 2010-10-07 23:14 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Daisuke Nishimura, Minchan Kim, Greg Thelen, linux-kernel,
linux-mm, containers, Andrea Righi, Balbir Singh
In-Reply-To: <20101007170405.27ed964c.kamezawa.hiroyu@jp.fujitsu.com>
On Thu, 7 Oct 2010 17:04:05 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> Now, at task migration among cgroup, memory cgroup scans page table and moving
> account if flags are properly set.
>
> The core code, mem_cgroup_move_charge_pte_range() does
>
> pte_offset_map_lock();
> for all ptes in a page table:
> 1. look into page table, find_and_get a page
> 2. remove it from LRU.
> 3. move charge.
> 4. putback to LRU. put_page()
> pte_offset_map_unlock();
>
> for pte entries on a 3rd level? page table.
>
> This pte_offset_map_lock seems a bit long. This patch modifies a rountine as
>
> for 32 pages: pte_offset_map_lock()
> find_and_get a page
> record it
> pte_offset_map_unlock()
> for all recorded pages
> isolate it from LRU.
> move charge
> putback to LRU
> for all recorded pages
> put_page()
The patch makes the code larger, more complex and slower!
I do think we're owed a more complete description of its benefits than
"seems a bit long". Have problems been observed? Any measurements
taken?
^ permalink raw reply
* Re: [PATCH] PM: add synchronous runtime interface for interrupt handlers
From: Kevin Hilman @ 2010-10-07 23:15 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Alan Stern, Linux-pm mailing list, Partha Basak, linux-omap
In-Reply-To: <201010072311.31071.rjw@sisk.pl>
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> On Thursday, October 07, 2010, Alan Stern wrote:
>> On Thu, 7 Oct 2010, Kevin Hilman wrote:
>>
>> > My confusion is not about the use of spinlocks, it's a question of what
>> > is being busy-waited for, and the thread that is being waited for is
>> > going to complete when interrupts are disabled.
>> >
>> > Sorry to be dense, but can you (re)summarize what you're proposing as I
>> > think I'm getting mixed up with all the various options we've been
>> > tossing around.
>> >
>> > If it can work, I'm certainly in favor of a busy-wait approach as it
>> > really ensures that sync requests are handled quickly.
>>
>> Okay, here's the story in a nutshell. Allowing a subsystem's or
>> driver's runtime-PM callbacks to run with interrupts disabled faces two
>> obstacles:
>>
>> (1): We don't want two different CPUs to run callbacks for the
>> same device at the same time. So if a callback is already
>> running on one CPU (i.e., if the device's runtime status is
>> either SUSPENDING or RESUMING) then another CPU can't be
>> allowed to invoke a callback.
>>
>> Thus, you can't do a synchronous pm_runtime_resume_irq()
>> if the device is in the middle of a suspend or resume
>> operation. We're left with two choices: Fail the synchronous
>> call and force the driver to defer matters to a workqueue
>> (possibly masking an IRQ line in the meantime), or busy-wait
>> until the concurrent operation finishes.
>>
>> If the PM core simply avoids releasing dev->power.lock before
>> invoking the runtime_suspend or runtime_resume callback, the
>> end result is almost the same as with busy-waiting.
>
> This is slightly more complicated, because suspend is a bit different from
> resume. I think it's generally acceptable to refuse to do a "fast path" suspend
> if the device state is not RPM_ACTIVE at the moment, but refusing to do
> a "fast path" resume may be more problematic (more on that later).
>
>> (2): In general we can't resume a device if its parent is suspended.
>> If the parent's runtime_resume routine needs to run with
>> interrupts enabled then there's no way to resume the device
>> while keeping interrupts disabled.
>>
>> Possible solutions involve, again, deferring matters to a
>> workqueue, or else simply not allowing the situation to arise
>> in the first place (forbid a device to have interrupt-disabled
>> callbacks unless its parent does too or the parent doesn't use
>> runtime PM at all).
>>
>> In general I'm against the solutions that require a workqueue.
>
> OK
>
>> Raphael appears to favor workqueues for (1) and be against them for (2).
>
> The particular case we need to handle (I think) is that some devices need to be
> resumed "atomically" as a part of bringing a CPU package out of a C-like-state
> (Kevin, is that correct?).
Correct, but there is more than one problematic case.
Another problem is in devices that are not atomic with C-states, but
receive wakeup IRQs while they're suspended and thus need to
pm_runtime_get() from their ISRs, without having an essentially
unbounded interrupt latency before the ISR can be handled.
Consider the following sequence for a given device
- device: ->runtime_suspend() /* registers not accessible */
- pm_idle
- IRQs disabled
- idle
- wakeup event
- idle loop finishes
- IRQs enabled
- device: ->runtime_resume()
Now, consider the 'wakeup event' is an IRQ for that device. That means
as soon as IRQs are (re)enabled (and before some other activity has
triggered a ->runtime_resume), the device's ISR is called. Since it is
RPM_SUSPENDED, it's registers are not accessible so it needs to do a
pm_runtime_get().
The case that raised this initially was a GPIO IRQ demux, where the
initial ISR is just a chained handler whichfigures out which GPIO
fired and then call genirq for that IRQ.
All that being said, while I've currently described these as two
different problems, the second one could be solved by converting it to
the first one. IOW, make GPIO be one of those devices that are
suspended/resumed atomically with the CPU so that it is guaranteed to be
awake when IRQs are re-enabled.
While that would work, I've been trying to move in the opposite
direction by trying to dis-connect them from CPU idle.
> In that case not only we can't defer the resume (by
> using a workqueue), but also we have to finish the resume within strict time
> constraints (the time to leave the given C-like-state is one of the parameters
> used by cpuidle governors to decide which state to choose).
>
> On the other hand, busy waiting (by looping) in the case the state is
> RPM_RESUMING is as though the callbacks were executed under a spinlock and we
> happened to wait on it. I'd prefer to avoid that. Moreover, if the state is
> RPM_SUSPENDING at the time a "fast path" resume is started, we are almost
> guaranteed to violate the time constraints (by busy waiting for the suspend to
> complete and carrying out the resume).
>
> So, here's an idea:
>
> First, let's introduce two flags in struct dev_pm_info, irq_safe and
> fast_resume. The former has to be set so that the things above work.
>
> Second, let's add a new flag to pass to __pm_runtime_{suspend|resume}(),
> RPM_FAST_RESUME such that if it is passed to __pm_runtime_suspend(), it
> causes fast_resume to be set for the given device (if the status is already
> RPM_SUSPENDED, it just sets the flag, otherwise it suspends the device
> normally and then sets the flag). Now, if fast_resume is set,
> __pm_runtime_resume() has to be passed RPM_FAST_RESUME, or it will
> fail (it also will fail if passed RPM_FAST_RESUME and fast_resume isn't
> set). In that case the status has to be RPM_SUSPENDED or RPM_RESUMING
> (otherwise fast_resume won't be set) and if it is RPM_RESUMING, this means
> that the other resume has been called with RPM_FAST_RESUME too (it would
> fail otherwise), so it's fine to busy loop until the status is RPM_SUSPENDED
> (it's the caller's problem to avoid that). RPM_FAST_RESUME causes
> __pm_runtime_resume() to avod turning interrupts on.
>
> If necessary, there may be a flag for __pm_runtime_suspend() that will
> carry out "atomic" suspend, but I'm not sure if that's necessary. Kevin?
I think we'll need both "atomic" suspend & resume.
One of the devices I'm currently managing in this atomic fashion (inside
pm_idle) is the UARTs (of course, I'm not currently using runtime PM for
this, I'm calling platform-specific hooks directly since IRQs are
disabled.) For the UARTs I'm using both atomic suspend and resume,
primarily for debug so I am sure UARTs are awake to see any panics
during the last parts of the suspend/idle process and the early parts of
the resume path. This UART case is a bit of a hack until the driver is
converted to runtime PM, but illustrates some debug related reasons we
might also need atomic suspend and resume.
We also have some workarounds for hardware errata that require
putting certain devices in a specific state just before (and after)
idle. The drivers for these devices will need both suspend and resume.
Kevin
^ permalink raw reply
* Re: [PATCH] PM: add synchronous runtime interface for interrupt handlers
From: Kevin Hilman @ 2010-10-07 23:15 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Partha Basak, Linux-pm mailing list, linux-omap
In-Reply-To: <201010072311.31071.rjw@sisk.pl>
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> On Thursday, October 07, 2010, Alan Stern wrote:
>> On Thu, 7 Oct 2010, Kevin Hilman wrote:
>>
>> > My confusion is not about the use of spinlocks, it's a question of what
>> > is being busy-waited for, and the thread that is being waited for is
>> > going to complete when interrupts are disabled.
>> >
>> > Sorry to be dense, but can you (re)summarize what you're proposing as I
>> > think I'm getting mixed up with all the various options we've been
>> > tossing around.
>> >
>> > If it can work, I'm certainly in favor of a busy-wait approach as it
>> > really ensures that sync requests are handled quickly.
>>
>> Okay, here's the story in a nutshell. Allowing a subsystem's or
>> driver's runtime-PM callbacks to run with interrupts disabled faces two
>> obstacles:
>>
>> (1): We don't want two different CPUs to run callbacks for the
>> same device at the same time. So if a callback is already
>> running on one CPU (i.e., if the device's runtime status is
>> either SUSPENDING or RESUMING) then another CPU can't be
>> allowed to invoke a callback.
>>
>> Thus, you can't do a synchronous pm_runtime_resume_irq()
>> if the device is in the middle of a suspend or resume
>> operation. We're left with two choices: Fail the synchronous
>> call and force the driver to defer matters to a workqueue
>> (possibly masking an IRQ line in the meantime), or busy-wait
>> until the concurrent operation finishes.
>>
>> If the PM core simply avoids releasing dev->power.lock before
>> invoking the runtime_suspend or runtime_resume callback, the
>> end result is almost the same as with busy-waiting.
>
> This is slightly more complicated, because suspend is a bit different from
> resume. I think it's generally acceptable to refuse to do a "fast path" suspend
> if the device state is not RPM_ACTIVE at the moment, but refusing to do
> a "fast path" resume may be more problematic (more on that later).
>
>> (2): In general we can't resume a device if its parent is suspended.
>> If the parent's runtime_resume routine needs to run with
>> interrupts enabled then there's no way to resume the device
>> while keeping interrupts disabled.
>>
>> Possible solutions involve, again, deferring matters to a
>> workqueue, or else simply not allowing the situation to arise
>> in the first place (forbid a device to have interrupt-disabled
>> callbacks unless its parent does too or the parent doesn't use
>> runtime PM at all).
>>
>> In general I'm against the solutions that require a workqueue.
>
> OK
>
>> Raphael appears to favor workqueues for (1) and be against them for (2).
>
> The particular case we need to handle (I think) is that some devices need to be
> resumed "atomically" as a part of bringing a CPU package out of a C-like-state
> (Kevin, is that correct?).
Correct, but there is more than one problematic case.
Another problem is in devices that are not atomic with C-states, but
receive wakeup IRQs while they're suspended and thus need to
pm_runtime_get() from their ISRs, without having an essentially
unbounded interrupt latency before the ISR can be handled.
Consider the following sequence for a given device
- device: ->runtime_suspend() /* registers not accessible */
- pm_idle
- IRQs disabled
- idle
- wakeup event
- idle loop finishes
- IRQs enabled
- device: ->runtime_resume()
Now, consider the 'wakeup event' is an IRQ for that device. That means
as soon as IRQs are (re)enabled (and before some other activity has
triggered a ->runtime_resume), the device's ISR is called. Since it is
RPM_SUSPENDED, it's registers are not accessible so it needs to do a
pm_runtime_get().
The case that raised this initially was a GPIO IRQ demux, where the
initial ISR is just a chained handler whichfigures out which GPIO
fired and then call genirq for that IRQ.
All that being said, while I've currently described these as two
different problems, the second one could be solved by converting it to
the first one. IOW, make GPIO be one of those devices that are
suspended/resumed atomically with the CPU so that it is guaranteed to be
awake when IRQs are re-enabled.
While that would work, I've been trying to move in the opposite
direction by trying to dis-connect them from CPU idle.
> In that case not only we can't defer the resume (by
> using a workqueue), but also we have to finish the resume within strict time
> constraints (the time to leave the given C-like-state is one of the parameters
> used by cpuidle governors to decide which state to choose).
>
> On the other hand, busy waiting (by looping) in the case the state is
> RPM_RESUMING is as though the callbacks were executed under a spinlock and we
> happened to wait on it. I'd prefer to avoid that. Moreover, if the state is
> RPM_SUSPENDING at the time a "fast path" resume is started, we are almost
> guaranteed to violate the time constraints (by busy waiting for the suspend to
> complete and carrying out the resume).
>
> So, here's an idea:
>
> First, let's introduce two flags in struct dev_pm_info, irq_safe and
> fast_resume. The former has to be set so that the things above work.
>
> Second, let's add a new flag to pass to __pm_runtime_{suspend|resume}(),
> RPM_FAST_RESUME such that if it is passed to __pm_runtime_suspend(), it
> causes fast_resume to be set for the given device (if the status is already
> RPM_SUSPENDED, it just sets the flag, otherwise it suspends the device
> normally and then sets the flag). Now, if fast_resume is set,
> __pm_runtime_resume() has to be passed RPM_FAST_RESUME, or it will
> fail (it also will fail if passed RPM_FAST_RESUME and fast_resume isn't
> set). In that case the status has to be RPM_SUSPENDED or RPM_RESUMING
> (otherwise fast_resume won't be set) and if it is RPM_RESUMING, this means
> that the other resume has been called with RPM_FAST_RESUME too (it would
> fail otherwise), so it's fine to busy loop until the status is RPM_SUSPENDED
> (it's the caller's problem to avoid that). RPM_FAST_RESUME causes
> __pm_runtime_resume() to avod turning interrupts on.
>
> If necessary, there may be a flag for __pm_runtime_suspend() that will
> carry out "atomic" suspend, but I'm not sure if that's necessary. Kevin?
I think we'll need both "atomic" suspend & resume.
One of the devices I'm currently managing in this atomic fashion (inside
pm_idle) is the UARTs (of course, I'm not currently using runtime PM for
this, I'm calling platform-specific hooks directly since IRQs are
disabled.) For the UARTs I'm using both atomic suspend and resume,
primarily for debug so I am sure UARTs are awake to see any panics
during the last parts of the suspend/idle process and the early parts of
the resume path. This UART case is a bit of a hack until the driver is
converted to runtime PM, but illustrates some debug related reasons we
might also need atomic suspend and resume.
We also have some workarounds for hardware errata that require
putting certain devices in a specific state just before (and after)
idle. The drivers for these devices will need both suspend and resume.
Kevin
^ permalink raw reply
* Re: [Qemu-devel] fix unsigned comparison warning in TCG
From: Venkateswararao Jujjuri (JV) @ 2010-10-07 23:15 UTC (permalink / raw)
To: Blue Swirl; +Cc: qemu-devel, Hollis Blanchard
In-Reply-To: <AANLkTi=AFOyVNAtvQ_1s6LW=S9WiW4Z6vkGOZWExctE6@mail.gmail.com>
On 9/26/2010 11:33 AM, Blue Swirl wrote:
> On Sun, Sep 26, 2010 at 5:40 PM, Hollis Blanchard <hollis@penguinppc.org> wrote:
>> TCGOpcode is an enum, which apparently can be unsigned.
>>
>> Signed-off-by: Hollis Blanchard <hollis@penguinppc.org>
>> ---
>>
>> % ./configure --target-list=ppcemb-softmmu --enable-debug
>> % make
>> ...
>> CC ppcemb-softmmu/tcg/tcg.o
>> cc1: warnings being treated as errors
>> /home/hollisb/source/qemu.git/tcg/tcg.c: In function
>> ‘tcg_add_target_add_op_defs’:
>> /home/hollisb/source/qemu.git/tcg/tcg.c:1030: error: comparison of
>> unsigned expression >= 0 is always true
>> % gcc -v
>> gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC)
>>
>> diff --git a/tcg/tcg.c b/tcg/tcg.c
>> index e0a9030..7e96859 100644
>> --- a/tcg/tcg.c
>> +++ b/tcg/tcg.c
>> @@ -1027,7 +1027,7 @@ void tcg_add_target_add_op_defs(const TCGTargetOpDef *tdef
>> if (tdefs->op == (TCGOpcode)-1)
>> break;
>> op = tdefs->op;
>> - assert(op >= 0 && op < NB_OPS);
>> + assert(op < NB_OPS);
>
> Please add int cast, like 95ee3914bfd551aeec49932a400530141865acad.
>
What is the latest on this? Waiting for this fix as I use --enable-debug a lot. :)
- JV
^ permalink raw reply
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.