Intel HDMI Audio not working with IOMMU enabled

Bug #1428121 reported by Kelvin Middleton on 2015-03-04
28
This bug affects 5 people
Affects Status Importance Assigned to Milestone
ALSA driver
Confirmed
Medium
alsa-driver (Ubuntu)
Medium
Unassigned

Bug Description

New ASRock Z97 Extreme 6 motherboard with an Intel i7 4790S and an Nvidia GTX 650.

Host uses Intel IGD for video and HDMI audio out.

When I pass kernel flags 'intel_iommu=on' or 'intel_iommu=on,igfx_on' HDMI audio no longer functions although the device and modules seem to load and I cannot locate any error messages. In this configuration IOMMU functions as expected and I can successfully pass the Nvidia card through to a KVM guest using VFIO.

As per this (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1223840) bug report and the linked bugzilla thread I attempted to use kernel flag 'intel_iommu=on,igfx_off'. This resolves the HDMI audio out but breaks IOMMU as in VGA pass through generates DMA errors.

I'm running from a clean installation of 14.10 with no modifications to the kernel or kvm, qemu, libvirt or virt-manager.

In either scenario above the analogue audio out continues to function, I haven't tested the optical out as I have no hardware to do so.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: linux-image-3.16.0-31-generic 3.16.0-31.41
ProcVersionSignature: Ubuntu 3.16.0-31.41-generic 3.16.7-ckt5
Uname: Linux 3.16.0-31-generic x86_64
ApportVersion: 2.14.7-0ubuntu8.2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC2: kelvin 3468 F.... pulseaudio
 /dev/snd/controlC3: kelvin 3468 F.... pulseaudio
 /dev/snd/controlC0: kelvin 3468 F.... pulseaudio
 /dev/snd/controlC1: kelvin 3468 F.... pulseaudio
CurrentDesktop: Unity
Date: Wed Mar 4 12:53:17 2015
HibernationDevice: RESUME=UUID=4d35060a-85c4-45fd-9f8e-530491588931
InstallationDate: Installed on 2015-02-26 (5 days ago)
InstallationMedia: Ubuntu-Server 14.10 "Utopic Unicorn" - Release amd64 (20141022.2)
MachineType: To Be Filled By O.E.M. To Be Filled By O.E.M.
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.16.0-31-generic.efi.signed root=UUID=4914f227-6bb0-40bb-a781-9ad7111a996f ro intremap=no_x2apic_optout intel_iommu=on,forcedac pci-stub.ids=10de:11c8,10de:0e0b nomdmonddf nomdmonisw
RelatedPackageVersions:
 linux-restricted-modules-3.16.0-31-generic N/A
 linux-backports-modules-3.16.0-31-generic N/A
 linux-firmware 1.138.1
RfKill:

SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/17/2014
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: P1.70
dmi.board.name: Z97 Extreme6
dmi.board.vendor: ASRock
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP1.70:bd12/17/2014:svnToBeFilledByO.E.M.:pnToBeFilledByO.E.M.:pvrToBeFilledByO.E.M.:rvnASRock:rnZ97Extreme6:rvr:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.name: To Be Filled By O.E.M.
dmi.product.version: To Be Filled By O.E.M.
dmi.sys.vendor: To Be Filled By O.E.M.

I built a new desktop PC based on the Gigabyte H87N-WIFI motherboard. It has one DVI and two HDMI outputs. However, I cannot get any sound over HDMI. The same OS image works perfectly on my laptop that also has an HDMI output.

This is not a pulseaudio problem, because the following command (with a 5-second wav file) takes a lot more than 5 seconds, and spams the kernel log with "playback write error (DMA or IRQ trouble?)":

pasuspender -- aplay -D hdmi:0,0 /usr/share/sounds/startup3.wav

I will attach more information to this bug.

Created attachment 107242
alsa-info.sh output

The relevant card is 00:03.0 (Intel Haswell HDMI)

Created attachment 107243
Kernel config

Created attachment 107245
Full dmesg

Created attachment 107267
Full dmesg after BIOS update

It was suggested that I update the BIOS and retry with -D hw:0,7. It didn't help, I still get the "playback write error (DMA or IRQ trouble?)" even with the F4 version of the BIOS.

Created attachment 107373
/proc/interrupts, three times

On IRC, ohsix asked me for /proc/interrupts. Here is what I did:

