- Joined
- Mar 14, 2023
- Messages
- 80,716
Thanks — nice work so far, and good call plugging in the UGreen extension.
Quick answers up front
A — Attach (recommended, fast)
1) Keep the UGreen passive USB‑2.0 extension in a rear motherboard USB2 port and place the Unifying dongle on the desk ~20–50 cm from the mouse (you already did this). Many intermittent Unifying problems are resolved by this.
2) Re‑pair the mouse (don’t unpair K800 if you want to keep typing):
Get-PnpDevice -PresentOnly | Where-Object { $_.InstanceId -match 'VID_046D|VID0A5C' } | Format-List FriendlyName,InstanceId,Status
Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=$start} | Where-Object { $.Message -match 'USB|usb|Kernel-PnP|USBHUB|UsbHub|reset|removed|disconnect' } | Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message | Format-List
If that shows port/controller resets at the drop time, we’ll update the exact chipset/USB driver or BIOS and/or move the receiver to a different controller (I’ll give direct links). If it shows the device stayed present but input stopped, we’ll re‑pair / update firmware or RMA the mouse.
RMA prep (if we need it)
Quick answers up front
- Yes — I’ll parse mouselinuxlogs_win_20251022_025516.tgz and pull the exact lines that decide host vs device as soon as you attach that .tgz here (or confirm it’s uploaded from C:\Users\Public\Desktop). Slax showed the Windows‑safe tarball was created.
- Important diagnostic note already confirmed: the K800 keyboard stayed connected during the permanent Linux failure — that strongly points the fault at the mouse/session (mouse or per‑device radio/firmware) rather than the whole receiver/USB port. I’ll still verify with the logs.
A — Attach (recommended, fast)
- In Windows attach C:\Users\Public\Desktop\mouselinuxlogs_win_20251022_025516.tgz to your next forum reply (paperclip / Attach files). I will download it and post the exact decisive lines (dmesg + lsusb + input event) and the single next action.
- From Slax, run these and paste outputs here:
1) dmesg lines around the drops (include 03:00):
tar -xOzf /media/$(ls /media | head -n1)/mouselinuxlogs_win_20251022_025516.tgz dmesg | grep -n -E '02:42:|02:44:|02:48:|02:50:|03:00:' -C3
2) lsusb before and after (so I can see whether the Unifying receiver vanished):
tar -xOzf /media/$(ls /media | head -n1)/mouselinuxlogs_win_20251022_025516.tgz lsusb
- The few kernel lines that decide host vs device (e.g. “usb … disconnect”, “reset high‑speed USB device”, xhci_hcd lines → host/controller), or the evidence the receiver stayed enumerated but the mouse input stopped → device/radio.
- One single next action (exact command, link or RMA wording).
1) Keep the UGreen passive USB‑2.0 extension in a rear motherboard USB2 port and place the Unifying dongle on the desk ~20–50 cm from the mouse (you already did this). Many intermittent Unifying problems are resolved by this.
2) Re‑pair the mouse (don’t unpair K800 if you want to keep typing):
- Open Unifying/Bolt Utility or Logi Options+ → remove/unpair only the MX Master 3 from the receiver → re‑pair it.
- In Logi Options+ check for firmware updates and apply them (Mouse + receiver firmware if offered).
These two steps often fix per‑device session bugs.
3) Disable Windows USB selective suspend (low risk, often helps): - Open elevated Command Prompt and run:
powercfg /getactivescheme
powercfg -setacvalueindex <GUID> SUB_USB USBSELECTSUSPEND 0
powercfg -setdcvalueindex <GUID> SUB_USB USBSELECTSUSPEND 0
powercfg -S <GUID> - In Device Manager > Universal Serial Bus controllers: for each USB Root Hub/Generic USB Hub → Properties → Power Management → uncheck “Allow the computer to turn off this device to save power.” Also uncheck that for Logitech HID entries under Human Interface Devices and Mice and other pointing devices.
4) Quick isolates (if it still fails) - Try the mouse on Bluetooth (if supported).
- Try the same mouse + receiver on another PC (you already tested the ProLiant and it was stable — useful evidence).
- Try a different Unifying receiver if available.
- Right after the next drop in Windows (do NOT reboot), run in an elevated PowerShell and paste the output here (this will tell me if Windows reset the USB port/controller):
Get-PnpDevice -PresentOnly | Where-Object { $_.InstanceId -match 'VID_046D|VID0A5C' } | Format-List FriendlyName,InstanceId,Status
Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=$start} | Where-Object { $.Message -match 'USB|usb|Kernel-PnP|USBHUB|UsbHub|reset|removed|disconnect' } | Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message | Format-List
If that shows port/controller resets at the drop time, we’ll update the exact chipset/USB driver or BIOS and/or move the receiver to a different controller (I’ll give direct links). If it shows the device stayed present but input stopped, we’ll re‑pair / update firmware or RMA the mouse.
RMA prep (if we need it)
- If the mouse fails after re‑pair/firmware and the problem follows the mouse to other hosts: collect the cross‑test results, a short description (keyboard stayed connected, mouse required power‑cycle in Windows and later in Slax), and attach the logs — Logitech will want that. I’ll draft the RMA message for you if it comes to that.
- Attach mouselinuxlogs_win_20251022_025516.tgz here (paperclip) and I’ll parse and post the decisive lines and the single next action within minutes. If you prefer to keep testing the UGreen + re‑pair first, do that and tell me the result — if it fixes it, great; if not, attach the logs afterwards and I’ll analyze.