I have a new AGX Orin 64gb dev kit. I flashed it with JetPack 6.2.1. Initially, it booted, and I got into the desktop environment. Now, I cannot get video signal out of it nor ssh into it. Running arp -a on another machine on the same local network, I see this “incomplete” entry for the Orin:
ubuntu.attlocal.net (192.168.1.103) at (incomplete) on en10 ifscope [ethernet]
I tried re-flashing it again, and it did not help (bricked right away).
I used sdkmanager on an ubuntu 22.04 machine to flash it, and selected all optional components. I installed to the built-in storage.
What should I try?
*** Please note that this reply is generated by LLM automatically ***
I’d be happy to help you troubleshoot the issue with your AGX Orin 64GB dev kit.
Initial Assessment
Based on your description, it seems like the device was initially working correctly after flashing with JetPack 6.2.1, but now it’s not booting properly, and you’re unable to get a video signal or SSH into it. The “incomplete” entry for the Orin on your local network suggests that the device is partially recognized, but there’s an issue with the network configuration or the device’s boot process.
Comparison with Similar Issues
I’ve reviewed the context and found some similar issues that might be relevant to your problem:
- Boot failed: There’s a topic about boot failure on Jetson Xavier NX, which might be related to your issue. However, the discussion is focused on a different device, so it’s not directly applicable.
- Boot fails after restoring a Jetson orin NX: This topic discusses a boot failure issue after restoring a Jetson Orin NX device. Although it’s a different device, the issue might be related to the boot process or the device tree configuration.
- Lan7430 issue for custom board Jetson Orin Nano: This topic discusses a PCIe issue on the Jetson Orin Nano, which might be related to the “incomplete” entry on your local network.
Potential Causes and Solutions
Based on the information provided, here are some potential causes and solutions to try:
- Re-flash the device: You’ve already tried re-flashing the device, but it’s worth trying again with a different approach. Make sure to select the correct device and follow the flashing instructions carefully.
- Check the device tree configuration: The “incomplete” entry on your local network might indicate an issue with the device tree configuration. You can try modifying the device tree to resolve the issue. Refer to the topic “Changing PCIE Lanes and Speed by editing the Device Tree” for guidance.
- Verify the network configuration: Ensure that the network configuration is correct, and the device is properly connected to the local network. You can try pinging the device or checking the network settings on your router.
- Try a different boot mode: You can try booting the device in a different mode, such as recovery mode or safe mode, to see if it resolves the issue.
- Check for hardware issues: Although unlikely, it’s possible that there’s a hardware issue with the device. Try checking the device’s hardware components, such as the Ethernet port or the HDMI output.
Next Steps
To further troubleshoot the issue, I recommend trying the following steps:
- Try re-flashing the device again, following the instructions carefully.
- Check the device tree configuration and modify it if necessary.
- Verify the network configuration and ensure the device is properly connected to the local network.
- Try booting the device in a different mode, such as recovery mode or safe mode.
If none of these steps resolve the issue, please provide more information about your setup, including the exact flashing process you followed and any error messages you encountered.
FYI, the real information about boot is from serial console, not from the monitor. See:
https://developer.ridgerun.com/wiki/index.php/NVIDIA_Jetson_Orin/In_Board/Getting_in_Board/Serial_Console
Do note that Jetsons do not have a hardware BIOS, and that the function of such is in software only. The side-effect of this is that it is nearly impossible to “brick” a Jetson. To be bricked it means it cannot be flashed or repaired without removing chips from the circuit board and reprogramming them outside of the system. Most likely something about the flash is wrong, but you can flash it again; if it can be flashed again, then it isn’t bricked, it is only failing temporarily. To know what is going on you can do two things with serial console:
- Get a boot serial console log.
- Get a serial console log during the flash.
Also, if you flash with JetPack/SDK Manager, then there is an export logs function, and you should click on that after the flash. Then attach the log to the forum. Any of the other serial console logs can have their session logged with the serial console program, and you can attach those to the forum as well.
Ok, I exported the logs after flashing (attached) using sdkmanager on ubuntu.
I do not see a /dev/ttyACM* device, so I cannot use minicom or screen to connect to it. I have a usb-c connected to the ubuntu machine.
SDKM_logs_JetPack_6.2.1_Linux_for_Jetson_AGX_Orin_[64GB_developer_kit_version]_2025-07-14_17-03-23.zip (2.5 MB)
According to the logs the flash succeeded. It should have automatically rebooted, and you’d need to respond to the first boot admin account setup. It isn’t unusual for people to have video issues despite the Jetson otherwise running as intended.
You should be able to use serial console for completing setup until the monitor issue is resolved, but is there anything unusual about your monitor or cable? For example, is there an adapter? It is normally harmless to adapt between HDMI and DisplayPort, but you would normally get a failure with some of the other types, e.g., old VGA to DisplayPort is expected to fail. Similar for analog DVI, but digital DVI usually works. Also, if the monitor has unusual resolutions, such as an LVDS display with some sort of adapter, this usually fails either from lack of EDID setup or from incompatible modes.
Relating to serial console, if you your host PC you monitor “dmesg --follow” (which continuously appends to the log as events are seen), and you plug in the serial port USB cable, what log lines are added as a result of that USB plug-in? Please note that only one connector has serial UART ports, the one on the left as you face the 40-pin header.
Ok, I got it to work by connecting it to a different monitor.
It seems there were multiple things going on here:
- It doesn’t like my 5k2k ultra wide monitor. In fact, while connected to that, I cannot ssh into it. After disconnecting it and rebooting, I can ssh to it again.
- I was not able to use it in “usb modem” mode. I used the same usb-c cable that I used for flashing it, so you would think there is nothing wrong with the cable.
Anyway, it works now, which is great, and I will try to get by with only using it in “ssh mode” for now.
If you connect to your Jetson via either serial console, or via ssh, and then monitor “dmesg --follow”, you could unplug the working monitor, and then see where the log ends. Watch for new log lines. Then plug in the failing monitor, and post the log output for the failing monitor plug-in event here in the forum. There might be options to figuring out why that monitor fails.
Plugging in the “bad” monitor again, now it (at least) initially works, although not at the full resolution of the monitor. I get these dmesg messages:
[ 14.965364] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
[ 14.965703] Aquantia AQR113C 6800000.ethernet:00: No AQR phy_mode setting in DT
[ 15.322977] usb0: HOST MAC fa:41:67:91:2e:3c
[ 15.322987] usb0: MAC fa:41:67:91:2e:3d
[ 15.323602] usb1: HOST MAC fa:41:67:91:2e:3e
[ 15.323605] usb1: MAC fa:41:67:91:2e:3f
[ 15.409811] tegra-xudc 3550000.usb: EP 0 (type: ctrl, dir: out) enabled
[ 15.574704] l4tbr0: port 1(usb0) entered blocking state
[ 15.574733] l4tbr0: port 1(usb0) entered disabled state
[ 15.574987] device usb0 entered promiscuous mode
[ 15.582253] l4tbr0: port 2(usb1) entered blocking state
[ 15.582274] l4tbr0: port 2(usb1) entered disabled state
[ 15.582434] device usb1 entered promiscuous mode
[ 15.595864] loop7: detected capacity change from 0 to 32768
[ 15.625352] zram: Added device: zram0
[ 15.625820] zram: Added device: zram1
[ 15.628685] zram: Added device: zram2
[ 15.631165] zram: Added device: zram3
[ 15.633716] zram: Added device: zram4
[ 15.634223] zram: Added device: zram5
[ 15.635933] zram: Added device: zram6
[ 15.637405] zram: Added device: zram7
[ 15.684380] zram0: detected capacity change from 0 to 8043624
[ 15.736682] Adding 4021808k swap on /dev/zram0. Priority:5 extents:1 across:4021808k SS
[ 15.740667] zram1: detected capacity change from 0 to 8043624
[ 15.748601] Adding 4021808k swap on /dev/zram1. Priority:5 extents:1 across:4021808k SS
[ 15.753575] zram2: detected capacity change from 0 to 8043624
[ 15.759543] Adding 4021808k swap on /dev/zram2. Priority:5 extents:1 across:4021808k SS
[ 15.763507] zram3: detected capacity change from 0 to 8043624
[ 15.769792] Adding 4021808k swap on /dev/zram3. Priority:5 extents:1 across:4021808k SS
[ 15.773673] zram4: detected capacity change from 0 to 8043624
[ 15.779772] Adding 4021808k swap on /dev/zram4. Priority:5 extents:1 across:4021808k SS
[ 15.784832] zram5: detected capacity change from 0 to 8043624
[ 15.790973] Adding 4021808k swap on /dev/zram5. Priority:5 extents:1 across:4021808k SS
[ 15.795606] zram6: detected capacity change from 0 to 8043624
[ 15.802169] Adding 4021808k swap on /dev/zram6. Priority:5 extents:1 across:4021808k SS
[ 15.806396] zram7: detected capacity change from 0 to 8043624
[ 15.812845] Adding 4021808k swap on /dev/zram7. Priority:5 extents:1 across:4021808k SS
[ 18.187544] nvidia-modeset: Loading NVIDIA UNIX Open Kernel Mode Setting Driver for aarch64 540.4.0 Release Build (buildbrain@mobile-u64-6262-d8000) Mon Jun 16 08:47:15 PDT 2025
[ 18.194025] [drm] [nvidia-drm] [GPU ID 0x00020000] Loading driver
[ 18.397533] nvethernet 6800000.ethernet: [xpcs_lane_bring_up][477][type:0x4][loga-0x0] PCS block lock SUCCESS
[ 18.397587] IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready
[ 18.397863] nvethernet 6800000.ethernet eno1: Link is Up - 1Gbps/Full - flow control rx/tx
[ 18.554390] loop8: detected capacity change from 0 to 8
[ 18.560571] NVRM rpcRmApiControl_dce: NVRM_RPC_DCE: Failed RM ctrl call cmd:0x731341 result 0xffff:
[ 18.573850] [drm] Initialized nvidia-drm 0.0.0 20160202 for 13800000.display on minor 1
[ 18.575003] nv_platform 13800000.display: [drm] Cannot find any crtc or sizes
[ 19.877896] audit: type=1326 audit(1752599189.355:2): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=kernel pid=2183 comm=“cupsd” exe=“/snap/cups/1102/sbin/cupsd” sig=0 arch=c00000b7 syscall=55 compat=0 ip=0xffff8cc0910c code=0x50000
[ 20.339493] audit: type=1326 audit(1752599189.815:3): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=kernel pid=2183 comm=“cupsd” exe=“/snap/cups/1102/sbin/cupsd” sig=0 arch=c00000b7 syscall=55 compat=0 ip=0xffff8cc0910c code=0x50000
[ 20.358031] audit: type=1326 audit(1752599189.835:4): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=kernel pid=2209 comm=“cups-browsed” exe=“/snap/cups/1102/sbin/cups-browsed” sig=0 arch=c00000b7 syscall=274 compat=0 ip=0xffffa7f31c28 code=0x50000
[ 20.768810] rfkill: input handler disabled
When plugging in the USB cable from the USB hub on the monitor, I additionally get these messages:
[261853.729191] usb 1-4.2: new high-speed USB device number 4 using tegra-xusb
[261853.836462] hub 1-4.2:1.0: USB hub found
[261853.836870] hub 1-4.2:1.0: 3 ports detected
[261853.917650] usb 2-3.2: new SuperSpeed Plus Gen 2x1 USB device number 3 using tegra-xusb
[261853.960194] hub 2-3.2:1.0: USB hub found
[261853.961402] hub 2-3.2:1.0: 3 ports detected
Subsequently, I was even able to change the resolution to the max of the monitor (5k x 2k @120hz).
We’ll see if this keeps working… If not, I will try to get these logs again.
If you post again be sure to post only the log messages which occur as a result of plugging in the monitor itself.
If you still have issues, also you might post the log “/var/log/Xorg.0.log” after the monitor plug-in (you would plug in the monitor before boot, boot, then unplug/replug, then get the log). Being able to get things working via late plug-in or unplug/replug is good, but it is just a workaround. It would be nice to narrow down the specific cause.
I cannot do exactly what you say – when I restart it with the monitor connected, it fails to start up properly. The best I can do is:
- Disconnect monitor and USB hub
- reboot
- ssh into it and get the log
- connect monitor and usb hub
- connect the log again
Attached are those two logs (i.e. parts of /var/log/Xorg.0.log up to just before connecting, and the part after connecting).
I also realized just now that if I just unplug the display and reboot, but keep the usb hub connected, it still fails. I have to unplug both (unplugging only usb hub also fails).
Another observation is that I can hear that the fan keeps spinning in these failed boot attempts.
The monitor is a Dell UltraSharp 40 (U4025QW).
log-boot.txt (19.0 KB)
log-after.txt (18.4 KB)
Something you might want to test…
When a Jetson is booted, and if you are at the GUI desktop (it doesn’t matter if the monitor works or not, it just matters that the kernel thinks you are at the GUI desktop), hitting “CTRL-ALT-F2” should get you to a text-only terminal which is not part of the GUI. This won’t work of course if the system itself has failed, but it will work if it is only the GUI failing. Does that do anything? Moving back to the GUI from a text console, should be “ALT-F1”. The fact that ssh works means this should work. If this works it means the keyboard is working and not the issue, but it would instead indicate it is the support for keyboard within the GUI. After boot can you “CTRL-ALT-F2” and see a terminal without any kind of replug of monitor or USB?
I think you missed something - I cannot even ssh if I boot with monitor or usb plugged in!
I did try before to ctrl-alt-f1 from the “bad boot” state, and no, I don’t get a terminal. It doesn’t react to the keyboard at all in that state.
Not F1, F2. The CTRL-ALT-F1 just goes back to the GUI. F2 is text mode.
ctrl+alt+F2 also does nothing.
That would suggest actual issues for USB or boot. There is normally an added driver which loads into the Xorg server for handling input, but this is only for the GUI and failures there would be an Xorg error; failure to go to one of the other consoles tends to mean a broader failure beyond just Xorg. I can’t say for certain, but the issue probably begins prior to Xorg loading.
The fascinating part is that an unplug and replug can help; if the main USB detection of keyboard is a problem, then replug would restore both the basic system and give Xorg a chance to load keyboard. I don’t know what to tell you though as to why it is happening.
If you get the chance, and you can log in with ssh or serial console when it fails, then run this command and post it with the label of the failed case:
lsusb
Then, after an unplug and replug to fix issues, run that command again and post the result. Maybe it is USB based in origin and not HDMI/DisplayPort in origin.
Again, ssh and serial console do not work when things fail, so I cannot run lsusb in that situation.
With everything plugged in, I see:
Bus 002 Device 003: ID 0bda:0483 Realtek Semiconductor Corp. 4-Port USB 3.0 Hub
Bus 002 Device 002: ID 0bda:0420 Realtek Semiconductor Corp. 4-Port USB 3.0 Hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 0bda:5483 Realtek Semiconductor Corp. 4-Port USB 2.0 Hub
Bus 001 Device 003: ID 0bda:5420 Realtek Semiconductor Corp. 4-Port USB 2.0 Hub
Bus 001 Device 002: ID 13d3:3549 IMC Networks Bluetooth Radio
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
If I unplug the USB hub, I see
Bus 002 Device 002: ID 0bda:0420 Realtek Semiconductor Corp. 4-Port USB 3.0 Hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0bda:5420 Realtek Semiconductor Corp. 4-Port USB 2.0 Hub
Bus 001 Device 002: ID 13d3:3549 IMC Networks Bluetooth Radio
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
The above would tend to be a more serious failure. However, is there any output to serial console during boot for the failed case even if it doesn’t reach login? If there is some sort of serial console output during boot, then the problem is much less severe than if there is no output at all during boot. I am probably getting repetitive since I’m not sure if any of the logs above are from a boot with monitor plugged in…basically any activity, even if it doesn’t boot or log in correctly, is useful.
A second question, would you happen to have another carrier board you can test with? Jetsons rarely ever brick, but if there is a hardware issue, then most of the time it is actually with the carrier board and not the module.
If something is shorted out or incorrectly routed for the monitor, then this could cause the issue. However, the story there is not so simple since device tree can change this in boot stage versus when Linux runs. It is possible for pin routing to be incorrect during boot, but then fixed as the Linux kernel loads. This would be rather difficult to cause, but if there is a reason why the device tree changes between boot stages and when the Linux kernel loads, then wiring options could change. I’m really grasping at this point because the problem is so unusual. It feels like it is some simple detail and not really hardware failure since plugging in after boot works. If the hardware really failed, then this should not work with plugin after boot either.
The USB modem device doesn’t even show up on the computer to which I connect the USB cable, on the failed boot attempts. I have no way of getting into the device in those situations.
I don’t have another carrier board.