Bug 6964

Summary: USB devices and sound doesn't work after wake up from suspend to ram
Product: Power Management Reporter: Filip Kata (fatman)
Component: Hibernation/SuspendAssignee: Rafael J. Wysocki (rjwysocki)
Status: REJECTED INSUFFICIENT_DATA    
Severity: normal CC: acpi-bugzilla, alan, protasnb, stern
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.17.7, 2.6.17.8, 2.6.17.9 Subsystem:
Regression: --- Bisected commit-id:
Bug Depends on:    
Bug Blocks: 7216    
Attachments: My kernel config
Dmesg before suspend to ram
Dmesg after laptop's wake up
Dmesg after mouse was plugged in
Dmesg after mouse was unplugged
Dmesg after mouse was plugged in again
Contents of /sys/kernel/debug/uhci/0000:00:1d.0 after wake up from suspend and before mouse plug in
Contents of /sys/kernel/debug/uhci/0000:00:1d.0 after wake up from suspend and after mouse plug in
/proc/interrupts before suspend to ram
/proc/interrupts after wake up from suspend

Description Filip Kata 2006-08-05 13:24:41 UTC
Most recent kernel where this bug did not occur:
Distribution: Debian SID upgraded to latest version
Hardware Environment: Toshiba Tecra 9000
Software Environment: bash
Problem Description:
Recently I've upgraded kernel to newest 2.6.17.7. After plugging in usb device
kernel makes nothing. Device works only on "fresh" - restarted system. I tried
usb mouse, bluetooth dongle and camera. None works. Mouse don't even get power.
Dmesg shows nothing.
Steps to reproduce:
1. start system
2. plug in usb device
3. it works
4. remove device
5. plug in different device
6. it doesn't work
Comment 1 Filip Kata 2006-08-05 13:30:42 UTC
Created attachment 8713 [details]
My kernel config
Comment 2 Alan Stern 2006-08-05 14:20:28 UTC
Please turn on CONFIG_USB_DEBUG, and then attach the dmesg logs showing what
happens when you first plug in a USB device, when you unplug it, and when you
try plugging it in again.
Comment 3 Filip Kata 2006-08-06 01:33:45 UTC
Created attachment 8715 [details]
Dmesg before suspend to ram

I found out that usb stops to work after suspend to ram. After wake up plugging
in any device makes nothing.
Comment 4 Filip Kata 2006-08-06 01:35:57 UTC
Created attachment 8716 [details]
Dmesg after laptop's wake up
Comment 5 Alan Stern 2006-08-06 08:22:58 UTC
Forget about suspend to RAM.  Please post dmesg logs showing what happens when
you first plug in the mouse, when you unplug it, and when you plug it in again.
Comment 6 Filip Kata 2006-08-07 01:33:41 UTC
Created attachment 8724 [details]
Dmesg after mouse was plugged in
Comment 7 Filip Kata 2006-08-07 01:34:36 UTC
Created attachment 8725 [details]
Dmesg after mouse was unplugged
Comment 8 Filip Kata 2006-08-07 01:35:13 UTC
Created attachment 8726 [details]
Dmesg after mouse was plugged in again
Comment 9 Alan Stern 2006-08-07 08:36:23 UTC
Unforunately that didn't help much.  The dmesgs for the two times you plugged in
the mouse were almost identical, with no indication about why it wasn't working
the second time.  In fact it did work at least partially, because that "A4Tech
USB Optical Mouse" string in the log was provided by the mouse.