cat /proc/interrupts > interrupts.txt
pasuspender -- aplay -D hw:1,0 /usr/share/sounds/startup3.wav # works, plays through analog output
cat /proc/interrupts >> interrupts.txt
pasuspender -- aplay -D hw:0,3 /usr/share/sounds/startup3.wav # hangs => ctrl+c
cat /proc/interrupts >> interrupts.txt

Backup info from Alexander:
"according to the log, this machine claims to have three HDMI outputs, while in fact it has one DVI (possibly wired for HDMI, at least ELD is successfully transferred over it) and two "real" HDMI.
All of them fail to transfer audio in the same way."

More info possibly relevant to this bug: the board appears to have general IRQ problems.

1. The analog audio sometimes stutters. There is the following message in dmesg while playing a DVD (note: this is about the different card!):

[ 2158.573591] hda-intel: IRQ timing workaround is activated for card #1. Suggest a bigger bdl_pos_adj.

2. Sometimes the keyboard or mouse exhibits lags (characters get delayed or the cursor sticks for several hundred milliseconds, while other screen updates appear as they should). Initially I attributed them to the fact that they are wireless (and that's the first time I use a wireless keyboard and mouse) and suspected interference from some unknown source. But, given the above IRQ-related message, I decided to tell you about that, too.

Download full text (5.5 KiB)

your still have deadlock and oops

1.351918] ======================================================
[ 1.351989] [ INFO: possible circular locking dependency detected ]
[ 1.352056] 3.11.0-rc5+ #1 Not tainted
[ 1.352122] -------------------------------------------------------
[ 1.352195] crda/311 is trying to acquire lock:
[ 1.352383] microcode: CPU5 sig=0x306c3, pf=0x2, revision=0x9
[ 1.352258] (genl_mutex){+.+.+.}, at: [<ffffffff81596902>] genl_lock+0x12/0x20
[ 1.352562]
but task is already holding lock:
[ 1.352716] systemd-udevd[275]: renamed network interface eth0 to enp2s0
[ 1.352666] (nlk->cb_mutex){+.+.+.}, at: [<ffffffff81592b09>] netlink_dump+0x29/0x240
[ 1.352940]
which lock already depends on the new lock.

[ 1.353039]
the existing dependency chain (in reverse order) is:
[ 1.353113] microcode: CPU6 sig=0x306c3, pf=0x2, revision=0x9
[ 1.353189]
-> #1 (nlk->cb_mutex){+.+.+.}:
[ 1.353385] [<ffffffff810ace97>] lock_acquire+0x87/0x130
[ 1.353482] [<ffffffff8166defc>] mutex_lock_nested+0x5c/0x3e0
[ 1.353575] [<ffffffff8159317f>] __netlink_dump_start+0xbf/0x1c0
[ 1.353686] [<ffffffff8159608c>] genl_family_rcv_msg+0x1bc/0x320
[ 1.353753] microcode: CPU7 sig=0x306c3, pf=0x2, revision=0x9
[ 1.353843] [<ffffffff81596989>] genl_rcv_msg+0x79/0xb0
[ 1.353938] [<ffffffff81595bd9>] netlink_rcv_skb+0xa9/0xc0
[ 1.354030] [<ffffffff81595eb7>] genl_rcv+0x27/0x40
[ 1.354123] [<ffffffff8159516d>] netlink_unicast+0x10d/0x190
[ 1.354214] [<ffffffff815955f9>] netlink_sendmsg+0x359/0x760
[ 1.354308] [<ffffffff8154e082>] sock_sendmsg+0xc2/0xe0
[ 1.354427] microcode: Microcode Update Driver: v2.00 <email address hidden>, Peter Oruba
[ 1.354409] [<ffffffff8154e46c>] ___sys_sendmsg+0x37c/0x390
[ 1.354619] [<ffffffff81551144>] __sys_sendmsg+0x44/0x80
[ 1.354729] [<ffffffff8155118d>] SyS_sendmsg+0xd/0x20
[ 1.354835] [<ffffffff81678f16>] system_call_fastpath+0x1a/0x1f
[ 1.354932]
-> #0 (genl_mutex){+.+.+.}:
[ 1.355129] [<ffffffff810ac028>] __lock_acquire+0x1528/0x1dd0
[ 1.355222] [<ffffffff810ace97>] lock_acquire+0x87/0x130
[ 1.355316] [<ffffffff8166defc>] mutex_lock_nested+0x5c/0x3e0
[ 1.355412] [<ffffffff81596902>] genl_lock+0x12/0x20
[ 1.355516] [<ffffffff81596aec>] ctrl_dumpfamily+0x12c/0x140
[ 1.355638] [<ffffffff81592b70>] netlink_dump+0x90/0x240
[ 1.355746] [<ffffffff81593010>] netlink_recvmsg+0x2f0/0x3a0
[ 1.355858] [<ffffffff8154dd29>] sock_recvmsg+0xd9/0xf0
[ 1.355964] [<ffffffff8154d562>] ___sys_recvmsg+0x112/0x2a0
[ 1.356076] [<ffffffff81551384>] __sys_recvmsg+0x44/0x80
[ 1.356181] [<ffffffff815513cd>] SyS_recvmsg+0xd/0x20
[ 1.356271] [<ffffffff81678f16>] system_call_fastpath+0x1a/0x1f
[ 1.356411]
other info that might help us debug this:

