Thanks @Richard !
I scrolled through the 2 pages in the issues and didn’t see it, where did I miss it?
I don’t have the Audio card for my FW16.
Does the reliability different depending which slot you put it in.
For example Slot 1 and Slot 4 might be more reliable.
What else do you have plugged into the other ports?
For diagnosing problems, a full dmesg or similar log is needed, as small snippets of it do not help in diagnosing a problem much at all.
One would also need some annotation in the logs, saying at what time you removed the audio card from the slot so one can look in the logs and determine if USB disconnects are due to bugs, or the user actually removing the slot card.
If I could suggest a place to start diagnosing this for FW developers, it would be fix this issue:
That would fix some stability problems in relation to the USB firmware, and might possibly fix this audio issue at the same time as this Audio card using the same USB chip that that issue has problems with also.
I mean, “sudo lspci -v” kills the USB chip, it disappears from the bus, and one has to reboot the laptop to get it back. Not great stability wise.
I can confirm that in my testing the port the expansion card was plugged into did not affect the behavior. When the issue occurs lsusb -v also fails, but my assumption was that this was because the USB device itself was nonresponsive, as when unplugged the command works properly. I’ve actually been unable to reproduce the issue since I’ve updated to BIOS 4.02, and I’m not quite sure why
Happened to me again. I dumped an EC log this time since we aren’t looking so closely at the kernel anymore. I’m admittedly not familiar with what the outputs mean in this case, but there was a part that stuck out.
EC log snippet
PORT80: F90E
PORT80: F90D
PORT80: F90D
PORT80: F022
PORT80: F90D
[61474.272800 HC 0x0070]
+++(++)PORT80: F022
[61474.307100 HC 0x0029]
PORT80: F90D
PORT80: F90D
PORT80: F90D
++PORT80: F90E
PORT80: F90D
+(++)[61474.370300 HC 0x0029 err 3]
[61474.372200 HC 0x0029 err 3]
[61474.374200 HC 0x0029 err 3]
[61474.376200 HC 0x0029 err 3]
[61474.378200 HC 0x0029 err 3]
PORT80: F90E
PORT80: F90D
PORT80: F90E
I don’t know whether or not HC 0x0029 is the audio expansion card or what error 3 pertains to, but maybe somebody here does?
Edit: Formatting
1 Like
HC 0x0029 is controlling the LED colours
1 Like
Ah. Disregard then. This was only something I grabbed after the fact as the failure happened in the middle of a meeting and I needed to get my mic working before anything else. I used a soft reboot so part of me was hoping the EC would still have something useful in it, but it appears not. Hopefully next time this happens I’ll be in a position to actually triage the thing
1 Like
What slot is the Audio card plugged into.
It might work better in Slot 1 or Slot 4, than slot 2,3,5,6.
So, worth trying in different slots, so see which work best.
Currently slot 5, but I had tested it in slots 1 and 2 some time ago, and the issue did not resolve. I don’t believe the audio issue is related unfortunately.
Nothing to add short of a reminder:
Please file experienced issues here for visibility for our firmware team. Posting here is community only and will not be seen. Thanks
I can now confirm that this is most likely a firmware issue. Even the replacement mainboard showed this issue at the first chance there was.
1 Like
I have a strange data point that might (or might not) be relevant here.
I got my FW16 (7040) about 2 weeks ago, and for the first week or so had no problems of any kind. Then, after about a week, I started experiencing the screen freezes, and a few days ago started getting these audio freezes. The audio freezes started out intermittently, but quickly became almost hourly.
Shortly after that, I was poking around in the BIOS, and switched to Gaming Mode. But I also noticed the setting for the number of days plugged in before switching to some mode (sorry, didn’t write down the exact name).
So on a whim, I unplugged the laptop for a few hours - and I haven’t had either problem since (about 2-3 days ago)! Gaming Mode may have something to do with the screen freezes, but is it possible that being plugged in too long might cause the audio problems?
Nope, that’s not possible. “Gaming mode” sets the amount of VRAM that can be allocated to the iGPU. It’s true that the higher amount of the gaming mode can alleviate some of the issues, but the screen freezing seems to be an ancient problem of the Linux kernel that can’t restore itself from an impossible situation that now also affects the amdgpu driver nd seems to be related to bad “Page flipping” with at least Panel Self Refresh, maybe even Panel Replay (though the fact that you probably didn’t apply and debug mask in the kernel options tells me what I feared, both are affected), and these modes are also the cause of the screen glitches.
The other mode you saw is just changing how the FW charges and shouldn’t have any other consequences. Also, as you said it yourself. “[…] number of days plugged in before switching to some mode […]”. After the set timeframe being nonstop connected to a charger, FW will stop constantly charging to 100 %. Simple as that.
Just had the issue and discovered this thread. I don’t see how it can be a firmware issue if there were no firmware updates in between but the problem has started happening on the 6.x.x kernel. I haven’t done as much testing as you guys but just my take
It has more or less been confirmed to be a firmware issue. The only thing that’s guaranteed though is that it’s impossible to be a Linux-related issue, as Windows is also affected. So the only possible options are firmware and hardware issues. And since replacing both the headphone jack module and the entire mainboard and even using a different USB C-to-jack adapter didn’t fix the issue for me, it’s unlikely to be a hardware issue, only leaving a firmware issue left.
Also, just because some kernel versions seem to somehow be able to avoid this issue doesn’t mean the kernel is what causes it, it can merely be a stopgap solution to prevent it from happening. But for that one would need to find out, what changes exactly Fedora introduced and later removed that happened to be able to prevent this issue. Also, it would only fix the issue on Linux, not on Windows.
2 Likes
windows does the same thing and all togeather refuses to connect to certain headphones and won’t work with anything from senhizer
It also refuses many different pairs of headphones and also sometimes inores speakers and microphones
Hello I just started having this issue too. Like just started an hour ago, never had this issue before. Rebooting is only a temporary fix. I have another USB-C audio adapter from an entirely different brand and it works just fine.
NixOS last update was a month ago, stable branch.
FW16 pre-order batch 15
Bios version 3.03, Bios release date 03/27/2024
Audio expansion card came with my FW
5276.877046] usb 1-2.3: Product: Audio Expansion Card
[ 5276.877049] usb 1-2.3: Manufacturer: Framework
[ 5277.119464] input: Framework Audio Expansion Card Consumer Control as /devices/pci0000:00/0000:00:08.1/0000:c2:00.3/usb1/1-2/1-2.3/1-2.3:1.2/0003:32AC:0010.0012/input/input31
[ 5277.170169] hid-generic 0003:32AC:0010.0012: input,hidraw7: USB HID v1.11 Device [Framework Audio Expansion Card] on usb-0000:c2:00.3-2.3/input2
[ 5282.396188] usb 1-2.3: uac_clock_source_is_valid(): cannot get clock validity for id 9
[ 5282.396192] usb 1-2.3: clock source 9 is not valid, cannot use
[ 5287.516236] usb 1-2.3: 1:1: cannot get freq (v2/v3): err -110
[ 5292.636378] usb 1-2.3: 1:1: cannot set freq 48000 (v2/v3): err -110
[ 5297.756358] usb 1-2.3: uac_clock_source_is_valid(): cannot get clock validity for id 9
[ 5297.756372] usb 1-2.3: clock source 9 is not valid, cannot use
[ 5302.876454] usbhid 1-2.3:1.2: can’t add hid device: -110
[ 5302.876454] usb 1-2.3: 1:1: cannot get freq (v2/v3): err -110
[ 5302.876551] usbhid 1-2.3:1.2: probe with driver usbhid failed with error -110
[ 5307.997451] usb 1-2.3: 1:1: cannot set freq 48000 (v2/v3): err -110
If I remember correctly, that would be the oldest BIOS version on record, which may be relevant to the debugging that the firmware team is doing. Posting your log to the github issue:
Is probably the easiest way to get their attention.
And now it seems to be working today with no issues…. weird
Hi all! I’m happen to be with all of you in the same boat. FW16, BIOS version 03.05. Debian “trixie” with kernel 6.12.74+deb13+1-amd64.
For the last several days I was having this issue and rebooting didn’t help. But I’ve just found a solution - I’ve changed a couple of parameters in BIOS Setup Utility (namely Battery Extender but I don’t think it matters which params were changed) and after reboot everything works out.
I believe that there is some state that is preserved between reboots (at least if laptop has a charged battery or connected to the charger). Presumably it is the state of EC. Changing any parameter in BIOS makes a full reset including EC and heals this glitch (until the next time).
Hope it helps you