I removed my audio expansion module, blew hard in the port and the plug, replaced it, installed the most recent Ubuntu package updates then rebooted - haven’t had the problem since. I’ve no idea how to trigger this problem but it only happened once for me. I use my audio jack every day.
When was the issue? I’ve found that depending on the kernel version it can take quite some time to repeat. The longest I’ve gone between instances is roughly a week
Some quick updates: I’ve gone ahead and switched back to stable since the 6.16 kernel became available in backports and the rest of it wasn’t really needed, or so I thought. Today I decided to try the backports version of pipewire+the 6.12 kernel since as mentioned previously that had a higher incidence rate in my testing. My machine has been running for about an hour and I haven’t had an occurence yet, which usually happens by now. I’ll need to run it for longer to be sure but maybe somebody can verify that the pipewire version has an effect? Thanks
1 Like
Actually I can only verify the opposite. While I have been on Testing the whole time, pipewire rarely ever gets an update and certainly none that I could trace this issue back to. On the other hand, the kernel version has vast influence, with some kernel versions having this issue on a daily basis or even more often.
To verify, I’m currently testing with the Fedora Kernel, which I’ve compiled as a Debian package, though I can’t be sure if I compiled their sources with all patches they include or if it was just a copy of the upstream Kernel they ship as part of one of their packages for some reason. I’m usually on a 6-8 day cyclus, so by mid next week I should know for sure if that helped or not.
I see. I’ll put a pin in that line of reasoning then. Which version of the fedora kernel have you compiled? Perhaps I can pinpoint an exact commit?
I’ve compiled 6.16.7. And no, you can’t. Whatever the fix is - if it’s even only in the kernel - had been present in at least Fedora 41 and 42. While I can’t tell with which kernel versions they released, it’s possible 41 released with a kernel just old enough to simply not being affected. It released in late October last year, but I think this didn’t start appearing before November or December. While 42 should be affected, it’s not, but that also doesn’t help. You’d have to find a patch/change introduced in 42 that hasn’t been upstreamed. But also who’s to say that the fix is an actual patch to the kernel sourcecode itself? The fix could simply be through difference in configuration, e. g. Fedora decided to compile something as module, while upstream and Debian don’t, or they set some other parameter differently. If the config has any influence on the result will be part of my tests too.
I can confirm, running Fedora’s kernel compiled with their own config, has now successfully prevented this from happening for me for the past ~11 days. Far longer than it ever took with affected Debian (or upstream) kernels. Doing this has some downsides though, I’ll see if compiling it with Debian’s config yields better results or if the issues are caused by Fedora’s patches.
1 Like
Interesting. I may well attempt to do the inverse. I managed to identify a few things that were built as modules in debian but built in in fedora, in particular usb_xhci_pci, usb_xhci_hcd, and usb_role_switch. Notably the former had this commit attached: Fix USB_XHCI_PCI regression (eb69261b) · Commits · cki-project / kernel-ark · GitLab
I’m still looking for the particular regression that it mentions and why the others are built in, but since the audio card would have to go through those drivers it may be relevant
Good to know, thanks. I would have looked at the deeper differences only at a later point. By that theory, Fedora’s sources compiled with Debian’s config should not prevent the issue from appearing. If that’s true, it should show up in much less than a week. Whatever this issue is, back when I live booted Fedora for testing things and then returning back to Debian it almost seemed like the issue couldn’t wait to reappear.
And it just happened. I’m applying your suggested changes now too and see what comes of it.
Edit: it doesn’t seem possible. When I switch CONFIG_USB_XHCI_HCD, CONFIG_USB_XHCI_PCI, CONFIG_USB_XHCI_PCI_RENESAS and CONFIG_USB_ROLE_SWITCH from m to y and compile, only the role switch config stays at y, the rest is automatically switched back to m.
I ran into that when I was building too. You need to set host-side usb to built in as well. I believe the specific flags are CONFIG_USB and CONFIG_USB_COMMON outside of menuconfig
EDIT: It slipped my mind before the initial post, but I also set the equivalent EHCI flags to built-in as well. I don’t believe the audio jack module runs over USB 2.0 so it may not matter, but I may as well put it out there
Right, this worked. Trying it out now.
I’ve got some bad news. While these configs may be part of Fedora’s fix, they aren’t the fix. I’ve compiled 6.17.1 straight from upstream sourced just yesterday, using Debian’s config with just these changes applied. Today the issue already reappeared. Right now, to be able to tell if maybe more config changes may be what collectively fixed things (or if Fedora actually changed code of the upstream kernel to fix things), I’m running on Fedora’s 6.16.7 sourced, again compiled with Debian’s config including Fedora’s fixes. If that prevents the issue from happening, only the made changes can have had an influence. Afterwards I will compile these sources again with the normal Debian config I usually use. If this still prevents the issue from happening, the fix must be solely in the source code.
I can save you some time with the source code avenue of things. I ran a diff check between the fedora 6.16.10 source and the vanilla source for the same. Barring some utility scripts missing from fedora’s version, they’re completely identical. Whatever the fix is, it’s either in the patch files or the config.
With other words the changes can only be inside the config. What I’m compiling is the content of the linux-6.16.7.tar.xz tarball located inside the kernel-6.16.7-200.fc42.src.rpm package, with the config config-6.16.7-fedora located in the kernel-core-6.16.7-200.fc42.x86_64.rpm. While I don’t have the original upstream 6.16.7 archive anymore (and I don’t know how to get it through git) they will probably be identical too then. At least I don’t see any patchfiles in there.
The .patch files were in the rpm, not the tarball. It should be named patch-6.16-redhat.patch or something similar. There’s also a patchlist.changelog file that’s a bit more human readable. I didn’t see it my first time through either, and it doesn’t really make a lot of sense for them to be there in my opinion, but I’m not Red Hat.
Exactly my point. The patch files aren’t in the sources I’ve compiled and I haven’t applied any patch files. That means the patch that fixes things can only be on the config.
The changelog files probably won’t be of that much value, unless you go through all files since kernel 6.9 up until the version F42 shipped with, as I’m unsure which exact kernel version started the problem and I nobody knows when Fedora fixed it.
And again I’ve got some bad news. I did want to experiment around with just applying all USB related configs of the Fedora config to the Debian config, but I just can into the issue again. While being on the Kernel that should be compiled solely based on the Fedora config. I’ll test again with their 6.16.10 kernel, making sure I don’t change anything (beyond disabling debug builds), but it seems while their config only slows this issue down from appearing, it doesn’t fully prevent it.
I see. Did that run include config_usb_hid? That was another that I had written down as notable as the audio expansion card also implements a generic HID interface. It’s under HID devices in menuconfig, not USB.
CONFIG_HID_GENERIC and CONFIG_HID are also set to included and not module. Much more of a stretch than the USB settings but we appear to have exhausted those