Display with lot of noise or complete gray image on HDMI monitor after boot up of JTX1

After boot up of JTX1 i see lot of noise on HDMI display monitor , many times complete screen is ghray color and it never comes of these any situation so i have to reboot it … PFA snapshot for the same…

I verified display is connected properly so not sure what’s the exact issue ?

I am using R23.2 L4T ubuntu…


20160704_174747.jpg

20160704_174747.jpg

That looks like either hardware failure or overheating. Since this is after boot, overheating is unlikely. You might want to RMA, search for RMA near the top of this link:
https://devtalk.nvidia.com/default/topic/793798/embedded-systems/some-jetson-web-links/

NOTE: There is a tiny chance it is just something that didn’t get seated correctly, but I wouldn’t count on it.

few more snaps are attached here…

This happens after boot up of linux… this is not consistent but many times it gets stuck on one of these screens…

Is this observed frequently ?

RMA is the only solution or is there any workaround for this issue ?

20160705_113003.jpg
20160705_130850.jpg

20160705_113003.jpg

20160705_130850.jpg

I’ve never heard of it on a Jetson, I’ve seen similar issues several times with desktop graphics cards. I do not know of workarounds, but if you look at the RMA info, you’ll see it offers “live chat”. The RMA people may know of something else to test or a workaround.

NOTE: If you have work you need to save before an RMA you could clone the rootfs:
https://devtalk.nvidia.com/default/topic/898999/jetson-tx1/tx1-r23-1-new-flash-structure-how-to-clone-/post/4784149/#4784149

Reposting the RMA procedure here:

  1. Go to http://www.nvidia.com/nvcc
  2. Select “Live Chat” from the options near the top of the page.
  3. Enter your personal information.
  4. Select the appropriate product from the drop-down list (“Tegra” in this case).
  5. Submit the request.
  6. If the Service agent is unable to resolve the technical issue, an RMA (Return Material Authorization) will be initiated.

More updates on this issue :

while board is connected to HDMI display monitor if we do 10-15 reboot cycles at any random reboot, it gets stuck on one of the above screens now at this point if we just unplug and plug HDMI cable screen again becomes correct…

what could be the reasons behind this behavior ?

in this case also we need to replace the Boards ?

We are having a similar problem, where we can not boot while a 4K HDMI TV (Samsung UE40HU6900S) is plugged in, otherwise the kernel will get stuck during boot and the TX1 will automatically reboot after about 20 seconds.
But if we boot without the TV plugged in and only plug the HDMI TV in after Ubuntu has booted, it works as expected.

I believe the problem lies somewhere in the initial handling of HDMI for showing the console during booting, since this problem is only present at boot.

Have you tried with a different monitor?

Yes I have tried with different display including smaller like liliput and HDMI monitor …

First thing in my case it boots properly it never reboots automatically but after boot up it is stuck in one of above screen so i need to unplug and plug HDMI cable to make it display properly…

I have observed issue with only large display , it worked most of the time with liliput tiny display.

even if it only occurs with larger resolution displays is it because of HDMI driver ?

If this were R24.1, then some errors may be because of mis-reading the EDID data from the monitor (i2c protocol). The result would be not knowing the monitor’s capabilities, and perhaps using a mode the monitor is not capable of. However, the original images of artifacts and gray still seem likely to be a separate hardware issue. The screen coming up but being corrupted would be a different issue versus not coming up at all due to an invalid video mode (which would be rejected by the monitor).

You may wish to install packages “read-edid” and “edid-decode”. Then run this to see how the monitor is queried (this can be run from serial console or ssh if video is failing):

sudo get-edid | parse-edid
sudo get-edid | edid-decode

Info regarding the R24.1 EDID failure is here, but I believe this is probably a different issue:
https://devtalk.nvidia.com/default/topic/946129/jetson-tx1/switching-to-tty1-6-/?offset=2#4910618