OpenMandriva Lx version:
OpenMandriva Lx release 6.0 (Vanadium) Rock for x86_64
Desktop environment (KDE, LXQT…):
KDE Plasma Version: 6.3.4
KDE Frameworks Version: 6.13.0
Qt Version: 6.9.0
Kernel Version: 6.14.2-desktop-3omv2590 (64-bit)
Graphics Platform: X11
Description of the issue (screenshots if relevant):
Relevant informations (hardware involved, software version, logs or output…):
I got mine Logitech, Inc. Nano Receiver connected as Bus 001 Device 005: ID 046d:c534
because of this any pendrive mouse or any other usb device connected to a front usb panel has ghudge lags and act crazy
below i paste the all info I manage to get about my “slow pendrive”
durring my issues occured
journalctl -k --since "15 minutes ago" | grep -Ei "0951|1666|Kingston"
mar 05 21:56:28 omv kernel: usb 2-3: New USB device found, idVendor=0951, idProduct=1666, bcdDevice= 1.10
mar 05 21:56:28 omv kernel: usb 2-3: Manufacturer: Kingston
mar 05 21:56:31 omv kernel: scsi 6:0:0:0: Direct-Access Kingston DataTraveler 3.0 PMAP PQ: 0 ANSI: 6
What happens when you connect it to a different usb hub, such as the one in the back?
My last experience with a desktop with a usb hub in the front and another in the back had the usb front hub running slower than the hub in the back.
Another thing to check is in your BIOS/UEFI. Is xHCI handoff “enabled” or set to “auto?” I am assuming yours has such a setting. Not sure why, but manufacturers set it to “disabled” or “manual.”
Basically, if I connect my Logitech Inc. Nano Receiver to any of the USB ports on the back panel of the motherboard, everything is fine. However, when I connect it to the front panel, which is supported by additional USB sockets/connectors on the motherboard, everything falls apart.
Unmounting slows to a halt.
I made a ‘hardware hack’: I used a USB-A to USB-A extension cable, which I connected to a USB port on the motherboard’s back panel, and then plugged the Logitech Inc. Nano Receiver into the other end of it.
However, if I connect two USB flash drives to the front panel, things get messy.
That is correct, and exactly the case yet it should not be the case
It’s enabled; ‘auto’ always means ‘off’ on every motherboard under the sun.
I assume everything discussed so far is USB-A, not USB-C.
My experience with desktop computers: front USB ports are USB 2.0 while back USB ports are 3.x. This alone would explain why the front ports are slow, if true on your hardware.
As a rule, I try to keep things such as USB keyboard and mouse devices connected to the USB 2.0 ports on the computer, not connected to the USB 3.x ports. Then keep USB 3.x devices, such as your Kingston connected to the 3.x ports.
It sounds as if your Nano receiver is USB 2.0, which would not surprise me. I have an old Logitech keyboard and mouse from around 2009 vintage, perfectly happy plugged into a USB 2.0 port, but will slow down everything when plugged into a USB 3.x port on the computer.
But if I use my USB 3.x hub that is designed to run USB 2.0 and 3.x on the same hub, then there is no speed penalty. Some of the newer wall brick powered USB hubs will do that.
Hardware manufacturers are supposed to color code their USB ports, with 2.0 being black and 3.x being blue. That is usually, but not always a quick way to check to see if the port is USB 2.0 or 3.x. But every now and then there is that one manufacturer doing its own thing and ignoring the use of proper colors.
As an option, you could run a USB 3.x powered hub out the back of the computer, seeing as that is where the 3.x ports are located. Then you can connect all kinds of things to the hub and not worry about overloading the computer’s power supply and maintain speed. USB hubs have a data cord long enough to reach around to the front of the computer. Yes, it isn’t a pretty option. But sometimes sacrificing good looks must be made for what works.
I have 3 usb ports on front 2x USB3.0 and 1x usb2.0. If I andertood you corectly if I put nano reciver where it supposed to go → USB2.0 port which was exactly my case I will have speed limitation on all USB 3.0.
Ok then it is propably software limit Fallback / Downspeeding on driver level. USB 3 and usb3 connectors on motherboard are separated and totally difrent but if the same firmware / driver runs them then, that is another story
Three USB ports on the front, two are 3.x and one is 2.0. My best guess is all three ports share the same bus. When you attach a 2.0 device, the speed drops for all three in order to maintain 2.0 compatibility. Why? The manufacturer is trying to cut costs and not provide the required hardware to allow 3.x speed when a 2.0 device is attached to the 2.0 port. I have seen this happen before, most often on desktop hardware, less often on laptops where space restrictions on the case force placing ports on the left and right side of the case.
I believe getting a powered USB 3.x hub that has provisions to cope with a 2.0 device attached to one of the ports without slowing down the rest of the hub is your best bet. Or just start using the ports in the rear and use a USB 3.x extension cord for each port.
Yes, a common sheared bus may also be the issue here.
That would be weird as heck because my motherboard is not some basic one. If that is the case, I will never buy anything Asrock again.
I must check if the same issue occurs on other distributions and Windows.
Just curious did you check lsusb to verify it is the same bus?
lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 048d:5702 Integrated Technology Express, Inc. RGB LED Controller Bus 001 Device 003: ID 05e3:0608 Genesys Logic, Inc. Hub Bus 001 Device 004: ID 8087:0aa7 Intel Corp. Wireless-AC 3168 Bluetooth Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub Bus 003 Device 003: ID 2109:2822 VIA Labs, Inc. USB2.0 Hub Bus 003 Device 005: ID 1a86:8072 QinHeng Electronics WCH.CN Bus 003 Device 006: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub Bus 003 Device 012: ID 2109:2817 VIA Labs, Inc. USB2.0 Hub Bus 003 Device 013: ID 05e3:0608 Genesys Logic, Inc. Hub Bus 003 Device 014: ID 2109:8817 VIA Labs, Inc. USB Billboard Device Bus 003 Device 016: ID 093a:2533 Pixart Imaging, Inc. Nulea M504 Gaming Mouse Bus 003 Device 017: ID 1c4f:0043 SiGma Micro USB Keyboard Bus 003 Device 018: ID 1b3f:2008 Generalplus Technology Inc. USB Audio Device Bus 003 Device 019: ID 2dc8:310a 8BitDo 8BitDo Ultimate 2C Wired Controller Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 004 Device 003: ID 2109:0822 VIA Labs, Inc. USB3.1 Hub Bus 004 Device 004: ID 0bda:0411 Realtek Semiconductor Corp. Hub Bus 004 Device 005: ID 154b:00ed PNY USB 3.0 FD Bus 004 Device 006: ID 2109:0817 VIA Labs, Inc. USB3.0 Hub
The Linux Foundation x.x is the root of that hub in question, and for the Bus section you can see that all those devices are on the same Bus and as other commenters noted it will operate at the slowest device speed of any device on that bus.
completly difrent buses. As long I commect keybord reciver and any usb HDD it is fine Yet if I connect pendrive and reciver my keybord freazes, if it is conected to a front panel. I cannot even go with lsusb. But, if it is connected to the mobo usb on “backplate” everything is fine.
Wierd ?!
No keybord reciver on fronpanel for my PC LOL
or Unmouting pendrive take ages go to infinity, and i cant even peak one, it is one or the other at random
Definitely a strange issue, I would continue with your prior plan to check other distros and windows to narrow it down to a hardware issue or OS level issue.
Could also be something weird with your pendrive, have you tried it on other machines with OM?
Nope, I have two laptops as well as this PC. At least I can use my Lenovo Thinpad to test this out. I won’t even touch my old HP with Nvidia. That HP is crazy; it’s like there are dragons and gnomes living inside it. You can use any distribution you like on it, as long as it’s Fedora. Every other distro will somewhat work or will not work at all.
So I will nuke my Thinkpad put OM in it, and see what will happen.
Ps I have the other minor issue with OM. But for now I must try to trace this particular crazyness
PS It is same with every pendrive I have. So most probably it is not a pendrive issue at all. (99% of my pendrives are fat 32 few of them are ext4 and 1 is ntfs). All of them have this issue
We do package Solaar / Usage Documentation which can help with managing and pairing Logitech devices and comes with udev rules which facilitates it’s device access including with Logitech’s USB / Bluetooth controllers/receivers.
dnf info solaar
I use solaar with my wired/wireless Logitech Ergo MX Trackball and with another Logitech USB controller/receiver for a wireless Keyboard/Mouse set on another machine and it works good.
I’m not writing that it will be a magic fix to the issues you have encountered as they could be hardware related (bluetooth and some usb storage devices can also be notoriously troublesome) but there is a chance it might help and would give you a software solution to better monitor & adjust those devices with more per device options than are otherwise exposed in the DE.