Hmm, okay, then it’s not the kill switch (that switch only disables the mic, not sound output).
I’d use this guide to make sure the audio cable is plugged in all the way (go up to step 5 and then close it back up, since you’re not replacing the audio board).
No luck there. It was very well-seated; I cycled both ends of the ribbon cable, but I still only see “Dummy output”
Just FYI, I have sound but no microphone on mine as well. I suspect driver issue because microphone used to work. I’m on openSUSE with 5.15.1
@Bryan_Elliott U21.10 works ok for me. The dmesg output you shared is a little unusual since it shows no response from codec.
$ uname -a
Linux***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 dmesg -k | grep snd_hda_intel
[ 258.312185] snd_hda_intel 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040380
[ 258.312239] snd_hda_intel 0000:00:1f.3: enabling device (0000 -> 0002)
[ 258.315667] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
What bios version do you have? Do you have a Tempo mainboard or Realtek Mainboard?
sudo dmidecode --type bios
For the mainboard type: you can run
sudo dmidecode --type chassis
And share the first 10 digits of the serial number.
uname -a
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
sudo dmidecode --type chassis | sed -e 's/\(Serial Number\|Asset Tag\): \([[:alnum:]]\{10\}\)[[:alnum:]]*$/\1: \2********/'
# 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.
Hey everyone,
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:
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"
# 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
# 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
[ 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...
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.
Using
snd-hda-intel model=dell-headset-multi
is not needed on mainboards with the Tempo codec. I think this may pass some invalid parameters to the codec.
However This does not sound like the root cause of issues most people are experiencing in this thread.
The Mic switch only cuts off the mic, not audio output.
If someone could enable hda tracing and unload and reload the snd_hda_intel module, it might shed some light onto what is happening.
echo 1 > /sys/kernel/debug/tracing/events/hda/enable
reload the snd_hda_intel module
cat /sys/kernel/debug/tracing/trace
And lets see what shows up
modprobe -r -f -a snd_hda_intel fails with
FATAL: Module snd_intel_dspcfg is in use
So does modprobe -r -f -a snd_intel_dspcfg
Nothing shows up.
I’m using the following script to unload and reload the module:
CADDR="0000:00:1f.3"
DRIVERS="snd_sof_pci_intel_tgl snd_sof_intel_hda snd_hda_codec_hdmi snd_hda_intel snd_soc_skl_hda_dsp snd_soc_intel_hda_dsp_common snd_hda_codec"
CDIR=/sys/bus/pci/devices/${CADDR}
# Device directory is a symlink
[[ -L "${CDIR}" ]] && {
echo "Removing card..."
echo '1' > ${CDIR}/remove
}
echo "Unloading drivers..."
modprobe -ar ${DRIVERS}
echo "Loading new drivers..."
#modprobe -a ${DRIVERS}
echo "Rescanning PCI bus..."
echo '1' > /sys/bus/pci/rescan
journalctl -k -f
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:
root@valent:~/# cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 0/0 #P:8
#
# _-----=> irqs-off/BH-disabled
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / _-=> migrate-disable
# |||| / delay
# TASK-PID CPU# ||||| TIMESTAMP FUNCTION
# | | | ||||| | |
I’m already using the following options in modprobe.d to get verbose logs from the modules themselves:
options snd_sof sof_debug=1
options snd_sof_intel_byt dyndbg=+p
options snd_sof_intel_bdw dyndbg=+p
options snd_sof_intel_ipc dyndbg=+p
options snd_sof_intel_hda_common dyndbg=+p
options snd_sof_intel_hda dyndbg=+p
options snd_sof dyndbg=+p
options snd_sof_pci dyndbg=+p
options snd_sof_acpi dyndbg=+p
options snd_sof_of dyndbg=+p
options snd_sof_nocodec dyndbg=+p
options sof-audio-pci-intel-tgl dyndbg=+p
options soundwire_bus dyndbg=+p
options soundwire_generic_allocation dyndbg=+p
options soundwire_cadence dyndbg=+p
options soundwire_intel_init dyndbg=+p
options soundwire_intel dyndbg=+p
options snd_soc_skl_hda_dsp dyndbg=+p
options snd_intel_dspcfg dyndbg=+p
journalctl output:
Jul 03 21:19:20 valent kernel: pci 0000:00:1f.3: Removing from iommu group 19
Jul 03 21:19:21 valent kernel: pci 0000:00:1f.3: [8086:a0c8] type 00 class 0x040380
Jul 03 21:19:21 valent kernel: pci 0000:00:1f.3: reg 0x10: [mem 0x4017004000-0x4017007fff 64bit]
Jul 03 21:19:21 valent kernel: pci 0000:00:1f.3: reg 0x20: [mem 0x4017100000-0x40171fffff 64bit]
Jul 03 21:19:21 valent kernel: pci 0000:00:1f.3: PME# supported from D3hot D3cold
Jul 03 21:19:21 valent kernel: pci 0000:00:1f.3: Adding to iommu group 19
Jul 03 21:19:22 valent kernel: pci 0000:00:1f.3: BAR 4: assigned [mem 0x4017100000-0x40171fffff 64bit]
Jul 03 21:19:22 valent kernel: pci 0000:00:1f.3: BAR 0: assigned [mem 0x4017004000-0x4017007fff 64bit]
Jul 03 21:19:22 valent kernel: snd_hda_intel 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040380
Jul 03 21:19:22 valent kernel: snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
Jul 03 21:19:23 valent kernel: snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x000f0000
Jul 03 21:19:24 valent kernel: snd_hda_intel 0000:00:1f.3: No response from codec, disabling MSI: last cmd=0x000f0000
Jul 03 21:19:25 valent kernel: snd_hda_intel 0000:00:1f.3: Codec #0 probe error; disabling it...
Jul 03 21:19:25 valent kernel: input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input39
Jul 03 21:19:25 valent kernel: input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input40
Jul 03 21:19:25 valent kernel: input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input41
Jul 03 21:19:25 valent kernel: input: HDA Intel PCH HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input42
Jul 03 21:19:25 valent kernel: input: HDA Intel PCH HDMI/DP,pcm=10 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input43
Jul 03 21:19:25 valent kernel: input: HDA Intel PCH HDMI/DP,pcm=11 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input44
Jul 03 21:19:25 valent kernel: input: HDA Intel PCH HDMI/DP,pcm=12 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input45
Jul 03 21:19:25 valent kernel: input: HDA Intel PCH HDMI/DP,pcm=13 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input46
Jul 03 21:19:25 valent kernel: input: HDA Intel PCH HDMI/DP,pcm=14 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input47
Jul 03 21:19:25 valent kernel: input: HDA Intel PCH HDMI/DP,pcm=15 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input48
Jul 03 21:19:25 valent kernel: input: HDA Intel PCH HDMI/DP,pcm=16 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input49
Jul 03 21:19:25 valent kernel: input: HDA Intel PCH HDMI/DP,pcm=17 as /devices/pci0000:00/0000:00:1f.3/sound/card0/input50
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 have the exact same issue.
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.
@Kieran_Levin Does this suggest hardware issue?
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.
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
1: 0 0 82338 0 0 0 0 0 IR-IO-APIC 1-edge i8042
8: 0 0 0 0 0 0 0 0 IR-IO-APIC 8-edge rtc0
9: 0 435474 0 0 0 0 0 0 IR-IO-APIC 9-fasteoi acpi
12: 0 280 0 0 0 0 0 0 IR-IO-APIC 12-edge i8042
14: 0 0 0 0 503446 0 0 0 IR-IO-APIC 14-fasteoi INT34C5:00
16: 0 0 0 0 0 0 7505306 0 IR-IO-APIC 16-fasteoi intel_ish_ipc, i801_smbus, snd_hda_intel:card0
27: 0 0 0 0 0 0 0 0 IR-IO-APIC 27-fasteoi idma64.0, i2c_designware.0
30: 0 0 0 0 0 0 9337572 0 IR-IO-APIC 30-fasteoi idma64.2, i2c_designware.2
40: 0 0 0 0 0 87 0 0 IR-IO-APIC 40-fasteoi idma64.1, i2c_designware.1
See IRQ 191
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
1: 0 0 0 0 0 0 51170 0 IR-IO-APIC 1-edge i8042
8: 0 0 0 0 0 0 0 0 IR-IO-APIC 8-edge rtc0
9: 0 224333 0 0 0 0 0 0 IR-IO-APIC 9-fasteoi acpi
14: 0 420947 0 0 0 0 0 0 IR-IO-APIC 14-fasteoi INT34C5:00
16: 0 0 134437 0 0 0 0 0 IR-IO-APIC 16-fasteoi intel_ish_ipc, i801_smbus
27: 0 0 0 0 0 0 0 0 IR-IO-APIC 27-fasteoi i2c_designware.0, idma64.0
30: 0 0 0 11426907 0 0 0 0 IR-IO-APIC 30-fasteoi i2c_designware.2, idma64.2
40: 0 0 178 0 0 0 0 0 IR-IO-APIC 40-fasteoi i2c_designware.1, idma64.1
120: 0 0 0 0 0 0 0 0 DMAR-MSI 4-edge dmar4
121: 0 0 0 0 0 0 0 0 DMAR-MSI 3-edge dmar3
122: 0 0 0 0 0 0 0 0 DMAR-MSI 2-edge dmar2
123: 0 0 0 0 0 0 0 0 DMAR-MSI 1-edge dmar1
124: 0 0 0 0 0 0 0 0 DMAR-MSI 0-edge dmar0
125: 0 0 0 0 0 0 0 0 DMAR-MSI 5-edge dmar5
126: 0 0 0 0 0 0 0 0 IR-PCI-MSI 98304-edge PCIe PME
127: 0 0 0 0 0 0 0 0 IR-PCI-MSI 114688-edge PCIe PME, pciehp
128: 0 0 0 0 0 0 0 0 IR-PCI-MSI 116736-edge PCIe PME, pciehp
129: 0 0 0 0 0 0 0 0 IR-PCI-MSI 118784-edge PCIe PME, pciehp
130: 0 0 0 0 0 0 0 0 IR-PCI-MSI 120832-edge PCIe PME, pciehp
131: 0 0 0 0 0 0 0 0 IR-PCI-MSI 475136-edge PCIe PME
132: 0 0 0 0 0 0 0 0 IR-PCI-MSI 212992-edge xhci_hcd
133: 0 0 0 0 0 22185 0 0 IR-PCI-MSI 327680-edge xhci_hcd
134: 0 29 0 0 0 0 0 0 INT34C5:00 335 FRMW0001:00
135: 0 420919 0 0 0 0 0 0 INT34C5:00 3 PIXA3854:00
136: 0 0 0 26140 0 0 0 0 IR-PCI-MSI 524288-edge nvme0q0
137: 9261 0 0 0 0 0 0 0 IR-PCI-MSI 524289-edge nvme0q1
138: 0 10181 0 0 0 0 0 0 IR-PCI-MSI 524290-edge nvme0q2
139: 0 0 11277 0 0 0 0 0 IR-PCI-MSI 524291-edge nvme0q3
140: 0 0 0 12821 0 0 0 0 IR-PCI-MSI 524292-edge nvme0q4
141: 0 0 0 0 7116 0 0 0 IR-PCI-MSI 524293-edge nvme0q5
142: 0 0 0 0 0 10932 0 0 IR-PCI-MSI 524294-edge nvme0q6
143: 0 0 0 0 0 0 10017 0 IR-PCI-MSI 524295-edge nvme0q7
144: 0 0 0 0 0 0 0 11724 IR-PCI-MSI 524296-edge nvme0q8
145: 0 0 0 0 2295110 0 0 0 IR-PCI-MSI 32768-edge i915
146: 0 0 0 0 0 879 0 0 IR-PCI-MSI 217088-edge thunderbolt
147: 0 0 0 0 0 0 1919 0 IR-PCI-MSI 217089-edge thunderbolt
164: 0 0 0 0 0 0 0 35 IR-PCI-MSI 360448-edge mei_me
165: 0 917 0 0 0 0 0 0 IR-PCI-MSI 219136-edge thunderbolt
166: 0 0 1989 0 0 0 0 0 IR-PCI-MSI 219137-edge thunderbolt
181: 0 0 0 28556 0 0 0 0 IR-PCI-MSI 89128960-edge iwlwifi:default_queue
182: 389 0 0 0 0 0 0 0 IR-PCI-MSI 89128961-edge iwlwifi:queue_1
183: 0 281 0 0 0 0 0 0 IR-PCI-MSI 89128962-edge iwlwifi:queue_2
184: 0 0 498 0 0 0 0 0 IR-PCI-MSI 89128963-edge iwlwifi:queue_3
185: 0 0 0 12772 0 0 0 0 IR-PCI-MSI 89128964-edge iwlwifi:queue_4
186: 0 0 0 0 457 0 0 0 IR-PCI-MSI 89128965-edge iwlwifi:queue_5
187: 0 0 0 0 0 1197 0 0 IR-PCI-MSI 89128966-edge iwlwifi:queue_6
188: 0 0 0 0 0 0 10 0 IR-PCI-MSI 89128967-edge iwlwifi:queue_7
189: 0 0 0 0 0 0 0 192 IR-PCI-MSI 89128968-edge iwlwifi:queue_8
190: 0 0 0 0 0 11 0 0 IR-PCI-MSI 89128969-edge iwlwifi:exception
191: 0 0 0 0 337469094 0 0 0 IR-PCI-MSI 514048-edge snd_hda_intel:card0
NMI: 0 0 0 0 0 0 0 0 Non-maskable interrupts
LOC: 2770023 1867902 1757985 2775119 11485590 4991902 1728517 1767911 Local timer interrupts
SPU: 0 0 0 0 0 0 0 0 Spurious interrupts
PMI: 0 0 0 0 0 0 0 0 Performance monitoring interrupts
IWI: 16527 23054 24296 21378 1173622 21975 22132 20748 IRQ work interrupts
RTR: 0 0 0 0 0 0 0 0 APIC ICR read retries
RES: 43903 29856 17097 36567 196868 16662 16502 18392 Rescheduling interrupts
CAL: 490275 252999 205334 192336 122022 158013 171050 175833 Function call interrupts
TLB: 65627 65136 64376 64131 45775 52753 58380 64106 TLB shootdowns
Sorry can you clarify what you mean here?
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.
Thanks. When I ran the command I looked briefly and I did not realise it was a cumulative count. For me it is going up at a rate of ~40/s.
Support have offered to replace my mainboard to try and fix this issue.
I would be surprised if that does not solve the issue. Here is to hoping all is well with the new board.