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,
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,
rather
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]>
> ---
>
> ---
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 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]
---
---
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 work at
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 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
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 needed, but
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
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
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 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 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 vmlinux.o
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
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
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
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
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
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
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
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.
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
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
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
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 the
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, 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 logic by
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
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
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 other arches
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 recent netdev
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 kept
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 in the first
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
> >>> ===
> >>> ---
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]>
> > >
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
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
> > > +++
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
+++
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
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:
---
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 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,
> -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
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
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:
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
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
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
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 unsubscribe
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/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]
-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 message
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, please do.
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);
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
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
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
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
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
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
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
> >
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
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
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.
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
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
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
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
> > >
> > >
> > >
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
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 away
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
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 CPU and
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 (maybe you
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
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
from Len Brown
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.
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
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
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
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
figure out,
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.
I need to
* 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 [EMAIL
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 up in C2 or
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 debugging the
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 as well.
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 possible
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 NUMA (NUMA-Q)
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.
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 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,
1 - 100 of 409 matches
Mail list logo
