* [Bug #14277] Caught 8-bit read from freed memory in b43 driver at association
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
@ 2009-10-26 18:45 ` Rafael J. Wysocki
2009-10-26 18:55 ` [Bug #14302] Kernel panic on i386 machine when booting with profile=2 Rafael J. Wysocki
` (40 subsequent siblings)
41 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:45 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Christian Casteyde
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14277
Subject : Caught 8-bit read from freed memory in b43 driver at association
Submitter : Christian Casteyde <casteyde.christian-GANU6spQydw@public.gmane.org>
Date : 2009-09-30 18:06 (27 days old)
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14302] Kernel panic on i386 machine when booting with profile=2
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
2009-10-26 18:45 ` [Bug #14277] Caught 8-bit read from freed memory in b43 driver at association Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 18:55 ` [Bug #14331] Radeon XPRESS 200M: System hang with radeon DRI and Fedora 10 userspace unless DRI=off Rafael J. Wysocki
` (39 subsequent siblings)
41 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Alex Shi, Ingo Molnar, Shi, Alex
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14302
Subject : Kernel panic on i386 machine when booting with profile=2
Submitter : Shi, Alex <alex.shi@intel.com>
Date : 2009-10-01 3:23 (26 days old)
References : http://marc.info/?l=linux-kernel&m=125436749607199&w=4
Handled-By : Alex Shi <alex.shi@intel.com>
Patch : http://patchwork.kernel.org/patch/50813/
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14331] Radeon XPRESS 200M: System hang with radeon DRI and Fedora 10 userspace unless DRI=off
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
2009-10-26 18:45 ` [Bug #14277] Caught 8-bit read from freed memory in b43 driver at association Rafael J. Wysocki
2009-10-26 18:55 ` [Bug #14302] Kernel panic on i386 machine when booting with profile=2 Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 18:55 ` [Bug #14298] warning at manage.c:361 (set_irq_wake), matrix-keypad related? Rafael J. Wysocki
` (38 subsequent siblings)
41 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Alex Villacis Lasso
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14331
Subject : Radeon XPRESS 200M: System hang with radeon DRI and Fedora 10 userspace unless DRI=off
Submitter : Alex Villacis Lasso <avillaci-x0m+Mc+nT7uljOmnV8AmnkElSqmLX1BE@public.gmane.org>
Date : 2009-10-06 00:29 (21 days old)
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14298] warning at manage.c:361 (set_irq_wake), matrix-keypad related?
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (2 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14331] Radeon XPRESS 200M: System hang with radeon DRI and Fedora 10 userspace unless DRI=off Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 18:55 ` [Bug #14297] console resume broken since ba15ab0e8d Rafael J. Wysocki
` (37 subsequent siblings)
41 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Pavel Machek
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14298
Subject : warning at manage.c:361 (set_irq_wake), matrix-keypad related?
Submitter : Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
Date : 2009-09-30 20:07 (27 days old)
References : http://marc.info/?l=linux-kernel&m=125434130703538&w=4
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14297] console resume broken since ba15ab0e8d
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (3 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14298] warning at manage.c:361 (set_irq_wake), matrix-keypad related? Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 18:55 ` [Bug #14296] spitz boots but suspend/resume is broken Rafael J. Wysocki
` (36 subsequent siblings)
41 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Alan Cox, Deepak Saxena, Greg Kroah-Hartman,
Sascha Hauer
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14297
Subject : console resume broken since ba15ab0e8d
Submitter : Sascha Hauer <s.hauer@pengutronix.de>
Date : 2009-09-30 15:11 (27 days old)
References : http://marc.info/?l=linux-kernel&m=125432349404060&w=4
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14296] spitz boots but suspend/resume is broken
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (4 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14297] console resume broken since ba15ab0e8d Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 18:55 ` [Bug #14299] oops in wireless, iwl3945 related? Rafael J. Wysocki
` (35 subsequent siblings)
41 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Dmitry Eremin-Solenikov, Eric Miao,
Pavel Machek
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14296
Subject : spitz boots but suspend/resume is broken
Submitter : Pavel Machek <pavel@ucw.cz>
Date : 2009-09-30 12:06 (27 days old)
References : http://marc.info/?l=linux-kernel&m=125431244516449&w=4
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14299] oops in wireless, iwl3945 related?
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (5 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14296] spitz boots but suspend/resume is broken Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-27 0:46 ` Pavel Machek
2009-10-26 18:55 ` [Bug #14354] Bad corruption with 2.6.32-rc1 and upwards Rafael J. Wysocki
` (34 subsequent siblings)
41 siblings, 1 reply; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Johannes Berg, Pavel Machek, 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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14299
Subject : oops in wireless, iwl3945 related?
Submitter : Pavel Machek <pavel@ucw.cz>
Date : 2009-09-29 17:12 (28 days old)
References : http://marc.info/?l=linux-kernel&m=125424439725743&w=4
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [Bug #14299] oops in wireless, iwl3945 related?
2009-10-26 18:55 ` [Bug #14299] oops in wireless, iwl3945 related? Rafael J. Wysocki
@ 2009-10-27 0:46 ` Pavel Machek
[not found] ` <20091027004600.GD5019-I/5MKhXcvmPrBKCeMvbIDA@public.gmane.org>
0 siblings, 1 reply; 128+ messages in thread
From: Pavel Machek @ 2009-10-27 0:46 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Johannes Berg,
reinette chatre
On Mon 2009-10-26 19:55:50, 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.31. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14299
> Subject : oops in wireless, iwl3945 related?
> Submitter : Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
> Date : 2009-09-29 17:12 (28 days old)
> References : http://marc.info/?l=linux-kernel&m=125424439725743&w=4
It did not happen again, and there were some fixes in that area. (It
happened 2 times total). Close it, I guess?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 128+ messages in thread
* [Bug #14354] Bad corruption with 2.6.32-rc1 and upwards
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (6 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14299] oops in wireless, iwl3945 related? Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 18:55 ` [Bug #14353] BUG: sleeping function called from invalid context at kernel/mutex.c:280 Rafael J. Wysocki
` (33 subsequent siblings)
41 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Frank Mayhar, Holger Freyther,
Theodore Ts'o
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14354
Subject : Bad corruption with 2.6.32-rc1 and upwards
Submitter : Holger Freyther <zecke-MQnelBtSfJRAfugRpC6u6w@public.gmane.org>
Date : 2009-10-09 15:42 (18 days old)
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14353] BUG: sleeping function called from invalid context at kernel/mutex.c:280
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (7 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14354] Bad corruption with 2.6.32-rc1 and upwards Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 19:11 ` Johannes Berg
2009-10-26 18:55 ` [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m Rafael J. Wysocki
` (32 subsequent siblings)
41 siblings, 1 reply; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Johannes Berg, Miles Lane
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14353
Subject : BUG: sleeping function called from invalid context at kernel/mutex.c:280
Submitter : Miles Lane <miles.lane-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-10-05 3:39 (22 days old)
References : http://marc.info/?l=linux-kernel&m=125471432208671&w=4
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (8 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14353] BUG: sleeping function called from invalid context at kernel/mutex.c:280 Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-30 18:48 ` Help needed, " Rafael J. Wysocki
2009-10-26 18:55 ` [Bug #14352] WARNING: at net/mac80211/scan.c:267 Rafael J. Wysocki
` (31 subsequent siblings)
41 siblings, 1 reply; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Greg Kroah-Hartman, Jose Marino,
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14334
Subject : pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
Submitter : Jose Marino <braket-PkbjNfxxIARBDgjK7y7TUQ@public.gmane.org>
Date : 2009-10-06 15:44 (21 days old)
^ permalink raw reply [flat|nested] 128+ messages in thread* Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
2009-10-26 18:55 ` [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m Rafael J. Wysocki
@ 2009-10-30 18:48 ` Rafael J. Wysocki
2009-10-30 19:47 ` Linus Torvalds
0 siblings, 1 reply; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-30 18:48 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Greg Kroah-Hartman, Jose Marino,
ACPI Devel Maling List, Linux PCI, Linus Torvalds,
Dominik Brodowski
Hi,
On Monday 26 October 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.31. Please verify if it still should be listed and let me know
> (either way).
Here's a puzzle for whoever likes hardware detective work.
Suspend to RAM worked just fine on the Jose's box before commit
53024df259e37ad49ee3d1f3721d4cecdd7bc357 (PM / yenta: Fix cardbus
suspend/resume regression, mainline commit
0c570cdeb8fdfcb354a3e9cd81bfc6a09c19de0c) that made the resume of CardBus
devices actually work. After this commit, the box hangs during resume 100% of
the time.
We've done quite some debugging and here's the summary of findings:
1) Resume works if pcmcia_socket_dev_resume(dev) is moved to the "regular"
resume phase, after resume_device_irqs().
2) Resume works if yenta_set_power() is not called during resume
(from yenta_set_socket()).
3) It doesn't help to resume all ACPI devices before yenta.
4) It doesn't help to disable yenta events during resume (unconditionally).
5) There are two CardBus bridges in the box and according to the PM_TRACE
information the _second_ one is the last device we attempt to wake up
during a failing resume.
Please look into http://bugzilla.kernel.org/show_bug.cgi?id=14334 for details.
OK, any ideas anyone?
Rafael
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
2009-10-30 18:48 ` Help needed, " Rafael J. Wysocki
@ 2009-10-30 19:47 ` Linus Torvalds
2009-10-30 20:32 ` Rafael J. Wysocki
2009-10-30 23:57 ` Benjamin Herrenschmidt
0 siblings, 2 replies; 128+ messages in thread
From: Linus Torvalds @ 2009-10-30 19:47 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List,
Greg Kroah-Hartman, Jose Marino, ACPI Devel Maling List,
Linux PCI, Dominik Brodowski
On Fri, 30 Oct 2009, Rafael J. Wysocki wrote:
>
>
> 1) Resume works if pcmcia_socket_dev_resume(dev) is moved to the "regular"
> resume phase, after resume_device_irqs().
Hmm. We really probably shouldn't call pcmcia_socket_dev_resume() in
early_resume. It takes mutexes etc, and it calls "socket_resume()", which
sleeps etc. That per se should be ok these days (since we don't actualyl
disable CPU irq's, just device irqs), but it also does that whole card
insertion events etc. And _that_ code I wouldn't trust at all.
The PCMCIA code is better than it used to be a long time ago, but some of
it is still pretty crazy.
I get the feeling that we should just revert that commit 0c570cdeb, and
instead always do PCMCIA suspend as a "eject" event. That way we have no
driver behind it to resume at resume time - and we'll see any plugged-in
device as just a new insertion.
Linus
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
2009-10-30 19:47 ` Linus Torvalds
@ 2009-10-30 20:32 ` Rafael J. Wysocki
2009-10-30 20:40 ` Linus Torvalds
2009-10-30 23:57 ` Benjamin Herrenschmidt
1 sibling, 1 reply; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-30 20:32 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Kernel Testers List,
Greg Kroah-Hartman, Jose Marino, ACPI Devel Maling List,
Linux PCI, Dominik Brodowski
On Friday 30 October 2009, Linus Torvalds wrote:
>
> On Fri, 30 Oct 2009, Rafael J. Wysocki wrote:
> >
> >
> > 1) Resume works if pcmcia_socket_dev_resume(dev) is moved to the "regular"
> > resume phase, after resume_device_irqs().
>
> Hmm. We really probably shouldn't call pcmcia_socket_dev_resume() in
> early_resume. It takes mutexes etc, and it calls "socket_resume()", which
> sleeps etc. That per se should be ok these days (since we don't actualyl
> disable CPU irq's, just device irqs), but it also does that whole card
> insertion events etc. And _that_ code I wouldn't trust at all.
I thought so when I worked on commit 0c570cdeb, but then it turned out to
work just fine with a number of boxes.
> The PCMCIA code is better than it used to be a long time ago, but some of
> it is still pretty crazy.
>
> I get the feeling that we should just revert that commit 0c570cdeb,
Well, there's nothing wrong with doing the PCI stuff and restoring the state at
the _noirq stage IMO, so instead of reverting it altogether, I'd add
yenta_dev_suspend|resume() that would just call
pcmcia_socket_dev_suspend|resume() during "regular" suspend|resume.
> and instead always do PCMCIA suspend as a "eject" event. That way we have no
> driver behind it to resume at resume time - and we'll see any plugged-in
> device as just a new insertion.
In fact I thought about that.
It looks like I need to find a CardBus adapter somewhere and clean that thing up.
That said, I'd really like to know what's going on in there. :-)
Thanks,
Rafael
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
2009-10-30 20:32 ` Rafael J. Wysocki
@ 2009-10-30 20:40 ` Linus Torvalds
2009-10-30 21:17 ` Linus Torvalds
0 siblings, 1 reply; 128+ messages in thread
From: Linus Torvalds @ 2009-10-30 20:40 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List,
Greg Kroah-Hartman, Jose Marino, ACPI Devel Maling List,
Linux PCI, Dominik Brodowski
On Fri, 30 Oct 2009, Rafael J. Wysocki wrote:
> On Friday 30 October 2009, Linus Torvalds wrote:
> > The PCMCIA code is better than it used to be a long time ago, but some of
> > it is still pretty crazy.
> >
> > I get the feeling that we should just revert that commit 0c570cdeb,
>
> Well, there's nothing wrong with doing the PCI stuff and restoring the state at
> the _noirq stage IMO, so instead of reverting it altogether, I'd add
> yenta_dev_suspend|resume() that would just call
> pcmcia_socket_dev_suspend|resume() during "regular" suspend|resume.
Oh, that sounds fine too. I didn't mean that we had to do an outright
revert, since we'd still need to do something else to fix the original
issue.
> > and instead always do PCMCIA suspend as a "eject" event. That way we have no
> > driver behind it to resume at resume time - and we'll see any plugged-in
> > device as just a new insertion.
>
> In fact I thought about that.
>
> It looks like I need to find a CardBus adapter somewhere and clean that thing up.
>
> That said, I'd really like to know what's going on in there. :-)
I have to admit that my last two laptops haven't even _had_ a PCMCIA slot,
so I'm unlikely to be able to help much. But I could dig out an old one,
and try to find the one wireless card I know I have in some corner.
And partly exactly _because_ even Cardbus is starting to be "legacy", I'd
personally prefer to try to simplify the model to the point where we don't
have to think about all the subtle interactions. Just making suspend act
as an eject would mean that we'd never have to worry about how the CardBus
bridge interacts with the PCI layer at suspend/resume time.
Linus
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
2009-10-30 20:40 ` Linus Torvalds
@ 2009-10-30 21:17 ` Linus Torvalds
[not found] ` <alpine.LFD.2.01.0910301412500.31845-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2009-10-30 23:54 ` Benjamin Herrenschmidt
0 siblings, 2 replies; 128+ messages in thread
From: Linus Torvalds @ 2009-10-30 21:17 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List,
Greg Kroah-Hartman, Jose Marino, ACPI Devel Maling List,
Linux PCI, Dominik Brodowski
On Fri, 30 Oct 2009, Linus Torvalds wrote:
>
> And partly exactly _because_ even Cardbus is starting to be "legacy", I'd
> personally prefer to try to simplify the model to the point where we don't
> have to think about all the subtle interactions. Just making suspend act
> as an eject would mean that we'd never have to worry about how the CardBus
> bridge interacts with the PCI layer at suspend/resume time.
Put another way: five years ago I would have felt that it could be
important that people can suspend and resume while they have a CD-ROM
mounted through a PCMCIA IDE card. Or something like that where you want
to keep session information.
These days, that scenario is less interesting to begin with, and we're
generally better at some of the hotplug issues anyway. Example: one of the
reasons I used to like not causing an unplug event was because I had
network cards, and hated setting up the connection again. These days, all
distros come with networkmanager or similar, and hotplug networking just
works (even if the "CD-ROM mounted" case probably still would cause
problems).
So I think we used to have good reasons to try to maintain state over a
suspend event, but many of those reasons have become weaker, while at the
same time USB has meant that PCMCIA itself has become more of a
"maintenance burden" rather than a "primary subsystem".
Linus
^ permalink raw reply [flat|nested] 128+ messages in thread[parent not found: <alpine.LFD.2.01.0910301412500.31845-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>]
* Re: Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
[not found] ` <alpine.LFD.2.01.0910301412500.31845-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
@ 2009-10-30 22:17 ` Rafael J. Wysocki
0 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-30 22:17 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Kernel Testers List,
Greg Kroah-Hartman, Jose Marino, ACPI Devel Maling List,
Linux PCI, Dominik Brodowski
On Friday 30 October 2009, Linus Torvalds wrote:
>
> On Fri, 30 Oct 2009, Linus Torvalds wrote:
> >
> > And partly exactly _because_ even Cardbus is starting to be "legacy", I'd
> > personally prefer to try to simplify the model to the point where we don't
> > have to think about all the subtle interactions. Just making suspend act
> > as an eject would mean that we'd never have to worry about how the CardBus
> > bridge interacts with the PCI layer at suspend/resume time.
>
> Put another way: five years ago I would have felt that it could be
> important that people can suspend and resume while they have a CD-ROM
> mounted through a PCMCIA IDE card. Or something like that where you want
> to keep session information.
>
> These days, that scenario is less interesting to begin with, and we're
> generally better at some of the hotplug issues anyway. Example: one of the
> reasons I used to like not causing an unplug event was because I had
> network cards, and hated setting up the connection again. These days, all
> distros come with networkmanager or similar, and hotplug networking just
> works (even if the "CD-ROM mounted" case probably still would cause
> problems).
>
> So I think we used to have good reasons to try to maintain state over a
> suspend event, but many of those reasons have become weaker, while at the
> same time USB has meant that PCMCIA itself has become more of a
> "maintenance burden" rather than a "primary subsystem".
I agree.
Rafael
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
2009-10-30 21:17 ` Linus Torvalds
[not found] ` <alpine.LFD.2.01.0910301412500.31845-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
@ 2009-10-30 23:54 ` Benjamin Herrenschmidt
1 sibling, 0 replies; 128+ messages in thread
From: Benjamin Herrenschmidt @ 2009-10-30 23:54 UTC (permalink / raw)
To: Linus Torvalds
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List,
Greg Kroah-Hartman, Jose Marino, ACPI Devel Maling List,
Linux PCI, Dominik Brodowski
> Put another way: five years ago I would have felt that it could be
> important that people can suspend and resume while they have a CD-ROM
> mounted through a PCMCIA IDE card. Or something like that where you want
> to keep session information.
I think you are a bit too much laptop centric :-) It's sadly still
common in the embedded space to use PCMCIA or Cardbus for ... root
filesystems.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
2009-10-30 19:47 ` Linus Torvalds
2009-10-30 20:32 ` Rafael J. Wysocki
@ 2009-10-30 23:57 ` Benjamin Herrenschmidt
2009-10-31 9:31 ` Rafael J. Wysocki
1 sibling, 1 reply; 128+ messages in thread
From: Benjamin Herrenschmidt @ 2009-10-30 23:57 UTC (permalink / raw)
To: Linus Torvalds
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List,
Greg Kroah-Hartman, Jose Marino, ACPI Devel Maling List,
Linux PCI, Dominik Brodowski
On Fri, 2009-10-30 at 12:47 -0700, Linus Torvalds wrote:
>
> On Fri, 30 Oct 2009, Rafael J. Wysocki wrote:
> >
> >
> > 1) Resume works if pcmcia_socket_dev_resume(dev) is moved to the "regular"
> > resume phase, after resume_device_irqs().
>
> Hmm. We really probably shouldn't call pcmcia_socket_dev_resume() in
> early_resume. It takes mutexes etc, and it calls "socket_resume()", which
> sleeps etc. That per se should be ok these days (since we don't actualyl
> disable CPU irq's, just device irqs), but it also does that whole card
> insertion events etc. And _that_ code I wouldn't trust at all.
>
> The PCMCIA code is better than it used to be a long time ago, but some of
> it is still pretty crazy.
>
> I get the feeling that we should just revert that commit 0c570cdeb, and
> instead always do PCMCIA suspend as a "eject" event. That way we have no
> driver behind it to resume at resume time - and we'll see any plugged-in
> device as just a new insertion.
To me the proper approach would be to split it so that
- early_resume() restores power & config space etc... so that existing
devices can move on (might check for removal). There's no other hotplug
activity
- normal resume() restarts handling of events such as insertions
Now, while I do have some cardbus & pcmcia stuff somewhere, I also don't
have much time to hack on this right now...
Cheers,
Ben.
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
2009-10-30 23:57 ` Benjamin Herrenschmidt
@ 2009-10-31 9:31 ` Rafael J. Wysocki
2009-10-31 21:01 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-31 9:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linus Torvalds, Linux Kernel Mailing List, Kernel Testers List,
Greg Kroah-Hartman, Jose Marino, ACPI Devel Maling List,
Linux PCI, Dominik Brodowski
On Saturday 31 October 2009, Benjamin Herrenschmidt wrote:
> On Fri, 2009-10-30 at 12:47 -0700, Linus Torvalds wrote:
> >
> > On Fri, 30 Oct 2009, Rafael J. Wysocki wrote:
> > >
> > >
> > > 1) Resume works if pcmcia_socket_dev_resume(dev) is moved to the "regular"
> > > resume phase, after resume_device_irqs().
> >
> > Hmm. We really probably shouldn't call pcmcia_socket_dev_resume() in
> > early_resume. It takes mutexes etc, and it calls "socket_resume()", which
> > sleeps etc. That per se should be ok these days (since we don't actualyl
> > disable CPU irq's, just device irqs), but it also does that whole card
> > insertion events etc. And _that_ code I wouldn't trust at all.
> >
> > The PCMCIA code is better than it used to be a long time ago, but some of
> > it is still pretty crazy.
> >
> > I get the feeling that we should just revert that commit 0c570cdeb, and
> > instead always do PCMCIA suspend as a "eject" event. That way we have no
> > driver behind it to resume at resume time - and we'll see any plugged-in
> > device as just a new insertion.
>
> To me the proper approach would be to split it so that
Well, agreed, but ...
> - early_resume() restores power & config space etc... so that existing
> devices can move on (might check for removal). There's no other hotplug
> activity
... that's exactly what doesn't work at the moment.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
2009-10-31 9:31 ` Rafael J. Wysocki
@ 2009-10-31 21:01 ` Benjamin Herrenschmidt
2009-10-31 21:27 ` Rafael J. Wysocki
0 siblings, 1 reply; 128+ messages in thread
From: Benjamin Herrenschmidt @ 2009-10-31 21:01 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linus Torvalds, Linux Kernel Mailing List, Kernel Testers List,
Greg Kroah-Hartman, Jose Marino, ACPI Devel Maling List,
Linux PCI, Dominik Brodowski
On Sat, 2009-10-31 at 10:31 +0100, Rafael J. Wysocki wrote:
> > To me the proper approach would be to split it so that
>
> Well, agreed, but ...
>
> > - early_resume() restores power & config space etc... so that existing
> > devices can move on (might check for removal). There's no other hotplug
> > activity
>
> ... that's exactly what doesn't work at the moment.
BTW. This is a PCMCIA problem, a Cardbus or both ? I'll see if I can dig
something on monday ?
From the little email history I caught, it smells like pcmcia old style.
I don't see a problem per-se with the mutex usage with the new interrupt
masking style as Linus says. socket_resume() also looks reasonably sane,
it's the whole handling of removal that should be deferred. Maybe
instead of doing socket_remove_drivers()...send_event() etc.. in there,
we could simply just shut the socket down (PCMCIA drivers should cope
with sockets returning ffff's for a short amount of time), flag it dead
in skt->state and have the "late" resume actually fire off the driver
removal and sending of the event.
BTW. Have we ever documented whether it's kosher to ->remove() a driver
before ->resume()'ing it ? (In which case obviously we wouldn't resume
it).
Cheers,
Ben.
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
2009-10-31 21:01 ` Benjamin Herrenschmidt
@ 2009-10-31 21:27 ` Rafael J. Wysocki
2009-10-31 21:44 ` Linus Torvalds
[not found] ` <200910312227.15493.rjw-KKrjLPT3xs0@public.gmane.org>
0 siblings, 2 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-31 21:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linus Torvalds, Linux Kernel Mailing List, Kernel Testers List,
Greg Kroah-Hartman, Jose Marino, ACPI Devel Maling List,
Linux PCI, Dominik Brodowski
On Saturday 31 October 2009, Benjamin Herrenschmidt wrote:
> On Sat, 2009-10-31 at 10:31 +0100, Rafael J. Wysocki wrote:
>
> > > To me the proper approach would be to split it so that
> >
> > Well, agreed, but ...
> >
> > > - early_resume() restores power & config space etc... so that existing
> > > devices can move on (might check for removal). There's no other hotplug
> > > activity
> >
> > ... that's exactly what doesn't work at the moment.
>
> BTW. This is a PCMCIA problem, a Cardbus or both ?
I _think_ it's a CardBus problem. Evidently, it only happens if the second
CardBus bridge is resumed right after the first one (which resumes entirely
correctly) and only if that happens in the early resume phase (ie. before
resume_device_irqs()).
> I'll see if I can dig something on monday ?
In the meantime I invented a patch that works, ie. apparently fixes the problem
and if there was a card in the socket during the suspend, it's standard config
space is restored correctly. I tested it on one of my boxes with two different
CardBus adapters and Jose says it fixes the problem for him.
The patch is appended, please have a look.
> >From the little email history I caught, it smells like pcmcia old style.
>
> I don't see a problem per-se with the mutex usage with the new interrupt
> masking style as Linus says. socket_resume() also looks reasonably sane,
> it's the whole handling of removal that should be deferred.
In the failing case we don't even get there. There are two CardBus bridges in
the system, but both sockets are empty, so we take the socket_insert() code
path.
> Maybe instead of doing socket_remove_drivers()...send_event() etc.. in there,
> we could simply just shut the socket down (PCMCIA drivers should cope
> with sockets returning ffff's for a short amount of time), flag it dead
> in skt->state and have the "late" resume actually fire off the driver
> removal and sending of the event.
>
> BTW. Have we ever documented whether it's kosher to ->remove() a driver
> before ->resume()'ing it ? (In which case obviously we wouldn't resume
> it).
The PM core doesn't have a problem with that. Whether or not it's sane from
the driver design point of view is a separate question, though.
Thanks,
Rafael
---
From: Rafael J. Wysocki <rjw@sisk.pl>
Subject: PM / yenta: Split resume into early and late parts
Commit 0c570cdeb8fdfcb354a3e9cd81bfc6a09c19de0c
(PM / yenta: Fix cardbus suspend/resume regression) caused resume to
fail on systems with two CardBus bridges. While the exact nature
of the failure is not known at the moment, it can be worked around by
splitting the yenta resume into an early part, executed during the
early phase of resume, that will only resume the socket and power it
up if there was a card in it during suspend, and a late part,
executed during "regular" resume, that will carry out all of the
remaining yenta resume operations.
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=14334, which is a
listed regression from 2.6.31.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
drivers/pcmcia/cs.c | 79 +++++++++++++++++++++++++++++-------------
drivers/pcmcia/yenta_socket.c | 12 +++++-
include/pcmcia/ss.h | 2 +
3 files changed, 68 insertions(+), 25 deletions(-)
Index: linux-2.6/drivers/pcmcia/yenta_socket.c
===================================================================
--- linux-2.6.orig/drivers/pcmcia/yenta_socket.c
+++ linux-2.6/drivers/pcmcia/yenta_socket.c
@@ -1275,16 +1275,26 @@ static int yenta_dev_resume_noirq(struct
if (socket->type && socket->type->restore_state)
socket->type->restore_state(socket);
- return pcmcia_socket_dev_resume(dev);
+ pcmcia_socket_dev_early_resume(dev);
+ return 0;
+}
+
+static int yenta_dev_resume(struct device *dev)
+{
+ pcmcia_socket_dev_late_resume(dev);
+ return 0;
}
static struct dev_pm_ops yenta_pm_ops = {
.suspend_noirq = yenta_dev_suspend_noirq,
.resume_noirq = yenta_dev_resume_noirq,
+ .resume = yenta_dev_resume,
.freeze_noirq = yenta_dev_suspend_noirq,
.thaw_noirq = yenta_dev_resume_noirq,
+ .thaw = yenta_dev_resume,
.poweroff_noirq = yenta_dev_suspend_noirq,
.restore_noirq = yenta_dev_resume_noirq,
+ .restore = yenta_dev_resume,
};
#define YENTA_PM_OPS (¥ta_pm_ops)
Index: linux-2.6/drivers/pcmcia/cs.c
===================================================================
--- linux-2.6.orig/drivers/pcmcia/cs.c
+++ linux-2.6/drivers/pcmcia/cs.c
@@ -98,10 +98,13 @@ EXPORT_SYMBOL(pcmcia_socket_list_rwsem);
* These functions check for the appropriate struct pcmcia_soket arrays,
* and pass them to the low-level functions pcmcia_{suspend,resume}_socket
*/
+static int socket_early_resume(struct pcmcia_socket *skt);
+static int socket_late_resume(struct pcmcia_socket *skt);
static int socket_resume(struct pcmcia_socket *skt);
static int socket_suspend(struct pcmcia_socket *skt);
-int pcmcia_socket_dev_suspend(struct device *dev)
+static void pcmcia_socket_dev_run(struct device *dev,
+ int (*cb)(struct pcmcia_socket *))
{
struct pcmcia_socket *socket;
@@ -110,29 +113,34 @@ int pcmcia_socket_dev_suspend(struct dev
if (socket->dev.parent != dev)
continue;
mutex_lock(&socket->skt_mutex);
- socket_suspend(socket);
+ cb(socket);
mutex_unlock(&socket->skt_mutex);
}
up_read(&pcmcia_socket_list_rwsem);
+}
+int pcmcia_socket_dev_suspend(struct device *dev)
+{
+ pcmcia_socket_dev_run(dev, socket_suspend);
return 0;
}
EXPORT_SYMBOL(pcmcia_socket_dev_suspend);
-int pcmcia_socket_dev_resume(struct device *dev)
+void pcmcia_socket_dev_early_resume(struct device *dev)
{
- struct pcmcia_socket *socket;
+ pcmcia_socket_dev_run(dev, socket_early_resume);
+}
+EXPORT_SYMBOL(pcmcia_socket_dev_early_resume);
- down_read(&pcmcia_socket_list_rwsem);
- list_for_each_entry(socket, &pcmcia_socket_list, socket_list) {
- if (socket->dev.parent != dev)
- continue;
- mutex_lock(&socket->skt_mutex);
- socket_resume(socket);
- mutex_unlock(&socket->skt_mutex);
- }
- up_read(&pcmcia_socket_list_rwsem);
+void pcmcia_socket_dev_late_resume(struct device *dev)
+{
+ pcmcia_socket_dev_run(dev, socket_late_resume);
+}
+EXPORT_SYMBOL(pcmcia_socket_dev_late_resume);
+int pcmcia_socket_dev_resume(struct device *dev)
+{
+ pcmcia_socket_dev_run(dev, socket_resume);
return 0;
}
EXPORT_SYMBOL(pcmcia_socket_dev_resume);
@@ -546,23 +554,30 @@ static int socket_suspend(struct pcmcia_
return 0;
}
-/*
- * Resume a socket. If a card is present, verify its CIS against
- * our cached copy. If they are different, the card has been
- * replaced, and we need to tell the drivers.
- */
-static int socket_resume(struct pcmcia_socket *skt)
+static void socket_start_resume(struct pcmcia_socket *skt)
{
- int ret;
-
- if (!(skt->state & SOCKET_SUSPEND))
- return -EBUSY;
-
skt->socket = dead_socket;
skt->ops->init(skt);
skt->ops->set_socket(skt, &skt->socket);
+}
+
+static int socket_early_resume(struct pcmcia_socket *skt)
+{
+ if ((skt->state & SOCKET_SUSPEND) && (skt->state & SOCKET_PRESENT))
+ socket_start_resume(skt);
+
+ return 0;
+}
+
+static int socket_late_resume(struct pcmcia_socket *skt)
+{
+ int ret;
+
+ if (!(skt->state & SOCKET_SUSPEND))
+ return 0;
if (!(skt->state & SOCKET_PRESENT)) {
+ socket_start_resume(skt);
skt->state &= ~SOCKET_SUSPEND;
return socket_insert(skt);
}
@@ -596,6 +611,22 @@ static int socket_resume(struct pcmcia_s
return 0;
}
+/*
+ * Resume a socket. If a card is present, verify its CIS against
+ * our cached copy. If they are different, the card has been
+ * replaced, and we need to tell the drivers.
+ */
+static int socket_resume(struct pcmcia_socket *skt)
+{
+ if (!(skt->state & SOCKET_SUSPEND))
+ return -EBUSY;
+
+ if (skt->state & SOCKET_PRESENT)
+ socket_start_resume(skt);
+
+ return socket_late_resume(skt);
+}
+
static void socket_remove(struct pcmcia_socket *skt)
{
dev_printk(KERN_NOTICE, &skt->dev,
Index: linux-2.6/include/pcmcia/ss.h
===================================================================
--- linux-2.6.orig/include/pcmcia/ss.h
+++ linux-2.6/include/pcmcia/ss.h
@@ -280,6 +280,8 @@ extern struct pccard_resource_ops pccard
/* socket drivers are expected to use these callbacks in their .drv struct */
extern int pcmcia_socket_dev_suspend(struct device *dev);
+extern void pcmcia_socket_dev_early_resume(struct device *dev);
+extern void pcmcia_socket_dev_late_resume(struct device *dev);
extern int pcmcia_socket_dev_resume(struct device *dev);
/* socket drivers use this callback in their IRQ handler */
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
2009-10-31 21:27 ` Rafael J. Wysocki
@ 2009-10-31 21:44 ` Linus Torvalds
2009-10-31 21:52 ` Rafael J. Wysocki
[not found] ` <200910312227.15493.rjw-KKrjLPT3xs0@public.gmane.org>
1 sibling, 1 reply; 128+ messages in thread
From: Linus Torvalds @ 2009-10-31 21:44 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Benjamin Herrenschmidt, Linux Kernel Mailing List,
Kernel Testers List, Greg Kroah-Hartman, Jose Marino,
ACPI Devel Maling List, Linux PCI, Dominik Brodowski
On Sat, 31 Oct 2009, Rafael J. Wysocki wrote:
>
> The patch is appended, please have a look.
Looks sane to me. It does the actual real socket ops early, and does the
crazy pcmcia resume late.
And I like how you abstracted out that dev->socket thing in
pcmcia_socket_dev_run().
The only thing that looks odd is how you do "socket_start_resume()" in the
"late_resume" path too - that has already been done by the early_resume,
and as far as I can see you're now initializing the socket twice.
Is there a reason for that? Or am I misreading the patch (I didn't
actually apply it, I just read the patch itself).
Linus
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
2009-10-31 21:44 ` Linus Torvalds
@ 2009-10-31 21:52 ` Rafael J. Wysocki
[not found] ` <200910312252.39446.rjw-KKrjLPT3xs0@public.gmane.org>
0 siblings, 1 reply; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-31 21:52 UTC (permalink / raw)
To: Linus Torvalds
Cc: Benjamin Herrenschmidt, Linux Kernel Mailing List,
Kernel Testers List, Greg Kroah-Hartman, Jose Marino,
ACPI Devel Maling List, Linux PCI, Dominik Brodowski
On Saturday 31 October 2009, Linus Torvalds wrote:
>
> On Sat, 31 Oct 2009, Rafael J. Wysocki wrote:
> >
> > The patch is appended, please have a look.
>
> Looks sane to me. It does the actual real socket ops early, and does the
> crazy pcmcia resume late.
>
> And I like how you abstracted out that dev->socket thing in
> pcmcia_socket_dev_run().
>
> The only thing that looks odd is how you do "socket_start_resume()" in the
> "late_resume" path too - that has already been done by the early_resume,
> and as far as I can see you're now initializing the socket twice.
>
> Is there a reason for that? Or am I misreading the patch (I didn't
> actually apply it, I just read the patch itself).
Yes, there is, because socket_early_resume() only does it in
the (skt->state & SOCKET_PRESENT) case. If that bit is not set, the
initialization is entirely postponed.
Rafael
^ permalink raw reply [flat|nested] 128+ messages in thread
[parent not found: <200910312227.15493.rjw-KKrjLPT3xs0@public.gmane.org>]
* Re: Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
[not found] ` <200910312227.15493.rjw-KKrjLPT3xs0@public.gmane.org>
@ 2009-10-31 22:56 ` Benjamin Herrenschmidt
2009-10-31 23:10 ` Rafael J. Wysocki
0 siblings, 1 reply; 128+ messages in thread
From: Benjamin Herrenschmidt @ 2009-10-31 22:56 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linus Torvalds, Linux Kernel Mailing List, Kernel Testers List,
Greg Kroah-Hartman, Jose Marino, ACPI Devel Maling List,
Linux PCI, Dominik Brodowski
On Sat, 2009-10-31 at 22:27 +0100, Rafael J. Wysocki wrote:
> In the meantime I invented a patch that works, ie. apparently fixes the problem
> and if there was a card in the socket during the suspend, it's standard config
> space is restored correctly. I tested it on one of my boxes with two different
> CardBus adapters and Jose says it fixes the problem for him.
>
> The patch is appended, please have a look.
Base idea of the patch sounds good, quick browse through looks good too,
I'll try to band on it with various PCMCIA & CB gear tomorrow.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
2009-10-31 22:56 ` Benjamin Herrenschmidt
@ 2009-10-31 23:10 ` Rafael J. Wysocki
2009-10-31 23:24 ` Rafael J. Wysocki
0 siblings, 1 reply; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-31 23:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linus Torvalds, Linux Kernel Mailing List, Kernel Testers List,
Greg Kroah-Hartman, Jose Marino, ACPI Devel Maling List,
Linux PCI, Dominik Brodowski
On Saturday 31 October 2009, Benjamin Herrenschmidt wrote:
> On Sat, 2009-10-31 at 22:27 +0100, Rafael J. Wysocki wrote:
>
> > In the meantime I invented a patch that works, ie. apparently fixes the problem
> > and if there was a card in the socket during the suspend, it's standard config
> > space is restored correctly. I tested it on one of my boxes with two different
> > CardBus adapters and Jose says it fixes the problem for him.
> >
> > The patch is appended, please have a look.
>
> Base idea of the patch sounds good, quick browse through looks good too,
>
> I'll try to band on it with various PCMCIA & CB gear tomorrow.
Wait, I made a mistake when testing it, didn't notice that my distro ejected
PCMCIA cards automatically before suspend (sigh).
Working on a better patch right now, will hopefully post it in a while.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
2009-10-31 23:10 ` Rafael J. Wysocki
@ 2009-10-31 23:24 ` Rafael J. Wysocki
2009-11-01 8:36 ` Rafael J. Wysocki
0 siblings, 1 reply; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-31 23:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linus Torvalds, Linux Kernel Mailing List, Kernel Testers List,
Greg Kroah-Hartman, Jose Marino, ACPI Devel Maling List,
Linux PCI, Dominik Brodowski
On Sunday 01 November 2009, Rafael J. Wysocki wrote:
> On Saturday 31 October 2009, Benjamin Herrenschmidt wrote:
> > On Sat, 2009-10-31 at 22:27 +0100, Rafael J. Wysocki wrote:
> >
> > > In the meantime I invented a patch that works, ie. apparently fixes the problem
> > > and if there was a card in the socket during the suspend, it's standard config
> > > space is restored correctly. I tested it on one of my boxes with two different
> > > CardBus adapters and Jose says it fixes the problem for him.
> > >
> > > The patch is appended, please have a look.
> >
> > Base idea of the patch sounds good, quick browse through looks good too,
> >
> > I'll try to band on it with various PCMCIA & CB gear tomorrow.
>
> Wait, I made a mistake when testing it, didn't notice that my distro ejected
> PCMCIA cards automatically before suspend (sigh).
>
> Working on a better patch right now, will hopefully post it in a while.
Here you go.
Waiting for feedback from the reporters of BKO #14334, so there's no sign-off
for now.
---
drivers/pcmcia/cs.c | 79 ++++++++++++++++++++++++++++--------------
drivers/pcmcia/yenta_socket.c | 12 +++++-
include/pcmcia/ss.h | 4 ++
3 files changed, 68 insertions(+), 27 deletions(-)
Index: linux-2.6/drivers/pcmcia/yenta_socket.c
===================================================================
--- linux-2.6.orig/drivers/pcmcia/yenta_socket.c
+++ linux-2.6/drivers/pcmcia/yenta_socket.c
@@ -1275,16 +1275,26 @@ static int yenta_dev_resume_noirq(struct
if (socket->type && socket->type->restore_state)
socket->type->restore_state(socket);
- return pcmcia_socket_dev_resume(dev);
+ pcmcia_socket_dev_early_resume(dev);
+ return 0;
+}
+
+static int yenta_dev_resume(struct device *dev)
+{
+ pcmcia_socket_dev_late_resume(dev);
+ return 0;
}
static struct dev_pm_ops yenta_pm_ops = {
.suspend_noirq = yenta_dev_suspend_noirq,
.resume_noirq = yenta_dev_resume_noirq,
+ .resume = yenta_dev_resume,
.freeze_noirq = yenta_dev_suspend_noirq,
.thaw_noirq = yenta_dev_resume_noirq,
+ .thaw = yenta_dev_resume,
.poweroff_noirq = yenta_dev_suspend_noirq,
.restore_noirq = yenta_dev_resume_noirq,
+ .restore = yenta_dev_resume,
};
#define YENTA_PM_OPS (¥ta_pm_ops)
Index: linux-2.6/drivers/pcmcia/cs.c
===================================================================
--- linux-2.6.orig/drivers/pcmcia/cs.c
+++ linux-2.6/drivers/pcmcia/cs.c
@@ -98,10 +98,13 @@ EXPORT_SYMBOL(pcmcia_socket_list_rwsem);
* These functions check for the appropriate struct pcmcia_soket arrays,
* and pass them to the low-level functions pcmcia_{suspend,resume}_socket
*/
+static int socket_early_resume(struct pcmcia_socket *skt);
+static int socket_late_resume(struct pcmcia_socket *skt);
static int socket_resume(struct pcmcia_socket *skt);
static int socket_suspend(struct pcmcia_socket *skt);
-int pcmcia_socket_dev_suspend(struct device *dev)
+static void pcmcia_socket_dev_run(struct device *dev,
+ int (*cb)(struct pcmcia_socket *))
{
struct pcmcia_socket *socket;
@@ -110,29 +113,34 @@ int pcmcia_socket_dev_suspend(struct dev
if (socket->dev.parent != dev)
continue;
mutex_lock(&socket->skt_mutex);
- socket_suspend(socket);
+ cb(socket);
mutex_unlock(&socket->skt_mutex);
}
up_read(&pcmcia_socket_list_rwsem);
+}
+int pcmcia_socket_dev_suspend(struct device *dev)
+{
+ pcmcia_socket_dev_run(dev, socket_suspend);
return 0;
}
EXPORT_SYMBOL(pcmcia_socket_dev_suspend);
-int pcmcia_socket_dev_resume(struct device *dev)
+void pcmcia_socket_dev_early_resume(struct device *dev)
{
- struct pcmcia_socket *socket;
+ pcmcia_socket_dev_run(dev, socket_early_resume);
+}
+EXPORT_SYMBOL(pcmcia_socket_dev_early_resume);
- down_read(&pcmcia_socket_list_rwsem);
- list_for_each_entry(socket, &pcmcia_socket_list, socket_list) {
- if (socket->dev.parent != dev)
- continue;
- mutex_lock(&socket->skt_mutex);
- socket_resume(socket);
- mutex_unlock(&socket->skt_mutex);
- }
- up_read(&pcmcia_socket_list_rwsem);
+void pcmcia_socket_dev_late_resume(struct device *dev)
+{
+ pcmcia_socket_dev_run(dev, socket_late_resume);
+}
+EXPORT_SYMBOL(pcmcia_socket_dev_late_resume);
+int pcmcia_socket_dev_resume(struct device *dev)
+{
+ pcmcia_socket_dev_run(dev, socket_resume);
return 0;
}
EXPORT_SYMBOL(pcmcia_socket_dev_resume);
@@ -546,29 +554,34 @@ static int socket_suspend(struct pcmcia_
return 0;
}
-/*
- * Resume a socket. If a card is present, verify its CIS against
- * our cached copy. If they are different, the card has been
- * replaced, and we need to tell the drivers.
- */
-static int socket_resume(struct pcmcia_socket *skt)
+static void socket_start_resume(struct pcmcia_socket *skt)
{
- int ret;
-
- if (!(skt->state & SOCKET_SUSPEND))
- return -EBUSY;
-
skt->socket = dead_socket;
skt->ops->init(skt);
skt->ops->set_socket(skt, &skt->socket);
+ if (skt->state & SOCKET_PRESENT)
+ skt->resume_status = socket_setup(skt, resume_delay);
+}
+
+static int socket_early_resume(struct pcmcia_socket *skt)
+{
+ if (skt->state & SOCKET_SUSPEND)
+ socket_start_resume(skt);
+
+ return 0;
+}
+
+static int socket_late_resume(struct pcmcia_socket *skt)
+{
+ if (!(skt->state & SOCKET_SUSPEND))
+ return 0;
if (!(skt->state & SOCKET_PRESENT)) {
skt->state &= ~SOCKET_SUSPEND;
return socket_insert(skt);
}
- ret = socket_setup(skt, resume_delay);
- if (ret == 0) {
+ if (skt->resume_status == 0) {
/*
* FIXME: need a better check here for cardbus cards.
*/
@@ -596,6 +609,20 @@ static int socket_resume(struct pcmcia_s
return 0;
}
+/*
+ * Resume a socket. If a card is present, verify its CIS against
+ * our cached copy. If they are different, the card has been
+ * replaced, and we need to tell the drivers.
+ */
+static int socket_resume(struct pcmcia_socket *skt)
+{
+ if (!(skt->state & SOCKET_SUSPEND))
+ return -EBUSY;
+
+ socket_start_resume(skt);
+ return socket_late_resume(skt);
+}
+
static void socket_remove(struct pcmcia_socket *skt)
{
dev_printk(KERN_NOTICE, &skt->dev,
Index: linux-2.6/include/pcmcia/ss.h
===================================================================
--- linux-2.6.orig/include/pcmcia/ss.h
+++ linux-2.6/include/pcmcia/ss.h
@@ -262,6 +262,8 @@ struct pcmcia_socket {
struct device dev;
/* data internal to the socket driver */
void *driver_data;
+ /* status of the card during resume from a system sleep state */
+ int resume_status;
};
@@ -280,6 +282,8 @@ extern struct pccard_resource_ops pccard
/* socket drivers are expected to use these callbacks in their .drv struct */
extern int pcmcia_socket_dev_suspend(struct device *dev);
+extern void pcmcia_socket_dev_early_resume(struct device *dev);
+extern void pcmcia_socket_dev_late_resume(struct device *dev);
extern int pcmcia_socket_dev_resume(struct device *dev);
/* socket drivers use this callback in their IRQ handler */
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
2009-10-31 23:24 ` Rafael J. Wysocki
@ 2009-11-01 8:36 ` Rafael J. Wysocki
2009-11-01 16:47 ` Dominik Brodowski
[not found] ` <200911010936.10409.rjw-KKrjLPT3xs0@public.gmane.org>
0 siblings, 2 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-11-01 8:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linus Torvalds, Linux Kernel Mailing List, Kernel Testers List,
Greg Kroah-Hartman, Jose Marino, ACPI Devel Maling List,
Linux PCI, Dominik Brodowski
On Sunday 01 November 2009, Rafael J. Wysocki wrote:
> On Sunday 01 November 2009, Rafael J. Wysocki wrote:
> > On Saturday 31 October 2009, Benjamin Herrenschmidt wrote:
> > > On Sat, 2009-10-31 at 22:27 +0100, Rafael J. Wysocki wrote:
> > >
> > > > In the meantime I invented a patch that works, ie. apparently fixes the problem
> > > > and if there was a card in the socket during the suspend, it's standard config
> > > > space is restored correctly. I tested it on one of my boxes with two different
> > > > CardBus adapters and Jose says it fixes the problem for him.
> > > >
> > > > The patch is appended, please have a look.
> > >
> > > Base idea of the patch sounds good, quick browse through looks good too,
> > >
> > > I'll try to band on it with various PCMCIA & CB gear tomorrow.
> >
> > Wait, I made a mistake when testing it, didn't notice that my distro ejected
> > PCMCIA cards automatically before suspend (sigh).
> >
> > Working on a better patch right now, will hopefully post it in a while.
>
> Here you go.
>
> Waiting for feedback from the reporters of BKO #14334, so there's no sign-off
> for now.
Jose confirms that the patch fixes the problem for him, so here it goes again
with full changelog.
If people don't object, I'll push it through the suspend-2.6 tree along with a
few other bug fixes.
---
From: Rafael J. Wysocki <rjw@sisk.pl>
Subject: PM / yenta: Split resume into early and late parts (rev. 2)
Commit 0c570cdeb8fdfcb354a3e9cd81bfc6a09c19de0c
(PM / yenta: Fix cardbus suspend/resume regression) caused resume to
fail on systems with two CardBus bridges. While the exact nature
of the failure is not known at the moment, it can be worked around by
splitting the yenta resume into an early part, executed during the
early phase of resume, that will only resume the socket and power it
up if there was a card in it during suspend, and a late part,
executed during "regular" resume, that will carry out all of the
remaining yenta resume operations.
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=14334, which is a
listed regression from 2.6.31.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
drivers/pcmcia/cs.c | 79 ++++++++++++++++++++++++++++--------------
drivers/pcmcia/yenta_socket.c | 12 +++++-
include/pcmcia/ss.h | 4 ++
3 files changed, 68 insertions(+), 27 deletions(-)
Index: linux-2.6/drivers/pcmcia/yenta_socket.c
===================================================================
--- linux-2.6.orig/drivers/pcmcia/yenta_socket.c
+++ linux-2.6/drivers/pcmcia/yenta_socket.c
@@ -1275,16 +1275,26 @@ static int yenta_dev_resume_noirq(struct
if (socket->type && socket->type->restore_state)
socket->type->restore_state(socket);
- return pcmcia_socket_dev_resume(dev);
+ pcmcia_socket_dev_early_resume(dev);
+ return 0;
+}
+
+static int yenta_dev_resume(struct device *dev)
+{
+ pcmcia_socket_dev_late_resume(dev);
+ return 0;
}
static struct dev_pm_ops yenta_pm_ops = {
.suspend_noirq = yenta_dev_suspend_noirq,
.resume_noirq = yenta_dev_resume_noirq,
+ .resume = yenta_dev_resume,
.freeze_noirq = yenta_dev_suspend_noirq,
.thaw_noirq = yenta_dev_resume_noirq,
+ .thaw = yenta_dev_resume,
.poweroff_noirq = yenta_dev_suspend_noirq,
.restore_noirq = yenta_dev_resume_noirq,
+ .restore = yenta_dev_resume,
};
#define YENTA_PM_OPS (¥ta_pm_ops)
Index: linux-2.6/drivers/pcmcia/cs.c
===================================================================
--- linux-2.6.orig/drivers/pcmcia/cs.c
+++ linux-2.6/drivers/pcmcia/cs.c
@@ -98,10 +98,13 @@ EXPORT_SYMBOL(pcmcia_socket_list_rwsem);
* These functions check for the appropriate struct pcmcia_soket arrays,
* and pass them to the low-level functions pcmcia_{suspend,resume}_socket
*/
+static int socket_early_resume(struct pcmcia_socket *skt);
+static int socket_late_resume(struct pcmcia_socket *skt);
static int socket_resume(struct pcmcia_socket *skt);
static int socket_suspend(struct pcmcia_socket *skt);
-int pcmcia_socket_dev_suspend(struct device *dev)
+static void pcmcia_socket_dev_run(struct device *dev,
+ int (*cb)(struct pcmcia_socket *))
{
struct pcmcia_socket *socket;
@@ -110,29 +113,34 @@ int pcmcia_socket_dev_suspend(struct dev
if (socket->dev.parent != dev)
continue;
mutex_lock(&socket->skt_mutex);
- socket_suspend(socket);
+ cb(socket);
mutex_unlock(&socket->skt_mutex);
}
up_read(&pcmcia_socket_list_rwsem);
+}
+int pcmcia_socket_dev_suspend(struct device *dev)
+{
+ pcmcia_socket_dev_run(dev, socket_suspend);
return 0;
}
EXPORT_SYMBOL(pcmcia_socket_dev_suspend);
-int pcmcia_socket_dev_resume(struct device *dev)
+void pcmcia_socket_dev_early_resume(struct device *dev)
{
- struct pcmcia_socket *socket;
+ pcmcia_socket_dev_run(dev, socket_early_resume);
+}
+EXPORT_SYMBOL(pcmcia_socket_dev_early_resume);
- down_read(&pcmcia_socket_list_rwsem);
- list_for_each_entry(socket, &pcmcia_socket_list, socket_list) {
- if (socket->dev.parent != dev)
- continue;
- mutex_lock(&socket->skt_mutex);
- socket_resume(socket);
- mutex_unlock(&socket->skt_mutex);
- }
- up_read(&pcmcia_socket_list_rwsem);
+void pcmcia_socket_dev_late_resume(struct device *dev)
+{
+ pcmcia_socket_dev_run(dev, socket_late_resume);
+}
+EXPORT_SYMBOL(pcmcia_socket_dev_late_resume);
+int pcmcia_socket_dev_resume(struct device *dev)
+{
+ pcmcia_socket_dev_run(dev, socket_resume);
return 0;
}
EXPORT_SYMBOL(pcmcia_socket_dev_resume);
@@ -546,29 +554,34 @@ static int socket_suspend(struct pcmcia_
return 0;
}
-/*
- * Resume a socket. If a card is present, verify its CIS against
- * our cached copy. If they are different, the card has been
- * replaced, and we need to tell the drivers.
- */
-static int socket_resume(struct pcmcia_socket *skt)
+static void socket_start_resume(struct pcmcia_socket *skt)
{
- int ret;
-
- if (!(skt->state & SOCKET_SUSPEND))
- return -EBUSY;
-
skt->socket = dead_socket;
skt->ops->init(skt);
skt->ops->set_socket(skt, &skt->socket);
+ if (skt->state & SOCKET_PRESENT)
+ skt->resume_status = socket_setup(skt, resume_delay);
+}
+
+static int socket_early_resume(struct pcmcia_socket *skt)
+{
+ if (skt->state & SOCKET_SUSPEND)
+ socket_start_resume(skt);
+
+ return 0;
+}
+
+static int socket_late_resume(struct pcmcia_socket *skt)
+{
+ if (!(skt->state & SOCKET_SUSPEND))
+ return 0;
if (!(skt->state & SOCKET_PRESENT)) {
skt->state &= ~SOCKET_SUSPEND;
return socket_insert(skt);
}
- ret = socket_setup(skt, resume_delay);
- if (ret == 0) {
+ if (skt->resume_status == 0) {
/*
* FIXME: need a better check here for cardbus cards.
*/
@@ -596,6 +609,20 @@ static int socket_resume(struct pcmcia_s
return 0;
}
+/*
+ * Resume a socket. If a card is present, verify its CIS against
+ * our cached copy. If they are different, the card has been
+ * replaced, and we need to tell the drivers.
+ */
+static int socket_resume(struct pcmcia_socket *skt)
+{
+ if (!(skt->state & SOCKET_SUSPEND))
+ return -EBUSY;
+
+ socket_start_resume(skt);
+ return socket_late_resume(skt);
+}
+
static void socket_remove(struct pcmcia_socket *skt)
{
dev_printk(KERN_NOTICE, &skt->dev,
Index: linux-2.6/include/pcmcia/ss.h
===================================================================
--- linux-2.6.orig/include/pcmcia/ss.h
+++ linux-2.6/include/pcmcia/ss.h
@@ -262,6 +262,8 @@ struct pcmcia_socket {
struct device dev;
/* data internal to the socket driver */
void *driver_data;
+ /* status of the card during resume from a system sleep state */
+ int resume_status;
};
@@ -280,6 +282,8 @@ extern struct pccard_resource_ops pccard
/* socket drivers are expected to use these callbacks in their .drv struct */
extern int pcmcia_socket_dev_suspend(struct device *dev);
+extern void pcmcia_socket_dev_early_resume(struct device *dev);
+extern void pcmcia_socket_dev_late_resume(struct device *dev);
extern int pcmcia_socket_dev_resume(struct device *dev);
/* socket drivers use this callback in their IRQ handler */
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
2009-11-01 8:36 ` Rafael J. Wysocki
@ 2009-11-01 16:47 ` Dominik Brodowski
[not found] ` <20091101164736.GA5666-S7uyTPAaJ/sb6pqDj42GsMgv3T4z79SOrE5yTffgRl4@public.gmane.org>
[not found] ` <200911010936.10409.rjw-KKrjLPT3xs0@public.gmane.org>
1 sibling, 1 reply; 128+ messages in thread
From: Dominik Brodowski @ 2009-11-01 16:47 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Benjamin Herrenschmidt, Linus Torvalds, Linux Kernel Mailing List,
Kernel Testers List, Greg Kroah-Hartman, Jose Marino,
ACPI Devel Maling List, Linux PCI
Hey,
On Sun, Nov 01, 2009 at 09:36:10AM +0100, Rafael J. Wysocki wrote:
> Commit 0c570cdeb8fdfcb354a3e9cd81bfc6a09c19de0c
> (PM / yenta: Fix cardbus suspend/resume regression) caused resume to
> fail on systems with two CardBus bridges. While the exact nature
> of the failure is not known at the moment, it can be worked around by
> splitting the yenta resume into an early part, executed during the
> early phase of resume, that will only resume the socket and power it
> up if there was a card in it during suspend, and a late part,
> executed during "regular" resume, that will carry out all of the
> remaining yenta resume operations.
>
> Fixes http://bugzilla.kernel.org/show_bug.cgi?id=14334, which is a
> listed regression from 2.6.31.
The only issue I see is that we now return 0 unconditionally on the resume
callbacks. Otherwise, it's
Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
> Index: linux-2.6/drivers/pcmcia/yenta_socket.c
> ===================================================================
> --- linux-2.6.orig/drivers/pcmcia/yenta_socket.c
> +++ linux-2.6/drivers/pcmcia/yenta_socket.c
> @@ -1275,16 +1275,26 @@ static int yenta_dev_resume_noirq(struct
> if (socket->type && socket->type->restore_state)
> socket->type->restore_state(socket);
>
> - return pcmcia_socket_dev_resume(dev);
> + pcmcia_socket_dev_early_resume(dev);
> + return 0;
> +}
> +
> +static int yenta_dev_resume(struct device *dev)
> +{
> + pcmcia_socket_dev_late_resume(dev);
> + return 0;
> }
>
> static struct dev_pm_ops yenta_pm_ops = {
> .suspend_noirq = yenta_dev_suspend_noirq,
> .resume_noirq = yenta_dev_resume_noirq,
> + .resume = yenta_dev_resume,
> .freeze_noirq = yenta_dev_suspend_noirq,
> .thaw_noirq = yenta_dev_resume_noirq,
> + .thaw = yenta_dev_resume,
> .poweroff_noirq = yenta_dev_suspend_noirq,
> .restore_noirq = yenta_dev_resume_noirq,
> + .restore = yenta_dev_resume,
> };
>
> #define YENTA_PM_OPS (¥ta_pm_ops)
> Index: linux-2.6/drivers/pcmcia/cs.c
> ===================================================================
> --- linux-2.6.orig/drivers/pcmcia/cs.c
> +++ linux-2.6/drivers/pcmcia/cs.c
> @@ -98,10 +98,13 @@ EXPORT_SYMBOL(pcmcia_socket_list_rwsem);
> * These functions check for the appropriate struct pcmcia_soket arrays,
> * and pass them to the low-level functions pcmcia_{suspend,resume}_socket
> */
> +static int socket_early_resume(struct pcmcia_socket *skt);
> +static int socket_late_resume(struct pcmcia_socket *skt);
> static int socket_resume(struct pcmcia_socket *skt);
> static int socket_suspend(struct pcmcia_socket *skt);
>
> -int pcmcia_socket_dev_suspend(struct device *dev)
> +static void pcmcia_socket_dev_run(struct device *dev,
> + int (*cb)(struct pcmcia_socket *))
> {
> struct pcmcia_socket *socket;
>
> @@ -110,29 +113,34 @@ int pcmcia_socket_dev_suspend(struct dev
> if (socket->dev.parent != dev)
> continue;
> mutex_lock(&socket->skt_mutex);
> - socket_suspend(socket);
> + cb(socket);
> mutex_unlock(&socket->skt_mutex);
> }
> up_read(&pcmcia_socket_list_rwsem);
> +}
>
> +int pcmcia_socket_dev_suspend(struct device *dev)
> +{
> + pcmcia_socket_dev_run(dev, socket_suspend);
> return 0;
> }
> EXPORT_SYMBOL(pcmcia_socket_dev_suspend);
>
> -int pcmcia_socket_dev_resume(struct device *dev)
> +void pcmcia_socket_dev_early_resume(struct device *dev)
> {
> - struct pcmcia_socket *socket;
> + pcmcia_socket_dev_run(dev, socket_early_resume);
> +}
> +EXPORT_SYMBOL(pcmcia_socket_dev_early_resume);
>
> - down_read(&pcmcia_socket_list_rwsem);
> - list_for_each_entry(socket, &pcmcia_socket_list, socket_list) {
> - if (socket->dev.parent != dev)
> - continue;
> - mutex_lock(&socket->skt_mutex);
> - socket_resume(socket);
> - mutex_unlock(&socket->skt_mutex);
> - }
> - up_read(&pcmcia_socket_list_rwsem);
> +void pcmcia_socket_dev_late_resume(struct device *dev)
> +{
> + pcmcia_socket_dev_run(dev, socket_late_resume);
> +}
> +EXPORT_SYMBOL(pcmcia_socket_dev_late_resume);
>
> +int pcmcia_socket_dev_resume(struct device *dev)
> +{
> + pcmcia_socket_dev_run(dev, socket_resume);
> return 0;
> }
> EXPORT_SYMBOL(pcmcia_socket_dev_resume);
> @@ -546,29 +554,34 @@ static int socket_suspend(struct pcmcia_
> return 0;
> }
>
> -/*
> - * Resume a socket. If a card is present, verify its CIS against
> - * our cached copy. If they are different, the card has been
> - * replaced, and we need to tell the drivers.
> - */
> -static int socket_resume(struct pcmcia_socket *skt)
> +static void socket_start_resume(struct pcmcia_socket *skt)
> {
> - int ret;
> -
> - if (!(skt->state & SOCKET_SUSPEND))
> - return -EBUSY;
> -
> skt->socket = dead_socket;
> skt->ops->init(skt);
> skt->ops->set_socket(skt, &skt->socket);
> + if (skt->state & SOCKET_PRESENT)
> + skt->resume_status = socket_setup(skt, resume_delay);
> +}
> +
> +static int socket_early_resume(struct pcmcia_socket *skt)
> +{
> + if (skt->state & SOCKET_SUSPEND)
> + socket_start_resume(skt);
> +
> + return 0;
> +}
> +
> +static int socket_late_resume(struct pcmcia_socket *skt)
> +{
> + if (!(skt->state & SOCKET_SUSPEND))
> + return 0;
>
> if (!(skt->state & SOCKET_PRESENT)) {
> skt->state &= ~SOCKET_SUSPEND;
> return socket_insert(skt);
> }
>
> - ret = socket_setup(skt, resume_delay);
> - if (ret == 0) {
> + if (skt->resume_status == 0) {
> /*
> * FIXME: need a better check here for cardbus cards.
> */
> @@ -596,6 +609,20 @@ static int socket_resume(struct pcmcia_s
> return 0;
> }
>
> +/*
> + * Resume a socket. If a card is present, verify its CIS against
> + * our cached copy. If they are different, the card has been
> + * replaced, and we need to tell the drivers.
> + */
> +static int socket_resume(struct pcmcia_socket *skt)
> +{
> + if (!(skt->state & SOCKET_SUSPEND))
> + return -EBUSY;
> +
> + socket_start_resume(skt);
> + return socket_late_resume(skt);
> +}
> +
> static void socket_remove(struct pcmcia_socket *skt)
> {
> dev_printk(KERN_NOTICE, &skt->dev,
> Index: linux-2.6/include/pcmcia/ss.h
> ===================================================================
> --- linux-2.6.orig/include/pcmcia/ss.h
> +++ linux-2.6/include/pcmcia/ss.h
> @@ -262,6 +262,8 @@ struct pcmcia_socket {
> struct device dev;
> /* data internal to the socket driver */
> void *driver_data;
> + /* status of the card during resume from a system sleep state */
> + int resume_status;
> };
>
>
> @@ -280,6 +282,8 @@ extern struct pccard_resource_ops pccard
>
> /* socket drivers are expected to use these callbacks in their .drv struct */
> extern int pcmcia_socket_dev_suspend(struct device *dev);
> +extern void pcmcia_socket_dev_early_resume(struct device *dev);
> +extern void pcmcia_socket_dev_late_resume(struct device *dev);
> extern int pcmcia_socket_dev_resume(struct device *dev);
>
> /* socket drivers use this callback in their IRQ handler */
^ permalink raw reply [flat|nested] 128+ messages in thread[parent not found: <200911010936.10409.rjw-KKrjLPT3xs0@public.gmane.org>]
* Re: Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
[not found] ` <200911010936.10409.rjw-KKrjLPT3xs0@public.gmane.org>
@ 2009-11-01 17:18 ` Linus Torvalds
2009-11-02 13:39 ` Rafael J. Wysocki
0 siblings, 1 reply; 128+ messages in thread
From: Linus Torvalds @ 2009-11-01 17:18 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Benjamin Herrenschmidt, Linux Kernel Mailing List,
Kernel Testers List, Greg Kroah-Hartman, Jose Marino,
ACPI Devel Maling List, Linux PCI, Dominik Brodowski
On Sun, 1 Nov 2009, Rafael J. Wysocki wrote:
>
> If people don't object, I'll push it through the suspend-2.6 tree along
> with a few other bug fixes.
No objections, but a cleanup request:
> +static int socket_early_resume(struct pcmcia_socket *skt)
> +{
> + if (skt->state & SOCKET_SUSPEND)
> + socket_start_resume(skt);
> +
> + return 0;
> +}
> +
> +static int socket_late_resume(struct pcmcia_socket *skt)
> +{
> + if (!(skt->state & SOCKET_SUSPEND))
> + return 0;
As far as I can tell, that "SOCKET_SUSPEND" test is totally pointless.
That socket _is_ going to be suspended, and testing for it here just seems
to confuse things.
So I'd remove it from both early_resume and late_resume, and only keep it
in the case of the legacy user-requested suspend/resume (do we even do
that any more?).
The SOCKET_SUSPEND flag itself is still relevant, of course, since the
state change handling will test it (in order to avoid insert/remove
handlign while we have the suspend flag set). It's just that the suspend
code shouldn't _test_ it, since the suspend code is what sets it in the
first place.
Linus
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
2009-11-01 17:18 ` Linus Torvalds
@ 2009-11-02 13:39 ` Rafael J. Wysocki
2009-11-02 17:38 ` Dominik Brodowski
[not found] ` <200911021439.28266.rjw-KKrjLPT3xs0@public.gmane.org>
0 siblings, 2 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-11-02 13:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: Benjamin Herrenschmidt, Linux Kernel Mailing List,
Kernel Testers List, Greg Kroah-Hartman, Jose Marino,
ACPI Devel Maling List, Linux PCI, Dominik Brodowski
On Sunday 01 November 2009, Linus Torvalds wrote:
>
> On Sun, 1 Nov 2009, Rafael J. Wysocki wrote:
> >
> > If people don't object, I'll push it through the suspend-2.6 tree along
> > with a few other bug fixes.
>
> No objections, but a cleanup request:
>
> > +static int socket_early_resume(struct pcmcia_socket *skt)
> > +{
> > + if (skt->state & SOCKET_SUSPEND)
> > + socket_start_resume(skt);
> > +
> > + return 0;
> > +}
> > +
> > +static int socket_late_resume(struct pcmcia_socket *skt)
> > +{
> > + if (!(skt->state & SOCKET_SUSPEND))
> > + return 0;
>
> As far as I can tell, that "SOCKET_SUSPEND" test is totally pointless.
Right.
> That socket _is_ going to be suspended, and testing for it here just seems
> to confuse things.
>
> So I'd remove it from both early_resume and late_resume, and only keep it
> in the case of the legacy user-requested suspend/resume (do we even do
> that any more?).
OK, updated patch is appended.
Thanks,
Rafael
---
From: Rafael J. Wysocki <rjw@sisk.pl>
Subject: PM / yenta: Split resume into early and late parts (rev. 3)
Commit 0c570cdeb8fdfcb354a3e9cd81bfc6a09c19de0c
(PM / yenta: Fix cardbus suspend/resume regression) caused resume to
fail on systems with two CardBus bridges. While the exact nature
of the failure is not known at the moment, it can be worked around by
splitting the yenta resume into an early part, executed during the
early phase of resume, that will only resume the socket and power it
up if there was a card in it during suspend, and a late part,
executed during "regular" resume, that will carry out all of the
remaining yenta resume operations.
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=14334, which is a
listed regression from 2.6.31.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
drivers/pcmcia/cs.c | 74 +++++++++++++++++++++++++++---------------
drivers/pcmcia/yenta_socket.c | 12 ++++++
include/pcmcia/ss.h | 4 ++
3 files changed, 63 insertions(+), 27 deletions(-)
Index: linux-2.6/drivers/pcmcia/yenta_socket.c
===================================================================
--- linux-2.6.orig/drivers/pcmcia/yenta_socket.c
+++ linux-2.6/drivers/pcmcia/yenta_socket.c
@@ -1275,16 +1275,26 @@ static int yenta_dev_resume_noirq(struct
if (socket->type && socket->type->restore_state)
socket->type->restore_state(socket);
- return pcmcia_socket_dev_resume(dev);
+ pcmcia_socket_dev_early_resume(dev);
+ return 0;
+}
+
+static int yenta_dev_resume(struct device *dev)
+{
+ pcmcia_socket_dev_late_resume(dev);
+ return 0;
}
static struct dev_pm_ops yenta_pm_ops = {
.suspend_noirq = yenta_dev_suspend_noirq,
.resume_noirq = yenta_dev_resume_noirq,
+ .resume = yenta_dev_resume,
.freeze_noirq = yenta_dev_suspend_noirq,
.thaw_noirq = yenta_dev_resume_noirq,
+ .thaw = yenta_dev_resume,
.poweroff_noirq = yenta_dev_suspend_noirq,
.restore_noirq = yenta_dev_resume_noirq,
+ .restore = yenta_dev_resume,
};
#define YENTA_PM_OPS (¥ta_pm_ops)
Index: linux-2.6/drivers/pcmcia/cs.c
===================================================================
--- linux-2.6.orig/drivers/pcmcia/cs.c
+++ linux-2.6/drivers/pcmcia/cs.c
@@ -98,10 +98,13 @@ EXPORT_SYMBOL(pcmcia_socket_list_rwsem);
* These functions check for the appropriate struct pcmcia_soket arrays,
* and pass them to the low-level functions pcmcia_{suspend,resume}_socket
*/
+static int socket_early_resume(struct pcmcia_socket *skt);
+static int socket_late_resume(struct pcmcia_socket *skt);
static int socket_resume(struct pcmcia_socket *skt);
static int socket_suspend(struct pcmcia_socket *skt);
-int pcmcia_socket_dev_suspend(struct device *dev)
+static void pcmcia_socket_dev_run(struct device *dev,
+ int (*cb)(struct pcmcia_socket *))
{
struct pcmcia_socket *socket;
@@ -110,29 +113,34 @@ int pcmcia_socket_dev_suspend(struct dev
if (socket->dev.parent != dev)
continue;
mutex_lock(&socket->skt_mutex);
- socket_suspend(socket);
+ cb(socket);
mutex_unlock(&socket->skt_mutex);
}
up_read(&pcmcia_socket_list_rwsem);
+}
+int pcmcia_socket_dev_suspend(struct device *dev)
+{
+ pcmcia_socket_dev_run(dev, socket_suspend);
return 0;
}
EXPORT_SYMBOL(pcmcia_socket_dev_suspend);
-int pcmcia_socket_dev_resume(struct device *dev)
+void pcmcia_socket_dev_early_resume(struct device *dev)
{
- struct pcmcia_socket *socket;
+ pcmcia_socket_dev_run(dev, socket_early_resume);
+}
+EXPORT_SYMBOL(pcmcia_socket_dev_early_resume);
- down_read(&pcmcia_socket_list_rwsem);
- list_for_each_entry(socket, &pcmcia_socket_list, socket_list) {
- if (socket->dev.parent != dev)
- continue;
- mutex_lock(&socket->skt_mutex);
- socket_resume(socket);
- mutex_unlock(&socket->skt_mutex);
- }
- up_read(&pcmcia_socket_list_rwsem);
+void pcmcia_socket_dev_late_resume(struct device *dev)
+{
+ pcmcia_socket_dev_run(dev, socket_late_resume);
+}
+EXPORT_SYMBOL(pcmcia_socket_dev_late_resume);
+int pcmcia_socket_dev_resume(struct device *dev)
+{
+ pcmcia_socket_dev_run(dev, socket_resume);
return 0;
}
EXPORT_SYMBOL(pcmcia_socket_dev_resume);
@@ -546,29 +554,29 @@ static int socket_suspend(struct pcmcia_
return 0;
}
-/*
- * Resume a socket. If a card is present, verify its CIS against
- * our cached copy. If they are different, the card has been
- * replaced, and we need to tell the drivers.
- */
-static int socket_resume(struct pcmcia_socket *skt)
+static void socket_start_resume(struct pcmcia_socket *skt)
{
- int ret;
-
- if (!(skt->state & SOCKET_SUSPEND))
- return -EBUSY;
-
skt->socket = dead_socket;
skt->ops->init(skt);
skt->ops->set_socket(skt, &skt->socket);
+ if (skt->state & SOCKET_PRESENT)
+ skt->resume_status = socket_setup(skt, resume_delay);
+}
+static int socket_early_resume(struct pcmcia_socket *skt)
+{
+ socket_start_resume(skt);
+ return 0;
+}
+
+static int socket_late_resume(struct pcmcia_socket *skt)
+{
if (!(skt->state & SOCKET_PRESENT)) {
skt->state &= ~SOCKET_SUSPEND;
return socket_insert(skt);
}
- ret = socket_setup(skt, resume_delay);
- if (ret == 0) {
+ if (skt->resume_status == 0) {
/*
* FIXME: need a better check here for cardbus cards.
*/
@@ -596,6 +604,20 @@ static int socket_resume(struct pcmcia_s
return 0;
}
+/*
+ * Resume a socket. If a card is present, verify its CIS against
+ * our cached copy. If they are different, the card has been
+ * replaced, and we need to tell the drivers.
+ */
+static int socket_resume(struct pcmcia_socket *skt)
+{
+ if (!(skt->state & SOCKET_SUSPEND))
+ return -EBUSY;
+
+ socket_start_resume(skt);
+ return socket_late_resume(skt);
+}
+
static void socket_remove(struct pcmcia_socket *skt)
{
dev_printk(KERN_NOTICE, &skt->dev,
Index: linux-2.6/include/pcmcia/ss.h
===================================================================
--- linux-2.6.orig/include/pcmcia/ss.h
+++ linux-2.6/include/pcmcia/ss.h
@@ -262,6 +262,8 @@ struct pcmcia_socket {
struct device dev;
/* data internal to the socket driver */
void *driver_data;
+ /* status of the card during resume from a system sleep state */
+ int resume_status;
};
@@ -280,6 +282,8 @@ extern struct pccard_resource_ops pccard
/* socket drivers are expected to use these callbacks in their .drv struct */
extern int pcmcia_socket_dev_suspend(struct device *dev);
+extern void pcmcia_socket_dev_early_resume(struct device *dev);
+extern void pcmcia_socket_dev_late_resume(struct device *dev);
extern int pcmcia_socket_dev_resume(struct device *dev);
/* socket drivers use this callback in their IRQ handler */
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
2009-11-02 13:39 ` Rafael J. Wysocki
@ 2009-11-02 17:38 ` Dominik Brodowski
[not found] ` <20091102173843.GA662-S7uyTPAaJ/sb6pqDj42GsMgv3T4z79SOrE5yTffgRl4@public.gmane.org>
[not found] ` <200911021439.28266.rjw-KKrjLPT3xs0@public.gmane.org>
1 sibling, 1 reply; 128+ messages in thread
From: Dominik Brodowski @ 2009-11-02 17:38 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linus Torvalds, Benjamin Herrenschmidt, Linux Kernel Mailing List,
Kernel Testers List, Greg Kroah-Hartman, Jose Marino,
ACPI Devel Maling List, Linux PCI
Hey,
just two minor nit-pick which we could handle post-2.6.32:
> +++ linux-2.6/drivers/pcmcia/cs.c
> @@ -98,10 +98,13 @@ EXPORT_SYMBOL(pcmcia_socket_list_rwsem);
> * These functions check for the appropriate struct pcmcia_soket arrays,
> * and pass them to the low-level functions pcmcia_{suspend,resume}_socket
... some documentation of the new functions, especially whether other socket
drivers should be updated?
> -static int socket_resume(struct pcmcia_socket *skt)
> +static void socket_start_resume(struct pcmcia_socket *skt)
> {
> - int ret;
> -
> - if (!(skt->state & SOCKET_SUSPEND))
> - return -EBUSY;
> -
> skt->socket = dead_socket;
> skt->ops->init(skt);
> skt->ops->set_socket(skt, &skt->socket);
> + if (skt->state & SOCKET_PRESENT)
> + skt->resume_status = socket_setup(skt, resume_delay);
> +}
>
> +static int socket_early_resume(struct pcmcia_socket *skt)
> +{
> + socket_start_resume(skt);
> + return 0;
> +}
Why do we need to have two functions doing the same? Wouldn't
static int socket_early_resume(...)
suffice, with the only call to socket_start_resume() being replaced with
socket_early_resume()?
Best,
Dominik
^ permalink raw reply [flat|nested] 128+ messages in thread[parent not found: <200911021439.28266.rjw-KKrjLPT3xs0@public.gmane.org>]
* Re: Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
[not found] ` <200911021439.28266.rjw-KKrjLPT3xs0@public.gmane.org>
@ 2009-11-02 17:50 ` Linus Torvalds
2009-11-02 22:22 ` Benjamin Herrenschmidt
1 sibling, 0 replies; 128+ messages in thread
From: Linus Torvalds @ 2009-11-02 17:50 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Benjamin Herrenschmidt, Linux Kernel Mailing List,
Kernel Testers List, Greg Kroah-Hartman, Jose Marino,
ACPI Devel Maling List, Linux PCI, Dominik Brodowski
On Mon, 2 Nov 2009, Rafael J. Wysocki wrote:
>
> OK, updated patch is appended.
Looks good to me, feel free to push any time (assuming you've gotten
testing confirmation from the people who reported it). Thanks,
Linus
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
[not found] ` <200911021439.28266.rjw-KKrjLPT3xs0@public.gmane.org>
2009-11-02 17:50 ` Linus Torvalds
@ 2009-11-02 22:22 ` Benjamin Herrenschmidt
2009-11-12 12:14 ` Pavel Machek
1 sibling, 1 reply; 128+ messages in thread
From: Benjamin Herrenschmidt @ 2009-11-02 22:22 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linus Torvalds, Linux Kernel Mailing List, Kernel Testers List,
Greg Kroah-Hartman, Jose Marino, ACPI Devel Maling List,
Linux PCI, Dominik Brodowski
On Mon, 2009-11-02 at 14:39 +0100, Rafael J. Wysocki wrote:
>
> > That socket _is_ going to be suspended, and testing for it here just seems
> > to confuse things.
> >
> > So I'd remove it from both early_resume and late_resume, and only keep it
> > in the case of the legacy user-requested suspend/resume (do we even do
> > that any more?).
>
> OK, updated patch is appended.
Test by me delayed to tomorrow ... hit another suspend/resume bug on
that laptop which took away the time I had to do that test yesterday and
today I'm off :-)
(Bug was simple but took a while to track down: machine was left in
storage for a while, battery ran out, RTC went back to Jan 1, 1904,
which means a negative xtime, and the new timekeeping code will do
horrible things including hanging at resume when that happens. Fix is to
make powerpc read_persistent_clock() to ignore the RTC when it contains
a date older than epoch).
Cheers,
Ben.
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: Help needed, Re: [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m
2009-11-02 22:22 ` Benjamin Herrenschmidt
@ 2009-11-12 12:14 ` Pavel Machek
0 siblings, 0 replies; 128+ messages in thread
From: Pavel Machek @ 2009-11-12 12:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Rafael J. Wysocki, Linus Torvalds, Linux Kernel Mailing List,
Kernel Testers List, Greg Kroah-Hartman, Jose Marino,
ACPI Devel Maling List, Linux PCI, Dominik Brodowski
Hi!
> (Bug was simple but took a while to track down: machine was left in
> storage for a while, battery ran out, RTC went back to Jan 1, 1904,
> which means a negative xtime, and the new timekeeping code will do
> horrible things including hanging at resume when that happens. Fix is to
> make powerpc read_persistent_clock() to ignore the RTC when it contains
> a date older than epoch).
Additionaly, it would be nice if the machine would not hang, no matter
what RTC says...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 128+ messages in thread
* [Bug #14352] WARNING: at net/mac80211/scan.c:267
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (9 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14334] pcmcia suspend regression from 2.6.31.1 to 2.6.31.2 - Dell Inspiron 600m Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 18:55 ` [Bug #14372] ath5k wireless not working after suspend-resume - eeepc Rafael J. Wysocki
` (30 subsequent siblings)
41 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14352
Subject : WARNING: at net/mac80211/scan.c:267
Submitter : Maciej Rutecki <maciej.rutecki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-10-08 00:30 (19 days old)
References : http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2089#c7
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14372] ath5k wireless not working after suspend-resume - eeepc
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (10 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14352] WARNING: at net/mac80211/scan.c:267 Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 20:15 ` Fabio Comolli
2009-10-26 18:55 ` [Bug #14373] Task blocked for more than 120 seconds Rafael J. Wysocki
` (29 subsequent siblings)
41 siblings, 1 reply; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Fabio Comolli
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14372
Subject : ath5k wireless not working after suspend-resume - eeepc
Submitter : Fabio Comolli <fabio.comolli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-10-03 15:36 (24 days old)
References : http://lkml.org/lkml/2009/10/3/91
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14373] Task blocked for more than 120 seconds
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (11 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14372] ath5k wireless not working after suspend-resume - eeepc Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 18:55 ` [Bug #14355] USB serial regression after 2.6.31.1 with Huawei E169 GSM modem Rafael J. Wysocki
` (28 subsequent siblings)
41 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Zeno Davatz
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14373
Subject : Task blocked for more than 120 seconds
Submitter : Zeno Davatz <zdavatz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-10-02 10:16 (25 days old)
References : http://marc.info/?l=linux-kernel&m=125447858618412&w=4
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14355] USB serial regression after 2.6.31.1 with Huawei E169 GSM modem
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (12 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14373] Task blocked for more than 120 seconds Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-27 1:54 ` Benjamin Herrenschmidt
2009-10-26 18:55 ` [Bug #14375] Intel(R) I/OAT DMA Engine init failed Rafael J. Wysocki
` (27 subsequent siblings)
41 siblings, 1 reply; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Alan Stern, Ben Efros,
Benjamin Herrenschmidt
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14355
Subject : USB serial regression after 2.6.31.1 with Huawei E169 GSM modem
Submitter : Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Date : 2009-10-10 03:07 (17 days old)
References : http://marc.info/?l=linux-kernel&m=125513456327542&w=4
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [Bug #14355] USB serial regression after 2.6.31.1 with Huawei E169 GSM modem
2009-10-26 18:55 ` [Bug #14355] USB serial regression after 2.6.31.1 with Huawei E169 GSM modem Rafael J. Wysocki
@ 2009-10-27 1:54 ` Benjamin Herrenschmidt
2009-10-27 8:28 ` Rafael J. Wysocki
0 siblings, 1 reply; 128+ messages in thread
From: Benjamin Herrenschmidt @ 2009-10-27 1:54 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Alan Stern,
Ben Efros
On Mon, 2009-10-26 at 19:55 +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.31. Please verify if it still should be listed and let me know
> (either way).
Well, the E169 works, though there seem to be a few issues remaining:
- There are reports that the E220 is still broken (by the same
regression, just that the patch that fixes the E169 doesn't fix the
E220, but since I don't have one of these, I'm waiting for users to send
dumps instead of just complaining :-)
- There's a weird glitch where the E169 tend to only work after being
plugged the -second- time. The first time, the storage device generally
shows up but not the ttyS's devices for some strange reason. Not sure
what's up yet. Yanking it and plugging it back works. Could be timing
related due to the need to load the module.
None of that happens with 2.6.31.1
Cheers,
Ben.
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14355
> Subject : USB serial regression after 2.6.31.1 with Huawei E169 GSM modem
> Submitter : Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
> Date : 2009-10-10 03:07 (17 days old)
> References : http://marc.info/?l=linux-kernel&m=125513456327542&w=4
>
>
> --
> 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] 128+ messages in thread
* Re: [Bug #14355] USB serial regression after 2.6.31.1 with Huawei E169 GSM modem
2009-10-27 1:54 ` Benjamin Herrenschmidt
@ 2009-10-27 8:28 ` Rafael J. Wysocki
0 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-27 8:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linux Kernel Mailing List, Kernel Testers List, Alan Stern,
Ben Efros
On Tuesday 27 October 2009, Benjamin Herrenschmidt wrote:
> On Mon, 2009-10-26 at 19:55 +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.31. Please verify if it still should be listed and let me know
> > (either way).
>
> Well, the E169 works, though there seem to be a few issues remaining:
>
> - There are reports that the E220 is still broken (by the same
> regression, just that the patch that fixes the E169 doesn't fix the
> E220, but since I don't have one of these, I'm waiting for users to send
> dumps instead of just complaining :-)
>
> - There's a weird glitch where the E169 tend to only work after being
> plugged the -second- time. The first time, the storage device generally
> shows up but not the ttyS's devices for some strange reason. Not sure
> what's up yet. Yanking it and plugging it back works. Could be timing
> related due to the need to load the module.
>
> None of that happens with 2.6.31.1
Well, I guess it's better to leave the bug open in that case.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 128+ messages in thread
* [Bug #14375] Intel(R) I/OAT DMA Engine init failed
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (13 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14355] USB serial regression after 2.6.31.1 with Huawei E169 GSM modem Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 21:57 ` Alexander Beregalov
2009-10-26 18:55 ` [Bug #14376] Kernel NULL pointer dereference/ kvm subsystem Rafael J. Wysocki
` (26 subsequent siblings)
41 siblings, 1 reply; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Alexander Beregalov, Dan Williams
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14375
Subject : Intel(R) I/OAT DMA Engine init failed
Submitter : Alexander Beregalov <a.beregalov@gmail.com>
Date : 2009-10-02 9:46 (25 days old)
References : http://marc.info/?l=linux-kernel&m=125447680016160&w=4
Handled-By : Dan Williams <dan.j.williams@intel.com>
Patch : http://patchwork.kernel.org/patch/51808/
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [Bug #14375] Intel(R) I/OAT DMA Engine init failed
2009-10-26 18:55 ` [Bug #14375] Intel(R) I/OAT DMA Engine init failed Rafael J. Wysocki
@ 2009-10-26 21:57 ` Alexander Beregalov
[not found] ` <a4423d670910261457o2e1ccb7t768199dfd9985270-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-10-26 22:13 ` Dan Williams
0 siblings, 2 replies; 128+ messages in thread
From: Alexander Beregalov @ 2009-10-26 21:57 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Dan Williams
2009/10/26 Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>:
> 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.31. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14375
> Subject : Intel(R) I/OAT DMA Engine init failed
> Submitter : Alexander Beregalov <a.beregalov@gmail.com>
> Date : 2009-10-02 9:46 (25 days old)
> References : http://marc.info/?l=linux-kernel&m=125447680016160&w=4
> Handled-By : Dan Williams <dan.j.williams@intel.com>
> Patch : http://patchwork.kernel.org/patch/51808/
When I patch reiserfs the bug goes to libata, it means ioatdma works
and libata does not. It looks like inaccurate work with memory
somewhere, but I do not know how to find it.
I cannot reproduce it since 2.6.32-rc3 and I do not see any bugs since then.
^ permalink raw reply [flat|nested] 128+ messages in thread[parent not found: <a4423d670910261457o2e1ccb7t768199dfd9985270-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [Bug #14375] Intel(R) I/OAT DMA Engine init failed
[not found] ` <a4423d670910261457o2e1ccb7t768199dfd9985270-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2009-10-26 22:12 ` Rafael J. Wysocki
0 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 22:12 UTC (permalink / raw)
To: Alexander Beregalov
Cc: Linux Kernel Mailing List, Kernel Testers List, Dan Williams
On Monday 26 October 2009, Alexander Beregalov wrote:
> 2009/10/26 Rafael J. Wysocki <rjw-KKrjLPT3xs0@public.gmane.org>:
> > 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.31. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14375
> > Subject : Intel(R) I/OAT DMA Engine init failed
> > Submitter : Alexander Beregalov <a.beregalov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date : 2009-10-02 9:46 (25 days old)
> > References : http://marc.info/?l=linux-kernel&m=125447680016160&w=4
> > Handled-By : Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > Patch : http://patchwork.kernel.org/patch/51808/
>
> When I patch reiserfs the bug goes to libata, it means ioatdma works
> and libata does not. It looks like inaccurate work with memory
> somewhere, but I do not know how to find it.
> I cannot reproduce it since 2.6.32-rc3 and I do not see any bugs since then.
Since you can't reproduce it with -rc3 and later, I'm going to close it now.
Please reopen if the problem reappears.
Best,
Rafael
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [Bug #14375] Intel(R) I/OAT DMA Engine init failed
2009-10-26 21:57 ` Alexander Beregalov
[not found] ` <a4423d670910261457o2e1ccb7t768199dfd9985270-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2009-10-26 22:13 ` Dan Williams
1 sibling, 0 replies; 128+ messages in thread
From: Dan Williams @ 2009-10-26 22:13 UTC (permalink / raw)
To: Alexander Beregalov
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List
On Mon, 2009-10-26 at 14:57 -0700, Alexander Beregalov wrote:
> 2009/10/26 Rafael J. Wysocki <rjw@sisk.pl>:
> > 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.31. Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14375
> > Subject : Intel(R) I/OAT DMA Engine init failed
> > Submitter : Alexander Beregalov <a.beregalov@gmail.com>
> > Date : 2009-10-02 9:46 (25 days old)
> > References : http://marc.info/?l=linux-kernel&m=125447680016160&w=4
> > Handled-By : Dan Williams <dan.j.williams@intel.com>
> > Patch : http://patchwork.kernel.org/patch/51808/
>
> When I patch reiserfs the bug goes to libata, it means ioatdma works
> and libata does not. It looks like inaccurate work with memory
> somewhere, but I do not know how to find it.
> I cannot reproduce it since 2.6.32-rc3 and I do not see any bugs since then.
If it helps the debug, the symptom seems to be that all interrupts get
turned off. Neither the normal device completion interrupt nor the
completion watchdog timer fire before the self test timeout. It seems
something else re-enables interrupts eventually, but we know they were
at least disabled for 3 seconds. An unmatched spin_unlock_irq in an
async initialization path perhaps?
--
Dan
^ permalink raw reply [flat|nested] 128+ messages in thread
* [Bug #14376] Kernel NULL pointer dereference/ kvm subsystem
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (14 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14375] Intel(R) I/OAT DMA Engine init failed Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 18:55 ` [Bug #14378] Problems with net/core/skbuff.c Rafael J. Wysocki
` (25 subsequent siblings)
41 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Don Dupuis
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14376
Subject : Kernel NULL pointer dereference/ kvm subsystem
Submitter : Don Dupuis <dondster-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-10-06 14:38 (21 days old)
References : http://marc.info/?l=linux-kernel&m=125484025021737&w=4
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14378] Problems with net/core/skbuff.c
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (15 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14376] Kernel NULL pointer dereference/ kvm subsystem Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 19:50 ` Eric Dumazet
2009-10-26 18:55 ` [Bug #14379] ACPI Warning for _SB_.BAT0._BIF: Converted Buffer to expected String Rafael J. Wysocki
` (24 subsequent siblings)
41 siblings, 1 reply; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Massimo Cetra
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14378
Subject : Problems with net/core/skbuff.c
Submitter : Massimo Cetra <mcetra@navynet.it>
Date : 2009-10-08 14:51 (19 days old)
References : http://marc.info/?l=linux-kernel&m=125501488220358&w=4
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [Bug #14378] Problems with net/core/skbuff.c
2009-10-26 18:55 ` [Bug #14378] Problems with net/core/skbuff.c Rafael J. Wysocki
@ 2009-10-26 19:50 ` Eric Dumazet
[not found] ` <4AE5FD84.8070906-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 128+ messages in thread
From: Eric Dumazet @ 2009-10-26 19:50 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Massimo Cetra
Rafael J. Wysocki a écrit :
> 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.31. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14378
> Subject : Problems with net/core/skbuff.c
> Submitter : Massimo Cetra <mcetra-BBpJ+9iBSNKonA0d6jMUrA@public.gmane.org>
> Date : 2009-10-08 14:51 (19 days old)
> References : http://marc.info/?l=linux-kernel&m=125501488220358&w=4
>
>
This was corrected by commit ed79bab847d8e5a2986d8ff43c49c6fb8ee3265f
virtio_net: use dev_kfree_skb_any() in free_old_xmit_skbs()
Because netpoll can call netdevice start_xmit() method with
irqs disabled, drivers should not call kfree_skb() from
their start_xmit(), but use dev_kfree_skb_any() instead.
Oct 8 11:16:52 172.30.1.31 [113074.791813] ------------[ cut here ]------------
Oct 8 11:16:52 172.30.1.31 [113074.791813] WARNING: at net/core/skbuff.c:398 \
skb_release_head_state+0x64/0xc8()
Oct 8 11:16:52 172.30.1.31 [113074.791813] Hardware name:
Oct 8 11:16:52 172.30.1.31 [113074.791813] Modules linked in: netconsole ocfs2 jbd2 quota_tree \
ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs crc32c drbd cn loop \
serio_raw psmouse snd_pcm snd_timer snd soundcore snd_page_alloc virtio_net pcspkr parport_pc parport \
i2c_piix4 i2c_core button processor evdev ext3 jbd mbcache dm_mirror dm_region_hash dm_log dm_snapshot \
dm_mod ide_cd_mod cdrom ata_generic ata_piix virtio_blk libata scsi_mod piix ide_pci_generic ide_core \
virtio_pci virtio_ring virtio floppy thermal fan thermal_sys [last unloaded: netconsole]
Oct 8 11:16:52 172.30.1.31 [113074.791813] Pid: 11132, comm: php5-cgi Tainted: G W \
2.6.31.2-vserver #1
Oct 8 11:16:52 172.30.1.31 [113074.791813] Call Trace:
Oct 8 11:16:52 172.30.1.31 [113074.791813] <IRQ> [<ffffffff81253cd5>] ? \
skb_release_head_state+0x64/0xc8
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81253cd5>] ? skb_release_head_state+0x64/0xc8
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81049ae1>] ? warn_slowpath_common+0x77/0xa3
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81253cd5>] ? skb_release_head_state+0x64/0xc8
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81253a1a>] ? __kfree_skb+0x9/0x7d
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffffa01cb139>] ? free_old_xmit_skbs+0x51/0x6e \
[virtio_net]
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffffa01cbc85>] ? start_xmit+0x26/0xf2 [virtio_net]
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff8126934f>] ? netpoll_send_skb+0xd2/0x205
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffffa0429216>] ? write_msg+0x90/0xeb [netconsole]
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81049f06>] ? __call_console_drivers+0x5e/0x6f
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff8102b49d>] ? kvm_clock_read+0x4d/0x52
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff8104a082>] ? release_console_sem+0x115/0x1ba
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff8104a632>] ? vprintk+0x2f2/0x34b
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff8106b142>] ? vx_update_load+0x18/0x13e
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81308309>] ? printk+0x4e/0x5d
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff8102b49d>] ? kvm_clock_read+0x4d/0x52
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81070b62>] ? getnstimeofday+0x55/0xaf
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81062683>] ? ktime_get_ts+0x21/0x49
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff810626b7>] ? ktime_get+0xc/0x41
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81062788>] ? hrtimer_interrupt+0x9c/0x146
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81024a4b>] ? smp_apic_timer_interrupt+0x80/0x93
Oct 8 11:16:52 172.30.1.31 [113074.791813] [<ffffffff81011663>] ? apic_timer_interrupt+0x13/0x20
Oct 8 11:16:52 172.30.1.31 [113074.791813] <EOI> [<ffffffff8130a9eb>] ? _spin_unlock_irq+0xd/0x31
Reported-and-tested-by: Massimo Cetra <mcetra-BBpJ+9iBSNKonA0d6jMUrA@public.gmane.org>
Signed-off-by: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Bug-Entry: http://bugzilla.kernel.org/show_bug.cgi?id=14378
Signed-off-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
^ permalink raw reply [flat|nested] 128+ messages in thread
* [Bug #14379] ACPI Warning for _SB_.BAT0._BIF: Converted Buffer to expected String
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (16 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14378] Problems with net/core/skbuff.c Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 19:15 ` Justin P. Mattock
2009-10-26 18:55 ` [Bug #14383] hackbench regression with kernel 2.6.32-rc1 Rafael J. Wysocki
` (23 subsequent siblings)
41 siblings, 1 reply; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Alexey Starikovskiy, Justin Mattock,
Len Brown, Lin Ming
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14379
Subject : ACPI Warning for _SB_.BAT0._BIF: Converted Buffer to expected String
Submitter : Justin Mattock <justinmattock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-10-08 21:46 (19 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d9adc2e031bd22d5d9607a53a8d3b30e0b675f39
References : http://marc.info/?l=linux-kernel&m=125504031328941&w=4
Handled-By : Alexey Starikovskiy <astarikovskiy-l3A5Bk7waGM@public.gmane.org>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=23347
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14383] hackbench regression with kernel 2.6.32-rc1
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (17 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14379] ACPI Warning for _SB_.BAT0._BIF: Converted Buffer to expected String Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 18:55 ` [Bug #14381] iwlagn lost connection after s2ram (with warnings) Rafael J. Wysocki
` (22 subsequent siblings)
41 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, 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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14383
Subject : hackbench regression with kernel 2.6.32-rc1
Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date : 2009-10-09 9:19 (18 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=29cd8bae396583a2ee9a3340db8c5102acf9f6fd
References : http://marc.info/?l=linux-kernel&m=125508007510274&w=4
Handled-By : Peter Zijlstra <a.p.zijlstra@chello.nl>
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14381] iwlagn lost connection after s2ram (with warnings)
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (18 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14383] hackbench regression with kernel 2.6.32-rc1 Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 19:56 ` Carlos R. Mafra
2009-10-26 18:55 ` [Bug #14380] Video tearing/glitching with T400 laptops Rafael J. Wysocki
` (21 subsequent siblings)
41 siblings, 1 reply; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Carlos R. Mafra, 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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14381
Subject : iwlagn lost connection after s2ram (with warnings)
Submitter : Carlos R. Mafra <crmafra2@gmail.com>
Date : 2009-10-07 14:20 (20 days old)
References : http://marc.info/?l=linux-kernel&m=125492569119947&w=4
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14380] Video tearing/glitching with T400 laptops
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (19 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14381] iwlagn lost connection after s2ram (with warnings) Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 18:55 ` [Bug #14384] tbench regression with 2.6.32-rc1 Rafael J. Wysocki
` (20 subsequent siblings)
41 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Arkadiusz Miskiewicz, Jesse Barnes,
Theodore Ts'o
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14380
Subject : Video tearing/glitching with T400 laptops
Submitter : Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org>
Date : 2009-10-02 22:40 (25 days old)
References : http://marc.info/?l=linux-kernel&m=125452324520623&w=4
Handled-By : Jesse Barnes <jbarnes-Y1mF5jBUw70BENJcbMCuUQ@public.gmane.org>
Patch : http://marc.info/?l=linux-kernel&m=125591495325000&w=4
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14384] tbench regression with 2.6.32-rc1
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (20 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14380] Video tearing/glitching with T400 laptops Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 18:55 ` [Bug #14389] Build system issue Rafael J. Wysocki
` (19 subsequent siblings)
41 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, 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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14384
Subject : tbench regression with 2.6.32-rc1
Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date : 2009-10-09 9:51 (18 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59abf02644c45f1591e1374ee7bb45dc757fcb88
References : http://marc.info/?l=linux-kernel&m=125508216713138&w=4
Handled-By : Peter Zijlstra <a.p.zijlstra@chello.nl>
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14389] Build system issue
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (21 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14384] tbench regression with 2.6.32-rc1 Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 20:05 ` Ingo Molnar
2009-10-26 18:55 ` [Bug #14387] deadlock with fallocate Rafael J. Wysocki
` (18 subsequent siblings)
41 siblings, 1 reply; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Ingo Molnar, Pavel Machek, Peter Zijlstra,
Sam Ravnborg
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14389
Subject : Build system issue
Submitter : Peter Zijlstra <peterz@infradead.org>
Date : 2009-10-09 8:58 (18 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=575543347b5baed0ca927cb90ba8807396fe9cc9
References : http://marc.info/?l=linux-kernel&m=125507914909152&w=4
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14387] deadlock with fallocate
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (22 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14389] Build system issue Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 20:41 ` Christoph Hellwig
2009-10-26 18:55 ` [Bug #14406] uvcvideo stopped work on Toshiba Rafael J. Wysocki
` (17 subsequent siblings)
41 siblings, 1 reply; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Andrew Morton, Christoph Hellwig,
Thomas Neumann
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14387
Subject : deadlock with fallocate
Submitter : Thomas Neumann <tneumann@users.sourceforge.net>
Date : 2009-10-07 3:00 (20 days old)
References : http://marc.info/?l=linux-kernel&m=125488495526471&w=4
Handled-By : Christoph Hellwig <hch@lst.de>
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14406] uvcvideo stopped work on Toshiba
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (23 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14387] deadlock with fallocate Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 18:55 ` [Bug #14415] Reboot on kernel load Rafael J. Wysocki
` (16 subsequent siblings)
41 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, okias
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14406
Subject : uvcvideo stopped work on Toshiba
Submitter : okias <d.okias-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-10-14 19:08 (13 days old)
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14415] Reboot on kernel load
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (24 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14406] uvcvideo stopped work on Toshiba Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 18:55 ` [Bug #14408] sysctl check failed Rafael J. Wysocki
` (15 subsequent siblings)
41 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Brian Beardall
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14415
Subject : Reboot on kernel load
Submitter : Brian Beardall <brian-sVkzCUl/XCrR7s880joybQ@public.gmane.org>
Date : 2009-10-15 23:57 (12 days old)
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14408] sysctl check failed
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (25 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14415] Reboot on kernel load Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-28 3:56 ` Eric W. Biederman
2009-10-26 18:55 ` [Bug #14390] "bind" a device to a driver doesn't not work anymore Rafael J. Wysocki
` (14 subsequent siblings)
41 siblings, 1 reply; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Alexey Dobriyan, Peter Teoh
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14408
Subject : sysctl check failed
Submitter : Peter Teoh <htmldeveloper@gmail.com>
Date : 2009-10-14 22:59 (13 days old)
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14390] "bind" a device to a driver doesn't not work anymore
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (26 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14408] sysctl check failed Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 18:55 ` [Bug #14430] sync() hangs in bdi_sched_wait Rafael J. Wysocki
` (13 subsequent siblings)
41 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Éric Piel
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14390
Subject : "bind" a device to a driver doesn't not work anymore
Submitter : Éric Piel <Eric.Piel@tremplin-utc.net>
Date : 2009-10-11 0:04 (16 days old)
References : http://marc.info/?l=linux-kernel&m=125521979921241&w=4
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14430] sync() hangs in bdi_sched_wait
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (27 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14390] "bind" a device to a driver doesn't not work anymore Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 18:55 ` [Bug #14472] EXT4 corruption Rafael J. Wysocki
` (12 subsequent siblings)
41 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Petr Vandrovec
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14430
Subject : sync() hangs in bdi_sched_wait
Submitter : Petr Vandrovec <petr-vPk2MGR0e28uaRcfnNAh7A@public.gmane.org>
Date : 2009-10-17 19:14 (10 days old)
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14472] EXT4 corruption
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (28 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14430] sync() hangs in bdi_sched_wait Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-29 19:57 ` Andrew Lutomirski
2009-10-26 18:55 ` [Bug #14466] EFI boot on x86 fails in .32 Rafael J. Wysocki
` (11 subsequent siblings)
41 siblings, 1 reply; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Andy Lutomirski, Shawn Starr, Theodore Tso
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14472
Subject : EXT4 corruption
Submitter : Shawn Starr <shawn.starr-bJEeYj9oJeDQT0dZR+AlfA@public.gmane.org>
Date : 2009-10-13 2:07 (14 days old)
References : http://marc.info/?l=linux-kernel&m=125539997508256&w=4
Handled-By : Theodore Tso <tytso-3s7WtUTddSA@public.gmane.org>
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [Bug #14472] EXT4 corruption
2009-10-26 18:55 ` [Bug #14472] EXT4 corruption Rafael J. Wysocki
@ 2009-10-29 19:57 ` Andrew Lutomirski
[not found] ` <cb0375e10910291257t1f2f16ciade932bd78689ccc-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 128+ messages in thread
From: Andrew Lutomirski @ 2009-10-29 19:57 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Shawn Starr,
Theodore Tso
On Mon, Oct 26, 2009 at 2:55 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.31. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14472
> Subject : EXT4 corruption
> Submitter : Shawn Starr <shawn.starr-bJEeYj9oJeDQT0dZR+AlfA@public.gmane.org>
> Date : 2009-10-13 2:07 (14 days old)
> References : http://marc.info/?l=linux-kernel&m=125539997508256&w=4
> Handled-By : Theodore Tso <tytso-3s7WtUTddSA@public.gmane.org>
>
This but is *not* fixed. I just triggered it a few minutes ago by
abusing i915 and drm, which caused a panic. This is slightly newer
than 2.6.32-rc5, with a couple of i915 bugfixes thrown in.
Photos are here:
http://web.mit.edu/luto/www/ext4_crashphotos/
This is a very nasty regression, for obvious reasons.
--Andy
^ permalink raw reply [flat|nested] 128+ messages in thread
* [Bug #14466] EFI boot on x86 fails in .32
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (29 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14472] EXT4 corruption Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 18:55 ` [Bug #14442] resume after hibernate: /dev/sdb drops and returns as /dev/sde Rafael J. Wysocki
` (10 subsequent siblings)
41 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Feng Tang, Matthew Garrett, 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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14466
Subject : EFI boot on x86 fails in .32
Submitter : Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>
Date : 2009-10-20 0:34 (7 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7bd867dfb4e0357e06a3211ab2bd0e714110def3
References : http://marc.info/?l=linux-kernel&m=125599887314290&w=4
Handled-By : Feng Tang <feng.tang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14442] resume after hibernate: /dev/sdb drops and returns as /dev/sde
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (30 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14466] EFI boot on x86 fails in .32 Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 18:55 ` [Bug #14467] Linker errors on ia64 with NR_CPUS=4096 Rafael J. Wysocki
` (9 subsequent siblings)
41 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Duncan
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14442
Subject : resume after hibernate: /dev/sdb drops and returns as /dev/sde
Submitter : Duncan <1i5t5.duncan-j9pdmedNgrk@public.gmane.org>
Date : 2009-10-20 01:52 (7 days old)
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14467] Linker errors on ia64 with NR_CPUS=4096
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (31 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14442] resume after hibernate: /dev/sdb drops and returns as /dev/sde Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-27 20:28 ` Christoph Lameter
2009-10-26 18:55 ` [Bug #14473] ATA related kernel warning after resume Rafael J. Wysocki
` (8 subsequent siblings)
41 siblings, 1 reply; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Christoph Lameter, Ingo Molnar, Jeff Mahoney,
Jiri Kosina, Luck, Tony, Peter Zijlstra, Peter Zijlstra,
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14467
Subject : Linker errors on ia64 with NR_CPUS=4096
Submitter : Jeff Mahoney <jeffm-IBi9RG/b67k@public.gmane.org>
Date : 2009-10-18 22:28 (9 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=34d76c41554a05425613d16efebb3069c4c545f0
References : http://marc.info/?l=linux-kernel&m=125590493116720&w=4
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [Bug #14467] Linker errors on ia64 with NR_CPUS=4096
2009-10-26 18:55 ` [Bug #14467] Linker errors on ia64 with NR_CPUS=4096 Rafael J. Wysocki
@ 2009-10-27 20:28 ` Christoph Lameter
2009-10-27 18:24 ` Jiri Kosina
0 siblings, 1 reply; 128+ messages in thread
From: Christoph Lameter @ 2009-10-27 20:28 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Ingo Molnar,
Jeff Mahoney, Jiri Kosina, Luck, Tony, Peter Zijlstra,
Peter Zijlstra, Tejun Heo
The NR_CPUS array in the percpu section needs to be removed.
A simple fix would be to allocate the rq_weight per cpu array
dynamically.
The large per cpu array was introduced as a fix to a race condition. Maybe
there is another way of dealing with this issue that does not require
large per cpu arrays?
^ permalink raw reply [flat|nested] 128+ messages in thread
* Re: [Bug #14467] Linker errors on ia64 with NR_CPUS=4096
2009-10-27 20:28 ` Christoph Lameter
@ 2009-10-27 18:24 ` Jiri Kosina
[not found] ` <alpine.LSU.2.00.0910271922490.19847-B4tOwbsTzaBolqkO4TVVkw@public.gmane.org>
0 siblings, 1 reply; 128+ messages in thread
From: Jiri Kosina @ 2009-10-27 18:24 UTC (permalink / raw)
To: Christoph Lameter
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List,
Ingo Molnar, Jeff Mahoney, Luck, Tony, Peter Zijlstra,
Peter Zijlstra, Tejun Heo
On Tue, 27 Oct 2009, Christoph Lameter wrote:
> The NR_CPUS array in the percpu section needs to be removed.
>
> A simple fix would be to allocate the rq_weight per cpu array
> dynamically.
There already are two patches for this acked by Ingo/Tejun, which Tejun is
going to take through his tree tomorrow.
http://lkml.org/lkml/2009/10/27/132
http://lkml.org/lkml/2009/10/27/215
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ permalink raw reply [flat|nested] 128+ messages in thread
* [Bug #14473] ATA related kernel warning after resume
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (32 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14467] Linker errors on ia64 with NR_CPUS=4096 Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 18:55 ` [Bug #14477] possible circular locking dependency in ISDN PPP Rafael J. Wysocki
` (7 subsequent siblings)
41 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Linux IDE, Tino Keitel
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14473
Subject : ATA related kernel warning after resume
Submitter : Tino Keitel <tino.keitel@tikei.de>
Date : 2009-10-14 6:55 (13 days old)
References : http://marc.info/?l=linux-kernel&m=125550466624678&w=4
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14477] possible circular locking dependency in ISDN PPP
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (33 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14473] ATA related kernel warning after resume Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 22:00 ` Tilman Schmidt
2009-10-26 18:55 ` [Bug #14480] 2 locks held by cat -- running "find /sys | head -c 4" --> system hang Rafael J. Wysocki
` (6 subsequent siblings)
41 siblings, 1 reply; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Tilman Schmidt
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14477
Subject : possible circular locking dependency in ISDN PPP
Submitter : Tilman Schmidt <tilman@imap.cc>
Date : 2009-10-18 22:16 (9 days old)
References : http://marc.info/?l=linux-kernel&m=125590423416087&w=4
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14480] 2 locks held by cat -- running "find /sys | head -c 4" --> system hang
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (34 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14477] possible circular locking dependency in ISDN PPP Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 18:55 ` [Bug #14479] nfs oops Rafael J. Wysocki
` (5 subsequent siblings)
41 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Chris Wilson, Miles Lane
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14480
Subject : 2 locks held by cat -- running "find /sys | head -c 4" --> system hang
Submitter : Miles Lane <miles.lane-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-10-20 16:11 (7 days old)
References : http://marc.info/?l=linux-kernel&m=125605511728088&w=4
Handled-By : Chris Wilson <chris-Y6uKTt2uX1cEflXRtASbqLVCufUGDwFn@public.gmane.org>
Patch : http://patchwork.kernel.org/patch/54974/
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14479] nfs oops
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (35 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14480] 2 locks held by cat -- running "find /sys | head -c 4" --> system hang Rafael J. Wysocki
@ 2009-10-26 18:55 ` Rafael J. Wysocki
2009-10-26 21:07 ` Egon Alter
2009-10-26 18:56 ` [Bug #14481] umount blocked for more than 120 seconds after USB drive removal Rafael J. Wysocki
` (4 subsequent siblings)
41 siblings, 1 reply; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:55 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Egon Alter, Frans Pop, Trond Myklebust
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14479
Subject : nfs oops
Submitter : Egon Alter <egon.alter-hi6Y0CQ0nG0@public.gmane.org>
Date : 2009-10-19 16:03 (8 days old)
References : http://marc.info/?l=linux-kernel&m=125596822630410&w=4
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14481] umount blocked for more than 120 seconds after USB drive removal
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (36 preceding siblings ...)
2009-10-26 18:55 ` [Bug #14479] nfs oops Rafael J. Wysocki
@ 2009-10-26 18:56 ` Rafael J. Wysocki
2009-10-26 23:45 ` Robert Hancock
2009-10-27 2:04 ` Yong Zhang
2009-10-26 18:56 ` [Bug #14482] kernel BUG at fs/dcache.c:670 +lvm +md +ext3 Rafael J. Wysocki
` (3 subsequent siblings)
41 siblings, 2 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:56 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Robert Hancock
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14481
Subject : umount blocked for more than 120 seconds after USB drive removal
Submitter : Robert Hancock <hancockrwd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-10-21 5:26 (6 days old)
References : http://marc.info/?l=linux-kernel&m=125610280532245&w=4
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [Bug #14481] umount blocked for more than 120 seconds after USB drive removal
2009-10-26 18:56 ` [Bug #14481] umount blocked for more than 120 seconds after USB drive removal Rafael J. Wysocki
@ 2009-10-26 23:45 ` Robert Hancock
[not found] ` <51f3faa70910261645x16235582keb00a5875f64db14-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-10-27 2:04 ` Yong Zhang
1 sibling, 1 reply; 128+ messages in thread
From: Robert Hancock @ 2009-10-26 23:45 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux Kernel Mailing List, Kernel Testers List
Haven't seen the problem again, but I haven't really tried to
reproduce it, and haven't gotten any responses about it, so yes, it
should still be listed.
On Mon, Oct 26, 2009 at 12:56 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.31. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14481
> Subject : umount blocked for more than 120 seconds after USB drive removal
> Submitter : Robert Hancock <hancockrwd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date : 2009-10-21 5:26 (6 days old)
> References : http://marc.info/?l=linux-kernel&m=125610280532245&w=4
>
>
>
^ permalink raw reply [flat|nested] 128+ messages in thread* Re: [Bug #14481] umount blocked for more than 120 seconds after USB drive removal
2009-10-26 18:56 ` [Bug #14481] umount blocked for more than 120 seconds after USB drive removal Rafael J. Wysocki
2009-10-26 23:45 ` Robert Hancock
@ 2009-10-27 2:04 ` Yong Zhang
2009-10-27 8:30 ` Rafael J. Wysocki
1 sibling, 1 reply; 128+ messages in thread
From: Yong Zhang @ 2009-10-27 2:04 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Kernel Testers List, Robert Hancock
On Tue, Oct 27, 2009 at 2:56 AM, 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.31. Please verify if it still should be listed and let me know
> (either way).
>
>
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14481
> Subject : umount blocked for more than 120 seconds after USB drive removal
> Submitter : Robert Hancock <hancockrwd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date : 2009-10-21 5:26 (6 days old)
> References : http://marc.info/?l=linux-kernel&m=125610280532245&w=4
>
>
I met the same problem on 2.6.32-rc5
Thanks,
Yong
> --
> 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] 128+ messages in thread
* [Bug #14482] kernel BUG at fs/dcache.c:670 +lvm +md +ext3
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (37 preceding siblings ...)
2009-10-26 18:56 ` [Bug #14481] umount blocked for more than 120 seconds after USB drive removal Rafael J. Wysocki
@ 2009-10-26 18:56 ` Rafael J. Wysocki
2009-10-26 18:56 ` [Bug #14483] WARNING: at drivers/base/sys.c:353 __sysdev_resume+0x54/0xca() Rafael J. Wysocki
` (2 subsequent siblings)
41 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:56 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Alexander Clouter
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14482
Subject : kernel BUG at fs/dcache.c:670 +lvm +md +ext3
Submitter : Alexander Clouter <alex@digriz.org.uk>
Date : 2009-10-23 10:30 (4 days old)
References : http://lkml.org/lkml/2009/10/23/50
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14483] WARNING: at drivers/base/sys.c:353 __sysdev_resume+0x54/0xca()
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (38 preceding siblings ...)
2009-10-26 18:56 ` [Bug #14482] kernel BUG at fs/dcache.c:670 +lvm +md +ext3 Rafael J. Wysocki
@ 2009-10-26 18:56 ` Rafael J. Wysocki
2009-10-26 20:08 ` Justin P. Mattock
2009-10-26 18:56 ` [Bug #14484] no video output after suspend Rafael J. Wysocki
2009-10-26 18:56 ` [Bug #14485] System lockup running "cat /sys/kernel/debug/dri/0/i915_regs" Rafael J. Wysocki
41 siblings, 1 reply; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:56 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Justin Mattock
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14483
Subject : WARNING: at drivers/base/sys.c:353 __sysdev_resume+0x54/0xca()
Submitter : Justin Mattock <justinmattock-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-10-25 19:58 (2 days old)
References : http://marc.info/?l=linux-kernel&m=125650070420168&w=4
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14484] no video output after suspend
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (39 preceding siblings ...)
2009-10-26 18:56 ` [Bug #14483] WARNING: at drivers/base/sys.c:353 __sysdev_resume+0x54/0xca() Rafael J. Wysocki
@ 2009-10-26 18:56 ` Rafael J. Wysocki
2009-10-27 21:25 ` Riccardo Magliocchetti
2009-10-26 18:56 ` [Bug #14485] System lockup running "cat /sys/kernel/debug/dri/0/i915_regs" Rafael J. Wysocki
41 siblings, 1 reply; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:56 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Kernel Testers List, Jesse Barnes, Riccardo Magliocchetti
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14484
Subject : no video output after suspend
Submitter : Riccardo Magliocchetti <riccardo.magliocchetti@gmail.com>
Date : 2009-10-25 20:57 (2 days old)
References : http://marc.info/?l=linux-kernel&m=125650430123713&w=4
Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org>
^ permalink raw reply [flat|nested] 128+ messages in thread* [Bug #14485] System lockup running "cat /sys/kernel/debug/dri/0/i915_regs"
2009-10-26 18:45 2.6.32-rc5-git3: Reported regressions from 2.6.31 Rafael J. Wysocki
` (40 preceding siblings ...)
2009-10-26 18:56 ` [Bug #14484] no video output after suspend Rafael J. Wysocki
@ 2009-10-26 18:56 ` Rafael J. Wysocki
41 siblings, 0 replies; 128+ messages in thread
From: Rafael J. Wysocki @ 2009-10-26 18:56 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Miles Lane
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.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14485
Subject : System lockup running "cat /sys/kernel/debug/dri/0/i915_regs"
Submitter : Miles Lane <miles.lane-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-10-26 4:00 (1 days old)
References : http://marc.info/?l=linux-kernel&m=125652968117713&w=4
^ permalink raw reply [flat|nested] 128+ messages in thread