tegra-i2c 7000c700.i2c: i2c transfer timed out, addr 0x0050, data 0x00
If “/sys” has the EDID data, but the i2c query command considers the data bogus, there is a question of whether the data in “/sys” is from a working query which is later corrupted, or if the query itself provides corrupted data. For reference on the data, see: https://en.wikipedia.org/wiki/Extended_Display_Identification_Data#EDID_1.3_data_format
Bytes 0 through 7 of “/sys” show correct fixed header, and checksum is correct. If you want more info, there is a nice online EDID parser named at the bottom of the Wikipedia page which you can copy and paste the “/sys” hex data info to: http://www.edidreader.com/
I do not know if that online parser notes anything about errors (other than noting if checksum passes/fails), but I suspect the “/sys” data is valid, and that the corruption is from the transfer from kernel space to user space where get-edid is given its data. For both of us the “no acknowledge” dmesg is about i2c address 0x50 (7000c700.i2c), and there is exactly one “potential” bus found, so I’m thinking the error is there. Odds are high that the controller at 7000c700 has an error in its response, although the data it has available from the kernel is correct.
Im still on 23.2. I don’t know why get-edid doesn’t work, but i don’t think it is an issue.
The edid is definitely ok.
I ran the tegra_edid_dump() in edid.c’s tegra_edid_get_monspecs function and it printed successfully. So at the dc driver level the edid is fine.
I unplugged and reran to verify it isn’t some kind of dummy edid and after unplugging it sure enough didn’t exist.
So i think I can rule out an issue with the edid.
Its more debugging the Nvidia driver and why its failing to start w/ startx, but idk how without the source. Is there any debugging utility/log i am missing for testing why the nvidia driver is not finding the display?
Hello,
We are tracking ‘get-edid’ issue internally. That should not impact the display function.
You can dump the edid through sysfs node: /sys/kernel/debug/tegradc.1/edid
From previous message, it seems that DP works but x fails to start right?
Generally, DP should work like HDMI.
Would you please check:
whether the HPD works well?
Whether the EDID is read correctly?
Whether the display mode is set automatically and correctly after cable plug-in? (/sys/class/graphics/fb1/modes shows all available modes, and /sys/class/graphics/fb1/mode shows current mode.)
The reason I wonder about the EDID in this case is because there is a sig. 11 towards the end of the Xorg.0.log. The ABI versions are correct, so the server should not segfault based on any kind of mismatched file…all of the software related to reaching this point in X11 startup is a known working combination. The part which is variable would be if data used by X11 is invalid and resulting in an invalid state. EDID is one of the only variable data sources, and we are seeing that there is a corruption of that data somewhere (“/sys” is valid, read-edid is not…where did it go wrong, and is this failed data going somewhere it shouldn’t?).
One could verify related file checksums with this if desired:
I see these same problems on JetPack2.3/L4T24.2 (cannot sync/startup with older monitor, bogus EDID I2C data & dmesg “register dump for debugging” messages with read-edid, but valid EDID data in /sys/kernel/debug/tegradc.1/edid & xrandr --valid) but also notice that the patch in comment 4 is not part of the release.
Will this patch be part of a future release or are there different/additional fixes for this problem (somewhat inconvenient to flash my module at this moment)?
I have tried booting the Tx1 with 4 different monitors. Two work fine, two older monitors don’t.
Specifically, the Jetson TX1 boots fine on a Dell U2410 & a Viewsonic Va2351-M, but won’t boot with either a Samsung SyncMaster 172x or a Dell 2007FPb.
Note that if I boot with a working monitor and start the window system, I can then switch to one of these other monitors and the HDMI sync’s up just fine.
The symptoms with both these monitors is as described in other posts: get-edid fails to read monitor EDID data (and a tegra-i2c register dump is printed to dmesg), though the data in /sys/kernel/debug/tegradc.1/edid is valid (and can be parsed with parse-edid).
I have not (yet) tried the kernel patch proposed above, nor have I (yet) tried the recent 24.2.1 release (just 24.2 and other prior releases).
DVI should support EDID, but there is still a possibility that analog pass-through is used without EDID. When each failing monitor is connected you may want to see if the file named from this has any content (if the file is non-empty, then you have EDID and the conversion from HDMI to DVI is not at fault):
As noted in comment #29, /sys/kernel/debug/tegradc.1/edid is valid and shows the correct monitor type when parsed by parse-edid or http://www.edidreader.com/ in all cases. get-edid, on the other hand, fails to read the monitor edid for some monitors and for those monitors generates a error message in the kernel dmesg log.