Hi, after booting normally, Jetson AGX Xavier shows a blue screen (it is perfoming the login automatically).
We are using Jetpack 4.3 and L4T R32.
AGX Xavier unit is already in production on the customer facilities, so doing a reflash is not a solution.
Any idea of what is provoking this issue (seems like it is not so unusual, according to the posts already existing), and how to fix it?
I don’t know about a “blue” screen per se, but is the monitor and cable purely HDMI? Has anything related to the monitor changed? Do you have ssh access to debug from, and if you do, does the ssh still work?
Could you take a picture for us to understand what “blue screen” do you see? Is this board booting into kernel?
Hi, this is the Blue Screen
the computer is connected with a HDMI Cable to an HDMI monitor, and we have all our software running and SSH still work.
We need to clarify the cause.
Does this issue happen to specific monitor or every monitor?
Does the display driver still works fine?
The kernel log should tell.
FYI, from ssh you should run “dmesg 2>&1 | tee log.txt” to get kernel log. You might also post a copy of the most recent “/var/log/Xorg.0.log” (which might be Xorg.1.log instead if $DISPLAY is “:1” and not “:0”). You could copy the log somewhere and rename it “Xorg.log.txt”.
You might also post the output of:
sudo -s
egrep -i -H `find /sys -name 'edid'`
exit
Hi,
You gave us a log that is from 16:00~ 21:00. May I know when do you see blue screen? Always see blue screen?
The kernel still detects the display.
May I know if you can see anything on screen if you run application like gstreamer?
The display is detected because we can see the device starting up and the login screen to put the password, the blue screen apears always but only after put the password and make the login, when the system loads the GUI. With the new user created the blue screen not apears after login in new account only in the old one.
We can’t see anything in blue screen account only have the access over SSH and access to services such as Apache website
Hi,
Did you really try to use gstreamer as I said? Especially the nvoverlaysink.
And are you able to enter ctrl + alt +f1~6 to switch to console mode?
We don’t have access to computer only by SSH
Is there any chance the NVIDIA-specific libraries were overwritten by something from Mesa? There are a lot of Mesa files which work perfectly well (and are needed), so there would be plenty of those, but I am thinking in particular about GL/GLX/GLES hardware acceleration files being accidentally overwritten.
What happens is that some stage of the GUI software may run without special requirements, e.g., the login manager, but then as the X server spawns and adds hardware acceleration, then any replacement with the wrong library will cause a load failure (and crash of the GUI, which was ok until hardware accelerated display was attempted).
Which files that would involve would depend on the particular Jetson and the release version. Typically there is a copy of the NVIDIA-specific version somewhere under “/usr/lib/aarch64-linux-gnu/tegra”, and a copy or symbolic link will exist to this in one of the Xorg X11 directories. If the Xorg version gets replaced with an invalid non-accelerated version, then copying the NVIDIA version in (or symbolic link to there) fixes the issue. I have not seen this in quite some time, but if you were working with an older release, then this could still occur.
Hi,
If you can use low level application to render on the monitor, but not some other X-based applications, then it means X has some problem. If even nvoverlaysink cannot work, then we may need to check other items.
That is why I asked you to try some non-X based application and nvoverlaysink is the easiest way.
If you cannot do anything but just sharing us the log, then please tell us if you customized anything on this board.
Just as linuxdev said, if you remove the NV Xorg driver, it is also possible to cause X failure.
Hi captemp,
Have you clarified the cause and resolved the problem?
Any result can be shared?
Thanks