USB mouse reconnects constantly with spamming on console

H

hackee

Hi guys.
I'm getting spammed with following messages on console, stating my usb mouse keeps get connected/disconnected every several seconds:
Code: 
ugen1.3: <Logitech USB Optical Mouse> at usbus1 (disconnected)
ums0: at uhub3, port 2, addr 3 (disconnected)
ums0: detached
ugen1.3: <Logitech USB Optical Mouse> at usbus1
ums0 on uhub3
ums0: <Logitech USB Optical Mouse, class 0/0, rev 2.00/72.00, addr 3> on usbus1
ums0: 3 buttons and [XYZ] coordinates ID=0
...

Here's my usbconfig output:
Code: 
$ usbconfig list
ugen0.1: <XHCI root HUB Intel> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA)
ugen1.1: <EHCI root HUB Intel> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen2.1: <EHCI root HUB Intel> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen1.2: <product 0x0024 vendor 0x8087> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen2.2: <product 0x0024 vendor 0x8087> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen1.4: <Integrated Camera Chicony Electronics Co., Ltd.> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (200mA)
ugen1.3: <USB Optical Mouse Logitech> at usbus1, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA)

Code: 
$ usbconfig -vd ugen1.3
ugen1.3: <USB Optical Mouse Logitech> at usbus1, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA)
ugen1.3.0: ums0: <Logitech USB Optical Mouse, class 0/0, rev 2.00/72.00, addr 3>

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0200
  bDeviceClass = 0x0000  <Probed by interface class>
  bDeviceSubClass = 0x0000
  bDeviceProtocol = 0x0000
  bMaxPacketSize0 = 0x0008
  idVendor = 0x046d
  idProduct = 0xc077
  bcdDevice = 0x7200
  iManufacturer = 0x0001  <Logitech>
  iProduct = 0x0002  <USB Optical Mouse>
  iSerialNumber = 0x0000  <no string>
  bNumConfigurations = 0x0001
Anybody knows how to fix the issue?
 
What hardware is the USB port to which the mouse is connected? Motherboard, keyboard, monitor, laptop port, USB hub?

Have you tried another USB port? The mouse alone, disconnecting all other external devices (if present)?

Does the mouse work as intended on other OSs?
 
T-Daemon said:
What hardware is the USB port to which the mouse is connected? Motherboard, keyboard, monitor, laptop port, USB hub?

Have you tried another USB port? The mouse alone, disconnecting all other external devices (if present)?
Click to expand...
It's Thinkpad T430. I don't use any other external devices, only mouse.
The mouse produces same messages on all usb ports, but works fine with X or with moused.
I thought maybe "pwr=SAVE" on uhubs could trigger this behaviour, but couldn't power them on. Only
ugen1.2: <product 0x0024 vendor 0x8087>; at usbus1, ugen2.2: <product 0x0024 vendor 0x8087> at usbus2 can be powered on, but that don't affect the result.
 
hackee said:
unfortunately here with me I get only this one.
Click to expand...
Ahh. My reason for asking was to rule out a failing device. connect/disconnects on USB devices are sometimes power related (device drawing more than the bus can supply), sometimes a failing device.
If the device is a wireless mouse (I use them on laptops) try a fresh battery in the mouse.
 
Can't provide any useful hard data (such as USB IDs) but I have a cheap HP mouse at the office which does the exact same thing.
 
jbo@ said:
Can't provide any useful hard data (such as USB IDs) but I have a cheap HP mouse at the office which does the exact same thing.
Click to expand...
I've seen similar in the past, sometimes it's hardware as a system boots. Different things in the path may get reset or enabled/disabled (hubs, ports on hubs) during boot so things may flap.
Another test I've done is: shutdown, power off, remove usb device (like a mouse), power on, wait for system fully up, then plug in mouse and see if it flaps. Behaviour is often more consistent this way. Yes, not ideal for a UI/UX POV, but from a debugging it helps.

Laptops: do problems occur from a power off state or from a suspend state? Completely different things in "is my device initialized" context.
 
