Meet the Gang   1   2   3   4   5   6   7   8   9   10   11   12

USB mouse goes missing

From icalla

Answered By Jay R. Ashworth, Karl-Heinz Herrmnn, Heather Stern, Ben Okopnik, Robos, Jim Dennis

Hi Gang,

[Jay] Hey there.

The mouse in question is a Microsoft IntelliMouse (optical). It is detected and initialised, and works fine - for a while. After some seemingly random time, and for no apparent reason, it goes missing. The pretty red glow from underneath goes out. The pointer disappears from the screen.

[K.-H.] I've got a Logitech optical/cordless, reciever is USB.

mine never stops the dull flashes, not even if PC is powered off for some time. if it detects movement it will change to rapid bright flashes to improve on accuracy I guess.

I can find no way to get it back, except to re-boot.

It does leave a bit of a trail in the syslog, but unfortunately it doesn't mean a lot to me. Here is a sample:

Jan 29 12:50:20 portia kernel: usb-uhci.c: interrupt, status 3, frame# 452
Jan 29 12:50:20 portia kernel: usb-uhci.c: interrupt, status 3, frame# 476
[6 more instances, at a distance of 24 frames apart]

[Jay] Are those "I'm ok" messages, or the beginning of "I'm dying"?

[Ben] Those are the "I'm not quite getting a handle on this thing" messages. I saw that just recently when messing around with hooking up my new Palm Pilot cradle to my laptop (too new to have Linux support yet. ). Using a slightly different module got me past that step.

Jan 29 12:55:55 portia kernel: usb.c: USB disconnect on device 2
Jan 29 12:55:55 portia kernel: hub.c: USB new device connect on bus1/1, assigned device number 3
Jan 29 12:55:59 portia kernel: usb_control/bulk_msg: timeout
Jan 29 12:55:59 portia kernel: usb.c: USB device not accepting new address=3 (error=-110)
Jan 29 12:56:00 portia kernel: hub.c: USB new device connect on bus1/1, assigned device number 4
Jan 29 12:56:04 portia kernel: usb_control/bulk_msg: timeout
Jan 29 12:56:04 portia kernel: usb.c: USB device not accepting new address=4 (error=-110)

[K.-H.] your device got disconnected and the usb-module tries to reconnect it with a new number. But your mouse doen't like the number it seems.

The question is: why does it disconnect?

How about new batteries if it's cordless? check the plugs if with cord? Does it beep when it fails the first time? Mine beeps on changes in the usb devices.

I would be grateful if somebody could tell me

[K.-H.] (a pretty much, correctly working setup.) What happens here if I unplug and replug the receiver is:

Jan 29 19:24:54 khhlap kernel: hub.c: port 1 connection change
Jan 29 19:24:54 khhlap kernel: hub.c: port 1, portstatus 100, change 3, 12 Mb/s
Jan 29 19:24:54 khhlap kernel: usb.c: USB disconnect on device 2
Jan 29 19:24:54 khhlap kernel: usb.c: kusbd: /sbin/hotplug remove 2
Jan 29 19:24:54 khhlap kernel: usb.c: kusbd policy returned 0xfffffffe

now its gone. reconnect:

Jan 29 19:24:54 khhlap kernel: hub.c: port 1 enable change, status 100
Jan 29 19:24:58 khhlap kernel: hub.c: port 2 connection change
Jan 29 19:24:58 khhlap kernel: hub.c: port 2, portstatus 301, change 1, 1.5 Mb/s
Jan 29 19:24:59 khhlap kernel: hub.c: port 2, portstatus 303, change 0, 1.5 Mb/s
Jan 29 19:24:59 khhlap kernel: hub.c: USB new device connect on bus1/2, assigned
Jan 29 19:24:59 khhlap kernel: usb.c: kmalloc IF cefa93a0, numif 1
Jan 29 19:24:59 khhlap kernel: usb.c: skipped 1 class/vendor specific interface
Jan 29 19:24:59 khhlap kernel: usb.c: new device strings: Mfr=1, Product=2, Seri
Jan 29 19:24:59 khhlap kernel: usb.c: USB device number 3 default language ID 0x

got a new number assigned (3 instead of 2)