[ 1.356700] Possible unsafe locking scenario:

[ 1.356929] CPU0 CPU1
[ 1.357081] ---- ----
[ 1.357248] lock(nlk->cb_mutex);
[ 1...

Read more...

This is not a deadlock, just a lockdep warning that is unrelated to audio (i.e. a separate bug). If you want, I will blacklist the iwldvm module so that you don't see this.

As for my earlier comment about general IRQ problems - I stand corrected. This IS RF interference. In pulseaudio -vvv log, I see front headphone jack status changes that correspond in time to the glitches. However, this computer's case does not have frnt panel audio jacks, so I left the motherboard pins that should lead to the front panel audio unconnected to anything. And the keyboard becomes non-lagged if I shift it a bit on my table. Also, the Dell monitor sometimes shows some spurious light near its sensor "buttons". So, I now believe all of this strange activity is actually unrelated to the HDMI bug.

I attempted to get rid of the bug by buying a different motherboard (MSI Z87I). The attempt is unsuccessful: the same bug manifests itself again on the new board.

Created attachment 109811
alsa-info.sh output from MSI board

This is with today's drm-intel/drm-intel-nightly

Created attachment 109821
dmesg from MSI board

Can you spot what's common (besides the form factor) between these two motherboards? Or should I suspect a faulty CPU?

which pin complex is DisplayPort and which pin complex is you HDMI ?

Do their ELD contain the monitor name ?

state.MID {
 control.1 {
  iface CARD
  name 'HDMI/DP,pcm=3 Jack'
  value true
  comment {
   access read
   type BOOLEAN
   count 1
  }
 }

 control.6 {
  iface PCM
  device 3
  name ELD
  value '100009006a100001000000000000000010ac16f044454c4c2055323431300907070000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
  comment {
   access 'read volatile'
   type BYTES
   count 83
  }
 }
 control.7 {
  iface CARD
  name 'HDMI/DP,pcm=7 Jack'
  value true
  comment {
   access read
   type BOOLEAN
   count 1
  }
 }

 control.12 {
  iface PCM
  device 7
  name ELD
  value '100008006522000000000000000000001e6d01004c4720545615075009570700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
  comment {
   access 'read volatile'
   type BYTES
   count 83
  }
 }

but your new motherboard does not have dual HDMI?

1.794216] hda-intel 0000:00:1b.0: codec_mask = 0x1
[ 1.794413] hda-intel 0000:00:1b.0: codec #0 probed OK
[ 1.796130] hda_codec: invalid CONNECT_LIST verb 7[1]:0
[ 1.796132] hdmi: haswell: override pin connection 0x7
[ 1.796677] HDMI hot plug event: Codec=0 Pin=5 Device=0 Inactive=0 Presence_Detect=1 ELD_Valid=1
[ 1.796731] HDMI status: Codec=0 Pin=5 Presence_Detect=1 ELD_Valid=1
[ 1.796738] HDMI status: Codec=0 Pin=5 Presence_Detect=1 ELD_Valid=1
[ 1.798571] HDMI: detected monitor DELL U2410 at connection type HDMI
[ 1.798573] HDMI: available speakers: FL/FR
[ 1.798575] HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000, bits = 16 20 24
[ 1.800315] HDMI: detected monitor DELL U2410 at connection type HDMI
[ 1.800318] HDMI: available speakers: FL/FR
[ 1.800321] HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000, bits = 16 20 24
[ 1.800386] HDMI hot plug event: Codec=0 Pin=5 Device=0 Inactive=0 Presence_Detect=1 ELD_Valid=1
[ 1.800407] HDMI status: Codec=0 Pin=6 Presence_Detect=1 ELD_Valid=1
[ 1.800419] HDMI status: Codec=0 Pin=5 Presence_Detect=1 ELD_Valid=1

> which pin complex is DisplayPort and which pin complex is you HDMI ?

I don't know how to figure this out. According to what you pasted, control.6 is DELL U2410, and control.12 is LG TV. Physically, DELL U2410 is connected to the DVI port using the DVI-to-HDMI cable, and LG TV to the HDMI. DisplayPort is unused.

> but your new motherboard does not have dual HDMI?

It sort-of does. It has one DVI connector that is seen as HDMI1 by xrandr and is actually connected to an HDMI encoder. Also it has a "real" HDMI connector that is seen as HDMI2 by xrandr. And it has a DisplayPort.

Also the old motherboard physically has one DVI and two HDMI sockets, but, from the software viewpoint, all three are HDMI. And actually, with the old board, the Dell monitor could produce audio clicks even when connected to the DVI output using DVI-to-HDMI cable.

So, in both cases, please treat the DVI physical connector as HDMI.

as you are using pulseaudio

what is the default sink ?

do these two available HDMI sinks have same priority ?

post the output of

pactl stat

pactl list

Sorry, I have replaced the motherboard back to Gigabyte H87N-WIFI, because it is more energy-effifient (to avoid the Streacom Nano150 PSU overload). So I cannot post any more output from the MSI board.

As for pulseaudio - it is completely irrelevant to this bug. As you can see from the comments above (including the original submission), the kernel complains even with pasuspender. If you want pulseaudio logs for some other reason, unrelated to this bug, please ask privately via e-mail.

did you only test the device 3 since your HDMI LG TV is connected to pin 6 which is device 5 ?
you are only connected your dell through DVI

Advanced information - PCI Vendor/Device/Subsystem ID's
!!-------------------------------------------------------

00:03.0 0403: 8086:0c0c (rev 06)
 Subsystem: 1462:7851
--
00:1b.0 0403: 8086:8c20 (rev 04)
 Subsystem: 1462:d851

1.790068] hda-intel 0000:00:03.0: chipset global capabilities = 0x2001