What I've found up till now. First I've removed these options from kernel:
Code: 
#options                EVDEV_SUPPORT
#device                 evdev
#device                 uinput
no effect, everything works, but messages continue to pop up. Also I removed ums driver from kernel, but it gets compiled in by default, so I decided not to proceed with "nodevice ums". Then I've found a wireless mouse. It just switched off in several seconds and no any messages appeared. looks like it didn't spam me. But I prefer a wired mouse because it's more convenient. Then I've found another wired mose. Here it looks a but complicated. At first it also showed these messages:
Code: 
ugen1.3: <YSPRINGTECH USB OPTICAL MOUSE> at usbus1
ums0 on uhub3
ums0: <YSPRINGTECH USB OPTICAL MOUSE, class 0/0, rev 2.00/0.00, addr 3> on usbus1
ums0: 3 buttons and [XYZ] coordinates ID=0
ugen1.3: <YSPRINGTECH USB OPTICAL MOUSE> at usbus1 (disconnected)
ums0: at uhub3, port 2, addr 3 (disconnected)
ums0: detached
but at much slower pace, maybe once per 1-2 minute. Also when I enabled hw.usb.usbhid.enable=1, after reboot i didn't notice any new messages. Then I removed it from sysctl.conf, and after reboot didn't notice them either. So I believe that my mouse has some impact on permanent connection/disconnection. But why new mouse behave so bizarre!? Dunno. Let's see how it'll behave next.
 
When it fails, can you disconnect/reconnect from the usb port and see if it works normally then?

I recently had that issue and believe it was a mouse gone bad but this makes me wonder.
 
drhowarddrfine said:
When it fails, can you disconnect/reconnect from the usb port and see if it works normally then?

I recently had that issue and believe it was a mouse gone bad but this makes me wonder.
Click to expand...
as I said, it works fine, you may disconnect and reconnect it manually, no problem, moused and X work as expected.
I launched devd -d on console and noticed that it reacts on reconnectons by destroyin and creating /dev/ums0 and /dev/usb/1.3.[01] devices. But it looks that it only reacts.
 
I have an Ivy Bridge laptop that sometimes reconnects random USB devices if I swipe my hand too-hard on a plastic table :p (large static in the room can cause it)

I had a USB-C mouse also do it too with a certain cable but fine with others.


I'd try disabling CPU virtualization (disables XAPIC and USB controllers going through IOMMU)
 
virtalization is disabled in BIOS.
upd.
- disabling EVDEV_SUPPORT evdev uinput actually breaks X, but don't affect spamming.
- compiling ums in-kernel or as a module don't affect spamming.
- and hw.usb.usbhid.enable=1 don't affect spamming.
- unloading uhid module don't affect spamming.
So I tend to belive it's a mouse. New one don't spam so hard so i'm switching on it.
 
I have had the same thing, with a Logitech M90 mouse. I didn't pay any attention to it. It has stopped doing that, but the mouse also has stopped working.

The mouse has power, but isn't showing up in usbconfig. Just looking in /var/log/messages shows some USBish messages when I fiddle with it.

So, at least in my case, I believe it is/was some bad data wires in the mouse's cable.
 
hackee said:
Hi guys.
I'm getting spammed with following messages on console, stating my usb mouse keeps get connected/disconnected every several seconds:
Code: 
ugen1.3: <Logitech USB Optical Mouse> at usbus1 (disconnected)
ums0: at uhub3, port 2, addr 3 (disconnected)
ums0: detached
ugen1.3: <Logitech USB Optical Mouse> at usbus1
ums0 on uhub3
ums0: <Logitech USB Optical Mouse, class 0/0, rev 2.00/72.00, addr 3> on usbus1
ums0: 3 buttons and [XYZ] coordinates ID=0
...

Here's my usbconfig output:
Code: 
$ usbconfig list
ugen0.1: <XHCI root HUB Intel> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA)
ugen1.1: <EHCI root HUB Intel> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen2.1: <EHCI root HUB Intel> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen1.2: <product 0x0024 vendor 0x8087> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen2.2: <product 0x0024 vendor 0x8087> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen1.4: <Integrated Camera Chicony Electronics Co., Ltd.> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (200mA)
ugen1.3: <USB Optical Mouse Logitech> at usbus1, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA)

Code: 
$ usbconfig -vd ugen1.3
ugen1.3: <USB Optical Mouse Logitech> at usbus1, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA)
ugen1.3.0: ums0: <Logitech USB Optical Mouse, class 0/0, rev 2.00/72.00, addr 3>

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0200
  bDeviceClass = 0x0000  <Probed by interface class>
  bDeviceSubClass = 0x0000
  bDeviceProtocol = 0x0000
  bMaxPacketSize0 = 0x0008
  idVendor = 0x046d
  idProduct = 0xc077
  bcdDevice = 0x7200
  iManufacturer = 0x0001  <Logitech>
  iProduct = 0x0002  <USB Optical Mouse>
  iSerialNumber = 0x0000  <no string>
  bNumConfigurations = 0x0001
Anybody knows how to fix the issue?
Click to expand...

I had the same problem, and I can't remember how I solved the issue, either by using a different MS mouse or perhaps by adding the following lines to /etc/rc.conf:

Code: 
hald_enable="YES"
moused_enable="YES"
 
