USB mouse works on and off (disconnects and re-connects)

mike11 · 05-11-2012, 07:14 AM

I'm using Debian stable, installed on a Toshiba laptop.
Plugged in a basic Microsoft USB mouse. Mouse works for a couple for seconds, then the LED goes out, then comes back again after a short while (typically 1-10seconds), in what appears a purely random fashion.

The mouse works fine on a Windows machine, and laptop usb ports are fine too since I've connected a USB HDD to them.

I've set in xorg.conf:
Section "InputDevice"
Identifier "USB Mouse"
Driver "mouse"
Option "CorePointer"
Option "Protocol" "Microsoft"
Option "Device" "/dev/input/mice"
Option "BaudRate" "300"
EndSection

Any ideas? (IRQ conflict? buggy usb support?).

Update:
It seems the mouse gets disconnected and then reconnected every few seconds.
This is /var/log/messages:

Code:

May 11 22:18:13 mypc kernel: [  451.032322] usb 2-1: USB disconnect, address 17
May 11 22:18:14 mypc kernel: [  452.512100] usb 2-1: new low speed USB device using uhci_hcd and address 18
May 11 22:18:15 mypc kernel: [  452.695082] usb 2-1: New USB device found, idVendor=045e, idProduct=0040
May 11 22:18:15 mypc kernel: [  452.695092] usb 2-1: New USB device strings: Mfr=1, Product=3, SerialNumber=0
May 11 22:18:15 mypc kernel: [  452.695099] usb 2-1: Product: Microsoft 3-Button Mouse with IntelliEye(TM)
May 11 22:18:15 mypc kernel: [  452.695106] usb 2-1: Manufacturer: Microsoft
May 11 22:18:15 mypc kernel: [  452.697056] usb 2-1: configuration #1 chosen from 1 choice
May 11 22:18:15 mypc kernel: [  452.716055] input: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM) as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/input/input22
May 11 22:18:15 mypc kernel: [  452.717370] generic-usb 0003:045E:0040.000C: input,hidraw0: USB HID v1.10 Mouse [Microsoft Microsoft 3-Button Mouse with IntelliEye(TM)] on usb-0000:00:1d.0-1/input0

I've tried adding "acpi=force irqpoll" to the grub options, but no change.

TIA

Doc CPU · 05-11-2012, 03:57 PM

Hi there,

Quote:

Originally Posted by mike11

Plugged in a basic Microsoft USB mouse. Mouse works for a couple for seconds, then the LED goes out, then comes back again after a short while (typically 1-10seconds), in what appears a purely random fashion.

it's a long shot, but for what it's worth... is it possible that this particular mouse exceeds the 100mA current limit, and your USB controller and the device driver enforce these limits strictly?

Quote:

Originally Posted by mike11

The mouse works fine on a Windows machine, and laptop usb ports are fine too since I've connected a USB HDD to them.

The Windows USB driver doesn't care if a device draws more current than it's allowed to. A USB device can be granted more than 100mA (up to a maximum of 500mA), but according to the USB standard it has to register that higher limit with the controller when it is being connected.
USB-powered 2½" hard disks usually negotiate that properly, and the 3½" hard disks don't have the problem because they have their own power supply.

Quote:

Originally Posted by mike11

It seems the mouse gets disconnected and then reconnected every few seconds.
This is /var/log/messages:

Code:

May 11 22:18:13 mypc kernel: [  451.032322] usb 2-1: USB disconnect, address 17
May 11 22:18:14 mypc kernel: [  452.512100] usb 2-1: new low speed USB device using uhci_hcd and address 18
May 11 22:18:15 mypc kernel: [  452.695082] usb 2-1: New USB device found, idVendor=045e, idProduct=0040
May 11 22:18:15 mypc kernel: [  452.695092] usb 2-1: New USB device strings: Mfr=1, Product=3, SerialNumber=0
May 11 22:18:15 mypc kernel: [  452.695099] usb 2-1: Product: Microsoft 3-Button Mouse with IntelliEye(TM)
May 11 22:18:15 mypc kernel: [  452.695106] usb 2-1: Manufacturer: Microsoft
May 11 22:18:15 mypc kernel: [  452.697056] usb 2-1: configuration #1 chosen from 1 choice
May 11 22:18:15 mypc kernel: [  452.716055] input: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM) as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/input/input22
May 11 22:18:15 mypc kernel: [  452.717370] generic-usb 0003:045E:0040.000C: input,hidraw0: USB HID v1.10 Mouse [Microsoft Microsoft 3-Button Mouse with IntelliEye(TM)] on usb-0000:00:1d.0-1/input0