[ 1.790207] hda-intel 0000:00:1b.0: chipset global capabilities = 0x4401

seem haswell only support 2 SDO

only two independent HDMI streams

for multistreaming

the two streams must have different stream tags instead of Same tag 0x2

574956] hdmi_setup_stream: NID=0x5, pinctl=0x40
[ 17.574958] hda_codec_setup_stream: NID=0x2, stream=0x2, channel=0, format=0x4011

[ 17.578555] hdmi_setup_stream: NID=0x6, pinctl=0x40
[ 17.578557] hda_codec_setup_stream: NID=0x2, stream=0x2, channel=0, format=0x4011

I tested both devices. For X in 3, 7, 8 the following command produces either a click in either a TV or a monitor (on older kernels like 3.11) or no sound at all (on newer kernels from git, or on the "remaining" device that corresponds to the unconnected port), and logs "playback write error (DMA or IRQ trouble?)":

pasuspender -- aplay -D hw:0,$X /usr/share/sounds/startup3.wav

As for different vs the same stream tags - how do I test that it is indeed my problem?

P.S. there is a cat show today, I will be able to reply and test your suggestions only after it.

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/plain/Documentation/sound/alsa/HD-Audio.txt

Hint Strings
~~~~~~~~~~~~
The codec parser have several switches and adjustment knobs for
matching better with the actual codec or device behavior. Many of
them can be adjusted dynamically via "hints" strings as mentioned in
the section above.

try specify hint

stick_stream = false for haswell hdmi

- sticky_stream (bool): keep the PCM format, stream tag and ID as long
  as possible; default true

- trigger_sense (bool): indicates that the jack detection needs the
  explicit call of AC_VERB_SET_PIN_SENSE verb

- indep_hp (bool): provide the independent headphone PCM stream and
  the corresponding mixer control, if available

For alc892

trigger_sense = false
indepdent_hp = true

it seem that MSI user manual does not mention how to support 7.1 for desktop motherboard with 5 stack

even intel web site does not mention which jack need to be retask for (side channel playback)

http://www.intel.com/support/motherboards/desktop/sb/CS-034198.htm

8-channel audio
8-channel audio is available only on certain Intel® Desktop Boards. After installing the audio driver from the Intel Express Installer CD, multi-channel audio can be enabled:

    Connect speakers to A, B, C, D, or E as shown in the figure below, up to eight speakers.

Raymond,

echo stick_stream = false > /sys/devices/pci0000:00/0000:00:03.0/sound/card0/hwC0D0/hints

does not help the IRQ or DMA problem.

