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
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.