Bug 4916
What is the output of lspci? Created attachment 5349 [details]
Output of lspci
Output of lspci
Could you please give dmesg output, including any output when adding the storage device, removing the mouse and plugging the mouse back in. This data should also be in /var/log/messages. May also be useful to have the lsusb output at 1) boot with the mouse only; 2) with the mouse still plugged in and having added the disk; 3) just the disk plugged in (unplug disk) and 4) with the mouse plugged back in. Thanks, Nish Created attachment 5353 [details]
dmesg output, including any output when adding the storage
device, removing the mouse and plugging the mouse back in
Created attachment 5354 [details]
lsusb output at 1) boot
with the mouse only; 2) with the mouse still plugged in and having added the
disk; 3) just the disk plugged in (unplug disk) and 4) with the mouse plugged
back in
Hope it helps!
Sander
Can you try borrowing a someone else's USB mouse, to see if the same thing still happens? Also, when the mouse has stopped working, what happens if you rmmod usbhid and then modprobe usbhid? Does the mouse start to work again? Yes, It does happen with an USB stick I borrowed from a friend When I try to rmmod and modprobe usbhid I get the following: $ sudo rmmod usbhid ERROR: Module usbhid does not exist in /proc/modules $ sudo modprobe usbhid FATAL: Module usbhid not found. Is that something I should have compiled in? When I search in menuconfig for 'usbhid' I don't get any matches though.. But what happens if you use a different mouse (not a different stick)? Apparently you have usbhid compiled into your kernel. Its setting in menuconfig is under Device Drivers -> USB support -> USB Human Interface Device (full HID) support, in the USB Input Devices subsection. You will also want to make sure that HID input layer support is turned on. Using another USB mouse did in fact work as it should, but another mouse of the
type that I'm normally using didn't. So the problem is probably related to the
type of mouse I'm using, but it's not my specific mouse that's broke.
I recompiled my kernel with usbhid as a module, and got no errors on the
rmmod/modprobe thing anymore, however it didn't make the mouse work. I still
had to take it out before it worked again.
Well if one mouse type works and another doesn't then it's likely to be some kernel compatibility problem. I'm sure we have debugging support in the kernel which will helkp us work out what's going on here. Can someone please guide Sander through it? Who maintains the USB mouse stuff anyway? Johannes Erdfelt? He seems to not have a bugzilla account... Here's something to try (I don't know if it will reveal anything useful, though).
Turn on USB verbose debugging in the kernel configuration (CONFIG_USB_DEBUG) and
rebuild the USB drivers. Then reboot and mount a debugfs filesystem:
mount -t debugfs none /sys/kernel/debug
Before you plug in the USB drive (while the mouse is still working), store a
copy of the "/sys/kernel/debug/uhci/0000:00:1d.0" file. Then after you plug in
the drive (while the mouse isn't working), make another copy of that file. Post
both copies, as well as a copy of the dmesg output going all the way back to the
boot-up, in this bug report.
hmm, I need a little more info here because it seems something is till missing. This is what I get when trying to mount debugfs after recompiling my kernel with USB_DEBUG and rebooting: 23:17 0 /usr/src/linux # mount -t debugfs none /sys/kernel/debug mount: mount point /sys/kernel/debug does not exist So I try creating it: 23:17 0 /home/sander # mkdir /sys/kernel/debug mkdir: cannot create directory `/sys/kernel/debug': Operation not permitted Then I tried making a mountpoint in /mnt, just to be sure: 23:18 1 /home/sander # mkdir /mnt/debug 23:18 0 /home/sander # mount -t debugfs none /mnt/debug mount: unknown filesystem type 'debugfs' And if it's any help, this is the contents of my /sys/kernel directory: 23:22 0 /usr/src/linux # ls /sys/kernel -l total 0 -r--r--r-- 1 root root 4096 Jul 29 23:20 hotplug_seqnum I tried searching in menuconfig for debugfs but that got me nowhere. Is there anything else I should have included to make this work? DEBUG_FS is enabled under Kernel Hacking --> Debug Filesystem (at least in 2.6.13-rc4). You may have been searching in menuconfig for debufs (which I did the first time as well :) ). Thanks, Nish Created attachment 5413 [details]
/sys/kernel/debug/uhci/0000:00:1d.0 before the USB stick is inserted
Thanks, I found it. Here are the files.
Created attachment 5414 [details]
/sys/kernel/debug/uhci/0000:00:1d.0 after USB stick is inserted
Created attachment 5415 [details]
Complete dmesg
..and the last one. Hope it's useful!
I didn't see anything useful in the dmesg log, unfortunately. But the UHCI
debugging files were helpful. The first one contains these lines:
- skel_int8_qh
[cecfb270] link (0ecfb152) element (0f1e6040)
0: [cf1e6040] link (00000001) e3 LS IOC Active NAK Length=7ff MaxLen=3 DT1
EndPt=1 Dev=2, PID=69(IN) (buf=0c502000)
which are the entry for the interrupt URB used by the HID driver to get event
reports from the mouse. Those lines were missing from the second file,
indicating that the URB completed (or was cancelled) but then was never
resubmitted (or failed in resubmission).
You may be able to get more information by using the usbmon facility. It's one
of the drivers listed in the USB kernel configuration, and
Documentation/usb/usbmon.txt explains how to use it.
Beyond that I don't know what to suggest. Maybe Vojtech will have some ideas.
Created attachment 5515 [details]
usbmon output of plugging in USB stick with mouse already inserted, then replugging the mouse
Here are the important lines from usbmon:
ca7ab100 2376566963 S Ii:002:01 -115 4 D
The second field is a timestamp in microseconds. So at 2376.566963 the HID
mouse driver submitted its event report interrupt URB.
ca7ab100 2401970709 C Ii:002:01 -84 0
At 2401.970709, some 25 seconds later, the URB completed with -84 = -EILSEQ,
indicating a low-level error in the USB data transmission. Apparently this
happened when you plugged in the stick, although I can't be certain because you
didn't include the usbmon log for the EHCI controller. Anyway, whatever the
cause, this was enough to cause the HID driver to forget about the mouse.
cecfdf80 2409908367 C Ii:001:01 0 1 D
At 2409.908367, some 8 seconds later still, the root hub status URB completed
because of the status change caused by you unplugging the mouse. Then a second
later you plugged the mouse back in again.
My impression is that a hardware flaw in your USB controllers causes the UHCI
companion controller to receive an error when you plug in a new device. The HID
driver should be able to cope with such errors by resubmitting its interrupt
URB, but it doesn't.
In fact, the code for the hid_irq_in, hid_irq_out, and hid_ctrl routines in
hid-core.c shows that the driver thinks -EILSEQ indicates a disconnection. This
is wrong. Yes, a disconnect can cause -EILSEQ errors, but so can other
problems. When such an error occurs the driver should resubmit the URB, perhaps
after waiting a few tens of milliseconds. The same is true for -EPROTO and
-ETIMEDOUT.
Vojtech, can you write a patch for the HID driver to fix this?
Created attachment 5616 [details]
Remove bogus tests from HID driver
This patch for 2.6.12 isn't the best one possible, but it ought to help solve
your problem. Try it out and see what happens.
Nope, this patch doesn't seem to fix the problem :( Created attachment 5621 [details]
usbmon output of the same process with the provided patch applied
Is this of any help?
The log shows that whatever the problem was, it wasn't just a transient occurrence. It persisted from the time the mouse stopped working until you replugged it. I wonder if this isn't some sort of mechanical problem. Like, maybe when you plug in the memory device, it somehow disturbs the mouse plug connector just enough to cause problems with signal transmission. That could explain why some brands of mouse work and others don't -- slight differences in the shapes of the plug connectors. What happens if you swap USB ports, or use different ports? Also, I wonder whether it matters that the USB stick is running at high speed. What happens if you rmmod ehci-hcd before plugging in the stick? (You may have to rebuild your kernel with ehci-hcd as a removable module.) Without it loaded, the stick will be forced to run at full speed instead. I only have two available USB slots on this laptop, and I've tried both combinations with the same effect. Furthermore, I doubt it's really a mechanical thing (or at least not an unsolvable one) because when I bought this machine it came preloaded with Windows XP Home which I used for about the first month and I don't remember having the problem there. I'm not 100% sure, but I've always used this USB stick a lot so I think I should have noticed if it had occurred. Removing ehci-hcd before plugging in the stick had no effect. It could even be some kind of electrical problem -- plugging in a second device causes a slight voltage drop to the mouse, which then dies. That also could explain why some brands are affected but not others: differences in sensitivity. Ultimately the fix will have to be for the USB HID driver to reset the mouse. I assume that's what Windows does. This will require a larger change than the first patch, and I won't have time to work on it for a while. Created attachment 5706 [details]
Manual device reset patch
You know, before changing the HID driver to make it reset the mouse, we should
check that a reset really will resuscitate the device. This patch will give
you an easy way to reset the mouse by hand. Once you've plugged in the stick
and the mouse has stopped working, as root do:
echo reset >/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/bConfigurationValue
(you better check that path to make sure it's correct). The reset should show
up in the dmesg log, and you'll be able to tell if the mouse starts working
again. If this does the job then it should be possible to add code to make the
HID driver do the equivalent thing automatically.
Created attachment 5731 [details]
dmesg output after going through the whole procedure
No, still nothing :( The mouse doesn't respond when I issue that command, but I
did have to change the path to the following:
echo reset > /sys/devices/pci0000:00/0000:00:1d.0/usb1/1-1/bConfigurationValue
Also, when I issued that command with just the mouse plugged in (while it was
working correctly) it stopped working too, so maybe the problem lies in that (I
doubt that should happen when resetting a device).
Attaching dmesg and usbmon again. And just for extra clarity: This is with the
first patch reversed and thus only the second patch applied.
Created attachment 5732 [details]
usbmon log of the whole procedure (inserting stick, issuing command, replugging)
this one may span about two minutes because I had to lookup the command again
Yes, the path will change depending on which port the mouse is plugged into. I had meant for you to use both patches in your testing, but since you say that doing the reset while the mouse is working causes it stop working, there's no point. Come to think of it, I should have realized the reset wouldn't work all by itself. When the mouse starts off, it initializes into Boot Protocol mode. The HID driver switches it over to Report Protocol mode and expects it to stay that way. But of course the reset switches it back, so it doesn't work any more. This means that it will be necessary to make a full-blown change to the HID driver. Oh well. Regarding boot protocol vs report protocol: On 99% of mice and keyboards the switch doesn't do anything, because the devices use a HIDBP-compatible layout of their reports. Oh, I didn't realize that. Then Sander, can you try running both tests over again (that is, reset after the mouse stops working and reset while the mouse is working) with both patches applied? Same results. The mouse stops working on both occasions with both patches applied.. Please attach the two logs (dmesg and usbmon) for the experiment where you reset the mouse while it is running. For the moment let's not worry about the USB stick. After all, we've got to be able to reset the mouse before we can recover from other problems. By the way, have you ever tried plugging the mouse and stick into a different computer to see if the same problem still occurs? Created attachment 5779 [details]
usbmon
Yes, I've tried the same devices on another machine and got the same results,
however that machine was of the exact same type as this one so that's probably
not really useful. I don't have access to other Linux machines at the moment,
but when I run into a different one I'll try it.
Created attachment 5780 [details]
dmesg
Created attachment 5806 [details]
Add HID device reset routine
Here's a rather experimental patch to try. You should remove the other two
patches before applying this one. If it works, it will automatically reset the
mouse about a second after you plug in the storage device.
Vojtech, while working on this I noticed that in hid_irq_out and hid_ctrl the
Success case falls through to the -ESHUTDOWN case and so sets unplug to 1. Is
it supposed to do that?
Thats definitely a bug, good catch! Created attachment 5808 [details]
rejected patch
Applying this patch fails with the following message:
20:28 1 /usr/src/linux # patch -p1 <
/home/sander/misc/references/kernel-bug-4916/patch-3.txt
patching file drivers/usb/input/hid-core.c
Hunk #1 succeeded at 1000 (offset 92 lines).
Hunk #2 FAILED at 1033.
Hunk #3 FAILED at 1214.
Hunk #4 FAILED at 1260.
Hunk #5 FAILED at 1867.
Hunk #6 FAILED at 1895.
5 out of 6 hunks FAILED -- saving rejects to file
drivers/usb/input/hid-core.c.rej
patching file drivers/usb/input/hid.h
Created attachment 5809 [details]
Add HID device reset routine
Here's a version of the patch made against vanilla 2.6.12. Make sure you have
removed all previous patches before trying to apply this one.
Sander, did you get a chance to test Alan's patch? I'm sorry, I've been away for a while and just got back. I need to catch up with stuff at home the next couple of days, but I'll try to test the patch this week. Sorry for the delay! shit, I totally forgot about this bug because I recently switched distros (from Gentoo to Kubuntu) and acquired another USB stick which didn't have these issues. I just tried and the old stick still has the problem in Kubuntu. However, I don't know how to test the patch(es) now anymore since Kubuntu just delivers a compiled kernel, and I'm just not that much into this stuff :) If you guys could give me any pointers on how to test this I'd be happy to try (promise) :) I'm really sorry about not responding anymore! I just had the same problem on a machine using the pre-build kernel 2.6.8 from Debian Sarge. I just installed 2.6.11, from Debian Testing, hopping that it solves the problem. Created attachment 7025 [details]
Add error recovery to the USB HID driver
Sander, try applying this patch to the 2.6.15 kernel source. Even if you don't
have your distribution's source, you can always download 2.6.15 from
www.kernel.org.
I just installed 2.6.12-1-686 (pre-build from Debian) and I have the same problem. I have two machines with the same mouse and this only happens in one of them. The machine with problems have a PII 300MHz, on a board ASUS P2L97. Luis, try running the 2.6.15 kernel together with the patch in attachment 7025 [details].
http://bugzilla.kernel.org/attachment.cgi?id=7025&action=view works for me, after plugging in my USB disk the mouse pointer hangs for 1-2 seconds (which I assume is some kind of timeout) and then continues as normal. Thanks! Created attachment 7149 [details]
Add error recovery to the USB HID driver (updated)
This is a slightly updated version of the earlier patch. Please try it and
make sure it works okay. If it does, I'll submit it for inclusion in the
kernel.
Yes. Works the same. Slight delay, after 1-2 seconds it works perfectly. Is it better to use this version instead of the previous one?
I patched the kernel with the previous one and apparently it's all fine :)
>This is a slightly updated version of the earlier patch. Please try it and
>make sure it works okay. If it does, I'll submit it for inclusion in the
>kernel.
>
Yes, the patch in attachment #7149 [details] is slightly better than the earlier one. The
original version contained a small mistake.
Is Alan's patch required to get this device working on 2.6.16-rc3? If so, Dmitry, do you feel it is solid enough to send this late in the 2.6.16-rc series, or should I wait until 2.6.16 is out? The patch looks very reasonable but it is pretty big and has a potential of disrupting HID and thus affecting a lot of people. This is not a recent regression and number of affected boxes seems to be limited so I'd feel more safe if we could wait for 2.6.17 to open. So, is this one going in any time soon? It's already in 2.6.17-rc1. The patch from this bug was included in 2.6.17. |
Distribution: Gentoo Hardware Environment: ASUS M2400N notebook Software Environment: ? Problem Description: When my USB mouse is plugged in and I insert my USB memory stick in another USB slot, the mouse stops working and needs to be taken out and plugged in again to resume. Steps to reproduce: Insert USB mouse (it works) Insert USB memory device (mouse stops working) Pull out and reinsert mouse (it works again) I never committed a kernel bug before so I don't know what info I should provide. If somethign is needed, just ask and I'll be happy to provide it.