Jan 29 19:24:59 khhlap kernel: Manufacturer: Logitech
Jan 29 19:24:59 khhlap kernel: Product: USB Receiver
Jan 29 19:24:59 khhlap kernel: input0: USB HID v1.10 Mouse [Logitech USB Receive
Jan 29 19:24:59 khhlap kernel: usb.c: hid driver claimed interface cefa93a0
Jan 29 19:24:59 khhlap kernel: usb.c: kusbd: /sbin/hotplug add 3
Jan 29 19:24:59 khhlap kernel: usb.c: kusbd policy returned 0xfffffffe
Jan 29 19:24:59 khhlap usbmgr[582]: vendor:0x46d product:0xc501
Jan 29 19:24:59 khhlap usbmgr[582]: class:0x3 subclass:0x1 protocol:0x2
Jan 29 19:24:59 khhlap usbmgr[582]: USB device is matched the configuration

After that X doesn't know the mouse any more. I guess the /dev/usb/mouseX changes with the usb-device number and X will fail to read mouse0. I use it on a laptop right now and the coreinputdevice is my touchpad, the mouse is set to sendcoreevents in /etc/XF86Config-4. This way X will not complain if the usb mouse is not there (but will not accept it reconnected later).

Restarting X is usually sufficient to get it working, I'll check if the usb device is changing the /dev/usb(mouseX number as well next time restarting.

1) What is wrong, and how to permanently fix it, or

[Jay] This sounds a lot like something is intermittent. Is the mouse plugged directly into your machine, or a subsidiary hub?

Any possiblity you have a second USB mouse you can borrow to test?

[Ben] Rather than suggesting a specific driver, which is only a small part of the picture, I'm going to send you to the place that got me as far as it was possible to get in my chase; I would say that you should be able to resolve your problem without too much trouble, since there's a whole section dedicated to USB mice. Go to https://www.linux-usb.org, and read the stuff in order, starting at the top (you can skip the sections that don't apply, but you do need to start at the very beginning or you'll miss important things.)

[Heather] Failing that, you actually may find it possible to make the USB subsystem more stable by compiling the correct USB "hub" driver into your kernel.

In this case UHCI support.

I also note that one of the USB hub flavors, UHCI ... yes, that's right, the one you are using ... has two different possible drivers to use for basic hub support. I have never discovered any difference using either one, but maybe your system wants "the other one" . You can try it as a module first and see.

Anyways my dad-in-law has a usb keyboard that lets the mouse plug into its back "piggyback" style - and we got better USB behavior by building usb-uhci into the kernel. Very minor difference, but he lives in X, and mouses being strange on you don't make a happy GUI.

[Ben] That was actually what worked for me, but I wanted him to have the big picture: understanding the USB process and tweaking the few small variables seems to be the way to go. I got this close with the Palm Pilot, even though it's not supported yet: got USB to recognize it as a valid device (!), one that did not get dropped... I wish I knew more about writing drivers and protocol parsers, but it's about #16,761 on the priority list.

[update: he seems to have gotten it working these days.]

2) How to re-initialise it without re-booting

[Jay] Since it doesn't seem to be able to locate the mouse after it dies, this may not be possible; I'm not a USB mechanic (yet); someone else will probably have a better answer here.

[K.-H.] restarting X seems not to suffice in your case since the mouse doesn't like a new number asigned.

This is my first effort posting to a group of this ilk, so please chide me gently if I step outside the bounds.

[Jay] Well, you aren't inquring about Motorola SoftModems on Windows 2000, so I'd say you're pretty much ok for now. Hell, you even included the syslog segment. You go, boy.

[Robos] Hi!

I can't contribute much, but maybe you can get it to work again by removing the module (looks like a module to me) and inserting it again. I'm not sure if some other module has to be removed and inserted first. Try /sbin/lsmod to see if it is a module (and being used) and then rmmod usb-uhci and modprobe usb-uhci. Give it a try, maybe it works.

[Ben] Yep. Rebooting is unnecessary; you can just unload/reload the module - but the problem is that the module that you're using is generating or missing a ton of spurious interrupts, which eventually brings it to its knees.

[K.-H.] So now I tried this again: on disconnect the mouse (reciever) is dropped from valid input devices (Xserver) reconnecting the mouse will leave it unused.

restarting X will not find the mouse on /dev/usbmouse0 as usually. restarting with config entry pointing to /dev/usbmouse1 does find the mouse and it's working again.

Changing a link which is in the Config to point to the right device after a disconnect/reconnect does not work. Restarting X with the same link to ...mouse1 will work.

I guess you should fiure out why your mouse gets disconnected, everything else is lots of trouble and strange things happening.

But basically restarting X with the right mouse device should suffice, rebooting the whole system is not necessary here. But my mouse gets reconnected without error, yours not.

That's as far as I can try help in this I think....

[Heather] X should stay working if you use /dev/mice (major 13, minor 63, type character) but that doesn't make it less annoying that it's losing an entry.

However, nothing will help if your mousie's little USB plug doesn't like staying in the socket. If you have a machine with more than one USB socket try the other one and see if it clears up suddenly. In which case you'll either need to give up on the flimsy socket, or use it only for devices that aren't so darn picky.

Good luck.

This page edited and maintained by the Editors of Linux Gazette Copyright © 2002
Published in issue 76 of Linux Gazette March 2002

HTML script maintained by Heather Stern of Starshine Technical Services, https://www.starshine.org/

Meet the Gang   1   2   3   4   5   6   7   8   9   10   11   12