Intel HDMI Audio not working with IOMMU enabled
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ALSA driver |
Confirmed
|
Medium
|
|||
alsa-driver (Ubuntu) |
Confirmed
|
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_
As per this (https:/
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-
ProcVersionSign
Uname: Linux 3.16.0-31-generic x86_64
ApportVersion: 2.14.7-0ubuntu8.2
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/
/dev/snd/
/dev/snd/
/dev/snd/
CurrentDesktop: Unity
Date: Wed Mar 4 12:53:17 2015
HibernationDevice: RESUME=
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=
RelatedPackageV
linux-
linux-
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.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.
dmi.modalias: dmi:bvnAmerican
dmi.product.name: To Be Filled By O.E.M.
dmi.product.
dmi.sys.vendor: To Be Filled By O.E.M.
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #14 |
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #15 |
Created attachment 107242
alsa-info.sh output
The relevant card is 00:03.0 (Intel Haswell HDMI)
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #16 |
Created attachment 107243
Kernel config
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #17 |
Created attachment 107245
Full dmesg
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #18 |
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.
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #19 |
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/
cat /proc/interrupts >> interrupts.txt
pasuspender -- aplay -D hw:0,3 /usr/share/
cat /proc/interrupts >> interrupts.txt
In Linux Kernel Bug Tracker #60769, mengdong.lin (mengdong.lin-linux-kernel-bugs) wrote : | #20 |
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."
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #21 |
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.
In Linux Kernel Bug Tracker #60769, superquad.vortex2 (superquad.vortex2-linux-kernel-bugs) wrote : | #22 |
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)
[ 1.352562]
but task is already holding lock:
[ 1.352716] systemd-udevd[275]: renamed network interface eth0 to enp2s0
[ 1.352666] (nlk->cb_
[ 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_
[ 1.353385] [<ffffffff810ac
[ 1.353482] [<ffffffff8166d
[ 1.353575] [<ffffffff81593
[ 1.353686] [<ffffffff81596
[ 1.353753] microcode: CPU7 sig=0x306c3, pf=0x2, revision=0x9
[ 1.353843] [<ffffffff81596
[ 1.353938] [<ffffffff81595
[ 1.354030] [<ffffffff81595
[ 1.354123] [<ffffffff81595
[ 1.354214] [<ffffffff81595
[ 1.354308] [<ffffffff8154e
[ 1.354427] microcode: Microcode Update Driver: v2.00 <email address hidden>, Peter Oruba
[ 1.354409] [<ffffffff8154e
[ 1.354619] [<ffffffff81551
[ 1.354729] [<ffffffff81551
[ 1.354835] [<ffffffff81678
[ 1.354932]
-> #0 (genl_mutex)
[ 1.355129] [<ffffffff810ac
[ 1.355222] [<ffffffff810ac
[ 1.355316] [<ffffffff8166d
[ 1.355412] [<ffffffff81596
[ 1.355516] [<ffffffff81596
[ 1.355638] [<ffffffff81592
[ 1.355746] [<ffffffff81593
[ 1.355858] [<ffffffff8154d
[ 1.355964] [<ffffffff8154d
[ 1.356076] [<ffffffff81551
[ 1.356181] [<ffffffff81551
[ 1.356271] [<ffffffff81678
[ 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-
[ 1...
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #23 |
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.
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #24 |
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.
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #25 |
Created attachment 109811
alsa-info.sh output from MSI board
This is with today's drm-intel/
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #26 |
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?
In Linux Kernel Bug Tracker #60769, superquad.vortex2 (superquad.vortex2-linux-kernel-bugs) wrote : | #27 |
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 '100009006a1000
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 '10000800652200
comment {
access 'read volatile'
type BYTES
count 83
}
}
In Linux Kernel Bug Tracker #60769, superquad.vortex2 (superquad.vortex2-linux-kernel-bugs) wrote : | #28 |
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
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #29 |
> 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.
In Linux Kernel Bug Tracker #60769, superquad.vortex2 (superquad.vortex2-linux-kernel-bugs) wrote : | #30 |
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
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #31 |
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.
In Linux Kernel Bug Tracker #60769, superquad.vortex2 (superquad.vortex2-linux-kernel-bugs) wrote : | #32 |
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/
!!-----
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
In Linux Kernel Bug Tracker #60769, superquad.vortex2 (superquad.vortex2-linux-kernel-bugs) wrote : | #33 |
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_
[ 17.578555] hdmi_setup_stream: NID=0x6, pinctl=0x40
[ 17.578557] hda_codec_
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #34 |
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/
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.
In Linux Kernel Bug Tracker #60769, superquad.vortex2 (superquad.vortex2-linux-kernel-bugs) wrote : | #35 |
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_
- indep_hp (bool): provide the independent headphone PCM stream and
the corresponding mixer control, if available
For alc892
trigger_sense = false
indepdent_hp = true
In Linux Kernel Bug Tracker #60769, superquad.vortex2 (superquad.vortex2-linux-kernel-bugs) wrote : | #36 |
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://
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.
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #37 |
Raymond,
echo stick_stream = false > /sys/devices/
does not help the IRQ or DMA problem.
And please do not hijack the bug for your multistreaming remarks.
In Linux Kernel Bug Tracker #60769, superquad.vortex2 (superquad.vortex2-linux-kernel-bugs) wrote : | #38 |
did you rebbot the computer or reloaded the modules or dynamic reconfiguration ?
In Linux Kernel Bug Tracker #60769, superquad.vortex2 (superquad.vortex2-linux-kernel-bugs) wrote : | #39 |
did you perform dynamic reconfigure
# echo 1 > /sys/class/
or
Early Patching
~~~~~~~~~~~~~~
When CONFIG_
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=
present.
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #40 |
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/
[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/
aplay -D hdmi:0,2 /usr/share/
Both aplay commands complete very slowly by themselves and lead to "playback write error (DMA or IRQ trouble?)" in the dmesg.
In Linux Kernel Bug Tracker #60769, superquad.vortex2 (superquad.vortex2-linux-kernel-bugs) wrote : | #41 |
should be sticky_stream = false
sticky_stream (bool): keep the PCM format, stream tag and ID as long as possible; default true
is it normal for the graphic driver get EDID from the dell monitor connected through dvi using DVI-HDMI adapter ?
only HDMI and Displayport are defined in the two bits CONNECTOR TYPE field in EDID
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #42 |
I have corrected the typo. Same effect: either a click in either the monitor or the TV, or no click at all, randomly.
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #43 |
As for the EDID-over-
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #44 |
Yesterday I made an observation by adding a few printk()s into azx_interrupt() (yes, I know, that's bad). The IRQs come fine when codec parameters are changed in the driver (but of course they are not consumed by snd_pcm_
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #45 |
Created attachment 110171
Debug patch
A patch that adds some printks about IRQ handling
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #46 |
Created attachment 110181
Dmesg with the debugging patch above
Dmesg from today's drm-intel/
First I attempted to play sound via hdmi:0,0, then through plughw:1,0. In the HDMI case, only the first (bogus) interrupt comes through after starting the playback. 3.11.0 behaves the same, please disregard the comment about the difference above.
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #47 |
Also I tried the following stupid hack on top of 3.11.0:
1. Deleted the !azx_dev-
2. Replaced all cases where azx_position_ok() returns -1 with the return code 0.
3. Made azx_irq_
I.e. I effectively forced pending IRQ processing to run every 10 ms. Result: no complaints about IRQ or DMA problem, and "time aplay ..." takes about half of the time it should take. With only one copy of aplay, no sound (no matter which device I use and which output I listen to). With two copies of aplay (one for hdmi:0,0 and one for hdmi:0,2) there is crackling sound in the monitor's output, and, if the TV is also connected, from the TV.
In Linux Kernel Bug Tracker #60769, vallesroc (vallesroc-linux-kernel-bugs) wrote : | #48 |
I'm experiencing the same issue on my GA-H87N-WIFI (same board), with an i5 4670 CPU.
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #49 |
Breakthrough: HDMI audio works using Debian's kernel (3.10-3-amd64, from linux-image-
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #50 |
This is not an introduced regression. It is a motherboard (hardware) bug well-hidden by some configuration option that differs in my kernel and in Debian kernel.
I have not yet identified the relevant set of configuration options, but disabling VT-d in the BIOS, or, alternatively, passing intel_iommu=off to the kernel command line allows the hardware to play the first period. Then it hangs (receives no further interrupts) in my kernel and happily continues in the Debian kernel.
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #51 |
Forgot to say that CONFIG_
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #52 |
OK, to get a working 3.10.14 kernel, two options are essential
CONFIG_
CONFIG_
I have not yet tried these options on newer kernels.
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #53 |
Changing these two options also helps on new kernels. So, I have a viable solution to my problem, but leave the bug open, as the failure mode is quite mysterious. Please add quirks so that IOMMU is not used on either of the boards, and that MID does not accept too-big preallocated buffers (even though SUSE had 1024 as the default for a long time - now we have a situation where this leads to bugs).
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #54 |
Created attachment 110261
Good dmesg, just in case
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #55 |
Created attachment 110271
Good config
In Linux Kernel Bug Tracker #60769, tiwai (tiwai-linux-kernel-bugs) wrote : | #56 |
Did you try intel_iommu=
Regarding the buffer size, try snoop=false option for snd-hda-intel, at first.
The restriction of preallocation size is not real solution, it just happens to work, and inappropriate to put into the driver statically as a quirk.
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #57 |
Tried intel_iommu=
Results are the same as with just disabling the IOMMU - i.e. one period plays, and then it gets stuck. So intel_iommu=
In Linux Kernel Bug Tracker #60769, tiwai (tiwai-linux-kernel-bugs) wrote : | #58 |
Another thing to test is to pass enable_msi=0 to snd-hda-intel.
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #59 |
Also tried: intel_iommu=
Result: the card still gets stuck.
P.S. I am currently in #alsa on freenode as patrakov and will be there for one hour, let's talk there if you want more interactive debugging.
In Linux Kernel Bug Tracker #60769, tiwai (tiwai-linux-kernel-bugs) wrote : | #60 |
OK, then try to adjust the preallocation size on the fly. It can be changed via proc file, e.g.
echo 1024 > /proc/asound/
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #61 |
I don't quite understand what you wanted me to test in comment #46. So I built some kernels with CONFIG_
Note: this testing was with a 44100 Hz S16_LE stereo wav file. Will reboot now and retest with different files.
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #62 |
With prealloc = 88, this works:
Slave: Hardware PCM card 0 'HDA Intel MID' device 3 subdevice 0
Its setup is:
stream : PLAYBACK
access : MMAP_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 32000
exact rate : 32000 (32000/1)
msbits : 16
buffer_size : 16000
period_size : 4000
period_time : 125000
tstamp_mode : NONE
period_step : 1
avail_min : 4000
period_event : 0
start_threshold : 16000
stop_threshold : 16000
silence_
silence_size : 0
boundary : 9007199254740992000
appl_ptr : 0
hw_ptr : 0
This doesn't:
Slave: Hardware PCM card 0 'HDA Intel MID' device 3 subdevice 0
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 44100
exact rate : 44100 (44100/1)
msbits : 16
buffer_size : 22052
period_size : 5513
period_time : 125011
tstamp_mode : NONE
period_step : 1
avail_min : 5513
period_event : 0
start_threshold : 22052
stop_threshold : 22052
silence_
silence_size : 0
boundary : 6207086186423386112
appl_ptr : 0
hw_ptr : 0
With prealloc = 84, this works:
Slave: Hardware PCM card 0 'HDA Intel MID' device 3 subdevice 0
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 44100
exact rate : 44100 (44100/1)
msbits : 16
buffer_size : 21504
period_size : 5376
period_time : 121904
tstamp_mode : NONE
period_step : 1
avail_min : 5376
period_event : 0
start_threshold : 21504
stop_threshold : 21504
silence_
silence_size : 0
boundary : 6052837899185946624
appl_ptr : 0
hw_ptr : 0
In Linux Kernel Bug Tracker #60769, tiwai (tiwai-linux-kernel-bugs) wrote : | #63 |
Build CONFIG_
At the untouched state, confirm that it shouldn't work (it's 1024). Then change to 64, and check that it works. Then echo 1024, check that it's actually changed (cat the same proc file will show the current value), then confirm that it breaks again.
In Linux Kernel Bug Tracker #60769, tiwai (tiwai-linux-kernel-bugs) wrote : | #64 |
Also, if it has something to do with buffer pages, you can try to disable 64bit DMA. Add AZX_DCAPS_NO_64BIT should do it:
--- a/sound/
+++ b/sound/
@@ -610,7 +610,7 @@ enum {
#define AZX_DCAPS_INTEL_PCH \
- (AZX_DCAPS_
+ (AZX_DCAPS_
/* quirks for ATI SB / AMD Hudson */
#define AZX_DCAPS_
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #65 |
I have not tried your patch, but found that intel_iommu=
In Linux Kernel Bug Tracker #60769, tiwai (tiwai-linux-kernel-bugs) wrote : | #66 |
Hm, interesting. I haven't heard of this for Intel chip.
Maybe specific to the combination of Haswell and HDMI and IOMMU.
But, yes, it's still interesting to check whether it influences on the behavior. Test with and without align_buffer_size option.
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #67 |
The patch does not help me to remove any of the following kernel parameters: intel_iommu=
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #68 |
In other words, the patch has no visivle effect.
In Linux Kernel Bug Tracker #60769, superquad.vortex2 (superquad.vortex2-linux-kernel-bugs) wrote : | #69 |
is the alignment only for haswell ?
how about your Intel hda controller with alc892 ?
859051] HDMI: detected monitor LG TV at connection type HDMI
[ 1.859054] HDMI: available speakers: FL/FR LFE FC RL/RR RC FLC/FRC RLC/RRC FLW/FRW FLH/FRH TC FCH
[ 1.859056] HDMI: supports coding type AC-3: channels = 6, rates = 32000 44100 48000, max bitrate = 640000
[ 1.859059] HDMI: supports coding type LPCM: channels = 2, rates = 32000 44100 48000 96000 192000, bits = 16 20 24
does playing audio different rate , channel , format to two HDMI TV at the same time work ?
321.906316] hdmi_setup_stream: NID=0x5, pinctl=0x40
[ 321.906317] hda_codec_
[ 339.856738] hda-intel 0000:00:03.0: azx_pcm_prepare: bufsize=0x10000, format=0x4011
[ 339.857090] hdmi_setup_stream: NID=0x7, pinctl=0x40
[ 339.857091] hda_codec_
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #70 |
It is indeed possible to output two independent streams with different sample rates via two HDMI outputs.
The analog controller never had any problems that required patches or kernel parameters. It also allows independent analog and spdif streams with different sample rates.
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #71 |
Hello Takashi,
I find it surprising that, despite the correct options being known, there is still no patch that adds a quirk. Is there any additional information that I need to add to the bug?
In Linux Kernel Bug Tracker #60769, superquad.vortex2 (superquad.vortex2-linux-kernel-bugs) wrote : | #72 |
have you ask those Intel developers if you think your Intel controller need align buffer ?
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #73 |
If I read the code correctly, AZX_DCAPS_BUFSIZE means "this device does not need buffer size alignment".
And this code says that no Intel HD audio device needs buffer size alignment:
/* Generic Intel */
{ PCI_DEVICE(
.class = PCI_CLASS_
.class_mask = 0xffffff,
.driver_data = AZX_DRIVER_ICH | AZX_DCAPS_BUFSIZE },
...which is false according to the findings in this bug. I will try to insert an entry before this and see if it helps.
I do realize that I have not indicated whether both quirks apply to both boards - I don't know yet and have to test. Unfortunately, the construction of the fanless case makes it hard to disassemble, so I will definitely not test the MSI board today :(
An Intel engineer is already in the CC list.
In Linux Kernel Bug Tracker #60769, tiwai (tiwai-linux-kernel-bugs) wrote : | #74 |
Well, the biggest question is whether this is specific to what parameter, IOW, which condition triggers the bug. Is it only on your mobo models, or only on a certain chipset, or only on some chipset revisions, or specific to (all) Haswell models, or happening only with combination of IOMMU (or any other kernel) setup?
It's hard to answer without more testing.
And, I have a bunch of (more than 20) Haswell machines here for testing, and none of them show such a problem. That's why I didn't apply any patch, so far; i.e. you're the only person hitting the issue, and it can be worked around by a known option :)
Once if we can narrow down the condition, I'd be glad to apply the fix.
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #75 |
As I promised, I have replaced the motherboard to MSI temporarily.
Results of the test: the MSI motherboard also needs both quirks (intel_
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #76 |
Just to stress this again, the bug needs some very specific conditions to trigger:
1. CONFIG_
2. CONFIG_
3. IOMMU enabled in the BIOS
4. A sound file with S16_LE, 44100 Hz, stereo - otherwise alsa-lib would choose a period size that is a multiple of 128
5. Testing directly with aplay -D hdmi:0,X - not via pulseaudio, and not via speaker-test, otherwise non-round period size will not be chosen
Takashi: are you sure that you have satisfied all those conditions during your tests? Even one unsatisfied condition could lead to you happily saying "there is no bug on this machine", while it in fact exists.
In Linux Kernel Bug Tracker #60769, tiwai (tiwai-linux-kernel-bugs) wrote : | #77 |
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.
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #78 |
On the Gigabyte board, snd_hda_
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #79 |
Well, the MSI board does not even have a setting to disable IOMMU in the BIOS. So nothing to test.
In Linux Kernel Bug Tracker #60769, tiwai (tiwai-linux-kernel-bugs) wrote : | #80 |
OK, thanks for quick tests.
Below is the patch I'm going to apply. Please let me know if this works.
In Linux Kernel Bug Tracker #60769, tiwai (tiwai-linux-kernel-bugs) wrote : | #81 |
Created attachment 113501
Fix buffer alignment for Haswell HDMI controllers
In Linux Kernel Bug Tracker #60769, dwmw2 (dwmw2-linux-kernel-bugs) wrote : | #82 |
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 Linux Kernel Bug Tracker #60769, tiwai (tiwai-linux-kernel-bugs) wrote : | #83 |
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.
In Linux Kernel Bug Tracker #60769, dwmw2 (dwmw2-linux-kernel-bugs) wrote : | #84 |
Please could you upload the DMAR tables from the offending machines? (/sys/firmware/
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #85 |
(In reply to Takashi Iwai from comment #67)
> Created attachment 113501 [details]
> Fix buffer alignment for Haswell HDMI controllers
The patch works.
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #86 |
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.
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #87 |
(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
In Linux Kernel Bug Tracker #60769, superquad.vortex2 (superquad.vortex2-linux-kernel-bugs) wrote : | #88 |
but your info did not have the channel mode to select 6ch , 8ch
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-
spec-
} else if (spec->multi_ios) {
spec->multi_ios = 0;
badness += BAD_MULTI_IO;
}
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #89 |
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.
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #90 |
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.
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #91 |
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?
In Linux Kernel Bug Tracker #60769, da_audiophile (daaudiophile-linux-kernel-bugs) wrote : | #92 |
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).
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #93 |
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.
In Linux Kernel Bug Tracker #60769, mengdong.lin (mengdong.lin-linux-kernel-bugs) wrote : | #94 |
3.14-rc7 should have the bug fix patch by Takashi.
Not sure about 3.13.6
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #95 |
Ping about the IOMMU bug.
In Linux Kernel Bug Tracker #60769, st.smartie (st.smartie-linux-kernel-bugs) wrote : | #96 |
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?
In Linux Kernel Bug Tracker #60769, alan (alan-linux-kernel-bugs) wrote : | #97 |
*** Bug 86311 has been marked as a duplicate of this bug. ***
In Linux Kernel Bug Tracker #60769, jani.nikula (jani.nikula-linux-kernel-bugs) wrote : | #98 |
*** Bug 67321 has been marked as a duplicate of this bug. ***
In Linux Kernel Bug Tracker #60769, jani.nikula (jani.nikula-linux-kernel-bugs) wrote : | #99 |
*** Bug 86221 has been marked as a duplicate of this bug. ***
Kelvin Middleton (kelvin-middleton) wrote : | #1 |
- AlsaInfo.txt Edit (58.2 KiB, text/plain; charset="utf-8")
- BootDmesg.txt Edit (82.8 KiB, text/plain; charset="utf-8")
- CRDA.txt Edit (287 bytes, text/plain; charset="utf-8")
- CurrentDmesg.txt Edit (2.1 KiB, text/plain; charset="utf-8")
- Dependencies.txt Edit (2.4 KiB, text/plain; charset="utf-8")
- IwConfig.txt Edit (138 bytes, text/plain; charset="utf-8")
- Lspci.txt Edit (16.9 KiB, text/plain; charset="utf-8")
- Lsusb.txt Edit (884 bytes, text/plain; charset="utf-8")
- ProcCpuinfo.txt Edit (7.9 KiB, text/plain; charset="utf-8")
- ProcEnviron.txt Edit (106 bytes, text/plain; charset="utf-8")
- ProcInterrupts.txt Edit (4.9 KiB, text/plain; charset="utf-8")
- ProcModules.txt Edit (6.2 KiB, text/plain; charset="utf-8")
- PulseList.txt Edit (36.4 KiB, text/plain; charset="utf-8")
- UdevDb.txt Edit (254.3 KiB, text/plain; charset="utf-8")
- UdevLog.txt Edit (551.7 KiB, text/plain; charset="utf-8")
- WifiSyslog.txt Edit (299.5 KiB, text/plain; charset="utf-8")
Kelvin Middleton (kelvin-middleton) wrote : | #2 |
- DMAR errors.txt Edit (106.4 KiB, text/plain)
Have attached the dmesg error stream when trying to run a guest with VFIO pass through when the 'intel_
Brad Figg (brad-figg) wrote : Status changed to Confirmed | #3 |
This change was made by a bot.
Changed in linux (Ubuntu): | |
status: | New → Confirmed |
Joseph Salisbury (jsalisbury) wrote : | #4 |
Would it be possible for you to test the latest upstream kernel? Refer to https:/
If this bug is fixed in the mainline kernel, please add the following tag 'kernel-
If the mainline kernel does not fix this bug, please add the tag: 'kernel-
If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".
Thanks in advance.
[0] http://
Changed in linux (Ubuntu): | |
importance: | Undecided → Medium |
status: | Confirmed → Incomplete |
tags: | added: kernel-bug-exists-upstream |
Kelvin Middleton (kelvin-middleton) wrote : | #5 |
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 |
In Linux Kernel Bug Tracker #60769, steven.brudenell (steven.brudenell-linux-kernel-bugs) wrote : | #100 |
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_
[ 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://
In Linux Kernel Bug Tracker #60769, abcoyle (abcoyle-linux-kernel-bugs) wrote : | #101 |
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,
In Linux Kernel Bug Tracker #60769, etfaker (etfaker-linux-kernel-bugs) wrote : | #102 |
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:/
In Linux Kernel Bug Tracker #60769, etfaker (etfaker-linux-kernel-bugs) wrote : | #103 |
(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:/
I should add that I also have no or very crappy/
Launchpad Janitor (janitor) wrote : | #6 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in alsa-driver (Ubuntu): | |
status: | New → Confirmed |
DiQ (dik23) wrote : | #7 |
Seeing this with 4.2.0-27-generic on Haswell 4790K
Kelvin Middleton (kelvin-middleton) wrote : | #8 |
- dmesg-extract-intel_iommu-on Edit (5.4 KiB, text/plain)
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 : | #9 |
Same issue with 4.2.0-27-generic, i7-4790K
Freddy Angel (fhangel) wrote : | #10 |
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
In Linux Kernel Bug Tracker #60769, adrian.sandu (adrian.sandu-linux-kernel-bugs) wrote : | #104 |
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 ..
In Linux Kernel Bug Tracker #60769, abcoyle (abcoyle-linux-kernel-bugs) wrote : | #105 |
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/
- 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,
In Linux Kernel Bug Tracker #60769, hancockrwd (hancockrwd-linux-kernel-bugs) wrote : | #106 |
I have a problem with HDMI audio on Haswell integrated video that may be related as described in this PulseAudio bug report:
https:/
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
In Linux Kernel Bug Tracker #60769, wgh (wgh-linux-kernel-bugs) wrote : | #107 |
Also having this on Lenovo ThinkPad T440.
Intel(R) Core(TM) i3-4010U CPU @ 1.70GHz, Haswell
In Linux Kernel Bug Tracker #60769, wgh (wgh-linux-kernel-bugs) wrote : | #108 |
Sorry for the spam, forgot to mention that I'm running 4.9.6 kernel (and also seen the issue in previous kernel versions).
Zeke Laschinski (geast) wrote : | #11 |
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=
intel_iommu=
intel_iommu=
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:/
https:/
penalvch (penalvch) wrote : | #12 |
Zeke Laschinski, did you test the patch yourself and confirm it fixes the problem you are experiencing?
Zeke Laschinski (geast) wrote : | #13 |
I've now tested the patch myself by patching kernel 4.10.0.21.23. Unfortunately, it does not fix the problem.
In Linux Kernel Bug Tracker #60769, kuasha420 (kuasha420-linux-kernel-bugs) wrote : | #109 |
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 |
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #110 |
Another instance of this bug: https:/
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?
In Linux Kernel Bug Tracker #60769, joro (joro-linux-kernel-bugs) wrote : | #111 |
Does it make a difference when you boot with 'intremap=off' on the kernel command line?
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #112 |
"intel_iommu=on intremap=off" yields no sound.
In Linux Kernel Bug Tracker #60769, diegoe (diegoe-linux-kernel-bugs) wrote : | #113 |
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
In Linux Kernel Bug Tracker #60769, diegoe (diegoe-linux-kernel-bugs) wrote : | #114 |
Created attachment 289287
lspci of affected haswell-
In Linux Kernel Bug Tracker #60769, diegoe (diegoe-linux-kernel-bugs) wrote : | #115 |
Created attachment 289289
dmesg-haswell-
In Linux Kernel Bug Tracker #60769, diegoe (diegoe-linux-kernel-bugs) wrote : | #116 |
Created attachment 289291
dmesg-haswell-
In Linux Kernel Bug Tracker #60769, amfernusus (amfernusus-linux-kernel-bugs) wrote : | #117 |
Sound pause and resume lags few seconds behind the video, adding solves this problem intel_iommu=
In Linux Kernel Bug Tracker #60769, patrakov (patrakov-linux-kernel-bugs) wrote : | #118 |
Another instance in the wild: https:/
In Linux Kernel Bug Tracker #60769, sb56637 (sb56637-linux-kernel-bugs) wrote : | #119 |
I can confirm that this bug affects me in Debian Bookworm (kernel 6.1) + Pipewire with this hardware (and a DisplayPort -> HDMI adapter):
=======
System:
Host: T440s Kernel: 6.1.0-13-amd64 arch: x86_64 bits: 64 Desktop: Cinnamon
v: 5.6.8 Distro: Debian GNU/Linux 12 (bookworm)
Machine:
Type: Laptop System: LENOVO product: 20AR006RUS v: ThinkPad T440s
Mobo: LENOVO model: 20AR006RUS v: SDK0E50510 PRO
UEFI: LENOVO v: GJETA4WW (2.54 )
date: 03/27/2020
CPU:
Info: dual core Intel Core i5-4300U [MT MCP] speed (MHz): avg: 805
min/max: 800/2900
Graphics:
Device-1: Intel Haswell-ULT Integrated Graphics driver: i915 v: kernel
Device-2: Chicony Integrated Camera type: USB driver: uvcvideo
Display: x11 server: X.Org v: 1.21.1.7 driver: X: loaded: modesetting
unloaded: fbdev,vesa dri: crocus gpu: i915 resolution: 1366x768~60Hz
API: OpenGL v: 4.6 Mesa 22.3.6 renderer: Mesa Intel HD Graphics 4400 (HSW
GT2)
Network:
Device-1: Intel Ethernet I218-LM driver: e1000e
Device-2: Intel Wireless 7260 driver: iwlwifi
Device-3: Intel Bluetooth wireless interface type: USB driver: btusb
=======
I also tried the Debian Backports 6.4 kernel with the same results.
The workaround suggested earlier in this report works:
> edit /etc/default/grub to add
> GRUB_CMDLINE_
However, it should be noted that openSUSE Tumbleweed + Pipewire on this same hardware does *NOT* have this bug.
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.