On Fri 2007-09-21 10:06:15, Thomas Gleixner wrote:
> On Fri, 2007-09-21 at 14:51 +1000, Paul Mackerras wrote:
> > Linus Torvalds writes:
> >
> > > It would indeed be nice if we could just take CPU's down early (while
> > > everything is working), and run the whole suspend code with just one CPU,
Thomas Gleixner wrote:
> On Fri, 2007-09-28 at 16:07 +0530, Kamalesh Babulal wrote:
>
>> The kgdb is also broken with 2.6.23-rc8-mm2 on the powerpc .
>> The below patch disables the kgdb from getting compiled over
>> powerpc platform.
>>
>> Signed-off-by : Kamalesh Babulal <[EMAIL PROTECTED]>
>>
On Fri, 2007-09-28 at 16:07 +0530, Kamalesh Babulal wrote:
> The kgdb is also broken with 2.6.23-rc8-mm2 on the powerpc .
> The below patch disables the kgdb from getting compiled over
> powerpc platform.
>
> Signed-off-by : Kamalesh Babulal <[EMAIL PROTECTED]>
> ---
>
> --- linux-2.6.23-rc8/lib/
Christoph Hellwig wrote:
> On Thu, Sep 20, 2007 at 03:23:19PM +1000, Paul Mackerras wrote:
>
>> I could remove all the kgdb support from arch/powerpc as a first step,
>> if that would make it easier to pull in the new stuff...
>>
>
> Given that the existing powerpc kgdb bits didn't seem to
On Tue, Sep 25, 2007 at 01:47:05PM +0200, Jarek Poplawski wrote:
> On Mon, Sep 24, 2007 at 11:50:23AM +0200, Nadia Derbey wrote:
> > Jarek Poplawski wrote:
> ...
> > >2. I'm not sure this refcounting with ipc_rcu_getref/putref is SMP
> > >safe (memory barriers): it's not atomic, so locking is neede
Satyam Sharma wrote:
Hi,
On Thu, 20 Sep 2007, Alan Cox wrote:
On Thu, 20 Sep 2007 14:13:15 +0100
[EMAIL PROTECTED] (Mel Gorman) wrote:
PPC64 building allmodconfig fails to compile drivers/ata/pata_scc.c . It
doesn't show up on other arches because this driver is specific to the
architecture.
On Wed, Sep 19, 2007 at 07:44:03PM +0200, Sam Ravnborg wrote:
> On Wed, Sep 19, 2007 at 10:28:48AM +0100, Andy Whitcroft wrote:
> > I am seeing this strange link error from a PowerMac G5 (powerpc):
> >
> > [...]
> > KSYM.tmp_kallsyms2.S
> > AS .tmp_kallsyms2.o
> > LD vm
On Mon, Sep 24, 2007 at 11:50:23AM +0200, Nadia Derbey wrote:
> Jarek Poplawski wrote:
...
> >2. I'm not sure this refcounting with ipc_rcu_getref/putref is SMP
> >safe (memory barriers): it's not atomic, so locking is needed, but
> >e.g. in do_msgsnd() kern_ipc_perm lock is used for this, while
>
On Sat, Sep 22, 2007 at 02:51:54PM +0530, Satyam Sharma wrote:
> Hi Greg,
>
>
> On Tue, 18 Sep 2007, Greg KH wrote:
> >
> > On Tue, Sep 18, 2007 at 03:04:48PM +0530, Satyam Sharma wrote:
> > >
> > > But wait ... isn't that a statically-allocated kobject, which were
> > > supposed to be "naughty
On (22/09/07 12:24), Satyam Sharma didst pronounce:
>
>
> On Thu, 20 Sep 2007, Satyam Sharma wrote:
> >
> > BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> > IIRC I got build failures in:
>
> > drivers/net/spider_net.c
>
>
> [PATCH -mm] spider_net: Misc build fixes after rec
On (22/09/07 14:11), Satyam Sharma didst pronounce:
>
> > -static volatile int kgdb_hwbreak_sstep[NR_CPUS];
> > +volatile int kgdb_hwbreak_sstep[NR_CPUS];
>
> That looks fishy to me. Why is it volatile-qualified?
It turned out that it was unnecessary. A follow-up patch removed the volatile
and k
On (22/09/07 08:20), Satyam Sharma didst pronounce:
> Hi,
>
>
> On Thu, 20 Sep 2007, Alan Cox wrote:
> >
> > On Thu, 20 Sep 2007 14:13:15 +0100
> > [EMAIL PROTECTED] (Mel Gorman) wrote:
> >
> > > PPC64 building allmodconfig fails to compile drivers/ata/pata_scc.c . It
> > > doesn't show up on o
Jarek Poplawski wrote:
On Thu, Sep 20, 2007 at 03:08:42PM +0200, Nadia Derbey wrote:
Nadia Derbey wrote:
Jarek Poplawski wrote:
On Thu, Sep 20, 2007 at 08:24:58AM +0200, Nadia Derbey wrote:
...
Actually, ipc_lock() is called most of the time without the
ipc_ids.mutex held and without r
Jarek Poplawski wrote:
On Fri, Sep 21, 2007 at 01:03:47PM +0200, Jarek Poplawski wrote:
...
I hope not! But, then it would be probably another logical trick:
ipc_rcu_getref/putref() seems to prevent kfreeing of a structure, so
if it's used in do_msgsnd() there should be a risk something can do
On Mon, Sep 24, 2007 at 09:35:23AM +0200, Peter Zijlstra wrote:
> On Mon, 24 Sep 2007 11:01:10 +0800 Fengguang Wu <[EMAIL PROTECTED]>
> wrote:
>
> > > That is an interesting idea how about this:
> >
> > It looks like a workaround, but it does solve the most important problem.
> > And it is a good
On Mon, Sep 24, 2007 at 08:54:07AM +0200, Jarek Poplawski wrote:
> After rethinking, this scenario seems to be wrong or very unprobable
> (I'm not sure of all ways "if (--container...)" could be compiled),
> so there should be no such risk - double kfree/vfree is more probable,
> so no danger. More
On Mon, 24 Sep 2007 11:01:10 +0800 Fengguang Wu <[EMAIL PROTECTED]>
wrote:
> > That is an interesting idea how about this:
>
> It looks like a workaround, but it does solve the most important problem.
> And it is a good logic by itself. So I'd vote for it.
>
> The fundamental problem is that th
On Fri, Sep 21, 2007 at 01:03:47PM +0200, Jarek Poplawski wrote:
...
> I hope not! But, then it would be probably another logical trick:
> ipc_rcu_getref/putref() seems to prevent kfreeing of a structure, so
> if it's used in do_msgsnd() there should be a risk something can do
> this kfree at this
Quoting Cedric Le Goater ([EMAIL PROTECTED]):
> Cedric Le Goater wrote:
> > Pavel Emelyanov wrote:
> >> Looks sane :)
> >>
> >> [snip]
> >>
> >>> Index: 2.6.23-rc6-mm1/kernel/exit.c
> >>> ===
> >>> --- 2.6.23-rc6-mm1.orig/kernel/exit.c
On Sun, Sep 23, 2007 at 03:02:35PM +0200, Peter Zijlstra wrote:
> On Sun, 23 Sep 2007 09:20:49 +0800 Fengguang Wu <[EMAIL PROTECTED]>
> wrote:
>
> > On Sat, Sep 22, 2007 at 03:16:22PM +0200, Peter Zijlstra wrote:
> > > On Sat, 22 Sep 2007 09:55:09 +0800 Fengguang Wu <[EMAIL PROTECTED]>
> > > wrote
Hi
I've tried to compile 2.6.23-rc6-mm1, but it fails on ipg.c with the error :
Setup is 10964 bytes (padded to 11264 bytes).
System is 1640 kB
Kernel: arch/i386/boot/bzImage is ready (#1)
Building modules, stage 2.
MODPOST 2030 modules
WARNING: Can't handle masks in drivers/mtd/nand/cafe_nan
On Sun, 23 Sep 2007 09:20:49 +0800 Fengguang Wu <[EMAIL PROTECTED]>
wrote:
> On Sat, Sep 22, 2007 at 03:16:22PM +0200, Peter Zijlstra wrote:
> > On Sat, 22 Sep 2007 09:55:09 +0800 Fengguang Wu <[EMAIL PROTECTED]>
> > wrote:
> >
> > > --- linux-2.6.22.orig/mm/page-writeback.c
> > > +++ linux-2.6.2
On Sat, Sep 22, 2007 at 03:16:22PM +0200, Peter Zijlstra wrote:
> On Sat, 22 Sep 2007 09:55:09 +0800 Fengguang Wu <[EMAIL PROTECTED]>
> wrote:
>
> > --- linux-2.6.22.orig/mm/page-writeback.c
> > +++ linux-2.6.22/mm/page-writeback.c
> > @@ -426,6 +426,14 @@ static void balance_dirty_pages(struct a
On Sat, 22 Sep 2007 09:55:09 +0800 Fengguang Wu <[EMAIL PROTECTED]>
wrote:
> --- linux-2.6.22.orig/mm/page-writeback.c
> +++ linux-2.6.22/mm/page-writeback.c
> @@ -426,6 +426,14 @@ static void balance_dirty_pages(struct a
> bdi_nr_writeback = bdi_stat(bdi, BDI_WRITEBACK);
>
Hi Greg,
On Tue, 18 Sep 2007, Greg KH wrote:
>
> On Tue, Sep 18, 2007 at 03:04:48PM +0530, Satyam Sharma wrote:
> >
> > But wait ... isn't that a statically-allocated kobject, which were
> > supposed to be "naughty" in the first place?
>
> Yes it is, if you want to dynamically create it, pleas
> -static volatile int kgdb_hwbreak_sstep[NR_CPUS];
> +volatile int kgdb_hwbreak_sstep[NR_CPUS];
That looks fishy to me. Why is it volatile-qualified? And does that
actually want to be a per-cpu var?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messag
On Thu, 20 Sep 2007, Satyam Sharma wrote:
>
> BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> IIRC I got build failures in:
> drivers/net/spider_net.c
Fixing the above showed up another problem in another file of the
same driver (drivers/net/spider_net_ethtool.c)
[PATCH -mm
On Thu, 20 Sep 2007, Satyam Sharma wrote:
>
> BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> IIRC I got build failures in:
> drivers/net/spider_net.c
[PATCH -mm] spider_net: Misc build fixes after recent netdev stats changes
Unbreak the following:
drivers/net/spider_net.c
On Thu, 20 Sep 2007, Satyam Sharma wrote:
>
> BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> IIRC I got build failures in:
> drivers/md/raid6int8.c
This turned out to be a gcc bug -- I was using an old cross-compiler.
-
To unsubscribe from this list: send the line "unsubscri
On Thu, 20 Sep 2007, Satyam Sharma wrote:
>
> BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ...
> IIRC I got build failures in:
> drivers/ata/pata_scc.c
http://lkml.org/lkml/2007/9/21/557
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
Hi,
On Thu, 20 Sep 2007, Alan Cox wrote:
>
> On Thu, 20 Sep 2007 14:13:15 +0100
> [EMAIL PROTECTED] (Mel Gorman) wrote:
>
> > PPC64 building allmodconfig fails to compile drivers/ata/pata_scc.c . It
> > doesn't show up on other arches because this driver is specific to the
> > architecture.
> >
On Thu, Sep 20, 2007 at 12:31:39PM +0100, Hugh Dickins wrote:
> On Wed, 19 Sep 2007, Peter Zijlstra wrote:
> > On Wed, 19 Sep 2007 21:03:19 +0100 (BST) Hugh Dickins
> > <[EMAIL PROTECTED]> wrote:
> >
> > > On Wed, 19 Sep 2007, Andy Whitcroft wrote:
> > > > Seems I have a case of a largish i386 NUM
Thomas,
On Friday, 21 September 2007 21:16, Thomas Gleixner wrote:
> Rafael,
>
> On Fri, 2007-09-21 at 21:20 +0200, Rafael J. Wysocki wrote:
> > On Friday, 21 September 2007 18:27, Thomas Gleixner wrote:
> > > I simply rmmod'ed the processor module before suspend and the problem is
> > > solved a
Rafael,
On Fri, 2007-09-21 at 21:20 +0200, Rafael J. Wysocki wrote:
> On Friday, 21 September 2007 18:27, Thomas Gleixner wrote:
> > I simply rmmod'ed the processor module before suspend and the problem is
> > solved as well. The cpuidle patches make this problem more prominent due
> > to the poss
On Friday, 21 September 2007 18:27, Thomas Gleixner wrote:
> Rafael,
>
> On Fri, 2007-09-21 at 16:20 +0200, Rafael J. Wysocki wrote:
> > > > If you need any help from me with that, please let me know.
> > >
> > > I'm zooming in. It seems, that the ACPI idle code plays tricks with us.
> > > After
Rafael,
On Fri, 2007-09-21 at 16:20 +0200, Rafael J. Wysocki wrote:
> > > If you need any help from me with that, please let me know.
> >
> > I'm zooming in. It seems, that the ACPI idle code plays tricks with us.
> > After debugging the swsusp_suspend() code path I figured out, that we
> > end u
Thomas,
On Friday, 21 September 2007 14:59, Thomas Gleixner wrote:
> Rafael,
>
> On Fri, 2007-09-21 at 00:30 +0200, Rafael J. Wysocki wrote:
> > > -ETOOTIRED led me too a wrong conclusion, but still it is a valuable
> > > hint that this change is making things work again.
> >
> > Yes, it is.
> >
* Guennadi Liakhovetski ([EMAIL PROTECTED]) wrote:
> Provide {enable,disable}_irq_wakeup dummies for undefined
> CONFIG_GENERIC_HARDIRQS case. Completely untested, as I don't even have
> cross-compilers for platforms without CONFIG_GENERIC_HARDIRQS.
>
> Signed-off-by: Guennadi Liakhovetski <[EMA
Rafael,
On Fri, 2007-09-21 at 00:30 +0200, Rafael J. Wysocki wrote:
> > -ETOOTIRED led me too a wrong conclusion, but still it is a valuable
> > hint that this change is making things work again.
>
> Yes, it is.
>
> > I need to go down into the details of the swsusp_suspend() code path to
> > fi
On Fri, Sep 21, 2007 at 01:03:47PM +0200, Jarek Poplawski wrote:
...
> any of them does ipc_rcu_getref() a bit later and sees old (cached)
Should be:
"any of them does ipc_rcu_putref() a bit later and sees old (cached)"
Sorry,
Jarek P.
-
To unsubscribe from this list: send the line "unsubscribe l
On Fri, Sep 21, 2007 at 12:11:15PM +0200, Nadia Derbey wrote:
> Jarek Poplawski wrote:
...
> >2. I'm not sure this refcounting with ipc_rcu_getref/putref is SMP
> >safe (memory barriers): it's not atomic, so locking is needed, but
> >e.g. in do_msgsnd() kern_ipc_perm lock is used for this, while
>
Jarek Poplawski wrote:
On Thu, Sep 20, 2007 at 03:08:42PM +0200, Nadia Derbey wrote:
Nadia Derbey wrote:
Jarek Poplawski wrote:
On Thu, Sep 20, 2007 at 08:24:58AM +0200, Nadia Derbey wrote:
...
Actually, ipc_lock() is called most of the time without the
ipc_ids.mutex held and without r
Andrew Morton wrote:
On Tue, 18 Sep 2007 16:55:19 +0200 Nadia Derbey <[EMAIL PROTECTED]> wrote:
This patch fixes the missing rcu_read_(un)lock in the ipc code
Thanks. Could you please check the code comments in ipc/util.c for
accuracy and completeness sometime?
Done - see attachment.
Ho
On Friday, 21 September 2007 09:56, Thomas Gleixner wrote:
> On Thu, 2007-09-20 at 19:35 -0400, Len Brown wrote:
> > > > (Btw, the above commit message points to just my response with a
> > > > testing
> > > > patch to the real email: the actual explanation of the INSANE ordering
> > > > is
> >
Thomas,
On Thursday, 20 September 2007 23:53, Thomas Gleixner wrote:
> Rafael,
>
> On Thu, 2007-09-20 at 23:45 +0200, Rafael J. Wysocki wrote:
> > > We disable everything in device_suspend()
> >
> > No, we don't. sysdevs are _not_ suspended in device_suspend().
> > They are suspended in device_
On Thu, Sep 20, 2007 at 03:08:42PM +0200, Nadia Derbey wrote:
> Nadia Derbey wrote:
> >Jarek Poplawski wrote:
> >
> >>On Thu, Sep 20, 2007 at 08:24:58AM +0200, Nadia Derbey wrote:
...
> >Actually, ipc_lock() is called most of the time without the
> >ipc_ids.mutex held and without refcounting (mayb
On Fri, 2007-09-21 at 14:51 +1000, Paul Mackerras wrote:
> Linus Torvalds writes:
>
> > It would indeed be nice if we could just take CPU's down early (while
> > everything is working), and run the whole suspend code with just one CPU,
> > rather than having to worry about the ordering between C
On Thu, 2007-09-20 at 19:35 -0400, Len Brown wrote:
> > > (Btw, the above commit message points to just my response with a testing
> > > patch to the real email: the actual explanation of the INSANE ordering is
> > > from Len Brown in
> > >
> > >
> > > https://lists.linux-foundation.org/piper
On Thu, Sep 20, 2007 at 10:36:13AM -0700, Christoph Lameter wrote:
> On Thu, 20 Sep 2007, Alexey Dobriyan wrote:
> > The winner is
> > slub-avoid-touching-page-struct-when-freeing-to-per-cpu-slab.patch
> > Blind bisecting pointed to it and reverting the patch from full -mm makes
> > the problem go
Linus Torvalds writes:
> It would indeed be nice if we could just take CPU's down early (while
> everything is working), and run the whole suspend code with just one CPU,
> rather than having to worry about the ordering between CPU and device
> takedown.
That is certainly what we want to do on
On Thu, Sep 20, 2007 at 09:42:44PM +0530, Kamalesh Babulal wrote:
> On 9/20/07, Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> > On 9/20/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > >
> > > On Wed, 19 Sep 2007 19:58:28 -0400
> > > [EMAIL PROTECTED] (Joseph Fannin) wrote:
> > >
> > > > On Tue, Se
Am 20.09.2007 22:25 schrieb Andrew Morton:
> There was a locking imbalance in the IPC code. Do you have the fixes in
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/hot-fixes/
> applied?
I hadn't. Now that I have, all the troubles are gone. X comes up
fin
On Thursday 20 September 2007 17:55, Linus Torvalds wrote:
>
> On Thu, 20 Sep 2007, Linus Torvalds wrote:
> >
> > (Btw, the above commit message points to just my response with a testing
> > patch to the real email: the actual explanation of the INSANE ordering is
> > from Len Brown in
> >
> >
On Friday, 21 September 2007 00:05, Thomas Gleixner wrote:
> Linus,
>
> On Thu, 2007-09-20 at 14:55 -0700, Linus Torvalds wrote:
> > And I think that's a damn reasonable thing to agree on: timers (and
> > anything else that CPU shutdown/bringup could *possibly* care about)
> > should be consider
Thomas,
On Thursday, 20 September 2007 23:53, Thomas Gleixner wrote:
> Rafael,
>
> On Thu, 2007-09-20 at 23:45 +0200, Rafael J. Wysocki wrote:
> > > We disable everything in device_suspend()
> >
> > No, we don't. sysdevs are _not_ suspended in device_suspend().
> > They are suspended in device_
Linus,
On Thu, 2007-09-20 at 14:55 -0700, Linus Torvalds wrote:
> And I think that's a damn reasonable thing to agree on: timers (and
> anything else that CPU shutdown/bringup could *possibly* care about)
> should be considered core enough that they had better be on the
> suspend_late/resume_ea
Rafael,
On Thu, 2007-09-20 at 23:54 +0200, Rafael J. Wysocki wrote:
> > Hmm. This is close to the ordering we have in STR too.
> >
> > I have some dim memory of there being some ACPI reason why it had to be
> > done that way.
>
> Yes. We're executing _INI from the CPU initialization code and t
On Thu, 20 Sep 2007, Linus Torvalds wrote:
>
> (Btw, the above commit message points to just my response with a testing
> patch to the real email: the actual explanation of the INSANE ordering is
> from Len Brown in
>
>
> https://lists.linux-foundation.org/pipermail/linux-pm/2006-Novem
Rafael,
On Thu, 2007-09-20 at 23:45 +0200, Rafael J. Wysocki wrote:
> > We disable everything in device_suspend()
>
> No, we don't. sysdevs are _not_ suspended in device_suspend().
> They are suspended in device_power_down(), which is called
> _after_ disable_nonboot_cpus() (from swsusp_suspend(
On Thursday, 20 September 2007 23:35, Linus Torvalds wrote:
>
> On Thu, 20 Sep 2007, Thomas Gleixner wrote:
> >
> > In meantime I figured out what's happening. The ordering in
> > hibernate_snapshot() is wrong. It does:
Actually, this is incorrect. Please read my reply to Thomas, just sent.
>
On Thu, 20 Sep 2007, Thomas Gleixner wrote:
>
> In meantime I figured out what's happening. The ordering in
> hibernate_snapshot() is wrong. It does:
Hmm. This is close to the ordering we have in STR too.
I have some dim memory of there being some ACPI reason why it had to be
done that way.
Thomas,
On Thursday, 20 September 2007 23:08, Thomas Gleixner wrote:
> Rafael,
>
> On Thu, 2007-09-20 at 22:39 +0200, Rafael J. Wysocki wrote:
> > > Works as well. What's the difference between this and the real thing ?
> >
> > The real thing also calls device_power_down(PMSG_FREEZE), which is a
Rafael,
On Thu, 2007-09-20 at 22:39 +0200, Rafael J. Wysocki wrote:
> > Works as well. What's the difference between this and the real thing ?
>
> The real thing also calls device_power_down(PMSG_FREEZE), which is a
> counterpart of sysdev_shutdown(), more or less, and I think that's what goes
>
On Thursday, 20 September 2007 16:12, Rafael J. Wysocki wrote:
> On Thursday, 20 September 2007 15:43, Thomas Gleixner wrote:
> > On Thu, 2007-09-20 at 15:29 +0200, Rafael J. Wysocki wrote:
> > > > > I haven't had the time to check if any special command line arguments
> > > > > help.
> > > > > Wi
On Thursday, 20 September 2007 17:49, Thomas Gleixner wrote:
> On Thu, 2007-09-20 at 16:50 +0200, Thomas Gleixner wrote:
> > > > > Well, the above may affect SMP systems, but the Vaio is UP. Hmm?
> > > >
> > > > My jinxed VAIO variant is SMP, but it looks like the same mysterious
> > > > error.
>
On Thu, 20 Sep 2007 21:20:24 +0200
Tilman Schmidt <[EMAIL PROTECTED]> wrote:
> Another data point. When booting into runlevel 3, the system is usable,
> although these messages still appear after boot:
>
> <4>[ 22.731025] sysfs: duplicate filename 'bInterfaceNumber' can not be
> created
> <4>[
On Thu, 20 Sep 2007 21:42:44 +0530
"Kamalesh Babulal" <[EMAIL PROTECTED]> wrote:
> ...
>
> > i have tested the change with cross compiler for power405 with the same
> > .config
> > with which the build problem is solved, but the build fails with another
> > error
> >
> > CC [M] drivers/net/mace
Another data point. When booting into runlevel 3, the system is usable,
although these messages still appear after boot:
<4>[ 22.731025] sysfs: duplicate filename 'bInterfaceNumber' can not be
created
<4>[ 22.735872] WARNING: at fs/sysfs/dir.c:433 sysfs_add_one()
<7>[ 22.740737] bas_gigaset
On 2007-09-20 01:55, /me wrote:
> Rats. Sorry. I remember now. That's not the first time I am hit by
> that one. I had even made a resolution to try and find out the correct
> options to set. So what are they? CONFIG_RTC=y and CONFIG_RTC_DRV_CMOS=n?
> Guess I should try that combination in my next
Christoph Lameter <[EMAIL PROTECTED]> writes:
> On Thu, 20 Sep 2007, Christoph Lameter wrote:
>
>> Eric: Anything that comes to mind in sysfs?
>
> Arg. Forget it. Its likely SLUB mm related.
Ok.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mes
On Thu, 20 Sep 2007, Christoph Lameter wrote:
> Eric: Anything that comes to mind in sysfs?
Arg. Forget it. Its likely SLUB mm related.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kerne
On Wednesday 19 September 2007, Andrew Morton wrote:
> Head still spinning.
>
> a) "rtc0" != "rtc" ??
One key difference between any of the numerous legacy RTC drivers
and the new framework is that the legacy drivers tended to think
(wrongly!) they would be the only RTC in the system, while the
f
On Thu, 20 Sep 2007, Alexey Dobriyan wrote:
> The winner is
> slub-avoid-touching-page-struct-when-freeing-to-per-cpu-slab.patch
> Blind bisecting pointed to it and reverting the patch from full -mm makes
> the problem go away
Hmmm.. This means likely that the c->node is used somewhere for
inde
Hello,
> > -ECONFUSED. Perhaps DEBUG_DRIVER may help some more. Or /me getting
> > some sleep.
>
> Sleeping helped (improved reading abilities).
>
> From: Cornelia Huck <[EMAIL PROTECTED]>
>
> mmc: Avoid double sdio_unregister_bus() on module unload.
>
> Signed-off-by: Cornelia Huck <[EMAIL PR
On Thu, 20 Sep 2007, Alexey Dobriyan wrote:
> OK, I do clean boot, ssh to box, then sudo slabinfo -v.
>
>
> =
> BUG kmalloc-16: Object padding overwritten
> ---
Cedric Le Goater wrote:
> Pavel Emelyanov wrote:
>> Looks sane :)
>>
>> [snip]
>>
>>> Index: 2.6.23-rc6-mm1/kernel/exit.c
>>> ===
>>> --- 2.6.23-rc6-mm1.orig/kernel/exit.c
>>> +++ 2.6.23-rc6-mm1/kernel/exit.c
>>> @@ -408,6 +408,8 @@ vo
On Thu, 20 Sep 2007 15:35:18 +0200
Cornelia Huck <[EMAIL PROTECTED]> wrote:
> On Wed, 19 Sep 2007 20:02:05 +0200,
> Cornelia Huck <[EMAIL PROTECTED]> wrote:
>
> > -ECONFUSED. Perhaps DEBUG_DRIVER may help some more. Or /me getting
> > some sleep.
>
> Sleeping helped (improved reading abilities).
On Thursday 20 September 2007, Kay Sievers wrote:
>
> Isn't that all caused by the rtc driver registering itself without
> checking if it is able to grab the device? Wouldn't moving the
> request_resource() before doing any device registration do the magic?
I suspect it would. Got patch?
I'm tr
On Thu, 2007-09-20 at 16:50 +0200, Thomas Gleixner wrote:
> > > > Well, the above may affect SMP systems, but the Vaio is UP. Hmm?
> > >
> > > My jinxed VAIO variant is SMP, but it looks like the same mysterious
> > > error.
> >
> > Hm. Have you tried
> >
> > # echo test > /sys/power/disk
> >
Alan Cox wrote:
On Thu, 20 Sep 2007 14:13:15 +0100
[EMAIL PROTECTED] (Mel Gorman) wrote:
PPC64 building allmodconfig fails to compile drivers/ata/pata_scc.c . It
doesn't show up on other arches because this driver is specific to the
architecture.
drivers/ata/pata_scc.c: In function `scc_bmd
On (20/09/07 15:09), Alan Cox didst pronounce:
> On Thu, 20 Sep 2007 14:13:15 +0100
> [EMAIL PROTECTED] (Mel Gorman) wrote:
>
> > PPC64 building allmodconfig fails to compile drivers/ata/pata_scc.c . It
> > doesn't show up on other arches because this driver is specific to the
> > architecture.
>
On Thu, 2007-09-20 at 16:47 +0200, Rafael J. Wysocki wrote:
> On Thursday, 20 September 2007 15:53, Thomas Gleixner wrote:
> > On Thu, 2007-09-20 at 16:12 +0200, Rafael J. Wysocki wrote:
> > > > Vs. the suspend / resume wreckage of rc6-mm1 / rc6-hrt2:
> > >
> > > ie. the one on the Vaio (I assume
On Thursday, 20 September 2007 15:53, Thomas Gleixner wrote:
> On Thu, 2007-09-20 at 16:12 +0200, Rafael J. Wysocki wrote:
> > > Vs. the suspend / resume wreckage of rc6-mm1 / rc6-hrt2:
> >
> > ie. the one on the Vaio (I assume).
> >
> > > I'm still fishing in rather dark water. Depending on the
On Thu, 2007-09-20 at 16:12 +0200, Rafael J. Wysocki wrote:
> > Vs. the suspend / resume wreckage of rc6-mm1 / rc6-hrt2:
>
> ie. the one on the Vaio (I assume).
>
> > I'm still fishing in rather dark water. Depending on the added
> > instrumentation points the problem mutates up to the point whe
On Thu, 20 Sep 2007 14:13:15 +0100
[EMAIL PROTECTED] (Mel Gorman) wrote:
> PPC64 building allmodconfig fails to compile drivers/ata/pata_scc.c . It
> doesn't show up on other arches because this driver is specific to the
> architecture.
>
> drivers/ata/pata_scc.c: In function `scc_bmdma_status'
On Thursday, 20 September 2007 15:43, Thomas Gleixner wrote:
> On Thu, 2007-09-20 at 15:29 +0200, Rafael J. Wysocki wrote:
> > > > I haven't had the time to check if any special command line arguments
> > > > help.
> > > > Will check tomorrow.
> > >
> > > Can you please disable the patches, which
On Thu, 2007-09-20 at 15:29 +0200, Rafael J. Wysocki wrote:
> > > I haven't had the time to check if any special command line arguments
> > > help.
> > > Will check tomorrow.
> >
> > Can you please disable the patches, which I sent Linus wards:
> >
> > timekeeping-access-rtc-outside-xtime-lock.p
On Wed, 19 Sep 2007 20:02:05 +0200,
Cornelia Huck <[EMAIL PROTECTED]> wrote:
> -ECONFUSED. Perhaps DEBUG_DRIVER may help some more. Or /me getting
> some sleep.
Sleeping helped (improved reading abilities).
From: Cornelia Huck <[EMAIL PROTECTED]>
mmc: Avoid double sdio_unregister_bus() on modul
On Thu, Sep 20, 2007 at 03:08:42PM +0200, Nadia Derbey wrote:
...
> So, here is the ipc_lock_by_ptr() status:
> 1) do_msgsnd(), semctl_main(GETALL), semctl_main(SETALL) and find_undo()
> call it inside a refcounting.
> ==> no rcu read section needed.
>
> 2) *_exit_ns(), ipc_findkey() and sysvip
On Thursday, 20 September 2007 08:18, Thomas Gleixner wrote:
> On Thu, 2007-09-20 at 02:06 +0200, Rafael J. Wysocki wrote:
> > On Wednesday, 19 September 2007 21:21, Thomas Gleixner wrote:
> > > On Wed, 2007-09-19 at 19:44 +0200, Rafael J. Wysocki wrote:
> > > > > > It boots with nohpet alone and s
On Thu, Sep 20, 2007 at 10:52:43AM +0200, Nadia Derbey wrote:
> Jarek Poplawski wrote:
...
> >which seems to suggest "out" is an RCU protected pointer, so, I
> >thought these refcounts were for something else. But, after looking
> >at how it's used it turns out to be ~90% wrong: probably 9 out of 1
Nadia Derbey wrote:
Jarek Poplawski wrote:
On Thu, Sep 20, 2007 at 08:24:58AM +0200, Nadia Derbey wrote:
Jarek Poplawski wrote:
On 18-09-2007 16:55, Nadia Derbey wrote:
...
Well, reviewing the code I found another place where the
rcu_read_unlock() was missing.
I'm so sorry for the inconv
Provide {enable,disable}_irq_wakeup dummies for undefined
CONFIG_GENERIC_HARDIRQS case. Completely untested, as I don't even have
cross-compilers for platforms without CONFIG_GENERIC_HARDIRQS.
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
On Tue, 18 Sep 2007, Andrew Morton wrote
On Thu, 20 Sep 2007 12:31:39 +0100 (BST) Hugh Dickins
<[EMAIL PROTECTED]> wrote:
Thanks Hugh!
> [PATCH mm] mm per-device dirty threshold fix
>
> Fix occasional hang when a task couldn't get out of balance_dirty_pages:
> mm-per-device-dirty-threshold.patch needs to reevaluate bdi_nr_writeback
>
On Wed, 19 Sep 2007, Peter Zijlstra wrote:
> On Wed, 19 Sep 2007 21:03:19 +0100 (BST) Hugh Dickins
> <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 19 Sep 2007, Andy Whitcroft wrote:
> > > Seems I have a case of a largish i386 NUMA (NUMA-Q) which has a mkfs
> > > stuck in a 'D' wait:
> > >
> > > =
On Thu, Sep 20, 2007 at 11:53:53AM +0400, Alexey Dobriyan wrote:
> On Wed, Sep 19, 2007 at 02:36:04PM -0700, Christoph Lameter wrote:
> > So I would think that this is an actual memory corruption issue on your
> > system and the /sys/slab stuff works fine. slabinfo -v will perform a more
> > deta
Pavel Emelyanov wrote:
> Looks sane :)
>
> [snip]
>
>> Index: 2.6.23-rc6-mm1/kernel/exit.c
>> ===
>> --- 2.6.23-rc6-mm1.orig/kernel/exit.c
>> +++ 2.6.23-rc6-mm1/kernel/exit.c
>> @@ -408,6 +408,8 @@ void daemonize(const char *name, ..
Looks sane :)
[snip]
> Index: 2.6.23-rc6-mm1/kernel/exit.c
> ===
> --- 2.6.23-rc6-mm1.orig/kernel/exit.c
> +++ 2.6.23-rc6-mm1/kernel/exit.c
> @@ -408,6 +408,8 @@ void daemonize(const char *name, ...)
> current->fs = fs;
>
On Wed, 19 Sep 2007 23:11:21 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> b) The kernel is trying to register two procfs files of the same name!
>If that's a configuration error then we have a Kconfiguration bug.
I guess the best solution would be to have Kconfig avoid that. I'll try
t
Jarek Poplawski wrote:
On Thu, Sep 20, 2007 at 08:24:58AM +0200, Nadia Derbey wrote:
Jarek Poplawski wrote:
On 18-09-2007 16:55, Nadia Derbey wrote:
...
Well, reviewing the code I found another place where the
rcu_read_unlock() was missing.
I'm so sorry for the inconvenience. It's true tha
1 - 100 of 205 matches
Mail list logo
