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
>
hen we've noticed it already) is probably better (?)
Sure that would be great to have.
> [ BTW I don't see the fix in your git trees or quilt queue. So I'll
> make a patch on top of 2.6.23-rc6-mm1 itself. ]
I'm behind in updating my patch queue, sorry, other things cam
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
>
>
&
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
idia(P)(U) thermal(U) ieee1394(U) pcmcia_core(U)
> watchdog_dev(U) processor(U) snd_hda_intel(U) intel_agp(U) ac(U) button(U)
> video(U) battery(U) power_supply(U) output(U) rtc(U)
> [ 48.297000] Pid: 7, comm: ksoftirqd/1 Tainted: P2.6.23-rc6-mm1 #8
> [ 48.297000] RIP
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
tel(U) intel_agp(U) ac(U) button(U) video(U) battery(U)
power_supply(U) output(U) rtc(U)
[ 48.297000] Pid: 7, comm: ksoftirqd/1 Tainted: P2.6.23-rc6-mm1 #8
[ 48.297000] RIP: 0010:[] []
__list_add+0xfb/0x138
[ 48.297000] RSP: :81000349fd38 EFLAGS: 00010002
[ 48.2
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
On 09/24/2007 05:25 AM, [EMAIL PROTECTED] wrote:
> On Fri, 21 Sep 2007 21:43:20 +0200, Jiri Slaby said:
>> On 09/21/2007 09:38 PM, Jiri Slaby wrote:
>>> It is rather the other user who adds the page to some other list while bein
> g at
>>> deferred_pages list. Could you try my debug patch
>>> (http
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 Fri, 21 Sep 2007 21:43:20 +0200, Jiri Slaby said:
> On 09/21/2007 09:38 PM, Jiri Slaby wrote:
> > It is rather the other user who adds the page to some other list while bein
g at
> > deferred_pages list. Could you try my debug patch
> > (http://lkml.org/lkml/2007/9/19/141)?
>
> or the whitespac
if (bdi_nr_reclaimable + bdi_nr_writeback <= bdi_thresh)
> > > > break;
> > > > if (pages_written >= write_chunk)
> > > >
> > >
> > > > [ 1305.361511] balance_dirty_pages written 0 0 cong
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 driver
ritten 0 0 congested 0 limits 48869
> > > 195477 5801 5760 288 -247
> >
> >
> >
> > Could you perhaps instrument the writeback_inodes() path to see why
> > nothing is written out? - the attached patch would be a nice start.
>
> Curiously the lockup pr
On Sat, Sep 22, 2007 at 10:35:45PM -0700, Andrew Morton wrote:
> On Sun, 23 Sep 2007 13:30:40 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote:
>
> > > That's interensting. serial_in(). We have had NMI watchdog expiries when
> > > the kernel is printing a large amount of stuff out a slow serial port
On Sun, 23 Sep 2007 13:30:40 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote:
> > That's interensting. serial_in(). We have had NMI watchdog expiries when
> > the kernel is printing a large amount of stuff out a slow serial port with
> > interrutps disabled. But I thought we'd pretty much plugged
l/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
> > >
> > > 2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6.
> >
> >
> > This bug appears in 2.6.23-rc3-mm1, too.
>
> hm, there isn't much info here.
>
> > The message:
> >
&g
On Sun, 23 Sep 2007 09:42:14 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 18, 2007 at 01:18:41AM -0700, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
> >
> > 2.6.23-rc6-mm1
On Sun, Sep 23, 2007 at 09:42:14AM +0800, Fengguang Wu wrote:
> On Tue, Sep 18, 2007 at 01:18:41AM -0700, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm1/
> >
> > 2.6.23-rc6-mm1 is a 29MB diff again
if (pages_written >= write_chunk)
> >
>
> > [ 1305.361511] balance_dirty_pages written 0 0 congested 0 limits 48869
> > 195477 5801 5760 288 -247
>
>
>
> Could you perhaps instrument the writeback_inodes() path to see why
> nothing is written o
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);
>
#x27;s a small/trivial
driver, so I think just converting it to dynamic allocation right now
itself (when we've noticed it already) is probably better (?)
[ BTW I don't see the fix in your git trees or quilt queue. So I'll
make a patch on top of 2.6.23-rc6-mm1 itself. ]
Thanks
> -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_et
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 follow
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 li
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-ke
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.
> >
see a hang like this.
> > >
> > > I've been seeing something like that on 4-way PPC64: in my case I've
> > > shells hanging in D state trying to append to kernel build log on ext3
> > > (the builds themselves going on elsewhere, in tmpfs): one of t
On 09/21/2007 09:38 PM, Jiri Slaby wrote:
> It is rather the other user who adds the page to some other list while being
> at
> deferred_pages list. Could you try my debug patch
> (http://lkml.org/lkml/2007/9/19/141)?
or the whitespace non-damaged version:
http://www.fi.muni.cz/~xslaby/sklad/page
On 09/21/2007 09:33 PM, [EMAIL PROTECTED] wrote:
> On Fri, 21 Sep 2007 19:30:04 +0200, Jiri Slaby said:
>> On 09/21/2007 07:16 PM, [EMAIL PROTECTED] wrote:
>
>>> Hmm.. maybe I'm chasing a different bug manifested by the same patch. For
>>> me,
>>> it's been a solid lockup at X startup since -rc3
On Fri, 21 Sep 2007 19:30:04 +0200, Jiri Slaby said:
> On 09/21/2007 07:16 PM, [EMAIL PROTECTED] wrote:
> > Hmm.. maybe I'm chasing a different bug manifested by the same patch. For
> > me,
> > it's been a solid lockup at X startup since -rc3-mm1, and this patch doesn't
> > change matters.
>
>
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
* Christoph Hellwig ([EMAIL PROTECTED]) wrote:
> On Thu, Sep 20, 2007 at 04:10:18PM -0700, Andrew Morton wrote:
> > On Tue, 18 Sep 2007 17:06:01 -0400
> > Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> >
> > > Here are the text edit lock patches ported to 2
On Fri, 21 Sep 2007 19:30:04 +0200, Jiri Slaby said:
> On 09/21/2007 07:16 PM, [EMAIL PROTECTED] wrote:
> > On Thu, 20 Sep 2007 17:06:05 CDT, Matt Mackall said:
> >> 2.6.23-rc3-mm1: solid lock on X shutdown (noticed when upgrading)
> >> -rc4-mm1: solid lock on X shutdown, random solid locks a
On 09/21/2007 07:16 PM, [EMAIL PROTECTED] wrote:
> On Thu, 20 Sep 2007 17:06:05 CDT, Matt Mackall said:
>> 2.6.23-rc3-mm1: solid lock on X shutdown (noticed when upgrading)
>> -rc4-mm1: solid lock on X shutdown, random solid locks about
>> once every four hours
>> -rc6-m
On Thu, Sep 20, 2007 at 04:10:18PM -0700, Andrew Morton wrote:
> On Tue, 18 Sep 2007 17:06:01 -0400
> Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
>
> > Here are the text edit lock patches ported to 2.6.23-rc6-mm1.
>
> I think I'll duck these one more time. There
On Fri, 21 Sep 2007 01:44:41 +0200, Andi Kleen said:
> Full bisect needed then I guess. Ok as a short cut you could perhaps
> the cpa-* patches first (might need to drop some later depending
> patches), then the drm and agp trees.
The later depending patches:
x86_64-mm-cpa-clflush.patch
x86_64-
On Thu, 20 Sep 2007 17:06:05 CDT, Matt Mackall said:
> On Thu, Sep 20, 2007 at 11:42:29AM +1000, Dave Airlie wrote:
> > I've attached a more complicated patch that does a 2 stage effort to
> > unmapping and freeing pages. My kernel no longer hangs with this
> > patch...
> >
> > Jiri can you confi
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.
> >
uennadi Liakhovetski <[EMAIL PROTECTED]>
>
It builds fine now.
Tested-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
> ---
>
> On Tue, 18 Sep 2007, Andrew Morton wrote:
>
> > On Tue, 18 Sep 2007 16:54:03 -0400
> > Mathieu Desnoyers <[EMAIL PROTECTED]> 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 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
MAIL PROTECTED]>
---
This patch applies on top of 2.6.23-rc6-mm1 + the previous IPC patches.
ipc/msg.c | 14 +-
ipc/sem.c | 14 ++
ipc/shm.c | 39 --
ipc/util.c | 78 +++--
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
> Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
>
> ---
> mm/slub.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> Index: linux-2.6.23-rc6-mm1/mm/slub.c
> ===
> --- linux-2.
On 09/21/2007 01:31 AM, Matt Mackall wrote:
> On Fri, Sep 21, 2007 at 01:03:04AM +0200, Andi Kleen wrote:
>>> It's broken for me.
>>>
>>> 2.6.23-rc3-mm1: solid lock on X shutdown (noticed when upgrading)
>>> -rc4-mm1: solid lock on X shutdown, random solid locks about
>>> once
On Thu, Sep 20 2007, Lee Schermerhorn wrote:
> PATCH 2.6.23-rc6-mm1 - Panic in blk_rq_map_sg() from CCISS driver
>
> New scatter/gather list chaining [sg_next()] treats 'page' member of
> struct scatterlist with low bit set [0x01] as a chain pointer to
> another struct
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
f mesa, that i915 dri driver doesn't know
your chipset. Try mesa-7.X.
I have also seen X exit broken with 2.6.23-rc6-mm1, will follow this thread
and try Dave's patch.
Thanks for testing!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
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 go
On Thu, Sep 20, 2007 at 06:31:14PM -0500, Matt Mackall wrote:
> On Fri, Sep 21, 2007 at 01:03:04AM +0200, Andi Kleen wrote:
> > > It's broken for me.
> > >
> > > 2.6.23-rc3-mm1: solid lock on X shutdown (noticed when upgrading)
> > > -rc4-mm1: solid lock on X shutdown, random solid locks abo
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 Fri, Sep 21, 2007 at 01:03:04AM +0200, Andi Kleen wrote:
> > It's broken for me.
> >
> > 2.6.23-rc3-mm1: solid lock on X shutdown (noticed when upgrading)
> > -rc4-mm1: solid lock on X shutdown, random solid locks about
> > once every four hours
> > -rc6-mm1: solid l
On Tue, 18 Sep 2007 17:06:01 -0400
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> Here are the text edit lock patches ported to 2.6.23-rc6-mm1.
I think I'll duck these one more time. There was a bit of followup
and for now I'd prefer to concentrate on obviously-safe stuff a
> It's broken for me.
>
> 2.6.23-rc3-mm1: solid lock on X shutdown (noticed when upgrading)
> -rc4-mm1: solid lock on X shutdown, random solid locks about
> once every four hours
> -rc6-mm1: solid lock on X startup
>+your patch: screen goes black, turns off and on a
> > But now I'm talking about another issue -- a regression since rc4-mm1,
> > where X
> > server is unable to bind agp memory (those x logs above). The clflush issue
> > has
> > solved andi in
> > http://lkml.org/lkml/2007/9/19/334
> > recently
>
> Tried that, my laptop still bricks the instant
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_
On 09/20/2007 11:24 AM, Zhenyu Wang wrote:
> On 2007.09.20 17:33:45 +, Dave Airlie wrote:
>>> Maybe you are rather interested in these dmesg lines:
>>> Linux agpgart interface v0.102
>>> agpgart: suspend/resume problematic: resume with 3D/DRI active may lockup
>>> X.Org
>>> on some chipset/BIO
On Thu, Sep 20, 2007 at 11:42:29AM +1000, Dave Airlie wrote:
> > The code is broken anyways. If you free pages without flushing
> > them first some other innocent user allocating them will end up
> > with possible uncached pages for some time.
> >
> > Does this simple patch help?
> >
>
> I've atta
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.
>
PATCH 2.6.23-rc6-mm1 - Panic in blk_rq_map_sg() from CCISS driver
New scatter/gather list chaining [sg_next()] treats 'page' member of
struct scatterlist with low bit set [0x01] as a chain pointer to
another struct scatterlist [array]. The CCISS driver request function
passes an uni
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
h is a
counterpart of sysdev_shutdown(), more or less, and I think that's what goes
belly up.
You can use the patch below (on top of -rc6-mm1), which just disables the image
creation (that should be irrelevant anyway) and see what happens.
/0x77d
> Sep 20 20:54:36 xenon kernel: [ 39.629004] []
> get_signal_to_deliver+0x408/0x434
> Sep 20 20:54:36 xenon kernel: [ 39.633252] []
> do_notify_resume+0x94/0x6a6
> Sep 20 20:54:36 xenon kernel: [ 39.637554] []
> work_notifysig+0x13/0x1a
> Sep 20 20:54:36 xenon
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
1 - 100 of 276 matches
Mail list logo
