Most recent kernel where this bug did not occur:
Distribution: Debian SID upgraded to latest version
Hardware Environment: Toshiba Tecra 9000
Software Environment: bash
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
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.
> ------- Additional Comments From firstname.lastname@example.org 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
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 220.127.116.11 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
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.