On which version of FreeBSD is this happening?

There is a open problem report from 2022-03-28 [1], reporting similar or same disconnects by multiple users, still active (last comment on 2025-07-09). The PR reporter claims having no problems on past CURRENT, now 15.0-BETA1 at the time of this writing (see comment # 134).

If that's not the version you have on the Thinkpad T430, try that (OS installed on a USB stick, installer media, for example, should do). If it is and there are still those disconnects, maybe drop a comment to the bug report.

[1] Bug 262882 - USB disconnects repeatedly, losing all attached devices on that USB hub
 
T-Daemon said:
On which version of FreeBSD is this happening?

There is a open problem report from 2022-03-28 [1], reporting similar or same disconnects by multiple users, still active (last comment on 2025-07-09). The PR reporter claims having no problems on past CURRENT, now 15.0-BETA1 at the time of this writing (see comment # 134).

If that's not the version you have on the Thinkpad T430, try that (OS installed on a USB stick, installer media, for example, should do). If it is and there are still those disconnects, maybe drop a comment to the bug report.

[1] Bug 262882 - USB disconnects repeatedly, losing all attached devices on that USB hub
Click to expand...
14.3-Release. I'm not going to switch to current right now, but new mouse behaves more politely) so I'll stick with it. Gave my old mouse to daughter, she's using it on her Dell's LinuxMint without any problems.
 
+1
Same here, i see those pesky message on the console
-----
Nov 4 08:19:11 fbs2 kernel: ugen0.2: <Logitech USB Optical Mouse> at usbus0 (disconnected)
Nov 4 08:19:11 fbs2 kernel: ums0: at uhub0, port 1, addr 1 (disconnected)
Nov 4 08:19:11 fbs2 kernel: ums0: detached
Nov 4 08:19:13 fbs2 kernel: ugen0.2: <Logitech USB Optical Mouse> at usbus0
Nov 4 08:19:13 fbs2 kernel: ums0 on uhub0
Nov 4 08:19:13 fbs2 kernel: ums0: <Logitech USB Optical Mouse, class 0/0, rev 2.00/72.00, addr 8> on usbus0
Nov 4 08:19:13 fbs2 kernel: ums0: 3 buttons and [XYZ] coordinates ID=0
Nov 4 08:20:13 fbs2 kernel: ugen0.2: <Logitech USB Optical Mouse> at usbus0 (disconnected)
Nov 4 08:20:13 fbs2 kernel: ums0: at uhub0, port 1, addr 8 (disconnected)
Nov 4 08:20:13 fbs2 kernel: ums0: detached
----
. FreeBSD fbs2 14.3-RELEASE FreeBSD 14.3-RELEASE releng/14.3-n271432-8c9ce319fef7 GENERIC amd64
. Logitech mouse M90
. ThinkCentre M710s
. Message stops in /var/log/messages as soon as a startx (startplasma-x11)
 
This solves it for me, i see now the mouse pointer on console. i did not need mouse on console but i like it more than the previous recurring message. bye.
----- /etc/rc.conf --------------
# . default config, i think i found it there from install, not 100% sure
# moused_nondefault_enable="NO"
# . new cofig, suppresses the mouse message, enables the mouse
moused_nondefault_enable="yes"
-----------------------------------------
 
I've seen this behaviour of constantly/frequently dropping USB-connections on my laptop (Thinkpad T16 gen1) with my yubikey and when using my phone via usb-tethering as a network uplink (ue0).
The issue apperead and disappeared over the various patch versions (and maybe package updates?) during the last few months. I haven't found the time to really investigate the issue, so I'm not sure if it was triggered by some third party software (e.g. pcscd comes to mind) or the base OS.

Currently (14.3-RELEASE releng/14.3-n271432-8c9ce319fef7 GENERIC amd64) the laptop is in a usable state[*], at least regarding the yubikey. When the problem was present, I had a time window of max 2-3 minutes where the yubikey was usable, then I had to re-plug it (and kill -9 gpg-agent because that thing craps itself since a few versions when the smartcard/yubikey is disconnected) so it would work for another 2-3 minutes (max).

AFAIR, mouse and keyboard were never affected though, and IIRC using a USB-hub on the USB-C port made it a lot worse than using one of the USB-A. Thanks to the beancounters that crippled the Thinkpad to only 2 USB-A ports I have to constantly mock around with a USB-C hub though, so there's always this additional possible source of error...


[*] apart from frozen screen and unusable input when closing the lid during boot/before login. Seems to be related to some energy saving crap that gets disabled as soon as the xfce power manager is loaded...
 
You must log in or register to reply here.
Back
Top