That appears to be my exact issue, as I had the same error code and it also was happening along with the notification regarding new firmware. Hasn’t happened since updating BTW.
But it most certainly isn’t the only problem, as I also had an incident where I could only change the audio volume up to some seemingly random value, like 58% and it didn’t react to every such change, then it died and upon restart there was again error 110 and ports on one side wouldn’t work - except for the rear one.
That only happened during the recent heatwave in Europe though, so could well be a case of this device being guaranteed to work up to 35°C, not 40°C - typical two temperatures consumer device manufacturers mention in manuals.
Makes sense. Yeah, there are at least two problems here and maybe three. I found the fwupd problem, and there are also some hangs in pipewire, and I think there’s one other that I’m currently tracking down still. Sounds like your experience is some corroboration for the “one other” theory.
I am running BIOS 4.4, so if you’re running 4.5 and things work, maybe that’s a sign that there’s a fix in there. On the other hand, Help! Framework 16 won’t turn on after bios changes - #11 by Jorg_Mertin indicates that maybe I should not be updating my BIOS if there is no urgent need… I had a plan involving updating the BIOS and seeing whether that fixes the fwupd problems with audio, but I don’t really want to go looking for trouble since things seem to be pretty much working for me now.
As long as no one else reports problems with the FW16 BIOS updates, it’s probably pretty safe, but also, “if it’s not broke don’t fix it” type of thing honestly. Maybe it’s better to just say that the thing is finally tentatively problem-free, and I feel the need to spend more time debugging it I can try running videoconferencing and see whether that works now.
Happened again - was okay the entire day but went out during an evening gaming session.
dmesg had this to say:
[ 3052.573742] usbhid 1-2.1:1.2: can't add hid device: -110
[ 3052.573782] usbhid 1-2.1:1.2: probe with driver usbhid failed with error -110
[ 3056.188490] usb 1-2.1: USB disconnect, device number 11
[ 3067.662313] amdgpu 0000:c4:00.0: MES failed to respond to msg=MISC (WAIT_REG_MEM)
[ 3067.662376] amdgpu 0000:c4:00.0: failed to reg_write_reg_wait
[ 3212.618031] usb 1-1: new high-speed USB device number 12 using xhci_hcd
[ 3212.754421] usb 1-1: New USB device found, idVendor=32ac, idProduct=0010, bcdDevice= 0.02
[ 3212.754429] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 3212.754432] usb 1-1: Product: Audio Expansion Card
[ 3212.754434] usb 1-1: Manufacturer: Framework
[ 3212.921922] ucsi_acpi USBC000:00: unknown error 256
[ 3212.993799] input: Framework Audio Expansion Card Consumer Control as /devices/pci0000:00/0000:00:08.1/0000:c4:00.3/usb1/1-1/1-1:1.2/0003:32AC:0010.0013/input/input33
[ 3213.045583] hid-generic 0003:32AC:0010.0013: input,hidraw17: USB HID v1.11 Device [Framework Audio Expansion Card] on usb-0000:c4:00.3-1/input2
[ 3218.466267] usb 1-1: uac_clock_source_is_valid(): cannot get clock validity for id 9
[ 3218.466275] usb 1-1: clock source 9 is not valid, cannot use
[ 3223.587404] usb 1-1: 1:1: cannot get freq (v2/v3): err -110
[ 3228.706576] usb 1-1: 1:1: cannot set freq 48000 (v2/v3): err -110
[ 3233.826724] usb 1-1: uac_clock_source_is_valid(): cannot get clock validity for id 9
[ 3233.826733] usb 1-1: clock source 9 is not valid, cannot use
[ 3238.946847] usb 1-1: 1:1: cannot get freq (v2/v3): err -110
[ 3238.946860] usbhid 1-1:1.2: can't add hid device: -110
[ 3238.946909] usbhid 1-1:1.2: probe with driver usbhid failed with error -110
[ 3244.067008] usb 1-1: 1:1: cannot set freq 48000 (v2/v3): err -110
3212 is when I disconnected the card and plugged it into a different slot. No success. Ports worked normally because I switched them around and there were no issues with other peripherals.
Additionally while it was plugged in, I could only change volume within a 10% range, but if I unplugged, volume control returned back to normal. I could unplug and plug in repeatedly to reproduce this issue.
Upon plugging in again lsusb would hang during listing the devices for 30s and only then finish showing the card.
Interestingly, I’ve found examples of people having similar issues with audio cards based on the same chip model:
To me this is a strong indicator that there’s something funky going on with that chip. It gets into a bad state and a mere restart doesn’t work. I had to turn off the laptop, wait a minute and only then powering it up would snap the card back to life.
The thing is though that this would only be the case if issues only arose when using the audio module. But I know for a fact that two of my DACs show the very same behavior. Unfortunately I can’t tell with certainty what chips they use, but for what I could figure out, at least one of the two is most likely using a Realtek chip and not a Broadcomm/Synaptics/Conexant chip. At least its Windows driver suggests so and the Windows control app for it mentions in one place “Copyright Realtek”.
Can you tell me which models those are? I could do some digging, maybe buy one or both and check if I can reproduce the problem. I especially want to have a DAC and the audio expansion card both plugged in and see if they fail at the same time - that would mean electrical issues.
Did re-plugging help with those DACs?
My experience is that off-the-shelf devices of this type being unstable is not actually that surprising. Unless of course you shelled out north of €70 and they still fail.
Particularly the chip Framework used is, well, cheap and there are several better ones - I was surprised to note it costs approximately as much as a decent headphone socket.
Also it would be important to verify if only wired audio is affected or also Bluetooth, HDMI and or speaker.
Did re-plugging help with those DACs?
No. Though in the cases when audio through the headphone jack module doesn’t work anymore yet the audio system is still working I can use them to have wired audio without having to reboot. Of course they aren’t plugged in when the bug appears.
Thanks. So basically when the bug occurs with the expansion card, you can just plug in one of your DACs and run audio through it?
In my case the speaker is unaffected - all I need is to switch to the correct device in whatever app I’m using. Thankfully the games I’m playing also manage this gracefully and I think last time it even switched automatically. Discord requires a manual switch most of the time.
I’ll switch to Bluetooth the next time it happens or use it from the get go and see how that works.
Sometimes, yes. On other occasions the entire audio system goes down, then only a reboot helps.
In my case the speaker is unaffected
The relevant question is if it also occurs when only BT, speaker or HDMI audio are used and not the audio module. Of course as long as the audio system doesn’t die you can switch to other outputs, that was never the question. But rather if it only triggers when using wired audio (audio module or USB DAC) or also when using any of the three other audio paths.
Not great. Do you still get the failure ever if you disable fwupd from running at all? Does sudo fwupdmgr get-devices kill your audio if you run it by hand while some audio is playing?
Hey. Whats up with F42? Ive used it and faced this exact problem too. This isnt a fedora, linux, or general OS issue. It is strictly a hw/fw bug. Somewhere in Taiwan, there is a company called Genesys Logic a terrible, corner-cutting fabless chip manufacturer that somehow managed to sell their half baked chips to Compal, the Framework OEM. These chips are notoriously buggy. There are countless threads about how flawed this company’s products are.
It is not a Linux problem. Linux kernel expects the hardware to behave properly, and it simply doesn’t. Windows, on the other hand, just silently power cycles it to hide the issue.
There are plenty of reasons why this happens. Maybe the lazy engineers at GL skipped fully qualifying their chips (after all, T&M equipment is expensive, and 3rd-tier manufacturers try to save every penny). Maybe Compal had no idea how to properly route and layout this garbage. Maybe the USB state machine in those chips is just fundamentally flawed. Who knows?
Currently, i’ve been completely bug-free for over 3 months with about a 70/30 time share between fedora and windows.
Fingers crossed it stays that way.
It has been long-established (aka since last December) that this can only be a hardware or firmware/BIOS issue. But what exactly is your Fedora setup that allowed you to suppress the issue for that long, even when combined with Windows?
Just letting everyone know it happened again, but this time with a twist: The card was in port 3, while charging from port 1 stopped working. Port 4 was charging normally.
This happens exclusively under heavy GPU load - this time it was running an LLM locally.
Had to power off the machine and let it sit for half a minute for the ports to start working again.
IIRC there are battery charge limits if the laptop is left on and plugged for a prolonged period of time, and high GPU load can outstrip the ability of the charger to replenish. One or both of those might be your culprit on that front. Regardless, I don’t have a dGPU and I have had audio cut out under low/no load besides, so I doubt it’s related
This keeps happening now, with or without GPU activity but there’s yet another twist:
If I unplug the charger the moment audio (in port 6) dies, it goes silent for a brief moment, then continues as normal.
The charging situation is different though, as having failed when plugged into port 1 it’s:
Port 1 - dead
Port 2 - dead
Port 4 - normal
Port 5 - normal
I can still insert a pendrive in port 3, but 1 & 2 are pretty much kaput - the same USB-A expansion card works fine on 3 and doesn’t on the other two on this side.
So, power issue? I’m going to keep it powered via 4 or 5 see whether it mitigates the issue.
I have a small update: FW finally shared some progress with me. fwupdmgr, or more precisely, fwupd-refresh.service being regularly triggered by fwupd-refresh.timer is somehow involved in this. I have masked the timer last week on tuesday and this issue hasn’t appeared since. I’ll keep this that way at least until next Tuesday to be sure, but at least for now this somehow seems to be preventing the symptom. I just do not understand in any way why, as this is what’s in the timer file:
This means that the service runs once within every hour, with randomization within the hour. Still, for me this only happens every 5-9 days (more or less). “Persistent” means that if a timer was skipped, e.g. because the device was off, it will run once it can do it again. So you would expect it to happen at least every couple of hours, at least once you’re connected via headphone jack. Except that’s not really what happens. It merely explains why a mainboard swap, be it to a different one of the same model or the Ryzen AI 300 one, couldn’t prevent this. But it also doesn’t explain why this happens across Linux distros and even on Windows. So there are still many questions unanswered.
I’ve noticed that sudo systemctl status fwupd-refresh.timer tells when the next trigger will happen. If we can predict these events, then maybe it would be possible to gather more info on them.
Do you still get the failure ever if you disable