Bug 6024 - USB stays in state D3 after suspend to mem
USB stays in state D3 after suspend to mem
Product: ACPI
Classification: Unclassified
Component: Power-Sleep-Wake
i386 Linux
: P2 normal
Assigned To: Shaohua
Depends on:
  Show dependency treegraph
Reported: 2006-02-07 01:35 UTC by Tim Dijkstra
Modified: 2007-04-28 12:49 UTC (History)
2 users (show)

See Also:
Kernel Version:
Tree: Mainline
Regression: ---

lspci -vvv (6.89 KB, text/plain)
2006-02-07 01:36 UTC, Tim Dijkstra
workaround (611 bytes, patch)
2006-02-13 19:05 UTC, Shaohua
Details | Diff
log of suspend /w module (3.59 KB, text/plain)
2006-02-15 01:36 UTC, Tim Dijkstra
log of suspend without module (10.45 KB, text/plain)
2006-02-15 01:39 UTC, Tim Dijkstra
log of suspend without module (9.44 KB, text/plain)
2006-02-15 11:19 UTC, Tim Dijkstra
acpidump (48.51 KB, text/plain)
2006-02-15 11:22 UTC, Tim Dijkstra
log of suspend /w module (5.34 KB, text/plain)
2006-02-15 11:38 UTC, Tim Dijkstra
lspic -vvv (8.95 KB, text/plain)
2006-02-16 12:16 UTC, Tim Dijkstra

Description Tim Dijkstra 2006-02-07 01:35:31 UTC
Most recent kernel where this bug did not occur: Before suspend didn't work at all
Distribution: Debian
Hardware Environment: A7V8X motherboard (VT8235 PCI Bridge, VT82xxxxx UHCI USB
1.1 Controller)
Software Environment: Vanilla kernel, Bare system, Debian sarge
Problem Description:

If I try to go to S3 (echo mem > /sys/power/state), with the uhci_hcd
modules loaded everything seems to go fine except that there's an immediate

[As an asside; I wonder if that has something to do with USB* being ACPI wakeup

Feb  2 20:09:54 commensaal kernel: ACPI wakeup devices:
Feb  2 20:09:54 commensaal kernel: PCI0 PCI1 USB0 USB1 USB2 SU20  LAN ]

Anyway, I tried to work around that problem by rmmod'ing uhci_hcd before
suspend, and modprobing afterwards. This seems to work except that
everything having to do with USB being really slow (I have a CF-reader
that takes ages to mount, and then is really slow in transfer speed.)

Now if use pci-config (it's by  Donald Becker, http://www.scyld.com/diag/index.html)
to check the status, it tells me that the device is in state D3.

If I check /sys/bus/usb/..../power/state it contains 0.

Now this program also has a --wake option, so I was adventurous and
tried it on the usb devices. And that helped! pci-config reports state
D0 and my CF-reader works at full speed!
Comment 1 Tim Dijkstra 2006-02-07 01:36:44 UTC
Created attachment 7263 [details]
lspci -vvv

lspci -vvv of my box
Comment 2 Shaohua 2006-02-13 19:05:13 UTC
Created attachment 7314 [details]

I guess this workaround can automatically switch the device to D0 state after
you reload the driver at resume time.
But the real issue of your problem is why your system has an immediate resume.
So I'd like look at your acpidmp out. Thanks!
Comment 3 Tim Dijkstra 2006-02-15 01:33:55 UTC
OK, I'll try make an acpidmp tonight. For now I'll attach two logs, one of a
suspend-resume cycle with uhci_usb loaded and one without.
Comment 4 Tim Dijkstra 2006-02-15 01:36:49 UTC
Created attachment 7336 [details]
log of suspend /w module

Log of echo > /sys/power/state with uhci_usb loaded. This resumes immediately.
Comment 5 Tim Dijkstra 2006-02-15 01:39:02 UTC
Created attachment 7337 [details]
log of suspend without module

This is a log of 
rmmod uhci_usb
echo mem > /sys/power/state 
modprobe uhci_usb

Note ACPI complaining about "Device is not power manageable". That could well
the root of the problem.
Comment 6 Tim Dijkstra 2006-02-15 11:19:38 UTC
Created attachment 7352 [details]
log of suspend without module

This is a log of suspend to RAM without uhci_usb loaded, but now with debug
messages included.
Comment 7 Tim Dijkstra 2006-02-15 11:22:00 UTC
Created attachment 7353 [details]

This a dump made with the acpidump utility from pmtools. I think this is what
you want. If not, tell me.
Comment 8 Tim Dijkstra 2006-02-15 11:38:40 UTC
Created attachment 7355 [details]
log of suspend /w module

This is a log of suspend to RAM wit uhci_usb loaded, but now with debug
messages included.
Comment 9 Alan Stern 2006-02-15 14:41:12 UTC
Please run "lspci -vvv" again, but this time run it as root.  Your earlier
attachment doesn't include the PCI capabilities.

When uhci-hcd is unloaded, the USB stack is out of the picture.  Any
suspend/resume processing is done by the PCI core.  I don't know how it handles
driverless devices...  Maybe it puts them into D3 during suspend and just leaves
them there during resume.  "lspci -vvv" as root will show device's current power
Comment 10 Shaohua 2006-02-15 16:54:28 UTC
Does the workaround in comment #2 change anything?
If it works, I think we should push it to base kernel, because it's likely 
modules are unloaded/reloaded before/after suspend.
Comment 11 Tim Dijkstra 2006-02-16 12:16:02 UTC
Created attachment 7372 [details]
lspic -vvv

Again lspci -vvv but now with root priv's
Comment 12 Tim Dijkstra 2006-02-16 12:17:11 UTC
Yep the workaround in comment #2 works for me.
Comment 13 Tim Dijkstra 2006-04-18 12:21:03 UTC
I noticed the fix from comment #2 isn't in 2.6.16, anything wrong with it?
Comment 14 Shaohua 2006-04-18 18:40:27 UTC
Patrick Mochel sent a updated patch based on my previous patch. But for some 
known reason, the patch is missed. I'll ping him.
Comment 15 Pavel Machek 2006-09-29 04:10:04 UTC
Any news? This report is getting old...
Comment 16 Alan Stern 2006-09-29 13:53:20 UTC
Patrick's suggested patch is here:


It seems to have faded away.  David, do you want to try reviving it?  I think
Patrick has been far too busy with other matters to work on this sort of thing
Comment 17 Shaohua 2006-09-29 22:24:41 UTC
Ok, I can take it. But I might have a little delay as I'm on holiday till Oct.8
Comment 18 Rafael J. Wysocki 2006-10-26 09:41:41 UTC
Have we had any progress?

Comment 19 Shaohua 2006-10-26 17:32:23 UTC
Yes, I sent a updated patch to akpm. It might be in -mm tree soon.
Comment 20 Shaohua 2006-10-29 23:32:50 UTC
Patch is in base kenrel now.

Note You need to log in before you can comment on or make changes to this bug.