I’m having these random, short system freezes while using my laptop. It sometimes results in double typing of a letter while using the terminal, or freeze and then speedup of the voice coming from Discord while smartworking.
I searched though journalctl and dmesg, but I couldn’t find anything useful, neither something like a kernel-panic or a UI-related problem.
Can someone point me out to a solution or an hint? It can be very annoying sometimes, especially while typing.
-- Logs begin at Fri 2020-10-02 18:19:06 CEST, end at Tue 2020-10-27 15:02:44 CET. --
ott 27 11:37:28 PCABS systemd-udevd[332]: could not read from '/sys/module/pcc_cpufreq/initstate': No such device
ott 27 11:37:30 PCABS kernel: usb 1-2.3: 4:1: cannot set freq 48000 to ep 0x2
ott 27 11:37:30 PCABS kernel: usb 1-2.3: 4:2: cannot set freq 48000 to ep 0x2
ott 27 11:37:30 PCABS kernel: usb 1-2.3: 2:3: cannot get min/max values for control 2 (id 2)
ott 27 11:37:44 PCABS NetworkManager[732]: <error> [1603795064.3459] device (wlan0): addrconf6: failed to start neighbor discovery: failure creating libndp socket: Address family not supported by protocol (97)
ott 27 11:38:33 PCABS pulseaudio[1559]: ALSA woke us up to write new data to the device, but there was actually nothing to write.
ott 27 11:38:33 PCABS pulseaudio[1559]: Most likely this is a bug in the ALSA driver 'snd_usb_audio'. Please report this issue to the ALSA developers.
ott 27 11:38:33 PCABS pulseaudio[1559]: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
It froze like twice while writing this reply, ran journalctl -b -p err but it gives me the same output.
Do you have sof-firmware installed. This looks like one of those Intel audio chips that require sof-firmware. Usually the audio is not working at all or something’s not working? Maybe install it and see if this is the issue?
Edit: You’ll need to reboot I think to have it load the modules.
I don’t know if sof-firmware did the trick, but now it’s two days without any stuttering. For reference, I downloaded TLPUI too and disabled USB autosuspension (I’m always using Steelseries USB headset) and tweaked the power management a bit.
Sorry for the late answer, but I had a couple of busy days at work/home!
journalctl -b -p err
-- Logs begin at Fri 2020-10-02 18:19:06 CEST, end at Tue 2020-11-03 09:41:09 CET. --
nov 03 09:06:57 PCABS NetworkManager[677]: <error> [1604390817.9858] device (wlan0): addrconf6: failed to start neighbor discovery: failure creating libndp socket: Address family not supported by protocol (97)
I’m back here because the issue came back after latest kernel updates. So I decided to switch to LTS and I’m getting this in journalctl -b -p err
-- Logs begin at Fri 2020-10-02 18:19:06 CEST. --
nov 10 10:55:02 PCABS kernel: usb 1-3.3: 4:1: cannot set freq 48000 to ep 0x2
nov 10 10:55:02 PCABS kernel: usb 1-3.3: 4:2: cannot set freq 48000 to ep 0x2
nov 10 10:55:02 PCABS kernel: usb 1-3.3: 2:0: cannot get min/max values for control 2 (id 2)
nov 10 10:55:03 PCABS systemd-udevd[327]: controlC1: /usr/lib/udev/rules.d/78-sound-card.rules:5 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3.3/1-3.3:1.0/sound/card1/controlC1/../uevent}, ignoring: No such file or directory
So I think it related to the USB audio card of the headset. These errors are not triggered when on latest non-LTS kernel.
EDIT: Adding some dmesg | grep usb logs (on LTS, for now):
[ 3.083153] usb 1-3.3: new full-speed USB device number 6 using xhci_hcd
[ 3.246571] usb 1-3.3: New USB device found, idVendor=1038, idProduct=1294, bcdDevice= 1.11
[ 3.246573] usb 1-3.3: New USB device strings: Mfr=4, Product=5, SerialNumber=0
[ 3.246574] usb 1-3.3: Product: Arctis Pro Wireless
[ 3.246575] usb 1-3.3: Manufacturer: SteelSeries
...
[ 4.134910] hid-generic 0003:1038:1290.0001: hiddev0,hidraw0: USB HID v1.11 Device [SteelSeries Arctis Pro Wireless] on usb-0000:00:14.0-3.2/input0
[ 4.134985] hid-generic 0003:1038:1290.0002: hiddev1,hidraw1: USB HID v1.11 Device [SteelSeries Arctis Pro Wireless] on usb-0000:00:14.0-3.2/input1
[ 4.135813] input: SteelSeries Arctis Pro Wireless Consumer Control as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3.3/1-3.3:1.5/0003:1038:1294.0003/input/input15
[ 4.213360] input: SteelSeries Arctis Pro Wireless as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3.3/1-3.3:1.5/0003:1038:1294.0003/input/input16
[ 4.213650] hid-generic 0003:1038:1294.0003: input,hiddev2,hidraw2: USB HID v1.11 Device [SteelSeries Arctis Pro Wireless] on usb-0000:00:14.0-3.3/input5
[ 4.408438] usb 1-3.3: 4:1: cannot set freq 48000 to ep 0x2
[ 4.409487] usb 1-3.3: 4:2: cannot set freq 48000 to ep 0x2
[ 4.410604] usb 1-3.3: 2:0: cannot get min/max values for control 2 (id 2)
[ 4.410668] usbcore: registered new interface driver snd-usb-audio
[ 4.430001] usb 1-3.3: USB disconnect, device number 6
[ 5.283139] usb 1-3.3: new full-speed USB device number 7 using xhci_hcd
[ 5.455157] usb 1-3.3: New USB device found, idVendor=1038, idProduct=1294, bcdDevice= 1.11
[ 5.455158] usb 1-3.3: New USB device strings: Mfr=4, Product=5, SerialNumber=0
[ 5.455159] usb 1-3.3: Product: Arctis Pro Wireless
[ 5.455160] usb 1-3.3: Manufacturer: SteelSeries
[ 5.752626] input: SteelSeries Arctis Pro Wireless Consumer Control as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3.3/1-3.3:1.5/0003:1038:1294.0005/input/input28
[ 5.813351] input: SteelSeries Arctis Pro Wireless as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3.3/1-3.3:1.5/0003:1038:1294.0005/input/input29
[ 5.813669] hid-generic 0003:1038:1294.0005: input,hiddev2,hidraw3: USB HID v1.11 Device [SteelSeries Arctis Pro Wireless] on usb-0000:00:14.0-3.3/input5
I will try to use non-LTS kernel ASAP and report back if it doesn’t trigger those errors.
EDIT2: Now I’m getting the same usb errors on 5.9.6-arch1-1. Very strange.
I am no sound expert but alsa has been glitchy lately. These look like the system is trying to use an output frequency not supported by the headset.
Ok so it looks like the default value is set to 48khz. I think this is just a warning as it should default to a different value.
High quality resampling
When software mixing is enabled, ALSA is forced to resample everything to the same frequency (48 kHz by default when supported). By default, it will try to use the speexrate converter to do so, and fallback to low-quality linear interpolation if it is not available[6]. Thus, if you are getting poor sound quality due to bad resampling, the problem can be solved by simply installing the alsa-plugins package.
For even higher quality resampling, you can change the default rate converter to speexrate_medium or speexrate_best. Both perform well enough that in practice it does not matter which one you choose, so using the best converter is usually not worth the extra CPU cycles it requires.
To change the default converter place the following contents in your ~/.asoundrc or /etc/asound.conf:
Still digging
edit-I need the model of steelseries headset you are using @Pipodi
edit2-Sorry you gave it in the output above.
Ok so the maximum supported frequency for that headset is 40Khz according to the manufacturer.
As I said I am no expert so maybe wait for someone else to give advice.
eidt 3- last one i promise. Disable TLP to make sure it is not putting that USB device to sleep.
@Pipodi
I wonder if the sof-firmware needs to be installed also when you are booted into the lts kernel? I guess you could check that. Not sure if it is system wide when installed.
Edit: Did you install alsa-plugins as the message said?
I’m pretty sure I’ve disabled the USB power suspend from TLPUI, but now I’ve disable TLP service completely. I’ll try this “extreme” solution for a couple of days and then I’ll try to re-activate something. Maybe I’ll post my TLP config later, so we can debug and spot something wrong.