[SOLVED] Nonstop EDID block 0 is all zeroes on console

[utkonos]

The following two lines were on the console hundreds of times:

EDID block 0 is all zeroes
i2c i2c-4: sendbytes: NAK bailout.

This is on a ASRockRack E3C246D4U2-2T bios version L2.44A

i2c-4 is: /sys/bus/i2c/devices/i2c-4: i915 gmbus dpb

Using this command:

readlink -f /sys/class/drm/card[0-9]/device
for c in /sys/class/drm/card[0-9]-*; do printf '%-22s %-14s %s\n' "${c##*/}" "$(cat "$c/status")" "edid=$(stat -c%s "$c/edid" 2>/dev/null) bytes"; done

I get this output:

/sys/devices/pci0000:00/0000:00:1c.0/0000:05:00.0/0000:06:00.0
/sys/devices/pci0000:00/0000:00:02.0
card0-VGA-1            connected      edid=0 bytes
card1-DP-1             disconnected   edid=0 bytes
card1-DP-2             disconnected   edid=0 bytes
card1-HDMI-A-1         disconnected   edid=0 bytes
card1-HDMI-A-2         disconnected   edid=0 bytes
card1-HDMI-A-3         disconnected   edid=0 bytes

Then in separate ssh connections, I ran dmesg -W in one and the following list of commands, one by one, in the other:

echo detect > /sys/class/drm/card0-VGA-1/status
echo detect > /sys/class/drm/card1-HDMI-A-1/status
echo detect > /sys/class/drm/card1-DP-1/status
echo detect > /sys/class/drm/card1-HDMI-A-2/status
echo detect > /sys/class/drm/card1-DP-2/status
echo detect > /sys/class/drm/card1-HDMI-A-3/status

This revealed the following to be the culprit: echo detect > /sys/class/drm/card1-HDMI-A-1/status

Then just for good measure, I ran this: echo off > /sys/class/drm/card1-HDMI-A-1/status

And after a few minutes of the log messages being totally quiet, this was identified as the culprit.

For my system, I am running ZFS, so the solution to quiet this permanently was to edit /etc/kernel/cmdline

First make a backup: cp /etc/kernel/cmdline /root/cmdline.bak
Then change old command line: root=ZFS=rpool/ROOT/pve-1 boot=zfs
To new command line: root=ZFS=rpool/ROOT/pve-1 boot=zfs video=HDMI-A-1:d
Then run proxmox-boot-tool: proxmox-boot-tool refresh
And reboot.

After reboot the flood of both of those messages is gone.

 

[andy25225]

With a fresh install of 9.2, i was getting this same problem.

CPU is an Intel Xeon E3-1245 v6, on a Supermicro X11SSH-LN4F.
This board has no outputs for the iGPU.

to silence the EDID spam you will need to disable all the HDMI outputs
video=HDMI-A-1:d video=HDMI-A-2:d video=HDMI-A-3:d

 

[celemine1gig]

Just out of curiosity:
Do you get the same EDID related messages on a bare-metal OS?
Are you passing through the iGPU? LXC, VM?

 

[utkonos]

With a fresh install of 9.2, i was getting this same problem.

CPU is an Intel Xeon E3-1245 v6, on a Supermicro X11SSH-LN4F.
This board has no outputs for the iGPU.

to silence the EDID spam you will need to disable all the HDMI outputs
video=HDMI-A-1:d video=HDMI-A-2:d video=HDMI-A-3:d

Yes, this is exactly the same as the workaround that I posted, but you did not isolate the one of the three that is causing the issue.

Just out of curiosity:
Do you get the same EDID related messages on a bare-metal OS?
Are you passing through the iGPU? LXC, VM?

I am running Proxmox on bare metal. The message I posted about is from the host OS.

 

[celemine1gig]

There is a difference between a real solution and a workaround.
From what you describe, it sounds like the board manufacturer (probably both Asrock and Supermicro, as mentioned in this thread) botched the VBIOS/VBT settings that get integrated in BIOS and define the available outputs and their specific setup/attributes.
If the board manufacturers don't do it correctly, the driver tries to detect stuff that can never be there.
So, if this is a persistent issue, that you are seeing with any recent Linux kernel, then I would suggest contacting the manufacturer about it.
If you are lucky, then they already know about it and might even have a new BIOS. Who knows, until you ask?

 

[utkonos]

There is a difference between a real solution and a workaround.
From what you describe, it sounds like the board menufacturer (probably both Asrock and Supermicro, as mentioned in this thread) botched the VBIOS/VBT settings that get integrated in BIOS and define the available outputs and their specific setup/attributes.
If the board manufacturers don't do it correctly, the driver tries to detect stuff that can never be there.
So, if this is a persistent issue, that you are seeing with any recent Linux kernel, then I would suggest contacting the manufacturer about it.
If you are lucky, then they already know about it and might even have a new BIOS. Who knows, until you ask?

Yes, thank you for that correction. I have edited my last comment to make sure that this is termed a workaround. Unfortunately, I don't have cycles to contact the board manufacturer, but thanks for pointing out that avenue.