|Summary:||USB devices and sound doesn't work after wake up from suspend to ram|
|Product:||Power Management||Reporter:||Filip Kata (fatman)|
|Component:||Hibernation/Suspend||Assignee:||Rafael J. Wysocki (rjwysocki)|
|Severity:||normal||CC:||acpi-bugzilla, alan, protasnb, stern|
|Kernel Version:||22.214.171.124, 126.96.36.199, 188.8.131.52||Subsystem:|
|Bug Depends on:|
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 184.108.40.206. 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 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
firstname.lastname@example.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=6964 > > > > > > ------- Additional Comments From email@example.com 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 220.127.116.11 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.