Control: retitle -1 kernel 5.17.6-1 causes issues with Audio out via HDMI (workaround: intel_iommu=igfx_off) Control: tag -1 - moreinfo On Thursday, 16 June 2022 01:35:42 CEST Troy Telford wrote: > 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. Excellent, metadata updated accordingly. > > 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/ > 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. 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
Attachment:
signature.asc
Description: This is a digitally signed message part.