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/Suspend | Assignee: | 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
Created attachment 8713 [details]
My kernel config
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. 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.
Created attachment 8716 [details]
Dmesg after laptop's wake up
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. Created attachment 8724 [details]
Dmesg after mouse was plugged in
Created attachment 8725 [details]
Dmesg after mouse was unplugged
Created attachment 8726 [details]
Dmesg after mouse was plugged in again
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. 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. 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. 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. Please do the test described in comment #11. Include also the contents of /proc/interrupts, both before and after plugging the mouse back in. Created attachment 8775 [details]
Contents of /sys/kernel/debug/uhci/0000:00:1d.0 after wake up from suspend and before mouse plug in
Created attachment 8776 [details]
Contents of /sys/kernel/debug/uhci/0000:00:1d.0 after wake up from suspend and after mouse plug in
I forgot to tell you that bug is also in latest 2.6.17.8 kernel. 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. 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. Created attachment 8778 [details]
/proc/interrupts before suspend to ram
Created attachment 8779 [details]
/proc/interrupts after wake up from suspend
Can anyone please tell me what the status of this bug is? 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 ;) Rejecting due to the lack of response from the reporter. |