* Re: Linux 2.6.16-rc3
2006-02-13 3:05 ` Andrew Morton
@ 2006-02-13 3:22 ` Trond Myklebust
2006-02-13 15:09 ` Benjamin LaHaise
2006-02-13 3:28 ` Sanjoy Mahajan
` (14 subsequent siblings)
15 siblings, 1 reply; 104+ messages in thread
From: Trond Myklebust @ 2006-02-13 3:22 UTC (permalink / raw)
To: Andrew Morton
Cc: Linus Torvalds, linux-kernel, Jens Axboe, James Bottomley,
Brown, Len, David S. Miller, Greg KH, linux-acpi, linux-usb-devel,
Yu, Luming, Ben Castricum, sanjoy, Helge Hafting, Carlo E. Prelz,
Gerrit Bruchhäuser, Nicolas.Mailhot, Jaroslav Kysela,
Takashi Iwai, Patrizio Bassi, Björn Nilsson,
Andrey Borzenkov, P. Christeas, ghrt, jinhong hu, Andrew Vasquez,
linux-scsi, Benjamin LaHaise
On Sun, 2006-02-12 at 19:05 -0800, Andrew Morton wrote:
> We still have some serious bugs, several of which are in 2.6.15 as well:
> - Benjamin LaHaise <bcrl@kvack.org> had an NFS problem ("NFS processes
> gettting stuck in D with currrent git").
...but which was apparently not repeatable:
As of this afternoon's tree
(6150c32589d1976ca8a5c987df951088c05a7542) after the more
recent set of nfs patches, it seems to be behaving itself. Will
keep sysrq enabled to see if it hits again, though.
I've had no news from Ben since then...
Cheers,
Trond
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3
2006-02-13 3:22 ` Trond Myklebust
@ 2006-02-13 15:09 ` Benjamin LaHaise
0 siblings, 0 replies; 104+ messages in thread
From: Benjamin LaHaise @ 2006-02-13 15:09 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Andrew Morton, Linus Torvalds, linux-kernel
On Sun, Feb 12, 2006 at 10:22:55PM -0500, Trond Myklebust wrote:
> > - Benjamin LaHaise <bcrl@kvack.org> had an NFS problem ("NFS processes
> > gettting stuck in D with currrent git").
>
> ...but which was apparently not repeatable:
>
> As of this afternoon's tree
> (6150c32589d1976ca8a5c987df951088c05a7542) after the more
> recent set of nfs patches, it seems to be behaving itself. Will
> keep sysrq enabled to see if it hits again, though.
>
> I've had no news from Ben since then...
Confirmed: I've had no problems with NFS since that update, and my test
box uses NFS regularly.
-ben
--
"Ladies and gentlemen, I'm sorry to interrupt, but the police are here
and they've asked us to stop the party." Don't Email: <dont@kvack.org>.
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Linux 2.6.16-rc3
2006-02-13 3:05 ` Andrew Morton
2006-02-13 3:22 ` Trond Myklebust
@ 2006-02-13 3:28 ` Sanjoy Mahajan
2006-02-13 3:36 ` Jeff Garzik
` (13 subsequent siblings)
15 siblings, 0 replies; 104+ messages in thread
From: Sanjoy Mahajan @ 2006-02-13 3:28 UTC (permalink / raw)
To: Andrew Morton
Cc: Linus Torvalds, linux-kernel, Jens Axboe, James Bottomley,
Brown, Len, David S. Miller, Greg KH, linux-acpi, linux-usb-devel,
Yu, Luming, Ben Castricum, Helge Hafting, Carlo E. Prelz,
Gerrit Bruchhäuser, Nicolas.Mailhot, Jaroslav Kysela,
Takashi Iwai, Patrizio Bassi, Björn Nilsson,
Andrey Borzenkov, P. Christeas, ghrt, jinhong hu, Andrew Vasquez,
linux-scsi, Benjamin LaHaise
> In http://bugzilla.kernel.org/show_bug.cgi?id=5989, Sanjoy Mahajan has
> another regression, but he's off collecting more info.
I'm nearly done with bisecting (spent a day on a wild bisect goose
chase due to being careless) and I'm 95% sure the problem is
introduced by:
commit b8e4d89357fc434618a59c1047cac72641191805
Author: Bob Moore <robert.moore@intel.com>
Date: Fri Jan 27 16:43:00 2006 -0500
[ACPI] ACPICA 20060127
But I will know for sure shortly.
-Sanjoy
`Never underestimate the evil of which men of power are capable.'
--Bertrand Russell, _War Crimes in Vietnam_, chapter 1.
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3
2006-02-13 3:05 ` Andrew Morton
2006-02-13 3:22 ` Trond Myklebust
2006-02-13 3:28 ` Sanjoy Mahajan
@ 2006-02-13 3:36 ` Jeff Garzik
2006-02-13 4:40 ` James Bottomley
` (12 subsequent siblings)
15 siblings, 0 replies; 104+ messages in thread
From: Jeff Garzik @ 2006-02-13 3:36 UTC (permalink / raw)
To: Andrew Morton
Cc: Linus Torvalds, linux-kernel, Jens Axboe, James Bottomley,
Brown, Len, David S. Miller, Greg KH, linux-acpi, linux-usb-devel,
Yu, Luming, Ben Castricum, sanjoy, Helge Hafting, Carlo E. Prelz,
Gerrit Bruchhäuser, Nicolas.Mailhot, Jaroslav Kysela,
Takashi Iwai, Patrizio Bassi, Björn Nilsson,
Andrey Borzenkov, P. Christeas, ghrt, jinhong hu, Andrew Vasquez,
linux-scsi, Benjamin LaHaise
Andrew Morton wrote:
> - http://bugzilla.kernel.org/show_bug.cgi?id=5914 - a sata bug (which is
> quite unremarkable :(), but this one is reported to eat filesystems.
Issue closed, as the bug notes...
Jeff
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3
2006-02-13 3:05 ` Andrew Morton
` (2 preceding siblings ...)
2006-02-13 3:36 ` Jeff Garzik
@ 2006-02-13 4:40 ` James Bottomley
2006-02-13 5:20 ` S3 sleep regression bisected (was Re: Linux 2.6.16-rc3) Sanjoy Mahajan
` (11 subsequent siblings)
15 siblings, 0 replies; 104+ messages in thread
From: James Bottomley @ 2006-02-13 4:40 UTC (permalink / raw)
To: Andrew Morton
Cc: Linus Torvalds, linux-kernel, Jens Axboe, Brown, Len,
David S. Miller, Greg KH, linux-acpi, linux-usb-devel, Yu, Luming,
Ben Castricum, sanjoy, Helge Hafting, Carlo E. Prelz,
Gerrit Bruchhäuser, Nicolas.Mailhot, Jaroslav Kysela,
Takashi Iwai, Patrizio Bassi, Björn Nilsson,
Andrey Borzenkov, P. Christeas, ghrt, jinhong hu, Andrew Vasquez,
linux-scsi, Benjamin LaHaise
On Sun, 2006-02-12 at 19:05 -0800, Andrew Morton wrote:
> - The scsi_cmd leak, which I don't think is fixed.
Erm, you mean the leak caused by flush barriers? That was verified as
fixed (albeit accidentally) in 2.6.16-rc1.
James
^ permalink raw reply [flat|nested] 104+ messages in thread* S3 sleep regression bisected (was Re: Linux 2.6.16-rc3)
2006-02-13 3:05 ` Andrew Morton
` (3 preceding siblings ...)
2006-02-13 4:40 ` James Bottomley
@ 2006-02-13 5:20 ` Sanjoy Mahajan
2006-02-13 7:04 ` Linux 2.6.16-rc3 Arjan van de Ven
` (10 subsequent siblings)
15 siblings, 0 replies; 104+ messages in thread
From: Sanjoy Mahajan @ 2006-02-13 5:20 UTC (permalink / raw)
To: Andrew Morton
Cc: Linus Torvalds, linux-kernel, Jens Axboe, James Bottomley,
Brown, Len, David S. Miller, Greg KH, linux-acpi, linux-usb-devel,
Yu, Luming, Ben Castricum, Helge Hafting, Carlo E. Prelz,
Gerrit Bruchhäuser, Nicolas.Mailhot, Jaroslav Kysela,
Takashi Iwai, Patrizio Bassi, Björn Nilsson,
Andrey Borzenkov, P. Christeas, ghrt, jinhong hu, Andrew Vasquez,
linux-scsi, Benjamin LaHaise
> In http://bugzilla.kernel.org/show_bug.cgi?id=5989, Sanjoy Mahajan has
> another regression, but he's off collecting more info.
Now collected. The problematic commit is:
bad: [292dd876ee765c478b27c93cc51e93a558ed58bf] Pull release into acpica branch
The longer story follows (and I'll file it with the bugzilla). The
bug is that S3 sleep hangs on the second sleep of my TP 600X,
producing an endless loop in the dmesgs (across a serial console):
exregion-0182 [30] ex_system_memory_space: system_memory 0 (32 width) Address=0000000023FDFFC0
exregion-0182 [30] ex_system_memory_space: system_memory 1 (32 width) Address=0000000023FDFFC0
exregion-0287 [30] ex_system_io_space_han: system_iO 1 (8 width) Address=00000000000000B2
exregion-0182 [29] ex_system_memory_space: system_memory 0 (32 width) Address=0000000023FDFFC0
'git bisect' narrowed the problematic commit to:
commit 292dd876ee765c478b27c93cc51e93a558ed58bf
Merge: d4ec6c7cc9a15a7a529719bc3b84f46812f9842e
9fdb62af92c741addbea15545f214a6e89460865
Author: Len Brown <len.brown@intel.com>
Date: Fri Jan 27 17:18:29 2006 -0500
Pull release into acpica branch
This commit had a slightly different bug from all the other ones I
marked as bad. This one hung on the first S3 sleep, with the same
endless loop pattern as the other bad ones (but they hang on the
second S3 sleep).
Below is the 'git bisect log', which for fun you can put in some file
and feed to 'git bisect replay somefile' :
$ git bisect log
git-bisect start
# good: [f3bcf72eb85aba88a7bd0a6116dd0b5418590dbe] Linux v2.6.16-rc1
git-bisect good f3bcf72eb85aba88a7bd0a6116dd0b5418590dbe
# bad: [e4f9aae0d74cb7d2fd5f0eb315cf9de1118fe260] Linux v2.6.16-rc2
git-bisect bad e4f9aae0d74cb7d2fd5f0eb315cf9de1118fe260
# good: [a6df590dd8b7644c8e298e3b13442bcd6ceeb739] Merge branch 'for-linus' of master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband
git-bisect good a6df590dd8b7644c8e298e3b13442bcd6ceeb739
# good: [e0e851cf30f1a9bd2e2a7624e9810378d6a2b072] reiserfs: reiserfs hang and performance fix for data=journal mode
git-bisect good e0e851cf30f1a9bd2e2a7624e9810378d6a2b072
# bad: [59ed2f59e4ea6a32f9591e378da7935f713a7000] Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6
git-bisect bad 59ed2f59e4ea6a32f9591e378da7935f713a7000
# good: [9fdb62af92c741addbea15545f214a6e89460865] [ACPI] merge 3549 4320 4485 4588 4980 5483 5651 acpica asus fops pnpacpi branches into release
git-bisect good 9fdb62af92c741addbea15545f214a6e89460865
# good: [61ee9cd5f2e76859222c1d64394ae633f9080163] PowerPC/PCI Hotplug build break
git-bisect good 61ee9cd5f2e76859222c1d64394ae633f9080163
# good: [e6da74e1f20ea7822e52a9e4fbd3d25bd907e471] Merge with /pub/scm/linux/kernel/git/torvalds/linux-2.6.git
git-bisect good e6da74e1f20ea7822e52a9e4fbd3d25bd907e471
# bad: [b8e4d89357fc434618a59c1047cac72641191805] [ACPI] ACPICA 20060127
git-bisect bad b8e4d89357fc434618a59c1047cac72641191805
# bad: [292dd876ee765c478b27c93cc51e93a558ed58bf] Pull release into acpica branch
git-bisect bad 292dd876ee765c478b27c93cc51e93a558ed58bf
# good: [d4ec6c7cc9a15a7a529719bc3b84f46812f9842e] [ACPI] remove "Resource isn't an IRQ" warning
git-bisect good d4ec6c7cc9a15a7a529719bc3b84f46812f9842e
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3
2006-02-13 3:05 ` Andrew Morton
` (4 preceding siblings ...)
2006-02-13 5:20 ` S3 sleep regression bisected (was Re: Linux 2.6.16-rc3) Sanjoy Mahajan
@ 2006-02-13 7:04 ` Arjan van de Ven
2006-02-13 8:11 ` Jens Axboe
` (9 subsequent siblings)
15 siblings, 0 replies; 104+ messages in thread
From: Arjan van de Ven @ 2006-02-13 7:04 UTC (permalink / raw)
To: Andrew Morton
Cc: Linus Torvalds, linux-kernel, Jens Axboe, James Bottomley,
Brown, Len, David S. Miller, Greg KH, linux-acpi, linux-usb-devel,
Yu, Luming, Ben Castricum, sanjoy, Helge Hafting, Carlo E. Prelz,
Gerrit Bruchhäuser, Nicolas.Mailhot, Jaroslav Kysela,
Takashi Iwai, Patrizio Bassi, Björn Nilsson,
Andrey Borzenkov, P. Christeas, ghrt, jinhong hu, Andrew Vasquez,
linux-scsi, Benjamin LaHaise
On Sun, 2006-02-12 at 19:05 -0800, Andrew Morton wrote:
> We still have some serious bugs, several of which are in 2.6.15 as well:
>
> - The scsi_cmd leak, which I don't think is fixed.
didn't this got nailed down to a 2.6.15 specific queueing bug, fixed in
2.6.16-rc ?
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3
2006-02-13 3:05 ` Andrew Morton
` (5 preceding siblings ...)
2006-02-13 7:04 ` Linux 2.6.16-rc3 Arjan van de Ven
@ 2006-02-13 8:11 ` Jens Axboe
2006-02-13 9:22 ` Patrizio Bassi
` (8 subsequent siblings)
15 siblings, 0 replies; 104+ messages in thread
From: Jens Axboe @ 2006-02-13 8:11 UTC (permalink / raw)
To: Andrew Morton
Cc: Linus Torvalds, linux-kernel, James Bottomley, Brown, Len,
David S. Miller, Greg KH, linux-acpi, linux-usb-devel, Yu, Luming,
Ben Castricum, sanjoy, Helge Hafting, Carlo E. Prelz,
Gerrit Bruchhäuser, Nicolas.Mailhot, Jaroslav Kysela,
Takashi Iwai, Patrizio Bassi, Björn Nilsson,
Andrey Borzenkov, P. Christeas, ghrt, jinhong hu, Andrew Vasquez,
linux-scsi, Benjamin LaHaise
On Sun, Feb 12 2006, Andrew Morton wrote:
>
> We still have some serious bugs, several of which are in 2.6.15 as well:
>
> - The scsi_cmd leak, which I don't think is fixed.
It is fixed in 2.6.16-rcX.
> - The some-x86_64-boxes-use-GFP_DMA-from-bio-layer bug, which causes
> oom-killings.
Still pending.
--
Jens Axboe
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3
2006-02-13 3:05 ` Andrew Morton
` (6 preceding siblings ...)
2006-02-13 8:11 ` Jens Axboe
@ 2006-02-13 9:22 ` Patrizio Bassi
2006-02-13 10:07 ` Linux 2.6.16-rc3 - x86_64 specific outstanding bugs Andi Kleen
` (7 subsequent siblings)
15 siblings, 0 replies; 104+ messages in thread
From: Patrizio Bassi @ 2006-02-13 9:22 UTC (permalink / raw)
To: Andrew Morton
Cc: Linus Torvalds, linux-kernel, Jens Axboe, James Bottomley,
Brown, Len, David S. Miller, Greg KH, linux-acpi, linux-usb-devel,
Yu, Luming, Ben Castricum, sanjoy, Helge Hafting, Carlo E. Prelz,
Gerrit Bruchhäuser, Nicolas.Mailhot, Jaroslav Kysela,
Takashi Iwai, Björn Nilsson, Andrey Borzenkov, P. Christeas,
ghrt, jinhong hu, Andrew Vasquez, linux-scsi, Benjamin LaHaise
Andrew Morton ha scritto:
> We still have some serious bugs, several of which are in 2.6.15 as well:
>
> - The scsi_cmd leak, which I don't think is fixed.
>
> - The some-x86_64-boxes-use-GFP_DMA-from-bio-layer bug, which causes
> oom-killings.
>
> - The skbuff_head_cache leak, which has been around since at least
> 2.6.11. Another box-killer, but is seems very hard to hit.
> (mki@mozone.net, "the dreaded oom-killer (reproducable in 2.6.11 -
> 2.6.16-rc1) :(")
>
> - http://bugzilla.kernel.org/show_bug.cgi?id=6060: an apparent ACPI
> regression.
>
> - Nathan's "sysfs-related oops during module unload", which Greg seems to
> have under control.
>
> - http://bugzilla.kernel.org/show_bug.cgi?id=6049 - another acpi
> regression. We have the actual offending commit here.
>
> - A couple of random tty-related oopses reported by Jesper Juhl. We
> don't know why these happened - they appear to not be related to the tty
> buffering changes.
>
> - http://bugzilla.kernel.org/show_bug.cgi?id=6038, another box-killing
> acpi regression.
>
> - Various reports similar to
> http://bugzilla.kernel.org/show_bug.cgi?id=6011, seemingly related to USB
> PCI quirk handling.
>
> - "Ben Castricum" <lk@bencastricum.nl> reports that ppp has started
> exhibiting mysterious failures (again).
>
> - Nasty warnings from scsi about kobject-layer things being called from
> irq context. James has a push-it-to-process-context patch which sadly
> assumes kmalloc() is immortal, but no other fix seems to have offered
> itself.
>
> - In http://bugzilla.kernel.org/show_bug.cgi?id=5989, Sanjoy Mahajan has
> another regression, but he's off collecting more info.
>
> - Helge Hafting reports a usb printer regression - I don't know if that's
> still live?
>
> - "Carlo E. Prelz" <fluido@fluido.as> has another USB/ehci regression
> ("ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15
> rc1").
>
> - Gerrit Bruchhuser <gbruchhaeuser@gmx.de> seems to have an aic7xxx
> regression ("AHA-7850 doesn't detect scanner anymore") but he doesn't say
> which kernel got it right.
>
> - http://bugzilla.kernel.org/show_bug.cgi?id=5914 - a sata bug (which is
> quite unremarkable :(), but this one is reported to eat filesystems.
>
> - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
> regression ("alsa suspend/resume continues to fail for ens1370")
>
> - Bjorn Nilsson <bni.swe@gmail.com> has an sk99lin regression ("3COM
> 3C940, does not work anymore after upgrade to 2.6.15")
>
> - Andrey Borzenkov <arvidjaar@mail.ru> has an acpi-cpufreq regression
> ("cannot unload acpi-cpufreq")
>
> - "P. Christeas" <p_christ@hol.gr> had an autofs regression ("Regression
> in Autofs, 2.6.15-git"), whic might be fixed now?
>
> - ghrt <ghrt@dial.kappa.ro> reports an alsa regression ("PROBLEM: SB
> Live! 5.1 (emu10k1, rev. 0a) doesn't work with 2.6.15")
>
> - jinhong hu <jinhong.hu@gmail.com> reports what appears to be a qlogic
> regression ("kernel 2.6.15 scsi problem")
>
> - Benjamin LaHaise <bcrl@kvack.org> had an NFS problem ("NFS processes
> gettting stuck in D with currrent git").
>
>
>
> These are clear regressions, reported in the last month by people who are
> willing to test patches. They're almost all in subsystems which have
> active and professional maintainers.
>
>
Really sad to say, but my Alsa ens1370 regression due to suspend problem
is still there.
Only fix is reboot actually. Ready to patch :)
PS.
i have a bug similar to:
http://bugzilla.kernel.org/show_bug.cgi?id=6038 (marked as blocking by
Andrew)
on my laptop.
but my dma expiry problem only happens during suspend.
I have a Sis 630 chipset with a 2.5" hitachi drive.
Been there...for ages..i can say: always...never got a working 2.6 kernel.
However in my poor opinion it's not blocking on my system, just boring.
Patrizio
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3 - x86_64 specific outstanding bugs.
2006-02-13 3:05 ` Andrew Morton
` (7 preceding siblings ...)
2006-02-13 9:22 ` Patrizio Bassi
@ 2006-02-13 10:07 ` Andi Kleen
2006-02-13 12:02 ` Linux 2.6.16-rc3 Takashi Iwai
` (6 subsequent siblings)
15 siblings, 0 replies; 104+ messages in thread
From: Andi Kleen @ 2006-02-13 10:07 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, discuss
Andrew Morton <akpm@osdl.org> writes:
[Note to people who find this using google in some archive.
This list is for an old kernel and totally obsolete. Don't email me
about asking about it. Use a newer kernel.]
> We still have some serious bugs, several of which are in 2.6.15 as well:
>From the x86-64 side for 2.6.16:
- Still oopses with mbind in some setups that I need to fix.
Problem at least understood now. Should be fixed. Related to
GFP_DMA32
- mbind can currently cause a local dos by starting the OOM killer
early. Christoph Lameter has patches that should be added.
- Doesn't boot on Opterons with nodes in the middle unpopulated.
I can reproduce on SimNow, but still need to fix (unfortunately
it completely changes when I add any debugging code)
- kg_crashme causes do_exit be called with interrupts disabled.
Need to fix that.
- logical cpu hot replug on multiprocessor opterons hangs the machine.
Prime suspect is the powernow-k8 driver.
- Nested kprobes are broken and cause a stack overflow on the int3
stack. Impossible to fix fully, but should support nesting for
a few levels at least. The systemtap testsuite triggers this apparently.
- The ATI timer fix using the local APIC timer breaks on many AMD
laptops who don't run the APIC timer in C2. Latest plan is to switch
to the RTC interrupt on these machines, but still needs to be implemented.
Also some other not well researched timer issue on the usual suspects
(mainly nforce3 laptops which seem to have all kind of broken timing),
but some of that might be related to the completely different timer
code in -mm* which seems to miss all the latest fixes.
-Andi
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3
2006-02-13 3:05 ` Andrew Morton
` (8 preceding siblings ...)
2006-02-13 10:07 ` Linux 2.6.16-rc3 - x86_64 specific outstanding bugs Andi Kleen
@ 2006-02-13 12:02 ` Takashi Iwai
2006-02-13 12:37 ` Patrizio Bassi
` (3 more replies)
2006-02-13 16:10 ` Adrian Bunk
` (5 subsequent siblings)
15 siblings, 4 replies; 104+ messages in thread
From: Takashi Iwai @ 2006-02-13 12:02 UTC (permalink / raw)
To: Andrew Morton
Cc: Linus Torvalds, linux-kernel, Jens Axboe, James Bottomley,
Brown, Len, David S. Miller, Greg KH, linux-acpi, linux-usb-devel,
Yu, Luming, Ben Castricum, sanjoy, Helge Hafting, Carlo E. Prelz,
Gerrit Bruchhäuser, Nicolas.Mailhot, Jaroslav Kysela,
Patrizio Bassi, Björn Nilsson, Andrey Borzenkov,
P. Christeas, ghrt, jinhong hu, Andrew Vasquez, linux-scsi,
Benjamin LaHaise
At Sun, 12 Feb 2006 19:05:20 -0800,
Andrew Morton wrote:
>
> - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
> regression ("alsa suspend/resume continues to fail for ens1370")
It's not a "regression". PM didn't work with ens1370 at all in the
eralier version.
About the problem there, I have no idea now what's wrong. The
suspend-to-disk works fine if the driver is built as module but not as
built-in kernel.
> - ghrt <ghrt@dial.kappa.ro> reports an alsa regression ("PROBLEM: SB
> Live! 5.1 (emu10k1, rev. 0a) doesn't work with 2.6.15")
I couldn't find this bugzilla entry...
Takashi
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3
2006-02-13 12:02 ` Linux 2.6.16-rc3 Takashi Iwai
@ 2006-02-13 12:37 ` Patrizio Bassi
2006-02-13 13:13 ` Takashi Iwai
2006-02-13 13:09 ` Rafael J. Wysocki
` (2 subsequent siblings)
3 siblings, 1 reply; 104+ messages in thread
From: Patrizio Bassi @ 2006-02-13 12:37 UTC (permalink / raw)
To: Takashi Iwai
Cc: Andrew Morton, Linus Torvalds, linux-kernel, Jens Axboe,
James Bottomley, Brown, Len, David S. Miller, Greg KH, linux-acpi,
linux-usb-devel, Yu, Luming, Ben Castricum, sanjoy, Helge Hafting,
Carlo E. Prelz, Gerrit Bruchhäuser, Nicolas.Mailhot,
Jaroslav Kysela, Björn Nilsson, Andrey Borzenkov,
P. Christeas, ghrt, jinhong hu, Andrew Vasquez, linux-scsi,
Benjamin LaHaise
Takashi Iwai ha scritto:
> At Sun, 12 Feb 2006 19:05:20 -0800,
> Andrew Morton wrote:
>
>> - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
>> regression ("alsa suspend/resume continues to fail for ens1370")
>>
>
> It's not a "regression". PM didn't work with ens1370 at all in the
> eralier version.
>
> About the problem there, I have no idea now what's wrong. The
> suspend-to-disk works fine if the driver is built as module but not as
> built-in kernel.
>
>
>
i wrote "regression" because before (ehm...exactly don't know...about
2.6.14 time)
after suspend i had to restart my distro's mixer values service or i
couldn't hear anything.
and...ok..it was boring but worked.
now i get 0x660 errors if i try to restore values and device seems dead,
just flood the syslog.
sound apps slow down (like 100% cpu usage) and no sound produced.
only fix is reboot.
>> - ghrt <ghrt@dial.kappa.ro> reports an alsa regression ("PROBLEM: SB
>> Live! 5.1 (emu10k1, rev. 0a) doesn't work with 2.6.15")
>>
>
> I couldn't find this bugzilla entry...
>
>
> Takashi
>
>
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3
2006-02-13 12:37 ` Patrizio Bassi
@ 2006-02-13 13:13 ` Takashi Iwai
2006-02-13 13:31 ` Patrizio Bassi
0 siblings, 1 reply; 104+ messages in thread
From: Takashi Iwai @ 2006-02-13 13:13 UTC (permalink / raw)
To: patrizio.bassi
Cc: Andrew Morton, Linus Torvalds, linux-kernel, Jens Axboe,
James Bottomley, Brown, Len, David S. Miller, Greg KH, linux-acpi,
linux-usb-devel, Yu, Luming, Ben Castricum, sanjoy, Helge Hafting,
Carlo E. Prelz, Gerrit Bruchhäuser, Nicolas.Mailhot,
Jaroslav Kysela, Björn Nilsson, Andrey Borzenkov,
P. Christeas, ghrt, jinhong hu, Andrew Vasquez, linux-scsi,
Benjamin LaHaise
At Mon, 13 Feb 2006 13:37:55 +0100,
Patrizio Bassi wrote:
>
> Takashi Iwai ha scritto:
> > At Sun, 12 Feb 2006 19:05:20 -0800,
> > Andrew Morton wrote:
> >
> >> - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
> >> regression ("alsa suspend/resume continues to fail for ens1370")
> >>
> >
> > It's not a "regression". PM didn't work with ens1370 at all in the
> > eralier version.
> >
> > About the problem there, I have no idea now what's wrong. The
> > suspend-to-disk works fine if the driver is built as module but not as
> > built-in kernel.
> >
> >
> >
> i wrote "regression" because before (ehm...exactly don't know...about
> 2.6.14 time)
> after suspend i had to restart my distro's mixer values service or i
> couldn't hear anything.
> and...ok..it was boring but worked.
You abused the function which wasn't officially supported :)
Takashi
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3
2006-02-13 13:13 ` Takashi Iwai
@ 2006-02-13 13:31 ` Patrizio Bassi
2006-02-13 14:15 ` Takashi Iwai
0 siblings, 1 reply; 104+ messages in thread
From: Patrizio Bassi @ 2006-02-13 13:31 UTC (permalink / raw)
To: Takashi Iwai
Cc: Andrew Morton, Linus Torvalds, linux-kernel, Jens Axboe,
James Bottomley, Brown, Len, David S. Miller, Greg KH, linux-acpi,
linux-usb-devel, Yu, Luming, Ben Castricum, sanjoy, Helge Hafting,
Carlo E. Prelz, Gerrit Bruchhäuser, Nicolas.Mailhot,
Jaroslav Kysela, Björn Nilsson, Andrey Borzenkov,
P. Christeas, ghrt, jinhong hu, Andrew Vasquez, linux-scsi,
Benjamin LaHaise
Takashi Iwai ha scritto:
> At Mon, 13 Feb 2006 13:37:55 +0100,
> Patrizio Bassi wrote:
>
>> Takashi Iwai ha scritto:
>>
>>> At Sun, 12 Feb 2006 19:05:20 -0800,
>>> Andrew Morton wrote:
>>>
>>>
>>>> - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
>>>> regression ("alsa suspend/resume continues to fail for ens1370")
>>>>
>>>>
>>> It's not a "regression". PM didn't work with ens1370 at all in the
>>> eralier version.
>>>
>>> About the problem there, I have no idea now what's wrong. The
>>> suspend-to-disk works fine if the driver is built as module but not as
>>> built-in kernel.
>>>
>>>
>>>
>>>
>> i wrote "regression" because before (ehm...exactly don't know...about
>> 2.6.14 time)
>> after suspend i had to restart my distro's mixer values service or i
>> couldn't hear anything.
>> and...ok..it was boring but worked.
>>
>
> You abused the function which wasn't officially supported :)
>
>
> Takashi
>
>
nice i'm an abuser! :)
ok, seriously..that's bad, because before it was not implemented, so ok...
but now it fails with errors (and make apps not working properly) which
is worse.
Patrizio
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3
2006-02-13 13:31 ` Patrizio Bassi
@ 2006-02-13 14:15 ` Takashi Iwai
2006-02-13 14:34 ` Patrizio Bassi
0 siblings, 1 reply; 104+ messages in thread
From: Takashi Iwai @ 2006-02-13 14:15 UTC (permalink / raw)
To: patrizio.bassi
Cc: Andrew Morton, Linus Torvalds, linux-kernel, Jens Axboe,
James Bottomley, Brown, Len, David S. Miller, Greg KH, linux-acpi,
linux-usb-devel, Yu, Luming, Ben Castricum, sanjoy, Helge Hafting,
Carlo E. Prelz, Gerrit Bruchhäuser, Nicolas.Mailhot,
Jaroslav Kysela, Björn Nilsson, Andrey Borzenkov,
P. Christeas, ghrt, jinhong hu, Andrew Vasquez, linux-scsi,
Benjamin LaHaise
At Mon, 13 Feb 2006 14:31:23 +0100,
Patrizio Bassi wrote:
>
> Takashi Iwai ha scritto:
> > At Mon, 13 Feb 2006 13:37:55 +0100,
> > Patrizio Bassi wrote:
> >
> >> Takashi Iwai ha scritto:
> >>
> >>> At Sun, 12 Feb 2006 19:05:20 -0800,
> >>> Andrew Morton wrote:
> >>>
> >>>
> >>>> - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
> >>>> regression ("alsa suspend/resume continues to fail for ens1370")
> >>>>
> >>>>
> >>> It's not a "regression". PM didn't work with ens1370 at all in the
> >>> eralier version.
> >>>
> >>> About the problem there, I have no idea now what's wrong. The
> >>> suspend-to-disk works fine if the driver is built as module but not as
> >>> built-in kernel.
> >>>
> >>>
> >>>
> >>>
> >> i wrote "regression" because before (ehm...exactly don't know...about
> >> 2.6.14 time)
> >> after suspend i had to restart my distro's mixer values service or i
> >> couldn't hear anything.
> >> and...ok..it was boring but worked.
> >>
> >
> > You abused the function which wasn't officially supported :)
> >
> >
> > Takashi
> >
> >
> nice i'm an abuser! :)
>
> ok, seriously..that's bad, because before it was not implemented, so ok...
> but now it fails with errors (and make apps not working properly) which
> is worse.
My rough guess is the initialization order, the resume was called too
early.
What about to put sleep between snd_ensoniq_chip_init() and
snd_ak4531_resume()? Or put more delay in snd_ak4531_resume()?
Takashi
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3
2006-02-13 14:15 ` Takashi Iwai
@ 2006-02-13 14:34 ` Patrizio Bassi
2006-02-13 14:39 ` Takashi Iwai
0 siblings, 1 reply; 104+ messages in thread
From: Patrizio Bassi @ 2006-02-13 14:34 UTC (permalink / raw)
To: Takashi Iwai
Cc: Andrew Morton, Linus Torvalds, linux-kernel, Jens Axboe,
James Bottomley, Brown, Len, David S. Miller, Greg KH, linux-acpi,
linux-usb-devel, Yu, Luming, Ben Castricum, sanjoy, Helge Hafting,
Carlo E. Prelz, Gerrit Bruchhäuser, Nicolas.Mailhot,
Jaroslav Kysela, Björn Nilsson, Andrey Borzenkov,
P. Christeas, ghrt, jinhong hu, Andrew Vasquez, linux-scsi,
Benjamin LaHaise
Takashi Iwai ha scritto:
> At Mon, 13 Feb 2006 14:31:23 +0100,
> Patrizio Bassi wrote:
>
>> Takashi Iwai ha scritto:
>>
>>> At Mon, 13 Feb 2006 13:37:55 +0100,
>>> Patrizio Bassi wrote:
>>>
>>>
>>>> Takashi Iwai ha scritto:
>>>>
>>>>
>>>>> At Sun, 12 Feb 2006 19:05:20 -0800,
>>>>> Andrew Morton wrote:
>>>>>
>>>>>
>>>>>
>>>>>> - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
>>>>>> regression ("alsa suspend/resume continues to fail for ens1370")
>>>>>>
>>>>>>
>>>>>>
>>>>> It's not a "regression". PM didn't work with ens1370 at all in the
>>>>> eralier version.
>>>>>
>>>>> About the problem there, I have no idea now what's wrong. The
>>>>> suspend-to-disk works fine if the driver is built as module but not as
>>>>> built-in kernel.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> i wrote "regression" because before (ehm...exactly don't know...about
>>>> 2.6.14 time)
>>>> after suspend i had to restart my distro's mixer values service or i
>>>> couldn't hear anything.
>>>> and...ok..it was boring but worked.
>>>>
>>>>
>>> You abused the function which wasn't officially supported :)
>>>
>>>
>>> Takashi
>>>
>>>
>>>
>> nice i'm an abuser! :)
>>
>> ok, seriously..that's bad, because before it was not implemented, so ok...
>> but now it fails with errors (and make apps not working properly) which
>> is worse.
>>
>
> My rough guess is the initialization order, the resume was called too
> early.
>
> What about to put sleep between snd_ensoniq_chip_init() and
> snd_ak4531_resume()? Or put more delay in snd_ak4531_resume()?
>
>
> Takashi
>
>
i'm almost sure the problem is not there (or, at least not only)
infact i get 0x660 errors (or better a long flood...) while suspending too.
there may be a bug or problem during suspending, and these problems
affect the normal resume.
however sleep is not always trustable...soif you think that's an init
problem you may add a
boolean value to check if init is completed or not and poll for TRUE
value in the resume function.
but, as i wrote before, i'm not sure the problem is **only** there.
Patrizio
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3
2006-02-13 14:34 ` Patrizio Bassi
@ 2006-02-13 14:39 ` Takashi Iwai
0 siblings, 0 replies; 104+ messages in thread
From: Takashi Iwai @ 2006-02-13 14:39 UTC (permalink / raw)
To: patrizio.bassi
Cc: Andrew Morton, Linus Torvalds, linux-kernel, Jens Axboe,
James Bottomley, Brown, Len, David S. Miller, Greg KH, linux-acpi,
linux-usb-devel, Yu, Luming, Ben Castricum, sanjoy, Helge Hafting,
Carlo E. Prelz, Gerrit Bruchhäuser, Nicolas.Mailhot,
Jaroslav Kysela, Björn Nilsson, Andrey Borzenkov,
P. Christeas, ghrt, jinhong hu, Andrew Vasquez, linux-scsi,
Benjamin LaHaise
At Mon, 13 Feb 2006 15:34:28 +0100,
Patrizio Bassi wrote:
>
> Takashi Iwai ha scritto:
> > At Mon, 13 Feb 2006 14:31:23 +0100,
> > Patrizio Bassi wrote:
> >
> >> Takashi Iwai ha scritto:
> >>
> >>> At Mon, 13 Feb 2006 13:37:55 +0100,
> >>> Patrizio Bassi wrote:
> >>>
> >>>
> >>>> Takashi Iwai ha scritto:
> >>>>
> >>>>
> >>>>> At Sun, 12 Feb 2006 19:05:20 -0800,
> >>>>> Andrew Morton wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
> >>>>>> regression ("alsa suspend/resume continues to fail for ens1370")
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> It's not a "regression". PM didn't work with ens1370 at all in the
> >>>>> eralier version.
> >>>>>
> >>>>> About the problem there, I have no idea now what's wrong. The
> >>>>> suspend-to-disk works fine if the driver is built as module but not as
> >>>>> built-in kernel.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> i wrote "regression" because before (ehm...exactly don't know...about
> >>>> 2.6.14 time)
> >>>> after suspend i had to restart my distro's mixer values service or i
> >>>> couldn't hear anything.
> >>>> and...ok..it was boring but worked.
> >>>>
> >>>>
> >>> You abused the function which wasn't officially supported :)
> >>>
> >>>
> >>> Takashi
> >>>
> >>>
> >>>
> >> nice i'm an abuser! :)
> >>
> >> ok, seriously..that's bad, because before it was not implemented, so ok...
> >> but now it fails with errors (and make apps not working properly) which
> >> is worse.
> >>
> >
> > My rough guess is the initialization order, the resume was called too
> > early.
> >
> > What about to put sleep between snd_ensoniq_chip_init() and
> > snd_ak4531_resume()? Or put more delay in snd_ak4531_resume()?
> >
> >
> > Takashi
> >
> >
> i'm almost sure the problem is not there (or, at least not only)
> infact i get 0x660 errors (or better a long flood...) while suspending too.
IIRC, suspend calls resume callback once to revive the devices back.
So, basically you see the same problem here.
Takashi
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Linux 2.6.16-rc3
2006-02-13 12:02 ` Linux 2.6.16-rc3 Takashi Iwai
2006-02-13 12:37 ` Patrizio Bassi
@ 2006-02-13 13:09 ` Rafael J. Wysocki
2006-02-13 13:51 ` Takashi Iwai
2006-02-13 16:36 ` Thierry Vignaud
2006-02-13 16:36 ` Thierry Vignaud
3 siblings, 1 reply; 104+ messages in thread
From: Rafael J. Wysocki @ 2006-02-13 13:09 UTC (permalink / raw)
To: Takashi Iwai
Cc: Andrew Morton, Linus Torvalds, linux-kernel, Jens Axboe,
James Bottomley, Brown, Len, David S. Miller, Greg KH, linux-acpi,
linux-usb-devel, Yu, Luming, Ben Castricum, sanjoy, Helge Hafting,
Carlo E. Prelz, Gerrit Bruchhäuser, Nicolas.Mailhot,
Jaroslav Kysela, Patrizio Bassi, Björn Nilsson,
Andrey Borzenkov, P. Christeas, ghrt, jinhong hu, Andrew Vasquez,
linux-scsi, Benjamin LaHaise
On Monday 13 February 2006 13:02, Takashi Iwai wrote:
> At Sun, 12 Feb 2006 19:05:20 -0800,
> Andrew Morton wrote:
> >
> > - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
> > regression ("alsa suspend/resume continues to fail for ens1370")
>
> It's not a "regression". PM didn't work with ens1370 at all in the
> eralier version.
>
> About the problem there, I have no idea now what's wrong. The
> suspend-to-disk works fine if the driver is built as module but not as
> built-in kernel.
That may be related to the fact that modular drivers are not present in
memory during resume (just a thought).
Greetings,
Rafael
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3
2006-02-13 13:09 ` Rafael J. Wysocki
@ 2006-02-13 13:51 ` Takashi Iwai
2006-02-13 19:33 ` Rafael J. Wysocki
0 siblings, 1 reply; 104+ messages in thread
From: Takashi Iwai @ 2006-02-13 13:51 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Andrew Morton, Linus Torvalds, linux-kernel, Jens Axboe,
James Bottomley, Brown, Len, David S. Miller, Greg KH, linux-acpi,
linux-usb-devel, Yu, Luming, Ben Castricum, sanjoy, Helge Hafting,
Carlo E. Prelz, Gerrit Bruchhäuser, Nicolas.Mailhot,
Jaroslav Kysela, Patrizio Bassi, Björn Nilsson,
Andrey Borzenkov, P. Christeas, ghrt, jinhong hu, Andrew Vasquez,
linux-scsi, Benjamin LaHaise
At Mon, 13 Feb 2006 14:09:51 +0100,
Rafael J. Wysocki wrote:
>
> On Monday 13 February 2006 13:02, Takashi Iwai wrote:
> > At Sun, 12 Feb 2006 19:05:20 -0800,
> > Andrew Morton wrote:
> > >
> > > - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
> > > regression ("alsa suspend/resume continues to fail for ens1370")
> >
> > It's not a "regression". PM didn't work with ens1370 at all in the
> > eralier version.
> >
> > About the problem there, I have no idea now what's wrong. The
> > suspend-to-disk works fine if the driver is built as module but not as
> > built-in kernel.
>
> That may be related to the fact that modular drivers are not present in
> memory during resume (just a thought).
I think the modular drivers are on memory but the order of
re-initialization is different.
Takashi
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3
2006-02-13 13:51 ` Takashi Iwai
@ 2006-02-13 19:33 ` Rafael J. Wysocki
0 siblings, 0 replies; 104+ messages in thread
From: Rafael J. Wysocki @ 2006-02-13 19:33 UTC (permalink / raw)
To: Takashi Iwai
Cc: Andrew Morton, Linus Torvalds, linux-kernel, Jens Axboe,
James Bottomley, Brown, Len, David S. Miller, Greg KH, linux-acpi,
linux-usb-devel, Yu, Luming, Ben Castricum, sanjoy, Helge Hafting,
Carlo E. Prelz, Gerrit Bruchhäuser, Nicolas.Mailhot,
Jaroslav Kysela, Patrizio Bassi, Björn Nilsson,
Andrey Borzenkov, P. Christeas, ghrt, jinhong hu, Andrew Vasquez,
linux-scsi, Benjamin LaHaise
On Monday 13 February 2006 14:51, Takashi Iwai wrote:
> At Mon, 13 Feb 2006 14:09:51 +0100,
> Rafael J. Wysocki wrote:
> >
> > On Monday 13 February 2006 13:02, Takashi Iwai wrote:
> > > At Sun, 12 Feb 2006 19:05:20 -0800,
> > > Andrew Morton wrote:
> > > >
> > > > - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
> > > > regression ("alsa suspend/resume continues to fail for ens1370")
> > >
> > > It's not a "regression". PM didn't work with ens1370 at all in the
> > > eralier version.
> > >
> > > About the problem there, I have no idea now what's wrong. The
> > > suspend-to-disk works fine if the driver is built as module but not as
> > > built-in kernel.
> >
> > That may be related to the fact that modular drivers are not present in
> > memory during resume (just a thought).
>
> I think the modular drivers are on memory but the order of
> re-initialization is different.
No, they are not (this is the part I'm sure of). software_resume() is called
before any modules have a chance to be loaded unless you boot with
noresume, load them from an initrd and start the resume manually.
Greetings,
Rafael
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Linux 2.6.16-rc3
2006-02-13 12:02 ` Linux 2.6.16-rc3 Takashi Iwai
2006-02-13 12:37 ` Patrizio Bassi
2006-02-13 13:09 ` Rafael J. Wysocki
@ 2006-02-13 16:36 ` Thierry Vignaud
2006-02-15 6:51 ` Andrew Morton
2006-02-13 16:36 ` Thierry Vignaud
3 siblings, 1 reply; 104+ messages in thread
From: Thierry Vignaud @ 2006-02-13 16:36 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 457 bytes --]
Takashi Iwai <tiwai@suse.de> writes:
> It's not a "regression". PM didn't work with ens1370 at all in the
> eralier version.
btw, PM support in snd-intel8x0 is broken (at least regarding
suspending) in 2.6.16-rc2-mm1 on a nforce2 chipset
even if not playing while suspending, ALSA won't resume playing: no
more program can play anything strace show that sound programs block
on unfinished "futex(0xb7768060, FUTEX_WAIT, 29, NULL..." calls
lspci -vvvv:
[-- Attachment #2: bug.suspend.lspci --]
[-- Type: text/plain, Size: 8816 bytes --]
00:00.0 Host bridge: nVidia Corporation nForce CPU bridge (rev b2)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Region 0: Memory at d8000000 (32-bit, prefetchable) [size=64M]
Capabilities: <access denied>
00:00.1 RAM memory: nVidia Corporation nForce 220/420 Memory Controller (rev b2)
Subsystem: ABIT Computer Corp. Unknown device 7105
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
00:00.2 RAM memory: nVidia Corporation nForce 220/420 Memory Controller (rev b2)
Subsystem: ABIT Computer Corp. Unknown device 7105
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
00:00.3 RAM memory: nVidia Corporation nForce 420 Memory Controller (DDR) (rev b2)
Subsystem: ABIT Computer Corp. Unknown device 7105
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
00:01.0 ISA bridge: nVidia Corporation nForce ISA Bridge (rev c3)
Subsystem: ABIT Computer Corp. Unknown device 7105
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Capabilities: <access denied>
00:01.1 SMBus: nVidia Corporation nForce PCI System Management (rev c1)
Subsystem: ABIT Computer Corp. Unknown device 7105
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at 5000 [size=16]
Region 1: I/O ports at d000 [size=16]
Region 2: I/O ports at d400 [size=32]
Capabilities: <access denied>
00:02.0 USB Controller: nVidia Corporation nForce USB Controller (rev c3) (prog-if 10 [OHCI])
Subsystem: ABIT Computer Corp. Unknown device 7105
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin A routed to IRQ 5
Region 0: Memory at e0081000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <access denied>
00:03.0 USB Controller: nVidia Corporation nForce USB Controller (rev c3) (prog-if 10 [OHCI])
Subsystem: ABIT Computer Corp. Unknown device 7105
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin A routed to IRQ 3
Region 0: Memory at e0080000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <access denied>
00:05.0 Multimedia audio controller: nVidia Corporation nForce Audio (rev c2)
Subsystem: ABIT Computer Corp. Unknown device 7105
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (250ns min, 3000ns max)
Interrupt: pin A routed to IRQ 5
Region 0: Memory at e0000000 (32-bit, non-prefetchable) [size=512K]
Capabilities: <access denied>
00:06.0 Multimedia audio controller: nVidia Corporation nForce Audio (rev c2)
Subsystem: ABIT Computer Corp. Unknown device 7105
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (500ns min, 1250ns max)
Interrupt: pin A routed to IRQ 3
Region 0: I/O ports at d800 [size=256]
Region 1: I/O ports at dc00 [size=128]
Region 2: Memory at e0082000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <access denied>
00:08.0 PCI bridge: nVidia Corporation nForce PCI-to-PCI bridge (rev c2) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
I/O behind bridge: 0000c000-0000cfff
Memory behind bridge: de000000-dfffffff
Prefetchable memory behind bridge: 10000000-100fffff
Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
00:09.0 IDE interface: nVidia Corporation nForce IDE (rev c3) (prog-if 8a [Master SecP PriP])
Subsystem: ABIT Computer Corp. Unknown device 7105
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Region 4: I/O ports at e400 [size=16]
Capabilities: <access denied>
00:1e.0 PCI bridge: nVidia Corporation nForce AGP to PCI Bridge (rev b2) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32
Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: dc000000-ddffffff
Prefetchable memory behind bridge: d0000000-d7ffffff
Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA+ VGA+ MAbort- >Reset- FastB2B-
01:06.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 64)
Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2500ns min, 2500ns max), Cache Line Size 08
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at c000 [size=128]
Region 1: Memory at df000000 (32-bit, non-prefetchable) [size=128]
[virtual] Expansion ROM at 10000000 [disabled] [size=128K]
Capabilities: <access denied>
01:07.0 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
Subsystem: Adaptec Unknown device 0335
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (250ns min, 10500ns max), Cache Line Size 08
Interrupt: pin A routed to IRQ 12
Region 0: Memory at df001000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <access denied>
01:07.1 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
Subsystem: Adaptec Unknown device 0335
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (250ns min, 10500ns max), Cache Line Size 08
Interrupt: pin B routed to IRQ 11
Region 0: Memory at df002000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <access denied>
01:07.2 USB Controller: NEC Corporation USB 2.0 (rev 02) (prog-if 20 [EHCI])
Subsystem: Adaptec Unknown device 03e0
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (4000ns min, 8500ns max), Cache Line Size 10
Interrupt: pin C routed to IRQ 11
Region 0: Memory at df003000 (32-bit, non-prefetchable) [size=256]
Capabilities: <access denied>
02:00.0 VGA compatible controller: nVidia Corporation NVCrush11 [GeForce2 MX Integrated Graphics] (rev b1) (prog-if 00 [VGA])
Subsystem: ABIT Computer Corp. Unknown device 7105
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (1250ns min, 250ns max)
Interrupt: pin A routed to IRQ 12
Region 0: Memory at dc000000 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at d0000000 (32-bit, prefetchable) [size=128M]
[virtual] Expansion ROM at dd000000 [disabled] [size=64K]
Capabilities: <access denied>
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Linux 2.6.16-rc3
2006-02-13 16:36 ` Thierry Vignaud
@ 2006-02-15 6:51 ` Andrew Morton
2006-02-15 13:40 ` Thierry Vignaud
0 siblings, 1 reply; 104+ messages in thread
From: Andrew Morton @ 2006-02-15 6:51 UTC (permalink / raw)
To: Thierry Vignaud; +Cc: tiwai, linux-kernel
Thierry Vignaud <tvignaud@mandriva.com> wrote:
>
> Takashi Iwai <tiwai@suse.de> writes:
>
> > It's not a "regression". PM didn't work with ens1370 at all in the
> > eralier version.
>
> btw, PM support in snd-intel8x0 is broken (at least regarding
> suspending) in 2.6.16-rc2-mm1 on a nforce2 chipset
Can you identify when this breakage occurred?
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Linux 2.6.16-rc3
2006-02-15 6:51 ` Andrew Morton
@ 2006-02-15 13:40 ` Thierry Vignaud
2006-02-15 20:00 ` Andrew Morton
0 siblings, 1 reply; 104+ messages in thread
From: Thierry Vignaud @ 2006-02-15 13:40 UTC (permalink / raw)
To: Andrew Morton; +Cc: tiwai, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1724 bytes --]
Andrew Morton <akpm@osdl.org> writes:
> > > It's not a "regression". PM didn't work with ens1370 at all in
> > > the eralier version.
> >
> > btw, PM support in snd-intel8x0 is broken (at least regarding
> > suspending) in 2.6.16-rc2-mm1 on a nforce2 chipset
>
> Can you identify when this breakage occurred?
i'll try to compile a few older kernels (and/or just older
alsa-kernel) if you want but i'm not sure it's a regression (i'll
check if it has ever worked before).
i've tried unloading/reloading sound modules after resuming (maybe
would it work if unloaded before suspending but of course full PM
support would be nicer).
not sure if it can help but while resuming, the snd-intel8x0 printed
quite a lot of warnings (due to preempting[1] i guess?) such as:
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
<d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0] <c01b6dee> pci_device_resume+0x16/0x43
<c02025d9> resume_device+0x7d/0x96 <c02026a7> dpm_resume+0x58/0x80
<c02026dc> device_resume+0xd/0x16 <c012db1f> pm_suspend_disk+0xbf/0xc8
<c012cb95> enter_state+0x50/0x16f <c012cd37> state_store+0x83/0x8f
<c012ccb4> state_store+0x0/0x8f <c0173492> subsys_attr_store+0x1e/0x22
<c0173a1b> sysfs_write_file+0x92/0xb9 <c0173989> sysfs_write_file+0x0/0xb9
<c01491ca> vfs_write+0x83/0x122 <c01499df> sys_write+0x3c/0x63
<c0102973> sysenter_past_esp+0x54/0x75
dmesg after resuming (only look at the beginning, the end is only ehci
garbage b/c ehci is bugging for monthes (rejecting mass media after
writing a few Mo)):
[-- Attachment #2: bug.suspend.broken_dmesg1 --]
[-- Type: text/plain, Size: 70080 bytes --]
e+0x0/0xb9
<c01491ca> vfs_write+0x83/0x122 <c01499df> sys_write+0x3c/0x63
<c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
<d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0] <c01b6dee> pci_device_resume+0x16/0x43
<c02025d9> resume_device+0x7d/0x96 <c02026a7> dpm_resume+0x58/0x80
<c02026dc> device_resume+0xd/0x16 <c012db1f> pm_suspend_disk+0xbf/0xc8
<c012cb95> enter_state+0x50/0x16f <c012cd37> state_store+0x83/0x8f
<c012ccb4> state_store+0x0/0x8f <c0173492> subsys_attr_store+0x1e/0x22
<c0173a1b> sysfs_write_file+0x92/0xb9 <c0173989> sysfs_write_file+0x0/0xb9
<c01491ca> vfs_write+0x83/0x122 <c01499df> sys_write+0x3c/0x63
<c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
<d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0] <c01b6dee> pci_device_resume+0x16/0x43
<c02025d9> resume_device+0x7d/0x96 <c02026a7> dpm_resume+0x58/0x80
<c02026dc> device_resume+0xd/0x16 <c012db1f> pm_suspend_disk+0xbf/0xc8
<c012cb95> enter_state+0x50/0x16f <c012cd37> state_store+0x83/0x8f
<c012ccb4> state_store+0x0/0x8f <c0173492> subsys_attr_store+0x1e/0x22
<c0173a1b> sysfs_write_file+0x92/0xb9 <c0173989> sysfs_write_file+0x0/0xb9
<c01491ca> vfs_write+0x83/0x122 <c01499df> sys_write+0x3c/0x63
<c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
<d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0] <c01b6dee> pci_device_resume+0x16/0x43
<c02025d9> resume_device+0x7d/0x96 <c02026a7> dpm_resume+0x58/0x80
<c02026dc> device_resume+0xd/0x16 <c012db1f> pm_suspend_disk+0xbf/0xc8
<c012cb95> enter_state+0x50/0x16f <c012cd37> state_store+0x83/0x8f
<c012ccb4> state_store+0x0/0x8f <c0173492> subsys_attr_store+0x1e/0x22
<c0173a1b> sysfs_write_file+0x92/0xb9 <c0173989> sysfs_write_file+0x0/0xb9
<c01491ca> vfs_write+0x83/0x122 <c01499df> sys_write+0x3c/0x63
<c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
<d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0] <c01b6dee> pci_device_resume+0x16/0x43
<c02025d9> resume_device+0x7d/0x96 <c02026a7> dpm_resume+0x58/0x80
<c02026dc> device_resume+0xd/0x16 <c012db1f> pm_suspend_disk+0xbf/0xc8
<c012cb95> enter_state+0x50/0x16f <c012cd37> state_store+0x83/0x8f
<c012ccb4> state_store+0x0/0x8f <c0173492> subsys_attr_store+0x1e/0x22
<c0173a1b> sysfs_write_file+0x92/0xb9 <c0173989> sysfs_write_file+0x0/0xb9
<c01491ca> vfs_write+0x83/0x122 <c01499df> sys_write+0x3c/0x63
<c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
<d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0] <c01b6dee> pci_device_resume+0x16/0x43
<c02025d9> resume_device+0x7d/0x96 <c02026a7> dpm_resume+0x58/0x80
<c02026dc> device_resume+0xd/0x16 <c012db1f> pm_suspend_disk+0xbf/0xc8
<c012cb95> enter_state+0x50/0x16f <c012cd37> state_store+0x83/0x8f
<c012ccb4> state_store+0x0/0x8f <c0173492> subsys_attr_store+0x1e/0x22
<c0173a1b> sysfs_write_file+0x92/0xb9 <c0173989> sysfs_write_file+0x0/0xb9
<c01491ca> vfs_write+0x83/0x122 <c01499df> sys_write+0x3c/0x63
<c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
<d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0] <c01b6dee> pci_device_resume+0x16/0x43
<c02025d9> resume_device+0x7d/0x96 <c02026a7> dpm_resume+0x58/0x80
<c02026dc> device_resume+0xd/0x16 <c012db1f> pm_suspend_disk+0xbf/0xc8
<c012cb95> enter_state+0x50/0x16f <c012cd37> state_store+0x83/0x8f
<c012ccb4> state_store+0x0/0x8f <c0173492> subsys_attr_store+0x1e/0x22
<c0173a1b> sysfs_write_file+0x92/0xb9 <c0173989> sysfs_write_file+0x0/0xb9
<c01491ca> vfs_write+0x83/0x122 <c01499df> sys_write+0x3c/0x63
<c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
<d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0] <c01b6dee> pci_device_resume+0x16/0x43
<c02025d9> resume_device+0x7d/0x96 <c02026a7> dpm_resume+0x58/0x80
<c02026dc> device_resume+0xd/0x16 <c012db1f> pm_suspend_disk+0xbf/0xc8
<c012cb95> enter_state+0x50/0x16f <c012cd37> state_store+0x83/0x8f
<c012ccb4> state_store+0x0/0x8f <c0173492> subsys_attr_store+0x1e/0x22
<c0173a1b> sysfs_write_file+0x92/0xb9 <c0173989> sysfs_write_file+0x0/0xb9
<c01491ca> vfs_write+0x83/0x122 <c01499df> sys_write+0x3c/0x63
<c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
<d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0] <c01b6dee> pci_device_resume+0x16/0x43
<c02025d9> resume_device+0x7d/0x96 <c02026a7> dpm_resume+0x58/0x80
<c02026dc> device_resume+0xd/0x16 <c012db1f> pm_suspend_disk+0xbf/0xc8
<c012cb95> enter_state+0x50/0x16f <c012cd37> state_store+0x83/0x8f
<c012ccb4> state_store+0x0/0x8f <c0173492> subsys_attr_store+0x1e/0x22
<c0173a1b> sysfs_write_file+0x92/0xb9 <c0173989> sysfs_write_file+0x0/0xb9
<c01491ca> vfs_write+0x83/0x122 <c01499df> sys_write+0x3c/0x63
<c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
<d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0] <c01b6dee> pci_device_resume+0x16/0x43
<c02025d9> resume_device+0x7d/0x96 <c02026a7> dpm_resume+0x58/0x80
<c02026dc> device_resume+0xd/0x16 <c012db1f> pm_suspend_disk+0xbf/0xc8
<c012cb95> enter_state+0x50/0x16f <c012cd37> state_store+0x83/0x8f
<c012ccb4> state_store+0x0/0x8f <c0173492> subsys_attr_store+0x1e/0x22
<c0173a1b> sysfs_write_file+0x92/0xb9 <c0173989> sysfs_write_file+0x0/0xb9
<c01491ca> vfs_write+0x83/0x122 <c01499df> sys_write+0x3c/0x63
<c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
<d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0] <c01b6dee> pci_device_resume+0x16/0x43
<c02025d9> resume_device+0x7d/0x96 <c02026a7> dpm_resume+0x58/0x80
<c02026dc> device_resume+0xd/0x16 <c012db1f> pm_suspend_disk+0xbf/0xc8
<c012cb95> enter_state+0x50/0x16f <c012cd37> state_store+0x83/0x8f
<c012ccb4> state_store+0x0/0x8f <c0173492> subsys_attr_store+0x1e/0x22
<c0173a1b> sysfs_write_file+0x92/0xb9 <c0173989> sysfs_write_file+0x0/0xb9
<c01491ca> vfs_write+0x83/0x122 <c01499df> sys_write+0x3c/0x63
<c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
<d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0] <c01b6dee> pci_device_resume+0x16/0x43
<c02025d9> resume_device+0x7d/0x96 <c02026a7> dpm_resume+0x58/0x80
<c02026dc> device_resume+0xd/0x16 <c012db1f> pm_suspend_disk+0xbf/0xc8
<c012cb95> enter_state+0x50/0x16f <c012cd37> state_store+0x83/0x8f
<c012ccb4> state_store+0x0/0x8f <c0173492> subsys_attr_store+0x1e/0x22
<c0173a1b> sysfs_write_file+0x92/0xb9 <c0173989> sysfs_write_file+0x0/0xb9
<c01491ca> vfs_write+0x83/0x122 <c01499df> sys_write+0x3c/0x63
<c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
<d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0] <c01b6dee> pci_device_resume+0x16/0x43
<c02025d9> resume_device+0x7d/0x96 <c02026a7> dpm_resume+0x58/0x80
<c02026dc> device_resume+0xd/0x16 <c012db1f> pm_suspend_disk+0xbf/0xc8
<c012cb95> enter_state+0x50/0x16f <c012cd37> state_store+0x83/0x8f
<c012ccb4> state_store+0x0/0x8f <c0173492> subsys_attr_store+0x1e/0x22
<c0173a1b> sysfs_write_file+0x92/0xb9 <c0173989> sysfs_write_file+0x0/0xb9
<c01491ca> vfs_write+0x83/0x122 <c01499df> sys_write+0x3c/0x63
<c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
<d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0] <c01b6dee> pci_device_resume+0x16/0x43
<c02025d9> resume_device+0x7d/0x96 <c02026a7> dpm_resume+0x58/0x80
<c02026dc> device_resume+0xd/0x16 <c012db1f> pm_suspend_disk+0xbf/0xc8
<c012cb95> enter_state+0x50/0x16f <c012cd37> state_store+0x83/0x8f
<c012ccb4> state_store+0x0/0x8f <c0173492> subsys_attr_store+0x1e/0x22
<c0173a1b> sysfs_write_file+0x92/0xb9 <c0173989> sysfs_write_file+0x0/0xb9
<c01491ca> vfs_write+0x83/0x122 <c01499df> sys_write+0x3c/0x63
<c0102973> sysenter_past_esp+0x54/0x75
PCI: Setting latency timer of device 0000:00:08.0 to 64
ohci_hcd 0000:01:07.0: PCI D0, from previous PCI D3
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <c011d16a> msleep+0x17/0x1c
<c01b5d83> pci_set_power_state+0x127/0x16a <c01b5dd3> pci_enable_device_bars+0xd/0x38
<c01b5e0c> pci_enable_device+0xe/0x2c <cf848a1b> usb_hcd_pci_resume+0x11b/0x1b7 [usbcore]
<c01b6dee> pci_device_resume+0x16/0x43 <c02025d9> resume_device+0x7d/0x96
<c02026a7> dpm_resume+0x58/0x80 <c02026dc> device_resume+0xd/0x16
<c012db1f> pm_suspend_disk+0xbf/0xc8 <c012cb95> enter_state+0x50/0x16f
<c012cd37> state_store+0x83/0x8f <c012ccb4> state_store+0x0/0x8f
<c0173492> subsys_attr_store+0x1e/0x22 <c0173a1b> sysfs_write_file+0x92/0xb9
<c0173989> sysfs_write_file+0x0/0xb9 <c01491ca> vfs_write+0x83/0x122
<c01499df> sys_write+0x3c/0x63 <c0102973> sysenter_past_esp+0x54/0x75
ACPI: PCI Interrupt 0000:01:07.0[A] -> Link [LNK4] -> GSI 12 (level, low) -> IRQ 12
ohci_hcd 0000:01:07.1: PCI D0, from previous PCI D3
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <c011d16a> msleep+0x17/0x1c
<c01b5d83> pci_set_power_state+0x127/0x16a <c01b5dd3> pci_enable_device_bars+0xd/0x38
<c01b5e0c> pci_enable_device+0xe/0x2c <cf848a1b> usb_hcd_pci_resume+0x11b/0x1b7 [usbcore]
<c01b6dee> pci_device_resume+0x16/0x43 <c02025d9> resume_device+0x7d/0x96
<c02026a7> dpm_resume+0x58/0x80 <c02026dc> device_resume+0xd/0x16
<c012db1f> pm_suspend_disk+0xbf/0xc8 <c012cb95> enter_state+0x50/0x16f
<c012cd37> state_store+0x83/0x8f <c012ccb4> state_store+0x0/0x8f
<c0173492> subsys_attr_store+0x1e/0x22 <c0173a1b> sysfs_write_file+0x92/0xb9
<c0173989> sysfs_write_file+0x0/0xb9 <c01491ca> vfs_write+0x83/0x122
<c01499df> sys_write+0x3c/0x63 <c0102973> sysenter_past_esp+0x54/0x75
ACPI: PCI Interrupt 0000:01:07.1[B] -> Link [LNK1] -> GSI 11 (level, low) -> IRQ 11
ehci_hcd 0000:01:07.2: PCI D0, from previous PCI D3
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <c011d16a> msleep+0x17/0x1c
<c01b5d83> pci_set_power_state+0x127/0x16a <c01b5dd3> pci_enable_device_bars+0xd/0x38
<c01b5e0c> pci_enable_device+0xe/0x2c <cf848a1b> usb_hcd_pci_resume+0x11b/0x1b7 [usbcore]
<c01b6dee> pci_device_resume+0x16/0x43 <c02025d9> resume_device+0x7d/0x96
<c02026a7> dpm_resume+0x58/0x80 <c02026dc> device_resume+0xd/0x16
<c012db1f> pm_suspend_disk+0xbf/0xc8 <c012cb95> enter_state+0x50/0x16f
<c012cd37> state_store+0x83/0x8f <c012ccb4> state_store+0x0/0x8f
<c0173492> subsys_attr_store+0x1e/0x22 <c0173a1b> sysfs_write_file+0x92/0xb9
<c0173989> sysfs_write_file+0x0/0xb9 <c01491ca> vfs_write+0x83/0x122
<c01499df> sys_write+0x3c/0x63 <c0102973> sysenter_past_esp+0x54/0x75
ACPI: PCI Interrupt 0000:01:07.2[C] -> Link [LNK2] -> GSI 11 (level, low) -> IRQ 11
ehci_hcd 0000:01:07.2: lost power, restarting
usb usb5: root hub lost power or was reset
ehci_hcd 0000:01:07.2: reset command 080002 (park)=0 ithresh=8 period=1024 Reset HALT
ehci_hcd 0000:01:07.2: MWI active
ehci_hcd 0000:01:07.2: ...powerdown ports...
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <c011d16a> msleep+0x17/0x1c
<cf861ed1> ehci_pci_reinit+0xf6/0xfe [ehci_hcd] <cf86584f> ehci_pci_resume+0xbd/0x10a [ehci_hcd]
<cf848a7a> usb_hcd_pci_resume+0x17a/0x1b7 [usbcore] <c01b6dee> pci_device_resume+0x16/0x43
<c02025d9> resume_device+0x7d/0x96 <c02026a7> dpm_resume+0x58/0x80
<c02026dc> device_resume+0xd/0x16 <c012db1f> pm_suspend_disk+0xbf/0xc8
<c012cb95> enter_state+0x50/0x16f <c012cd37> state_store+0x83/0x8f
<c012ccb4> state_store+0x0/0x8f <c0173492> subsys_attr_store+0x1e/0x22
<c0173a1b> sysfs_write_file+0x92/0xb9 <c0173989> sysfs_write_file+0x0/0xb9
<c01491ca> vfs_write+0x83/0x122 <c01499df> sys_write+0x3c/0x63
<c0102973> sysenter_past_esp+0x54/0x75
ehci_hcd 0000:01:07.2: reset command 080002 (park)=0 ithresh=8 period=1024 Reset HALT
ehci_hcd 0000:01:07.2: init command 010009 (park)=0 ithresh=1 period=256 RUN
ehci_hcd 0000:01:07.2: USB 2.0 started, EHCI 0.95, driver 10 Dec 2004
ehci_hcd 0000:01:07.2: ...powerup ports...
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <cf86309c> ehci_run+0x165/0x16f [ehci_hcd]
<c028c6bf> schedule_timeout+0x7a/0x95 <c011c755> process_timeout+0x0/0x5
<c011d16a> msleep+0x17/0x1c <cf865895> ehci_pci_resume+0x103/0x10a [ehci_hcd]
<cf848a7a> usb_hcd_pci_resume+0x17a/0x1b7 [usbcore] <c01b6dee> pci_device_resume+0x16/0x43
<c02025d9> resume_device+0x7d/0x96 <c02026a7> dpm_resume+0x58/0x80
<c02026dc> device_resume+0xd/0x16 <c012db1f> pm_suspend_disk+0xbf/0xc8
<c012cb95> enter_state+0x50/0x16f <c012cd37> state_store+0x83/0x8f
<c012ccb4> state_store+0x0/0x8f <c0173492> subsys_attr_store+0x1e/0x22
<c0173a1b> sysfs_write_file+0x92/0xb9 <c0173989> sysfs_write_file+0x0/0xb9
<c01491ca> vfs_write+0x83/0x122 <c01499df> sys_write+0x3c/0x63
<c0102973> sysenter_past_esp+0x54/0x75
nvidiafb: your nForce DIMMs are not arranged in optimal banks!
i2c_adapter i2c-0: PM: resume from 0, parent 0000:02:00.0 still 1
i2c_adapter i2c-1: PM: resume from 0, parent 0000:02:00.0 still 1
i2c_adapter i2c-2: PM: resume from 0, parent 0000:02:00.0 still 1
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c01af304> vsnprintf+0x45a/0x497
<c028c6bf> schedule_timeout+0x7a/0x95 <c011c755> process_timeout+0x0/0x5
<c01fe3cb> ps2_sendbyte+0xa1/0xdd <c0124c68> autoremove_wake_function+0x0/0x2d
<c01fe5bb> ps2_command+0xdd/0x2ce <c02271bc> atkbd_probe+0x4c/0xe0
<c022842f> atkbd_reconnect+0x97/0xfc <c01fc876> serio_reconnect_driver+0x21/0x34
<c01fc8ba> serio_resume+0xb/0x1a <c02025d9> resume_device+0x7d/0x96
<c02026a7> dpm_resume+0x58/0x80 <c02026dc> device_resume+0xd/0x16
<c012db1f> pm_suspend_disk+0xbf/0xc8 <c012cb95> enter_state+0x50/0x16f
<c012cd37> state_store+0x83/0x8f <c012ccb4> state_store+0x0/0x8f
<c0173492> subsys_attr_store+0x1e/0x22 <c0173a1b> sysfs_write_file+0x92/0xb9
<c0173989> sysfs_write_file+0x0/0xb9 <c01491ca> vfs_write+0x83/0x122
<c01499df> sys_write+0x3c/0x63 <c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6c6> schedule_timeout+0x81/0x95
<c028c6bf> schedule_timeout+0x7a/0x95 <c011c755> process_timeout+0x0/0x5
<c01fe64f> ps2_command+0x171/0x2ce <c0124c68> autoremove_wake_function+0x0/0x2d
<c02271bc> atkbd_probe+0x4c/0xe0 <c022842f> atkbd_reconnect+0x97/0xfc
<c01fc876> serio_reconnect_driver+0x21/0x34 <c01fc8ba> serio_resume+0xb/0x1a
<c02025d9> resume_device+0x7d/0x96 <c02026a7> dpm_resume+0x58/0x80
<c02026dc> device_resume+0xd/0x16 <c012db1f> pm_suspend_disk+0xbf/0xc8
<c012cb95> enter_state+0x50/0x16f <c012cd37> state_store+0x83/0x8f
<c012ccb4> state_store+0x0/0x8f <c0173492> subsys_attr_store+0x1e/0x22
<c0173a1b> sysfs_write_file+0x92/0xb9 <c0173989> sysfs_write_file+0x0/0xb9
<c01491ca> vfs_write+0x83/0x122 <c01499df> sys_write+0x3c/0x63
<c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <c01fe731> ps2_command+0x253/0x2ce
<c0124c68> autoremove_wake_function+0x0/0x2d <c02271bc> atkbd_probe+0x4c/0xe0
<c022842f> atkbd_reconnect+0x97/0xfc <c01fc876> serio_reconnect_driver+0x21/0x34
<c01fc8ba> serio_resume+0xb/0x1a <c02025d9> resume_device+0x7d/0x96
<c02026a7> dpm_resume+0x58/0x80 <c02026dc> device_resume+0xd/0x16
<c012db1f> pm_suspend_disk+0xbf/0xc8 <c012cb95> enter_state+0x50/0x16f
<c012cd37> state_store+0x83/0x8f <c012ccb4> state_store+0x0/0x8f
<c0173492> subsys_attr_store+0x1e/0x22 <c0173a1b> sysfs_write_file+0x92/0xb9
<c0173989> sysfs_write_file+0x0/0xb9 <c01491ca> vfs_write+0x83/0x122
<c01499df> sys_write+0x3c/0x63 <c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <c01fe3cb> ps2_sendbyte+0xa1/0xdd
<c0124c68> autoremove_wake_function+0x0/0x2d <c01fe5bb> ps2_command+0xdd/0x2ce
<c0124c68> autoremove_wake_function+0x0/0x2d <c022736e> atkbd_activate+0x1a/0x69
<c0228455> atkbd_reconnect+0xbd/0xfc <c01fc876> serio_reconnect_driver+0x21/0x34
<c01fc8ba> serio_resume+0xb/0x1a <c02025d9> resume_device+0x7d/0x96
<c02026a7> dpm_resume+0x58/0x80 <c02026dc> device_resume+0xd/0x16
<c012db1f> pm_suspend_disk+0xbf/0xc8 <c012cb95> enter_state+0x50/0x16f
<c012cd37> state_store+0x83/0x8f <c012ccb4> state_store+0x0/0x8f
<c0173492> subsys_attr_store+0x1e/0x22 <c0173a1b> sysfs_write_file+0x92/0xb9
<c0173989> sysfs_write_file+0x0/0xb9 <c01491ca> vfs_write+0x83/0x122
<c01499df> sys_write+0x3c/0x63 <c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <c01fe3cb> ps2_sendbyte+0xa1/0xdd
<c0124c68> autoremove_wake_function+0x0/0x2d <c01fe5d8> ps2_command+0xfa/0x2ce
<c0124c68> autoremove_wake_function+0x0/0x2d <c022736e> atkbd_activate+0x1a/0x69
<c0228455> atkbd_reconnect+0xbd/0xfc <c01fc876> serio_reconnect_driver+0x21/0x34
<c01fc8ba> serio_resume+0xb/0x1a <c02025d9> resume_device+0x7d/0x96
<c02026a7> dpm_resume+0x58/0x80 <c02026dc> device_resume+0xd/0x16
<c012db1f> pm_suspend_disk+0xbf/0xc8 <c012cb95> enter_state+0x50/0x16f
<c012cd37> state_store+0x83/0x8f <c012ccb4> state_store+0x0/0x8f
<c0173492> subsys_attr_store+0x1e/0x22 <c0173a1b> sysfs_write_file+0x92/0xb9
<c0173989> sysfs_write_file+0x0/0xb9 <c01491ca> vfs_write+0x83/0x122
<c01499df> sys_write+0x3c/0x63 <c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <c01fe3cb> ps2_sendbyte+0xa1/0xdd
<c0124c68> autoremove_wake_function+0x0/0x2d <c01fe5bb> ps2_command+0xdd/0x2ce
<c0124c68> autoremove_wake_function+0x0/0x2d <c0227385> atkbd_activate+0x31/0x69
<c0228455> atkbd_reconnect+0xbd/0xfc <c01fc876> serio_reconnect_driver+0x21/0x34
<c01fc8ba> serio_resume+0xb/0x1a <c02025d9> resume_device+0x7d/0x96
<c02026a7> dpm_resume+0x58/0x80 <c02026dc> device_resume+0xd/0x16
<c012db1f> pm_suspend_disk+0xbf/0xc8 <c012cb95> enter_state+0x50/0x16f
<c012cd37> state_store+0x83/0x8f <c012ccb4> state_store+0x0/0x8f
<c0173492> subsys_attr_store+0x1e/0x22 <c0173a1b> sysfs_write_file+0x92/0xb9
<c0173989> sysfs_write_file+0x0/0xb9 <c01491ca> vfs_write+0x83/0x122
<c01499df> sys_write+0x3c/0x63 <c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <c01fe3cb> ps2_sendbyte+0xa1/0xdd
<c0124c68> autoremove_wake_function+0x0/0x2d <c01fe5d8> ps2_command+0xfa/0x2ce
<c0124c68> autoremove_wake_function+0x0/0x2d <c0227385> atkbd_activate+0x31/0x69
<c0228455> atkbd_reconnect+0xbd/0xfc <c01fc876> serio_reconnect_driver+0x21/0x34
<c01fc8ba> serio_resume+0xb/0x1a <c02025d9> resume_device+0x7d/0x96
<c02026a7> dpm_resume+0x58/0x80 <c02026dc> device_resume+0xd/0x16
<c012db1f> pm_suspend_disk+0xbf/0xc8 <c012cb95> enter_state+0x50/0x16f
<c012cd37> state_store+0x83/0x8f <c012ccb4> state_store+0x0/0x8f
<c0173492> subsys_attr_store+0x1e/0x22 <c0173a1b> sysfs_write_file+0x92/0xb9
<c0173989> sysfs_write_file+0x0/0xb9 <c01491ca> vfs_write+0x83/0x122
<c01499df> sys_write+0x3c/0x63 <c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <c01fe3cb> ps2_sendbyte+0xa1/0xdd
<c0124c68> autoremove_wake_function+0x0/0x2d <c01fe5bb> ps2_command+0xdd/0x2ce
<c0124c68> autoremove_wake_function+0x0/0x2d <c0227397> atkbd_activate+0x43/0x69
<c0228455> atkbd_reconnect+0xbd/0xfc <c01fc876> serio_reconnect_driver+0x21/0x34
<c01fc8ba> serio_resume+0xb/0x1a <c02025d9> resume_device+0x7d/0x96
<c02026a7> dpm_resume+0x58/0x80 <c02026dc> device_resume+0xd/0x16
<c012db1f> pm_suspend_disk+0xbf/0xc8 <c012cb95> enter_state+0x50/0x16f
<c012cd37> state_store+0x83/0x8f <c012ccb4> state_store+0x0/0x8f
<c0173492> subsys_attr_store+0x1e/0x22 <c0173a1b> sysfs_write_file+0x92/0xb9
<c0173989> sysfs_write_file+0x0/0xb9 <c01491ca> vfs_write+0x83/0x122
<c01499df> sys_write+0x3c/0x63 <c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <c01fe3cb> ps2_sendbyte+0xa1/0xdd
<c0124c68> autoremove_wake_function+0x0/0x2d <c01fe5bb> ps2_command+0xdd/0x2ce
<c0228465> atkbd_reconnect+0xcd/0xfc <c01fc876> serio_reconnect_driver+0x21/0x34
<c01fc8ba> serio_resume+0xb/0x1a <c02025d9> resume_device+0x7d/0x96
<c02026a7> dpm_resume+0x58/0x80 <c02026dc> device_resume+0xd/0x16
<c012db1f> pm_suspend_disk+0xbf/0xc8 <c012cb95> enter_state+0x50/0x16f
<c012cd37> state_store+0x83/0x8f <c012ccb4> state_store+0x0/0x8f
<c0173492> subsys_attr_store+0x1e/0x22 <c0173a1b> sysfs_write_file+0x92/0xb9
<c0173989> sysfs_write_file+0x0/0xb9 <c01491ca> vfs_write+0x83/0x122
<c01499df> sys_write+0x3c/0x63 <c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <c01fe3cb> ps2_sendbyte+0xa1/0xdd
<c0124c68> autoremove_wake_function+0x0/0x2d <c01fe5d8> ps2_command+0xfa/0x2ce
<c0228465> atkbd_reconnect+0xcd/0xfc <c01fc876> serio_reconnect_driver+0x21/0x34
<c01fc8ba> serio_resume+0xb/0x1a <c02025d9> resume_device+0x7d/0x96
<c02026a7> dpm_resume+0x58/0x80 <c02026dc> device_resume+0xd/0x16
<c012db1f> pm_suspend_disk+0xbf/0xc8 <c012cb95> enter_state+0x50/0x16f
<c012cd37> state_store+0x83/0x8f <c012ccb4> state_store+0x0/0x8f
<c0173492> subsys_attr_store+0x1e/0x22 <c0173a1b> sysfs_write_file+0x92/0xb9
<c0173989> sysfs_write_file+0x0/0xb9 <c01491ca> vfs_write+0x83/0x122
<c01499df> sys_write+0x3c/0x63 <c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c0213851> ide_do_request+0x515/0x730
<c010339a> common_interrupt+0x1a/0x20 <c028c59f> wait_for_completion+0x70/0xc2
<c0112f98> default_wake_function+0x0/0xc <c0213b37> ide_do_drive_cmd+0xcb/0xf0
<c0211301> generic_ide_resume+0x7d/0x88 <c01a84c8> blk_end_sync_rq+0x0/0x1d
<c02177f3> task_no_data_intr+0x0/0x63 <c02025d9> resume_device+0x7d/0x96
<c02026a7> dpm_resume+0x58/0x80 <c02026dc> device_resume+0xd/0x16
<c012db1f> pm_suspend_disk+0xbf/0xc8 <c012cb95> enter_state+0x50/0x16f
<c012cd37> state_store+0x83/0x8f <c012ccb4> state_store+0x0/0x8f
<c0173492> subsys_attr_store+0x1e/0x22 <c0173a1b> sysfs_write_file+0x92/0xb9
<c0173989> sysfs_write_file+0x0/0xb9 <c01491ca> vfs_write+0x83/0x122
<c01499df> sys_write+0x3c/0x63 <c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c59f> wait_for_completion+0x70/0xc2
<c0112f98> default_wake_function+0x0/0xc <c0213b37> ide_do_drive_cmd+0xcb/0xf0
<c0211301> generic_ide_resume+0x7d/0x88 <c01a84c8> blk_end_sync_rq+0x0/0x1d
<c02025d9> resume_device+0x7d/0x96 <c02026a7> dpm_resume+0x58/0x80
<c02026dc> device_resume+0xd/0x16 <c012db1f> pm_suspend_disk+0xbf/0xc8
<c012cb95> enter_state+0x50/0x16f <c012cd37> state_store+0x83/0x8f
<c012ccb4> state_store+0x0/0x8f <c0173492> subsys_attr_store+0x1e/0x22
<c0173a1b> sysfs_write_file+0x92/0xb9 <c0173989> sysfs_write_file+0x0/0xb9
<c01491ca> vfs_write+0x83/0x122 <c01499df> sys_write+0x3c/0x63
<c0102973> sysenter_past_esp+0x54/0x75
BUG: warning at drivers/ide/ide-iops.c:1235/ide_wait_not_busy()
<c0214b0a> ide_wait_not_busy+0x48/0x92 <c02136d9> ide_do_request+0x39d/0x730
<c01a83bc> freed_request+0x1d/0x37 <c0213cf8> ide_intr+0x19c/0x1d4
<c0219548> ide_dma_intr+0x0/0x8f <c01302f8> handle_IRQ_event+0x21/0x4a
<c0130397> __do_IRQ+0x76/0xcf <c0104abe> do_IRQ+0x5e/0x79
=======================
<c010339a> common_interrupt+0x1a/0x20 <c01019bc> default_idle+0x2b/0x53
<c0101a24> cpu_idle+0x40/0x5e <c0322602> start_kernel+0x299/0x29b
usb usb1: finish resume
ohci_hcd 0000:00:02.0: lost power
usb usb1: root hub lost power or was reset
ohci_hcd 0000:00:02.0: resetting from state 'reset', control = 0x600
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c011d0d9> __mod_timer+0x9f/0xa9
<c028c6bf> schedule_timeout+0x7a/0x95 <c011c755> process_timeout+0x0/0x5
<c011d16a> msleep+0x17/0x1c <cf828643> ohci_run+0x19e/0x46d [ohci_hcd]
<cf8291ba> ohci_bus_resume+0x35e/0x5e4 [ohci_hcd] <cf840c5e> hcd_bus_resume+0x2d/0x7a [usbcore]
<cf83d974> hub_resume+0x38/0x17f [usbcore] <cf83c4f7> usb_generic_resume+0x0/0xcf [usbcore]
<cf83c56a> usb_generic_resume+0x73/0xcf [usbcore] <cf83d610> finish_device_resume+0x119/0x16a [usbcore]
<cf83e46a> usb_resume_device+0x46/0xa1 [usbcore] <c02025d9> resume_device+0x7d/0x96
<c02026a7> dpm_resume+0x58/0x80 <c02026dc> device_resume+0xd/0x16
<c012db1f> pm_suspend_disk+0xbf/0xc8 <c012cb95> enter_state+0x50/0x16f
<c012cd37> state_store+0x83/0x8f <c012ccb4> state_store+0x0/0x8f
<c0173492> subsys_attr_store+0x1e/0x22 <c0173a1b> sysfs_write_file+0x92/0xb9
<c0173989> sysfs_write_file+0x0/0xb9 <c01491ca> vfs_write+0x83/0x122
<c01499df> sys_write+0x3c/0x63 <c0102973> sysenter_past_esp+0x54/0x75
ohci_hcd 0000:00:02.0: OHCI controller state
ohci_hcd 0000:00:02.0: OHCI 1.0, NO legacy support registers
ohci_hcd 0000:00:02.0: control 0x683 RWE RWC HCFS=operational CBSR=3
ohci_hcd 0000:00:02.0: cmdstatus 0x00000 SOC=0
ohci_hcd 0000:00:02.0: intrstatus 0x00000004 SF
ohci_hcd 0000:00:02.0: intrenable 0x8000000a MIE RD WDH
ohci_hcd 0000:00:02.0: hcca frame #0003
ohci_hcd 0000:00:02.0: roothub.a 01000203 POTPGT=1 NPS NDP=3(3)
ohci_hcd 0000:00:02.0: roothub.b 00000000 PPCM=0000 DR=0000
ohci_hcd 0000:00:02.0: roothub.status 00008000 DRWE
ohci_hcd 0000:00:02.0: roothub.portstatus [0] 0x00000100 PPS
ohci_hcd 0000:00:02.0: roothub.portstatus [1] 0x00000100 PPS
ohci_hcd 0000:00:02.0: roothub.portstatus [2] 0x00000100 PPS
ohci_hcd 0000:00:02.0: restart complete
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <c011d16a> msleep+0x17/0x1c
<cf83d9b0> hub_resume+0x74/0x17f [usbcore] <cf83c4f7> usb_generic_resume+0x0/0xcf [usbcore]
<cf83c56a> usb_generic_resume+0x73/0xcf [usbcore] <cf83d610> finish_device_resume+0x119/0x16a [usbcore]
<cf83e46a> usb_resume_device+0x46/0xa1 [usbcore] <c02025d9> resume_device+0x7d/0x96
<c02026a7> dpm_resume+0x58/0x80 <c02026dc> device_resume+0xd/0x16
<c012db1f> pm_suspend_disk+0xbf/0xc8 <c012cb95> enter_state+0x50/0x16f
<c012cd37> state_store+0x83/0x8f <c012ccb4> state_store+0x0/0x8f
<c0173492> subsys_attr_store+0x1e/0x22 <c0173a1b> sysfs_write_file+0x92/0xb9
<c0173989> sysfs_write_file+0x0/0xb9 <c01491ca> vfs_write+0x83/0x122
<c01499df> sys_write+0x3c/0x63 <c0102973> sysenter_past_esp+0x54/0x75
ohci_hcd 0000:00:02.0: GetStatus roothub.portstatus [0] = 0x00010100 CSC PPS
usb usb2: finish resume
ohci_hcd 0000:00:03.0: lost power
usb usb2: root hub lost power or was reset
ohci_hcd 0000:00:03.0: resetting from state 'reset', control = 0x600
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <cf842dc0> usb_start_wait_urb+0x141/0x14b [usbcore]
<c028c6bf> schedule_timeout+0x7a/0x95 <c011c755> process_timeout+0x0/0x5
<c011d16a> msleep+0x17/0x1c <cf828643> ohci_run+0x19e/0x46d [ohci_hcd]
<cf8291ba> ohci_bus_resume+0x35e/0x5e4 [ohci_hcd] <cf840c5e> hcd_bus_resume+0x2d/0x7a [usbcore]
<cf83d974> hub_resume+0x38/0x17f [usbcore] <cf83c4f7> usb_generic_resume+0x0/0xcf [usbcore]
<cf83c56a> usb_generic_resume+0x73/0xcf [usbcore] <cf83d610> finish_device_resume+0x119/0x16a [usbcore]
<cf83e46a> usb_resume_device+0x46/0xa1 [usbcore] <c02025d9> resume_device+0x7d/0x96
<c02026a7> dpm_resume+0x58/0x80 <c02026dc> device_resume+0xd/0x16
<c012db1f> pm_suspend_disk+0xbf/0xc8 <c012cb95> enter_state+0x50/0x16f
<c012cd37> state_store+0x83/0x8f <c012ccb4> state_store+0x0/0x8f
<c0173492> subsys_attr_store+0x1e/0x22 <c0173a1b> sysfs_write_file+0x92/0xb9
<c0173989> sysfs_write_file+0x0/0xb9 <c01491ca> vfs_write+0x83/0x122
<c01499df> sys_write+0x3c/0x63 <c0102973> sysenter_past_esp+0x54/0x75
ohci_hcd 0000:00:03.0: OHCI controller state
ohci_hcd 0000:00:03.0: OHCI 1.0, NO legacy support registers
ohci_hcd 0000:00:03.0: control 0x683 RWE RWC HCFS=operational CBSR=3
ohci_hcd 0000:00:03.0: cmdstatus 0x00000 SOC=0
ohci_hcd 0000:00:03.0: intrstatus 0x00000004 SF
ohci_hcd 0000:00:03.0: intrenable 0x8000000a MIE RD WDH
ohci_hcd 0000:00:03.0: hcca frame #0003
ohci_hcd 0000:00:03.0: roothub.a 01000203 POTPGT=1 NPS NDP=3(3)
ohci_hcd 0000:00:03.0: roothub.b 00000000 PPCM=0000 DR=0000
ohci_hcd 0000:00:03.0: roothub.status 00008000 DRWE
ohci_hcd 0000:00:03.0: roothub.portstatus [0] 0x00000100 PPS
ohci_hcd 0000:00:03.0: roothub.portstatus [1] 0x00000100 PPS
ohci_hcd 0000:00:03.0: roothub.portstatus [2] 0x00000100 PPS
ohci_hcd 0000:00:03.0: restart complete
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <c011d16a> msleep+0x17/0x1c
<cf83d9b0> hub_resume+0x74/0x17f [usbcore] <cf83c4f7> usb_generic_resume+0x0/0xcf [usbcore]
<cf83c56a> usb_generic_resume+0x73/0xcf [usbcore] <cf83d610> finish_device_resume+0x119/0x16a [usbcore]
<cf83e46a> usb_resume_device+0x46/0xa1 [usbcore] <c02025d9> resume_device+0x7d/0x96
<c02026a7> dpm_resume+0x58/0x80 <c02026dc> device_resume+0xd/0x16
<c012db1f> pm_suspend_disk+0xbf/0xc8 <c012cb95> enter_state+0x50/0x16f
<c012cd37> state_store+0x83/0x8f <c012ccb4> state_store+0x0/0x8f
<c0173492> subsys_attr_store+0x1e/0x22 <c0173a1b> sysfs_write_file+0x92/0xb9
<c0173989> sysfs_write_file+0x0/0xb9 <c01491ca> vfs_write+0x83/0x122
<c01499df> sys_write+0x3c/0x63 <c0102973> sysenter_past_esp+0x54/0x75
ohci_hcd 0000:00:03.0: GetStatus roothub.portstatus [0] = 0x00010100 CSC PPS
usb usb3: finish resume
ohci_hcd 0000:01:07.0: lost power
usb usb3: root hub lost power or was reset
ohci_hcd 0000:01:07.0: resetting from state 'reset', control = 0x0
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <cf842dc0> usb_start_wait_urb+0x141/0x14b [usbcore]
<c028c6bf> schedule_timeout+0x7a/0x95 <c011c755> process_timeout+0x0/0x5
<c011d16a> msleep+0x17/0x1c <cf828643> ohci_run+0x19e/0x46d [ohci_hcd]
<cf8291ba> ohci_bus_resume+0x35e/0x5e4 [ohci_hcd] <cf840c5e> hcd_bus_resume+0x2d/0x7a [usbcore]
<cf83d974> hub_resume+0x38/0x17f [usbcore] <cf83c4f7> usb_generic_resume+0x0/0xcf [usbcore]
<cf83c56a> usb_generic_resume+0x73/0xcf [usbcore] <cf83d610> finish_device_resume+0x119/0x16a [usbcore]
<cf83e46a> usb_resume_device+0x46/0xa1 [usbcore] <c02025d9> resume_device+0x7d/0x96
<c02026a7> dpm_resume+0x58/0x80 <c02026dc> device_resume+0xd/0x16
<c012db1f> pm_suspend_disk+0xbf/0xc8 <c012cb95> enter_state+0x50/0x16f
<c012cd37> state_store+0x83/0x8f <c012ccb4> state_store+0x0/0x8f
<c0173492> subsys_attr_store+0x1e/0x22 <c0173a1b> sysfs_write_file+0x92/0xb9
<c0173989> sysfs_write_file+0x0/0xb9 <c01491ca> vfs_write+0x83/0x122
<c01499df> sys_write+0x3c/0x63 <c0102973> sysenter_past_esp+0x54/0x75
ohci_hcd 0000:01:07.0: OHCI controller state
ohci_hcd 0000:01:07.0: OHCI 1.0, NO legacy support registers
ohci_hcd 0000:01:07.0: control 0x083 HCFS=operational CBSR=3
ohci_hcd 0000:01:07.0: cmdstatus 0x00000 SOC=0
ohci_hcd 0000:01:07.0: intrstatus 0x00000004 SF
ohci_hcd 0000:01:07.0: intrenable 0x8000001a MIE UE RD WDH
ohci_hcd 0000:01:07.0: hcca frame #01fe
ohci_hcd 0000:01:07.0: roothub.a ff000203 POTPGT=255 NPS NDP=3(3)
ohci_hcd 0000:01:07.0: roothub.b 00000000 PPCM=0000 DR=0000
ohci_hcd 0000:01:07.0: roothub.status 00008000 DRWE
ohci_hcd 0000:01:07.0: roothub.portstatus [0] 0x00000100 PPS
ohci_hcd 0000:01:07.0: roothub.portstatus [1] 0x00000100 PPS
ohci_hcd 0000:01:07.0: roothub.portstatus [2] 0x00000100 PPS
ohci_hcd 0000:01:07.0: restart complete
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c011d0d9> __mod_timer+0x9f/0xa9
<c028c6bf> schedule_timeout+0x7a/0x95 <c011c755> process_timeout+0x0/0x5
<c011d16a> msleep+0x17/0x1c <cf83d9b0> hub_resume+0x74/0x17f [usbcore]
<cf83c4f7> usb_generic_resume+0x0/0xcf [usbcore] <cf83c56a> usb_generic_resume+0x73/0xcf [usbcore]
<cf83d610> finish_device_resume+0x119/0x16a [usbcore] <cf83e46a> usb_resume_device+0x46/0xa1 [usbcore]
<c02025d9> resume_device+0x7d/0x96 <c02026a7> dpm_resume+0x58/0x80
<c02026dc> device_resume+0xd/0x16 <c012db1f> pm_suspend_disk+0xbf/0xc8
<c012cb95> enter_state+0x50/0x16f <c012cd37> state_store+0x83/0x8f
<c012ccb4> state_store+0x0/0x8f <c0173492> subsys_attr_store+0x1e/0x22
<c0173a1b> sysfs_write_file+0x92/0xb9 <c0173989> sysfs_write_file+0x0/0xb9
<c01491ca> vfs_write+0x83/0x122 <c01499df> sys_write+0x3c/0x63
<c0102973> sysenter_past_esp+0x54/0x75
ohci_hcd 0000:01:07.0: GetStatus roothub.portstatus [0] = 0x00010100 CSC PPS
usb 3-2: finish resume
usb 3-2: gone after usb resume? status -19
hub 3-0:1.0: resume port 2 --> -19
hub 3-0:1.0: logical disconnect on port 2
usb usb4: finish resume
ohci_hcd 0000:01:07.1: lost power
usb usb4: root hub lost power or was reset
ohci_hcd 0000:01:07.1: resetting from state 'reset', control = 0x0
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <cf842dc0> usb_start_wait_urb+0x141/0x14b [usbcore]
<c028c6bf> schedule_timeout+0x7a/0x95 <c011c755> process_timeout+0x0/0x5
<c011d16a> msleep+0x17/0x1c <cf828643> ohci_run+0x19e/0x46d [ohci_hcd]
<cf8291ba> ohci_bus_resume+0x35e/0x5e4 [ohci_hcd] <cf840c5e> hcd_bus_resume+0x2d/0x7a [usbcore]
<cf83d974> hub_resume+0x38/0x17f [usbcore] <cf83c4f7> usb_generic_resume+0x0/0xcf [usbcore]
<cf83c56a> usb_generic_resume+0x73/0xcf [usbcore] <cf83d610> finish_device_resume+0x119/0x16a [usbcore]
<cf83e46a> usb_resume_device+0x46/0xa1 [usbcore] <c02025d9> resume_device+0x7d/0x96
<c02026a7> dpm_resume+0x58/0x80 <c02026dc> device_resume+0xd/0x16
<c012db1f> pm_suspend_disk+0xbf/0xc8 <c012cb95> enter_state+0x50/0x16f
<c012cd37> state_store+0x83/0x8f <c012ccb4> state_store+0x0/0x8f
<c0173492> subsys_attr_store+0x1e/0x22 <c0173a1b> sysfs_write_file+0x92/0xb9
<c0173989> sysfs_write_file+0x0/0xb9 <c01491ca> vfs_write+0x83/0x122
<c01499df> sys_write+0x3c/0x63 <c0102973> sysenter_past_esp+0x54/0x75
ohci_hcd 0000:01:07.1: OHCI controller state
ohci_hcd 0000:01:07.1: OHCI 1.0, NO legacy support registers
ohci_hcd 0000:01:07.1: control 0x083 HCFS=operational CBSR=3
ohci_hcd 0000:01:07.1: cmdstatus 0x00000 SOC=0
ohci_hcd 0000:01:07.1: intrstatus 0x00000004 SF
ohci_hcd 0000:01:07.1: intrenable 0x8000001a MIE UE RD WDH
ohci_hcd 0000:01:07.1: hcca frame #01fe
ohci_hcd 0000:01:07.1: roothub.a ff000202 POTPGT=255 NPS NDP=2(2)
ohci_hcd 0000:01:07.1: roothub.b 00000000 PPCM=0000 DR=0000
ohci_hcd 0000:01:07.1: roothub.status 00008000 DRWE
ohci_hcd 0000:01:07.1: roothub.portstatus [0] 0x00000100 PPS
ohci_hcd 0000:01:07.1: roothub.portstatus [1] 0x00000100 PPS
ohci_hcd 0000:01:07.1: restart complete
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c011d0d9> __mod_timer+0x9f/0xa9
<c028c6bf> schedule_timeout+0x7a/0x95 <c011c755> process_timeout+0x0/0x5
<c011d16a> msleep+0x17/0x1c <cf83d9b0> hub_resume+0x74/0x17f [usbcore]
<cf83c4f7> usb_generic_resume+0x0/0xcf [usbcore] <cf83c56a> usb_generic_resume+0x73/0xcf [usbcore]
<cf83d610> finish_device_resume+0x119/0x16a [usbcore] <cf83e46a> usb_resume_device+0x46/0xa1 [usbcore]
<c02025d9> resume_device+0x7d/0x96 <c02026a7> dpm_resume+0x58/0x80
<c02026dc> device_resume+0xd/0x16 <c012db1f> pm_suspend_disk+0xbf/0xc8
<c012cb95> enter_state+0x50/0x16f <c012cd37> state_store+0x83/0x8f
<c012ccb4> state_store+0x0/0x8f <c0173492> subsys_attr_store+0x1e/0x22
<c0173a1b> sysfs_write_file+0x92/0xb9 <c0173989> sysfs_write_file+0x0/0xb9
<c01491ca> vfs_write+0x83/0x122 <c01499df> sys_write+0x3c/0x63
<c0102973> sysenter_past_esp+0x54/0x75
ohci_hcd 0000:01:07.1: GetStatus roothub.portstatus [0] = 0x00010100 CSC PPS
usb usb5: finish resume
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
<c011c755> process_timeout+0x0/0x5 <c011d16a> msleep+0x17/0x1c
<cf83d9b0> hub_resume+0x74/0x17f [usbcore] <cf83c4f7> usb_generic_resume+0x0/0xcf [usbcore]
<cf83c56a> usb_generic_resume+0x73/0xcf [usbcore] <cf83d610> finish_device_resume+0x119/0x16a [usbcore]
<cf83e46a> usb_resume_device+0x46/0xa1 [usbcore] <c02025d9> resume_device+0x7d/0x96
<c02026a7> dpm_resume+0x58/0x80 <c02026dc> device_resume+0xd/0x16
<c012db1f> pm_suspend_disk+0xbf/0xc8 <c012cb95> enter_state+0x50/0x16f
<c012cd37> state_store+0x83/0x8f <c012ccb4> state_store+0x0/0x8f
<c0173492> subsys_attr_store+0x1e/0x22 <c0173a1b> sysfs_write_file+0x92/0xb9
<c0173989> sysfs_write_file+0x0/0xb9 <c01491ca> vfs_write+0x83/0x122
<c01499df> sys_write+0x3c/0x63 <c0102973> sysenter_past_esp+0x54/0x75
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001002 POWER sig=se0 CSC
ehci_hcd 0000:01:07.2: GetStatus port 3 status 001403 POWER sig=k CSC CONNECT
Restarting tasks...<3>BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c0112f8f> try_to_wake_up+0xe1/0xea
<c012cea3> thaw_processes+0x97/0xc4 <c012d90e> unprepare_processes+0x25/0x2a
<c012db24> pm_suspend_disk+0xc4/0xc8 <c012cb95> enter_state+0x50/0x16f
<c012cd37> state_store+0x83/0x8f <c012ccb4> state_store+0x0/0x8f
<c0173492> subsys_attr_store+0x1e/0x22 <c0173a1b> sysfs_write_file+0x92/0xb9
<c0173989> sysfs_write_file+0x0/0xb9 <c01491ca> vfs_write+0x83/0x122
<c01499df> sys_write+0x3c/0x63 <c0102973> sysenter_past_esp+0x54/0x75
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0002
ohci_hcd 0000:00:02.0: GetStatus roothub.portstatus [0] = 0x00010100 CSC PPS
hub 1-0:1.0: port 1, status 0100, change 0001, 12 Mb/s
done
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c014922a> vfs_write+0xe3/0x122
<c01499df> sys_write+0x3c/0x63 <c0102a3a> work_resched+0x5/0x16
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c028be58> io_schedule+0xe/0x16
<c014a963> sync_buffer+0x2b/0x2e <c028c733> __wait_on_bit+0x31/0x56
<c014a938> sync_buffer+0x0/0x2e <c014a938> sync_buffer+0x0/0x2e
<c028c7b9> out_of_line_wait_on_bit+0x61/0x69 <c0124d17> wake_bit_function+0x0/0x3c
<c014a1b3> __wait_on_buffer+0x1c/0x1f <c017b03e> ext3_bread+0x47/0x61
<c017c4a2> dx_probe+0x3a/0x2af <c017d4e4> ext3_find_entry+0xc2/0x4ed
<c01af373> snprintf+0x1b/0x1f <c017dfaa> ext3_lookup+0x1f/0x75
<c0153848> __lookup_hash+0xaa/0xc3 <c0155916> open_namei+0xc9/0x4e5
<c0148839> do_filp_open+0x1c/0x31 <c01af373> snprintf+0x1b/0x1f
<c014885d> filp_open+0xf/0x11 <c0151295> do_coredump+0x4e9/0x59e
<c011e84a> __dequeue_signal+0x149/0x154 <c011f777> get_signal_to_deliver+0x3eb/0x418
<c0111230> do_page_fault+0x0/0x4c3 <c0102372> do_notify_resume+0x6f/0x5a1
<c0103463> error_code+0x4f/0x54 <c028dd4a> iret_exc+0x136/0x779
<c01116a3> do_page_fault+0x473/0x4c3 <c0111230> do_page_fault+0x0/0x4c3
<c0102a5e> work_notifysig+0x13/0x19
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c01a7957> generic_make_request+0x191/0x1c2
<c028be58> io_schedule+0xe/0x16 <c014a963> sync_buffer+0x2b/0x2e
<c028c733> __wait_on_bit+0x31/0x56 <c014a938> sync_buffer+0x0/0x2e
<c014a938> sync_buffer+0x0/0x2e <c028c7b9> out_of_line_wait_on_bit+0x61/0x69
<c0124d17> wake_bit_function+0x0/0x3c <c014a1b3> __wait_on_buffer+0x1c/0x1f
<c017b03e> ext3_bread+0x47/0x61 <c017d571> ext3_find_entry+0x14f/0x4ed
<c017dfaa> ext3_lookup+0x1f/0x75 <c0153848> __lookup_hash+0xaa/0xc3
<c0155916> open_namei+0xc9/0x4e5 <c0148839> do_filp_open+0x1c/0x31
<c01af373> snprintf+0x1b/0x1f <c014885d> filp_open+0xf/0x11
<c0151295> do_coredump+0x4e9/0x59e <c011e84a> __dequeue_signal+0x149/0x154
<c011f777> get_signal_to_deliver+0x3eb/0x418 <c0111230> do_page_fault+0x0/0x4c3
<c0102372> do_notify_resume+0x6f/0x5a1 <c0103463> error_code+0x4f/0x54
<c028dd4a> iret_exc+0x136/0x779 <c01116a3> do_page_fault+0x473/0x4c3
<c0111230> do_page_fault+0x0/0x4c3 <c0102a5e> work_notifysig+0x13/0x19
hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x100
hub 2-0:1.0: state 7 ports 3 chg 0000 evt 0002
ohci_hcd 0000:00:03.0: GetStatus roothub.portstatus [0] = 0x00010100 CSC PPS
hub 2-0:1.0: port 1, status 0100, change 0001, 12 Mb/s
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c01354ed> get_page_from_freelist+0x7d/0x2fb
<c01a7957> generic_make_request+0x191/0x1c2 <c028be58> io_schedule+0xe/0x16
<c014a963> sync_buffer+0x2b/0x2e <c028c733> __wait_on_bit+0x31/0x56
<c014a938> sync_buffer+0x0/0x2e <c014a938> sync_buffer+0x0/0x2e
<c028c7b9> out_of_line_wait_on_bit+0x61/0x69 <c0124d17> wake_bit_function+0x0/0x3c
<c014a1b3> __wait_on_buffer+0x1c/0x1f <c014c575> __bread+0x59/0x6c
<c01771b4> read_inode_bitmap+0x28/0x4c <c01779ed> ext3_new_inode+0x3f9/0x824
<c017d188> ext3_create+0x5d/0xc2 <c017d12b> ext3_create+0x0/0xc2
<c0155811> vfs_create+0x5e/0x9a <c0155982> open_namei+0x135/0x4e5
<c0148839> do_filp_open+0x1c/0x31 <c01af373> snprintf+0x1b/0x1f
<c014885d> filp_open+0xf/0x11 <c0151295> do_coredump+0x4e9/0x59e
<c011e84a> __dequeue_signal+0x149/0x154 <c011f777> get_signal_to_deliver+0x3eb/0x418
<c0111230> do_page_fault+0x0/0x4c3 <c0102372> do_notify_resume+0x6f/0x5a1
<c0103463> error_code+0x4f/0x54 <c028dd4a> iret_exc+0x136/0x779
<c01116a3> do_page_fault+0x473/0x4c3 <c0111230> do_page_fault+0x0/0x4c3
<c0102a5e> work_notifysig+0x13/0x19
hub 2-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x100
hub 3-0:1.0: state 7 ports 3 chg 0004 evt 0006
ohci_hcd 0000:01:07.0: GetStatus roothub.portstatus [0] = 0x00010100 CSC PPS
hub 3-0:1.0: port 1, status 0100, change 0001, 12 Mb/s
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c01354ed> get_page_from_freelist+0x7d/0x2fb
<c01a7957> generic_make_request+0x191/0x1c2 <c028be58> io_schedule+0xe/0x16
<c014a963> sync_buffer+0x2b/0x2e <c028c733> __wait_on_bit+0x31/0x56
<c014a938> sync_buffer+0x0/0x2e <c014a938> sync_buffer+0x0/0x2e
<c028c7b9> out_of_line_wait_on_bit+0x61/0x69 <c0124d17> wake_bit_function+0x0/0x3c
<c014a1b3> __wait_on_buffer+0x1c/0x1f <c0178352> __ext3_get_inode_loc+0x27b/0x2c2
<c017841e> ext3_reserve_inode_write+0x1a/0x7a <c017889b> ext3_mark_inode_dirty+0x11/0x27
<c01858ca> journal_dirty_metadata+0x12e/0x15c <c0177d87> ext3_new_inode+0x793/0x824
<c017d188> ext3_create+0x5d/0xc2 <c017d12b> ext3_create+0x0/0xc2
<c0155811> vfs_create+0x5e/0x9a <c0155982> open_namei+0x135/0x4e5
<c0148839> do_filp_open+0x1c/0x31 <c01af373> snprintf+0x1b/0x1f
<c014885d> filp_open+0xf/0x11 <c0151295> do_coredump+0x4e9/0x59e
<c011e84a> __dequeue_signal+0x149/0x154 <c011f777> get_signal_to_deliver+0x3eb/0x418
<c0111230> do_page_fault+0x0/0x4c3 <c0102372> do_notify_resume+0x6f/0x5a1
<c0103463> error_code+0x4f/0x54 <c028dd4a> iret_exc+0x136/0x779
<c01116a3> do_page_fault+0x473/0x4c3 <c0111230> do_page_fault+0x0/0x4c3
<c0102a5e> work_notifysig+0x13/0x19
hub 3-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x100
ohci_hcd 0000:01:07.0: GetStatus roothub.portstatus [1] = 0x00010100 CSC PPS
hub 3-0:1.0: port 2, status 0100, change 0001, 12 Mb/s
usb 3-2: USB disconnect, address 3
usb 3-2: usb_disable_device nuking all URBs
usb 3-2: unregistering interface 3-2:1.0
usb 3-2:1.0: uevent
usb 3-2: unregistering device
usb 3-2: uevent
hub 3-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100
hub 4-0:1.0: state 7 ports 2 chg 0000 evt 0002
ohci_hcd 0000:01:07.1: GetStatus roothub.portstatus [0] = 0x00010100 CSC PPS
hub 4-0:1.0: port 1, status 0100, change 0001, 12 Mb/s
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c01a7957> generic_make_request+0x191/0x1c2
<c028be58> io_schedule+0xe/0x16 <c014a963> sync_buffer+0x2b/0x2e
<c028c733> __wait_on_bit+0x31/0x56 <c014a938> sync_buffer+0x0/0x2e
<c014a938> sync_buffer+0x0/0x2e <c028c7b9> out_of_line_wait_on_bit+0x61/0x69
<c0124d17> wake_bit_function+0x0/0x3c <c014a1b3> __wait_on_buffer+0x1c/0x1f
<c0178352> __ext3_get_inode_loc+0x27b/0x2c2 <c017841e> ext3_reserve_inode_write+0x1a/0x7a
<c017889b> ext3_mark_inode_dirty+0x11/0x27 <c017be7c> add_dirent_to_buf+0x1fa/0x279
<c017c836> ext3_add_entry+0x11f/0x871 <c0177e08> ext3_new_inode+0x814/0x824
<c017cf97> ext3_add_nondir+0xf/0x3a <c017d1b9> ext3_create+0x8e/0xc2
<c017d12b> ext3_create+0x0/0xc2 <c0155811> vfs_create+0x5e/0x9a
<c0155982> open_namei+0x135/0x4e5 <c0148839> do_filp_open+0x1c/0x31
<c01af373> snprintf+0x1b/0x1f <c014885d> filp_open+0xf/0x11
<c0151295> do_coredump+0x4e9/0x59e <c011e84a> __dequeue_signal+0x149/0x154
<c011f777> get_signal_to_deliver+0x3eb/0x418 <c0111230> do_page_fault+0x0/0x4c3
<c0102372> do_notify_resume+0x6f/0x5a1 <c0103463> error_code+0x4f/0x54
<c028dd4a> iret_exc+0x136/0x779 <c01116a3> do_page_fault+0x473/0x4c3
<c0111230> do_page_fault+0x0/0x4c3 <c0102a5e> work_notifysig+0x13/0x19
hub 4-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x100
hub 5-0:1.0: state 7 ports 5 chg 0004 evt 000c
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001803 POWER sig=j CSC CONNECT
hub 5-0:1.0: port 2, status 0501, change 0001, 480 Mb/s
usb 5-2: USB disconnect, address 3
usb 5-2: usb_disable_device nuking all URBs
usb 5-2: unregistering interface 5-2:1.0
usb 5-2:1.0: uevent
usb 5-2: unregistering device
usb 5-2: uevent
hub 5-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c011652c> vprintk+0x23f/0x286
<c01a7957> generic_make_request+0x191/0x1c2 <c028be58> io_schedule+0xe/0x16
<c014a963> sync_buffer+0x2b/0x2e <c028c733> __wait_on_bit+0x31/0x56
<c014a938> sync_buffer+0x0/0x2e <c014a938> sync_buffer+0x0/0x2e
<c028c7b9> out_of_line_wait_on_bit+0x61/0x69 <c0124d17> wake_bit_function+0x0/0x3c
<c014a1b3> __wait_on_buffer+0x1c/0x1f <c014c575> __bread+0x59/0x6c
<c017550e> read_block_bitmap+0x27/0x4a <c0176336> ext3_new_blocks+0x191/0x55d
<c01281c3> debug_mutex_add_waiter+0x14/0x25 <c0179dad> ext3_get_blocks_handle+0x12b/0x89d
<c0179dad> ext3_get_blocks_handle+0x12b/0x89d <c0179fd5> ext3_get_blocks_handle+0x353/0x89d
<c0102a5e> work_notifysig+0x13/0x19 <c011652c> vprintk+0x23f/0x286
<c011652c> vprintk+0x23f/0x286 <c010dc72> smp_apic_timer_interrupt+0x2a/0x2f
<c01033bc> apic_timer_interrupt+0x1c/0x24 <c017a5ad> ext3_direct_io_get_blocks+0x8e/0xa8
<c017a5d6> ext3_get_block+0xf/0x12 <c014b904> __block_prepare_write+0x114/0x379
<c014bb7f> block_prepare_write+0x16/0x22 <c017a5c7> ext3_get_block+0x0/0x12
<c01795fc> ext3_prepare_write+0x7f/0x115 <c017a5c7> ext3_get_block+0x0/0x12
<c013216e> generic_file_buffered_write+0x21e/0x52b <c0183f09> journal_stop+0x1c7/0x1d1
<c017ef4f> __ext3_journal_stop+0x19/0x34 <c013353e> __generic_file_aio_write_nolock+0x3a1/0x3de
<c013377e> generic_file_aio_write+0x3d/0xa4 <c0133792> generic_file_aio_write+0x51/0xa4
<c017701d> ext3_file_write+0x19/0x83 <c0148df6> do_sync_write+0xb8/0xf3
<c0124c68> autoremove_wake_function+0x0/0x2d <c017ba41> ext3_orphan_del+0x52/0x1b6
<c015d87a> inode_setattr+0x146/0x150 <c01affab> _mmx_memcpy+0x3c/0x136
<c0169540> dump_write+0x10/0x1c <c016b515> elf_core_dump+0x6ad/0xb32
<c015dba3> notify_change+0x20d/0x21d <c01512f1> do_coredump+0x545/0x59e
<c011e84a> __dequeue_signal+0x149/0x154 <c011f777> get_signal_to_deliver+0x3eb/0x418
<c0111230> do_page_fault+0x0/0x4c3 <c0102372> do_notify_resume+0x6f/0x5a1
<c0103463> error_code+0x4f/0x54 <c028dd4a> iret_exc+0x136/0x779
<c01116a3> do_page_fault+0x473/0x4c3 <c0111230> do_page_fault+0x0/0x4c3
<c0102a5e> work_notifysig+0x13/0x19
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 4
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c01a7957> generic_make_request+0x191/0x1c2
<c028be58> io_schedule+0xe/0x16 <c014a963> sync_buffer+0x2b/0x2e
<c028c733> __wait_on_bit+0x31/0x56 <c014a938> sync_buffer+0x0/0x2e
<c014a938> sync_buffer+0x0/0x2e <c028c7b9> out_of_line_wait_on_bit+0x61/0x69
<c0124d17> wake_bit_function+0x0/0x3c <c014a1b3> __wait_on_buffer+0x1c/0x1f
<c014c575> __bread+0x59/0x6c <c0179c0d> ext3_get_branch+0x6b/0xe0
<c0179d37> ext3_get_blocks_handle+0xb5/0x89d <c0135653> get_page_from_freelist+0x1e3/0x2fb
<c01858ef> journal_dirty_metadata+0x153/0x15c <c0178830> ext3_mark_iloc_dirty+0x2d7/0x331
<c017a5ad> ext3_direct_io_get_blocks+0x8e/0xa8 <c017a5d6> ext3_get_block+0xf/0x12
<c0164d2d> do_mpage_readpage+0xe3/0x318 <c0132461> generic_file_buffered_write+0x511/0x52b
<c0165787> mpage_readpages+0x8e/0xef <c017a5c7> ext3_get_block+0x0/0x12
<c01357b8> __alloc_pages+0x4d/0x25d <c0177e7e> ext3_readpages+0x0/0x15
<c0136aaf> __do_page_cache_readahead+0x140/0x201 <c017a5c7> ext3_get_block+0x0/0x12
<c013377e> generic_file_aio_write+0x3d/0xa4 <c013379b> generic_file_aio_write+0x5a/0xa4
<c0132a98> filemap_nopage+0x148/0x2e2 <c013bab5> __handle_mm_fault+0x201/0x6a2
<c013c102> get_user_pages+0x1ac/0x25b <c016b7eb> elf_core_dump+0x983/0xb32
<c01512f1> do_coredump+0x545/0x59e <c011e84a> __dequeue_signal+0x149/0x154
<c011f777> get_signal_to_deliver+0x3eb/0x418 <c0111230> do_page_fault+0x0/0x4c3
<c0102372> do_notify_resume+0x6f/0x5a1 <c0103463> error_code+0x4f/0x54
<c028dd4a> iret_exc+0x136/0x779 <c01116a3> do_page_fault+0x473/0x4c3
<c0111230> do_page_fault+0x0/0x4c3 <c0102a5e> work_notifysig+0x13/0x19
BUG: scheduling while atomic: zsh/0x00000001/2196
<c028b93f> schedule+0x43/0x54e <c0177e7e> ext3_readpages+0x0/0x15
<c0136aaf> __do_page_cache_readahead+0x140/0x201 <c017a5c7> ext3_get_block+0x0/0x12
<c028be58> io_schedule+0xe/0x16 <c0131043> sync_page+0x0/0x36
<c0131076> sync_page+0x33/0x36 <c028c7ed> __wait_on_bit_lock+0x2c/0x51
<c0131169> __lock_page+0x50/0x56 <c0124d17> wake_bit_function+0x0/0x3c
<c0132b5c> filemap_nopage+0x20c/0x2e2 <c013bab5> __handle_mm_fault+0x201/0x6a2
<c013c102> get_user_pages+0x1ac/0x25b <c016b7eb> elf_core_dump+0x983/0xb32
<c01512f1> do_coredump+0x545/0x59e <c011e84a> __dequeue_signal+0x149/0x154
<c011f777> get_signal_to_deliver+0x3eb/0x418 <c0111230> do_page_fault+0x0/0x4c3
<c0102372> do_notify_resume+0x6f/0x5a1 <c0103463> error_code+0x4f/0x54
<c028dd4a> iret_exc+0x136/0x779 <c01116a3> do_page_fault+0x473/0x4c3
<c0111230> do_page_fault+0x0/0x4c3 <c0102a5e> work_notifysig+0x13/0x19
note: zsh[2196] exited with preempt_count 1
0:0:0:0: rejecting I/O to dead device
EXT3-fs error (device sda1): ext3_find_entry: reading directory #2 offset 0
ehci_hcd 0000:01:07.2: Unlink after no-IRQ? Controller is probably using the wrong IRQ.
usb 5-2: khubd timed out on ep0in len=8/64
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
usb 5-2: khubd timed out on ep0out len=0/0
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
usb 5-2: khubd timed out on ep0out len=0/0
0:0:0:0: rejecting I/O to dead device
usb 5-2: device not accepting address 4, error -110
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 5
0:0:0:0: rejecting I/O to dead device
usb 5-2: khubd timed out on ep0in len=18/64
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
usb 5-2: khubd timed out on ep0out len=0/0
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 5, error -110
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 6
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
usb 5-2: khubd timed out on ep0out len=0/0
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 6, error -110
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 7
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
usb 5-2: khubd timed out on ep0out len=0/0
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 7, error -110
ehci_hcd 0000:01:07.2: GetStatus port 3 status 001403 POWER sig=k CSC CONNECT
hub 5-0:1.0: port 3, status 0501, change 0001, 480 Mb/s
hub 5-0:1.0: debounce: port 3: total 100ms stable 100ms status 0x501
ehci_hcd 0000:01:07.2: port 3 low speed --> companion
ehci_hcd 0000:01:07.2: GetStatus port 3 status 003402 POWER OWNER sig=k CSC
hub 5-0:1.0: state 7 ports 5 chg 0000 evt 0000
hub 3-0:1.0: state 7 ports 3 chg 0000 evt 0004
ohci_hcd 0000:01:07.0: GetStatus roothub.portstatus [1] = 0x00010301 CSC LSDA PPS CCS
hub 3-0:1.0: port 2, status 0301, change 0001, 1.5 Mb/s
0:0:0:0: rejecting I/O to dead device
hub 3-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x301
ohci_hcd 0000:01:07.0: GetStatus roothub.portstatus [1] = 0x00100303 PRSC LSDA PPS PES CCS
usb 3-2: new low speed USB device using ohci_hcd and address 4
ohci_hcd 0000:01:07.0: GetStatus roothub.portstatus [1] = 0x00100303 PRSC LSDA PPS PES CCS
usb 3-2: skipped 1 descriptor after interface
usb 3-2: default language 0x0409
usb 3-2: new device found, idVendor=045e, idProduct=0040
usb 3-2: new device strings: Mfr=1, Product=3, SerialNumber=0
usb 3-2: Product: Microsoft 3-Button Mouse with IntelliEye(TM)
usb 3-2: Manufacturer: Microsoft
usb 3-2: uevent
usb 3-2: device is bus-powered
usb 3-2: configuration #1 chosen from 1 choice
usb 3-2: adding 3-2:1.0 (config #1, interface 0)
usb 3-2:1.0: uevent
usbhid 3-2:1.0: usb_probe_interface
usbhid 3-2:1.0: usb_probe_interface - got id
input: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM) as /class/input/input3
input: USB HID v1.10 Mouse [Microsoft Microsoft 3-Button Mouse with IntelliEye(TM)] on usb-0000:01:07.0-2
drivers/usb/core/inode.c: creating file '004'
hub 3-0:1.0: state 7 ports 3 chg 0000 evt 0004
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
0:0:0:0: rejecting I/O to dead device
hub 5-0:1.0: state 7 ports 5 chg 0000 evt 0004
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001002 POWER sig=se0 CSC
hub 5-0:1.0: port 2, status 0100, change 0001, 12 Mb/s
hub 5-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100
hub 5-0:1.0: state 7 ports 5 chg 0000 evt 0004
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001803 POWER sig=j CSC CONNECT
hub 5-0:1.0: port 2, status 0501, change 0001, 480 Mb/s
hub 5-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 9
usb 5-2: khubd timed out on ep0in len=18/64
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 9, error -110
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 10
usb 5-2: khubd timed out on ep0in len=18/64
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 10, error -110
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 11
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 11, error -110
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 12
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 12, error -110
hub 5-0:1.0: state 7 ports 5 chg 0000 evt 0004
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001002 POWER sig=se0 CSC
hub 5-0:1.0: port 2, status 0100, change 0001, 12 Mb/s
hub 5-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100
hub 5-0:1.0: state 7 ports 5 chg 0000 evt 0004
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001803 POWER sig=j CSC CONNECT
hub 5-0:1.0: port 2, status 0501, change 0001, 480 Mb/s
hub 5-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 13
usb 5-2: khubd timed out on ep0in len=8/64
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 13, error -110
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 14
usb 5-2: khubd timed out on ep0in len=18/64
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 14, error -110
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 15
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 15, error -110
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 16
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 16, error -110
hub 5-0:1.0: state 7 ports 5 chg 0000 evt 0004
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001002 POWER sig=se0 CSC
hub 5-0:1.0: port 2, status 0100, change 0001, 12 Mb/s
hub 5-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100
hub 5-0:1.0: state 7 ports 5 chg 0000 evt 0004
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001803 POWER sig=j CSC CONNECT
hub 5-0:1.0: port 2, status 0501, change 0001, 480 Mb/s
hub 5-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 17
usb 5-2: khubd timed out on ep0in len=8/64
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 17, error -110
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 18
usb 5-2: khubd timed out on ep0in len=18/64
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 18, error -110
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 19
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 19, error -110
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 20
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 20, error -110
[-- Attachment #3: Type: text/plain, Size: 153 bytes --]
while testing suspending with that kernel, the root shell that echoed
in /sys/power/state got killed with "note: zsh[2196] exited with preempt_count 1"
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Linux 2.6.16-rc3
2006-02-15 13:40 ` Thierry Vignaud
@ 2006-02-15 20:00 ` Andrew Morton
0 siblings, 0 replies; 104+ messages in thread
From: Andrew Morton @ 2006-02-15 20:00 UTC (permalink / raw)
To: Thierry Vignaud; +Cc: tiwai, linux-kernel
Thierry Vignaud <tvignaud@mandriva.com> wrote:
>
> Andrew Morton <akpm@osdl.org> writes:
>
> > > > It's not a "regression". PM didn't work with ens1370 at all in
> > > > the eralier version.
> > >
> > > btw, PM support in snd-intel8x0 is broken (at least regarding
> > > suspending) in 2.6.16-rc2-mm1 on a nforce2 chipset
> >
> > Can you identify when this breakage occurred?
>
> i'll try to compile a few older kernels (and/or just older
> alsa-kernel) if you want but i'm not sure it's a regression (i'll
> check if it has ever worked before).
OK, thanks.
> i've tried unloading/reloading sound modules after resuming (maybe
> would it work if unloaded before suspending but of course full PM
> support would be nicer).
>
> not sure if it can help but while resuming, the snd-intel8x0 printed
> quite a lot of warnings (due to preempting[1] i guess?) such as:
> BUG: scheduling while atomic: zsh/0x00000001/2196
> <c028b93f> schedule+0x43/0x54e <c028c6bf> schedule_timeout+0x7a/0x95
> <c011c755> process_timeout+0x0/0x5 <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
> <d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0] <c01b6dee> pci_device_resume+0x16/0x43
> <c02025d9> resume_device+0x7d/0x96 <c02026a7> dpm_resume+0x58/0x80
> <c02026dc> device_resume+0xd/0x16 <c012db1f> pm_suspend_disk+0xbf/0xc8
> <c012cb95> enter_state+0x50/0x16f <c012cd37> state_store+0x83/0x8f
> <c012ccb4> state_store+0x0/0x8f <c0173492> subsys_attr_store+0x1e/0x22
> <c0173a1b> sysfs_write_file+0x92/0xb9 <c0173989> sysfs_write_file+0x0/0xb9
> <c01491ca> vfs_write+0x83/0x122 <c01499df> sys_write+0x3c/0x63
> <c0102973> sysenter_past_esp+0x54/0x75
>
> dmesg after resuming (only look at the beginning, the end is only ehci
> garbage b/c ehci is bugging for monthes (rejecting mass media after
> writing a few Mo)):
That's odd. I don't see what could have elevated preempt_count() on that
path. What does `grep PREEMPT .config' say?
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Linux 2.6.16-rc3
2006-02-13 12:02 ` Linux 2.6.16-rc3 Takashi Iwai
` (2 preceding siblings ...)
2006-02-13 16:36 ` Thierry Vignaud
@ 2006-02-13 16:36 ` Thierry Vignaud
3 siblings, 0 replies; 104+ messages in thread
From: Thierry Vignaud @ 2006-02-13 16:36 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 457 bytes --]
Takashi Iwai <tiwai@suse.de> writes:
> It's not a "regression". PM didn't work with ens1370 at all in the
> eralier version.
btw, PM support in snd-intel8x0 is broken (at least regarding
suspending) in 2.6.16-rc2-mm1 on a nforce2 chipset
even if not playing while suspending, ALSA won't resume playing: no
more program can play anything strace show that sound programs block
on unfinished "futex(0xb7768060, FUTEX_WAIT, 29, NULL..." calls
lspci -vvvv:
[-- Attachment #2: bug.suspend.lspci --]
[-- Type: text/plain, Size: 8816 bytes --]
00:00.0 Host bridge: nVidia Corporation nForce CPU bridge (rev b2)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Region 0: Memory at d8000000 (32-bit, prefetchable) [size=64M]
Capabilities: <access denied>
00:00.1 RAM memory: nVidia Corporation nForce 220/420 Memory Controller (rev b2)
Subsystem: ABIT Computer Corp. Unknown device 7105
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
00:00.2 RAM memory: nVidia Corporation nForce 220/420 Memory Controller (rev b2)
Subsystem: ABIT Computer Corp. Unknown device 7105
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
00:00.3 RAM memory: nVidia Corporation nForce 420 Memory Controller (DDR) (rev b2)
Subsystem: ABIT Computer Corp. Unknown device 7105
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
00:01.0 ISA bridge: nVidia Corporation nForce ISA Bridge (rev c3)
Subsystem: ABIT Computer Corp. Unknown device 7105
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Capabilities: <access denied>
00:01.1 SMBus: nVidia Corporation nForce PCI System Management (rev c1)
Subsystem: ABIT Computer Corp. Unknown device 7105
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at 5000 [size=16]
Region 1: I/O ports at d000 [size=16]
Region 2: I/O ports at d400 [size=32]
Capabilities: <access denied>
00:02.0 USB Controller: nVidia Corporation nForce USB Controller (rev c3) (prog-if 10 [OHCI])
Subsystem: ABIT Computer Corp. Unknown device 7105
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin A routed to IRQ 5
Region 0: Memory at e0081000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <access denied>
00:03.0 USB Controller: nVidia Corporation nForce USB Controller (rev c3) (prog-if 10 [OHCI])
Subsystem: ABIT Computer Corp. Unknown device 7105
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin A routed to IRQ 3
Region 0: Memory at e0080000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <access denied>
00:05.0 Multimedia audio controller: nVidia Corporation nForce Audio (rev c2)
Subsystem: ABIT Computer Corp. Unknown device 7105
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (250ns min, 3000ns max)
Interrupt: pin A routed to IRQ 5
Region 0: Memory at e0000000 (32-bit, non-prefetchable) [size=512K]
Capabilities: <access denied>
00:06.0 Multimedia audio controller: nVidia Corporation nForce Audio (rev c2)
Subsystem: ABIT Computer Corp. Unknown device 7105
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (500ns min, 1250ns max)
Interrupt: pin A routed to IRQ 3
Region 0: I/O ports at d800 [size=256]
Region 1: I/O ports at dc00 [size=128]
Region 2: Memory at e0082000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <access denied>
00:08.0 PCI bridge: nVidia Corporation nForce PCI-to-PCI bridge (rev c2) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
I/O behind bridge: 0000c000-0000cfff
Memory behind bridge: de000000-dfffffff
Prefetchable memory behind bridge: 10000000-100fffff
Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
00:09.0 IDE interface: nVidia Corporation nForce IDE (rev c3) (prog-if 8a [Master SecP PriP])
Subsystem: ABIT Computer Corp. Unknown device 7105
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Region 4: I/O ports at e400 [size=16]
Capabilities: <access denied>
00:1e.0 PCI bridge: nVidia Corporation nForce AGP to PCI Bridge (rev b2) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32
Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: dc000000-ddffffff
Prefetchable memory behind bridge: d0000000-d7ffffff
Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA+ VGA+ MAbort- >Reset- FastB2B-
01:06.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 64)
Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2500ns min, 2500ns max), Cache Line Size 08
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at c000 [size=128]
Region 1: Memory at df000000 (32-bit, non-prefetchable) [size=128]
[virtual] Expansion ROM at 10000000 [disabled] [size=128K]
Capabilities: <access denied>
01:07.0 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
Subsystem: Adaptec Unknown device 0335
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (250ns min, 10500ns max), Cache Line Size 08
Interrupt: pin A routed to IRQ 12
Region 0: Memory at df001000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <access denied>
01:07.1 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
Subsystem: Adaptec Unknown device 0335
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (250ns min, 10500ns max), Cache Line Size 08
Interrupt: pin B routed to IRQ 11
Region 0: Memory at df002000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <access denied>
01:07.2 USB Controller: NEC Corporation USB 2.0 (rev 02) (prog-if 20 [EHCI])
Subsystem: Adaptec Unknown device 03e0
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (4000ns min, 8500ns max), Cache Line Size 10
Interrupt: pin C routed to IRQ 11
Region 0: Memory at df003000 (32-bit, non-prefetchable) [size=256]
Capabilities: <access denied>
02:00.0 VGA compatible controller: nVidia Corporation NVCrush11 [GeForce2 MX Integrated Graphics] (rev b1) (prog-if 00 [VGA])
Subsystem: ABIT Computer Corp. Unknown device 7105
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (1250ns min, 250ns max)
Interrupt: pin A routed to IRQ 12
Region 0: Memory at dc000000 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at d0000000 (32-bit, prefetchable) [size=128M]
[virtual] Expansion ROM at dd000000 [disabled] [size=64K]
Capabilities: <access denied>
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Linux 2.6.16-rc3
2006-02-13 3:05 ` Andrew Morton
` (9 preceding siblings ...)
2006-02-13 12:02 ` Linux 2.6.16-rc3 Takashi Iwai
@ 2006-02-13 16:10 ` Adrian Bunk
2006-02-13 19:31 ` Daniel Drake
2006-02-13 20:30 ` Paul Fulghum
` (4 subsequent siblings)
15 siblings, 1 reply; 104+ messages in thread
From: Adrian Bunk @ 2006-02-13 16:10 UTC (permalink / raw)
To: Andrew Morton
Cc: Linus Torvalds, linux-kernel, Greg KH, linux-usb-devel, dbrownell
On Sun, Feb 12, 2006 at 07:05:20PM -0800, Andrew Morton wrote:
>...
> - Various reports similar to
> http://bugzilla.kernel.org/show_bug.cgi?id=6011, seemingly related to USB
> PCI quirk handling.
>...
This bug contains a patch.
What is the status of this patch?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3
2006-02-13 16:10 ` Adrian Bunk
@ 2006-02-13 19:31 ` Daniel Drake
0 siblings, 0 replies; 104+ messages in thread
From: Daniel Drake @ 2006-02-13 19:31 UTC (permalink / raw)
To: Adrian Bunk
Cc: Andrew Morton, Linus Torvalds, linux-kernel, Greg KH,
linux-usb-devel, dbrownell
Adrian Bunk wrote:
> On Sun, Feb 12, 2006 at 07:05:20PM -0800, Andrew Morton wrote:
>> ...
>> - Various reports similar to
>> http://bugzilla.kernel.org/show_bug.cgi?id=6011, seemingly related to USB
>> PCI quirk handling.
>> ...
>
> This bug contains a patch.
>
> What is the status of this patch?
The patch is in Greg's tree so should see its way to Linus soon.
However, it's not the complete fix for the general issue.
Gentoo have had two reports of it. One is fixed by David's patch, the
other is not (http://bugs.gentoo.org/122277 - will be re-filed on kernel
bugzilla once I have investigated more).
Daniel
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Linux 2.6.16-rc3
2006-02-13 3:05 ` Andrew Morton
` (10 preceding siblings ...)
2006-02-13 16:10 ` Adrian Bunk
@ 2006-02-13 20:30 ` Paul Fulghum
2006-02-13 20:38 ` Greg KH
` (3 subsequent siblings)
15 siblings, 0 replies; 104+ messages in thread
From: Paul Fulghum @ 2006-02-13 20:30 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linus Torvalds, Linux Kernel Mailing List
On Sun, 2006-02-12 at 19:05 -0800, Andrew Morton wrote:
> - A couple of random tty-related oopses reported by Jesper Juhl. We
> don't know why these happened - they appear to not be related to the tty
> buffering changes.
I just posted a patch for this under
[PATCH] tty reference count fix
This is not related to the tty buffering changes.
--
Paul Fulghum
Microgate Systems, Ltd
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3
2006-02-13 3:05 ` Andrew Morton
` (11 preceding siblings ...)
2006-02-13 20:30 ` Paul Fulghum
@ 2006-02-13 20:38 ` Greg KH
2006-02-14 16:34 ` James Bottomley
2006-02-14 15:19 ` [PATCH] x86: fix oprofile kernel callgraph regression Gerald Britton
` (2 subsequent siblings)
15 siblings, 1 reply; 104+ messages in thread
From: Greg KH @ 2006-02-13 20:38 UTC (permalink / raw)
To: Andrew Morton
Cc: Linus Torvalds, linux-kernel, Jens Axboe, James Bottomley,
Brown, Len, David S. Miller, linux-acpi, linux-usb-devel,
Yu, Luming, Ben Castricum, sanjoy, Helge Hafting, Carlo E. Prelz,
Gerrit Bruchh?user, Nicolas.Mailhot, Jaroslav Kysela,
Takashi Iwai, Patrizio Bassi, Bj?rn Nilsson, Andrey Borzenkov,
P. Christeas, ghrt, jinhong hu, Andrew Vasquez, linux-scsi,
Benjamin LaHaise
On Sun, Feb 12, 2006 at 07:05:20PM -0800, Andrew Morton wrote:
>
> We still have some serious bugs, several of which are in 2.6.15 as well:
>
> - Nathan's "sysfs-related oops during module unload", which Greg seems to
> have under control.
Yes, this isn't a "regression" but has been there for a while. It can
also only be triggered by a root user, so it's severity is much lower.
> - Various reports similar to
> http://bugzilla.kernel.org/show_bug.cgi?id=6011, seemingly related to USB
> PCI quirk handling.
I have a patch for this, which will be going to Linus later tonight.
> - Nasty warnings from scsi about kobject-layer things being called from
> irq context. James has a push-it-to-process-context patch which sadly
> assumes kmalloc() is immortal, but no other fix seems to have offered
> itself.
This has been the case for a long time. I don't really think there is a
rush to get this fixed, but I really like James's proposed patch. It's
up to him if he feels it is ready for 2.6.16 or not.
> - Helge Hafting reports a usb printer regression - I don't know if that's
> still live?
He never reported back, and one other person who reported this, figured
out that it was bad ram in the system. Replacing that fixed the issue.
I've also printed a lot of stuff here (tax time...) and had no problems.
> - "Carlo E. Prelz" <fluido@fluido.as> has another USB/ehci regression
> ("ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15
> rc1").
Fixed by the previously mentioned EHCI quirk/handoff patch that will be
going to Linus.
So, that's it for the USB stuff, thankfully.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3
2006-02-13 20:38 ` Greg KH
@ 2006-02-14 16:34 ` James Bottomley
2006-02-15 16:07 ` [linux-usb-devel] " Alan Stern
2006-02-16 1:56 ` James Bottomley
0 siblings, 2 replies; 104+ messages in thread
From: James Bottomley @ 2006-02-14 16:34 UTC (permalink / raw)
To: Greg KH
Cc: Andrew Morton, Linus Torvalds, linux-kernel, Jens Axboe,
Brown, Len, David S. Miller, linux-acpi, linux-usb-devel,
Yu, Luming, Ben Castricum, sanjoy, Helge Hafting, Carlo E. Prelz,
Gerrit Bruchh?user, Nicolas.Mailhot, Jaroslav Kysela,
Takashi Iwai, Patrizio Bassi, Bj?rn Nilsson, Andrey Borzenkov,
P. Christeas, ghrt, jinhong hu, Andrew Vasquez, linux-scsi,
Benjamin LaHaise
On Mon, 2006-02-13 at 12:38 -0800, Greg KH wrote:
> > - Nasty warnings from scsi about kobject-layer things being called
> from
> > irq context. James has a push-it-to-process-context patch which
> sadly
> > assumes kmalloc() is immortal, but no other fix seems to have
> offered
> > itself.
>
> This has been the case for a long time. I don't really think there is
> a
> rush to get this fixed, but I really like James's proposed patch.
> It's
> up to him if he feels it is ready for 2.6.16 or not.
Well, I can't solve the problem that it requires memory allocation from
IRQ context to operate. Based on that, it's an unsafe interface. I'm
going to put it inside SCSI for 2.6.16, since it's better than what we
have now, but I don't think we can export it globally.
James
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [linux-usb-devel] Re: Linux 2.6.16-rc3
2006-02-14 16:34 ` James Bottomley
@ 2006-02-15 16:07 ` Alan Stern
2006-02-15 16:27 ` Greg KH
2006-02-15 19:58 ` James Bottomley
2006-02-16 1:56 ` James Bottomley
1 sibling, 2 replies; 104+ messages in thread
From: Alan Stern @ 2006-02-15 16:07 UTC (permalink / raw)
To: James Bottomley, Greg KH; +Cc: Kernel development list
On Tue, 14 Feb 2006, James Bottomley wrote:
> On Mon, 2006-02-13 at 12:38 -0800, Greg KH wrote:
> > > - Nasty warnings from scsi about kobject-layer things being called
> > from
> > > irq context. James has a push-it-to-process-context patch which
> > sadly
> > > assumes kmalloc() is immortal, but no other fix seems to have
> > offered
> > > itself.
> >
> > This has been the case for a long time. I don't really think there is
> > a
> > rush to get this fixed, but I really like James's proposed patch.
> > It's
> > up to him if he feels it is ready for 2.6.16 or not.
>
> Well, I can't solve the problem that it requires memory allocation from
> IRQ context to operate. Based on that, it's an unsafe interface. I'm
> going to put it inside SCSI for 2.6.16, since it's better than what we
> have now, but I don't think we can export it globally.
Could we perhaps make this safer and more general?
For instance, add to struct device a "pending puts" counter and a list
header (both protected by a global spinlock), and have a kernel thread
periodically check the list, doing put_device wherever needed. How does
that sound?
Alan Stern
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [linux-usb-devel] Re: Linux 2.6.16-rc3
2006-02-15 16:07 ` [linux-usb-devel] " Alan Stern
@ 2006-02-15 16:27 ` Greg KH
2006-02-15 16:35 ` Arjan van de Ven
2006-02-15 19:58 ` James Bottomley
1 sibling, 1 reply; 104+ messages in thread
From: Greg KH @ 2006-02-15 16:27 UTC (permalink / raw)
To: Alan Stern; +Cc: James Bottomley, Kernel development list
On Wed, Feb 15, 2006 at 11:07:32AM -0500, Alan Stern wrote:
> On Tue, 14 Feb 2006, James Bottomley wrote:
>
> > On Mon, 2006-02-13 at 12:38 -0800, Greg KH wrote:
> > > > - Nasty warnings from scsi about kobject-layer things being called
> > > from
> > > > irq context. James has a push-it-to-process-context patch which
> > > sadly
> > > > assumes kmalloc() is immortal, but no other fix seems to have
> > > offered
> > > > itself.
> > >
> > > This has been the case for a long time. I don't really think there is
> > > a
> > > rush to get this fixed, but I really like James's proposed patch.
> > > It's
> > > up to him if he feels it is ready for 2.6.16 or not.
> >
> > Well, I can't solve the problem that it requires memory allocation from
> > IRQ context to operate. Based on that, it's an unsafe interface. I'm
> > going to put it inside SCSI for 2.6.16, since it's better than what we
> > have now, but I don't think we can export it globally.
>
> Could we perhaps make this safer and more general?
>
> For instance, add to struct device a "pending puts" counter and a list
> header (both protected by a global spinlock), and have a kernel thread
> periodically check the list, doing put_device wherever needed. How does
> that sound?
Sounds like a garbage collector :)
Nah, I don't think it's a good idea. James's patch should work just
fine.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [linux-usb-devel] Re: Linux 2.6.16-rc3
2006-02-15 16:27 ` Greg KH
@ 2006-02-15 16:35 ` Arjan van de Ven
2006-02-15 17:06 ` Greg KH
0 siblings, 1 reply; 104+ messages in thread
From: Arjan van de Ven @ 2006-02-15 16:35 UTC (permalink / raw)
To: Greg KH; +Cc: Alan Stern, James Bottomley, Kernel development list
On Wed, 2006-02-15 at 08:27 -0800, Greg KH wrote:
>
> Nah, I don't think it's a good idea. James's patch should work just
> fine.
another option is to have a "kill list" which you put the thing on, and
then wake up a thread. only 2 pointers in the object ;(
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [linux-usb-devel] Re: Linux 2.6.16-rc3
2006-02-15 16:35 ` Arjan van de Ven
@ 2006-02-15 17:06 ` Greg KH
2006-02-15 21:52 ` Alan Stern
0 siblings, 1 reply; 104+ messages in thread
From: Greg KH @ 2006-02-15 17:06 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Alan Stern, James Bottomley, Kernel development list
On Wed, Feb 15, 2006 at 05:35:08PM +0100, Arjan van de Ven wrote:
> On Wed, 2006-02-15 at 08:27 -0800, Greg KH wrote:
> >
> > Nah, I don't think it's a good idea. James's patch should work just
> > fine.
>
> another option is to have a "kill list" which you put the thing on, and
> then wake up a thread. only 2 pointers in the object ;(
Hm, that's almost what James's patch is trying to do. Care to mock up a
patch that shows this? It might be a simpler solution.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [linux-usb-devel] Re: Linux 2.6.16-rc3
2006-02-15 17:06 ` Greg KH
@ 2006-02-15 21:52 ` Alan Stern
2006-02-15 21:59 ` Greg KH
0 siblings, 1 reply; 104+ messages in thread
From: Alan Stern @ 2006-02-15 21:52 UTC (permalink / raw)
To: Greg KH; +Cc: Arjan van de Ven, James Bottomley, Kernel development list
On Wed, 15 Feb 2006, Greg KH wrote:
> On Wed, Feb 15, 2006 at 05:35:08PM +0100, Arjan van de Ven wrote:
> > On Wed, 2006-02-15 at 08:27 -0800, Greg KH wrote:
> > >
> > > Nah, I don't think it's a good idea. James's patch should work just
> > > fine.
> >
> > another option is to have a "kill list" which you put the thing on, and
> > then wake up a thread. only 2 pointers in the object ;(
>
> Hm, that's almost what James's patch is trying to do. Care to mock up a
> patch that shows this? It might be a simpler solution.
It won't work. You might have to do 2 put_device calls on the same
structure. That's why I suggested the "pending puts" counter; something
can't go on a list more than once.
Alan Stern
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [linux-usb-devel] Re: Linux 2.6.16-rc3
2006-02-15 21:52 ` Alan Stern
@ 2006-02-15 21:59 ` Greg KH
2006-02-15 22:25 ` Alan Stern
0 siblings, 1 reply; 104+ messages in thread
From: Greg KH @ 2006-02-15 21:59 UTC (permalink / raw)
To: Alan Stern; +Cc: Arjan van de Ven, James Bottomley, Kernel development list
On Wed, Feb 15, 2006 at 04:52:43PM -0500, Alan Stern wrote:
> On Wed, 15 Feb 2006, Greg KH wrote:
>
> > On Wed, Feb 15, 2006 at 05:35:08PM +0100, Arjan van de Ven wrote:
> > > On Wed, 2006-02-15 at 08:27 -0800, Greg KH wrote:
> > > >
> > > > Nah, I don't think it's a good idea. James's patch should work just
> > > > fine.
> > >
> > > another option is to have a "kill list" which you put the thing on, and
> > > then wake up a thread. only 2 pointers in the object ;(
> >
> > Hm, that's almost what James's patch is trying to do. Care to mock up a
> > patch that shows this? It might be a simpler solution.
>
> It won't work. You might have to do 2 put_device calls on the same
> structure. That's why I suggested the "pending puts" counter; something
> can't go on a list more than once.
It would only go on the list if the "put" was the last one. Otherwise
it would not make any sense to put it on any list.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [linux-usb-devel] Re: Linux 2.6.16-rc3
2006-02-15 21:59 ` Greg KH
@ 2006-02-15 22:25 ` Alan Stern
2006-02-15 22:37 ` Greg KH
0 siblings, 1 reply; 104+ messages in thread
From: Alan Stern @ 2006-02-15 22:25 UTC (permalink / raw)
To: Greg KH; +Cc: Arjan van de Ven, James Bottomley, Kernel development list
On Wed, 15 Feb 2006, Greg KH wrote:
> On Wed, Feb 15, 2006 at 04:52:43PM -0500, Alan Stern wrote:
> > On Wed, 15 Feb 2006, Greg KH wrote:
> >
> > > On Wed, Feb 15, 2006 at 05:35:08PM +0100, Arjan van de Ven wrote:
> > > > On Wed, 2006-02-15 at 08:27 -0800, Greg KH wrote:
> > > > >
> > > > > Nah, I don't think it's a good idea. James's patch should work just
> > > > > fine.
> > > >
> > > > another option is to have a "kill list" which you put the thing on, and
> > > > then wake up a thread. only 2 pointers in the object ;(
> > >
> > > Hm, that's almost what James's patch is trying to do. Care to mock up a
> > > patch that shows this? It might be a simpler solution.
> >
> > It won't work. You might have to do 2 put_device calls on the same
> > structure. That's why I suggested the "pending puts" counter; something
> > can't go on a list more than once.
>
> It would only go on the list if the "put" was the last one. Otherwise
> it would not make any sense to put it on any list.
There's no way to know whether or not any particular "put" is the last
one. So you have to assume they all are.
Alan Stern
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [linux-usb-devel] Re: Linux 2.6.16-rc3
2006-02-15 22:25 ` Alan Stern
@ 2006-02-15 22:37 ` Greg KH
2006-02-15 22:51 ` Alan Stern
0 siblings, 1 reply; 104+ messages in thread
From: Greg KH @ 2006-02-15 22:37 UTC (permalink / raw)
To: Alan Stern; +Cc: Arjan van de Ven, James Bottomley, Kernel development list
On Wed, Feb 15, 2006 at 05:25:37PM -0500, Alan Stern wrote:
> On Wed, 15 Feb 2006, Greg KH wrote:
>
> > On Wed, Feb 15, 2006 at 04:52:43PM -0500, Alan Stern wrote:
> > > On Wed, 15 Feb 2006, Greg KH wrote:
> > >
> > > > On Wed, Feb 15, 2006 at 05:35:08PM +0100, Arjan van de Ven wrote:
> > > > > On Wed, 2006-02-15 at 08:27 -0800, Greg KH wrote:
> > > > > >
> > > > > > Nah, I don't think it's a good idea. James's patch should work just
> > > > > > fine.
> > > > >
> > > > > another option is to have a "kill list" which you put the thing on, and
> > > > > then wake up a thread. only 2 pointers in the object ;(
> > > >
> > > > Hm, that's almost what James's patch is trying to do. Care to mock up a
> > > > patch that shows this? It might be a simpler solution.
> > >
> > > It won't work. You might have to do 2 put_device calls on the same
> > > structure. That's why I suggested the "pending puts" counter; something
> > > can't go on a list more than once.
> >
> > It would only go on the list if the "put" was the last one. Otherwise
> > it would not make any sense to put it on any list.
>
> There's no way to know whether or not any particular "put" is the last
> one. So you have to assume they all are.
The underlying kobject can "know" that the put was the last one, and
handle it differently if needed. Yes, it would not use a kref anymore,
but that might be needed here.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [linux-usb-devel] Re: Linux 2.6.16-rc3
2006-02-15 22:37 ` Greg KH
@ 2006-02-15 22:51 ` Alan Stern
0 siblings, 0 replies; 104+ messages in thread
From: Alan Stern @ 2006-02-15 22:51 UTC (permalink / raw)
To: Greg KH; +Cc: Arjan van de Ven, James Bottomley, Kernel development list
On Wed, 15 Feb 2006, Greg KH wrote:
> > > It would only go on the list if the "put" was the last one. Otherwise
> > > it would not make any sense to put it on any list.
> >
> > There's no way to know whether or not any particular "put" is the last
> > one. So you have to assume they all are.
>
> The underlying kobject can "know" that the put was the last one, and
> handle it differently if needed. Yes, it would not use a kref anymore,
> but that might be needed here.
You would need a kref variant, something which would include room for the
list header and a pointer to the release routine. Okay, that does involve
less time overhead than what I proposed (although the same amount of space
overhead).
Alan Stern
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [linux-usb-devel] Re: Linux 2.6.16-rc3
2006-02-15 16:07 ` [linux-usb-devel] " Alan Stern
2006-02-15 16:27 ` Greg KH
@ 2006-02-15 19:58 ` James Bottomley
2006-02-15 22:24 ` Alan Stern
1 sibling, 1 reply; 104+ messages in thread
From: James Bottomley @ 2006-02-15 19:58 UTC (permalink / raw)
To: Alan Stern; +Cc: Kernel development list, Greg KH
On Wed, 2006-02-15 at 11:07 -0500, Alan Stern wrote:
> Could we perhaps make this safer and more general?
>
> For instance, add to struct device a "pending puts" counter and a list
> header (both protected by a global spinlock), and have a kernel thread
> periodically check the list, doing put_device wherever needed. How does
> that sound?
That's what I've been discussing with Jens elsewhere on this list.
However, I think what you're proposing is overly complex. All we really
need is for a way of flagging a kobject (or kref) so the final put will
be in user context. Then we can use storage within the kobject or
device (or something else) for the purpose.
James
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [linux-usb-devel] Re: Linux 2.6.16-rc3
2006-02-15 19:58 ` James Bottomley
@ 2006-02-15 22:24 ` Alan Stern
0 siblings, 0 replies; 104+ messages in thread
From: Alan Stern @ 2006-02-15 22:24 UTC (permalink / raw)
To: James Bottomley; +Cc: Kernel development list, Greg KH
On Wed, 15 Feb 2006, James Bottomley wrote:
> On Wed, 2006-02-15 at 11:07 -0500, Alan Stern wrote:
> > Could we perhaps make this safer and more general?
> >
> > For instance, add to struct device a "pending puts" counter and a list
> > header (both protected by a global spinlock), and have a kernel thread
> > periodically check the list, doing put_device wherever needed. How does
> > that sound?
>
> That's what I've been discussing with Jens elsewhere on this list.
> However, I think what you're proposing is overly complex. All we really
> need is for a way of flagging a kobject (or kref) so the final put will
> be in user context. Then we can use storage within the kobject or
> device (or something else) for the purpose.
That's more or less what I was suggesting. The problems are: How do you
know which put is the last? (Answer: you don't. So every put has to be
done in process context.) And how do you flag the data structure and tell
some process thread to do the put? (Answer: by putting the object on a
list, as in my suggestion.)
Alan Stern
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Linux 2.6.16-rc3
2006-02-14 16:34 ` James Bottomley
2006-02-15 16:07 ` [linux-usb-devel] " Alan Stern
@ 2006-02-16 1:56 ` James Bottomley
2006-02-16 17:12 ` Russell King
1 sibling, 1 reply; 104+ messages in thread
From: James Bottomley @ 2006-02-16 1:56 UTC (permalink / raw)
To: Greg KH
Cc: Andrew Morton, Linus Torvalds, linux-kernel, Jens Axboe,
Brown, Len, David S. Miller, linux-acpi, linux-usb-devel,
Yu, Luming, Ben Castricum, sanjoy, Helge Hafting, Carlo E. Prelz,
Gerrit Bruchh?user, Nicolas.Mailhot, Jaroslav Kysela,
Takashi Iwai, Patrizio Bassi, Bj?rn Nilsson, Andrey Borzenkov,
P. Christeas, ghrt, jinhong hu, Andrew Vasquez, linux-scsi,
Benjamin LaHaise
On Tue, 2006-02-14 at 10:34 -0600, James Bottomley wrote:
> Well, I can't solve the problem that it requires memory allocation from
> IRQ context to operate. Based on that, it's an unsafe interface. I'm
> going to put it inside SCSI for 2.6.16, since it's better than what we
> have now, but I don't think we can export it globally.
OK, this is what I'm proposing as the device model fix. What it does is
thread context checking APIs throughout the device subsystem. SCSI can
then use it simply via device_put_process_context(). Since we have to
supply the kref_work; I'd plan to do that as an additional element in
struct scsi_device.
This, by itself, won't solve the SCSI target problem, but I plan to fix
that via a device model addition which would have target alloc waiting
around for any deleted targets to disappear.
Since this is planned for post 2.6.16, we have plenty of time to argue
about it.
James
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 6b355bd..4ae42de 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -338,10 +338,10 @@ struct device * get_device(struct device
* put_device - decrement reference count.
* @dev: device in question.
*/
-void put_device(struct device * dev)
+void put_device_process_context(struct device * dev, struct kref_work *work)
{
if (dev)
- kobject_put(&dev->kobj);
+ kobject_put_process_context(&dev->kobj, work);
}
@@ -445,7 +445,7 @@ EXPORT_SYMBOL_GPL(device_register);
EXPORT_SYMBOL_GPL(device_del);
EXPORT_SYMBOL_GPL(device_unregister);
EXPORT_SYMBOL_GPL(get_device);
-EXPORT_SYMBOL_GPL(put_device);
+EXPORT_SYMBOL_GPL(put_device_process_context);
EXPORT_SYMBOL_GPL(device_create_file);
EXPORT_SYMBOL_GPL(device_remove_file);
diff --git a/include/linux/device.h b/include/linux/device.h
index 58df18d..ac9d457 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -396,7 +396,13 @@ extern int (*platform_notify_remove)(str
*
*/
extern struct device * get_device(struct device * dev);
-extern void put_device(struct device * dev);
+extern void put_device_process_context(struct device * dev,
+ struct kref_work *work);
+static inline void put_device(struct device *dev)
+{
+ put_device_process_context(dev, NULL);
+}
+
/* drivers/base/power.c */
diff --git a/include/linux/kobject.h b/include/linux/kobject.h
index 2a8d8da..d079fea 100644
--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -76,7 +76,12 @@ extern int kobject_register(struct kobje
extern void kobject_unregister(struct kobject *);
extern struct kobject * kobject_get(struct kobject *);
-extern void kobject_put(struct kobject *);
+extern void kobject_put_process_context(struct kobject *, struct kref_work *);
+
+static inline void kobject_put(struct kobject *kobj)
+{
+ kobject_put_process_context(kobj, NULL);
+}
extern char * kobject_get_path(struct kobject *, gfp_t);
diff --git a/include/linux/kref.h b/include/linux/kref.h
index 6fee353..16b15db 100644
--- a/include/linux/kref.h
+++ b/include/linux/kref.h
@@ -18,15 +18,29 @@
#ifdef __KERNEL__
#include <linux/types.h>
+#include <linux/workqueue.h>
#include <asm/atomic.h>
struct kref {
atomic_t refcount;
};
+struct kref_work {
+ struct work_struct work;
+ struct kref *kref;
+ void (*release)(struct kref *kref);
+};
+
void kref_init(struct kref *kref);
void kref_get(struct kref *kref);
-int kref_put(struct kref *kref, void (*release) (struct kref *kref));
+int kref_put_process_context(struct kref *kref,
+ void (*release) (struct kref *kref),
+ struct kref_work *work);
+static inline int kref_put(struct kref *kref,
+ void (*release) (struct kref *kref))
+{
+ return kref_put_process_context(kref, release, NULL);
+}
#endif /* __KERNEL__ */
#endif /* _KREF_H_ */
diff --git a/lib/kobject.c b/lib/kobject.c
index efe67fa..6b80c54 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -372,10 +372,10 @@ static void kobject_release(struct kref
*
* Decrement the refcount, and if 0, call kobject_cleanup().
*/
-void kobject_put(struct kobject * kobj)
+void kobject_put_process_context(struct kobject * kobj, struct kref_work *work)
{
if (kobj)
- kref_put(&kobj->kref, kobject_release);
+ kref_put_process_context(&kobj->kref, kobject_release, work);
}
@@ -537,7 +537,7 @@ EXPORT_SYMBOL(kobject_init);
EXPORT_SYMBOL(kobject_register);
EXPORT_SYMBOL(kobject_unregister);
EXPORT_SYMBOL(kobject_get);
-EXPORT_SYMBOL(kobject_put);
+EXPORT_SYMBOL(kobject_put_process_context);
EXPORT_SYMBOL(kobject_add);
EXPORT_SYMBOL(kobject_del);
diff --git a/lib/kref.c b/lib/kref.c
index 0d07cc3..66231cf 100644
--- a/lib/kref.c
+++ b/lib/kref.c
@@ -13,6 +13,7 @@
#include <linux/kref.h>
#include <linux/module.h>
+#include <linux/hardirq.h>
/**
* kref_init - initialize object.
@@ -33,27 +34,47 @@ void kref_get(struct kref *kref)
atomic_inc(&kref->refcount);
}
+static void kref_release_process_context(void *data)
+{
+ struct kref_work *work = data;
+
+ work->release(work->kref);
+}
+
/**
- * kref_put - decrement refcount for object.
+ * kref_put_user - decrement refcount for object and put in user context
* @kref: object.
* @release: pointer to the function that will clean up the object when the
* last reference to the object is released.
* This pointer is required, and it is not acceptable to pass kfree
* in as this function.
+ * @work: pointer to a kref_work used to take the release through user
+ * context (may be null)
*
- * Decrement the refcount, and if 0, call release().
+ * Decrement the refcount, and if 0, call release(). If work is not null
+ * execute release via schedule_work if not in process context.
* Return 1 if the object was removed, otherwise return 0. Beware, if this
* function returns 0, you still can not count on the kref from remaining in
* memory. Only use the return value if you want to see if the kref is now
* gone, not present.
*/
-int kref_put(struct kref *kref, void (*release)(struct kref *kref))
+int kref_put_process_context(struct kref *kref,
+ void (*release)(struct kref *kref),
+ struct kref_work *work)
{
WARN_ON(release == NULL);
WARN_ON(release == (void (*)(struct kref *))kfree);
if (atomic_dec_and_test(&kref->refcount)) {
- release(kref);
+ if (!work || !in_interrupt())
+ release(kref);
+ else {
+ INIT_WORK(&work->work, kref_release_process_context,
+ work);
+ schedule_work(&work->work);
+ }
+
+
return 1;
}
return 0;
@@ -61,4 +82,4 @@ int kref_put(struct kref *kref, void (*r
EXPORT_SYMBOL(kref_init);
EXPORT_SYMBOL(kref_get);
-EXPORT_SYMBOL(kref_put);
+EXPORT_SYMBOL(kref_put_process_context);
^ permalink raw reply related [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3
2006-02-16 1:56 ` James Bottomley
@ 2006-02-16 17:12 ` Russell King
2006-02-16 17:34 ` Stefan Richter
2006-02-16 17:57 ` James Bottomley
0 siblings, 2 replies; 104+ messages in thread
From: Russell King @ 2006-02-16 17:12 UTC (permalink / raw)
To: James Bottomley
Cc: Greg KH, Andrew Morton, Linus Torvalds, linux-kernel, Jens Axboe,
Brown, Len, David S. Miller, linux-acpi, linux-usb-devel,
Yu, Luming, Ben Castricum, sanjoy, Helge Hafting, Carlo E. Prelz,
Gerrit Bruchh?user, Nicolas.Mailhot, Jaroslav Kysela,
Takashi Iwai, Patrizio Bassi, Bj?rn Nilsson, Andrey Borzenkov,
P. Christeas, ghrt, jinhong hu, Andrew Vasquez, linux-scsi,
Benjamin LaHaise
On Wed, Feb 15, 2006 at 08:56:00PM -0500, James Bottomley wrote:
> On Tue, 2006-02-14 at 10:34 -0600, James Bottomley wrote:
> > Well, I can't solve the problem that it requires memory allocation from
> > IRQ context to operate. Based on that, it's an unsafe interface. I'm
> > going to put it inside SCSI for 2.6.16, since it's better than what we
> > have now, but I don't think we can export it globally.
>
> OK, this is what I'm proposing as the device model fix. What it does is
> thread context checking APIs throughout the device subsystem. SCSI can
> then use it simply via device_put_process_context(). Since we have to
> supply the kref_work; I'd plan to do that as an additional element in
> struct scsi_device.
>
> This, by itself, won't solve the SCSI target problem, but I plan to fix
> that via a device model addition which would have target alloc waiting
> around for any deleted targets to disappear.
>
> Since this is planned for post 2.6.16, we have plenty of time to argue
> about it.
This is probably an idiotic question, but if there's something in the
scsi release handler can't be called in non-process context, why can't
scsi queue up the release processing via the work API itself, rather
than having to have this additional code and complexity for everyone?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Linux 2.6.16-rc3
2006-02-16 17:12 ` Russell King
@ 2006-02-16 17:34 ` Stefan Richter
2006-02-16 17:57 ` James Bottomley
1 sibling, 0 replies; 104+ messages in thread
From: Stefan Richter @ 2006-02-16 17:34 UTC (permalink / raw)
To: Russell King
Cc: James Bottomley, Greg KH, Andrew Morton, Linus Torvalds,
linux-kernel, Jens Axboe, Brown, Len, David S. Miller, linux-acpi,
linux-usb-devel, Yu, Luming, Ben Castricum, sanjoy, Helge Hafting,
Carlo E. Prelz, Gerrit Bruchh?user, Nicolas.Mailhot,
Jaroslav Kysela, Takashi Iwai, Patrizio Bassi, Bj?rn Nilsson,
Andrey Borzenkov, P. Christeas, ghrt, jinhong hu, Andrew Vasquez,
linux-scsi, Benjamin LaHaise
Russell King wrote:
> On Wed, Feb 15, 2006 at 08:56:00PM -0500, James Bottomley wrote:
[...]
>>OK, this is what I'm proposing as the device model fix. What it does is
>>thread context checking APIs throughout the device subsystem. SCSI can
>>then use it simply via device_put_process_context().
[...]
>>Since this is planned for post 2.6.16, we have plenty of time to argue
>>about it.
>
> This is probably an idiotic question, but if there's something in the
> scsi release handler can't be called in non-process context, why can't
> scsi queue up the release processing via the work API itself, rather
> than having to have this additional code and complexity for everyone?
Moreover, why are SCSI release handlers called in non-process context in
the first place? IMO the fix should be to make sure that SCSI release
handlers are always called from process context --- by the respective
layers which manage physical devices, i.e. one or more layers beneath
SCSI core.
--
Stefan Richter
-=====-=-==- --=- =----
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Linux 2.6.16-rc3
2006-02-16 17:12 ` Russell King
2006-02-16 17:34 ` Stefan Richter
@ 2006-02-16 17:57 ` James Bottomley
2006-02-16 18:09 ` Russell King
1 sibling, 1 reply; 104+ messages in thread
From: James Bottomley @ 2006-02-16 17:57 UTC (permalink / raw)
To: Russell King
Cc: Greg KH, Andrew Morton, Linus Torvalds, linux-kernel, Jens Axboe,
Brown, Len, David S. Miller, linux-acpi, linux-usb-devel,
Yu, Luming, Ben Castricum, sanjoy, Helge Hafting, Carlo E. Prelz,
Gerrit Bruchh?user, Nicolas.Mailhot, Jaroslav Kysela,
Takashi Iwai, Patrizio Bassi, Bj?rn Nilsson, Andrey Borzenkov,
P. Christeas, ghrt, jinhong hu, Andrew Vasquez, linux-scsi,
Benjamin LaHaise
On Thu, 2006-02-16 at 17:12 +0000, Russell King wrote:
> This is probably an idiotic question, but if there's something in the
> scsi release handler can't be called in non-process context, why can't
> scsi queue up the release processing via the work API itself, rather
> than having to have this additional code and complexity for everyone?
It's because, in order to get a guaranteed single allocation for the
workqueue to execute in user context, I need to know when the release
will be called. The only way to do that is to add the execute in
process context directly to kref_put.
James
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Linux 2.6.16-rc3
2006-02-16 17:57 ` James Bottomley
@ 2006-02-16 18:09 ` Russell King
2006-02-16 18:14 ` James Bottomley
0 siblings, 1 reply; 104+ messages in thread
From: Russell King @ 2006-02-16 18:09 UTC (permalink / raw)
To: James Bottomley
Cc: Greg KH, Andrew Morton, Linus Torvalds, linux-kernel, Jens Axboe,
Brown, Len, David S. Miller, linux-acpi, linux-usb-devel,
Yu, Luming, Ben Castricum, sanjoy, Helge Hafting, Carlo E. Prelz,
Gerrit Bruchh?user, Nicolas.Mailhot, Jaroslav Kysela,
Takashi Iwai, Patrizio Bassi, Bj?rn Nilsson, Andrey Borzenkov,
P. Christeas, ghrt, jinhong hu, Andrew Vasquez, linux-scsi,
Benjamin LaHaise
On Thu, Feb 16, 2006 at 09:57:32AM -0800, James Bottomley wrote:
> On Thu, 2006-02-16 at 17:12 +0000, Russell King wrote:
> > This is probably an idiotic question, but if there's something in the
> > scsi release handler can't be called in non-process context, why can't
> > scsi queue up the release processing via the work API itself, rather
> > than having to have this additional code and complexity for everyone?
>
> It's because, in order to get a guaranteed single allocation for the
> workqueue to execute in user context, I need to know when the release
> will be called. The only way to do that is to add the execute in
> process context directly to kref_put.
Is there something in the driver model which would prevent something
like this?
static void scsi_release_process(void *p)
{
struct my_work *work = p;
struct device *dev = work->dev;
/* destroy dev */
kfree(work);
}
static void scsi_release(struct device *dev)
{
struct my_work *work;
work = kmalloc(sizeof(struct my_work), GFP_ATOMIC);
if (work) {
INIT_WORK(&work->work, scsi_release_process, work);
work->dev = dev;
schedule_work(&work->work);
} else {
printk(KERN_ERR ...);
}
}
where scsi_release() is the function called by the device model on the
last put of a scsi device.
I guess is more or less what you're trying to do invasively via the
driver model.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3
2006-02-16 18:09 ` Russell King
@ 2006-02-16 18:14 ` James Bottomley
2006-02-16 18:18 ` Russell King
0 siblings, 1 reply; 104+ messages in thread
From: James Bottomley @ 2006-02-16 18:14 UTC (permalink / raw)
To: Russell King
Cc: Greg KH, Andrew Morton, Linus Torvalds, linux-kernel, Jens Axboe,
Brown, Len, David S. Miller, linux-acpi, linux-usb-devel,
Yu, Luming, Ben Castricum, sanjoy, Helge Hafting, Carlo E. Prelz,
Gerrit Bruchh?user, Nicolas.Mailhot, Jaroslav Kysela,
Takashi Iwai, Patrizio Bassi, Bj?rn Nilsson, Andrey Borzenkov,
P. Christeas, ghrt, jinhong hu, Andrew Vasquez, linux-scsi,
Benjamin LaHaise
On Thu, 2006-02-16 at 18:09 +0000, Russell King wrote:
> where scsi_release() is the function called by the device model on the
> last put of a scsi device.
>
> I guess is more or less what you're trying to do invasively via the
> driver model.
Yes ... except I think more than just SCSI has the problem (and we
actually have it in more than one release function) so it seems like a
good candidate for a general abstraction.
James
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Linux 2.6.16-rc3
2006-02-16 18:14 ` James Bottomley
@ 2006-02-16 18:18 ` Russell King
2006-02-16 19:09 ` James Bottomley
0 siblings, 1 reply; 104+ messages in thread
From: Russell King @ 2006-02-16 18:18 UTC (permalink / raw)
To: James Bottomley
Cc: Greg KH, Andrew Morton, Linus Torvalds, linux-kernel, Jens Axboe,
Brown, Len, David S. Miller, linux-acpi, linux-usb-devel,
Yu, Luming, Ben Castricum, sanjoy, Helge Hafting, Carlo E. Prelz,
Gerrit Bruchh?user, Nicolas.Mailhot, Jaroslav Kysela,
Takashi Iwai, Patrizio Bassi, Bj?rn Nilsson, Andrey Borzenkov,
P. Christeas, ghrt, jinhong hu, Andrew Vasquez, linux-scsi,
Benjamin LaHaise
On Thu, Feb 16, 2006 at 10:14:31AM -0800, James Bottomley wrote:
> On Thu, 2006-02-16 at 18:09 +0000, Russell King wrote:
> > where scsi_release() is the function called by the device model on the
> > last put of a scsi device.
> >
> > I guess is more or less what you're trying to do invasively via the
> > driver model.
>
> Yes ... except I think more than just SCSI has the problem (and we
> actually have it in more than one release function) so it seems like a
> good candidate for a general abstraction.
Maybe implementing it as a helper function would be the best and
simplest solution?
static void scsi_release(struct device *dev)
{
schedule_release_process(dev, scsi_release_process);
}
where schedule_release_process() contains more or less what I posted
in the previous mailing.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3
2006-02-16 18:18 ` Russell King
@ 2006-02-16 19:09 ` James Bottomley
2006-02-16 20:01 ` Jens Axboe
0 siblings, 1 reply; 104+ messages in thread
From: James Bottomley @ 2006-02-16 19:09 UTC (permalink / raw)
To: Russell King
Cc: Greg KH, Andrew Morton, Linus Torvalds, linux-kernel, Jens Axboe,
Brown, Len, David S. Miller, linux-acpi, linux-usb-devel,
Yu, Luming, Ben Castricum, sanjoy, Helge Hafting, Carlo E. Prelz,
Gerrit Bruchh?user, Nicolas.Mailhot, Jaroslav Kysela,
Takashi Iwai, Patrizio Bassi, Bj?rn Nilsson, Andrey Borzenkov,
P. Christeas, ghrt, jinhong hu, Andrew Vasquez, linux-scsi,
Benjamin LaHaise
On Thu, 2006-02-16 at 18:18 +0000, Russell King wrote:
> Maybe implementing it as a helper function would be the best and
> simplest solution?
>
> static void scsi_release(struct device *dev)
> {
> schedule_release_process(dev, scsi_release_process);
> }
>
> where schedule_release_process() contains more or less what I posted
> in the previous mailing.
That's almost exactly the execute_in_process_context() API that began
this discussion (and which Andi NAK'd). However, it could possibly be
resurrected with the proviso that the caller has to feed in the
workqueue memory. How would people feel about that?
James
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3
2006-02-16 19:09 ` James Bottomley
@ 2006-02-16 20:01 ` Jens Axboe
2006-02-18 0:42 ` James Bottomley
0 siblings, 1 reply; 104+ messages in thread
From: Jens Axboe @ 2006-02-16 20:01 UTC (permalink / raw)
To: James Bottomley
Cc: Russell King, Greg KH, Andrew Morton, Linus Torvalds,
linux-kernel, Brown, Len, David S. Miller, linux-acpi,
linux-usb-devel, Yu, Luming, Ben Castricum, sanjoy, Helge Hafting,
Carlo E. Prelz, Gerrit Bruchh?user, Nicolas.Mailhot,
Jaroslav Kysela, Takashi Iwai, Patrizio Bassi, Bj?rn Nilsson,
Andrey Borzenkov, P. Christeas, ghrt, jinhong hu, Andrew Vasquez,
linux-scsi, Benjamin LaHaise
On Thu, Feb 16 2006, James Bottomley wrote:
> On Thu, 2006-02-16 at 18:18 +0000, Russell King wrote:
> > Maybe implementing it as a helper function would be the best and
> > simplest solution?
> >
> > static void scsi_release(struct device *dev)
> > {
> > schedule_release_process(dev, scsi_release_process);
> > }
> >
> > where schedule_release_process() contains more or less what I posted
> > in the previous mailing.
>
> That's almost exactly the execute_in_process_context() API that began
> this discussion (and which Andi NAK'd). However, it could possibly be
> resurrected with the proviso that the caller has to feed in the
> workqueue memory. How would people feel about that?
That's what I suggested in the first place as well. I still think it's a
good idea, fwiw :)
--
Jens Axboe
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3
2006-02-16 20:01 ` Jens Axboe
@ 2006-02-18 0:42 ` James Bottomley
2006-02-18 1:00 ` Greg KH
` (3 more replies)
0 siblings, 4 replies; 104+ messages in thread
From: James Bottomley @ 2006-02-18 0:42 UTC (permalink / raw)
To: Jens Axboe
Cc: Russell King, Greg KH, Andrew Morton, Linus Torvalds,
linux-kernel, Brown, Len, David S. Miller, linux-acpi,
linux-usb-devel, Yu, Luming, Ben Castricum, sanjoy, Helge Hafting,
Carlo E. Prelz, Gerrit Bruchh?user, Nicolas.Mailhot,
Jaroslav Kysela, Takashi Iwai, Patrizio Bassi, Bj?rn Nilsson,
Andrey Borzenkov, P. Christeas, ghrt, jinhong hu, Andrew Vasquez,
linux-scsi, Benjamin LaHaise
On Thu, 2006-02-16 at 21:01 +0100, Jens Axboe wrote:
> That's what I suggested in the first place as well. I still think it's a
> good idea, fwiw :)
OK smarty pants ... some of us are a bit slower on the uptake. How
about this then. It won't solve the target problem, but it will solve
the device put.
James
[PATCH] add execute_in_process_context() API
We have several points in the SCSI stack (primarily for our device
functions) where we need to guarantee process context, but (given the
place where the last reference was released) we cannot guarantee this.
This API gets around the issue by executing the function directly if
the caller has process context, but scheduling a workqueue to execute
in process context if the caller doesn't have it.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Index: BUILD-2.6/include/linux/workqueue.h
===================================================================
--- BUILD-2.6.orig/include/linux/workqueue.h 2006-02-17 13:02:00.000000000 -0600
+++ BUILD-2.6/include/linux/workqueue.h 2006-02-17 17:57:52.000000000 -0600
@@ -20,6 +20,12 @@
struct timer_list timer;
};
+struct execute_work {
+ struct work_struct work;
+ void (*fn)(void *);
+ void *data;
+};
+
#define __WORK_INITIALIZER(n, f, d) { \
.entry = { &(n).entry, &(n).entry }, \
.func = (f), \
@@ -74,6 +80,8 @@
void cancel_rearming_delayed_work(struct work_struct *work);
void cancel_rearming_delayed_workqueue(struct workqueue_struct *,
struct work_struct *);
+int execute_in_process_context(void (*fn)(void *), void *,
+ struct execute_work *);
/*
* Kill off a pending schedule_delayed_work(). Note that the work callback
Index: BUILD-2.6/kernel/workqueue.c
===================================================================
--- BUILD-2.6.orig/kernel/workqueue.c 2006-02-17 13:02:01.000000000 -0600
+++ BUILD-2.6/kernel/workqueue.c 2006-02-17 18:00:15.000000000 -0600
@@ -27,6 +27,7 @@
#include <linux/cpu.h>
#include <linux/notifier.h>
#include <linux/kthread.h>
+#include <linux/hardirq.h>
/*
* The per-CPU workqueue (if single thread, we always use the first
@@ -476,6 +477,45 @@
}
EXPORT_SYMBOL(cancel_rearming_delayed_work);
+static void execute_in_process_context_work(void *data)
+{
+ void (*fn)(void *data);
+ struct execute_work *ew = data;
+
+ fn = ew->fn;
+ data = ew->data;
+
+ fn(data);
+}
+
+/**
+ * execute_in_process_context - reliably execute the routine with user context
+ * @fn: the function to execute
+ * @data: data to pass to the function
+ *
+ * Executes the function immediately if process context is available,
+ * otherwise schedules the function for delayed execution.
+ *
+ * Returns: 0 - function was executed
+ * 1 - function was scheduled for execution
+ */
+int execute_in_process_context(void (*fn)(void *data), void *data,
+ struct execute_work *ew)
+{
+ if (!in_interrupt()) {
+ fn(data);
+ return 0;
+ }
+
+ INIT_WORK(&ew->work, execute_in_process_context_work, ew);
+ ew->fn = fn;
+ ew->data = data;
+ schedule_work(&ew->work);
+
+ return 1;
+}
+EXPORT_SYMBOL_GPL(execute_in_process_context);
+
int keventd_up(void)
{
return keventd_wq != NULL;
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3
2006-02-18 0:42 ` James Bottomley
@ 2006-02-18 1:00 ` Greg KH
2006-02-18 2:12 ` Roland Dreier
` (2 subsequent siblings)
3 siblings, 0 replies; 104+ messages in thread
From: Greg KH @ 2006-02-18 1:00 UTC (permalink / raw)
To: James Bottomley
Cc: Jens Axboe, Russell King, Andrew Morton, Linus Torvalds,
linux-kernel, Brown, Len, David S. Miller, linux-acpi,
linux-usb-devel, Yu, Luming, Ben Castricum, sanjoy, Helge Hafting,
Carlo E. Prelz, Gerrit Bruchh?user, Nicolas.Mailhot,
Jaroslav Kysela, Takashi Iwai, Patrizio Bassi, Bj?rn Nilsson,
Andrey Borzenkov, P. Christeas, ghrt, jinhong hu, Andrew Vasquez,
linux-scsi, Benjamin LaHaise
On Fri, Feb 17, 2006 at 04:42:43PM -0800, James Bottomley wrote:
> On Thu, 2006-02-16 at 21:01 +0100, Jens Axboe wrote:
> > That's what I suggested in the first place as well. I still think it's a
> > good idea, fwiw :)
>
> OK smarty pants ... some of us are a bit slower on the uptake. How
> about this then. It won't solve the target problem, but it will solve
> the device put.
>
> James
>
> [PATCH] add execute_in_process_context() API
I like it, nice job.
Acked-by: Greg Kroah-Hartma <gregkh@suse.de>
thanks,
greg k-h
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3
2006-02-18 0:42 ` James Bottomley
2006-02-18 1:00 ` Greg KH
@ 2006-02-18 2:12 ` Roland Dreier
2006-02-18 10:03 ` [linux-usb-devel] " Sergey Vlasov
2006-02-18 20:16 ` Alan Stern
3 siblings, 0 replies; 104+ messages in thread
From: Roland Dreier @ 2006-02-18 2:12 UTC (permalink / raw)
To: James Bottomley
Cc: Jens Axboe, Russell King, Greg KH, Andrew Morton, Linus Torvalds,
linux-kernel, Brown, Len, David S. Miller, linux-acpi,
linux-usb-devel, Yu, Luming, Ben Castricum, sanjoy, Helge Hafting,
Carlo E. Prelz, Gerrit Bruchh?user, Nicolas.Mailhot,
Jaroslav Kysela, Takashi Iwai, Patrizio Bassi, Bj?rn Nilsson,
Andrey Borzenkov, P. Christeas, ghrt, jinhong hu, Andrew Vasquez,
linux-scsi, Benjamin LaHaise
> +/**
> + * execute_in_process_context - reliably execute the routine with user context
> + * @fn: the function to execute
> + * @data: data to pass to the function
> + *
> + * Executes the function immediately if process context is available,
> + * otherwise schedules the function for delayed execution.
> + *
> + * Returns: 0 - function was executed
> + * 1 - function was scheduled for execution
> + */
> +int execute_in_process_context(void (*fn)(void *data), void *data,
> + struct execute_work *ew)
> +{
> + if (!in_interrupt()) {
> + fn(data);
> + return 0;
> + }
Is testing in_interrupt() really sufficient to make this work? I seem
to remember that (at least) with CONFIG_PREEMPT disabled, there are
contexts where it is not safe to sleep but where both in_interrupt()
and in_atomic() still return 0.
- R.
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [linux-usb-devel] Re: Linux 2.6.16-rc3
2006-02-18 0:42 ` James Bottomley
2006-02-18 1:00 ` Greg KH
2006-02-18 2:12 ` Roland Dreier
@ 2006-02-18 10:03 ` Sergey Vlasov
2006-02-19 14:30 ` James Bottomley
2006-02-18 20:16 ` Alan Stern
3 siblings, 1 reply; 104+ messages in thread
From: Sergey Vlasov @ 2006-02-18 10:03 UTC (permalink / raw)
To: James Bottomley
Cc: Jens Axboe, Russell King, Greg KH, Andrew Morton, Linus Torvalds,
linux-kernel, Brown, Len, David S. Miller, linux-acpi,
linux-usb-devel, Yu, Luming, Ben Castricum, sanjoy, Helge Hafting,
Carlo E. Prelz, Gerrit Bruchh?user, Nicolas.Mailhot,
Jaroslav Kysela, Takashi Iwai, Patrizio Bassi, Bj?rn Nilsson,
Andrey Borzenkov, P. Christeas, ghrt, jinhong hu, Andrew Vasquez,
linux-scsi, Benjamin LaHaise
[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]
On Fri, Feb 17, 2006 at 04:42:43PM -0800, James Bottomley wrote:
> +static void execute_in_process_context_work(void *data)
> +{
> + void (*fn)(void *data);
> + struct execute_work *ew = data;
> +
> + fn = ew->fn;
> + data = ew->data;
> +
> + fn(data);
> +}
After removing kfree(), which was here in the initial implementation,
this function became a thunk which does nothing useful - we can just
stick fn and data directly into work_struct.
> +
> +/**
> + * execute_in_process_context - reliably execute the routine with user context
> + * @fn: the function to execute
> + * @data: data to pass to the function
> + *
> + * Executes the function immediately if process context is available,
> + * otherwise schedules the function for delayed execution.
> + *
> + * Returns: 0 - function was executed
> + * 1 - function was scheduled for execution
> + */
> +int execute_in_process_context(void (*fn)(void *data), void *data,
> + struct execute_work *ew)
> +{
> + if (!in_interrupt()) {
> + fn(data);
> + return 0;
> + }
> +
> + INIT_WORK(&ew->work, execute_in_process_context_work, ew);
> + ew->fn = fn;
> + ew->data = data;
> + schedule_work(&ew->work);
> +
> + return 1;
> +}
Then this becomes:
int execute_in_process_context(void (*fn)(void *data), void *data,
struct work_struct *work)
{
if (!in_interrupt()) {
fn(data);
return 0;
}
INIT_WORK(work, fn, data);
schedule_work(work);
return 1;
}
(and struct execute_work is no longer needed).
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [linux-usb-devel] Re: Linux 2.6.16-rc3
2006-02-18 10:03 ` [linux-usb-devel] " Sergey Vlasov
@ 2006-02-19 14:30 ` James Bottomley
2006-02-23 18:43 ` James Bottomley
0 siblings, 1 reply; 104+ messages in thread
From: James Bottomley @ 2006-02-19 14:30 UTC (permalink / raw)
To: Sergey Vlasov
Cc: Jens Axboe, Russell King, Greg KH, Andrew Morton, Linus Torvalds,
linux-kernel, Brown, Len, David S. Miller, linux-acpi,
linux-usb-devel, Yu, Luming, Ben Castricum, sanjoy, Helge Hafting,
Carlo E. Prelz, Gerrit Bruchh?user, Nicolas.Mailhot,
Jaroslav Kysela, Takashi Iwai, Patrizio Bassi, Bj?rn Nilsson,
Andrey Borzenkov, P. Christeas, ghrt, jinhong hu, Andrew Vasquez,
linux-scsi, Benjamin LaHaise
On Sat, 2006-02-18 at 13:03 +0300, Sergey Vlasov wrote:
> After removing kfree(), which was here in the initial implementation,
> this function became a thunk which does nothing useful - we can just
> stick fn and data directly into work_struct.
Yes, thanks ... although I think there's still value to wrappering
work_struct (a bit like kref wrappers atomic_t).
James
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [linux-usb-devel] Re: Linux 2.6.16-rc3
2006-02-19 14:30 ` James Bottomley
@ 2006-02-23 18:43 ` James Bottomley
0 siblings, 0 replies; 104+ messages in thread
From: James Bottomley @ 2006-02-23 18:43 UTC (permalink / raw)
To: Sergey Vlasov
Cc: Jens Axboe, Russell King, Greg KH, Andrew Morton, Linus Torvalds,
linux-kernel, Brown, Len, David S. Miller, linux-acpi,
linux-usb-devel, Yu, Luming, Ben Castricum, sanjoy, Helge Hafting,
Carlo E. Prelz, Gerrit Bruchh?user, Nicolas.Mailhot,
Jaroslav Kysela, Takashi Iwai, Patrizio Bassi, Bj?rn Nilsson,
Andrey Borzenkov, P. Christeas, ghrt, jinhong hu, Andrew Vasquez,
linux-scsi, Benjamin LaHaise
On Sun, 2006-02-19 at 08:30 -0600, James Bottomley wrote:
> Yes, thanks ... although I think there's still value to wrappering
> work_struct (a bit like kref wrappers atomic_t).
OK, so how about this?
James
[PATCH] add execute_in_process_context() API
We have several points in the SCSI stack (primarily for our device
functions) where we need to guarantee process context, but (given the
place where the last reference was released) we cannot guarantee this.
This API gets around the issue by executing the function directly if
the caller has process context, but scheduling a workqueue to execute
in process context if the caller doesn't have it.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Index: BUILD-2.6/include/linux/workqueue.h
===================================================================
--- BUILD-2.6.orig/include/linux/workqueue.h 2006-02-20 08:57:43.000000000 -0600
+++ BUILD-2.6/include/linux/workqueue.h 2006-02-20 08:58:34.000000000 -0600
@@ -20,6 +20,10 @@
struct timer_list timer;
};
+struct execute_work {
+ struct work_struct work;
+};
+
#define __WORK_INITIALIZER(n, f, d) { \
.entry = { &(n).entry, &(n).entry }, \
.func = (f), \
@@ -74,6 +78,8 @@
void cancel_rearming_delayed_work(struct work_struct *work);
void cancel_rearming_delayed_workqueue(struct workqueue_struct *,
struct work_struct *);
+int execute_in_process_context(void (*fn)(void *), void *,
+ struct execute_work *);
/*
* Kill off a pending schedule_delayed_work(). Note that the work callback
Index: BUILD-2.6/kernel/workqueue.c
===================================================================
--- BUILD-2.6.orig/kernel/workqueue.c 2006-02-20 08:57:43.000000000 -0600
+++ BUILD-2.6/kernel/workqueue.c 2006-02-20 08:59:18.000000000 -0600
@@ -27,6 +27,7 @@
#include <linux/cpu.h>
#include <linux/notifier.h>
#include <linux/kthread.h>
+#include <linux/hardirq.h>
/*
* The per-CPU workqueue (if single thread, we always use the first
@@ -476,6 +477,34 @@
}
EXPORT_SYMBOL(cancel_rearming_delayed_work);
+/**
+ * execute_in_process_context - reliably execute the routine with user context
+ * @fn: the function to execute
+ * @data: data to pass to the function
+ * @ew: guaranteed storage for the execute work structure (must
+ * be available when the work executes)
+ *
+ * Executes the function immediately if process context is available,
+ * otherwise schedules the function for delayed execution.
+ *
+ * Returns: 0 - function was executed
+ * 1 - function was scheduled for execution
+ */
+int execute_in_process_context(void (*fn)(void *data), void *data,
+ struct execute_work *ew)
+{
+ if (!in_interrupt()) {
+ fn(data);
+ return 0;
+ }
+
+ INIT_WORK(&ew->work, fn, data);
+ schedule_work(&ew->work);
+
+ return 1;
+}
+EXPORT_SYMBOL_GPL(execute_in_process_context);
+
int keventd_up(void)
{
return keventd_wq != NULL;
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [linux-usb-devel] Re: Linux 2.6.16-rc3
2006-02-18 0:42 ` James Bottomley
` (2 preceding siblings ...)
2006-02-18 10:03 ` [linux-usb-devel] " Sergey Vlasov
@ 2006-02-18 20:16 ` Alan Stern
2006-02-19 13:51 ` James Bottomley
3 siblings, 1 reply; 104+ messages in thread
From: Alan Stern @ 2006-02-18 20:16 UTC (permalink / raw)
To: James Bottomley
Cc: Jens Axboe, Russell King, Greg KH, Andrew Morton, Linus Torvalds,
linux-kernel, Brown, Len, David S. Miller, linux-acpi,
linux-usb-devel, Yu, Luming, Ben Castricum, sanjoy, Helge Hafting,
Carlo E. Prelz, Gerrit Bruchh?user, Nicolas.Mailhot,
Jaroslav Kysela, Takashi Iwai, Patrizio Bassi, Bj?rn Nilsson,
Andrey Borzenkov, P. Christeas, ghrt, jinhong hu, Andrew Vasquez,
linux-scsi, Benjamin LaHaise
On Fri, 17 Feb 2006, James Bottomley wrote:
> +/**
> + * execute_in_process_context - reliably execute the routine with user context
> + * @fn: the function to execute
> + * @data: data to pass to the function
> + *
> + * Executes the function immediately if process context is available,
> + * otherwise schedules the function for delayed execution.
> + *
> + * Returns: 0 - function was executed
> + * 1 - function was scheduled for execution
> + */
> +int execute_in_process_context(void (*fn)(void *data), void *data,
> + struct execute_work *ew)
> +{
> + if (!in_interrupt()) {
> + fn(data);
> + return 0;
> + }
The test should be in_atomic(), not in_interrupt().
Alan Stern
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [linux-usb-devel] Re: Linux 2.6.16-rc3
2006-02-18 20:16 ` Alan Stern
@ 2006-02-19 13:51 ` James Bottomley
0 siblings, 0 replies; 104+ messages in thread
From: James Bottomley @ 2006-02-19 13:51 UTC (permalink / raw)
To: Alan Stern
Cc: Jens Axboe, Russell King, Greg KH, Andrew Morton, Linus Torvalds,
linux-kernel, Brown, Len, David S. Miller, linux-acpi,
linux-usb-devel, Yu, Luming, Ben Castricum, sanjoy, Helge Hafting,
Carlo E. Prelz, Gerrit Bruchh?user, Nicolas.Mailhot,
Jaroslav Kysela, Takashi Iwai, Patrizio Bassi, Bj?rn Nilsson,
Andrey Borzenkov, P. Christeas, ghrt, jinhong hu, Andrew Vasquez,
linux-scsi, Benjamin LaHaise
On Sat, 2006-02-18 at 15:16 -0500, Alan Stern wrote:
> The test should be in_atomic(), not in_interrupt().
There's a long prior discussion of why it has to be in_interrupt()
James
^ permalink raw reply [flat|nested] 104+ messages in thread
* [PATCH] x86: fix oprofile kernel callgraph regression
2006-02-13 3:05 ` Andrew Morton
` (12 preceding siblings ...)
2006-02-13 20:38 ` Greg KH
@ 2006-02-14 15:19 ` Gerald Britton
2006-02-14 15:58 ` Hugh Dickins
2006-02-18 21:06 ` Linux 2.6.16-rc3 Helge Hafting
2006-02-22 16:49 ` Ben Castricum
15 siblings, 1 reply; 104+ messages in thread
From: Gerald Britton @ 2006-02-14 15:19 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds, Hugh Dickins, phil.el, gbritton
Cc: linux-kernel, oprofile-list
Fix x86 oprofile regression introduced by:
commit c34d1b4d165c67b966bca4aba026443d7ff161eb
[PATCH] mm: kill check_user_page_readable
That commit reorganized tests for the userspace stack walking moving all
those tests into dump_backtrace(), however, dump_backtrace() was used for
both userspace and kernel stalk walking. The result is typically no
recorded callgraph information for kernel samples.
Revive the original function as dump_kernel_backtrace() and rename the
other to dump_user_backtrace() to avoid future confusion.
Signed-off-by: Gerald Britton <gbritton@alum.mit.edu>
---
backtrace.c | 19 ++++++++++++++++---
1 files changed, 16 insertions(+), 3 deletions(-)
--- a/arch/i386/oprofile/backtrace.c 2006-02-13 19:27:40.000000000 -0500
+++ b/arch/i386/oprofile/backtrace.c 2006-02-13 19:30:32.000000000 -0500
@@ -20,7 +20,20 @@ struct frame_head {
} __attribute__((packed));
static struct frame_head *
-dump_backtrace(struct frame_head * head)
+dump_kernel_backtrace(struct frame_head * head)
+{
+ oprofile_add_trace(head->ret);
+
+ /* frame pointers should strictly progress back up the stack
+ * (towards higher addresses) */
+ if (head >= head->ebp)
+ return NULL;
+
+ return head->ebp;
+}
+
+static struct frame_head *
+dump_user_backtrace(struct frame_head * head)
{
struct frame_head bufhead[2];
@@ -105,10 +118,10 @@ x86_backtrace(struct pt_regs * const reg
if (!user_mode_vm(regs)) {
while (depth-- && valid_kernel_stack(head, regs))
- head = dump_backtrace(head);
+ head = dump_kernel_backtrace(head);
return;
}
while (depth-- && head)
- head = dump_backtrace(head);
+ head = dump_user_backtrace(head);
}
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: [PATCH] x86: fix oprofile kernel callgraph regression
2006-02-14 15:19 ` [PATCH] x86: fix oprofile kernel callgraph regression Gerald Britton
@ 2006-02-14 15:58 ` Hugh Dickins
0 siblings, 0 replies; 104+ messages in thread
From: Hugh Dickins @ 2006-02-14 15:58 UTC (permalink / raw)
To: Gerald Britton
Cc: Andrew Morton, Linus Torvalds, phil.el, linux-kernel,
oprofile-list
On Tue, 14 Feb 2006, Gerald Britton wrote:
> Fix x86 oprofile regression introduced by:
> commit c34d1b4d165c67b966bca4aba026443d7ff161eb
> [PATCH] mm: kill check_user_page_readable
>
> That commit reorganized tests for the userspace stack walking moving all
> those tests into dump_backtrace(), however, dump_backtrace() was used for
> both userspace and kernel stalk walking. The result is typically no
> recorded callgraph information for kernel samples.
>
> Revive the original function as dump_kernel_backtrace() and rename the
> other to dump_user_backtrace() to avoid future confusion.
>
> Signed-off-by: Gerald Britton <gbritton@alum.mit.edu>
Apology-from: Hugh Dickins <hugh@veritas.com>
^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: Linux 2.6.16-rc3
2006-02-13 3:05 ` Andrew Morton
` (13 preceding siblings ...)
2006-02-14 15:19 ` [PATCH] x86: fix oprofile kernel callgraph regression Gerald Britton
@ 2006-02-18 21:06 ` Helge Hafting
2006-02-22 16:49 ` Ben Castricum
15 siblings, 0 replies; 104+ messages in thread
From: Helge Hafting @ 2006-02-18 21:06 UTC (permalink / raw)
To: Andrew Morton
Cc: Linus Torvalds, linux-kernel, Jens Axboe, James Bottomley,
Brown, Len, David S. Miller, Greg KH, linux-acpi, linux-usb-devel,
Yu, Luming, Ben Castricum, sanjoy, Helge Hafting, Carlo E. Prelz,
Gerrit Bruchhäuser, Nicolas.Mailhot, Jaroslav Kysela,
Takashi Iwai, Patrizio Bassi, Björn Nilsson,
Andrey Borzenkov, P. Christeas, ghrt, jinhong hu, Andrew Vasquez,
linux-scsi, Benjamin LaHaise
Andrew Morton wrote:
>We still have some serious bugs, several of which are in 2.6.15 as well:
>
[...]
>- Helge Hafting reports a usb printer regression - I don't know if that's
> still live?
>
>
I tried printing four pages of graphichs with 2.6.16-rc3-mm1
and it worked fine. When I had the problem I couldn't even print
three, I had to print the 10 pages I needed one by one.
So I believe the situation has improved.
Helge Hafting
^ permalink raw reply [flat|nested] 104+ messages in thread* Re: Linux 2.6.16-rc3
2006-02-13 3:05 ` Andrew Morton
` (14 preceding siblings ...)
2006-02-18 21:06 ` Linux 2.6.16-rc3 Helge Hafting
@ 2006-02-22 16:49 ` Ben Castricum
15 siblings, 0 replies; 104+ messages in thread
From: Ben Castricum @ 2006-02-22 16:49 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds
Cc: linux-kernel, Jens Axboe, James Bottomley, Brown, Len,
David S. Miller, Greg KH, Yu, Luming, Ben Castricum, sanjoy,
Helge Hafting, Carlo E. Prelz, Gerrit Bruchhäuser,
Nicolas.Mailhot, Jaroslav Kysela, Takashi Iwai, Patrizio Bassi,
Björn Nilsson, Andrey Borzenkov, P. Christeas, ghrt,
jinhong hu, Andrew Vasquez, Benjamin LaHaise
> We still have some serious bugs, several of which are in 2.6.15 as well:
> [...]
> - "Ben Castricum" <lk@bencastricum.nl> reports that ppp has started
> exhibiting mysterious failures (again).
I found the time to do some more testing, this time with the latest
2.6.16-rc4 from git and still pppd version 2.4.1.
The problem was very easy to reproduce, within 10 minutes I appeared again.
I could narrow the problem down to not being able to _send_ traffic.
Ifconfig -a and tcpdump showed traffic coming in, but not going out. I tried
stracing the relevant programs (I use pptp to connect to the dsl modem)
root@gateway:~# ps -ef | grep pp
root 870 1 0 16:47 ? 00:00:00 /usr/sbin/upnpd ppp0 eth1
root 329 1 0 16:45 ? 00:00:00 /usr/sbin/pptp pptp: call
manager for 10.0.0.138
root 323 322 0 16:45 ? 00:00:14 /usr/sbin/pptp pptp:
GRE-to-PPP gateway on /dev/ptmx
root 322 1 0 16:45 ? 00:00:00 /usr/sbin/pppd call adsl
root 3156 2941 0 17:15 pts/2 00:00:00 grep pp
root@gateway:~# strace -p 322
select(4, [0 3], NULL, [0 3], NULL <unfinished ...>
(nothing happening there)
root@gateway:~# strace -p 323
write(4, " \201\210\v\0\0\0\0\0\2\320X", 12) = 12
select(5, [0 4], NULL, NULL, NULL) = 1 (in [4])
read(4, "E\0\0`\36P\0\0@/G\225\n\0\0\212\n\0\0\0010\1\210\v\0@\0"..., 8260)
= 96
write(0, "\377\3\0!E\0\0< \211@\0(\6\27\336\310\256\260\215\325T"..., 64) =
64
select(5, [0 4], NULL, NULL, {0, 500000}) = 1 (in [4], left {0, 488000})
read(4, "E\0\0T\36Q\0\0@/G\240\n\0\0\212\n\0\0\0010\1\210\v\000"..., 8260) =
84
write(0, "\377\3\0!E\0\0000_E@\0w\6\320rRH\340\256\325T\313\304\20"..., 52)
= 52
select(5, [0 4], NULL, NULL, {0, 0}) = 0 (Timeout)
write(4, " \201\210\v\0\0\0\0\0\2\320Z", 12) = 12
select(5, [0 4], NULL, NULL, NULL) = 1 (in [4])
read(4, "E\0\0T\36R\0\0@/G\237\n\0\0\212\n\0\0\0010\1\210\v\000"..., 8260) =
84
write(0, "\377\3\0!E\0\0000_F@\0w\6\320qRH\340\256\325T\313\304\20"..., 52)
= 52
select(5, [0 4], NULL, NULL, {0, 500000}) = 1 (in [4], left {0, 472000})
read(4, "E\0\0T\36S\0\0@/G\236\n\0\0\212\n\0\0\0010\1\210\v\000"..., 8260) =
84
write(0, "\377\3\0!E\0\0000\21\223@\0q\6\205\\P\313\200\364\325T"..., 52) =
52
select(5, [0 4], NULL, NULL, {0, 0}) = 0 (Timeout)
write(4, " \201\210\v\0\0\0\0\0\2\320\\", 12) = 12
select(5, [0 4], NULL, NULL, NULL) = 1 (in [4])
read(4, "E\0\0T\36T\0\0@/G\235\n\0\0\212\n\0\0\0010\1\210\v\000"..., 8260) =
84
write(0, "\377\3\0!E\0\0000C\2@\0h\6\17\233\311\307UJ\325T\313\304"..., 52)
= 52
select(5, [0 4], NULL, NULL, {0, 500000}) = 1 (in [4], left {0, 496000})
read(4, "E\0\0`\36U\0\0@/G\220\n\0\0\212\n\0\0\0010\1\210\v\0@\0"..., 8260)
= 96
write(0, "\377\3\0!E\0\0<0e@\0003\6\4T\303\200\256i\325T\313\304"..., 64) =
64
select(5, [0 4], NULL, NULL, {0, 0}) = 0 (Timeout)
write(4, " \201\210\v\0\0\0\0\0\2\320^", 12) = 12
select(5, [0 4], NULL, NULL, NULL) = 1 (in [4])
read(4, "E\0\0d\36V\0\0@/G\213\n\0\0\212\n\0\0\0010\1\210\v\0D\0"..., 8260)
= 100
write(0, "\377\3\0!E\0\0@:S\0\0003\6\203Y\311\32_\330\325T\313\304"..., 68)
= 68
select(5, [0 4], NULL, NULL, {0, 500000}) = 1 (in [4], left {0, 484000})
read(4, "E\0\0`\36W\0\0@/G\216\n\0\0\212\n\0\0\0010\1\210\v\0@\0"..., 8260)
= 96
write(0, "\377\3\0!E\0\0<\275\240@\0%\6\24\355\310\320\31E\325T\313"..., 64)
= 64
select(5, [0 4], NULL, NULL, {0, 0}) = 0 (Timeout)
write(4, " \201\210\v\0\0\0\0\0\2\320`", 12) = 12
select(5, [0 4], NULL, NULL, NULL) = 1 (in [4])
read(4, "E\0\0d\36X\0\0@/G\211\n\0\0\212\n\0\0\0010\1\210\v\0D\0"..., 8260)
= 100
write(0, "\377\3\0!E\0\0@a\264\0\0003\6\250\345\311\374\22\t\325"..., 68) =
68
select(5, [0 4], NULL, NULL, {0, 500000}) = 1 (in [4], left {0, 496000})
read(4, "E\0\0d\36Y\0\0@/G\210\n\0\0\212\n\0\0\0010\1\210\v\0D\0"..., 8260)
= 100
write(0, "\377\3\0!E\0\0@j\217\0\0003\6\272\317\310\350\370W\325"..., 68) =
68
select(5, [0 4], NULL, NULL, {0, 0}) = 0 (Timeout)
write(4, " \201\210\v\0\0\0\0\0\2\320b", 12) = 12
select(5, [0 4], NULL, NULL, NULL) = 1 (in [4])
read(4, "E\0\0T\36Z\0\0@/G\227\n\0\0\212\n\0\0\0010\1\210\v\000"..., 8260) =
84
write(0, "\377\3\0!E\0\0000\26\217@\0p\6\375o\310\251\215\6\325T"..., 52) =
52
select(5, [0 4], NULL, NULL, {0, 500000}) = 1 (in [4], left {0, 440000})
read(4, "E\0\0T\36[\0\0@/G\226\n\0\0\212\n\0\0\0010\1\210\v\000"..., 8260) =
84
write(0, "\377\3\0!E\0\0000\3672@\0o\6[-\310\264O\232\325T\313\304"..., 52)
= 52
select(5, [0 4], NULL, NULL, {0, 0}) = 0 (Timeout)
write(4, " \201\210\v\0\0\0\0\0\2\320d", 12) = 12
select(5, [0 4], NULL, NULL, NULL <unfinished ...>
(and so on...)
root@gateway:~# strace -p 329
select(7, [3 4 6], [], NULL, NULL <unfinished ...>
nothing hapening here either.
checking the iptables setup (I flushed the rules before I started with
troubleshooting):
root@gateway:~# iptables-save
# Generated by iptables-save v1.2.6a on Wed Feb 22 17:10:44 2006
*filter
:INPUT ACCEPT [6204:440626]
:FORWARD ACCEPT [8:284]
:OUTPUT ACCEPT [18978:2854072]
COMMIT
# Completed on Wed Feb 22 17:10:44 2006
# Generated by iptables-save v1.2.6a on Wed Feb 22 17:10:44 2006
*nat
:PREROUTING ACCEPT [44153:2316103]
:POSTROUTING ACCEPT [805:50699]
:OUTPUT ACCEPT [2308:153409]
COMMIT
# Completed on Wed Feb 22 17:10:44 2006
root@gateway:~# iptables-save
# Generated by iptables-save v1.2.6a on Wed Feb 22 17:10:48 2006
*filter
:INPUT ACCEPT [6721:478137]
:FORWARD ACCEPT [8:284]
:OUTPUT ACCEPT [20528:3083677]
COMMIT
# Completed on Wed Feb 22 17:10:48 2006
# Generated by iptables-save v1.2.6a on Wed Feb 22 17:10:48 2006
*nat
:PREROUTING ACCEPT [44241:2320941]
:POSTROUTING ACCEPT [806:50777]
:OUTPUT ACCEPT [2309:153487]
COMMIT
# Completed on Wed Feb 22 17:10:48 2006
Does this help anything?
Kind regards,
Ben
^ permalink raw reply [flat|nested] 104+ messages in thread
