Linux sproket 5.13.0-22-generic #22-Ubuntu SMP Fri Nov 5 13:21:36 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
sudo dmidecode --type bios
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.
Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
Vendor: INSYDE Corp.
Version: 03.06
Release Date: 10/18/2021
Address: 0xE0000
Runtime Size: 128 kB
ROM Size: 12 MB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
8042 keyboard services are supported (int 9h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 3.6
Handle 0x0011, DMI type 13, 22 bytes
BIOS Language Information
Language Description Format: Long
Installable Languages: 4
en|US|iso8859-1,0
fr|FR|iso8859-1,0
zh|TW|unicode,0
ja|JP|unicode,0
Currently Installed Language: en|US|iso8859-1,0
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.
Handle 0x0003, DMI type 3, 22 bytes
Chassis Information
Manufacturer: Framework
Type: Notebook
Lock: Not Present
Version: AA
Serial Number: FRANBMCPAA********
Asset Tag: FRANBMCPAA*********
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None
OEM Information: 0x00000000
Height: Unspecified
Number Of Power Cords: 1
Contained Elements: 0
SKU Number: FRANBMCP0A
Wanna hear something fun? Last night just before bed, I had sound working (through no action but a couple reboots), and I figured I’d report back after work. I put it to sleep to switch to my company computer and when I woke it back up: no sound again.
I’m new here and pretty new to Ubuntu as well but wanted to share how I fixed my dummy output issue. Initially I had the same issue where my Output device was designated as Dummy Output and nothing was visible in the Input Device, even after toggling the physical switch. The issue turned out the me with the official instructions for how to make the 3.5mm jack support, here. After Removing: options snd-hda-intel model=dell-headset-multi
from: /etc/modprobe.d/alsa-base.conf
Everything started working perfectly.
Hope this helps,
Cheers!
My laptop seems to be affected by the same issue and since upgrading to Ubuntu 22.04 didn’t fix it (my secret hope), I’d hope for some support in the forums.
So:
“aplay” on a wav file runs but gives no audio output
My Pulseaudio setup only shows “Dummy Ausgabe” (German for “Dummy Output”) as an output device. Sound typically can’t be heard. Listing via command line ‘pacmd list-sinks’:
1 sink(s) available.
* index: 0
name: <auto_null>
driver: <module-null-sink.c>
flags: DECIBEL_VOLUME LATENCY DYNAMIC_LATENCY
state: RUNNING
suspend cause: (none)
priority: 1000
volume: front-left: 65536 / 100% / 0.00 dB, front-right: 65536 / 100% / 0.00 dB
balance 0.00
base volume: 65536 / 100% / 0.00 dB
volume steps: 65537
muted: no
current latency: 1648.55 ms
max request: 344 KiB
max rewind: 344 KiB
monitor source: 0
sample spec: s16le 2ch 44100Hz
channel map: front-left,front-right
Stereo
used by: 1
linked by: 1
configured latency: 2000.00 ms; range is 0.50 .. 2000.00 ms
module: 13
properties:
device.description = "Dummy-Ausgabe"
device.class = "abstract"
device.icon_name = "audio-card"
My Framework is running Ubuntu 22.04 but the issue was already there on Ubuntu 21.10.
I’m on BIOS v3.07 which should be current:
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.
Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
Vendor: INSYDE Corp.
Version: 03.07
Release Date: 12/14/2021
Address: 0xE0000
Runtime Size: 128 kB
ROM Size: 12 MB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
8042 keyboard services are supported (int 9h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 3.7
Handle 0x0011, DMI type 13, 22 bytes
BIOS Language Information
Language Description Format: Long
Installable Languages: 4
en|US|iso8859-1,0
fr|FR|iso8859-1,0
zh|TW|unicode,0
ja|JP|unicode,0
Currently Installed Language: en|US|iso8859-1,0
my chassis information (I’m impressed by the ‘sed’ expression):
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.
Handle 0x0003, DMI type 3, 22 bytes
Chassis Information
Manufacturer: Framework
Type: Notebook
Lock: Not Present
Version: AA
Serial Number: FRANBMCPAA********
Asset Tag: FRANBMCPAA********
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None
OEM Information: 0x00000000
Height: Unspecified
Number Of Power Cords: 1
Contained Elements: 0
SKU Number: FRANBMCP0A
what seems weird to me is that the snd_hda_intel module reports a codec issue:
[ 14.326522] snd_hda_intel 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040380
[ 14.326582] snd_hda_intel 0000:00:1f.3: enabling device (0000 -> 0002)
[ 14.326817] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[ 15.343764] snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000
[ 16.351890] snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x000f0000
[ 17.355750] snd_hda_intel 0000:00:1f.3: Codec #0 probe error; disabling it...
I’ve tried with and without the “dell-headset-multi” option in ‘/etc/modprobe.d/alsa-base.conf’ but I see no effect there.
I cannot really tell what makes the sound work sometimes… and sometimes not work. Could these really be loose cables on the sound board!?
To be clear, I still don’t have a solution for this. Whether sound works is kinda random on boot and, if I’m lucky enough to have it working, I try very hard not to shut the laptop down or suspend it.
It kinda sucks. The model setting for snd_hda_intel doesn’t do anything.
I have the exact same behavior here except mine is not intermittent - it has literally never worked (My framework is gen-less, Tempo chip, I5, bought about 3 weeks ago).
But it works on Windows 10 using the standard MS driver, and it works on Windows 10 inside a QEMU VM with the Tiger Lake sound device passed through to the VM. It doesn’t matter what OS I use - everything down to 18.04 Ubuntu, Void, Manjaro, Debian, Arch all display the exact same behaviour outlined in the logs.
I suspect this is an initialization bug in the BIOS or linux driver for some reason, and has been worked around in Windows. Why it only affects some Frameworks and not others is an absolute mystery to me and so far, Framework support have been rather silent on the matter. I don’t know much about SOF / the Intel HDA driver but I’ve been poking around in the kernel source / Tempo data sheet to see if I can work out what’s going on, but since I can’t see what Windows is doing differently it’s kinda flying blind.
If I enable hda and hda_intel tracing via sysfs first and then run this, I see the same kernel output from journalctl but zero output from the trace endpoint:
In an update to my previous statement, I have seen the card work a few (2 or 3) times in Linux - it is not consistent in any fashion except never works when booting the laptop from cold or restarting - it seems to start working randomly after sleeping or hibernating, which makes me think this is some sort of power / initialization / timing issue in the way the Tempo chip is started.
I’ve exhausted the suggestions from Framework Support at this point so pretty much at a loss unless we can work out a way to log HDA verbs and work out why the chip won’t start / be detected.
I’ve managed to use qemu to dump the init and HDA verbs from both Windows 10 (sound working) and Ubuntu 18.04 (sound not working) and the TL;DR is that this is something that fails very very early on in the codec initialisation process in Linux.
Windows:
CORBUBASE write of 0x1
CORBLBASE write of 0x2d6a7000
RIRBUBASE write of 0x1
RIRBLBASE write of 0x2d6a7800
CORBUBASE write of 0x1
CORBLBASE write of 0x2d6a7000
RIRBUBASE write of 0x1
RIRBLBASE write of 0x2d6a7800
CORBWP advance to 3, last WP 0
CORB[1] = 0xf0000 (caddr:0x0 nid:0x0 control:0xf00 param:0x0)
CORB[2] = 0xf0002 (caddr:0x0 nid:0x0 control:0xf00 param:0x2)
CORB[3] = 0xf0004 (caddr:0x0 nid:0x0 control:0xf00 param:0x4)
RIRBWP advance to 3, last WP 0
CORB caddr:0x0 nid:0x0 control:0xf00 param:0x0 response:0x111d7695 (ex 0x0)
CORB caddr:0x0 nid:0x0 control:0xf00 param:0x2 response:0x100101 (ex 0x0)
CORB caddr:0x0 nid:0x0 control:0xf00 param:0x4 response:0x10001 (ex 0x0)
CORBWP advance to 5, last WP 3
CORB[4] = 0x1f0001 (caddr:0x0 nid:0x1 control:0xf00 param:0x1)
CORB[5] = 0x1f0005 (caddr:0x0 nid:0x1 control:0xf00 param:0x5)
RIRBWP advance to 5, last WP 3
Linux:
CORBLBASE write of 0x1fe4a000
CORBUBASE write of 0x4
CORBWP advance to 0, last WP 0
RIRBLBASE write of 0x1fe4a800
RIRBUBASE write of 0x4
CORBWP advance to 1, last WP 0
CORB[1] = 0xf0000 (caddr:0x0 nid:0x0 control:0xf00 param:0x0)
RIRBWP advance to 8, last WP 0
CORB caddr:0x0 nid:0x0 control:0xf00 param:0x0 response:0xffffffff (ex 0x10)
CORB caddr:0x0 nid:0x0 control:0x0 param:0x0 response:0xffffffff (ex 0x10)
CORB caddr:0x0 nid:0x0 control:0x0 param:0x0 response:0xffffffff (ex 0x10)
CORB caddr:0x0 nid:0x0 control:0x0 param:0x0 response:0xffffffff (ex 0x10)
CORB caddr:0x0 nid:0x0 control:0x0 param:0x0 response:0xffffffff (ex 0x10)
CORB caddr:0x0 nid:0x0 control:0x0 param:0x0 response:0xffffffff (ex 0x10)
CORB caddr:0x0 nid:0x0 control:0x0 param:0x0 response:0xffffffff (ex 0x10)
CORB caddr:0x0 nid:0x0 control:0x0 param:0x0 response:0xffffffff (ex 0x10)
RIRBWP advance to 15, last WP 8
CORB caddr:0x0 nid:0x0 control:0x0 param:0x0 response:0xffffffff (ex 0x10)
CORB caddr:0x0 nid:0x0 control:0x0 param:0x0 response:0xffffffff (ex 0x10)
CORB caddr:0x0 nid:0x0 control:0x0 param:0x0 response:0xffffffff (ex 0x10)
These CORB caddr lines with all values set to 0 except the response (255) are the driver continually trying to probe the unresponsive codec - the decoded command:
Command Received for Node ID 0x0: AC_VERB_PARAMETERS with parameter: AC_PAR_VENDOR_ID
Command Received for Node ID 0x0: Unknown Command: 0x0 with parameter: AC_PAR_VENDOR_ID
The Windows code succeeds this command instantly on the first try and moves onto further probing:
Command Received for Node ID 0x0: AC_VERB_PARAMETERS with parameter: AC_PAR_VENDOR_ID
Command Received for Node ID 0x0: AC_VERB_PARAMETERS with parameter: AC_PAR_REV_ID
Command Received for Node ID 0x0: AC_VERB_PARAMETERS with parameter: AC_PAR_NODE_COUNT
Command Received for Node ID 0x1: AC_VERB_PARAMETERS with parameter: AC_PAR_SUBSYSTEM_ID
Command Received for Node ID 0x1: AC_VERB_PARAMETERS with parameter: AC_PAR_FUNCTION_TYPE
Command Received for Node ID 0x1: AC_VERB_GET_SUBSYSTEM_ID with parameter: AC_PAR_VENDOR_ID
I don’t know how these initialization steps differ as I don’t have anything to decode the commands being sent here but they’re clearly very different.
Edit to update: The code I was using to log writes / reads to the PCI device doesn’t take into account anything outside the HDA process (i.e. once the card appears to be initialised) - so these logs above are maybe not helpful to track down the actual issue. It should be possible to modify the patch to capture the correct info and convert it to a format that makes sense.
I’ve also noticed that it is possible to trigger the same ‘looping probe’ behaviour in Windows with the sound not working, so this isn’t solely a Linux issue but does appear to be very, very, very rare in Windows.
I got a replacement mainboard due to this issue (Piece of mainboard partially melted).
My old board works perfectly fine (audio wise) switching between old the and new board one has working audio ther other doesn’t.
I get all the same output from dmeg as other above do “no response from codec”
Also seeing constant CPU activity of 1-1.5% with the new board and generally higher power drain though I don’t know if that is related.
Try running watch -n1 -d cat /proc/interrupts and look for the line identifying snd_intel_hda:card0 on the right. For me it’s IRQ 16, and goes up by around 350 interrupts per second on CPU 6.
Yeah if you use the watch command from above, you should be able to see which core is handling interrupts from the sound card - in your case it looks like CPU5 (the only non zero field on IRQ191). It looks like you already have a ton of interrupts and it’s probably going up pretty fast.
Swapped in the board just now and audio worked from the first boot - so this is definitely some sort of hardware quirk, as I haven’t changed anything from old board to new - simply shut down and swapped the mainboard.
Side note: experience says replacing a laptop mainboard shouldn’t take less than 15 mins but now we live in a world with Frameworks and I’m down with that
Thanks for all the debugging everyone, Since swapping the mainboard seems to fix this issue there seems to be something hardware specific that is being exposed in newer Linux kernels.
I have also not been able to reproduce this issue on my systems here.
I have requested our RMA center to get one of the returned units sent to me so we can debug the hardware further and see if we can figure out what is going on.
- so this is definitely some sort of hardware quirk, as I haven’t changed anything from old board to new - simply shut down and swapped the mainboard.