Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
After scouring my logs I've found this started after my first boot
of kernel 5.17.6-1 (2022-05-14). I started having issues with audio
out via HDMI - especially if the device had its input changed or
was turned off.
Kernel 5.17.0-1-amd64 (Debian 5.17.3-1 (2022-04-18) does not have
this issue, which should help reduce the Δ somewhat.
The problem remains with linux-image-5.17.0-3-amd64. I am currently
unable (unwilling?) to test linux-image-5.18.0, as my root
filesytem uses ZFS, and there are currently no DKMS packages that
build on linux-image-5.18. (I don't have an abundance of time to
try to both get an upstream zfs set of packages built as well as
figure out how to get a rootfs booting using that kernel module.)
* What exactly did you do (or not do) that was effective (or
ineffective)?
By plugging my error into Google, I was lead to
https://www.mail-archive.com/kernel-packages@lists.launchpad.net/msg478114.html,
which wasn't _quite_ what I was looking for, but it mentioned the
intel_iommu driver, and as the device id in my error message used
an Intel driver (snd_hda_intel), it seemed a reasonable place to
start looking.
That lead me to
https://www.kernel.org/doc/Documentation/Intel-IOMMU.txt, which
explicitly said:
"If you encounter issues with graphics devices, you can try adding
option intel_iommu=igfx_off to turn off the integrated graphics
engine. If this fixes anything, please ensure you file a bug
reporting the problem."
As the motherboard has an Intel integrated graphics engine, and the
rest of the document seemed to describe the error message I was
seeing, it seemed reasonable to try the option intel_iommu=igfx_off
* What was the outcome of this action?
The problems vanished, and the error messages stopped appearing in
my kernel log.
I initially thought to add this to the kernel.org bugzilla, but
they had a useful message saying "Please use your distribution's
bug tracking tools" which is reasonable, as I am using a Debian
kernel.
I'm not sure the appropriate way to report the issue upstream (if
it is even is an issue upstream). Unfortuantely, I can't test the
latest 5.18 kernel yet, as my root filesystem uses ZFS, and there
are no working DKMS packages for it yet.
*** End of the template - remove these template lines ***
Control: tag -1 moreinfo If that's the case, then the issue should be in the following list: https://tracker.debian.org/news/1324075/accepted-linux-5176-1-source-into-unstable-unstable/ And is the issue of this bug report "issues with audio out via HDMI"? The title of this bug report looks to describe a (potential) workaround.
You are correct. 5.17.3-1 worked fine and 5.17.6-1 (and 5.17.11-1) are broken. "Issues with Audio out via HDMI” is a *far* better description for the bug report. (Facepalm). Setting intel_iommu=igfx_off is a workaround which addresses the issue for me. I’ll see if I can find the issue in the list, but I’m not familiar with the kernel internals, so it’ll be mostly an adventure with git. I’ll be quite happy if I can find the file (or commit) where the change occurred.
Control: retitle -1 kernel 5.17.6-1 causes issues with Audio out via HDMI (workaround: intel_iommu=igfx_off) Control: tag -1 - moreinfo Excellent, metadata updated accordingly. The changes in that upload consisted from the Debian side of changes to arm64/armhf configuration, which are 100% irrelevant to your issue. And it is really doubtful that the changes wrt AXP288 on x86 affected you. Which results in the conclusion that the issue is caused by the *upstream* changes between 5.17.3 and 5.17.6 which is not that large a commit range :-) So you should report this in the upstream bug tracker as this is not a Debian (caused) issue. If you report the URL of that upstream bug report, then we can track it's progress more easily. https://wiki.debian.org/DebianKernel/GitBisect describes how to do a 'git bisect' wrt to the kernel and is the best way to figure out which commit caused the regression. $ git bisect start $ git bisect good v5.17.3 $ git bisect bad v5.17.6 ^^ would be how you'd start the 'git bisect' session. There is another way you could try which would likely be faster, but you'd need a bit of luck with that. If you don't, you'd still need to do the git bisect. https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2 describes how you can test a single patch and then you can verify whether that patch fixes your issue. Or you can try out several patches first and if that fixes the issue, then repeat the procedure where you keep dropping patches until you only have 1 left. Based on the the commit list between v5.17.3 and v5.17.6 you pick one (or several) commits which you think may have caused it. (IOW: educated guessing) Then you can make a patch of a revert of that commit. (Repeat for any other 'suspicious' commits). And you'd use those patch(es) as argument to 'bash debian/bin/test-patches'. One of these procedures is the best and likely fastest way to get this issue (actually) fixed. But it would likely be a git adventure. So, you should definitely report this in the upstream kernel bug tracker. If you can track down which (single) commit caused the regression, that would seriously speed up the finding of a proper solution. AFAIK the 'git adventure' would really help and be appreciated, but I don't think it's a (hard) requirement. If you have further questions, feel free to ask. Cheers, Diederik
I have built a vanilla kernel 5.17.6 to replicate the issue, but before I was able to test it (to reproduce it and send a report to kernel.org <http://kernel.org/>’s bugzilla), I became very ill with COVID-19, which put everything on hold for a while. Now that I’ve largely recovered, I have been able run a system apt upgrade - and noticed that the zfs modules have been updated to support kernel 5.18, so I am now able to test against `linux-image-5.18.0-2` - it seemed to make sense to see if I could reproduce against that first, if only to see if a newer kernel resolved the issue. It appears that was the correct move: - I’ve been able to boot the Debian 5.18.0-2 linux-image package, - After about nine days of uptime, I’ve been unable to reproduce the issue. - There are none of the `DMAR: DRHD: handling fault` messages in the kernel log. I believe this bug can be closed, as it does not appear to be an issue with the current kernels.
Version: linux/5.18.5-1 Thanks for testing and reporting back. Closing bug with version 5.18.0-2.