Bug 3916

Summary: CONFIG_USB_SUSPEND=y breaks APM Suspend to RAM
Product: Drivers Reporter: Frank Schmitt (tonne2004)
Component: USBAssignee: Greg Kroah-Hartman (greg)
Status: CLOSED PATCH_ALREADY_AVAILABLE    
Severity: high CC: bunk, dbrownell
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.9 Subsystem:
Regression: --- Bisected commit-id:
Bug Depends on:    
Bug Blocks: 5089    
Attachments: Kernel config for 2.6.10-rc3-bk12 triggering the bug

Description Frank Schmitt 2004-12-18 07:19:53 UTC 
Distribution: Fedora Core 3
Hardware Environment: IBM Thinkpad R40
Software Environment: kernel 2.6.9 and up (tested 2.6.10-rc3 and 2.6.10-rc3-bk12)
Problem Description: My r40 is running under APM. Suspend to RAM via Fn+F4
always worked for me, until Fedora started shipping 2.6.9 kernels. Since then
the notebook powers down ok and the LED indicating that it's sleeping is on, but
after some (~3) minutes, it wakes up on its own and hangs forcing a hard reset.
After some fiddling with different kernels and different configs, I found out
that this faulty behaviour is triggered by the kernel setting
CONFIG_USB_SUSPEND=y. If this option isn't set, the problem doesn't occur, as
soon as it is set the problem is there. Tested with 2.6.9 from Fedora Core 3,
and plain 2.6.9, 2.6.10-rc3 and 2.6.10-rc3-bk12 from kernel.org.

Steps to reproduce: 
1. Build a kernel with CONFIG_USB_SUSPEND=y
2. Boot it with kernel arguments acpi=off apm=on
3. Initiate APM Suspend to RAM (on a thinkpad by hitting Fn+F4)
4. See it go to sleep alright
5. Wait some minutes
6. See that it wakes up without you doing anythink
7. See that it hangs forcing you to do a hard reset
Comment 1 Frank Schmitt 2004-12-18 07:24:02 UTC 
Created attachment 4282 [details]
Kernel config for 2.6.10-rc3-bk12 triggering the bug
Comment 2 David Brownell 2005-10-13 12:51:35 UTC 
Fedora's bug was enabling that particular EXPERIMENTAL feature. 
On a different topic, 2.6.15 USB should handle suspend transitions 
a lot better.
Comment 3 Adrian Bunk 2006-04-06 14:34:15 UTC 
What is the status of this issue in kernel 2.6.16.1?
Comment 4 Frank Schmitt 2006-04-11 03:44:45 UTC 
It seems the issue is resolved in 2.6.16.1, at least I can't reproduce the error
any more. I'll close the bug for now but do some more tests in the weekend and
re-open if needed.