* [Bug #12414] iwl4965 cannot use "ap auto" on latest 2.6.28/29?
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:06 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:06 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Jeff Chua
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12414
Subject : iwl4965 cannot use "ap auto" on latest 2.6.28/29?
Submitter : Jeff Chua <jeff.chua.linux@gmail.com>
Date : 2009-01-05 4:13 (35 days old)
References : http://marc.info/?l=linux-kernel&m=123112882127823&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12415] WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.c:689
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Christian Borntraeger, Reinette Chatre,
Tomas Winkler
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12415
Subject : WARNING: at drivers/net/wireless/iwlwifi/iwl-sta.c:689
Submitter : Christian Borntraeger <borntraeger@de.ibm.com>
Date : 2009-01-05 10:36 (35 days old)
References : http://marc.info/?l=linux-wireless&m=123115178019082&w=4
Handled-By : Reinette Chatre <reinette.chatre@intel.com>
Patch : http://marc.info/?l=linux-wireless&m=123316414222201&w=2
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12441] Xorg can't use dri on radeon X1950 AGP
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Daniel Vetter, Dave Airlie
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12441
Subject : Xorg can't use dri on radeon X1950 AGP
Submitter : Daniel Vetter <daniel@ffwll.ch>
Date : 2009-01-13 05:20 (27 days old)
Handled-By : Dave Airlie <airlied@linux.ie>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=20032&action=view
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12419] possible circular locking dependency on i915 dma
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Wang Chen
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12419
Subject : possible circular locking dependency on i915 dma
Submitter : Wang Chen <wangchen@cn.fujitsu.com>
Date : 2009-01-08 14:11 (32 days old)
References : http://marc.info/?l=linux-kernel&m=123142399720125&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12418] Repeated ioctl(4, 0x40046445, ..) loop in glxgears
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Dave Airlie, Pallipadi, Venkatesh
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12418
Subject : Repeated ioctl(4, 0x40046445, ..) loop in glxgears
Submitter : Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com>
Date : 2009-01-07 22:43 (33 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7c1c2871a6a3a114853ec6836e9035ac1c0c7f7a
References : http://marc.info/?l=linux-kernel&m=123136836213319&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12491] i915 lockdep warning
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Brandeburg, Jesse, Roland Dreier
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12491
Subject : i915 lockdep warning
Submitter : Brandeburg, Jesse <jesse.brandeburg@intel.com>
Date : 2009-01-13 23:17 (27 days old)
References : http://marc.info/?l=linux-kernel&m=123188898423532&w=4
Handled-By : Roland Dreier <rolandd@cisco.com>
Patch : http://marc.info/?l=linux-kernel&m=123378709730700&w=2
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12444] X hangs following switch from radeonfb console - Bisected
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Graham Murray
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12444
Subject : X hangs following switch from radeonfb console - Bisected
Submitter : Graham Murray <graham@gmurray.org.uk>
Date : 2009-01-13 14:03 (27 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7c1c2871a6a3a114853ec6836e9035ac1c0c7f7a
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12490] ath5k related kernel panic in 2.6.29-rc1
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Bob Copeland, Sergey S. Kostyliov
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12490
Subject : ath5k related kernel panic in 2.6.29-rc1
Submitter : Sergey S. Kostyliov <rathamahata@gmail.com>
Date : 2009-01-12 7:38 (28 days old)
References : http://marc.info/?l=linux-kernel&m=123174591509586&w=4
Handled-By : Bob Copeland <me@bobcopeland.com>
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12497] new barrier warnings in 2.6.29-rc1
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Christoph Hellwig, Jens Axboe, Tejun Heo
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12497
Subject : new barrier warnings in 2.6.29-rc1
Submitter : Christoph Hellwig <hch@lst.de>
Date : 2009-01-12 15:46 (28 days old)
References : http://marc.info/?l=linux-kernel&m=123177528217154&w=4
Handled-By : Jens Axboe <jens.axboe@oracle.com>
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12494] Sony backlight regression from 2.6.28 to 29-rc
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Mattia Dongili, Norbert Preining
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12494
Subject : Sony backlight regression from 2.6.28 to 29-rc
Submitter : Norbert Preining <preining@logic.at>
Date : 2009-01-19 8:14 (21 days old)
References : http://marc.info/?l=linux-acpi&m=123235286829512&w=4
Handled-By : Mattia Dongili <malattia@linux.it>
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12496] swsusp cannot find resume device (sometimes)
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Arjan van de Ven, Rafael J. Wysocki
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12496
Subject : swsusp cannot find resume device (sometimes)
Submitter : Rafael J. Wysocki <rjw@sisk.pl>
Date : 2009-01-09 12:24 (31 days old)
References : http://marc.info/?l=linux-kernel&m=123150395731165&w=4
Handled-By : Arjan van de Ven <arjan@infradead.org>
Patch : http://marc.info/?l=linux-kernel&m=123156441218358&w=4
http://marc.info/?t=123156453100002&r=1&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12496] swsusp cannot find resume device (sometimes)
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Arjan van de Ven, Rafael J. Wysocki
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12496
Subject : swsusp cannot find resume device (sometimes)
Submitter : Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
Date : 2009-01-09 12:24 (31 days old)
References : http://marc.info/?l=linux-kernel&m=123150395731165&w=4
Handled-By : Arjan van de Ven <arjan-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Patch : http://marc.info/?l=linux-kernel&m=123156441218358&w=4
http://marc.info/?t=123156453100002&r=1&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12496] swsusp cannot find resume device (sometimes)
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-09 0:38 ` Arjan van de Ven
-1 siblings, 0 replies; 219+ messages in thread
From: Arjan van de Ven @ 2009-02-09 0:38 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Rafael J. Wysocki, greg
On Sun, 8 Feb 2009 20:21:39 +0100 (CET)
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me
> know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12496
> Subject : swsusp cannot find resume device (sometimes)
> Submitter : Rafael J. Wysocki <rjw@sisk.pl>
> Date : 2009-01-09 12:24 (31 days old)
> References :
> http://marc.info/?l=linux-kernel&m=123150395731165&w=4
> Handled-By : Arjan van de Ven <arjan@infradead.org>
> Patch :
> http://marc.info/?l=linux-kernel&m=123156441218358&w=4
> http://marc.info/?t=123156453100002&r=1&w=4
>
>
the patches are in -mm waiting for gregkh to pick them up and push...
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12496] swsusp cannot find resume device (sometimes)
@ 2009-02-09 0:38 ` Arjan van de Ven
0 siblings, 0 replies; 219+ messages in thread
From: Arjan van de Ven @ 2009-02-09 0:38 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List,
Rafael J. Wysocki, greg-U8xfFu+wG4EAvxtiuMwx3w
On Sun, 8 Feb 2009 20:21:39 +0100 (CET)
"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me
> know (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12496
> Subject : swsusp cannot find resume device (sometimes)
> Submitter : Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
> Date : 2009-01-09 12:24 (31 days old)
> References :
> http://marc.info/?l=linux-kernel&m=123150395731165&w=4
> Handled-By : Arjan van de Ven <arjan-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> Patch :
> http://marc.info/?l=linux-kernel&m=123156441218358&w=4
> http://marc.info/?t=123156453100002&r=1&w=4
>
>
the patches are in -mm waiting for gregkh to pick them up and push...
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12496] swsusp cannot find resume device (sometimes)
@ 2009-02-09 2:27 ` Greg KH
0 siblings, 0 replies; 219+ messages in thread
From: Greg KH @ 2009-02-09 2:27 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List
On Sun, Feb 08, 2009 at 04:38:17PM -0800, Arjan van de Ven wrote:
> On Sun, 8 Feb 2009 20:21:39 +0100 (CET)
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
>
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me
> > know (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12496
> > Subject : swsusp cannot find resume device (sometimes)
> > Submitter : Rafael J. Wysocki <rjw@sisk.pl>
> > Date : 2009-01-09 12:24 (31 days old)
> > References :
> > http://marc.info/?l=linux-kernel&m=123150395731165&w=4
> > Handled-By : Arjan van de Ven <arjan@infradead.org>
> > Patch :
> > http://marc.info/?l=linux-kernel&m=123156441218358&w=4
> > http://marc.info/?t=123156453100002&r=1&w=4
> >
> >
>
> the patches are in -mm waiting for gregkh to pick them up and push...
Ok, I'm totally confused now, care to point out exactly which ones I
should be picking up and pushing?
thanks,
greg "i'm slow, humor me" k-h
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12496] swsusp cannot find resume device (sometimes)
@ 2009-02-09 2:27 ` Greg KH
0 siblings, 0 replies; 219+ messages in thread
From: Greg KH @ 2009-02-09 2:27 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List
On Sun, Feb 08, 2009 at 04:38:17PM -0800, Arjan van de Ven wrote:
> On Sun, 8 Feb 2009 20:21:39 +0100 (CET)
> "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me
> > know (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12496
> > Subject : swsusp cannot find resume device (sometimes)
> > Submitter : Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
> > Date : 2009-01-09 12:24 (31 days old)
> > References :
> > http://marc.info/?l=linux-kernel&m=123150395731165&w=4
> > Handled-By : Arjan van de Ven <arjan-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> > Patch :
> > http://marc.info/?l=linux-kernel&m=123156441218358&w=4
> > http://marc.info/?t=123156453100002&r=1&w=4
> >
> >
>
> the patches are in -mm waiting for gregkh to pick them up and push...
Ok, I'm totally confused now, care to point out exactly which ones I
should be picking up and pushing?
thanks,
greg "i'm slow, humor me" k-h
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12496] swsusp cannot find resume device (sometimes)
@ 2009-02-09 23:46 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-09 23:46 UTC (permalink / raw)
To: Greg KH
Cc: Arjan van de Ven, Linux Kernel Mailing List, Kernel Testers List,
Andrew Morton
On Monday 09 February 2009, Greg KH wrote:
> On Sun, Feb 08, 2009 at 04:38:17PM -0800, Arjan van de Ven wrote:
> > On Sun, 8 Feb 2009 20:21:39 +0100 (CET)
> > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> >
> > > This message has been generated automatically as a part of a report
> > > of recent regressions.
> > >
> > > The following bug entry is on the current list of known regressions
> > > from 2.6.28. Please verify if it still should be listed and let me
> > > know (either way).
> > >
> > >
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12496
> > > Subject : swsusp cannot find resume device (sometimes)
> > > Submitter : Rafael J. Wysocki <rjw@sisk.pl>
> > > Date : 2009-01-09 12:24 (31 days old)
> > > References :
> > > http://marc.info/?l=linux-kernel&m=123150395731165&w=4
> > > Handled-By : Arjan van de Ven <arjan@infradead.org>
> > > Patch :
> > > http://marc.info/?l=linux-kernel&m=123156441218358&w=4
> > > http://marc.info/?t=123156453100002&r=1&w=4
> > >
> > >
> >
> > the patches are in -mm waiting for gregkh to pick them up and push...
>
> Ok, I'm totally confused now, care to point out exactly which ones I
> should be picking up and pushing?
Patches from -mm called:
drivers-consolidate-driver_probe_done-loops-into-one-place.patch
drivers-consolidate-driver_probe_done-loops-into-one-place-checkpatch-fixes.patch
resume-wait-for-device-probing-to-finish.patch
drivers-consolidate-driver_probe_done-loops-into-one-place-fix.patch
in this order.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12496] swsusp cannot find resume device (sometimes)
@ 2009-02-09 23:46 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-09 23:46 UTC (permalink / raw)
To: Greg KH
Cc: Arjan van de Ven, Linux Kernel Mailing List, Kernel Testers List,
Andrew Morton
On Monday 09 February 2009, Greg KH wrote:
> On Sun, Feb 08, 2009 at 04:38:17PM -0800, Arjan van de Ven wrote:
> > On Sun, 8 Feb 2009 20:21:39 +0100 (CET)
> > "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> >
> > > This message has been generated automatically as a part of a report
> > > of recent regressions.
> > >
> > > The following bug entry is on the current list of known regressions
> > > from 2.6.28. Please verify if it still should be listed and let me
> > > know (either way).
> > >
> > >
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12496
> > > Subject : swsusp cannot find resume device (sometimes)
> > > Submitter : Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
> > > Date : 2009-01-09 12:24 (31 days old)
> > > References :
> > > http://marc.info/?l=linux-kernel&m=123150395731165&w=4
> > > Handled-By : Arjan van de Ven <arjan-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> > > Patch :
> > > http://marc.info/?l=linux-kernel&m=123156441218358&w=4
> > > http://marc.info/?t=123156453100002&r=1&w=4
> > >
> > >
> >
> > the patches are in -mm waiting for gregkh to pick them up and push...
>
> Ok, I'm totally confused now, care to point out exactly which ones I
> should be picking up and pushing?
Patches from -mm called:
drivers-consolidate-driver_probe_done-loops-into-one-place.patch
drivers-consolidate-driver_probe_done-loops-into-one-place-checkpatch-fixes.patch
resume-wait-for-device-probing-to-finish.patch
drivers-consolidate-driver_probe_done-loops-into-one-place-fix.patch
in this order.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12501] build bug in eeepc-laptop.c
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Ingo Molnar, Matthew Garrett
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12501
Subject : build bug in eeepc-laptop.c
Submitter : Ingo Molnar <mingo@elte.hu>
Date : 2009-01-14 17:25 (26 days old)
References : http://lkml.org/lkml/2009/1/14/315
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12502] pipe_read oops on sh
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Adrian McMenamin
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12502
Subject : pipe_read oops on sh
Submitter : Adrian McMenamin <lkmladrian@gmail.com>
Date : 2009-01-15 9:48 (25 days old)
References : http://marc.info/?l=linux-kernel&m=123201298005600&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12503] [slab corruption] BUG key_jar: Poison overwritten
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, David Howells, Ingo Molnar, Vegard Nossum
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12503
Subject : [slab corruption] BUG key_jar: Poison overwritten
Submitter : Ingo Molnar <mingo@elte.hu>
Date : 2009-01-15 18:16 (25 days old)
References : http://marc.info/?l=linux-kernel&m=123204353425825&w=4
Handled-By : David Howells <dhowells@redhat.com>
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12503] [slab corruption] BUG key_jar: Poison overwritten
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, David Howells, Ingo Molnar, Vegard Nossum
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12503
Subject : [slab corruption] BUG key_jar: Poison overwritten
Submitter : Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
Date : 2009-01-15 18:16 (25 days old)
References : http://marc.info/?l=linux-kernel&m=123204353425825&w=4
Handled-By : David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12503] [slab corruption] BUG key_jar: Poison overwritten
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-08 22:12 ` Ingo Molnar
-1 siblings, 0 replies; 219+ messages in thread
From: Ingo Molnar @ 2009-02-08 22:12 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, David Howells,
Vegard Nossum
* Rafael J. Wysocki <rjw@sisk.pl> wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12503
> Subject : [slab corruption] BUG key_jar: Poison overwritten
> Submitter : Ingo Molnar <mingo@elte.hu>
> Date : 2009-01-15 18:16 (25 days old)
> References : http://marc.info/?l=linux-kernel&m=123204353425825&w=4
> Handled-By : David Howells <dhowells@redhat.com>
This slab corruption has not triggered again. It's either a very rare thing (in
which case there's no realistic way to debug it via this angle), or it got fixed
meanwhile.
Please close it. Thanks,
Ingo
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12503] [slab corruption] BUG key_jar: Poison overwritten
@ 2009-02-08 22:12 ` Ingo Molnar
0 siblings, 0 replies; 219+ messages in thread
From: Ingo Molnar @ 2009-02-08 22:12 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, David Howells,
Vegard Nossum
* Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12503
> Subject : [slab corruption] BUG key_jar: Poison overwritten
> Submitter : Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
> Date : 2009-01-15 18:16 (25 days old)
> References : http://marc.info/?l=linux-kernel&m=123204353425825&w=4
> Handled-By : David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
This slab corruption has not triggered again. It's either a very rare thing (in
which case there's no realistic way to debug it via this angle), or it got fixed
meanwhile.
Please close it. Thanks,
Ingo
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12503] [slab corruption] BUG key_jar: Poison overwritten
@ 2009-02-09 0:40 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-09 0:40 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linux Kernel Mailing List, Kernel Testers List, David Howells,
Vegard Nossum
On Sunday 08 February 2009, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <rjw@sisk.pl> wrote:
>
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12503
> > Subject : [slab corruption] BUG key_jar: Poison overwritten
> > Submitter : Ingo Molnar <mingo@elte.hu>
> > Date : 2009-01-15 18:16 (25 days old)
> > References : http://marc.info/?l=linux-kernel&m=123204353425825&w=4
> > Handled-By : David Howells <dhowells@redhat.com>
>
> This slab corruption has not triggered again. It's either a very rare thing (in
> which case there's no realistic way to debug it via this angle), or it got fixed
> meanwhile.
>
> Please close it. Thanks,
Closed as "unreproducible".
Thanks,
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12503] [slab corruption] BUG key_jar: Poison overwritten
@ 2009-02-09 0:40 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-09 0:40 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linux Kernel Mailing List, Kernel Testers List, David Howells,
Vegard Nossum
On Sunday 08 February 2009, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
>
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12503
> > Subject : [slab corruption] BUG key_jar: Poison overwritten
> > Submitter : Ingo Molnar <mingo-X9Un+BFzKDI@public.gmane.org>
> > Date : 2009-01-15 18:16 (25 days old)
> > References : http://marc.info/?l=linux-kernel&m=123204353425825&w=4
> > Handled-By : David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>
> This slab corruption has not triggered again. It's either a very rare thing (in
> which case there's no realistic way to debug it via this angle), or it got fixed
> meanwhile.
>
> Please close it. Thanks,
Closed as "unreproducible".
Thanks,
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12499] Problem with using bluetooth adaper connected to usb port
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Maciej Rutecki
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12499
Subject : Problem with using bluetooth adaper connected to usb port
Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
Date : 2009-01-13 18:34 (27 days old)
References : http://marc.info/?l=linux-kernel&m=123187185426236&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12571] Suspend-resume on Dell Latitude D410 newly broken in 2.6.29-rc*
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Ross Boswell
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12571
Subject : Suspend-resume on Dell Latitude D410 newly broken in 2.6.29-rc*
Submitter : Ross Boswell <drb@med.co.nz>
Date : 2009-01-29 03:46 (11 days old)
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12571] Suspend-resume on Dell Latitude D410 newly broken in 2.6.29-rc*
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Ross Boswell
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12571
Subject : Suspend-resume on Dell Latitude D410 newly broken in 2.6.29-rc*
Submitter : Ross Boswell <drb-KpQn0vuWxAmlVyrhU4qvOw@public.gmane.org>
Date : 2009-01-29 03:46 (11 days old)
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12508] "powerpc/pci: Reserve legacy regions on PCI" broke my G3
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Benjamin Herrenschmidt, Mikael Pettersson
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12508
Subject : "powerpc/pci: Reserve legacy regions on PCI" broke my G3
Submitter : Mikael Pettersson <mikpe@it.uu.se>
Date : 2009-01-17 22:46 (23 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c1f343028d35ba4e88cd4a3c44e0d8b8a84264ee
References : http://marc.info/?l=linux-kernel&m=123223247325452&w=4
Handled-By : Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12508] "powerpc/pci: Reserve legacy regions on PCI" broke my G3
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Benjamin Herrenschmidt, Mikael Pettersson
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12508
Subject : "powerpc/pci: Reserve legacy regions on PCI" broke my G3
Submitter : Mikael Pettersson <mikpe-1zs4UD6AkMk@public.gmane.org>
Date : 2009-01-17 22:46 (23 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c1f343028d35ba4e88cd4a3c44e0d8b8a84264ee
References : http://marc.info/?l=linux-kernel&m=123223247325452&w=4
Handled-By : Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12508] "powerpc/pci: Reserve legacy regions on PCI" broke my G3
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-08 23:38 ` Mikael Pettersson
-1 siblings, 0 replies; 219+ messages in thread
From: Mikael Pettersson @ 2009-02-08 23:38 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List,
Benjamin Herrenschmidt, Mikael Pettersson
Rafael J. Wysocki wrote:
>This message has been generated automatically as a part of a report
>of recent regressions.
>
>The following bug entry is on the current list of known regressions
>from 2.6.28. Please verify if it still should be listed and let me know
>(either way).
>
>
>Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=3D12508
>Subject : "powerpc/pci: Reserve legacy regions on PCI" broke my G3
>Submitter : Mikael Pettersson <mikpe@it.uu.se>
>Date : 2009-01-17 22:46 (23 days old)
>First-Bad-Commit: http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linu=
>x-2.6.git;a=3Dcommit;h=3Dc1f343028d35ba4e88cd4a3c44e0d8b8a84264ee
>References : http://marc.info/?l=3Dlinux-kernel&m=3D123223247325452&w=3D4
>Handled-By : Benjamin Herrenschmidt <benh@kernel.crashing.org>
Fixed in 2.6.29-rc4.
See <http://marc.info/?l=linux-kernel&m=123394660404763&w=2> (you were CC:d).
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12508] "powerpc/pci: Reserve legacy regions on PCI" broke my G3
@ 2009-02-08 23:38 ` Mikael Pettersson
0 siblings, 0 replies; 219+ messages in thread
From: Mikael Pettersson @ 2009-02-08 23:38 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List,
Benjamin Herrenschmidt, Mikael Pettersson
Rafael J. Wysocki wrote:
>This message has been generated automatically as a part of a report
>of recent regressions.
>
>The following bug entry is on the current list of known regressions
>from 2.6.28. Please verify if it still should be listed and let me know
>(either way).
>
>
>Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=3D12508
>Subject : "powerpc/pci: Reserve legacy regions on PCI" broke my G3
>Submitter : Mikael Pettersson <mikpe-1zs4UD6AkMk@public.gmane.org>
>Date : 2009-01-17 22:46 (23 days old)
>First-Bad-Commit: http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linu=
>x-2.6.git;a=3Dcommit;h=3Dc1f343028d35ba4e88cd4a3c44e0d8b8a84264ee
>References : http://marc.info/?l=3Dlinux-kernel&m=3D123223247325452&w=3D4
>Handled-By : Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Fixed in 2.6.29-rc4.
See <http://marc.info/?l=linux-kernel&m=123394660404763&w=2> (you were CC:d).
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12508] "powerpc/pci: Reserve legacy regions on PCI" broke my G3
@ 2009-02-09 0:39 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-09 0:39 UTC (permalink / raw)
To: Mikael Pettersson
Cc: Linux Kernel Mailing List, Kernel Testers List, Benjamin Herrenschmidt
On Monday 09 February 2009, Mikael Pettersson wrote:
> Rafael J. Wysocki wrote:
> >This message has been generated automatically as a part of a report
> >of recent regressions.
> >
> >The following bug entry is on the current list of known regressions
> >from 2.6.28. Please verify if it still should be listed and let me know
> >(either way).
> >
> >
> >Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=3D12508
> >Subject : "powerpc/pci: Reserve legacy regions on PCI" broke my G3
> >Submitter : Mikael Pettersson <mikpe@it.uu.se>
> >Date : 2009-01-17 22:46 (23 days old)
> >First-Bad-Commit: http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linu=
> >x-2.6.git;a=3Dcommit;h=3Dc1f343028d35ba4e88cd4a3c44e0d8b8a84264ee
> >References : http://marc.info/?l=3Dlinux-kernel&m=3D123223247325452&w=3D4
> >Handled-By : Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> Fixed in 2.6.29-rc4.
Thanks, closed.
> See <http://marc.info/?l=linux-kernel&m=123394660404763&w=2> (you were CC:d).
Yes, but I wasn't quite sure if that was a mainline commit or a commit from
the Ben's tree.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12510] 2.6.29-rc2 dies on startup
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Ferenc Wagner
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12510
Subject : 2.6.29-rc2 dies on startup
Submitter : Ferenc Wagner <wferi@niif.hu>
Date : 2009-01-19 12:53 (21 days old)
References : http://marc.info/?l=linux-kernel&m=123236969321703&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12551] end_request: I/O error, dev cciss/c0d0, sector 87435720
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Ralf Hildebrandt
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12551
Subject : end_request: I/O error, dev cciss/c0d0, sector 87435720
Submitter : Ralf Hildebrandt <ralf.hildebrandt@charite.de>
Date : 2009-01-27 06:51 (13 days old)
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12551] end_request: I/O error, dev cciss/c0d0, sector 87435720
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Ralf Hildebrandt
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12551
Subject : end_request: I/O error, dev cciss/c0d0, sector 87435720
Submitter : Ralf Hildebrandt <ralf.hildebrandt-jq1tPX9l7E6ELgA04lAiVw@public.gmane.org>
Date : 2009-01-27 06:51 (13 days old)
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12574] possible circular locking dependency detected
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Michael S. Tsirkin
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12574
Subject : possible circular locking dependency detected
Submitter : Michael S. Tsirkin <m.s.tsirkin@gmail.com>
Date : 2009-01-29 11:35 (11 days old)
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12574] possible circular locking dependency detected
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Michael S. Tsirkin
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12574
Subject : possible circular locking dependency detected
Submitter : Michael S. Tsirkin <m.s.tsirkin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-01-29 11:35 (11 days old)
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12574] possible circular locking dependency detected
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-09 13:59 ` Michael S. Tsirkin
-1 siblings, 0 replies; 219+ messages in thread
From: Michael S. Tsirkin @ 2009-02-09 13:59 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List
I have verified that this still occurs on 2.6.29-rc4.
On Sun, Feb 8, 2009 at 9:21 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12574
> Subject : possible circular locking dependency detected
> Submitter : Michael S. Tsirkin <m.s.tsirkin@gmail.com>
> Date : 2009-01-29 11:35 (11 days old)
>
>
>
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12574] possible circular locking dependency detected
@ 2009-02-09 13:59 ` Michael S. Tsirkin
0 siblings, 0 replies; 219+ messages in thread
From: Michael S. Tsirkin @ 2009-02-09 13:59 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List
I have verified that this still occurs on 2.6.29-rc4.
On Sun, Feb 8, 2009 at 9:21 PM, Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12574
> Subject : possible circular locking dependency detected
> Submitter : Michael S. Tsirkin <m.s.tsirkin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date : 2009-01-29 11:35 (11 days old)
>
>
>
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12574] possible circular locking dependency detected
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-10 22:37 ` Michael S. Tsirkin
-1 siblings, 0 replies; 219+ messages in thread
From: Michael S. Tsirkin @ 2009-02-10 22:37 UTC (permalink / raw)
To: Dave Airlie, dri-devel
Cc: Linux Kernel Mailing List, Kernel Testers List, Rafael J. Wysocki
Dave, dri guys,
Could you take a look at this circular dependency please (below)? I
observe it when suspending laptop with radeon drm loaded and with
lockdep enabled. It seems that the root of the problem is that
various vm ops such as drm_vm_open, drm_mmap) are called with mm
semaphore taken, and take dev->struct_mutex. On the other hand,
drm_rmmap_locked is called with dev->struct_mutex, and calls mtrr_del
which depends on mm semaphore indirectly.
What do you think?
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12574
Subject : possible circular locking dependency detected
Submitter : Michael S. Tsirkin <m.s.tsirkin@gmail.com>
Date : 2009-01-29 11:35 (11 days old)
/var/log/message dump below.
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.29-rc4-mst-debug #95
-------------------------------------------------------
sleep.sh/6730 is trying to acquire lock:
(&per_cpu(cpu_policy_rwsem, cpu)){----}, at: [<c02c0da1>] lock_policy_rwsem_write+0x31/0x70
but task is already holding lock:
(&cpu_hotplug.lock){--..}, at: [<c012d89a>] cpu_hotplug_begin+0x1a/0x50
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #6 (&cpu_hotplug.lock){--..}:
[<c0152221>] validate_chain+0xb51/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c0366c5d>] mutex_lock_nested+0x9d/0x2e0
[<c012d8fc>] get_online_cpus+0x2c/0x40
[<c010d96f>] mtrr_del_page+0x2f/0x160
[<c010dada>] mtrr_del+0x3a/0x50
[<f851a342>] drm_rmmap_locked+0xc2/0x180 [drm]
[<f8521d31>] drm_master_destroy+0x151/0x160 [drm]
[<c022a37c>] kref_put+0x2c/0x80
[<f8521af2>] drm_master_put+0x12/0x20 [drm]
[<f851dd1b>] drm_release+0x25b/0x4a0 [drm]
[<c019781d>] __fput+0xbd/0x1d0
[<c0197c09>] fput+0x19/0x20
[<c0194a47>] filp_close+0x47/0x70
[<c0194ada>] sys_close+0x6a/0xc0
[<c0103215>] sysenter_do_call+0x12/0x35
[<ffffffff>] 0xffffffff
-> #5 (&dev->struct_mutex){--..}:
[<c0152221>] validate_chain+0xb51/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c0366c5d>] mutex_lock_nested+0x9d/0x2e0
[<f8522add>] drm_vm_open+0x2d/0x50 [drm]
[<c012a397>] dup_mm+0x227/0x310
[<c012b22f>] copy_process+0xd7f/0x1020
[<c012b5e8>] do_fork+0x78/0x320
[<c01017ef>] sys_clone+0x2f/0x40
[<c0103215>] sysenter_do_call+0x12/0x35
[<ffffffff>] 0xffffffff
-> #4 (&mm->mmap_sem/1){--..}:
[<c0152221>] validate_chain+0xb51/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c01441e8>] down_write_nested+0x48/0x70
[<c012a238>] dup_mm+0xc8/0x310
[<c012b22f>] copy_process+0xd7f/0x1020
[<c012b5e8>] do_fork+0x78/0x320
[<c01017ef>] sys_clone+0x2f/0x40
[<c0103292>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
-> #3 (&mm->mmap_sem){----}:
[<c0152221>] validate_chain+0xb51/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c0183d73>] might_fault+0x73/0x90
[<c022f633>] copy_to_user+0x33/0x60
[<c01a3975>] filldir64+0xb5/0xe0
[<c01e0c2f>] sysfs_readdir+0x11f/0x1f0
[<c01a3b0d>] vfs_readdir+0x8d/0xb0
[<c01a3b99>] sys_getdents64+0x69/0xc0
[<c0103292>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
-> #2 (sysfs_mutex){--..}:
[<c0152221>] validate_chain+0xb51/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c0366c5d>] mutex_lock_nested+0x9d/0x2e0
[<c01e0f0c>] sysfs_addrm_start+0x2c/0xb0
[<c01e14a0>] create_dir+0x40/0x90
[<c01e1556>] sysfs_create_subdir+0x16/0x20
[<c01e2770>] internal_create_group+0x50/0x1a0
[<c01e28ec>] sysfs_create_group+0xc/0x10
[<f81674fc>] cpufreq_stat_notifier_policy+0x9c/0x230 [cpufreq_stats]
[<c036b007>] notifier_call_chain+0x37/0x80
[<c0144d24>] __blocking_notifier_call_chain+0x44/0x60
[<c0144d5a>] blocking_notifier_call_chain+0x1a/0x20
[<c02c0226>] __cpufreq_set_policy+0xd6/0x230
[<c02c14a8>] cpufreq_add_dev+0x4e8/0x6b0
[<c029d5a5>] sysdev_driver_register+0x75/0x130
[<c02bff55>] cpufreq_register_driver+0xb5/0x1c0
[<f808b0bd>] uinput_destroy_device+0x4d/0x60 [uinput]
[<c010111a>] do_one_initcall+0x2a/0x160
[<c015bdf5>] sys_init_module+0x85/0x1b0
[<c0103215>] sysenter_do_call+0x12/0x35
[<ffffffff>] 0xffffffff
-> #1 ((cpufreq_policy_notifier_list).rwsem){----}:
[<c0152221>] validate_chain+0xb51/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c0367441>] down_read+0x41/0x60
[<c0144d0a>] __blocking_notifier_call_chain+0x2a/0x60
[<c0144d5a>] blocking_notifier_call_chain+0x1a/0x20
[<c02c1165>] cpufreq_add_dev+0x1a5/0x6b0
[<c029d5a5>] sysdev_driver_register+0x75/0x130
[<c02bff55>] cpufreq_register_driver+0xb5/0x1c0
[<f808b0bd>] uinput_destroy_device+0x4d/0x60 [uinput]
[<c010111a>] do_one_initcall+0x2a/0x160
[<c015bdf5>] sys_init_module+0x85/0x1b0
[<c0103215>] sysenter_do_call+0x12/0x35
[<ffffffff>] 0xffffffff
-> #0 (&per_cpu(cpu_policy_rwsem, cpu)){----}:
[<c0151cbb>] validate_chain+0x5eb/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c03674a1>] down_write+0x41/0x60
[<c02c0da1>] lock_policy_rwsem_write+0x31/0x70
[<c03655a5>] cpufreq_cpu_callback+0x45/0x80
[<c036b007>] notifier_call_chain+0x37/0x80
[<c0144b49>] __raw_notifier_call_chain+0x19/0x20
[<c03574c9>] _cpu_down+0x79/0x280
[<c012da5c>] disable_nonboot_cpus+0x7c/0x100
[<c015cac5>] suspend_devices_and_enter+0xd5/0x170
[<c015cd40>] enter_state+0x1b0/0x1c0
[<c015cddf>] state_store+0x8f/0xd0
[<c0228cf4>] kobj_attr_store+0x24/0x30
[<c01e02d2>] sysfs_write_file+0xa2/0x100
[<c0196e89>] vfs_write+0x99/0x130
[<c01973cd>] sys_write+0x3d/0x70
[<c0103215>] sysenter_do_call+0x12/0x35
[<ffffffff>] 0xffffffff
other info that might help us debug this:
4 locks held by sleep.sh/6730:
#0: (&buffer->mutex){--..}, at: [<c01e025b>] sysfs_write_file+0x2b/0x100
#1: (pm_mutex){--..}, at: [<c015cbdb>] enter_state+0x4b/0x1c0
#2: (cpu_add_remove_lock){--..}, at: [<c012d83f>] cpu_maps_update_begin+0xf/0x20
#3: (&cpu_hotplug.lock){--..}, at: [<c012d89a>] cpu_hotplug_begin+0x1a/0x50
stack backtrace:
Pid: 6730, comm: sleep.sh Not tainted 2.6.29-rc4-mst-debug #95
Call Trace:
[<c015166c>] print_circular_bug_tail+0x7c/0xe0
[<c0151cbb>] validate_chain+0x5eb/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c013cf1e>] ? __cancel_work_timer+0x2e/0x190
[<c01532d0>] lock_acquire+0x60/0x80
[<c02c0da1>] ? lock_policy_rwsem_write+0x31/0x70
[<c03674a1>] down_write+0x41/0x60
[<c02c0da1>] ? lock_policy_rwsem_write+0x31/0x70
[<c02c0da1>] lock_policy_rwsem_write+0x31/0x70
[<c03655a5>] cpufreq_cpu_callback+0x45/0x80
[<c036b007>] notifier_call_chain+0x37/0x80
[<c0144b49>] __raw_notifier_call_chain+0x19/0x20
[<c03574c9>] _cpu_down+0x79/0x280
[<c012d83f>] ? cpu_maps_update_begin+0xf/0x20
[<c012da5c>] disable_nonboot_cpus+0x7c/0x100
[<c02531cb>] ? acpi_disable_all_gpes+0x25/0x2a
[<c015cac5>] suspend_devices_and_enter+0xd5/0x170
[<c015cd40>] enter_state+0x1b0/0x1c0
[<c015cddf>] state_store+0x8f/0xd0
[<c015cd50>] ? state_store+0x0/0xd0
[<c0228cf4>] kobj_attr_store+0x24/0x30
[<c01e02d2>] sysfs_write_file+0xa2/0x100
[<c0196e89>] vfs_write+0x99/0x130
[<c0103247>] ? sysenter_exit+0xf/0x18
[<c01e0230>] ? sysfs_write_file+0x0/0x100
[<c01973cd>] sys_write+0x3d/0x70
[<c0103215>] sysenter_do_call+0x12/0x35
--
MST
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12574] possible circular locking dependency detected
@ 2009-02-10 22:37 ` Michael S. Tsirkin
0 siblings, 0 replies; 219+ messages in thread
From: Michael S. Tsirkin @ 2009-02-10 22:37 UTC (permalink / raw)
To: Dave Airlie, dri-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Cc: Linux Kernel Mailing List, Kernel Testers List, Rafael J. Wysocki
Dave, dri guys,
Could you take a look at this circular dependency please (below)? I
observe it when suspending laptop with radeon drm loaded and with
lockdep enabled. It seems that the root of the problem is that
various vm ops such as drm_vm_open, drm_mmap) are called with mm
semaphore taken, and take dev->struct_mutex. On the other hand,
drm_rmmap_locked is called with dev->struct_mutex, and calls mtrr_del
which depends on mm semaphore indirectly.
What do you think?
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12574
Subject : possible circular locking dependency detected
Submitter : Michael S. Tsirkin <m.s.tsirkin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-01-29 11:35 (11 days old)
/var/log/message dump below.
=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.29-rc4-mst-debug #95
-------------------------------------------------------
sleep.sh/6730 is trying to acquire lock:
(&per_cpu(cpu_policy_rwsem, cpu)){----}, at: [<c02c0da1>] lock_policy_rwsem_write+0x31/0x70
but task is already holding lock:
(&cpu_hotplug.lock){--..}, at: [<c012d89a>] cpu_hotplug_begin+0x1a/0x50
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #6 (&cpu_hotplug.lock){--..}:
[<c0152221>] validate_chain+0xb51/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c0366c5d>] mutex_lock_nested+0x9d/0x2e0
[<c012d8fc>] get_online_cpus+0x2c/0x40
[<c010d96f>] mtrr_del_page+0x2f/0x160
[<c010dada>] mtrr_del+0x3a/0x50
[<f851a342>] drm_rmmap_locked+0xc2/0x180 [drm]
[<f8521d31>] drm_master_destroy+0x151/0x160 [drm]
[<c022a37c>] kref_put+0x2c/0x80
[<f8521af2>] drm_master_put+0x12/0x20 [drm]
[<f851dd1b>] drm_release+0x25b/0x4a0 [drm]
[<c019781d>] __fput+0xbd/0x1d0
[<c0197c09>] fput+0x19/0x20
[<c0194a47>] filp_close+0x47/0x70
[<c0194ada>] sys_close+0x6a/0xc0
[<c0103215>] sysenter_do_call+0x12/0x35
[<ffffffff>] 0xffffffff
-> #5 (&dev->struct_mutex){--..}:
[<c0152221>] validate_chain+0xb51/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c0366c5d>] mutex_lock_nested+0x9d/0x2e0
[<f8522add>] drm_vm_open+0x2d/0x50 [drm]
[<c012a397>] dup_mm+0x227/0x310
[<c012b22f>] copy_process+0xd7f/0x1020
[<c012b5e8>] do_fork+0x78/0x320
[<c01017ef>] sys_clone+0x2f/0x40
[<c0103215>] sysenter_do_call+0x12/0x35
[<ffffffff>] 0xffffffff
-> #4 (&mm->mmap_sem/1){--..}:
[<c0152221>] validate_chain+0xb51/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c01441e8>] down_write_nested+0x48/0x70
[<c012a238>] dup_mm+0xc8/0x310
[<c012b22f>] copy_process+0xd7f/0x1020
[<c012b5e8>] do_fork+0x78/0x320
[<c01017ef>] sys_clone+0x2f/0x40
[<c0103292>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
-> #3 (&mm->mmap_sem){----}:
[<c0152221>] validate_chain+0xb51/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c0183d73>] might_fault+0x73/0x90
[<c022f633>] copy_to_user+0x33/0x60
[<c01a3975>] filldir64+0xb5/0xe0
[<c01e0c2f>] sysfs_readdir+0x11f/0x1f0
[<c01a3b0d>] vfs_readdir+0x8d/0xb0
[<c01a3b99>] sys_getdents64+0x69/0xc0
[<c0103292>] syscall_call+0x7/0xb
[<ffffffff>] 0xffffffff
-> #2 (sysfs_mutex){--..}:
[<c0152221>] validate_chain+0xb51/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c0366c5d>] mutex_lock_nested+0x9d/0x2e0
[<c01e0f0c>] sysfs_addrm_start+0x2c/0xb0
[<c01e14a0>] create_dir+0x40/0x90
[<c01e1556>] sysfs_create_subdir+0x16/0x20
[<c01e2770>] internal_create_group+0x50/0x1a0
[<c01e28ec>] sysfs_create_group+0xc/0x10
[<f81674fc>] cpufreq_stat_notifier_policy+0x9c/0x230 [cpufreq_stats]
[<c036b007>] notifier_call_chain+0x37/0x80
[<c0144d24>] __blocking_notifier_call_chain+0x44/0x60
[<c0144d5a>] blocking_notifier_call_chain+0x1a/0x20
[<c02c0226>] __cpufreq_set_policy+0xd6/0x230
[<c02c14a8>] cpufreq_add_dev+0x4e8/0x6b0
[<c029d5a5>] sysdev_driver_register+0x75/0x130
[<c02bff55>] cpufreq_register_driver+0xb5/0x1c0
[<f808b0bd>] uinput_destroy_device+0x4d/0x60 [uinput]
[<c010111a>] do_one_initcall+0x2a/0x160
[<c015bdf5>] sys_init_module+0x85/0x1b0
[<c0103215>] sysenter_do_call+0x12/0x35
[<ffffffff>] 0xffffffff
-> #1 ((cpufreq_policy_notifier_list).rwsem){----}:
[<c0152221>] validate_chain+0xb51/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c0367441>] down_read+0x41/0x60
[<c0144d0a>] __blocking_notifier_call_chain+0x2a/0x60
[<c0144d5a>] blocking_notifier_call_chain+0x1a/0x20
[<c02c1165>] cpufreq_add_dev+0x1a5/0x6b0
[<c029d5a5>] sysdev_driver_register+0x75/0x130
[<c02bff55>] cpufreq_register_driver+0xb5/0x1c0
[<f808b0bd>] uinput_destroy_device+0x4d/0x60 [uinput]
[<c010111a>] do_one_initcall+0x2a/0x160
[<c015bdf5>] sys_init_module+0x85/0x1b0
[<c0103215>] sysenter_do_call+0x12/0x35
[<ffffffff>] 0xffffffff
-> #0 (&per_cpu(cpu_policy_rwsem, cpu)){----}:
[<c0151cbb>] validate_chain+0x5eb/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c01532d0>] lock_acquire+0x60/0x80
[<c03674a1>] down_write+0x41/0x60
[<c02c0da1>] lock_policy_rwsem_write+0x31/0x70
[<c03655a5>] cpufreq_cpu_callback+0x45/0x80
[<c036b007>] notifier_call_chain+0x37/0x80
[<c0144b49>] __raw_notifier_call_chain+0x19/0x20
[<c03574c9>] _cpu_down+0x79/0x280
[<c012da5c>] disable_nonboot_cpus+0x7c/0x100
[<c015cac5>] suspend_devices_and_enter+0xd5/0x170
[<c015cd40>] enter_state+0x1b0/0x1c0
[<c015cddf>] state_store+0x8f/0xd0
[<c0228cf4>] kobj_attr_store+0x24/0x30
[<c01e02d2>] sysfs_write_file+0xa2/0x100
[<c0196e89>] vfs_write+0x99/0x130
[<c01973cd>] sys_write+0x3d/0x70
[<c0103215>] sysenter_do_call+0x12/0x35
[<ffffffff>] 0xffffffff
other info that might help us debug this:
4 locks held by sleep.sh/6730:
#0: (&buffer->mutex){--..}, at: [<c01e025b>] sysfs_write_file+0x2b/0x100
#1: (pm_mutex){--..}, at: [<c015cbdb>] enter_state+0x4b/0x1c0
#2: (cpu_add_remove_lock){--..}, at: [<c012d83f>] cpu_maps_update_begin+0xf/0x20
#3: (&cpu_hotplug.lock){--..}, at: [<c012d89a>] cpu_hotplug_begin+0x1a/0x50
stack backtrace:
Pid: 6730, comm: sleep.sh Not tainted 2.6.29-rc4-mst-debug #95
Call Trace:
[<c015166c>] print_circular_bug_tail+0x7c/0xe0
[<c0151cbb>] validate_chain+0x5eb/0x1150
[<c0152a66>] __lock_acquire+0x246/0xa50
[<c013cf1e>] ? __cancel_work_timer+0x2e/0x190
[<c01532d0>] lock_acquire+0x60/0x80
[<c02c0da1>] ? lock_policy_rwsem_write+0x31/0x70
[<c03674a1>] down_write+0x41/0x60
[<c02c0da1>] ? lock_policy_rwsem_write+0x31/0x70
[<c02c0da1>] lock_policy_rwsem_write+0x31/0x70
[<c03655a5>] cpufreq_cpu_callback+0x45/0x80
[<c036b007>] notifier_call_chain+0x37/0x80
[<c0144b49>] __raw_notifier_call_chain+0x19/0x20
[<c03574c9>] _cpu_down+0x79/0x280
[<c012d83f>] ? cpu_maps_update_begin+0xf/0x20
[<c012da5c>] disable_nonboot_cpus+0x7c/0x100
[<c02531cb>] ? acpi_disable_all_gpes+0x25/0x2a
[<c015cac5>] suspend_devices_and_enter+0xd5/0x170
[<c015cd40>] enter_state+0x1b0/0x1c0
[<c015cddf>] state_store+0x8f/0xd0
[<c015cd50>] ? state_store+0x0/0xd0
[<c0228cf4>] kobj_attr_store+0x24/0x30
[<c01e02d2>] sysfs_write_file+0xa2/0x100
[<c0196e89>] vfs_write+0x99/0x130
[<c0103247>] ? sysenter_exit+0xf/0x18
[<c01e0230>] ? sysfs_write_file+0x0/0x100
[<c01973cd>] sys_write+0x3d/0x70
[<c0103215>] sysenter_do_call+0x12/0x35
--
MST
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12574] possible circular locking dependency detected
@ 2009-02-10 22:41 ` Eric Anholt
0 siblings, 0 replies; 219+ messages in thread
From: Eric Anholt @ 2009-02-10 22:41 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Dave Airlie, dri-devel, Linux Kernel Mailing List,
Kernel Testers List, Rafael J. Wysocki
[-- Attachment #1: Type: text/plain, Size: 936 bytes --]
On Wed, 2009-02-11 at 00:37 +0200, Michael S. Tsirkin wrote:
> Dave, dri guys,
> Could you take a look at this circular dependency please (below)? I
> observe it when suspending laptop with radeon drm loaded and with
> lockdep enabled. It seems that the root of the problem is that
> various vm ops such as drm_vm_open, drm_mmap) are called with mm
> semaphore taken, and take dev->struct_mutex. On the other hand,
> drm_rmmap_locked is called with dev->struct_mutex, and calls mtrr_del
> which depends on mm semaphore indirectly.
>
> What do you think?
Yes, there are real lock inversions now due to the GTT mmap code. It's
going to be a pain to fix (I tried getting the mmap_sem -> struct_mutex
path to go away, but the fact that mmap_sem is held over the fault
handler pretty much kills that). It's high on the list, though.
--
Eric Anholt
eric@anholt.net eric.anholt@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12574] possible circular locking dependency detected
@ 2009-02-10 22:41 ` Eric Anholt
0 siblings, 0 replies; 219+ messages in thread
From: Eric Anholt @ 2009-02-10 22:41 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Dave Airlie, dri-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Linux Kernel Mailing List, Kernel Testers List,
Rafael J. Wysocki
[-- Attachment #1: Type: text/plain, Size: 995 bytes --]
On Wed, 2009-02-11 at 00:37 +0200, Michael S. Tsirkin wrote:
> Dave, dri guys,
> Could you take a look at this circular dependency please (below)? I
> observe it when suspending laptop with radeon drm loaded and with
> lockdep enabled. It seems that the root of the problem is that
> various vm ops such as drm_vm_open, drm_mmap) are called with mm
> semaphore taken, and take dev->struct_mutex. On the other hand,
> drm_rmmap_locked is called with dev->struct_mutex, and calls mtrr_del
> which depends on mm semaphore indirectly.
>
> What do you think?
Yes, there are real lock inversions now due to the GTT mmap code. It's
going to be a pain to fix (I tried getting the mmap_sem -> struct_mutex
path to go away, but the fact that mmap_sem is held over the fault
handler pretty much kills that). It's high on the list, though.
--
Eric Anholt
eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org eric.anholt-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12574] possible circular locking dependency detected
2009-02-10 22:41 ` Eric Anholt
@ 2009-02-11 7:10 ` Thomas Hellström
-1 siblings, 0 replies; 219+ messages in thread
From: Thomas Hellström @ 2009-02-11 7:10 UTC (permalink / raw)
To: Eric Anholt
Cc: Michael S. Tsirkin, Dave Airlie, Rafael J. Wysocki, dri-devel,
Linux Kernel Mailing List, Kernel Testers List
Eric Anholt wrote:
> On Wed, 2009-02-11 at 00:37 +0200, Michael S. Tsirkin wrote:
>
>> Dave, dri guys,
>> Could you take a look at this circular dependency please (below)? I
>> observe it when suspending laptop with radeon drm loaded and with
>> lockdep enabled. It seems that the root of the problem is that
>> various vm ops such as drm_vm_open, drm_mmap) are called with mm
>> semaphore taken, and take dev->struct_mutex. On the other hand,
>> drm_rmmap_locked is called with dev->struct_mutex, and calls mtrr_del
>> which depends on mm semaphore indirectly.
>>
>> What do you think?
>>
>
> Yes, there are real lock inversions now due to the GTT mmap code. It's
> going to be a pain to fix (I tried getting the mmap_sem -> struct_mutex
> path to go away, but the fact that mmap_sem is held over the fault
> handler pretty much kills that). It's high on the list, though.
>
Shouldn't it be possible to relax this given that in the fault()
handler, the mmap_sem() is taken in read mode only. This means that it
should be deadlock-safe (but still a little ugly) to take the mmap_sem()
in read mode when the struct mutex is held.
Another quick way to fix potential deadlocks, would be to take the
struct mutex in the following way in fault():
if (!mutex_trylock(&dev->struct_mutex)) {
needs_resched();
return VM_FAULT_NOPAGE;
}
/Thomas
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> ------------------------------------------------------------------------
>
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12574] possible circular locking dependency detected
@ 2009-02-11 7:10 ` Thomas Hellström
0 siblings, 0 replies; 219+ messages in thread
From: Thomas Hellström @ 2009-02-11 7:10 UTC (permalink / raw)
To: Eric Anholt
Cc: Kernel Testers List, Dave Airlie, Michael S. Tsirkin,
Linux Kernel Mailing List, Rafael J. Wysocki, dri-devel
Eric Anholt wrote:
> On Wed, 2009-02-11 at 00:37 +0200, Michael S. Tsirkin wrote:
>
>> Dave, dri guys,
>> Could you take a look at this circular dependency please (below)? I
>> observe it when suspending laptop with radeon drm loaded and with
>> lockdep enabled. It seems that the root of the problem is that
>> various vm ops such as drm_vm_open, drm_mmap) are called with mm
>> semaphore taken, and take dev->struct_mutex. On the other hand,
>> drm_rmmap_locked is called with dev->struct_mutex, and calls mtrr_del
>> which depends on mm semaphore indirectly.
>>
>> What do you think?
>>
>
> Yes, there are real lock inversions now due to the GTT mmap code. It's
> going to be a pain to fix (I tried getting the mmap_sem -> struct_mutex
> path to go away, but the fact that mmap_sem is held over the fault
> handler pretty much kills that). It's high on the list, though.
>
Shouldn't it be possible to relax this given that in the fault()
handler, the mmap_sem() is taken in read mode only. This means that it
should be deadlock-safe (but still a little ugly) to take the mmap_sem()
in read mode when the struct mutex is held.
Another quick way to fix potential deadlocks, would be to take the
struct mutex in the following way in fault():
if (!mutex_trylock(&dev->struct_mutex)) {
needs_resched();
return VM_FAULT_NOPAGE;
}
/Thomas
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> ------------------------------------------------------------------------
>
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
--
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12600] i915 lockdep warning
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Bob Copeland, Brandeburg, Jesse
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12600
Subject : i915 lockdep warning
Submitter : Brandeburg, Jesse <jesse.brandeburg@intel.com>
Date : 2009-01-13 23:17 (27 days old)
References : http://marc.info/?l=linux-kernel&m=123188898423532&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12600] i915 lockdep warning
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Bob Copeland, Brandeburg, Jesse
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12600
Subject : i915 lockdep warning
Submitter : Brandeburg, Jesse <jesse.brandeburg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date : 2009-01-13 23:17 (27 days old)
References : http://marc.info/?l=linux-kernel&m=123188898423532&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12600] i915 lockdep warning
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-09 1:12 ` Roland Dreier
-1 siblings, 0 replies; 219+ messages in thread
From: Roland Dreier @ 2009-02-09 1:12 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Bob Copeland,
Brandeburg, Jesse
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12600
> Subject : i915 lockdep warning
> Submitter : Brandeburg, Jesse <jesse.brandeburg@intel.com>
> Date : 2009-01-13 23:17 (27 days old)
> References : http://marc.info/?l=linux-kernel&m=123188898423532&w=4
Looks like a dup of 12491 to me.
- R.
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12600] i915 lockdep warning
@ 2009-02-09 1:12 ` Roland Dreier
0 siblings, 0 replies; 219+ messages in thread
From: Roland Dreier @ 2009-02-09 1:12 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Bob Copeland,
Brandeburg, Jesse
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12600
> Subject : i915 lockdep warning
> Submitter : Brandeburg, Jesse <jesse.brandeburg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Date : 2009-01-13 23:17 (27 days old)
> References : http://marc.info/?l=linux-kernel&m=123188898423532&w=4
Looks like a dup of 12491 to me.
- R.
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12600] i915 lockdep warning
@ 2009-02-09 17:21 ` Bob Copeland
0 siblings, 0 replies; 219+ messages in thread
From: Bob Copeland @ 2009-02-09 17:21 UTC (permalink / raw)
To: Roland Dreier, Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Brandeburg, Jesse
On Sun, 08 Feb 2009 17:12:21 -0800, Roland Dreier wrote
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12600
> > Subject : i915 lockdep warning
> > Submitter : Brandeburg, Jesse <jesse.brandeburg@intel.com>
> > Date : 2009-01-13 23:17 (27 days old)
> > References : http://marc.info/?l=linux-kernel&m=123188898423532&w=4
>
> Looks like a dup of 12491 to me.
>
> - R.
I can also confirm that Roland's patch fixes it for me.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Andrew Morton, Jan Kara, Linus Torvalds,
Nick Piggin
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12604
Subject : Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
Submitter : Jan Kara <jack@suse.cz>
Date : 2009-01-30 1:23 (10 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=31a12666d8f0c22235297e1c1575f82061480029
References : http://marc.info/?l=linux-kernel&m=123327862901800&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Andrew Morton, Jan Kara, Linus Torvalds,
Nick Piggin
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12604
Subject : Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
Submitter : Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
Date : 2009-01-30 1:23 (10 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=31a12666d8f0c22235297e1c1575f82061480029
References : http://marc.info/?l=linux-kernel&m=123327862901800&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-10 16:28 ` Jan Kara
-1 siblings, 0 replies; 219+ messages in thread
From: Jan Kara @ 2009-02-10 16:28 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Andrew Morton,
Jan Kara, Linus Torvalds, Nick Piggin
On Sun 08-02-09 20:21:42, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
Yes, I've verified with latest git and the regression is still there.
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12604
> Subject : Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
> Submitter : Jan Kara <jack@suse.cz>
> Date : 2009-01-30 1:23 (10 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=31a12666d8f0c22235297e1c1575f82061480029
> References : http://marc.info/?l=linux-kernel&m=123327862901800&w=4
Honza
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
@ 2009-02-10 16:28 ` Jan Kara
0 siblings, 0 replies; 219+ messages in thread
From: Jan Kara @ 2009-02-10 16:28 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Andrew Morton,
Jan Kara, Linus Torvalds, Nick Piggin
On Sun 08-02-09 20:21:42, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
Yes, I've verified with latest git and the regression is still there.
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12604
> Subject : Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
> Submitter : Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
> Date : 2009-01-30 1:23 (10 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=31a12666d8f0c22235297e1c1575f82061480029
> References : http://marc.info/?l=linux-kernel&m=123327862901800&w=4
Honza
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
@ 2009-02-12 1:47 ` Nick Piggin
0 siblings, 0 replies; 219+ messages in thread
From: Nick Piggin @ 2009-02-12 1:47 UTC (permalink / raw)
To: Jan Kara
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, Linus Torvalds
On Tue, Feb 10, 2009 at 05:28:30PM +0100, Jan Kara wrote:
> On Sun 08-02-09 20:21:42, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> Yes, I've verified with latest git and the regression is still there.
I'm working on this FWIW...
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12604
> > Subject : Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
> > Submitter : Jan Kara <jack@suse.cz>
> > Date : 2009-01-30 1:23 (10 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=31a12666d8f0c22235297e1c1575f82061480029
> > References : http://marc.info/?l=linux-kernel&m=123327862901800&w=4
>
> Honza
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
@ 2009-02-12 1:47 ` Nick Piggin
0 siblings, 0 replies; 219+ messages in thread
From: Nick Piggin @ 2009-02-12 1:47 UTC (permalink / raw)
To: Jan Kara
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, Linus Torvalds
On Tue, Feb 10, 2009 at 05:28:30PM +0100, Jan Kara wrote:
> On Sun 08-02-09 20:21:42, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> Yes, I've verified with latest git and the regression is still there.
I'm working on this FWIW...
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12604
> > Subject : Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
> > Submitter : Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
> > Date : 2009-01-30 1:23 (10 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=31a12666d8f0c22235297e1c1575f82061480029
> > References : http://marc.info/?l=linux-kernel&m=123327862901800&w=4
>
> Honza
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
@ 2009-02-12 2:02 ` Linus Torvalds
0 siblings, 0 replies; 219+ messages in thread
From: Linus Torvalds @ 2009-02-12 2:02 UTC (permalink / raw)
To: Nick Piggin
Cc: Jan Kara, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, Federico Cuello,
Artem Bityutskiy
On Thu, 12 Feb 2009, Nick Piggin wrote:
> On Tue, Feb 10, 2009 at 05:28:30PM +0100, Jan Kara wrote:
> > On Sun 08-02-09 20:21:42, Rafael J. Wysocki wrote:
> > > This message has been generated automatically as a part of a report
> > > of recent regressions.
> > >
> > > The following bug entry is on the current list of known regressions
> > > from 2.6.28. Please verify if it still should be listed and let me know
> > > (either way).
> > Yes, I've verified with latest git and the regression is still there.
>
> I'm working on this FWIW...
Shouldn't we just revert it? The code does look to be broken.
It also looks like the interaction with that ever-buggy "nr_to_write"
thing are totally wrong. I can see that whole
if (!cycled) {
..
index = 0;
goto retry
}
doing all the wrong things: if we ever hit the combination of
"!cycled + nr_to-write==0", we're always screwed. It simply _cannot_ do
the right thing.
I dunno. That whole piece-of-sh*t function has been incredibly buggy this
release. The code is an unreadable mess, and I think that "cyclic" stuff
is part of the reason for it being messy and buggy. Please convince me
it's worth saving, or let me revert the whole stinking pile of crud?
Please?
Linus
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
@ 2009-02-12 2:02 ` Linus Torvalds
0 siblings, 0 replies; 219+ messages in thread
From: Linus Torvalds @ 2009-02-12 2:02 UTC (permalink / raw)
To: Nick Piggin
Cc: Jan Kara, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, Federico Cuello,
Artem Bityutskiy
On Thu, 12 Feb 2009, Nick Piggin wrote:
> On Tue, Feb 10, 2009 at 05:28:30PM +0100, Jan Kara wrote:
> > On Sun 08-02-09 20:21:42, Rafael J. Wysocki wrote:
> > > This message has been generated automatically as a part of a report
> > > of recent regressions.
> > >
> > > The following bug entry is on the current list of known regressions
> > > from 2.6.28. Please verify if it still should be listed and let me know
> > > (either way).
> > Yes, I've verified with latest git and the regression is still there.
>
> I'm working on this FWIW...
Shouldn't we just revert it? The code does look to be broken.
It also looks like the interaction with that ever-buggy "nr_to_write"
thing are totally wrong. I can see that whole
if (!cycled) {
..
index = 0;
goto retry
}
doing all the wrong things: if we ever hit the combination of
"!cycled + nr_to-write==0", we're always screwed. It simply _cannot_ do
the right thing.
I dunno. That whole piece-of-sh*t function has been incredibly buggy this
release. The code is an unreadable mess, and I think that "cyclic" stuff
is part of the reason for it being messy and buggy. Please convince me
it's worth saving, or let me revert the whole stinking pile of crud?
Please?
Linus
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
@ 2009-02-12 3:34 ` Nick Piggin
0 siblings, 0 replies; 219+ messages in thread
From: Nick Piggin @ 2009-02-12 3:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jan Kara, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, Federico Cuello,
Artem Bityutskiy
On Wed, Feb 11, 2009 at 06:02:19PM -0800, Linus Torvalds wrote:
>
>
> On Thu, 12 Feb 2009, Nick Piggin wrote:
>
> > On Tue, Feb 10, 2009 at 05:28:30PM +0100, Jan Kara wrote:
> > > On Sun 08-02-09 20:21:42, Rafael J. Wysocki wrote:
> > > > This message has been generated automatically as a part of a report
> > > > of recent regressions.
> > > >
> > > > The following bug entry is on the current list of known regressions
> > > > from 2.6.28. Please verify if it still should be listed and let me know
> > > > (either way).
> > > Yes, I've verified with latest git and the regression is still there.
> >
> > I'm working on this FWIW...
>
> Shouldn't we just revert it? The code does look to be broken.
>
> It also looks like the interaction with that ever-buggy "nr_to_write"
> thing are totally wrong. I can see that whole
>
> if (!cycled) {
> ..
> index = 0;
> goto retry
> }
>
> doing all the wrong things: if we ever hit the combination of
> "!cycled + nr_to-write==0", we're always screwed. It simply _cannot_ do
> the right thing.
Doh, I think you spotted the bug. I was going off on the wrong track.
> I dunno. That whole piece-of-sh*t function has been incredibly buggy this
> release. The code is an unreadable mess, and I think that "cyclic" stuff
> is part of the reason for it being messy and buggy. Please convince me
> it's worth saving, or let me revert the whole stinking pile of crud?
Well... the cyclic stuff apparently gets used by some filesystems to do
data integrity stuff, so I think the problem addressed by my broken
commit maybe shouldn't be ignored.
Maybe you're being harsh on this function. It has been two thinko bugs
so far. Before this release cycle it seemed to have the record for the
most data integrity bugs in a single function...
How's this? Jan, can you test with the bdb workload please?
--
A bug was introduced into write_cache_pages cyclic writeout by commit
31a12666d8f0c22235297e1c1575f82061480029. The intention (and comments)
is that we should cycle back and look for more dirty pages at the
beginning of the file if there is no more work to be done.
But the !done condition was dropped from the test. This means that any
time the page writeout loop breaks (eg. due to nr_to_write == 0), we
will set index to 0, then goto again. This will set done_index to index,
then find done is set, so will proceed to the end of the function. When
updating mapping->writeback_index for cyclic writeout, we now use
done_index == 0, so we're always cycling back to 0.
This seemed to be causing random mmap writes (slapadd and iozone) to
start writing more pages from the LRU and writeout would slowdown.
With this patch, iozone random write performance is increased nearly
5x on my system (iozone -B -r 4k -s 64k -s 512m -s 1200m on ext2).
Signed-off-by: Nick Piggin <npiggin@suse.de>
---
Index: linux-2.6/mm/page-writeback.c
===================================================================
--- linux-2.6.orig/mm/page-writeback.c 2009-02-12 13:30:42.000000000 +1100
+++ linux-2.6/mm/page-writeback.c 2009-02-12 14:16:28.000000000 +1100
@@ -1079,7 +1079,7 @@ continue_unlock:
pagevec_release(&pvec);
cond_resched();
}
- if (!cycled) {
+ if (!cycled && !done) {
/*
* range_cyclic:
* We hit the last page and there is more work to be done: wrap
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
@ 2009-02-12 3:34 ` Nick Piggin
0 siblings, 0 replies; 219+ messages in thread
From: Nick Piggin @ 2009-02-12 3:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jan Kara, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, Federico Cuello,
Artem Bityutskiy
On Wed, Feb 11, 2009 at 06:02:19PM -0800, Linus Torvalds wrote:
>
>
> On Thu, 12 Feb 2009, Nick Piggin wrote:
>
> > On Tue, Feb 10, 2009 at 05:28:30PM +0100, Jan Kara wrote:
> > > On Sun 08-02-09 20:21:42, Rafael J. Wysocki wrote:
> > > > This message has been generated automatically as a part of a report
> > > > of recent regressions.
> > > >
> > > > The following bug entry is on the current list of known regressions
> > > > from 2.6.28. Please verify if it still should be listed and let me know
> > > > (either way).
> > > Yes, I've verified with latest git and the regression is still there.
> >
> > I'm working on this FWIW...
>
> Shouldn't we just revert it? The code does look to be broken.
>
> It also looks like the interaction with that ever-buggy "nr_to_write"
> thing are totally wrong. I can see that whole
>
> if (!cycled) {
> ..
> index = 0;
> goto retry
> }
>
> doing all the wrong things: if we ever hit the combination of
> "!cycled + nr_to-write==0", we're always screwed. It simply _cannot_ do
> the right thing.
Doh, I think you spotted the bug. I was going off on the wrong track.
> I dunno. That whole piece-of-sh*t function has been incredibly buggy this
> release. The code is an unreadable mess, and I think that "cyclic" stuff
> is part of the reason for it being messy and buggy. Please convince me
> it's worth saving, or let me revert the whole stinking pile of crud?
Well... the cyclic stuff apparently gets used by some filesystems to do
data integrity stuff, so I think the problem addressed by my broken
commit maybe shouldn't be ignored.
Maybe you're being harsh on this function. It has been two thinko bugs
so far. Before this release cycle it seemed to have the record for the
most data integrity bugs in a single function...
How's this? Jan, can you test with the bdb workload please?
--
A bug was introduced into write_cache_pages cyclic writeout by commit
31a12666d8f0c22235297e1c1575f82061480029. The intention (and comments)
is that we should cycle back and look for more dirty pages at the
beginning of the file if there is no more work to be done.
But the !done condition was dropped from the test. This means that any
time the page writeout loop breaks (eg. due to nr_to_write == 0), we
will set index to 0, then goto again. This will set done_index to index,
then find done is set, so will proceed to the end of the function. When
updating mapping->writeback_index for cyclic writeout, we now use
done_index == 0, so we're always cycling back to 0.
This seemed to be causing random mmap writes (slapadd and iozone) to
start writing more pages from the LRU and writeout would slowdown.
With this patch, iozone random write performance is increased nearly
5x on my system (iozone -B -r 4k -s 64k -s 512m -s 1200m on ext2).
Signed-off-by: Nick Piggin <npiggin-l3A5Bk7waGM@public.gmane.org>
---
Index: linux-2.6/mm/page-writeback.c
===================================================================
--- linux-2.6.orig/mm/page-writeback.c 2009-02-12 13:30:42.000000000 +1100
+++ linux-2.6/mm/page-writeback.c 2009-02-12 14:16:28.000000000 +1100
@@ -1079,7 +1079,7 @@ continue_unlock:
pagevec_release(&pvec);
cond_resched();
}
- if (!cycled) {
+ if (!cycled && !done) {
/*
* range_cyclic:
* We hit the last page and there is more work to be done: wrap
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
@ 2009-02-12 14:32 ` Jan Kara
0 siblings, 0 replies; 219+ messages in thread
From: Jan Kara @ 2009-02-12 14:32 UTC (permalink / raw)
To: Nick Piggin
Cc: Linus Torvalds, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, Federico Cuello,
Artem Bityutskiy
On Thu 12-02-09 04:34:23, Nick Piggin wrote:
> On Wed, Feb 11, 2009 at 06:02:19PM -0800, Linus Torvalds wrote:
> >
> >
> > On Thu, 12 Feb 2009, Nick Piggin wrote:
> >
> > > On Tue, Feb 10, 2009 at 05:28:30PM +0100, Jan Kara wrote:
> > > > On Sun 08-02-09 20:21:42, Rafael J. Wysocki wrote:
> > > > > This message has been generated automatically as a part of a report
> > > > > of recent regressions.
> > > > >
> > > > > The following bug entry is on the current list of known regressions
> > > > > from 2.6.28. Please verify if it still should be listed and let me know
> > > > > (either way).
> > > > Yes, I've verified with latest git and the regression is still there.
> > >
> > > I'm working on this FWIW...
> >
> > Shouldn't we just revert it? The code does look to be broken.
> >
> > It also looks like the interaction with that ever-buggy "nr_to_write"
> > thing are totally wrong. I can see that whole
> >
> > if (!cycled) {
> > ..
> > index = 0;
> > goto retry
> > }
> >
> > doing all the wrong things: if we ever hit the combination of
> > "!cycled + nr_to-write==0", we're always screwed. It simply _cannot_ do
> > the right thing.
>
> Doh, I think you spotted the bug. I was going off on the wrong track.
>
>
> > I dunno. That whole piece-of-sh*t function has been incredibly buggy this
> > release. The code is an unreadable mess, and I think that "cyclic" stuff
> > is part of the reason for it being messy and buggy. Please convince me
> > it's worth saving, or let me revert the whole stinking pile of crud?
>
> Well... the cyclic stuff apparently gets used by some filesystems to do
> data integrity stuff, so I think the problem addressed by my broken
> commit maybe shouldn't be ignored.
>
> Maybe you're being harsh on this function. It has been two thinko bugs
> so far. Before this release cycle it seemed to have the record for the
> most data integrity bugs in a single function...
>
> How's this? Jan, can you test with the bdb workload please?
Yes, this patch returns write performance of BDB workload back to
original numbers. Thanks for the fix.
Honza
> --
>
> A bug was introduced into write_cache_pages cyclic writeout by commit
> 31a12666d8f0c22235297e1c1575f82061480029. The intention (and comments)
> is that we should cycle back and look for more dirty pages at the
> beginning of the file if there is no more work to be done.
>
> But the !done condition was dropped from the test. This means that any
> time the page writeout loop breaks (eg. due to nr_to_write == 0), we
> will set index to 0, then goto again. This will set done_index to index,
> then find done is set, so will proceed to the end of the function. When
> updating mapping->writeback_index for cyclic writeout, we now use
> done_index == 0, so we're always cycling back to 0.
>
> This seemed to be causing random mmap writes (slapadd and iozone) to
> start writing more pages from the LRU and writeout would slowdown.
>
> With this patch, iozone random write performance is increased nearly
> 5x on my system (iozone -B -r 4k -s 64k -s 512m -s 1200m on ext2).
>
> Signed-off-by: Nick Piggin <npiggin@suse.de>
> ---
> Index: linux-2.6/mm/page-writeback.c
> ===================================================================
> --- linux-2.6.orig/mm/page-writeback.c 2009-02-12 13:30:42.000000000 +1100
> +++ linux-2.6/mm/page-writeback.c 2009-02-12 14:16:28.000000000 +1100
> @@ -1079,7 +1079,7 @@ continue_unlock:
> pagevec_release(&pvec);
> cond_resched();
> }
> - if (!cycled) {
> + if (!cycled && !done) {
> /*
> * range_cyclic:
> * We hit the last page and there is more work to be done: wrap
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
@ 2009-02-12 14:32 ` Jan Kara
0 siblings, 0 replies; 219+ messages in thread
From: Jan Kara @ 2009-02-12 14:32 UTC (permalink / raw)
To: Nick Piggin
Cc: Linus Torvalds, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, Federico Cuello,
Artem Bityutskiy
On Thu 12-02-09 04:34:23, Nick Piggin wrote:
> On Wed, Feb 11, 2009 at 06:02:19PM -0800, Linus Torvalds wrote:
> >
> >
> > On Thu, 12 Feb 2009, Nick Piggin wrote:
> >
> > > On Tue, Feb 10, 2009 at 05:28:30PM +0100, Jan Kara wrote:
> > > > On Sun 08-02-09 20:21:42, Rafael J. Wysocki wrote:
> > > > > This message has been generated automatically as a part of a report
> > > > > of recent regressions.
> > > > >
> > > > > The following bug entry is on the current list of known regressions
> > > > > from 2.6.28. Please verify if it still should be listed and let me know
> > > > > (either way).
> > > > Yes, I've verified with latest git and the regression is still there.
> > >
> > > I'm working on this FWIW...
> >
> > Shouldn't we just revert it? The code does look to be broken.
> >
> > It also looks like the interaction with that ever-buggy "nr_to_write"
> > thing are totally wrong. I can see that whole
> >
> > if (!cycled) {
> > ..
> > index = 0;
> > goto retry
> > }
> >
> > doing all the wrong things: if we ever hit the combination of
> > "!cycled + nr_to-write==0", we're always screwed. It simply _cannot_ do
> > the right thing.
>
> Doh, I think you spotted the bug. I was going off on the wrong track.
>
>
> > I dunno. That whole piece-of-sh*t function has been incredibly buggy this
> > release. The code is an unreadable mess, and I think that "cyclic" stuff
> > is part of the reason for it being messy and buggy. Please convince me
> > it's worth saving, or let me revert the whole stinking pile of crud?
>
> Well... the cyclic stuff apparently gets used by some filesystems to do
> data integrity stuff, so I think the problem addressed by my broken
> commit maybe shouldn't be ignored.
>
> Maybe you're being harsh on this function. It has been two thinko bugs
> so far. Before this release cycle it seemed to have the record for the
> most data integrity bugs in a single function...
>
> How's this? Jan, can you test with the bdb workload please?
Yes, this patch returns write performance of BDB workload back to
original numbers. Thanks for the fix.
Honza
> --
>
> A bug was introduced into write_cache_pages cyclic writeout by commit
> 31a12666d8f0c22235297e1c1575f82061480029. The intention (and comments)
> is that we should cycle back and look for more dirty pages at the
> beginning of the file if there is no more work to be done.
>
> But the !done condition was dropped from the test. This means that any
> time the page writeout loop breaks (eg. due to nr_to_write == 0), we
> will set index to 0, then goto again. This will set done_index to index,
> then find done is set, so will proceed to the end of the function. When
> updating mapping->writeback_index for cyclic writeout, we now use
> done_index == 0, so we're always cycling back to 0.
>
> This seemed to be causing random mmap writes (slapadd and iozone) to
> start writing more pages from the LRU and writeout would slowdown.
>
> With this patch, iozone random write performance is increased nearly
> 5x on my system (iozone -B -r 4k -s 64k -s 512m -s 1200m on ext2).
>
> Signed-off-by: Nick Piggin <npiggin-l3A5Bk7waGM@public.gmane.org>
> ---
> Index: linux-2.6/mm/page-writeback.c
> ===================================================================
> --- linux-2.6.orig/mm/page-writeback.c 2009-02-12 13:30:42.000000000 +1100
> +++ linux-2.6/mm/page-writeback.c 2009-02-12 14:16:28.000000000 +1100
> @@ -1079,7 +1079,7 @@ continue_unlock:
> pagevec_release(&pvec);
> cond_resched();
> }
> - if (!cycled) {
> + if (!cycled && !done) {
> /*
> * range_cyclic:
> * We hit the last page and there is more work to be done: wrap
--
Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-14 14:29 ` Theodore Tso
-1 siblings, 0 replies; 219+ messages in thread
From: Theodore Tso @ 2009-02-14 14:29 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Andrew Morton,
Jan Kara, Linus Torvalds, Nick Piggin
On Sun, Feb 08, 2009 at 08:21:42PM +0100, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12604
> Subject : Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
> Submitter : Jan Kara <jack@suse.cz>
> Date : 2009-01-30 1:23 (10 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=31a12666d8f0c22235297e1c1575f82061480029
> References : http://marc.info/?l=linux-kernel&m=123327862901800&w=4
>
Note: this has been fixed in mainline as of 2.6.29-rc5, in commit
3a4c6800. So this bug can be closed now...
- Ted
P.S. One good thing about the commit 31a12666 was that made an
otherwise very hard to hit potential deadlock condition in ext4 very
easy to hit, and thus for us to detect and to fix. So, thanks. :-)
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
@ 2009-02-14 14:29 ` Theodore Tso
0 siblings, 0 replies; 219+ messages in thread
From: Theodore Tso @ 2009-02-14 14:29 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Andrew Morton,
Jan Kara, Linus Torvalds, Nick Piggin
On Sun, Feb 08, 2009 at 08:21:42PM +0100, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12604
> Subject : Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
> Submitter : Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
> Date : 2009-01-30 1:23 (10 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=31a12666d8f0c22235297e1c1575f82061480029
> References : http://marc.info/?l=linux-kernel&m=123327862901800&w=4
>
Note: this has been fixed in mainline as of 2.6.29-rc5, in commit
3a4c6800. So this bug can be closed now...
- Ted
P.S. One good thing about the commit 31a12666 was that made an
otherwise very hard to hit potential deadlock condition in ext4 very
easy to hit, and thus for us to detect and to fix. So, thanks. :-)
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
@ 2009-02-14 19:53 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-14 19:53 UTC (permalink / raw)
To: Theodore Tso
Cc: Linux Kernel Mailing List, Kernel Testers List, Andrew Morton,
Jan Kara, Linus Torvalds, Nick Piggin
On Saturday 14 February 2009, Theodore Tso wrote:
> On Sun, Feb 08, 2009 at 08:21:42PM +0100, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12604
> > Subject : Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
> > Submitter : Jan Kara <jack@suse.cz>
> > Date : 2009-01-30 1:23 (10 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=31a12666d8f0c22235297e1c1575f82061480029
> > References : http://marc.info/?l=linux-kernel&m=123327862901800&w=4
> >
>
> Note: this has been fixed in mainline as of 2.6.29-rc5, in commit
> 3a4c6800. So this bug can be closed now...
The bug has been closed already.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12604] Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
@ 2009-02-14 19:53 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-14 19:53 UTC (permalink / raw)
To: Theodore Tso
Cc: Linux Kernel Mailing List, Kernel Testers List, Andrew Morton,
Jan Kara, Linus Torvalds, Nick Piggin
On Saturday 14 February 2009, Theodore Tso wrote:
> On Sun, Feb 08, 2009 at 08:21:42PM +0100, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12604
> > Subject : Commit 31a12666d8f0c22235297e1c1575f82061480029 slows down Berkeley DB
> > Submitter : Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>
> > Date : 2009-01-30 1:23 (10 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=31a12666d8f0c22235297e1c1575f82061480029
> > References : http://marc.info/?l=linux-kernel&m=123327862901800&w=4
> >
>
> Note: this has been fixed in mainline as of 2.6.29-rc5, in commit
> 3a4c6800. So this bug can be closed now...
The bug has been closed already.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12610] sync-Regression in 2.6.28.2?
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Federico Cuello, Ralf Hildebrandt
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12610
Subject : sync-Regression in 2.6.28.2?
Submitter : Ralf Hildebrandt <Ralf.Hildebrandt@charite.de>
Date : 2009-01-27 9:35 (13 days old)
References : http://marc.info/?l=linux-kernel&m=123304977706620&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12606] fb_mmap: circular locking dependency on hibernation
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Andrea Righi, Andrey Borzenkov
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12606
Subject : fb_mmap: circular locking dependency on hibernation
Submitter : Andrey Borzenkov <arvidjaar@mail.ru>
Date : 2009-01-27 18:37 (13 days old)
References : http://marc.info/?l=linux-kernel&m=123308162731408&w=4
Handled-By : Andrea Righi <righi.andrea@gmail.com>
Patch : http://marc.info/?l=linux-kernel&m=123365581406194&w=2
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12606] fb_mmap: circular locking dependency on hibernation
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Andrea Righi, Andrey Borzenkov
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12606
Subject : fb_mmap: circular locking dependency on hibernation
Submitter : Andrey Borzenkov <arvidjaar-JGs/UdohzUI@public.gmane.org>
Date : 2009-01-27 18:37 (13 days old)
References : http://marc.info/?l=linux-kernel&m=123308162731408&w=4
Handled-By : Andrea Righi <righi.andrea-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Patch : http://marc.info/?l=linux-kernel&m=123365581406194&w=2
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12606] fb_mmap: circular locking dependency on hibernation
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-08 22:00 ` Andrea Righi
-1 siblings, 0 replies; 219+ messages in thread
From: Andrea Righi @ 2009-02-08 22:00 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Andrey Borzenkov
On 2009-02-08 20:21, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12606
> Subject : fb_mmap: circular locking dependency on hibernation
> Submitter : Andrey Borzenkov <arvidjaar@mail.ru>
> Date : 2009-01-27 18:37 (13 days old)
> References : http://marc.info/?l=linux-kernel&m=123308162731408&w=4
> Handled-By : Andrea Righi <righi.andrea@gmail.com>
> Patch : http://marc.info/?l=linux-kernel&m=123365581406194&w=2
This is fixed by:
commit 1f5e31d7e55ac7fbd4ec5e5b20c8868b0e4564c9
Author: Andrea Righi <righi.andrea@gmail.com>
Date: Wed Feb 4 15:12:03 2009 -0800
fbmem: don't call copy_from/to_user() with mutex held
Avoid calling copy_from/to_user() with fb_info->lock mutex held in fbmem
ioctl().
fb_mmap() is called under mm->mmap_sem (A) held, that also acquires
fb_info->lock (B); fb_ioctl() takes fb_info->lock (B) and does
copy_from/to_user() that might acquire mm->mmap_sem (A), causing a
deadlock.
NOTE: it doesn't push down the fb_info->lock in each own driver's
fb_ioctl(), so there are still potential deadlocks elsewhere.
Signed-off-by: Andrea Righi <righi.andrea@gmail.com>
Cc: Dave Jones <davej@redhat.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Johannes Weiner <hannes@saeurebad.de>
Cc: Krzysztof Helt <krzysztof.h1@wp.pl>
Cc: Harvey Harrison <harvey.harrison@gmail.com>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12606] fb_mmap: circular locking dependency on hibernation
@ 2009-02-08 22:00 ` Andrea Righi
0 siblings, 0 replies; 219+ messages in thread
From: Andrea Righi @ 2009-02-08 22:00 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Andrey Borzenkov
On 2009-02-08 20:21, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12606
> Subject : fb_mmap: circular locking dependency on hibernation
> Submitter : Andrey Borzenkov <arvidjaar-JGs/UdohzUI@public.gmane.org>
> Date : 2009-01-27 18:37 (13 days old)
> References : http://marc.info/?l=linux-kernel&m=123308162731408&w=4
> Handled-By : Andrea Righi <righi.andrea-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Patch : http://marc.info/?l=linux-kernel&m=123365581406194&w=2
This is fixed by:
commit 1f5e31d7e55ac7fbd4ec5e5b20c8868b0e4564c9
Author: Andrea Righi <righi.andrea-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Wed Feb 4 15:12:03 2009 -0800
fbmem: don't call copy_from/to_user() with mutex held
Avoid calling copy_from/to_user() with fb_info->lock mutex held in fbmem
ioctl().
fb_mmap() is called under mm->mmap_sem (A) held, that also acquires
fb_info->lock (B); fb_ioctl() takes fb_info->lock (B) and does
copy_from/to_user() that might acquire mm->mmap_sem (A), causing a
deadlock.
NOTE: it doesn't push down the fb_info->lock in each own driver's
fb_ioctl(), so there are still potential deadlocks elsewhere.
Signed-off-by: Andrea Righi <righi.andrea-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Dave Jones <davej-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org>
Cc: Johannes Weiner <hannes-BfM5BwqdGSkPyMaTEpOvjQ@public.gmane.org>
Cc: Krzysztof Helt <krzysztof.h1-5tc4TXWwyLM@public.gmane.org>
Cc: Harvey Harrison <harvey.harrison-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Stefan Richter <stefanr-MtYdepGKPcBMYopoZt5u/LNAH6kLmebB@public.gmane.org>
Signed-off-by: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Signed-off-by: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12606] fb_mmap: circular locking dependency on hibernation
@ 2009-02-08 22:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 22:06 UTC (permalink / raw)
To: righi.andrea
Cc: Linux Kernel Mailing List, Kernel Testers List, Andrey Borzenkov
On Sunday 08 February 2009, Andrea Righi wrote:
> On 2009-02-08 20:21, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12606
> > Subject : fb_mmap: circular locking dependency on hibernation
> > Submitter : Andrey Borzenkov <arvidjaar@mail.ru>
> > Date : 2009-01-27 18:37 (13 days old)
> > References : http://marc.info/?l=linux-kernel&m=123308162731408&w=4
> > Handled-By : Andrea Righi <righi.andrea@gmail.com>
> > Patch : http://marc.info/?l=linux-kernel&m=123365581406194&w=2
>
> This is fixed by:
>
> commit 1f5e31d7e55ac7fbd4ec5e5b20c8868b0e4564c9
> Author: Andrea Righi <righi.andrea@gmail.com>
> Date: Wed Feb 4 15:12:03 2009 -0800
>
> fbmem: don't call copy_from/to_user() with mutex held
Thanks, closed.
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12606] fb_mmap: circular locking dependency on hibernation
@ 2009-02-08 22:06 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 22:06 UTC (permalink / raw)
To: righi.andrea-Re5JQEeQqe8AvxtiuMwx3w
Cc: Linux Kernel Mailing List, Kernel Testers List, Andrey Borzenkov
On Sunday 08 February 2009, Andrea Righi wrote:
> On 2009-02-08 20:21, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12606
> > Subject : fb_mmap: circular locking dependency on hibernation
> > Submitter : Andrey Borzenkov <arvidjaar-JGs/UdohzUI@public.gmane.org>
> > Date : 2009-01-27 18:37 (13 days old)
> > References : http://marc.info/?l=linux-kernel&m=123308162731408&w=4
> > Handled-By : Andrea Righi <righi.andrea-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Patch : http://marc.info/?l=linux-kernel&m=123365581406194&w=2
>
> This is fixed by:
>
> commit 1f5e31d7e55ac7fbd4ec5e5b20c8868b0e4564c9
> Author: Andrea Righi <righi.andrea-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Wed Feb 4 15:12:03 2009 -0800
>
> fbmem: don't call copy_from/to_user() with mutex held
Thanks, closed.
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Benjamin Herrenschmidt, Hugh Dickins, Jesse Barnes
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12608
Subject : 2.6.29-rc powerpc G5 Xorg legacy_mem regression
Submitter : Hugh Dickins <hugh@veritas.com>
Date : 2009-01-21 21:12 (19 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d3a54014e2a94bd37b7dee5e76e03f7bc4fab49a
References : http://marc.info/?l=linux-kernel&m=123257250431870&w=4
Handled-By : Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Benjamin Herrenschmidt, Hugh Dickins, Jesse Barnes
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12608
Subject : 2.6.29-rc powerpc G5 Xorg legacy_mem regression
Submitter : Hugh Dickins <hugh-DTz5qymZ9yRBDgjK7y7TUQ@public.gmane.org>
Date : 2009-01-21 21:12 (19 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d3a54014e2a94bd37b7dee5e76e03f7bc4fab49a
References : http://marc.info/?l=linux-kernel&m=123257250431870&w=4
Handled-By : Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12608] 2.6.29-rc powerpc G5 Xorg legacy_mem regression
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-09 10:24 ` Hugh Dickins
-1 siblings, 0 replies; 219+ messages in thread
From: Hugh Dickins @ 2009-02-09 10:24 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List,
Benjamin Herrenschmidt, Jesse Barnes
On Sun, 8 Feb 2009, Rafael J. Wysocki wrote:
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12608
> Subject : 2.6.29-rc powerpc G5 Xorg legacy_mem regression
> Submitter : Hugh Dickins <hugh@veritas.com>
> Date : 2009-01-21 21:12 (19 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d3a54014e2a94bd37b7dee5e76e03f7bc4fab49a
> References : http://marc.info/?l=linux-kernel&m=123257250431870&w=4
> Handled-By : Benjamin Herrenschmidt <benh@kernel.crashing.org>
Please still list it for now, but I expect Ben's fix to be in -rc5.
Hugh
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12609] v2.6.29-rc2 libata sff 32bit PIO regression
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Alan Cox, Hugh Dickins, Larry Finger,
Mikael Pettersson, Sergei Shtylyov
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12609
Subject : v2.6.29-rc2 libata sff 32bit PIO regression
Submitter : Larry Finger <Larry.Finger@lwfinger.net>
Date : 2009-01-23 23:52 (17 days old)
References : http://marc.info/?l=linux-kernel&m=123275478111406&w=4
http://marc.info/?l=linux-kernel&m=123254501314058&w=4
Handled-By : Mikael Pettersson <mikpe@it.uu.se>
Hugh Dickins <hugh@veritas.com>
Sergei Shtylyov <sshtylyov@ru.mvista.com>
Patch : http://marc.info/?l=linux-kernel&m=123412278730735&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12609] v2.6.29-rc2 libata sff 32bit PIO regression
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Alan Cox, Hugh Dickins, Larry Finger,
Mikael Pettersson, Sergei Shtylyov
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12609
Subject : v2.6.29-rc2 libata sff 32bit PIO regression
Submitter : Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Date : 2009-01-23 23:52 (17 days old)
References : http://marc.info/?l=linux-kernel&m=123275478111406&w=4
http://marc.info/?l=linux-kernel&m=123254501314058&w=4
Handled-By : Mikael Pettersson <mikpe-1zs4UD6AkMk@public.gmane.org>
Hugh Dickins <hugh-DTz5qymZ9yRBDgjK7y7TUQ@public.gmane.org>
Sergei Shtylyov <sshtylyov-hkdhdckH98+B+jHODAdFcQ@public.gmane.org>
Patch : http://marc.info/?l=linux-kernel&m=123412278730735&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12609] v2.6.29-rc2 libata sff 32bit PIO regression
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-09 10:25 ` Hugh Dickins
-1 siblings, 0 replies; 219+ messages in thread
From: Hugh Dickins @ 2009-02-09 10:25 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Alan Cox,
Larry Finger, Mikael Pettersson, Sergei Shtylyov
On Sun, 8 Feb 2009, Rafael J. Wysocki wrote:
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12609
> Subject : v2.6.29-rc2 libata sff 32bit PIO regression
> Submitter : Larry Finger <Larry.Finger@lwfinger.net>
> Date : 2009-01-23 23:52 (17 days old)
> References : http://marc.info/?l=linux-kernel&m=123275478111406&w=4
> http://marc.info/?l=linux-kernel&m=123254501314058&w=4
> Handled-By : Mikael Pettersson <mikpe@it.uu.se>
> Hugh Dickins <hugh@veritas.com>
> Sergei Shtylyov <sshtylyov@ru.mvista.com>
> Patch : http://marc.info/?l=linux-kernel&m=123412278730735&w=4
Please still list it for now, but I expect Sergei's and Alan's fixes
to be in -rc5.
Hugh
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12615] boot hangs while bringing up gianfar ethernet
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Ira Snyder, Peter Korsgaard
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12615
Subject : boot hangs while bringing up gianfar ethernet
Submitter : Ira Snyder <iws@ovro.caltech.edu>
Date : 2009-01-29 19:41 (11 days old)
References : http://marc.info/?l=linux-kernel&m=123325817201665&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12617] unable to compile e100 firmware into kernel
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Andrey Borzenkov, David Woodhouse, Jesse Brandeburg
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12617
Subject : unable to compile e100 firmware into kernel
Submitter : Andrey Borzenkov <arvidjaar@mail.ru>
Date : 2009-01-31 15:59 (9 days old)
References : http://marc.info/?l=linux-kernel&m=123341764915181&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12613] [Suspend regression][DRM, RADEON]
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Dave Airlie, Dave Airlie, etienne,
Soeren Sonnenburg
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
Subject : [Suspend regression][DRM, RADEON]
Submitter : etienne <etienne.basset@numericable.fr>
Date : 2009-01-28 22:00 (12 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
http://marc.info/?l=linux-kernel&m=123334865404574&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12613] [Suspend regression][DRM, RADEON]
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Dave Airlie, Dave Airlie, etienne,
Soeren Sonnenburg
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
Subject : [Suspend regression][DRM, RADEON]
Submitter : etienne <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
Date : 2009-01-28 22:00 (12 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
http://marc.info/?l=linux-kernel&m=123334865404574&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12613] [Suspend regression][DRM, RADEON]
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-08 22:07 ` etienne
-1 siblings, 0 replies; 219+ messages in thread
From: etienne @ 2009-02-08 22:07 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Dave Airlie,
Dave Airlie, Soeren Sonnenburg
Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
> Subject : [Suspend regression][DRM, RADEON]
> Submitter : etienne <etienne.basset@numericable.fr>
> Date : 2009-01-28 22:00 (12 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
> References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
> http://marc.info/?l=linux-kernel&m=123334865404574&w=4
>
>
>
hello,
yes it's still present in -rc4
But I noticed that when I switch off KDE4.2 desktop effects, suspend to
ram is 100% reliable with 2.6.29-rc4
With 2.6.28, STR is 100% reliable with or without desktop effects
hope this helps,
Etienne
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12613] [Suspend regression][DRM, RADEON]
@ 2009-02-08 22:07 ` etienne
0 siblings, 0 replies; 219+ messages in thread
From: etienne @ 2009-02-08 22:07 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Dave Airlie,
Dave Airlie, Soeren Sonnenburg
Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
> Subject : [Suspend regression][DRM, RADEON]
> Submitter : etienne <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
> Date : 2009-01-28 22:00 (12 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
> References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
> http://marc.info/?l=linux-kernel&m=123334865404574&w=4
>
>
>
hello,
yes it's still present in -rc4
But I noticed that when I switch off KDE4.2 desktop effects, suspend to
ram is 100% reliable with 2.6.29-rc4
With 2.6.28, STR is 100% reliable with or without desktop effects
hope this helps,
Etienne
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12613] [Suspend regression][DRM, RADEON]
@ 2009-02-08 22:11 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 22:11 UTC (permalink / raw)
To: etienne
Cc: Linux Kernel Mailing List, Kernel Testers List, Dave Airlie,
Soeren Sonnenburg, Benjamin Herrenschmidt
On Sunday 08 February 2009, etienne wrote:
> Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
> > Subject : [Suspend regression][DRM, RADEON]
> > Submitter : etienne <etienne.basset@numericable.fr>
> > Date : 2009-01-28 22:00 (12 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
> > References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
> > http://marc.info/?l=linux-kernel&m=123334865404574&w=4
> >
> >
> >
> hello,
> yes it's still present in -rc4
> But I noticed that when I switch off KDE4.2 desktop effects, suspend to
> ram is 100% reliable with 2.6.29-rc4
> With 2.6.28, STR is 100% reliable with or without desktop effects
Thanks for the update.
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12613] [Suspend regression][DRM, RADEON]
@ 2009-02-08 22:11 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 22:11 UTC (permalink / raw)
To: etienne
Cc: Linux Kernel Mailing List, Kernel Testers List, Dave Airlie,
Soeren Sonnenburg, Benjamin Herrenschmidt
On Sunday 08 February 2009, etienne wrote:
> Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
> > Subject : [Suspend regression][DRM, RADEON]
> > Submitter : etienne <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
> > Date : 2009-01-28 22:00 (12 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
> > References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
> > http://marc.info/?l=linux-kernel&m=123334865404574&w=4
> >
> >
> >
> hello,
> yes it's still present in -rc4
> But I noticed that when I switch off KDE4.2 desktop effects, suspend to
> ram is 100% reliable with 2.6.29-rc4
> With 2.6.28, STR is 100% reliable with or without desktop effects
Thanks for the update.
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12613] [Suspend regression][DRM, RADEON]
@ 2009-02-09 2:26 ` Dave Airlie
0 siblings, 0 replies; 219+ messages in thread
From: Dave Airlie @ 2009-02-09 2:26 UTC (permalink / raw)
To: etienne
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Dave Airlie, Dave Airlie, Soeren Sonnenburg
On Mon, Feb 9, 2009 at 8:07 AM, etienne <etienne.basset@numericable.fr> wrote:
> Rafael J. Wysocki wrote:
>>
>> This message has been generated automatically as a part of a report
>> of recent regressions.
>>
>> The following bug entry is on the current list of known regressions
>> from 2.6.28. Please verify if it still should be listed and let me know
>> (either way).
>>
>>
>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
>> Subject : [Suspend regression][DRM, RADEON]
>> Submitter : etienne <etienne.basset@numericable.fr>
>> Date : 2009-01-28 22:00 (12 days old)
>> First-Bad-Commit:
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
>> References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
>> http://marc.info/?l=linux-kernel&m=123334865404574&w=4
>>
>>
>>
>
> hello,
> yes it's still present in -rc4
> But I noticed that when I switch off KDE4.2 desktop effects, suspend to ram
> is 100% reliable with 2.6.29-rc4
> With 2.6.28, STR is 100% reliable with or without desktop effects
>
Hi Etienne,
Can you try commenting out the calls to the radeon_suspend and
radeon_resume hooks in radeon_drv.c?
Dave.
> hope this helps,
> Etienne
>
>
>
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12613] [Suspend regression][DRM, RADEON]
@ 2009-02-09 2:26 ` Dave Airlie
0 siblings, 0 replies; 219+ messages in thread
From: Dave Airlie @ 2009-02-09 2:26 UTC (permalink / raw)
To: etienne
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Dave Airlie, Dave Airlie, Soeren Sonnenburg
On Mon, Feb 9, 2009 at 8:07 AM, etienne <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org> wrote:
> Rafael J. Wysocki wrote:
>>
>> This message has been generated automatically as a part of a report
>> of recent regressions.
>>
>> The following bug entry is on the current list of known regressions
>> from 2.6.28. Please verify if it still should be listed and let me know
>> (either way).
>>
>>
>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
>> Subject : [Suspend regression][DRM, RADEON]
>> Submitter : etienne <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
>> Date : 2009-01-28 22:00 (12 days old)
>> First-Bad-Commit:
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
>> References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
>> http://marc.info/?l=linux-kernel&m=123334865404574&w=4
>>
>>
>>
>
> hello,
> yes it's still present in -rc4
> But I noticed that when I switch off KDE4.2 desktop effects, suspend to ram
> is 100% reliable with 2.6.29-rc4
> With 2.6.28, STR is 100% reliable with or without desktop effects
>
Hi Etienne,
Can you try commenting out the calls to the radeon_suspend and
radeon_resume hooks in radeon_drv.c?
Dave.
> hope this helps,
> Etienne
>
>
>
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12613] [Suspend regression][DRM, RADEON]
@ 2009-02-09 18:08 ` etienne
0 siblings, 0 replies; 219+ messages in thread
From: etienne @ 2009-02-09 18:08 UTC (permalink / raw)
To: Dave Airlie
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Dave Airlie, Dave Airlie, Soeren Sonnenburg
Dave Airlie wrote:
> On Mon, Feb 9, 2009 at 8:07 AM, etienne <etienne.basset@numericable.fr> wrote:
>
>> Rafael J. Wysocki wrote:
>>
>>> This message has been generated automatically as a part of a report
>>> of recent regressions.
>>>
>>> The following bug entry is on the current list of known regressions
>>> from 2.6.28. Please verify if it still should be listed and let me know
>>> (either way).
>>>
>>>
>>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
>>> Subject : [Suspend regression][DRM, RADEON]
>>> Submitter : etienne <etienne.basset@numericable.fr>
>>> Date : 2009-01-28 22:00 (12 days old)
>>> First-Bad-Commit:
>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
>>> References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
>>> http://marc.info/?l=linux-kernel&m=123334865404574&w=4
>>>
>>>
>>>
>>>
>> hello,
>> yes it's still present in -rc4
>> But I noticed that when I switch off KDE4.2 desktop effects, suspend to ram
>> is 100% reliable with 2.6.29-rc4
>> With 2.6.28, STR is 100% reliable with or without desktop effects
>>
>>
>
> Hi Etienne,
>
> Can you try commenting out the calls to the radeon_suspend and
> radeon_resume hooks in radeon_drv.c?
>
> Dave.
>
Hi Dave,
I just tested that and I didn't change anything (cannot STR/resume with
desktop effect, STR/resume OK without desktop effects)
thanks,
Etienne
the patch i used, to verify i understood you ;)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon
index fef2078..805b367 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -90,8 +90,8 @@ static struct drm_driver driver = {
.postclose = radeon_driver_postclose,
.lastclose = radeon_driver_lastclose,
.unload = radeon_driver_unload,
- .suspend = radeon_suspend,
- .resume = radeon_resume,
+/* .suspend = radeon_suspend,
+ .resume = radeon_resume, */
.get_vblank_counter = radeon_get_vblank_counter,
.enable_vblank = radeon_enable_vblank,
.disable_vblank = radeon_disable_vblank,
^ permalink raw reply related [flat|nested] 219+ messages in thread
* Re: [Bug #12613] [Suspend regression][DRM, RADEON]
@ 2009-02-09 18:08 ` etienne
0 siblings, 0 replies; 219+ messages in thread
From: etienne @ 2009-02-09 18:08 UTC (permalink / raw)
To: Dave Airlie
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Dave Airlie, Dave Airlie, Soeren Sonnenburg
Dave Airlie wrote:
> On Mon, Feb 9, 2009 at 8:07 AM, etienne <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org> wrote:
>
>> Rafael J. Wysocki wrote:
>>
>>> This message has been generated automatically as a part of a report
>>> of recent regressions.
>>>
>>> The following bug entry is on the current list of known regressions
>>> from 2.6.28. Please verify if it still should be listed and let me know
>>> (either way).
>>>
>>>
>>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
>>> Subject : [Suspend regression][DRM, RADEON]
>>> Submitter : etienne <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
>>> Date : 2009-01-28 22:00 (12 days old)
>>> First-Bad-Commit:
>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
>>> References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
>>> http://marc.info/?l=linux-kernel&m=123334865404574&w=4
>>>
>>>
>>>
>>>
>> hello,
>> yes it's still present in -rc4
>> But I noticed that when I switch off KDE4.2 desktop effects, suspend to ram
>> is 100% reliable with 2.6.29-rc4
>> With 2.6.28, STR is 100% reliable with or without desktop effects
>>
>>
>
> Hi Etienne,
>
> Can you try commenting out the calls to the radeon_suspend and
> radeon_resume hooks in radeon_drv.c?
>
> Dave.
>
Hi Dave,
I just tested that and I didn't change anything (cannot STR/resume with
desktop effect, STR/resume OK without desktop effects)
thanks,
Etienne
the patch i used, to verify i understood you ;)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon
index fef2078..805b367 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -90,8 +90,8 @@ static struct drm_driver driver = {
.postclose = radeon_driver_postclose,
.lastclose = radeon_driver_lastclose,
.unload = radeon_driver_unload,
- .suspend = radeon_suspend,
- .resume = radeon_resume,
+/* .suspend = radeon_suspend,
+ .resume = radeon_resume, */
.get_vblank_counter = radeon_get_vblank_counter,
.enable_vblank = radeon_enable_vblank,
.disable_vblank = radeon_disable_vblank,
^ permalink raw reply related [flat|nested] 219+ messages in thread
* Re: [Bug #12613] [Suspend regression][DRM, RADEON]
@ 2009-02-09 19:31 ` etienne
0 siblings, 0 replies; 219+ messages in thread
From: etienne @ 2009-02-09 19:31 UTC (permalink / raw)
To: Dave Airlie
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Dave Airlie, Dave Airlie, Soeren Sonnenburg
Dave Airlie wrote:
> On Mon, Feb 9, 2009 at 8:07 AM, etienne <etienne.basset@numericable.fr> wrote:
>
>> Rafael J. Wysocki wrote:
>>
>>> This message has been generated automatically as a part of a report
>>> of recent regressions.
>>>
>>> The following bug entry is on the current list of known regressions
>>> from 2.6.28. Please verify if it still should be listed and let me know
>>> (either way).
>>>
>>>
>>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
>>> Subject : [Suspend regression][DRM, RADEON]
>>> Submitter : etienne <etienne.basset@numericable.fr>
>>> Date : 2009-01-28 22:00 (12 days old)
>>> First-Bad-Commit:
>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
>>> References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
>>> http://marc.info/?l=linux-kernel&m=123334865404574&w=4
>>>
>>>
>>>
>>>
>> hello,
>> yes it's still present in -rc4
>> But I noticed that when I switch off KDE4.2 desktop effects, suspend to ram
>> is 100% reliable with 2.6.29-rc4
>> With 2.6.28, STR is 100% reliable with or without desktop effects
>>
>>
>
> Hi Etienne,
>
> Can you try commenting out the calls to the radeon_suspend and
> radeon_resume hooks in radeon_drv.c?
>
> Dave.
>
Hi Dave,
I created the following "shot in the dark" patch that solves my problem!
I looked at the change between 2.6.28 and .29rc, and only the
radeon_cp.c:radeon_cp_init_ring_buffer changes stroke my eyes (cause
it's called by radeon_cp_resume indirectedly)
I don't understand what i did and how this works, but it works for me
regards
Etienne
Signed-off-by: etienne <etienne.basset@numericable.fr>
diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
b/drivers/gpu/drm/radeon/radeon_cp.c
index 63212d7..fc6e134
100644
---
a/drivers/gpu/drm/radeon/radeon_cp.c
+++
b/drivers/gpu/drm/radeon/radeon_cp.c
@@ -557,7 +557,8 @@ static int radeon_do_engine_reset(struct drm_device
* dev)
}
static void radeon_cp_init_ring_buffer(struct drm_device *
dev,
- drm_radeon_private_t *
dev_priv)
+ drm_radeon_private_t *
dev_priv,
+ struct drm_radeon_master_private
*master)
{
u32 ring_start,
cur_read_ptr;
u32
tmp;
@@ -668,13 +669,13 @@ static void radeon_cp_init_ring_buffer(struct
drm_device *
dev,
RADEON_WRITE(RADEON_BUS_CNTL,
tmp);
} /* PCIE cards appears to not need this
*/
- dev_priv->scratch[0] =
0;
+ master->sarea_priv->last_frame = dev_priv->scratch[0] = 0;
RADEON_WRITE(RADEON_LAST_FRAME_REG, 0);
- dev_priv->scratch[1] = 0;
+ master->sarea_priv->last_dispatch = dev_priv->scratch[1] = 0;
RADEON_WRITE(RADEON_LAST_DISPATCH_REG, 0);
- dev_priv->scratch[2] = 0;
+ master->sarea_priv->last_clear = dev_priv->scratch[2] = 0;
RADEON_WRITE(RADEON_LAST_CLEAR_REG, 0);
radeon_do_wait_for_idle(dev_priv);
@@ -1215,7 +1216,7 @@ static int radeon_do_init_cp(struct drm_device
*dev, drm_radeon_init_t *init,
}
radeon_cp_load_microcode(dev_priv);
- radeon_cp_init_ring_buffer(dev, dev_priv);
+ radeon_cp_init_ring_buffer(dev, dev_priv, master_priv);
dev_priv->last_buf = 0;
@@ -1281,9 +1282,11 @@ static int radeon_do_cleanup_cp(struct drm_device
* dev)
*
* Charl P. Botha <http://cpbotha.net>
*/
-static int radeon_do_resume_cp(struct drm_device * dev)
+static int radeon_do_resume_cp(struct drm_device * dev,
+ struct drm_file * file_priv)
{
drm_radeon_private_t *dev_priv = dev->dev_private;
+ struct drm_radeon_master_private * master_priv =
file_priv->master->driver_priv;
if (!dev_priv) {
DRM_ERROR("Called with no initialization\n");
@@ -1304,7 +1307,7 @@ static int radeon_do_resume_cp(struct drm_device *
dev)
}
radeon_cp_load_microcode(dev_priv);
- radeon_cp_init_ring_buffer(dev, dev_priv);
+ radeon_cp_init_ring_buffer(dev, dev_priv, master_priv);
radeon_do_engine_reset(dev);
radeon_irq_set_state(dev, RADEON_SW_INT_ENABLE, 1);
@@ -1480,7 +1483,7 @@ int radeon_cp_idle(struct drm_device *dev, void
*data, struct drm_file *file_pri
int radeon_cp_resume(struct drm_device *dev, void *data, struct
drm_file *file_priv)
{
- return radeon_do_resume_cp(dev);
+ return radeon_do_resume_cp(dev, file_priv);
}
int radeon_engine_reset(struct drm_device *dev, void *data, struct
drm_file *file_priv)
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12613] [Suspend regression][DRM, RADEON]
@ 2009-02-09 19:31 ` etienne
0 siblings, 0 replies; 219+ messages in thread
From: etienne @ 2009-02-09 19:31 UTC (permalink / raw)
To: Dave Airlie
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Dave Airlie, Dave Airlie, Soeren Sonnenburg
Dave Airlie wrote:
> On Mon, Feb 9, 2009 at 8:07 AM, etienne <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org> wrote:
>
>> Rafael J. Wysocki wrote:
>>
>>> This message has been generated automatically as a part of a report
>>> of recent regressions.
>>>
>>> The following bug entry is on the current list of known regressions
>>> from 2.6.28. Please verify if it still should be listed and let me know
>>> (either way).
>>>
>>>
>>> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
>>> Subject : [Suspend regression][DRM, RADEON]
>>> Submitter : etienne <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
>>> Date : 2009-01-28 22:00 (12 days old)
>>> First-Bad-Commit:
>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
>>> References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
>>> http://marc.info/?l=linux-kernel&m=123334865404574&w=4
>>>
>>>
>>>
>>>
>> hello,
>> yes it's still present in -rc4
>> But I noticed that when I switch off KDE4.2 desktop effects, suspend to ram
>> is 100% reliable with 2.6.29-rc4
>> With 2.6.28, STR is 100% reliable with or without desktop effects
>>
>>
>
> Hi Etienne,
>
> Can you try commenting out the calls to the radeon_suspend and
> radeon_resume hooks in radeon_drv.c?
>
> Dave.
>
Hi Dave,
I created the following "shot in the dark" patch that solves my problem!
I looked at the change between 2.6.28 and .29rc, and only the
radeon_cp.c:radeon_cp_init_ring_buffer changes stroke my eyes (cause
it's called by radeon_cp_resume indirectedly)
I don't understand what i did and how this works, but it works for me
regards
Etienne
Signed-off-by: etienne <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
b/drivers/gpu/drm/radeon/radeon_cp.c
index 63212d7..fc6e134
100644
---
a/drivers/gpu/drm/radeon/radeon_cp.c
+++
b/drivers/gpu/drm/radeon/radeon_cp.c
@@ -557,7 +557,8 @@ static int radeon_do_engine_reset(struct drm_device
* dev)
}
static void radeon_cp_init_ring_buffer(struct drm_device *
dev,
- drm_radeon_private_t *
dev_priv)
+ drm_radeon_private_t *
dev_priv,
+ struct drm_radeon_master_private
*master)
{
u32 ring_start,
cur_read_ptr;
u32
tmp;
@@ -668,13 +669,13 @@ static void radeon_cp_init_ring_buffer(struct
drm_device *
dev,
RADEON_WRITE(RADEON_BUS_CNTL,
tmp);
} /* PCIE cards appears to not need this
*/
- dev_priv->scratch[0] =
0;
+ master->sarea_priv->last_frame = dev_priv->scratch[0] = 0;
RADEON_WRITE(RADEON_LAST_FRAME_REG, 0);
- dev_priv->scratch[1] = 0;
+ master->sarea_priv->last_dispatch = dev_priv->scratch[1] = 0;
RADEON_WRITE(RADEON_LAST_DISPATCH_REG, 0);
- dev_priv->scratch[2] = 0;
+ master->sarea_priv->last_clear = dev_priv->scratch[2] = 0;
RADEON_WRITE(RADEON_LAST_CLEAR_REG, 0);
radeon_do_wait_for_idle(dev_priv);
@@ -1215,7 +1216,7 @@ static int radeon_do_init_cp(struct drm_device
*dev, drm_radeon_init_t *init,
}
radeon_cp_load_microcode(dev_priv);
- radeon_cp_init_ring_buffer(dev, dev_priv);
+ radeon_cp_init_ring_buffer(dev, dev_priv, master_priv);
dev_priv->last_buf = 0;
@@ -1281,9 +1282,11 @@ static int radeon_do_cleanup_cp(struct drm_device
* dev)
*
* Charl P. Botha <http://cpbotha.net>
*/
-static int radeon_do_resume_cp(struct drm_device * dev)
+static int radeon_do_resume_cp(struct drm_device * dev,
+ struct drm_file * file_priv)
{
drm_radeon_private_t *dev_priv = dev->dev_private;
+ struct drm_radeon_master_private * master_priv =
file_priv->master->driver_priv;
if (!dev_priv) {
DRM_ERROR("Called with no initialization\n");
@@ -1304,7 +1307,7 @@ static int radeon_do_resume_cp(struct drm_device *
dev)
}
radeon_cp_load_microcode(dev_priv);
- radeon_cp_init_ring_buffer(dev, dev_priv);
+ radeon_cp_init_ring_buffer(dev, dev_priv, master_priv);
radeon_do_engine_reset(dev);
radeon_irq_set_state(dev, RADEON_SW_INT_ENABLE, 1);
@@ -1480,7 +1483,7 @@ int radeon_cp_idle(struct drm_device *dev, void
*data, struct drm_file *file_pri
int radeon_cp_resume(struct drm_device *dev, void *data, struct
drm_file *file_priv)
{
- return radeon_do_resume_cp(dev);
+ return radeon_do_resume_cp(dev, file_priv);
}
int radeon_engine_reset(struct drm_device *dev, void *data, struct
drm_file *file_priv)
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12613] [Suspend regression][DRM, RADEON]
2009-02-08 22:07 ` etienne
@ 2009-02-09 5:50 ` Soeren Sonnenburg
-1 siblings, 0 replies; 219+ messages in thread
From: Soeren Sonnenburg @ 2009-02-09 5:50 UTC (permalink / raw)
To: etienne
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Dave Airlie, Dave Airlie
On Sun, 2009-02-08 at 23:07 +0100, etienne wrote:
> Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
> > Subject : [Suspend regression][DRM, RADEON]
> > Submitter : etienne <etienne.basset@numericable.fr>
> > Date : 2009-01-28 22:00 (12 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
> > References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
> > http://marc.info/?l=linux-kernel&m=123334865404574&w=4
> >
> >
> >
> hello,
> yes it's still present in -rc4
> But I noticed that when I switch off KDE4.2 desktop effects, suspend to
> ram is 100% reliable with 2.6.29-rc4
> With 2.6.28, STR is 100% reliable with or without desktop effects
For me it is reliable as soon as compositing/dri is disabled on 2.6.29.
On 2.6.28 it worked with compositing/dri *sometimes* - so 2.6.29 is the
first reliable kernel for me (when not using 3d).
Soeren
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12613] [Suspend regression][DRM, RADEON]
@ 2009-02-09 5:50 ` Soeren Sonnenburg
0 siblings, 0 replies; 219+ messages in thread
From: Soeren Sonnenburg @ 2009-02-09 5:50 UTC (permalink / raw)
To: etienne
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Dave Airlie, Dave Airlie
On Sun, 2009-02-08 at 23:07 +0100, etienne wrote:
> Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12613
> > Subject : [Suspend regression][DRM, RADEON]
> > Submitter : etienne <etienne.basset@numericable.fr>
> > Date : 2009-01-28 22:00 (12 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a9d51a5ad1154b5b20add1e8d30a5564f8aabbe9
> > References : http://marc.info/?l=linux-kernel&m=123318030419558&w=4
> > http://marc.info/?l=linux-kernel&m=123334865404574&w=4
> >
> >
> >
> hello,
> yes it's still present in -rc4
> But I noticed that when I switch off KDE4.2 desktop effects, suspend to
> ram is 100% reliable with 2.6.29-rc4
> With 2.6.28, STR is 100% reliable with or without desktop effects
For me it is reliable as soon as compositing/dri is disabled on 2.6.29.
On 2.6.28 it worked with compositing/dri *sometimes* - so 2.6.29 is the
first reliable kernel for me (when not using 3d).
Soeren
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12650] Strange load average and ksoftirqd behavior with 2.6.29-rc2-git1
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Damien Wyart
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12650
Subject : Strange load average and ksoftirqd behavior with 2.6.29-rc2-git1
Submitter : Damien Wyart <damien.wyart@free.fr>
Date : 2009-01-20 16:25 (20 days old)
References : http://marc.info/?l=linux-kernel&m=123246937207675&w=2
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12618] hackbench [pthread mode] regression with 2.6.29-rc3
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Ingo Molnar, Peter Zijlstra, Zhang, Yanmin
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12618
Subject : hackbench [pthread mode] regression with 2.6.29-rc3
Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date : 2009-02-01 7:30 (8 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=490dea45d00f01847ebebd007685d564aaf2cd98
References : http://marc.info/?l=linux-kernel&m=123347347726527&w=4
Handled-By : Peter Zijlstra <peterz@infradead.org>
Patch : http://marc.info/?l=linux-kernel&m=123383366122146&w=4
http://marc.info/?l=linux-kernel&m=123383366222152&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12649] Early crash with 2.6.29-rc3
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Andrew McMillan, Len Brown
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12649
Subject : Early crash with 2.6.29-rc3
Submitter : Andrew McMillan <andrew@morphoss.com>
Date : 2009-02-04 20:03 (5 days old)
References : http://marc.info/?l=linux-kernel&m=123377840816097&w=4
Handled-By : Len Brown <lenb@kernel.org>
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12656] iwl3945 broken after hibernation: Wait for START_ALIVE timeout after 2000ms.
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Alex Riesen, Reinette Chatre
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12656
Subject : iwl3945 broken after hibernation: Wait for START_ALIVE timeout after 2000ms.
Submitter : Alex Riesen <fork0@users.sf.net>
Date : 2009-02-08 01:52 (1 days old)
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12656] iwl3945 broken after hibernation: Wait for START_ALIVE timeout after 2000ms.
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Alex Riesen, Reinette Chatre
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12656
Subject : iwl3945 broken after hibernation: Wait for START_ALIVE timeout after 2000ms.
Submitter : Alex Riesen <fork0-iA+eEnwkJgzk1uMJSBkQmQ@public.gmane.org>
Date : 2009-02-08 01:52 (1 days old)
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12661] commit 64ff3b938ec6782e6585a83d5459b98b0c3f6eb8 breaks rlogin
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, David S. Miller, Herbert Xu, Jeff Chua
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12661
Subject : commit 64ff3b938ec6782e6585a83d5459b98b0c3f6eb8 breaks rlogin
Submitter : Jeff Chua <jeff.chua.linux@gmail.com>
Date : 2009-02-05 14:41 (4 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=64ff3b938ec6782e6585a83d5459b98b0c3f6eb8
References : http://marc.info/?l=linux-kernel&m=123384496107361&w=4
Handled-By : Herbert Xu <herbert@gondor.apana.org.au>
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12661] commit 64ff3b938ec6782e6585a83d5459b98b0c3f6eb8 breaks rlogin
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, David S. Miller, Herbert Xu, Jeff Chua
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12661
Subject : commit 64ff3b938ec6782e6585a83d5459b98b0c3f6eb8 breaks rlogin
Submitter : Jeff Chua <jeff.chua.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-02-05 14:41 (4 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=64ff3b938ec6782e6585a83d5459b98b0c3f6eb8
References : http://marc.info/?l=linux-kernel&m=123384496107361&w=4
Handled-By : Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12661] commit 64ff3b938ec6782e6585a83d5459b98b0c3f6eb8 breaks rlogin
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-09 4:23 ` Herbert Xu
-1 siblings, 0 replies; 219+ messages in thread
From: Herbert Xu @ 2009-02-09 4:23 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, David S. Miller,
Jeff Chua
On Sun, Feb 08, 2009 at 08:21:46PM +0100, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
The patch in question has already been reverted. So while we
still need to track down the underlying problem with rlogin, it's
no longer a kernel regression.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12661] commit 64ff3b938ec6782e6585a83d5459b98b0c3f6eb8 breaks rlogin
@ 2009-02-09 4:23 ` Herbert Xu
0 siblings, 0 replies; 219+ messages in thread
From: Herbert Xu @ 2009-02-09 4:23 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, David S. Miller,
Jeff Chua
On Sun, Feb 08, 2009 at 08:21:46PM +0100, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
The patch in question has already been reverted. So while we
still need to track down the underlying problem with rlogin, it's
no longer a kernel regression.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12661] commit 64ff3b938ec6782e6585a83d5459b98b0c3f6eb8 breaks rlogin
@ 2009-02-14 22:35 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-14 22:35 UTC (permalink / raw)
To: Herbert Xu
Cc: Linux Kernel Mailing List, Kernel Testers List, David S. Miller,
Jeff Chua
On Monday 09 February 2009, Herbert Xu wrote:
> On Sun, Feb 08, 2009 at 08:21:46PM +0100, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
>
> The patch in question has already been reverted. So while we
> still need to track down the underlying problem with rlogin, it's
> no longer a kernel regression.
I've closed the bug, sorry for the slow response.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12661] commit 64ff3b938ec6782e6585a83d5459b98b0c3f6eb8 breaks rlogin
@ 2009-02-14 22:35 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-14 22:35 UTC (permalink / raw)
To: Herbert Xu
Cc: Linux Kernel Mailing List, Kernel Testers List, David S. Miller,
Jeff Chua
On Monday 09 February 2009, Herbert Xu wrote:
> On Sun, Feb 08, 2009 at 08:21:46PM +0100, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.28. Please verify if it still should be listed and let me know
> > (either way).
>
> The patch in question has already been reverted. So while we
> still need to track down the underlying problem with rlogin, it's
> no longer a kernel regression.
I've closed the bug, sorry for the slow response.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12660] Linux 2.6.28.3 freezing on a 32-bits x86 Thinkpad T43p
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Ingo Molnar, Mathieu Desnoyers
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12660
Subject : Linux 2.6.28.3 freezing on a 32-bits x86 Thinkpad T43p
Submitter : Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Date : 2009-02-04 21:11 (5 days old)
References : http://marc.info/?l=linux-kernel&m=123378196022258&w=4
Handled-By : Ingo Molnar <mingo@elte.hu>
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12659] Failure to resume two Sandisk USB flash drives attached to a Belkin USB Busport Mobile (F5U022).
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List,
2.6.29-rc3-git3 -- Failure to resume two Sandisk USB flash
drives, Rafael J. Wysocki
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12659
Subject : Failure to resume two Sandisk USB flash drives attached to a Belkin USB Busport Mobile (F5U022).
Submitter : 2.6.29-rc3-git3 -- Failure to resume two Sandisk USB flash drives
Date : 2009-02-03 4:58 (6 days old)
References : http://marc.info/?l=linux-kernel&m=123363718614763&w=4
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12659] Failure to resume two Sandisk USB flash drives attached to a Belkin USB Busport Mobile (F5U022).
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List,
2.6.29-rc3-git3 -- Failure to resume two Sandisk USB flash
drives, Rafael J. Wysocki
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12659
Subject : Failure to resume two Sandisk USB flash drives attached to a Belkin USB Busport Mobile (F5U022).
Submitter : 2.6.29-rc3-git3 -- Failure to resume two Sandisk USB flash drives
Date : 2009-02-03 4:58 (6 days old)
References : http://marc.info/?l=linux-kernel&m=123363718614763&w=4
Handled-By : Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12662] linux 2.6.29-rc3 kernel failure with mptsas
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Andrew Morton, Morten P.D. Stevens
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12662
Subject : linux 2.6.29-rc3 kernel failure with mptsas
Submitter : Morten P.D. Stevens <mstevens@win-professional.com>
Date : 2009-02-05 22:29 (4 days old)
References : http://marc.info/?l=linux-kernel&m=123387302729741&w=4
Handled-By : Andrew Morton <akpm@linux-foundation.org>
Patch : http://marc.info/?l=linux-kernel&m=123396429501103&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12664] viafb triggers BUG at mm/vmalloc.c:294
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Alexey Dobriyan, wixor
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12664
Subject : viafb triggers BUG at mm/vmalloc.c:294
Submitter : wixor <wixorpeek@gmail.com>
Date : 2009-02-07 19:44 (2 days old)
References : http://marc.info/?l=linux-kernel&m=123403591109515&w=4
Handled-By : Alexey Dobriyan <adobriyan@gmail.com>
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12664] viafb triggers BUG at mm/vmalloc.c:294
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Alexey Dobriyan, wixor
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12664
Subject : viafb triggers BUG at mm/vmalloc.c:294
Submitter : wixor <wixorpeek-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-02-07 19:44 (2 days old)
References : http://marc.info/?l=linux-kernel&m=123403591109515&w=4
Handled-By : Alexey Dobriyan <adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12664] viafb triggers BUG at mm/vmalloc.c:294
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-09 10:17 ` wixor
-1 siblings, 0 replies; 219+ messages in thread
From: wixor @ 2009-02-09 10:17 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Alexey Dobriyan
There was no support for Chrome9 framebuffer before 2.6.28, so that is
a progress. However now that we have it, it doesn't work (at least for
me).... The BUG appearing seemed to be an mm-issue also reported by
others (see http://marc.info/?l=linux-kernel&m=123415925903748&w=2). I
don't know if it was there before 2.6.28. It doesn't look like any
solution has been merged to mainline.
It is certainly an issue, but I'm not sure if it's also a regression
from 2.6.28.
--
wixor
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12664] viafb triggers BUG at mm/vmalloc.c:294
@ 2009-02-09 10:17 ` wixor
0 siblings, 0 replies; 219+ messages in thread
From: wixor @ 2009-02-09 10:17 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Alexey Dobriyan
There was no support for Chrome9 framebuffer before 2.6.28, so that is
a progress. However now that we have it, it doesn't work (at least for
me).... The BUG appearing seemed to be an mm-issue also reported by
others (see http://marc.info/?l=linux-kernel&m=123415925903748&w=2). I
don't know if it was there before 2.6.28. It doesn't look like any
solution has been merged to mainline.
It is certainly an issue, but I'm not sure if it's also a regression
from 2.6.28.
--
wixor
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12664] viafb triggers BUG at mm/vmalloc.c:294
@ 2009-02-14 22:39 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-14 22:39 UTC (permalink / raw)
To: wixor; +Cc: Linux Kernel Mailing List, Kernel Testers List, Alexey Dobriyan
On Monday 09 February 2009, wixor wrote:
> There was no support for Chrome9 framebuffer before 2.6.28, so that is
> a progress. However now that we have it, it doesn't work (at least for
> me).... The BUG appearing seemed to be an mm-issue also reported by
> others (see http://marc.info/?l=linux-kernel&m=123415925903748&w=2). I
> don't know if it was there before 2.6.28. It doesn't look like any
> solution has been merged to mainline.
>
> It is certainly an issue, but I'm not sure if it's also a regression
> from 2.6.28.
I've dropped it from the list of recent regressions, sorry for the slow
response.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12664] viafb triggers BUG at mm/vmalloc.c:294
@ 2009-02-14 22:39 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-14 22:39 UTC (permalink / raw)
To: wixor; +Cc: Linux Kernel Mailing List, Kernel Testers List, Alexey Dobriyan
On Monday 09 February 2009, wixor wrote:
> There was no support for Chrome9 framebuffer before 2.6.28, so that is
> a progress. However now that we have it, it doesn't work (at least for
> me).... The BUG appearing seemed to be an mm-issue also reported by
> others (see http://marc.info/?l=linux-kernel&m=123415925903748&w=2). I
> don't know if it was there before 2.6.28. It doesn't look like any
> solution has been merged to mainline.
>
> It is certainly an issue, but I'm not sure if it's also a regression
> from 2.6.28.
I've dropped it from the list of recent regressions, sorry for the slow
response.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12666] Build failure with latest -git: btrfs on ppc64
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Chuck Ebbert, Kyle McMartin
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12666
Subject : Build failure with latest -git: btrfs on ppc64
Submitter : Chuck Ebbert <cebbert@redhat.com>
Date : 2009-02-07 20:50 (2 days old)
References : http://marc.info/?l=linux-kernel&m=123404002114219&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12666] Build failure with latest -git: btrfs on ppc64
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Chuck Ebbert, Kyle McMartin
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12666
Subject : Build failure with latest -git: btrfs on ppc64
Submitter : Chuck Ebbert <cebbert-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date : 2009-02-07 20:50 (2 days old)
References : http://marc.info/?l=linux-kernel&m=123404002114219&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12666] Build failure with latest -git: btrfs on ppc64
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-08 21:53 ` Kyle McMartin
-1 siblings, 0 replies; 219+ messages in thread
From: Kyle McMartin @ 2009-02-08 21:53 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Chuck Ebbert,
Kyle McMartin
On Sun, Feb 08, 2009 at 08:21:49PM +0100, Rafael J. Wysocki wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12666
> Subject : Build failure with latest -git: btrfs on ppc64
> Submitter : Chuck Ebbert <cebbert@redhat.com>
> Date : 2009-02-07 20:50 (2 days old)
> References : http://marc.info/?l=linux-kernel&m=123404002114219&w=4
>
Just fyi, patch here:
Subject: x86: spinlocks: define dummy __raw_spin_is_contended
Date: Sun, 8 Feb 2009 13:03:41 -0500
Message-ID: <20090208180341.GC11398@bombadil.infradead.org>
cheers, Kyle
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12666] Build failure with latest -git: btrfs on ppc64
@ 2009-02-08 21:53 ` Kyle McMartin
0 siblings, 0 replies; 219+ messages in thread
From: Kyle McMartin @ 2009-02-08 21:53 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Chuck Ebbert,
Kyle McMartin
On Sun, Feb 08, 2009 at 08:21:49PM +0100, Rafael J. Wysocki wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12666
> Subject : Build failure with latest -git: btrfs on ppc64
> Submitter : Chuck Ebbert <cebbert-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Date : 2009-02-07 20:50 (2 days old)
> References : http://marc.info/?l=linux-kernel&m=123404002114219&w=4
>
Just fyi, patch here:
Subject: x86: spinlocks: define dummy __raw_spin_is_contended
Date: Sun, 8 Feb 2009 13:03:41 -0500
Message-ID: <20090208180341.GC11398-PfSpb0PWhxZc2C7mugBRk2EX/6BAtgUQ@public.gmane.org>
cheers, Kyle
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12666] Build failure with latest -git: btrfs on ppc64
2009-02-08 21:53 ` Kyle McMartin
(?)
@ 2009-02-08 22:08 ` Rafael J. Wysocki
2009-02-10 20:00 ` Chuck Ebbert
-1 siblings, 1 reply; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 22:08 UTC (permalink / raw)
To: Kyle McMartin
Cc: Linux Kernel Mailing List, Kernel Testers List, Chuck Ebbert
On Sunday 08 February 2009, Kyle McMartin wrote:
> On Sun, Feb 08, 2009 at 08:21:49PM +0100, Rafael J. Wysocki wrote:
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12666
> > Subject : Build failure with latest -git: btrfs on ppc64
> > Submitter : Chuck Ebbert <cebbert@redhat.com>
> > Date : 2009-02-07 20:50 (2 days old)
> > References : http://marc.info/?l=linux-kernel&m=123404002114219&w=4
> >
>
> Just fyi, patch here:
> Subject: x86: spinlocks: define dummy __raw_spin_is_contended
> Date: Sun, 8 Feb 2009 13:03:41 -0500
> Message-ID: <20090208180341.GC11398@bombadil.infradead.org>
Thanks, updated the bug entry with this patch.
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12666] Build failure with latest -git: btrfs on ppc64
@ 2009-02-10 20:00 ` Chuck Ebbert
0 siblings, 0 replies; 219+ messages in thread
From: Chuck Ebbert @ 2009-02-10 20:00 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Kyle McMartin, Linux Kernel Mailing List, Kernel Testers List
On Sun, 8 Feb 2009 23:08:13 +0100
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> On Sunday 08 February 2009, Kyle McMartin wrote:
> > On Sun, Feb 08, 2009 at 08:21:49PM +0100, Rafael J. Wysocki wrote:
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12666
> > > Subject : Build failure with latest -git: btrfs on ppc64
> > > Submitter : Chuck Ebbert <cebbert@redhat.com>
> > > Date : 2009-02-07 20:50 (2 days old)
> > > References : http://marc.info/?l=linux-kernel&m=123404002114219&w=4
> > >
> >
> > Just fyi, patch here:
> > Subject: x86: spinlocks: define dummy __raw_spin_is_contended
> > Date: Sun, 8 Feb 2009 13:03:41 -0500
> > Message-ID: <20090208180341.GC11398@bombadil.infradead.org>
>
Patch was merged, commit a5ef7ca0e2636bad0ccd07b996d775348ae2b65e
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12666] Build failure with latest -git: btrfs on ppc64
@ 2009-02-10 20:00 ` Chuck Ebbert
0 siblings, 0 replies; 219+ messages in thread
From: Chuck Ebbert @ 2009-02-10 20:00 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Kyle McMartin, Linux Kernel Mailing List, Kernel Testers List
On Sun, 8 Feb 2009 23:08:13 +0100
"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> wrote:
> On Sunday 08 February 2009, Kyle McMartin wrote:
> > On Sun, Feb 08, 2009 at 08:21:49PM +0100, Rafael J. Wysocki wrote:
> > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12666
> > > Subject : Build failure with latest -git: btrfs on ppc64
> > > Submitter : Chuck Ebbert <cebbert-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > > Date : 2009-02-07 20:50 (2 days old)
> > > References : http://marc.info/?l=linux-kernel&m=123404002114219&w=4
> > >
> >
> > Just fyi, patch here:
> > Subject: x86: spinlocks: define dummy __raw_spin_is_contended
> > Date: Sun, 8 Feb 2009 13:03:41 -0500
> > Message-ID: <20090208180341.GC11398-PfSpb0PWhxZc2C7mugBRk2EX/6BAtgUQ@public.gmane.org>
>
Patch was merged, commit a5ef7ca0e2636bad0ccd07b996d775348ae2b65e
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12668] USB flash disk surprise disconnect
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Vegard Nossum
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12668
Subject : USB flash disk surprise disconnect
Submitter : Vegard Nossum <vegard.nossum@gmail.com>
Date : 2009-02-08 10:21 (1 days old)
References : http://marc.info/?l=linux-kernel&m=123408851821292&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12663] Commit 8c7e58e690ae60ab4215b025f433ed4af261e103 breaks resume
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Brian Gerst, Jiri Slaby
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12663
Subject : Commit 8c7e58e690ae60ab4215b025f433ed4af261e103 breaks resume
Submitter : Jiri Slaby <jirislaby@gmail.com>
Date : 2009-02-07 18:40 (2 days old)
References : http://lkml.org/lkml/2009/2/7/100
Handled-By : Brian Gerst <brgerst@gmail.com>
Patch : http://lkml.org/lkml/2009/2/7/100
http://lkml.org/lkml/2009/2/8/59
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Ingo Molnar, Paul Collins, Thomas Gleixner
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12667
Subject : Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
Submitter : Paul Collins <paul@burly.ondioline.org>
Date : 2009-01-21 7:15 (19 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
References : http://marc.info/?l=linux-kernel&m=123252215315106&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-08 19:21 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Ingo Molnar, Paul Collins, Thomas Gleixner
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12667
Subject : Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
Submitter : Paul Collins <paul-dsjeNyW6Qm/D+ROgJ3VA+kB+6BGkLq7r@public.gmane.org>
Date : 2009-01-21 7:15 (19 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
References : http://marc.info/?l=linux-kernel&m=123252215315106&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-09 7:53 ` Paul Collins
-1 siblings, 0 replies; 219+ messages in thread
From: Paul Collins @ 2009-02-09 7:53 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Ingo Molnar,
Thomas Gleixner
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12667
> Subject : Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
> Submitter : Paul Collins <paul@burly.ondioline.org>
> Date : 2009-01-21 7:15 (19 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
> References : http://marc.info/?l=linux-kernel&m=123252215315106&w=4
I've just done ten suspend/resume cycles with 2.6.29-rc4 and this
message was not logged, so it's either gone away or else become much
more difficult to reproduce.
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-09 7:53 ` Paul Collins
0 siblings, 0 replies; 219+ messages in thread
From: Paul Collins @ 2009-02-09 7:53 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Ingo Molnar,
Thomas Gleixner
"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> writes:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12667
> Subject : Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
> Submitter : Paul Collins <paul-dsjeNyW6Qm/D+ROgJ3VA+kB+6BGkLq7r@public.gmane.org>
> Date : 2009-01-21 7:15 (19 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
> References : http://marc.info/?l=linux-kernel&m=123252215315106&w=4
I've just done ten suspend/resume cycles with 2.6.29-rc4 and this
message was not logged, so it's either gone away or else become much
more difficult to reproduce.
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-09 9:18 ` Ingo Molnar
0 siblings, 0 replies; 219+ messages in thread
From: Ingo Molnar @ 2009-02-09 9:18 UTC (permalink / raw)
To: Paul Collins
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Thomas Gleixner
* Paul Collins <paul@burly.ondioline.org> wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12667
> > Subject : Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
> > Submitter : Paul Collins <paul@burly.ondioline.org>
> > Date : 2009-01-21 7:15 (19 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
> > References : http://marc.info/?l=linux-kernel&m=123252215315106&w=4
>
> I've just done ten suspend/resume cycles with 2.6.29-rc4 and this
> message was not logged, so it's either gone away or else become much
> more difficult to reproduce.
Various suspend handlers were enabling irqs spuriously - fixed by recent patches in
-rc4. The warning above is consistent with the timekeeping code being surprised with
a premature irqs-enable.
Ingo
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-14 22:42 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-14 22:42 UTC (permalink / raw)
To: Paul Collins
Cc: Linux Kernel Mailing List, Kernel Testers List, Ingo Molnar,
Thomas Gleixner
On Monday 09 February 2009, Paul Collins wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12667
> > Subject : Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
> > Submitter : Paul Collins <paul@burly.ondioline.org>
> > Date : 2009-01-21 7:15 (19 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
> > References : http://marc.info/?l=linux-kernel&m=123252215315106&w=4
>
> I've just done ten suspend/resume cycles with 2.6.29-rc4 and this
> message was not logged, so it's either gone away or else become much
> more difficult to reproduce.
Thanks, I've closed the bug.
Sorry for the slow response.
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-14 22:42 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-14 22:42 UTC (permalink / raw)
To: Paul Collins
Cc: Linux Kernel Mailing List, Kernel Testers List, Ingo Molnar,
Thomas Gleixner
On Monday 09 February 2009, Paul Collins wrote:
> "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> writes:
>
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12667
> > Subject : Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
> > Submitter : Paul Collins <paul-dsjeNyW6Qm/D+ROgJ3VA+kB+6BGkLq7r@public.gmane.org>
> > Date : 2009-01-21 7:15 (19 days old)
> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
> > References : http://marc.info/?l=linux-kernel&m=123252215315106&w=4
>
> I've just done ten suspend/resume cycles with 2.6.29-rc4 and this
> message was not logged, so it's either gone away or else become much
> more difficult to reproduce.
Thanks, I've closed the bug.
Sorry for the slow response.
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-16 7:17 ` Paul Collins
0 siblings, 0 replies; 219+ messages in thread
From: Paul Collins @ 2009-02-16 7:17 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Ingo Molnar,
Thomas Gleixner, benh
"Rafael J. Wysocki" <rjw@sisk.pl> writes:
> On Monday 09 February 2009, Paul Collins wrote:
>> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>>
>> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12667
>> > Subject : Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
>> > Submitter : Paul Collins <paul@burly.ondioline.org>
>> > Date : 2009-01-21 7:15 (19 days old)
>> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
>> > References : http://marc.info/?l=linux-kernel&m=123252215315106&w=4
>>
>> I've just done ten suspend/resume cycles with 2.6.29-rc4 and this
>> message was not logged, so it's either gone away or else become much
>> more difficult to reproduce.
>
> Thanks, I've closed the bug.
It turns out I didn't test this properly. The warning is only triggered
when I close and open the lid, not when I run 'snooze' to suspend and
hit Return to resume, as I did for my so-called testing of 2.6.29-rc4.
Whatever is triggering the warning is still present in 2.6.29-rc5.
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-16 7:17 ` Paul Collins
0 siblings, 0 replies; 219+ messages in thread
From: Paul Collins @ 2009-02-16 7:17 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Ingo Molnar,
Thomas Gleixner, benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r
"Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> writes:
> On Monday 09 February 2009, Paul Collins wrote:
>> "Rafael J. Wysocki" <rjw-KKrjLPT3xs0@public.gmane.org> writes:
>>
>> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12667
>> > Subject : Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
>> > Submitter : Paul Collins <paul-dsjeNyW6Qm/D+ROgJ3VA+kB+6BGkLq7r@public.gmane.org>
>> > Date : 2009-01-21 7:15 (19 days old)
>> > First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
>> > References : http://marc.info/?l=linux-kernel&m=123252215315106&w=4
>>
>> I've just done ten suspend/resume cycles with 2.6.29-rc4 and this
>> message was not logged, so it's either gone away or else become much
>> more difficult to reproduce.
>
> Thanks, I've closed the bug.
It turns out I didn't test this properly. The warning is only triggered
when I close and open the lid, not when I run 'snooze' to suspend and
hit Return to resume, as I did for my so-called testing of 2.6.29-rc4.
Whatever is triggering the warning is still present in 2.6.29-rc5.
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-16 9:10 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 219+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-16 9:10 UTC (permalink / raw)
To: Paul Collins
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar, Thomas Gleixner
On Mon, 2009-02-16 at 20:17 +1300, Paul Collins wrote:
> It turns out I didn't test this properly. The warning is only
> triggered
> when I close and open the lid, not when I run 'snooze' to suspend and
> hit Return to resume, as I did for my so-called testing of 2.6.29-rc4.
>
> Whatever is triggering the warning is still present in 2.6.29-rc5.
Right, we probably need to stop sending input events from the PMU driver
when it's "suspended".
Ping me if I don't produce a patch tomorrow (ie, I forgot :-)
Cheers,
Ben.
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-16 9:10 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 219+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-16 9:10 UTC (permalink / raw)
To: Paul Collins
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar, Thomas Gleixner
On Mon, 2009-02-16 at 20:17 +1300, Paul Collins wrote:
> It turns out I didn't test this properly. The warning is only
> triggered
> when I close and open the lid, not when I run 'snooze' to suspend and
> hit Return to resume, as I did for my so-called testing of 2.6.29-rc4.
>
> Whatever is triggering the warning is still present in 2.6.29-rc5.
Right, we probably need to stop sending input events from the PMU driver
when it's "suspended".
Ping me if I don't produce a patch tomorrow (ie, I forgot :-)
Cheers,
Ben.
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
2009-02-16 9:10 ` Benjamin Herrenschmidt
@ 2009-02-16 10:47 ` Paul Collins
-1 siblings, 0 replies; 219+ messages in thread
From: Paul Collins @ 2009-02-16 10:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar, Thomas Gleixner
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Mon, 2009-02-16 at 20:17 +1300, Paul Collins wrote:
>> It turns out I didn't test this properly. The warning is only
>> triggered
>> when I close and open the lid, not when I run 'snooze' to suspend and
>> hit Return to resume, as I did for my so-called testing of 2.6.29-rc4.
>>
>> Whatever is triggering the warning is still present in 2.6.29-rc5.
>
> Right, we probably need to stop sending input events from the PMU driver
> when it's "suspended".
>
> Ping me if I don't produce a patch tomorrow (ie, I forgot :-)
Just for laughs I slapped together the following, which seems to do the
job, although not especially tidily.
diff --git a/drivers/macintosh/via-pmu-event.c b/drivers/macintosh/via-pmu-event.c
index 25cd565..33c4b45 100644
--- a/drivers/macintosh/via-pmu-event.c
+++ b/drivers/macintosh/via-pmu-event.c
@@ -23,6 +23,7 @@
#include <linux/input.h>
#include <linux/adb.h>
#include <linux/pmu.h>
+#include <linux/bug.h>
#include "via-pmu-event.h"
static struct input_dev *pmu_input_dev;
@@ -56,24 +57,62 @@ static int __init via_pmu_event_init(void)
return err;
}
+static bool lid_event_pending;
+static int lid_event_pending_down;
+static bool power_button_event_pending;
+static int power_button_event_pending_down;
+
void via_pmu_event(int key, int down)
{
if (unlikely(!pmu_input_dev))
return;
- switch (key) {
- case PMU_EVT_POWER:
- input_report_key(pmu_input_dev, KEY_POWER, down);
- break;
- case PMU_EVT_LID:
- input_report_switch(pmu_input_dev, SW_LID, down);
- break;
- default:
- /* no such key handled */
- return;
- }
+ if (!pmu_sys_suspended) {
+ switch (key) {
+ case PMU_EVT_POWER:
+ input_report_key(pmu_input_dev, KEY_POWER, down);
+ break;
+ case PMU_EVT_LID:
+ input_report_switch(pmu_input_dev, SW_LID, down);
+ break;
+ default:
+ /* no such key handled */
+ return;
+ }
+
+ input_sync(pmu_input_dev);
+ } else {
+ switch (key) {
+ case PMU_EVT_POWER:
+ power_button_event_pending = true;
+ power_button_event_pending_down = down;
+ break;
+ case PMU_EVT_LID:
+ lid_event_pending = true;
+ lid_event_pending_down = down;
+ break;
+ default:
+ /* no such key handled */
+ return;
+ }
+ }
+}
+void via_pmu_event_resume(void)
+{
+ WARN_ON(pmu_sys_suspended);
+
+ if (power_button_event_pending) {
+ input_report_key(pmu_input_dev, KEY_POWER,
+ power_button_event_pending_down);
+ power_button_event_pending = false;
+ }
+ if (lid_event_pending) {
+ input_report_switch(pmu_input_dev, SW_LID,
+ lid_event_pending_down);
+ lid_event_pending = false;
+ }
input_sync(pmu_input_dev);
}
diff --git a/drivers/macintosh/via-pmu-event.h b/drivers/macintosh/via-pmu-event.h
index 72c54de..2754adc 100644
--- a/drivers/macintosh/via-pmu-event.h
+++ b/drivers/macintosh/via-pmu-event.h
@@ -4,5 +4,6 @@
#define PMU_EVT_POWER 0
#define PMU_EVT_LID 1
extern void via_pmu_event(int key, int down);
+extern void via_pmu_event_resume(void);
#endif /* __VIA_PMU_EVENT_H */
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index b40fb9b..01b8689 100644
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -2479,6 +2479,8 @@ static int pmu_sys_resume(struct sys_device *sysdev)
pmu_resume();
pmu_sys_suspended = 0;
+ via_pmu_event_resume();
+
return 0;
}
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply related [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-16 10:47 ` Paul Collins
0 siblings, 0 replies; 219+ messages in thread
From: Paul Collins @ 2009-02-16 10:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar, Thomas Gleixner
Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> writes:
> On Mon, 2009-02-16 at 20:17 +1300, Paul Collins wrote:
>> It turns out I didn't test this properly. The warning is only
>> triggered
>> when I close and open the lid, not when I run 'snooze' to suspend and
>> hit Return to resume, as I did for my so-called testing of 2.6.29-rc4.
>>
>> Whatever is triggering the warning is still present in 2.6.29-rc5.
>
> Right, we probably need to stop sending input events from the PMU driver
> when it's "suspended".
>
> Ping me if I don't produce a patch tomorrow (ie, I forgot :-)
Just for laughs I slapped together the following, which seems to do the
job, although not especially tidily.
diff --git a/drivers/macintosh/via-pmu-event.c b/drivers/macintosh/via-pmu-event.c
index 25cd565..33c4b45 100644
--- a/drivers/macintosh/via-pmu-event.c
+++ b/drivers/macintosh/via-pmu-event.c
@@ -23,6 +23,7 @@
#include <linux/input.h>
#include <linux/adb.h>
#include <linux/pmu.h>
+#include <linux/bug.h>
#include "via-pmu-event.h"
static struct input_dev *pmu_input_dev;
@@ -56,24 +57,62 @@ static int __init via_pmu_event_init(void)
return err;
}
+static bool lid_event_pending;
+static int lid_event_pending_down;
+static bool power_button_event_pending;
+static int power_button_event_pending_down;
+
void via_pmu_event(int key, int down)
{
if (unlikely(!pmu_input_dev))
return;
- switch (key) {
- case PMU_EVT_POWER:
- input_report_key(pmu_input_dev, KEY_POWER, down);
- break;
- case PMU_EVT_LID:
- input_report_switch(pmu_input_dev, SW_LID, down);
- break;
- default:
- /* no such key handled */
- return;
- }
+ if (!pmu_sys_suspended) {
+ switch (key) {
+ case PMU_EVT_POWER:
+ input_report_key(pmu_input_dev, KEY_POWER, down);
+ break;
+ case PMU_EVT_LID:
+ input_report_switch(pmu_input_dev, SW_LID, down);
+ break;
+ default:
+ /* no such key handled */
+ return;
+ }
+
+ input_sync(pmu_input_dev);
+ } else {
+ switch (key) {
+ case PMU_EVT_POWER:
+ power_button_event_pending = true;
+ power_button_event_pending_down = down;
+ break;
+ case PMU_EVT_LID:
+ lid_event_pending = true;
+ lid_event_pending_down = down;
+ break;
+ default:
+ /* no such key handled */
+ return;
+ }
+ }
+}
+void via_pmu_event_resume(void)
+{
+ WARN_ON(pmu_sys_suspended);
+
+ if (power_button_event_pending) {
+ input_report_key(pmu_input_dev, KEY_POWER,
+ power_button_event_pending_down);
+ power_button_event_pending = false;
+ }
+ if (lid_event_pending) {
+ input_report_switch(pmu_input_dev, SW_LID,
+ lid_event_pending_down);
+ lid_event_pending = false;
+ }
input_sync(pmu_input_dev);
}
diff --git a/drivers/macintosh/via-pmu-event.h b/drivers/macintosh/via-pmu-event.h
index 72c54de..2754adc 100644
--- a/drivers/macintosh/via-pmu-event.h
+++ b/drivers/macintosh/via-pmu-event.h
@@ -4,5 +4,6 @@
#define PMU_EVT_POWER 0
#define PMU_EVT_LID 1
extern void via_pmu_event(int key, int down);
+extern void via_pmu_event_resume(void);
#endif /* __VIA_PMU_EVENT_H */
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index b40fb9b..01b8689 100644
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -2479,6 +2479,8 @@ static int pmu_sys_resume(struct sys_device *sysdev)
pmu_resume();
pmu_sys_suspended = 0;
+ via_pmu_event_resume();
+
return 0;
}
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply related [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-19 8:27 ` Paul Collins
0 siblings, 0 replies; 219+ messages in thread
From: Paul Collins @ 2009-02-19 8:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar, Thomas Gleixner
Paul Collins <paul@burly.ondioline.org> writes:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>
>> On Mon, 2009-02-16 at 20:17 +1300, Paul Collins wrote:
>>> It turns out I didn't test this properly. The warning is only
>>> triggered
>>> when I close and open the lid, not when I run 'snooze' to suspend and
>>> hit Return to resume, as I did for my so-called testing of 2.6.29-rc4.
>>>
>>> Whatever is triggering the warning is still present in 2.6.29-rc5.
>>
>> Right, we probably need to stop sending input events from the PMU driver
>> when it's "suspended".
>>
>> Ping me if I don't produce a patch tomorrow (ie, I forgot :-)
>
> Just for laughs I slapped together the following, which seems to do the
> job, although not especially tidily.
And it doesn't even do the job. Judging by this new trace, submitting
input events from the via-pmu resume function is still too early.
NIP [c0053b4c] getnstimeofday+0x24/0x188
LR [c0053ccc] do_gettimeofday+0x1c/0x58
Call Trace:
[eed09cb0] [c0053ccc] do_gettimeofday+0x1c/0x58
[eed09ce0] [c03492cc] evdev_event+0x28/0x158
[eed09d10] [c0341748] input_pass_event+0xac/0xb0
[eed09d30] [c03444a8] input_event+0x80/0x98
[eed09d50] [c02f7668] via_pmu_event_resume+0x60/0xb8 <-- the function I added
[eed09d60] [c02f725c] pmu_sys_resume+0x5c/0x74
[eed09de0] [c02d6420] __sysdev_resume+0x64/0x84
[eed09e00] [c02d6498] sysdev_resume+0x58/0xa4
[eed09e20] [c02dd39c] device_power_up+0x18/0x38
[eed09e40] [c00609d4] suspend_devices_and_enter+0x11c/0x180
[eed09e60] [c0060be8] enter_state+0x11c/0x160
[eed09e80] [c02f4d6c] pmu_ioctl+0x15c/0x24c
[eed09e90] [c00bad34] vfs_ioctl+0x8c/0x90
[eed09ea0] [c00bade8] do_vfs_ioctl+0x8c/0x70c
[eed09f10] [c00bb504] sys_ioctl+0x9c/0xa4
[eed09f40] [c0012eb8] ret_from_syscall+0x0/0x38
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-19 8:27 ` Paul Collins
0 siblings, 0 replies; 219+ messages in thread
From: Paul Collins @ 2009-02-19 8:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar, Thomas Gleixner
Paul Collins <paul-dsjeNyW6Qm/D+ROgJ3VA+kB+6BGkLq7r@public.gmane.org> writes:
> Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> writes:
>
>> On Mon, 2009-02-16 at 20:17 +1300, Paul Collins wrote:
>>> It turns out I didn't test this properly. The warning is only
>>> triggered
>>> when I close and open the lid, not when I run 'snooze' to suspend and
>>> hit Return to resume, as I did for my so-called testing of 2.6.29-rc4.
>>>
>>> Whatever is triggering the warning is still present in 2.6.29-rc5.
>>
>> Right, we probably need to stop sending input events from the PMU driver
>> when it's "suspended".
>>
>> Ping me if I don't produce a patch tomorrow (ie, I forgot :-)
>
> Just for laughs I slapped together the following, which seems to do the
> job, although not especially tidily.
And it doesn't even do the job. Judging by this new trace, submitting
input events from the via-pmu resume function is still too early.
NIP [c0053b4c] getnstimeofday+0x24/0x188
LR [c0053ccc] do_gettimeofday+0x1c/0x58
Call Trace:
[eed09cb0] [c0053ccc] do_gettimeofday+0x1c/0x58
[eed09ce0] [c03492cc] evdev_event+0x28/0x158
[eed09d10] [c0341748] input_pass_event+0xac/0xb0
[eed09d30] [c03444a8] input_event+0x80/0x98
[eed09d50] [c02f7668] via_pmu_event_resume+0x60/0xb8 <-- the function I added
[eed09d60] [c02f725c] pmu_sys_resume+0x5c/0x74
[eed09de0] [c02d6420] __sysdev_resume+0x64/0x84
[eed09e00] [c02d6498] sysdev_resume+0x58/0xa4
[eed09e20] [c02dd39c] device_power_up+0x18/0x38
[eed09e40] [c00609d4] suspend_devices_and_enter+0x11c/0x180
[eed09e60] [c0060be8] enter_state+0x11c/0x160
[eed09e80] [c02f4d6c] pmu_ioctl+0x15c/0x24c
[eed09e90] [c00bad34] vfs_ioctl+0x8c/0x90
[eed09ea0] [c00bade8] do_vfs_ioctl+0x8c/0x70c
[eed09f10] [c00bb504] sys_ioctl+0x9c/0xa4
[eed09f40] [c0012eb8] ret_from_syscall+0x0/0x38
--
Paul Collins
Wellington, New Zealand
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-19 8:38 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 219+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-19 8:38 UTC (permalink / raw)
To: Paul Collins
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar, Thomas Gleixner
On Thu, 2009-02-19 at 21:27 +1300, Paul Collins wrote:
> > Just for laughs I slapped together the following, which seems to do
> the
> > job, although not especially tidily.
>
> And it doesn't even do the job. Judging by this new trace, submitting
> input events from the via-pmu resume function is still too early.
>
What's up Thomas ? We can't call gettimeofday() from a sysdev
suspend/resume ? That's a little bit too harsh no ?
Cheers,
Ben.
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-19 8:38 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 219+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-19 8:38 UTC (permalink / raw)
To: Paul Collins
Cc: Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar, Thomas Gleixner
On Thu, 2009-02-19 at 21:27 +1300, Paul Collins wrote:
> > Just for laughs I slapped together the following, which seems to do
> the
> > job, although not especially tidily.
>
> And it doesn't even do the job. Judging by this new trace, submitting
> input events from the via-pmu resume function is still too early.
>
What's up Thomas ? We can't call gettimeofday() from a sysdev
suspend/resume ? That's a little bit too harsh no ?
Cheers,
Ben.
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
2009-02-19 8:38 ` Benjamin Herrenschmidt
@ 2009-02-19 13:00 ` Rafael J. Wysocki
-1 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-19 13:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Paul Collins, Linux Kernel Mailing List, Kernel Testers List,
Ingo Molnar, Thomas Gleixner
On Thursday 19 February 2009, Benjamin Herrenschmidt wrote:
> On Thu, 2009-02-19 at 21:27 +1300, Paul Collins wrote:
> > > Just for laughs I slapped together the following, which seems to do
> > the
> > > job, although not especially tidily.
> >
> > And it doesn't even do the job. Judging by this new trace, submitting
> > input events from the via-pmu resume function is still too early.
> >
> What's up Thomas ? We can't call gettimeofday() from a sysdev
> suspend/resume ? That's a little bit too harsh no ?
Perhaps the ordering is wrong (ie. via-pmu resume happens bevore timekeeping
resume)?
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-19 13:00 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-19 13:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Paul Collins, Linux Kernel Mailing List, Kernel Testers List,
Ingo Molnar, Thomas Gleixner
On Thursday 19 February 2009, Benjamin Herrenschmidt wrote:
> On Thu, 2009-02-19 at 21:27 +1300, Paul Collins wrote:
> > > Just for laughs I slapped together the following, which seems to do
> > the
> > > job, although not especially tidily.
> >
> > And it doesn't even do the job. Judging by this new trace, submitting
> > input events from the via-pmu resume function is still too early.
> >
> What's up Thomas ? We can't call gettimeofday() from a sysdev
> suspend/resume ? That's a little bit too harsh no ?
Perhaps the ordering is wrong (ie. via-pmu resume happens bevore timekeeping
resume)?
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-19 21:47 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 219+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-19 21:47 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Paul Collins, Linux Kernel Mailing List, Kernel Testers List,
Ingo Molnar, Thomas Gleixner
On Thu, 2009-02-19 at 14:00 +0100, Rafael J. Wysocki wrote:
> On Thursday 19 February 2009, Benjamin Herrenschmidt wrote:
> > On Thu, 2009-02-19 at 21:27 +1300, Paul Collins wrote:
> > > > Just for laughs I slapped together the following, which seems to do
> > > the
> > > > job, although not especially tidily.
> > >
> > > And it doesn't even do the job. Judging by this new trace, submitting
> > > input events from the via-pmu resume function is still too early.
> > >
> > What's up Thomas ? We can't call gettimeofday() from a sysdev
> > suspend/resume ? That's a little bit too harsh no ?
>
> Perhaps the ordering is wrong (ie. via-pmu resume happens bevore timekeeping
> resume)?
In this case, maybe gtod should just return the frozen time (ie, last
time at the time of suspend) rather than WARN ?
Ben.
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-19 21:47 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 219+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-19 21:47 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Paul Collins, Linux Kernel Mailing List, Kernel Testers List,
Ingo Molnar, Thomas Gleixner
On Thu, 2009-02-19 at 14:00 +0100, Rafael J. Wysocki wrote:
> On Thursday 19 February 2009, Benjamin Herrenschmidt wrote:
> > On Thu, 2009-02-19 at 21:27 +1300, Paul Collins wrote:
> > > > Just for laughs I slapped together the following, which seems to do
> > > the
> > > > job, although not especially tidily.
> > >
> > > And it doesn't even do the job. Judging by this new trace, submitting
> > > input events from the via-pmu resume function is still too early.
> > >
> > What's up Thomas ? We can't call gettimeofday() from a sysdev
> > suspend/resume ? That's a little bit too harsh no ?
>
> Perhaps the ordering is wrong (ie. via-pmu resume happens bevore timekeeping
> resume)?
In this case, maybe gtod should just return the frozen time (ie, last
time at the time of suspend) rather than WARN ?
Ben.
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
2009-02-19 21:47 ` Benjamin Herrenschmidt
@ 2009-02-19 22:08 ` Rafael J. Wysocki
-1 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-19 22:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Paul Collins, Linux Kernel Mailing List, Kernel Testers List,
Ingo Molnar, Thomas Gleixner
On Thursday 19 February 2009, Benjamin Herrenschmidt wrote:
> On Thu, 2009-02-19 at 14:00 +0100, Rafael J. Wysocki wrote:
> > On Thursday 19 February 2009, Benjamin Herrenschmidt wrote:
> > > On Thu, 2009-02-19 at 21:27 +1300, Paul Collins wrote:
> > > > > Just for laughs I slapped together the following, which seems to do
> > > > the
> > > > > job, although not especially tidily.
> > > >
> > > > And it doesn't even do the job. Judging by this new trace, submitting
> > > > input events from the via-pmu resume function is still too early.
> > > >
> > > What's up Thomas ? We can't call gettimeofday() from a sysdev
> > > suspend/resume ? That's a little bit too harsh no ?
> >
> > Perhaps the ordering is wrong (ie. via-pmu resume happens bevore timekeeping
> > resume)?
>
> In this case, maybe gtod should just return the frozen time (ie, last
> time at the time of suspend) rather than WARN ?
This might work, but there seem to be more problems like this (cpufreq vs
timekeeping for example).
I think we need a more general approach.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-19 22:08 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-19 22:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Paul Collins, Linux Kernel Mailing List, Kernel Testers List,
Ingo Molnar, Thomas Gleixner
On Thursday 19 February 2009, Benjamin Herrenschmidt wrote:
> On Thu, 2009-02-19 at 14:00 +0100, Rafael J. Wysocki wrote:
> > On Thursday 19 February 2009, Benjamin Herrenschmidt wrote:
> > > On Thu, 2009-02-19 at 21:27 +1300, Paul Collins wrote:
> > > > > Just for laughs I slapped together the following, which seems to do
> > > > the
> > > > > job, although not especially tidily.
> > > >
> > > > And it doesn't even do the job. Judging by this new trace, submitting
> > > > input events from the via-pmu resume function is still too early.
> > > >
> > > What's up Thomas ? We can't call gettimeofday() from a sysdev
> > > suspend/resume ? That's a little bit too harsh no ?
> >
> > Perhaps the ordering is wrong (ie. via-pmu resume happens bevore timekeeping
> > resume)?
>
> In this case, maybe gtod should just return the frozen time (ie, last
> time at the time of suspend) rather than WARN ?
This might work, but there seem to be more problems like this (cpufreq vs
timekeeping for example).
I think we need a more general approach.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
2009-02-19 8:38 ` Benjamin Herrenschmidt
@ 2009-02-19 20:17 ` Thomas Gleixner
-1 siblings, 0 replies; 219+ messages in thread
From: Thomas Gleixner @ 2009-02-19 20:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Paul Collins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar
On Thu, 19 Feb 2009, Benjamin Herrenschmidt wrote:
> On Thu, 2009-02-19 at 21:27 +1300, Paul Collins wrote:
> > > Just for laughs I slapped together the following, which seems to do
> > the
> > > job, although not especially tidily.
> >
> > And it doesn't even do the job. Judging by this new trace, submitting
> > input events from the via-pmu resume function is still too early.
> >
> What's up Thomas ? We can't call gettimeofday() from a sysdev
> suspend/resume ? That's a little bit too harsh no ?
Well, harsh or not is not the question here.
Fact is that you call gettimeofday() _before_ the timekeeping code has
resumed.
That's a simple ordering problem. timekeeping is in the sysdev class
as well and it's not the only sysdev which has explicit ordering
requirements.
Thanks,
tglx
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-19 20:17 ` Thomas Gleixner
0 siblings, 0 replies; 219+ messages in thread
From: Thomas Gleixner @ 2009-02-19 20:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Paul Collins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar
On Thu, 19 Feb 2009, Benjamin Herrenschmidt wrote:
> On Thu, 2009-02-19 at 21:27 +1300, Paul Collins wrote:
> > > Just for laughs I slapped together the following, which seems to do
> > the
> > > job, although not especially tidily.
> >
> > And it doesn't even do the job. Judging by this new trace, submitting
> > input events from the via-pmu resume function is still too early.
> >
> What's up Thomas ? We can't call gettimeofday() from a sysdev
> suspend/resume ? That's a little bit too harsh no ?
Well, harsh or not is not the question here.
Fact is that you call gettimeofday() _before_ the timekeeping code has
resumed.
That's a simple ordering problem. timekeeping is in the sysdev class
as well and it's not the only sysdev which has explicit ordering
requirements.
Thanks,
tglx
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-19 21:23 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-19 21:23 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Benjamin Herrenschmidt, Paul Collins, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar
On Thursday 19 February 2009, Thomas Gleixner wrote:
> On Thu, 19 Feb 2009, Benjamin Herrenschmidt wrote:
>
> > On Thu, 2009-02-19 at 21:27 +1300, Paul Collins wrote:
> > > > Just for laughs I slapped together the following, which seems to do
> > > the
> > > > job, although not especially tidily.
> > >
> > > And it doesn't even do the job. Judging by this new trace, submitting
> > > input events from the via-pmu resume function is still too early.
> > >
> > What's up Thomas ? We can't call gettimeofday() from a sysdev
> > suspend/resume ? That's a little bit too harsh no ?
>
> Well, harsh or not is not the question here.
>
> Fact is that you call gettimeofday() _before_ the timekeeping code has
> resumed.
>
> That's a simple ordering problem. timekeeping is in the sysdev class
> as well and it's not the only sysdev which has explicit ordering
> requirements.
Do we need suspend-resume priorities for sysdevs? Such that sysdevs
with a higher priority will always be suspended earlier and resumed later
than sysdevs with lower priority (or the other way around)?
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-19 21:23 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-19 21:23 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Benjamin Herrenschmidt, Paul Collins, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar
On Thursday 19 February 2009, Thomas Gleixner wrote:
> On Thu, 19 Feb 2009, Benjamin Herrenschmidt wrote:
>
> > On Thu, 2009-02-19 at 21:27 +1300, Paul Collins wrote:
> > > > Just for laughs I slapped together the following, which seems to do
> > > the
> > > > job, although not especially tidily.
> > >
> > > And it doesn't even do the job. Judging by this new trace, submitting
> > > input events from the via-pmu resume function is still too early.
> > >
> > What's up Thomas ? We can't call gettimeofday() from a sysdev
> > suspend/resume ? That's a little bit too harsh no ?
>
> Well, harsh or not is not the question here.
>
> Fact is that you call gettimeofday() _before_ the timekeeping code has
> resumed.
>
> That's a simple ordering problem. timekeeping is in the sysdev class
> as well and it's not the only sysdev which has explicit ordering
> requirements.
Do we need suspend-resume priorities for sysdevs? Such that sysdevs
with a higher priority will always be suspended earlier and resumed later
than sysdevs with lower priority (or the other way around)?
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-19 21:51 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 219+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-19 21:51 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Paul Collins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar
On Thu, 2009-02-19 at 21:17 +0100, Thomas Gleixner wrote:
>
> Well, harsh or not is not the question here.
>
> Fact is that you call gettimeofday() _before_ the timekeeping code has
> resumed.
>
> That's a simple ordering problem. timekeeping is in the sysdev class
> as well and it's not the only sysdev which has explicit ordering
> requirements.
And how do I control that ordering ?
I find that a bit fishy ... What about making gettimeofday() in the
timekeeping code work, just return a frozen snapshot of the value on
suspend instead ?
Ben.
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-19 21:51 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 219+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-19 21:51 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Paul Collins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar
On Thu, 2009-02-19 at 21:17 +0100, Thomas Gleixner wrote:
>
> Well, harsh or not is not the question here.
>
> Fact is that you call gettimeofday() _before_ the timekeeping code has
> resumed.
>
> That's a simple ordering problem. timekeeping is in the sysdev class
> as well and it's not the only sysdev which has explicit ordering
> requirements.
And how do I control that ordering ?
I find that a bit fishy ... What about making gettimeofday() in the
timekeeping code work, just return a frozen snapshot of the value on
suspend instead ?
Ben.
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
2009-02-19 21:51 ` Benjamin Herrenschmidt
@ 2009-02-22 19:31 ` Thomas Gleixner
-1 siblings, 0 replies; 219+ messages in thread
From: Thomas Gleixner @ 2009-02-22 19:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Paul Collins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar
On Fri, 20 Feb 2009, Benjamin Herrenschmidt wrote:
> On Thu, 2009-02-19 at 21:17 +0100, Thomas Gleixner wrote:
> >
> > Well, harsh or not is not the question here.
> >
> > Fact is that you call gettimeofday() _before_ the timekeeping code has
> > resumed.
> >
> > That's a simple ordering problem. timekeeping is in the sysdev class
> > as well and it's not the only sysdev which has explicit ordering
> > requirements.
>
> And how do I control that ordering ?
>
> I find that a bit fishy ... What about making gettimeofday() in the
> timekeeping code work, just return a frozen snapshot of the value on
> suspend instead ?
We had problems in the past where we just returned frozen time and the
calling code got surprised when the time jumped 5 hours ahead just a
few microseconds later.
What I find more fishy is the fact that the lid switch needs to be a
sysdev. It's a simple input event, which causes the user space code to
trigger the suspend sequence when the lid is shut.
Thanks,
tglx
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-22 19:31 ` Thomas Gleixner
0 siblings, 0 replies; 219+ messages in thread
From: Thomas Gleixner @ 2009-02-22 19:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Paul Collins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar
On Fri, 20 Feb 2009, Benjamin Herrenschmidt wrote:
> On Thu, 2009-02-19 at 21:17 +0100, Thomas Gleixner wrote:
> >
> > Well, harsh or not is not the question here.
> >
> > Fact is that you call gettimeofday() _before_ the timekeeping code has
> > resumed.
> >
> > That's a simple ordering problem. timekeeping is in the sysdev class
> > as well and it's not the only sysdev which has explicit ordering
> > requirements.
>
> And how do I control that ordering ?
>
> I find that a bit fishy ... What about making gettimeofday() in the
> timekeeping code work, just return a frozen snapshot of the value on
> suspend instead ?
We had problems in the past where we just returned frozen time and the
calling code got surprised when the time jumped 5 hours ahead just a
few microseconds later.
What I find more fishy is the fact that the lid switch needs to be a
sysdev. It's a simple input event, which causes the user space code to
trigger the suspend sequence when the lid is shut.
Thanks,
tglx
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-22 20:46 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 219+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-22 20:46 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Paul Collins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar
On Sun, 2009-02-22 at 20:31 +0100, Thomas Gleixner wrote:
> We had problems in the past where we just returned frozen time and the
> calling code got surprised when the time jumped 5 hours ahead just a
> few microseconds later.
>
> What I find more fishy is the fact that the lid switch needs to be a
> sysdev. It's a simple input event, which causes the user space code to
> trigger the suspend sequence when the lid is shut.
>
Well, the PMU is a sysdev for lots of good reasons.. then it -also-
happens to provide us with the lid switch event.
I'm a bit surprised by the explanation about the code that is surprised
to see the time jump. IE. Code -will- see the time jump anyway. IE. I
don't see how making gtod blow instead of returning a frozen time will
make any difference whatsoever for code who get the time some time
before suspend and then some time after resume and see a 5 hours gap...
Cheers,
Ben.
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-22 20:46 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 219+ messages in thread
From: Benjamin Herrenschmidt @ 2009-02-22 20:46 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Paul Collins, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Ingo Molnar
On Sun, 2009-02-22 at 20:31 +0100, Thomas Gleixner wrote:
> We had problems in the past where we just returned frozen time and the
> calling code got surprised when the time jumped 5 hours ahead just a
> few microseconds later.
>
> What I find more fishy is the fact that the lid switch needs to be a
> sysdev. It's a simple input event, which causes the user space code to
> trigger the suspend sequence when the lid is shut.
>
Well, the PMU is a sysdev for lots of good reasons.. then it -also-
happens to provide us with the lid switch event.
I'm a bit surprised by the explanation about the code that is surprised
to see the time jump. IE. Code -will- see the time jump anyway. IE. I
don't see how making gtod blow instead of returning a frozen time will
make any difference whatsoever for code who get the time some time
before suspend and then some time after resume and see a 5 hours gap...
Cheers,
Ben.
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-09 10:32 ` Thomas Gleixner
-1 siblings, 0 replies; 219+ messages in thread
From: Thomas Gleixner @ 2009-02-09 10:32 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Ingo Molnar,
Paul Collins
On Sun, 8 Feb 2009, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12667
> Subject : Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
> Submitter : Paul Collins <paul@burly.ondioline.org>
> Date : 2009-01-21 7:15 (19 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
First bad commit ? The commit adds a WARN_ON to getnstimeofday() when
it is called while timekeeping is suspended. So instead of pointing to
that commit can we please figure out WTF this happens?
Looking at the call stack this is pretty obvious:
[ee4fdc80] [c0053b10] do_gettimeofday+0x1c/0x58
[ee4fdcb0] [c0348868] evdev_event+0x28/0x158
[ee4fdce0] [c0340ce4] input_pass_event+0xac/0xb0
[ee4fdd00] [c0343a44] input_event+0x80/0x98
[ee4fdd20] [c02f6d24] via_pmu_event+0x88/0x8c
[ee4fdd30] [c02f4f60] via_pmu_interrupt+0x6e0/0xb2c
[ee4fdd90] [c02f5664] pmu_wait_complete+0x50/0x84
[ee4fddb0] [c02f6764] powerbook_sleep+0x9f0/0xb24
[ee4fde40] [c00607f8] suspend_devices_and_enter+0x10c/0x180
[ee4fde60] [c0060a1c] enter_state+0x11c/0x160
[ee4fde80] [c02f4404] pmu_ioctl+0x15c/0x24c
[ee4fde90] [c00bab04] vfs_ioctl+0x8c/0x90
[ee4fdea0] [c00babb8] do_vfs_ioctl+0x8c/0x70c
[ee4fdf10] [c00bb2d4] sys_ioctl+0x9c/0xa4
[ee4fdf40] [c0012eb8] ret_from_syscall+0x0/0x38
powerbook_sleep() calls into the event interface which calls
gettimeofday() _AFTER_ timekeeping was suspended already so the
WARN_ON triggers.
Thanks,
tglx
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
@ 2009-02-09 10:32 ` Thomas Gleixner
0 siblings, 0 replies; 219+ messages in thread
From: Thomas Gleixner @ 2009-02-09 10:32 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Ingo Molnar,
Paul Collins
On Sun, 8 Feb 2009, Rafael J. Wysocki wrote:
> This message has been generated automatically as a part of a report
> of recent regressions.
>
> The following bug entry is on the current list of known regressions
> from 2.6.28. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12667
> Subject : Badness at kernel/time/timekeeping.c:98 in pmud (timekeeping_suspended)
> Submitter : Paul Collins <paul-dsjeNyW6Qm/D+ROgJ3VA+kB+6BGkLq7r@public.gmane.org>
> Date : 2009-01-21 7:15 (19 days old)
> First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1c5745aa380efb6417b5681104b007c8612fb496
First bad commit ? The commit adds a WARN_ON to getnstimeofday() when
it is called while timekeeping is suspended. So instead of pointing to
that commit can we please figure out WTF this happens?
Looking at the call stack this is pretty obvious:
[ee4fdc80] [c0053b10] do_gettimeofday+0x1c/0x58
[ee4fdcb0] [c0348868] evdev_event+0x28/0x158
[ee4fdce0] [c0340ce4] input_pass_event+0xac/0xb0
[ee4fdd00] [c0343a44] input_event+0x80/0x98
[ee4fdd20] [c02f6d24] via_pmu_event+0x88/0x8c
[ee4fdd30] [c02f4f60] via_pmu_interrupt+0x6e0/0xb2c
[ee4fdd90] [c02f5664] pmu_wait_complete+0x50/0x84
[ee4fddb0] [c02f6764] powerbook_sleep+0x9f0/0xb24
[ee4fde40] [c00607f8] suspend_devices_and_enter+0x10c/0x180
[ee4fde60] [c0060a1c] enter_state+0x11c/0x160
[ee4fde80] [c02f4404] pmu_ioctl+0x15c/0x24c
[ee4fde90] [c00bab04] vfs_ioctl+0x8c/0x90
[ee4fdea0] [c00babb8] do_vfs_ioctl+0x8c/0x70c
[ee4fdf10] [c00bb2d4] sys_ioctl+0x9c/0xa4
[ee4fdf40] [c0012eb8] ret_from_syscall+0x0/0x38
powerbook_sleep() calls into the event interface which calls
gettimeofday() _AFTER_ timekeeping was suspended already so the
WARN_ON triggers.
Thanks,
tglx
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12671] uvc_status_cleanup(): undefined reference to `input_unregister_device'
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Ingo Molnar
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12671
Subject : uvc_status_cleanup(): undefined reference to `input_unregister_device'
Submitter : Ingo Molnar <mingo@elte.hu>
Date : 2009-02-08 14:58 (1 days old)
References : http://marc.info/?l=linux-kernel&m=123410529909318&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12669] 2.6.28.4 regression: mmap fails if mlockall used
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Hugh Dickins, Sami Farin
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12669
Subject : 2.6.28.4 regression: mmap fails if mlockall used
Submitter : Sami Farin <safari-kernel@safari.iki.fi>
Date : 2009-02-08 10:52 (1 days old)
References : http://marc.info/?l=linux-kernel&m=123409037423068&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* [Bug #12670] BUG: unable to handle kernel paging request at pin_to_kill+0x21
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-08 19:21 ` Rafael J. Wysocki
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 19:21 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Alessandro Bono
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.28. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12670
Subject : BUG: unable to handle kernel paging request at pin_to_kill+0x21
Submitter : Alessandro Bono <alessandro.bono@gmail.com>
Date : 2009-02-08 11:04 (1 days old)
References : http://marc.info/?l=linux-kernel&m=123409113223833&w=4
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: 2.6.29-rc4: Reported regressions from 2.6.28
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
` (44 preceding siblings ...)
2009-02-08 19:21 ` Rafael J. Wysocki
@ 2009-02-08 21:55 ` Linus Torvalds
2009-02-08 21:55 ` Linus Torvalds
` (2 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Linus Torvalds @ 2009-02-08 21:55 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Adrian Bunk, Linux SCSI List, Network Development,
Linux Kernel Mailing List, Natalie Protasevich, Linux ACPI,
Andrew Morton, Kernel Testers List, Linux PM List
On Sun, 8 Feb 2009, Rafael J. Wysocki wrote:
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12669
> Subject : 2.6.28.4 regression: mmap fails if mlockall used
> Submitter : Sami Farin <safari-kernel@safari.iki.fi>
> Date : 2009-02-08 10:52 (1 days old)
> References : http://marc.info/?l=linux-kernel&m=123409037423068&w=4
Oh, Hugh just sent a patch, and it's now commit
d5b562330ec766292a3ac54ae5e0673610bd5b3d. Sadly this just missed -rc4 by
something like 20 minutes..
Linus
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: 2.6.29-rc4: Reported regressions from 2.6.28
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
` (45 preceding siblings ...)
2009-02-08 21:55 ` 2.6.29-rc4: Reported regressions from 2.6.28 Linus Torvalds
@ 2009-02-08 21:55 ` Linus Torvalds
2009-02-08 22:04 ` Rafael J. Wysocki
[not found] ` <alpine.LFD.2.00.0902081354150.3048-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2009-02-08 21:57 ` [linux-pm] " Alan Stern
2009-02-09 7:36 ` Stefan Richter
48 siblings, 2 replies; 219+ messages in thread
From: Linus Torvalds @ 2009-02-08 21:55 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton,
Natalie Protasevich, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List
On Sun, 8 Feb 2009, Rafael J. Wysocki wrote:
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12669
> Subject : 2.6.28.4 regression: mmap fails if mlockall used
> Submitter : Sami Farin <safari-kernel@safari.iki.fi>
> Date : 2009-02-08 10:52 (1 days old)
> References : http://marc.info/?l=linux-kernel&m=123409037423068&w=4
Oh, Hugh just sent a patch, and it's now commit
d5b562330ec766292a3ac54ae5e0673610bd5b3d. Sadly this just missed -rc4 by
something like 20 minutes..
Linus
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: 2.6.29-rc4: Reported regressions from 2.6.28
2009-02-08 21:55 ` Linus Torvalds
@ 2009-02-08 22:04 ` Rafael J. Wysocki
[not found] ` <alpine.LFD.2.00.0902081354150.3048-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
1 sibling, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 22:04 UTC (permalink / raw)
To: Linus Torvalds
Cc: Adrian Bunk, Linux SCSI List, Network Development,
Linux Kernel Mailing List, Natalie Protasevich, Linux ACPI,
Andrew Morton, Kernel Testers List, Linux PM List
On Sunday 08 February 2009, Linus Torvalds wrote:
>
> On Sun, 8 Feb 2009, Rafael J. Wysocki wrote:
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12669
> > Subject : 2.6.28.4 regression: mmap fails if mlockall used
> > Submitter : Sami Farin <safari-kernel@safari.iki.fi>
> > Date : 2009-02-08 10:52 (1 days old)
> > References : http://marc.info/?l=linux-kernel&m=123409037423068&w=4
>
> Oh, Hugh just sent a patch, and it's now commit
> d5b562330ec766292a3ac54ae5e0673610bd5b3d. Sadly this just missed -rc4 by
> something like 20 minutes..
Yes, I saw the Hugh's message right after sending the report.
Bug closed.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
[parent not found: <alpine.LFD.2.00.0902081354150.3048-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>]
* Re: 2.6.29-rc4: Reported regressions from 2.6.28
2009-02-08 21:55 ` Linus Torvalds
@ 2009-02-08 22:04 ` Rafael J. Wysocki
[not found] ` <alpine.LFD.2.00.0902081354150.3048-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
1 sibling, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 22:04 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton,
Natalie Protasevich, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List
On Sunday 08 February 2009, Linus Torvalds wrote:
>
> On Sun, 8 Feb 2009, Rafael J. Wysocki wrote:
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12669
> > Subject : 2.6.28.4 regression: mmap fails if mlockall used
> > Submitter : Sami Farin <safari-kernel-nmB1AuG+Lnw9NyIDpsMsJw@public.gmane.org>
> > Date : 2009-02-08 10:52 (1 days old)
> > References : http://marc.info/?l=linux-kernel&m=123409037423068&w=4
>
> Oh, Hugh just sent a patch, and it's now commit
> d5b562330ec766292a3ac54ae5e0673610bd5b3d. Sadly this just missed -rc4 by
> something like 20 minutes..
Yes, I saw the Hugh's message right after sending the report.
Bug closed.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: 2.6.29-rc4: Reported regressions from 2.6.28
@ 2009-02-08 22:04 ` Rafael J. Wysocki
0 siblings, 0 replies; 219+ messages in thread
From: Rafael J. Wysocki @ 2009-02-08 22:04 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton,
Natalie Protasevich, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List
On Sunday 08 February 2009, Linus Torvalds wrote:
>
> On Sun, 8 Feb 2009, Rafael J. Wysocki wrote:
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12669
> > Subject : 2.6.28.4 regression: mmap fails if mlockall used
> > Submitter : Sami Farin <safari-kernel@safari.iki.fi>
> > Date : 2009-02-08 10:52 (1 days old)
> > References : http://marc.info/?l=linux-kernel&m=123409037423068&w=4
>
> Oh, Hugh just sent a patch, and it's now commit
> d5b562330ec766292a3ac54ae5e0673610bd5b3d. Sadly this just missed -rc4 by
> something like 20 minutes..
Yes, I saw the Hugh's message right after sending the report.
Bug closed.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: [linux-pm] 2.6.29-rc4: Reported regressions from 2.6.28
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
` (46 preceding siblings ...)
2009-02-08 21:55 ` Linus Torvalds
@ 2009-02-08 21:57 ` Alan Stern
2009-02-09 0:43 ` Rafael J. Wysocki
2009-02-09 7:36 ` Stefan Richter
48 siblings, 1 reply; 219+ messages in thread
From: Alan Stern @ 2009-02-08 21:57 UTC (permalink / raw)
To: Vegard Nossum, Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Natalie Protasevich
On Sun, 8 Feb 2009, Rafael J. Wysocki wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12668
> Subject : USB flash disk surprise disconnect
> Submitter : Vegard Nossum <vegard.nossum@gmail.com>
> Date : 2009-02-08 10:21 (1 days old)
> References : http://marc.info/?l=linux-kernel&m=123408851821292&w=4
Is there any reason to think this is a regression rather than a
one-time fluke?
If it really is a regression, additional debugging info would help.
The log excerpt in the email report doesn't show anything that happened
prior to the disconnect.
Alan Stern
^ permalink raw reply [flat|nested] 219+ messages in thread
* Re: 2.6.29-rc4: Reported regressions from 2.6.28
2009-02-08 19:05 2.6.29-rc4: Reported regressions from 2.6.28 Rafael J. Wysocki
@ 2009-02-09 7:36 ` Stefan Richter
2009-02-08 19:21 ` Rafael J. Wysocki
` (47 subsequent siblings)
48 siblings, 0 replies; 219+ messages in thread
From: Stefan Richter @ 2009-02-09 7:36 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton,
Linus Torvalds, Natalie Protasevich, Kernel Testers List
Rafael J. Wysocki wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12600
> Subject : i915 lockdep warning
> Submitter : Brandeburg, Jesse <jesse.brandeburg@intel.com>
> Date : 2009-01-13 23:17 (27 days old)
> References : http://marc.info/?l=linux-kernel&m=123188898423532&w=4
Now closed as duplicate of
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=12491
> Subject : i915 lockdep warning
> Submitter : Brandeburg, Jesse <jesse.brandeburg@intel.com>
> Date : 2009-01-13 23:17 (27 days old)
> References : http://marc.info/?l=linux-kernel&m=123188898423532&w=4
> Handled-By : Roland Dreier <rolandd@cisco.com>
> Patch : http://marc.info/?l=linux-kernel&m=123378709730700&w=2
--
Stefan Richter
-=====-==--= --=- -=--=
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 219+ messages in thread