The type of GPU would be interesting, to see if there’s some kind of pattern. The first ones were
GTX 980
Quadro K2100M
Connectors, adapters, converters used?
[ 133.040133] snd_hda_codec_hdmi hdaudioC2D0: HDMI: invalid ELD data byte 0
I’m using a Thinkpad laptop with a Hama miniDP to HDMI/DVI/DP adapter. This setup has worked fine for years (so this rules out the adapter as an issue).
My card is a GTX660. I have also been struggling against the problem since Archlinux upgraded to 415.xx and then since Voidlinux upgraded to 418.xx. But with 418.xx, on Void at least (I am not in the mood to test with Arch/systemd.), the bug seems to affect only the DisplayPort audio output. I have a three monitor setup. One is connected through DisplayPort and two were attached through DVI. I’ve changed one of the DVI connections to HDMI. Surprisingly, the video card recognized the audio output on the HDMI, but still not on the DisplayPort. That is the makeshift I will use for now.
Mine is a GTX 970. Same issue with having the sound from DP (card) to HDMI (monitor). However, it is not a 100% failure. Maybe 10-20% of the times I boot, the ELD is detected. Monitor is a Samsung UHD TV (Q7FN). So it looks like a race condition issue - at least in my case. Maybe a problem with systemd and the order the drivers are loaded at boot? Any suggestion about a way to pinpoint the problem? I am happy to compare log outputs between failures and success.
OS is Archlinux, the problem happend from drivers 415, drivers 410 were working properly.
No, and I do not think this is relevant. This command only detects the jack plugs, with analog signal.
Pin 0x14 (Green Line Out, Rear side): present = No
Pin 0x15 (Black Line Out, Rear side): present = No
Pin 0x16 (Orange Line Out, Rear side): present = No
Pin 0x18 (Pink Mic, Rear side): present = No
Pin 0x19 (Pink Mic, Front side): present = No
Pin 0x1a (Blue Line In, Rear side): present = No
Pin 0x1b (Green Headphone, Front side): present = No
$ sudo hdajacksensetest -s -c 1
Pin 0x04 ( Digital Out, HDMI): present = No
Pin 0x05 ( Digital Out, HDMI): present = Yes
Pin 0x06 ( Digital Out, HDMI): present = No
Pin 0x07 ( Digital Out, HDMI): present = No
The strange thing is that my cable is connected physically to HDMI 1 on the Samsung, not HDMI 2. But it says (when detected) HDMI 2 in pavucontrol.
Now I am wondering: since it looks like a race condition (I have detection every 5 to 10 reboots), I could trace the boot sequence and see if they do differ. With this working boot, I have:
$ dmesg|grep HDA\ NV
[ 5.049550] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input29
[ 5.049591] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input30
[ 5.049618] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input31
[ 5.049642] input: HDA NVidia HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input32
but I know that systemd provides better tools to record the boot sequence.
By the way, am I the only one to observe this hit and miss behaviour?
Was that hdajacksensetest output from the non-working state? You could then try to read the ELD using
sudo hda-verb /dev/snd/hwC1D0 0x5 0xf2e 0x8
or
sudo hda-verb /dev/snd/hwC1D0 0x5 0xf2f 0
and see if it changes anything.
However I may be onto something. I just restarted and saved the output of dmesg. I can check how the order of entries differ in non working and working cases. Could it be the race condition this problem suggests? I need to do further dmesg dumps to confirm.