Bug 5475

Does the mouse freeze if you are using it with GPM in console? What device are 
you usign to get mouse data (/dev/input/mice, /dev/psaux, etc)?

I am using /dev/input/mice.

Using gpm it freezes also. When I started using gpm and when the mouse froze, I
could not get to unfreeze again by switching terminals.

I have tried looking in syslog, messages and dmesg, nothing there to pinpoint
the problem.

Does this happen on 2.6.14?

I just tried kernel 2.6.14.2 and the same thing happened.

Is there any debug logging I can set or see somewhere?

I am using kernel 2.6.15 on Ubuntu development version and the same thing
happens. There is no information in kern.log or messages.log.

My mouse is a Logitech Optical Mouse M/N: M-BD58.

I've tried using a PS/2 adaptor and the mouse works fine.

There are two things you can do.  First, turn on CONFIG_USB_DEBUG and check the
dmesg log.  Second, use the usbmon facility to keep track of USB data flowing
back and forth (see the instructions in Documentation/usb/usbmon.txt).  This
should tell us if the problem is in the lower part of the driver stack.

No response in 2 months, closing.  If this is still a problem, please reopen
with the requested information.

Hi,

Sorry for my late answer.

I have tried using usbmon on 2.6.15 but I did not see all my usb devices, only 2
( I have three usb devices, a mouse, keyboard and a logitech headset).

I followed the instructions in usbmon.txt, mounted the debug_fs.

In the doc it says:

ls /sys/kernel/debug/usbmon
1s  1t  2s  2t  3s  3t  4s  4t

but I only have 4:

1s 1t 2s 2t

Also it says, 

cat /proc/bus/usb/devices

but

dir /proc/bus/usb/

gives an empty directory.

From lsusb:

Bus 001 Device 004: ID 046d:c00c Logitech, Inc. Optical Wheel Mouse

So it must be device 4 but that does not correspond to ls /sys/kernel/debug/usbmon.

I am pretty confused.

The entries in /sys/kernel/debug/usbmon correspond to your computer's USB
controllers (or buses), not to USB devices.  Apparently your computer has only
two controllers, so there are only four files.  Since the mouse shows up on bus
1 according to lsusb, the file you need to monitor is 1t.

In some distributions, /proc/bus/usb isn't mounted by default.  You have to
mount it by hand:

   mount -t usbfs none /proc/bus/usb

Created attachment 7602 [details]
dump of usbmon

This is a dump of usbmon. The mouse freezed while catting 1t. I stopped,
unplugged the mouse and then plugged it in again.

Created attachment 7603 [details]
Dump of usbmon while mouse is working

This is a dump after the mouse was unplugged and plugged in again (ie. while
the mouse was working).

The dump indicates that the mouse simply stopped working.  Of course, it's
possible that the USB host controller stopped working instead.

Have you tried booting a 2.6.10 kernel recently?  Do you know that it still works?

What shows up in the usbmon output if the mouse freezes under Gnome and you
unfreeze it by switching terminals?

Hi,

I'm using 2.6.10 (Ubuntu Hoary - 5.04) on a daily basis and there are no
problems here.

I have see other people reporting this problem:

https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/20125
http://www.ubuntuforums.org/showthread.php?t=127027

There is a difference using 2.6.12 and 2.6.15. On 2.6.12 I can unfreeze the
mouse by switching terminals.

On 2.6.15 I have to unplug it. Switching terminals does not work.

Okay, try doing this with 2.6.15:  Turn on CONFIG_USB_DEBUG in the kernel
configuration and make sure that CONFIG_USB_HID is set to M, not Y.  Rebuild the
USB drivers and load uhci-hcd with

   modprobe uhci-hcd debug=3

Next, mount /sys/kernel/debug.  When the mouse freezes, go to
/sys/kernel/debug/uhci and post the contents of the file which corresponds to
the USB controller the mouse is plugged into.  After that, try doing

   rmmod usbhid
   modprobe usbhid

and see if that gets the mouse to start working again.

Created attachment 7698 [details]
A patch that fixed it for a couple users

Try this patch - it fixed it for a number of SuSE users. I believe I have
sent it to Dmitry already, if not, please correct me.

The problem is that the mouse in question sometimes caused EILSEQ
intermittently,
resulting in the driver giving up on it. This makes the driver ignore the
intermittent errors.

The provided patch works for me.

Thanks to everyone.

Alan has reworked HID driver interrupt handling quite a bit, could you please 
try the latest git snapshot (or 2.6.17-rc1 when it comes out)?

I'll try 2.6.17-rc1 when it comes out.

2.6.17-rc1 seems to be working fine. The mouse doesn't freeze.