Can you do the same experiment over again, but this time using usbmon instead of
dmesg?  The instructions for usbmon are in the kernel source, under
Documentation/usb/usbmon.txt.  You'll have to set CONFIG_DEBUG_FS and
CONFIG_USB_MON to use it.
Comment 10 Filip Kata 2006-08-07 10:10:42 UTC
bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=6964
>
>
>
>
>
> ------- Additional Comments From stern@rowland.harvard.edu  2006-08-07 08:36 -------
> Unforunately that didn't help much.  The dmesgs for the two times you plugged in
> the mouse were almost identical, with no indication about why it wasn't working
> the second time.  In fact it did work at least partially, because that "A4Tech
> USB Optical Mouse" string in the log was provided by the mouse.
>   
Because it was alright this time. As I said problem occurs only after 
wake up from suspend to ram. I will send you output of usb monitor tomorrow.

Comment 11 Alan Stern 2006-08-07 10:47:40 UTC
You didn't use the word "only" in comment #3.

Okay, here's yet another experiment to try.  Before suspending, unplug the mouse
and do

   echo 2 >/sys/module/uhci_hcd/parameters/debug
   mount -t debugfs none /sys/kernel/debug

(note that this requires CONFIG_DEBUG_FS).  Then after you resume, make a copy
of /sys/kernel/debug/uhci/0000:00:1d.0.  In fact, attach two copies: one with
the mouse still unplugged and one after you plug it back in.  Be sure to plug
the mouse into the same port as you used in comments #6-8.

This debugging file will show what the uhci-hcd driver thinks is happening and
what state the USB controller is in.
Comment 12 Filip Kata 2006-08-12 11:05:13 UTC
I found out that it's not only usb problem. Problem is connected also with sound
and other modules. After wake up from suspend nothing works. Running alsaconf
return sound but to get usb devices working I have to restart system.
Comment 13 Alan Stern 2006-08-13 11:07:04 UTC
Please do the test described in comment #11.  Include also the contents of
/proc/interrupts, both before and after plugging the mouse back in.
Comment 14 Filip Kata 2006-08-13 11:45:17 UTC
Created attachment 8775 [details]
Contents of /sys/kernel/debug/uhci/0000:00:1d.0 after wake up from suspend and before mouse plug in
Comment 15 Filip Kata 2006-08-13 11:45:47 UTC
Created attachment 8776 [details]
Contents of /sys/kernel/debug/uhci/0000:00:1d.0 after wake up from suspend and after mouse plug in
Comment 16 Filip Kata 2006-08-13 11:47:19 UTC
I forgot to tell you that bug is also in latest 2.6.17.8 kernel.
Comment 17 Alan Stern 2006-08-13 12:03:59 UTC
The values in /proc/interrupts will probably confirm this.  It looks like IRQs
are not getting delivered correctly after your system resumes.

This bug should be placed under a different category or component.  It clearly
isn't a USB issue.  Maybe it's something to do with ACPI.
Comment 18 Filip Kata 2006-08-13 13:56:49 UTC
I will post /proc/interrupts and then change it to ACPI category. When I noticed
than alsa doesn't work I was pretty sure that's ACPI problem. On this machine I
have made change from 2.6.16.something kernel version to latest 2.6.17 and than
it started. It's quite annoying because after each suspend you have to reboot
whole machine.
Comment 19 Filip Kata 2006-08-14 04:01:50 UTC
Created attachment 8778 [details]
/proc/interrupts before suspend to ram
Comment 20 Filip Kata 2006-08-14 04:03:44 UTC
Created attachment 8779 [details]
/proc/interrupts after wake up from suspend
Comment 21 Rafael J. Wysocki 2007-06-04 10:44:56 UTC
Can anyone please tell me what the status of this bug is?
Comment 22 Natalie Protasevich 2007-06-13 16:04:51 UTC
Filip, any chance that you can try latest kernel?
Also, the interrupts look a bit odd because the modules pcmcia0.0, Intel 82801CA-ICH3 trade places and I am not sure if the corresponding modules get unloaded and loaded back in different order and if anything wrong with this. Can you also provide "lsmod" before and after the unplug maybe? unless your problems are gone in later kernels ;)
Comment 23 Rafael J. Wysocki 2007-08-09 09:23:15 UTC
Rejecting due to the lack of response from the reporter.