Hello all,
I am having trouble with my steelseries arctis nova 5x headset, sometimes for a session everything is fine but also sometimes there are periods of time where the headset looses connection, then 3 seconds later reconnects. Is there anyone who knows perhaps why it is doing this??
Hi, this is a fairly common issue with 2.4GHz USB dongles on Linux and usually comes down to one of a few things:
1. USB autosuspend — the kernel may be putting the dongle to sleep. Check with:
cat /sys/bus/usb/devices/*/power/control
Find your dongle’s device (via lsusb) and set it to on instead of auto:
echo 'on' | sudo tee /sys/bus/usb/devices/X-X/power/control
To make it permanent, add a udev rule.
2. USB 3.0 port interference — USB3 ports/hubs are a well-known source of RF noise in the 2.4GHz band and can cause exactly this kind of intermittent drop/reconnect. Try plugging the dongle into a USB 2.0 port instead, or use a short USB extension cable to move it away from other USB3 devices/hubs.
3. Check dmesg during a dropout:
sudo dmesg -w
and watch it live when the disconnect happens — it’ll tell you if the kernel is resetting the USB device, which points to a driver/power issue rather than pure RF interference.
4. WiFi channel overlap — if you’re on a busy 2.4GHz WiFi channel, that can also cause it. Worth trying a USB extension + different physical placement to rule interference in/out.
Start with the USB port swap and autosuspend check — those fix it in most cases.
So, I think it is the USB autosuspend thing but front your instructions I don’t understand how to set it from auto to on
Sure, let’s do it simply. Open a terminal and run these one at a time:
Step 1 — find your dongle:
lsusb
Look for the line with “SteelSeries” in it and note the ID, e.g. 1038:1234.
Step 2 — find its path (copy-paste this whole block as one command):
for d in /sys/bus/usb/devices/*/; do grep -l "1038" "$d/idVendor" 2>/dev/null; done
This prints something like /sys/bus/usb/devices/2-3/idVendor. The folder part (2-3) is what you need.
Step 3 — check the current setting, using the folder name from step 2:
cat /sys/bus/usb/devices/2-3/power/control
It should print auto.
Step 4 — switch it to on:
echo on | sudo tee /sys/bus/usb/devices/2-3/power/control
It’ll ask for your password, then print on back to confirm it worked.
That’s it — no editing files, just those 4 commands in order. Try using the headset for a while after step 4 and see if it still drops.
(Note: this resets after a reboot. If it fixes the issue, let me know and I’ll show you how to make it permanent with a udev rule.)
When I do step 3, it prints on
Are you still having that problem?
Currently no, but if it starts again I will tell you.
That sounds good; I’m glad everything is running smoothly so far. Don’t hesitate to reply here if it happens again. 
It happened again, I ran the command ```
sudo dmesg -w
And it says in red sticky mixer values
This is an issue for some devices in kernel 7.1. (It happens on my wired USB headset too - I summarised here what’s going on.)
In kernel 7.2, a quirk flag is available to fix it, and it should be possible to apply this to your device using a modprobe config.
For now, do you have a 7.0.x kernel available to boot from?
That said, the “sticky mixer” issue affects volume control primarily - so it may be that your disconnection issues are something separate from that.
This is a known issue: https://bbs.archlinux.org/viewtopic.php?id=314220 with a different USB device. Solution was to add a quirk table entry for the device.
That’s the one I referred to in the post I linked to.
Note that the quirk has been added only in kernel 7.2. I don’t believe there is a solution for this within 7.1.
uhm…Im like quite lost I dont understand if it just there is just no solution in kernal 7.1. or change version something?? im just lost
As far as the “sticky mixer” issue is concerned, I can’t see how to fix that in kernel 7.1. Hopefully not too long until we get 7.2 into Fedora 44 though.
However, I’m not confident that the “sticky mixer” issue is the source of your disconnections. Could be there are two separate issues going on.
It would be useful to try the Fedora 44 live ISO, which is on kernel 6.19.x from what I remember. The “sticky mixer” issue shouldn’t be present there, but do you still see disconnections?
the thing is, as I already said, sometimes for a whole day even maybe 3 days its totally fine but suddenly on one random day it does the disconnections.
I doubt the “sticky mixer” thing is related to that then. That affects the way that volume controls work on the device, and from what I can tell is 100% predictable and consistent.