I recently bought a 12th Gen Framework (DIY Kit, the base model one) and installed Ubuntu 22.04 on it. Everything was working up until about an hour ago. I got a strange partial OS hang, where I couldn’t move the mouse and the screen got corrupted, but I could still hear the ba-dah-dooh that GNOME makes when you unplug or replug the charger. I left it there for about a minute before holding down the power button to power down the machine.
After this point, every time I boot Ubuntu the onboard audio does not work and it just picks up a dummy device. I know the audio stack is at least partially working because I can still pair AirPods to the laptop through Bluetooth.
As recommended by another thread about broken audio I tried booting from the install media I used to set up the laptop. It also gives me a dummy device, though I don’t remember if the install media had working audio or not.
As recommended by some StackOverflow comments I also tried setting options snd-hda-intel model=generic in alsa-base.conf; but that instead gives me a “DisplayPort/HDMI” output that does not route to the internal speakers.
As far as I can tell the snd_hda_intel driver is loaded (it shows up in lspci and lsmod) but not detecting the audio hardware. Is there a way to debug this further or is my laptop’s audio hardware somehow bricked?
Well, I drained the laptop battery and plugged it back in, and audio’s working again. My guess is that my initial hang wound up b0rking whatever audio hardware is in the 12th Gen motherboards, and that it was keeping that configuration across shutdowns. Perhaps it’s wired up to 5VSB or something and draining the battery is necessary to fully reset whatever configuration got corrupted.
In which case my next question is… is there a more convenient way to reset the audio codec hardware than draining or yanking the battery?
What codec does your machine have? The “Tempo” 92HD95? There’s a thread here somewhere (ah, here) where some Linux users describe issues where the codec doesn’t initialize correctly and there’s a dummy output instead, as far as I know without a solution but maybe you were seeing the same thing.
There’s some randomness in those reports so it’s not necessarily even related to your crash, but possibly coincidence (or maybe a clue to what’s happening there).
I’m not sure, I’ll have to open mine tomorrow. I have a 12th Gen board that I got a week or so ago so I’m assuming it’s a Tempo chip - the switch off of Realtek chips happened way before 12th Gen right?
FWIW I got the crash again and my audio is dummied out again. dmesg reports the exact same codec response timeout. Will try to unplug the battery tomorrow (I suspect draining it every time will kill it) and see what dmesg reports when the codec chip is working.
I found a chip next to the battery connector marked TSI - I’m assuming that’s a Tempo chip, since it looks just like the one on the Framework blog post announcing the switch away from Realtek.
At any rate, pulling the battery connector also fixes the codec chip and everything detects correctly. My guess is that there’s some sort of bug in Tempo’s HDA implementation that the Linux drivers are tickling somehow, or that it’s retaining state from the forced shutdown and Linux doesn’t know how to properly reset it.
It feels like something that could be fixed with a quirk or something on the Linux side… if it could be determined what’s happening.