That's only the log extract of the moment the mouse is being recognized. The part about disconnecting it would be more interesting.

[X] Doc CPU

mike11 · 05-12-2012, 06:34 AM

Thanks.

After long hours yesterday searching online, there seems to be main causes for such usb mouse issue:
irq conflict and hardware issues, possibly due to the 100mA current thing.

Following comments online, I've tried adding noapic nolapic and acpi=force irqpoll in grub, but it didn't solve the issue.

Regarding the messages, it shows "USB disconnect, address <something>", for example:

Code:

May 12 13:33:25 mypc kernel: [  571.013697] generic-usb 0003:045E:0040.0004: input,hidraw0: USB HID v1.10 Mouse [Microsoft Microsoft 3-Button Mouse with IntelliEye(TM)] on usb-0000:00:1d.0-1/input0
May 12 13:33:59 mypc kernel: [  605.040483] usb 2-1: USB disconnect, address 7
May 12 13:34:00 mypc kernel: [  605.344064] usb 2-1: new low speed USB device using uhci_hcd and address 8
May 12 13:34:00 mypc kernel: [  605.526414] usb 2-1: New USB device found, idVendor=045e, idProduct=0040
May 12 13:34:00 mypc kernel: [  605.526424] usb 2-1: New USB device strings: Mfr=1, Product=3, SerialNumber=0
May 12 13:34:00 mypc kernel: [  605.526432] usb 2-1: Product: Microsoft 3-Button Mouse with IntelliEye(TM)

Is there a linux driver which doesn't choke when the mouse draws more than 100mA? or some magic settings to xorg/hal/whatever?.

TIA

mike11 · 05-15-2012, 04:25 AM

I'm bumping this thread since I still haven't found a reply.

Anyone solved a similar problem? any ideas?

sparschauer · 06-13-2017, 07:24 AM

Cheap USB mice have a buffer overflow if not always polled and disconnect/reconnect e.g. every minute this way.
The usbhid driver needs the quirk HID_QUIRK_ALWAYS_POLL (0x00000400) then.

Start with kernel boot parameter "usbhid.quirks=0x045e:0x0040:0x00000400". In drivers/hid/usbhid/hid-quirks.c of the kernel source there is a list of all usbhid quirks. I can see that 0x045e:0x0040 is still not included for v4.12. Please report this bug to the linux-usb@vger.kernel.org mailing list to get it fixed. TIA

Also disabling USB auto-suspend by kernel boot parameter "usbcore.autosuspend=-1" should be tried to check if it is a power management issue instead.

rtmistler · 06-13-2017, 08:15 AM

Quote:

Originally Posted by sparschauer

Cheap USB mice have a buffer overflow if not always polled and disconnect/reconnect e.g. every minute this way.
The usbhid driver needs the quirk HID_QUIRK_ALWAYS_POLL (0x00000400) then.

Start with kernel boot parameter "usbhid.quirks=0x045e:0x0040:0x00000400". In drivers/hid/usbhid/hid-quirks.c of the kernel source there is a list of all usbhid quirks. I can see that 0x045e:0x0040 is still not included for v4.12. Please report this bug to the linux-usb@vger.kernel.org mailing list to get it fixed. TIA

Also disabling USB auto-suspend by kernel boot parameter "usbcore.autosuspend=-1" should be tried to check if it is a power management issue instead.

Hi sparschauer and welcome to LQ.

Just a heads up, this thread is about 5 years old. Your advice may be helpful.

One thing to consider is to look at the OP's LQ profile. Right in there near the top it should cite the last time they were active on LQ. For instance in this case, mike11 hasn't signed on to LQ since June of 2012.

No worries, you're advice may help them still by way of alerting them over email that someone answered, or someone else may find it useful. In general the very old questions, it seems to be a toss up whether or not a current solution will be helpful.

Best Regards.

AwesomeMachine · 06-13-2017, 12:35 PM

You could try using a powered USB hub. That will get rid of the possible power problem. And you shouldn't need an xorg.conf section for an ordinary mouse.