And please do not hijack the bug for your multistreaming remarks.

did you rebbot the computer or reloaded the modules or dynamic reconfiguration ?

did you perform dynamic reconfigure

# echo 1 > /sys/class/sound/hwC0D0/reconfig

or

Early Patching
~~~~~~~~~~~~~~
When CONFIG_SND_HDA_PATCH_LOADER=y is set, you can pass a "patch" as a
firmware file for modifying the HD-audio setup before initializing the
codec. This can work basically like the reconfiguration via sysfs in
the above, but it does it before the first codec configuration.

A patch file is a plain text file which looks like below:

------------------------------------------------------------------------
  [codec]
  0x12345678 0xabcd1234 2

  [model]
  auto

  [pincfg]
  0x12 0x411111f0

  [verb]
  0x20 0x500 0x03
  0x20 0x400 0xff

  [hint]
  jack_detect = no
------------------------------------------------------------------------

The hd-audio driver reads the file via request_firmware(). Thus,
a patch file has to be located on the appropriate firmware path,
typically, /lib/firmware. For example, when you pass the option
`patch=hda-init.fw`, the file /lib/firmware/hda-init.fw must be
present.

With the Gigabyte board, I did the following, without any effect except a single click. Note: no matter which HDMI device I specify, the click is most often in the TV speakers, not in the monitor output. But sometimes (rarely) the same aplay command produces a click both in the TV speakers and on the monitor output.

Created /lib/firmware/hda-init.fw with the following contents:

[hint]
stick_stream = false

Ran the following commands, without pulseaudio running:

