I have seen the Nano crash with this output pattern on many occasions, on many devices. Does the pattern give a clue as to the reason why the device crashed? It happens once every few weeks, with any of my Nano based devices. I have no idea of the cause, it occurs at seemingly random intervals. Hope you can help!
I should add, that overall the image looks grey, this is a close up of the pixels on the screen. This image represents around 10% of the width of a 1080p output.
Another important piece of information is when this happens, if I connect through SSH I can close our application and restart it, but the grey pattern persists. like it overlays everything on the desktop.
FYI I have seen this happen on both:
Nvidia Nano developer kit booting from microSD
Nvidia Xavier NX plus Auvidea JNX30 Carrierboard booting from internal eMMC with additional M.2 SSD
I discovered that :
sudo pkill X
does get rid of the grey pattern, and returns me to the login page on the device
this doesn’t really solve my problem, but i guess it gives us a hint where the issue is coming from?
With the information, we cannot tell what is going on.
If this could be workaround by killed the Xorg, then I think it is still software side problem. Just a bug that has low reproduce rate.
You can try to do more test like testing this over other jetson nano devices and see if this issue would happen. This can prove that it is not due to broken hardware.
Also, try to upgrade the system. It is just for debug, I am not asking to you totally move to latest release for your product.
it is not a bug with our application, because I can kill our application via SSH and then restart it and the pattern persists overlaying anything that happens on the device.
I am not blaming that this is the bug from your application. My point here is you can firstly check if this issue is triggered by your application. Triggering some bugs do not mean your application itself has bug.
This is a totally new issue that no one ever reported before, so issue will not be resolved by just giving out few comments and we will know how to solve it.
Please clarify the situation first
What is the exact situation to hit this problem? I mean if you don’t run your application, will this error happen automatically?
Do you have other jetson nano to validate this issue? This can prove whether this is hardware issue or not.
How is the reproduce rate of this issue? I mean if you run your application 1000 times, how many times will hit this?
Will this issue happen if you use rel-32.6.1? Again, this is just for debug. If you cannot run a gl application on rel-32.6, please tell me the reason.
Is it possible to share your code to us so that we can try to reproduce this with our device?
You might want to ssh in and monitor the Xorg log as this occurs. I’ll assume you are using a DISPLAY of “:0”, but adjust if using something like “:1”. On a separate ssh terminal run this: sudo tail -f /var/log/Xorg.0.log
Note what the output stops at once your application is running normally. Then, after the problem hits, but before killing it, note if something has been appended to the log.
linuxdev - thanks for the suggestion. Much appreciated - I will try that next time it happens
WayneWWW - thanks for giving this some further thought, here are some answers to your questions…
What is the exact situation to hit this problem? I mean if you don’t run your application, will this error happen automatically?
The error happens a few minutes after the devices are started. it is rare. sometimes I will go for weeks without seeing it. then sometimes it will happen a few times in a row after the device boots. Our application is running from sh script acting as a systemctl service.
Do you have other jetson nano to validate this issue? This can prove whether this is hardware issue or not.
I have a few of them yes, I have seen it happen on many different devices.
How is the reproduce rate of this issue? I mean if you run your application 1000 times, how many times will hit this?
I would estimate in a thousand runs of the device it would happen around 40 times.
Will this issue happen if you use rel-32.6.1? Again, this is just for debug. If you cannot run a gl application on rel-32.6, please tell me the reason.
I will try to setup a new jetson release for comparative testing.
Is it possible to share your code to us so that we can try to reproduce this with our device?
I have a few of them yes, I have seen it happen on many different devices.
With this answer from you, I guess we need your sample code to reproduce this issue and see what is going on. This is probably just software side problem.
Also, you can try to disable this systemctl service first to confirm if this issue is triggered by your application.
Frankly speaking, I guess it is. We have lots of users here who conduct reboot stress test. They don’t report any of such issue after thousands of reboot iterations.
Just a thought: This might be a timing issue as to when the service starts. Perhaps there is some other service which the program running on depends on, and normally the other service is up and running in time. Such services might change timing on occasion during boot. If this is the case, then you might see if your program possibly has a need of another service which the systemd script needs to mark as a prerequisite to guarantee which order the service starts in. I base this on the idea that this is “sometimes” after a boot, versus “sometimes after the system has been running for some time”. That sounds like timing.
Hi Wayne. Thanks for checking in. Much appreciated.
I am not going to be able to provide the source for our application. But I will continue to monitor the systems to try to find the cause of the problem. If I can find the source of the problem then I will try to provide a cut down application to reproduce the error, if possible.
But I haven’t seen it happen since we spoke last. So its pretty tricky to trace. I will be trying the suggestions by linuxDev re: xorg log, next time it happens and I will report back.
If this is a 4GB nano, you can also try with default gdm3. But since it looks like this issue takes really long time to just reproduce once. I will leave option to you to decide.
