Infinite restarting after flashed Jetson Linux 6.0 production release

Let’s separate these two issues, in this topic, skip oem-config works

In previous log, that CBB error leads to reboot too.

This is not true. In my observation, CBB errors occurred on every rebooting, so the logic is

  • An unknown reason causes oem-config reboot
  • On rebooting, the serial console flood CBB errors
  • Several seconds later, it does reboot
  • Repeat the above process

For the nvstart-weston.sh issue, the logic is:

  • The AGX Orin reboot instantly after run the command
  • On rebooting, the serial console flood CBB errors
  • Sometimes it does reboot in several seconds later, and Sometimes it stuck on flooding

For a workable installation:

  • I reboot or shutdown the AGX Orin
  • On rebooting or shutting down, the serial console flood CBB errors
  • Several seconds later, it does reboot or shut down

Ok. Thanks for clarification.

Even though CBB error didn’t trigger reboot, they should be still fatal as such consecutive log print may slow down system … We will check them too.

Could you provide the monitor model IDs which are in use here?
We will use the monitors we have to test first. But if we cannot reproduce it, then we need to know what kind of monitors that will reproduce error.

And sorry for one more question.

Did such monitor ever hit any error on Jetpack5 before ?

I didn’t notice the CBB error before because it only shows on the serial console.

This is the first time I have had trouble configuring it.

I will try to reflash a JP 5.1.3 if I can find my old Ubuntu 20.04 PC

TBH, I think monitors are common, and if you haven’t encountered my issue before (in your QA process), it might be that my hardware has a problem.

Is there any tool to diagnose the hardware?

I think you could cross check with Jetpack5. If this is really hardware issue, then Jetpack5 may not work either.

I grab an old PC, fresh install Ubuntu 20.04 and SDK manager.

Flash the AGX Orin with 5.1.3

  • No oem-config issue
  • No CBB error issue

Here is the log: minicom.cap.txt (147.6 KB)
All reboot trigger by me

However,

  • nvstart-weston.sh still not working
    • The monitor reports no signal
    • Serial console shows it doesn’t reboot, and running normal except display
    • I can get /tmp/weston-startup.log in serial console
jasl@jasl-tegra:~$ cat /tmp/weston-startup.log 
Date: 2024-05-06 CST
[02:22:39.778] weston 6.0.1
               http://wayland.freedesktop.org
               Bug reports to: https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston&version=3.0.0
               Build: unknown (not built from git or tarball)
[02:22:39.779] Command line: /usr/bin/weston
[02:22:39.779] OS: Linux, 5.10.192-tegra, #1 SMP PREEMPT Mon Feb 19 20:19:53 PST 2024, aarch64
[02:22:39.780] Using config file '/etc/xdg/weston/weston.ini'
[02:22:39.781] Output repaint window is 8 ms maximum.
[02:22:39.781] Loading module '/usr/lib/aarch64-linux-gnu/weston//drm-backend.so'
[02:22:39.783] initializing drm backend
[02:22:39.783] no drm device found
[02:22:39.783] fatal: failed to create compositor backend
[02:22:39.783] Internal warning: debug scope 'drm-backend' has not been destroyed.

Thanks for sharing the result. I think that is still software scope issue.

Thank you for helping me.

Hope you can reproduce my case and find the root cause.

We can reproduce the issue. Will do further check.

2 Likes

May I ask if the source of the bug is from the OS or the firmware?

From the L4T OS. We have located the root cause.

1 Like

Is there a workaround? Wasted a good chunk of my week on this issue.

Workaround in comment #15.

2 Likes

Confirming that this workaround worked for me also.

1 Like

Do we have a fix ETA?

Issue has been fixed. You can just reflash your board with sdkmanager again.

BTW, that weston issue is not included.

Thank you!

Do you confirm the Weston issue?

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.