You’re right to be annoyed — sorry for the back‑and‑forth. I don’t yet have the internal text from the tarball available here, so I can’t paste the exact log lines myself. I can, however, give you the precise commands to extract the decisive snippets on your side (Windows or Slax) and the corrected PowerShell capture to run immediately after the next drop. Paste the outputs here (or attach those extracted files) and I will extract the exact kernel/lsusb/input lines and tell you the single next action.
Short status summary from what I can read so far
- Your Windows Get‑PnpDevice output shows the Logitech devices still listed OK (the receiver stayed present). That already strongly suggests a per‑device radio/session loss rather than the USB controller removing the whole device — but we still need the kernel dmesg + lsusb + event snippets to be 100% certain. The commands below will produce those snippets.
A — If you want to extract the decisive snippets from the tarball on Windows (fast)
1) List the files inside the tarball (to see internal names):
Open an elevated PowerShell and run:
tar -tzf "C:\Users\Public\Desktop\mouselinuxlogs_win_20251022_025516.tgz" | Select-String -Pattern "dmesg|lsusb|input|mouse|event"
2) Extract and filter the dmesg lines we need (replace <internal_dmesg_path> with the path from step 1):
tar -xOzf "C:\Users\Public\Desktop\mouselinuxlogs_win_20251022_025516.tgz" "<internal_dmesg_path>" | Select-String -Pattern "02:42:|02:44:|02:48:|02:50:|03:00:|usb|xhci|disconnect|reset" -Context 3 > "$env:USERPROFILE\Desktop\dmesg_snippet.txt"
(Then open the file on your Desktop and attach it or paste its contents.)
3) Extract the lsusb before/after snapshots (replace internal names you saw):
tar -xOzf "C:\Users\Public\Desktop\mouselinuxlogs_win_20251022_025516.tgz" "<internal_lsusb_before>" > "$env:USERPROFILE\Desktop\lsusb_before.txt"
tar -xOzf "C:\Users\Public\Desktop\mouselinuxlogs_win_20251022_025516.tgz" "<internal_lsusb_after>" > "$env:USERPROFILE\Desktop\lsusb_after.txt"
Attach dmesg_snippet.txt, lsusb_before.txt and lsusb_after.txt (paperclip). I’ll parse and paste the exact decisive lines.
B — If you prefer to do the extraction in Slax (commands you can paste in root shell)
1) List internal paths (so you can use the correct names):
tar -tzf /media/$(ls /media | head -n1)/mouselinuxlogs_win_20251022_025516.tgz | egrep -i 'dmesg|lsusb|input|mouse|event' -n
2) Extract dmesg lines around the events (replace the internal path shown above):
tar -xOzf /media/$(ls /media | head -n1)/mouselinuxlogs_win_20251022_025516.tgz <internal_path_for_dmesg> | grep -n -E '02:42:|02:44:|02:48:|02:50:|03:00:|usb|xhci|disconnect|reset' -C3
3) Extract lsusb before/after (replace internal names):
tar -xOzf /media/$(ls /media | head -n1)/mouselinuxlogs_win_20251022_025516.tgz <internal_lsusb_before>
tar -xOzf /media/$(ls /media | head -n1)/mouselinuxlogs_win_20251022_025516.tgz <internal_lsusb_after>
Paste those outputs here (they’re small). I’ll extract the exact lines and give the single next action.
C — If the mouse drops again right now in Windows: run this corrected, decisive PowerShell capture (Admin)
You tried this earlier but had a typo ($. instead of $_). Run this immediately after the next drop (do NOT reboot) — it will capture device list + recent System events that mention USB/hub resets. Paste the full output here.
$start = (Get-Date).AddMinutes(-10)
Get-PnpDevice -PresentOnly | Where-Object { $_.InstanceId -match 'VID_046D|VID
0A5C' } | 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
What I will look for and what each outcome means (so you know what you’ll get back)
- If dmesg / System events contain “usb … disconnect” or xhci_hcd / port reset messages at the drop time: that’s a host/controller/port reset → update chipset/USB drivers, BIOS, or move receiver to a different root hub / use the UGreen permanently.
- If lsusb still shows the Unifying receiver but the mouse input/event stream halts (no events): that’s a mouse radio/session problem → re‑pair (done), firmware (none available), try another Unifying receiver, or RMA the mouse if the fault follows the mouse to other hosts.
Immediate recommended practical step while we wait for logs
- Keep the receiver on the UGreen passive USB‑2.0 extension in a rear motherboard USB2 port (you already did this) and use for a few hours. If the drops stop, keep it as the long‑term fix. If it continues to drop, run the PowerShell capture above immediately after the next drop and paste results.
If you want me to parse the tarball for you right now
- Attach the Windows tarball file C:\Users\Public\Desktop\mouselinuxlogs_win_20251022_025516.tgz to your forum reply (paperclip) — that’s the fastest path. I will download it and paste the exact decisive lines within minutes.
Again — sorry for the earlier attachment confusion. Tell me which extraction path you’ll use (Windows tar extract, Slax extract, or paste the PowerShell output after next drop) and I’ll act immediately on the output you paste or the file you attach.