fuser -k /dev/snd/* ; rmmod snd-hda-intel

modprobe snd-hda-intel patch=hda-init.fw

aplay -D hdmi:0,0 /usr/share/sounds/startup3.wav

aplay -D hdmi:0,2 /usr/share/sounds/startup3.wav # in another terminal

Both aplay commands complete very slowly by themselves and lead to "playback write error (DMA or IRQ trouble?)" in the dmesg.

36 comments hidden view all 116 comments

Hrm, OK, maybe it's safer to set the alignment for Haswell HDMI generically.

But before doing it: could you check whether the same problem happens even without IOMMU? I guess this is independent from that.

On the Gigabyte board, snd_hda_intel.align_buffer_size=1 is needed even with IOMMU disabled in the BIOS. Let me recheck with MSI, and please join #alsa or #pulseaudio on freenode if you want more interactive debugging.

Well, the MSI board does not even have a setting to disable IOMMU in the BIOS. So nothing to test.

OK, thanks for quick tests.
Below is the patch I'm going to apply. Please let me know if this works.

Created attachment 113501
Fix buffer alignment for Haswell HDMI controllers

I'm confused by the IOMMU aspect of this. Surely the DMA for the *audio* will still from from the HD Audio controller, not from the graphics device? So turning off the IOMMU from the graphics device really shouldn't make any difference?

And if there's some mixup in hardware and the DMA transactions are actually happening with the PCI source-id of the graphics device instead of the HD audio controller... then we should see *faults*. But we don't; instead the DMA just silently fails?

How is the integration between the graphics and audio devices supposed to work?

In the case of Intel HDMI, the audio device is a kind of slave of GPU. The actual data is handled solely in the graphics side.

And, on the recent Intel chips like Haswell, both are integrated more tightly. For example, if GPU is turned off, just accessing to the audio PCI register gives kernel Oops or a hard lockup, although it looks independent in the PCI level.

Please could you upload the DMAR tables from the offending machines? (/sys/firmware/acpi/tables/DMAR)

(In reply to Takashi Iwai from comment #67)
> Created attachment 113501 [details]
> Fix buffer alignment for Haswell HDMI controllers

The patch works.

Created attachment 113511
DMAR from the MSI board

I will not attach the DMAR from the Gigabyte board today, because it is rather hard to disassemble and reassemble the whole computer. At any given moment, at most one of those boards can be in my computer, because I don't have two Haswell CPUs.

(yes I know this is unrelated to this bug)

(In reply to Raymond from comment #22)
> it seem that MSI user manual does not mention how to support 7.1 for desktop
> motherboard with 5 stack

Please don't worry. On the MSI board, 7.1 works over analog output out of the box. Here is what goes where, both according to the labels and to the fact:

Line In: blue jack
Front Left/Right: green jack
Microphone: red jack
Surround left/right: black jack
Center/LFE: orange (meant to be brown?) jack
Side Left/Right: light-gray jack

but your info did not have the channel mode to select 6ch , 8ch

http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda?id=a07a949be6eb1c9aab06adaadce72dbd27b7d9cb

ALSA: hda - Fix multi-io channel mode management
The multi-io channels can vary not only from 1 to 6 but also may vary
from 6 to 8 or such.

spec->multi_ios = 1 when only blue Jack is used for retasking

 if (spec->multi_ios == 2) {
   for (i = 0; i < 2; i++)
    spec->private_dac_nids[spec->multiout.num_dacs++] =
     spec->multi_io[i].dac;
  } else if (spec->multi_ios) {
   spec->multi_ios = 0;
   badness += BAD_MULTI_IO;
  }

Raymond: there was indeed no such switch. From my "user" viewpoint, I don't see why it would be necessary on that board, as there are enough connectors and there is never any need to retask jacks. IOW, there is indeed no way to switch the board into a 5.1 mode and no need to do so.

Created attachment 113661
DMAR from the Gigabyte board

I have replaced the board again in order to get the DMAR info. Unfortunately, in the process, one of the adhesive pads that keep the nuts from the passive cooling system in place was damaged.

This means slightly suboptimal position of the passive heatsink (but it still survives the full CPU load) and, more importantly, physical impossibility to remove the heatsink again (well, maybe with the help of thin flat pliers this is fixable, but I don't have them at hand now). So no more motherboard changes for your testing, I am stuck with Gigabyte :(

I do have a backup copy of "lspci -nnvv", "dmidecode --dump-bin" and all ACPI tables that were exposed in sysfs from the MSI board.

Erased that lspci/dmidecode backup by accident :(

David Woodhouse: with both DMARs attached to this bug, why there is no further progress in the IOMMU side of the bug?

Alexander - I am considering the MSI Z87I and am wondering if your bug is still present in kernel version 3.13.6 (current stable) or in 3.14-rc7 (current rc).

The buffer alignment bug is fixed. As for the IOMMU bug, I don't know. I still have a workaround on my kernel command line and I am too lazy to check whether it is still needed. However, the IOMMU bug, even if it still exists, is so easily workaroundable that you should not consider it as an argument against this board.

3.14-rc7 should have the bug fix patch by Takashi.
Not sure about 3.13.6

Ping about the IOMMU bug.

Ping about the IOMMU bug.

The IOMMU broke my hdmi sound outputs on my ASUS B85M-G. I am developing intel IGD virtualization, so 'igfx_off' is not a way for me.

Should I file another bug to cover this issue?

*** Bug 86311 has been marked as a duplicate of this bug. ***

*** Bug 67321 has been marked as a duplicate of this bug. ***

*** Bug 86221 has been marked as a duplicate of this bug. ***

97 comments hidden view all 116 comments

Have attached the dmesg error stream when trying to run a guest with VFIO pass through when the 'intel_iommu,igfx=off' kernel flag is used.

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Joseph Salisbury (jsalisbury) wrote :

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.0 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.0-rc2-vivid/

Changed in linux (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Incomplete
tags: added: kernel-bug-exists-upstream

Think I've done all correctly, upstream has the same issues using the kernel you linked.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
tags: added: latest-bios-1.70
affects: linux (Ubuntu) → alsa-driver (Ubuntu)
Changed in alsa-driver (Ubuntu):
status: Confirmed → New
94 comments hidden view all 116 comments

Another ping. I've also had problems with Haswell + HDMI audio + IOMMU. For me, using the media player Kodi to bitstream AC3 or DTS data over HDMI doesn't work (other types of audio data work though).

This only happens with intel_iommu=on or CONFIG_INTEL_IOMMU_DEFAULT_ON=y. With IOMMU enabled I also see this line in dmesg:

[ 35.168233] snd_hda_intel 0000:00:03.0: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.

My hardware is an Intel Haswell NUC D54250WYK.

I posted more info at http://forum.kodi.tv/showthread.php?tid=224324 if that helps.

Hi there,

I also seem to be affected by this issue (Haswell i7-4790k, Asus Maximus Hero VII).

No HDMI Audio from integrated Intel HD 4600 graphics, with intel_iommu=on (I need this turned on in order to do GPU passthrough for a discrete Nvidia adapter).

There is no audio being output, even though every command I try seems to confirm the HDMI audio device is present and 'working'.

Finally, can anyone confirm whether or not Skylake CPU's are also affected by this issue, or is the issue limited to Haswell CPU's only?

Thanks,

I also have the sound problem with intel_iommu=on and hdmi output via HDMI on a haswell cpu + nvidia gpu (Intel i7-4702HQ 2.2-3.2Ghz and GT750M). Is there any hope of getting this fixed to make PCI passthrough possible? Thanks !

Outputs + logs:
https://bbs.archlinux.org/viewtopic.php?id=204460

(In reply to etfaker from comment #88)
> I also have the sound problem with intel_iommu=on and hdmi output via HDMI
> on a haswell cpu + nvidia gpu (Intel i7-4702HQ 2.2-3.2Ghz and GT750M). Is
> there any hope of getting this fixed to make PCI passthrough possible?
> Thanks !
>
> Outputs + logs:
> https://bbs.archlinux.org/viewtopic.php?id=204460

I should add that I also have no or very crappy/stuttering/low quality sound output via HDMI with intel_iommu=on which makes it useless :/ but I need it.

96 comments hidden view all 116 comments
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in alsa-driver (Ubuntu):
status: New → Confirmed
DiQ (dik23) wrote :

Seeing this with 4.2.0-27-generic on Haswell 4790K

Glad to see this bug report isn't completely dead.

Can confirm too that the problem still exists with kernel 4.2.0-27-generic with the same motherboard as per the original bug report.

The attached is a recent extract from dmesg outputs...I use vfio passthrough for GFX on a Windows guest. You can see from the timestamps that I start the guest at 21:02:44 and at around 21:26:07 I get some DMAR faults pertain to device at 00:02.0. This device is the Intel IGD...

lspci -s 00:02.0
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)

...not sure if this is related to the HDMI audio or not.

What I can say is that I have to boot the host with "intel_iommu=on". If I change this to =on,igfx_off then my syslog fills with constant complaints about DMAR for another device I use in passthrough which works perfectly with =on, this device is a DVB-S2 device. If I use =igfx_off this stops IOMMU so I can not longer passthrough PCI devices but presto the HDMI audio now works?!

Freddy Angel (fhangel) wrote :

Same issue with 4.2.0-27-generic, i7-4790K

Freddy Angel (fhangel) wrote :

I can confirm same problem with the latest mainstream 4.4.2 kernel on a fresh install.
Same hardware as the OP except for the VGA, mine is the NVIDIA GTX 750 Ti

93 comments hidden view all 116 comments

And .. after some days when I thought I was getting mad... or something wrong with my mobo ... I found this which fits perfectly !
I've never used my onboard hdmi .. now I use it since I passthrough the nvidia card to a VM and use the onboard hdmi to use it on the regular system ( maybe even launch a kodi if audio would work ).

So, workarounds ? Any way I can help debug ?

I'm on a 4.4.3 kernel, the cpu is a i7-4790 ( without the K ), the mobo is a ASUS H97-PRO GAMER. I don't use it for gaming though .. but more as a server and desktop ..

Hi again,

Just a quick update subsequent to my original comment (see below)

I recently upgraded from Haswell to Skylake (i6700k, Asus Maximus Hero VIII Alpha) and it would appear that I no longer have the HDMI audio issue..

As in:

- I have vt-d enabled in the bios
- My currently booted kernel has iommu=on (verified via 'cat /proc/cmdline')
- The iommu seems to be working (verified via 'dmesg | grep iommu' and 'find /sys/kernel/iommu_groups/ -type l')
- With the above in place, I appear to have working HDMI audio (from the integrated Intel HD 530 graphics)

This would suggest the problem is Haswell specific, since Skylake doesn't appear to be affected?

Thanks,

(In reply to Alza from comment #87)
> Hi there,
>
> I also seem to be affected by this issue (Haswell i7-4790k, Asus Maximus
> Hero VII).
>
> No HDMI Audio from integrated Intel HD 4600 graphics, with intel_iommu=on (I
> need this turned on in order to do GPU passthrough for a discrete Nvidia
> adapter).
>
> There is no audio being output, even though every command I try seems to
> confirm the HDMI audio device is present and 'working'.
>
> Finally, can anyone confirm whether or not Skylake CPU's are also affected
> by this issue, or is the issue limited to Haswell CPU's only?
>
> Thanks,

I have a problem with HDMI audio on Haswell integrated video that may be related as described in this PulseAudio bug report:

https://bugs.freedesktop.org/show_bug.cgi?id=94804

If I have "intel_iommu=on" on the kernel command line without adding "igfx_off", the HDMI audio works, but with significant timing problems. When playing a video, either the audio and video quickly start to drift out of sync, up to a few seconds off, or (in VLC's case) it starts having audio dropouts and complaining like this:

core warning: picture is too late to be displayed (missing 25 ms)
core debug: picture might be displayed late (missing 13 ms)
core warning: playback way too early (-121209): playing silence
core debug: inserting 5818 zeroes
core warning: playback too early (-40158): down-sampling
core warning: timing screwed (drift: -81704 us): stopping resampling
core warning: playback too early (-82366): down-sampling
core warning: playback way too early (-121032): playing silence
core debug: inserting 5809 zeroes
core debug: auto hiding mouse cursor
core warning: playback too early (-40230): down-sampling
core debug: auto hiding mouse cursor
core warning: timing screwed (drift: -80762 us): stopping resampling
core warning: playback too early (-81447): down-sampling
core warning: playback way too early (-120541): playing silence
core debug: inserting 5785 zeroes

Also having this on Lenovo ThinkPad T440.

Intel(R) Core(TM) i3-4010U CPU @ 1.70GHz, Haswell

Sorry for the spam, forgot to mention that I'm running 4.9.6 kernel (and also seen the issue in previous kernel versions).

96 comments hidden view all 116 comments
Zeke Laschinski (geast) wrote :

Ubuntu 17.04 with 4.10.0-21, libvirt 2.5.0, QEMU 2.8, and virt-manager 1.3.2.
Gigabyte EX58-UD3R Rev 1.6, ICH10 (00:1b.0) audio, x5675 (Westmere).
Nvidia GTX 275 for the host, GTX 1050 Ti for the VM.

Added to /etc/default/grub, updated grub, rebooted, and replaced the previous entry each time:
intel_iommu=igfx_off (Audio works, breaks IOMMU)

intel_iommu=on,igfx_off (Breaks audio)

intel_iommu=on,igfx_off snd_hda_intel.align_buffer_size=1 (Breaks audio)

intel_iommu=on iommu=pt (Breaks audio)

dmesg gives with intel_iommu=on:
DMAR: [DMA Read] Request device [00:1b.0] fault addr ffffb000 [fault reason 02] Present bit in context entry is clear

THE FIX:
Alex Williamson created a patch that was verified by Matthieu Speder
https://bugzilla.kernel.org/show_bug.cgi?id=76331
https://patchwork.kernel.org/patch/4505951/

Zeke Laschinski, did you test the patch yourself and confirm it fixes the problem you are experiencing?

Zeke Laschinski (geast) wrote :

I've now tested the patch myself by patching kernel 4.10.0.21.23. Unfortunately, it does not fix the problem.

95 comments hidden view all 116 comments

Is there any chance that this bug will ever get fixed? This bug is present in the latest linux-mainline 5.3-rc6 still :(

Changed in alsa-driver:
importance: Unknown → Medium
status: Unknown → Confirmed

Another instance of this bug: https://www.reddit.com/r/archlinux/comments/ghozc1/cantt_get_audio_from_intel_graphics_hdmi_out/

Dear maintainers, maybe it's time to fix the IOMMU driver? Or, if IOMMU maintainers are indeed unreachable, maybe ALSA maintainers can detect this condition (iommu on, Haswell HDMI) and at least emit a warning in the log referencing this bug and a possible workaround?

Does it make a difference when you boot with 'intremap=off' on the kernel command line?

"intel_iommu=on intremap=off" yields no sound.

Created attachment 289285
DMAR table of Haswell macbookpro11,1 [8086:0a2e]

I have been able to reproduce this bug on a Haswell system, specifically a 2013 Retina MacBookPro (macbookpro11,1) with an integrated Intel graphics card, with a single HDMI out.

00:02.0 VGA compatible controller [0300]: Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a2e] (rev 09)
00:03.0 Audio device [0403]: Intel Corporation Haswell-ULT HD Audio Controller [8086:0a0c] (rev 09)

(I'm attaching the full lspci -nn)

I can reliably reproduce the symptoms of lagging audio and eventual complete failure of HDMI audio. I can work-around this issue by disabling IOMMU either completely or just for the integrated graphics.

I haven't test the kernel patch, but I can do it if you believe it is still relevant to try and fix this upstream.

I hope I can help with this, thank you very much for your work!

I'm attaching the DMAR table of my system, as well as my boot/kernel log for IOMMU-off and IOMMU-on

Created attachment 289287
lspci of affected haswell-macbookpro11,1

Created attachment 289289
dmesg-haswell-macbook11,1 (iommu is ON)

Created attachment 289291
dmesg-haswell-macbook11,1 (iommu BUT with igfx_off)

Displaying first 40 and last 40 comments. View all 116 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.