Bug 6071
| Summary: | uhci_hcd and ohci_hcd prevents CPU from entering C3 state | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Jakub Jozwicki (jakub007) |
| Component: | USB | Assignee: | Greg Kroah-Hartman (greg) |
| Status: | RESOLVED WILL_NOT_FIX | ||
| Severity: | normal | CC: | bjoern, protasnb |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.25 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 5089 | ||
| Attachments: |
dmesg
lspci -vvv lsusb -vvv |
||
Has this ever worked on other kernel version? Can you enable CONFIG_USB_DEBUG and provide some debug log messages for when you try to suspend? Created attachment 7339 [details]
dmesg
Created attachment 7342 [details]
lspci -vvv
Created attachment 7343 [details]
lsusb -vvv
> Has this ever worked on other kernel version?
Probably not.
Here is explanation of the problem:
"When a USB device is attached to a PC, the USB host controller polls the frame
scheduler in memory. This is a direct memory access (DMA) bus master operation.
Any bus master traffic, interrupt, or one of several other system activities
are "break events" that will move a CPU out of C3 because, by definition, the
CPU's cache cannot be snooped while in C3. The resolution is selective suspend.
This feature allows a driver to suspend the USB device it controls when the
device becomes idle, even while the system itself remains in a fully
operational power state (S0)."
Yeah, this is a known issue with USB and Linux right now. People are working on it, but it will be a while before it's fixed. I recommend just unloading the modules for now if you wish to suspend and have good battery life. who is actually working on this? The bug should be assigned to them instead of being "rejected documented". The ehci-hcd driver without polling works nice and leaves the cpu in c3 state. uhci's polling is really a bad thing for some laptop users. Any update on this problem? Bjorn, have you tested with recent kernel? An update: on kernel 2.6.25 this problem still exists! Unloading the module does indeed make entering the C3 state possible, but it would be nice to actually get this fixed (as by removing the module I also shut down the bluetooth and fingerprint scanner in the X61). This is a hardware issue. Will close as WILL_NOT_FIX unless someone submits some patches to implement this. |
Most recent kernel where this bug did not occur: Distribution: Gentoo Hardware Environment: AMD Turion 64, ASUS A6K laptop Software Environment: Problem Description: uhci_hcd and ohci_hcd prevents CPU from entering C3 state cat /proc/acpi/processor/CPU1/power: active state: C2 max_cstate: C8 bus master activity: 00200803 states: C1: type[C1] promotion[C2] demotion[--] latency[000] usage[00007730] *C2: type[C2] promotion[C3] demotion[C1] latency[099] usage[00057774] C3: type[C3] promotion[--] demotion[C2] latency[990] usage[00000237] after rmmod ohci_hcd: active state: C3 max_cstate: C8 bus master activity: 00200800 states: C1: type[C1] promotion[C2] demotion[--] latency[000] usage[00009410] C2: type[C2] promotion[C3] demotion[C1] latency[099] usage[00066640] *C3: type[C3] promotion[--] demotion[C2] latency[990] usage[00025690] Steps to reproduce: 1) Buy some hardware with CPU supporting C3 power state and USB 1.1, USB mouse 2) Install linux with coldplug/hotplug which will load drivers for mouse 3) See that CPU never enters C3 and laptop life on battery is shortened by 30 minutes - 1 hour