Hooked to a jetson nano 4gb my hdmi monitor stays black.
Nano boots and I can control it through vnc so I can work remotely, I can see my regular desktop but my hdmi hooked monitor stays black.
I changed monitor, tried with three others ; changed cables, nothing, still black.
I moved my nano module to a known working board and still nothing.
I can see remotely that it is recognized in ubuntu display setting.
Any idea why hdmi output died from this nano module
???
Please dump dmesg and /var/log/Xorg.0.log when you have monitor connected and boot.
I will also suggest that before you provide the “/var/log/Xorg.0.log” that you add this to the “/etc/X11/xorg.conf” file (section “Device”):
Section "Device"
Option "ModeDebug"
...
(then reboot)
I followed yours advice, screen stays black
Here dmesg and log
Thanks anyway for help
dmesg_j08 (59.3 KB)
Xorg.0.log (233.7 KB)
Yah… of course screen stays black. This is just for dumping the log… you didn’t do anything special yet.
Please also try other kind of monitor here. Is this NV devkit or some custom board? Looks like a custom board.
I have a “farm” with eight NV devkit 4gb. I bought them to one of your official dealer about 18 months ago . They alll run the same program. One of them is faulty whatever monitor I hook on it, whatever working booting sd card I use the screen stays black .
Just for reference, the Samsung shows a lot of valid modes:
[ 16.185] (II) NVIDIA(GPU-0): --- Modes in ModePool for Samsung SyncMaster (DFP-0) ---
[ 16.185] (II) NVIDIA(GPU-0): "nvidia-auto-select" : 1920 x 1080 @ 60.0 Hz (from: EDID, CEA, Detailed)
[ 16.185] (II) NVIDIA(GPU-0): "1920x1080" : 1920 x 1080 @ 60.0 Hz (from: EDID, CEA, Detailed)
[ 16.185] (II) NVIDIA(GPU-0): "1920x1080_60" : 1920 x 1080 @ 60.0 Hz (from: EDID, CEA, Detailed)
[ 16.185] (II) NVIDIA(GPU-0): "1920x1080_60_0" : 1920 x 1080 @ 60.0 Hz (from: EDID, CEA)
[ 16.185] (II) NVIDIA(GPU-0): "1920x1080_60_1" : 1920 x 1080 @ 59.9 Hz (from: EDID, CEA)
[ 16.185] (II) NVIDIA(GPU-0): "1920x1080_50" : 1920 x 1080 @ 50.0 Hz (from: EDID, CEA)
[ 16.185] (II) NVIDIA(GPU-0): "1680x1050" : 1680 x 1050 @ 60.0 Hz (from: EDID)
[ 16.185] (II) NVIDIA(GPU-0): "1680x1050_60" : 1680 x 1050 @ 60.0 Hz (from: EDID)
[ 16.185] (II) NVIDIA(GPU-0): "1600x1200" : 1600 x 1200 @ 60.0 Hz (from: EDID)
[ 16.186] (II) NVIDIA(GPU-0): "1600x1200_60" : 1600 x 1200 @ 60.0 Hz (from: EDID)
[ 16.186] (II) NVIDIA(GPU-0): "1440x900" : 1440 x 900 @ 75.0 Hz (from: EDID)
[ 16.186] (II) NVIDIA(GPU-0): "1440x900_75" : 1440 x 900 @ 75.0 Hz (from: EDID)
[ 16.186] (II) NVIDIA(GPU-0): "1440x900_60" : 1440 x 900 @ 59.9 Hz (from: EDID)
[ 16.186] (II) NVIDIA(GPU-0): "1280x1024" : 1280 x 1024 @ 75.0 Hz (from: EDID)
[ 16.186] (II) NVIDIA(GPU-0): "1280x1024_75" : 1280 x 1024 @ 75.0 Hz (from: EDID)
[ 16.186] (II) NVIDIA(GPU-0): "1280x1024_60" : 1280 x 1024 @ 60.0 Hz (from: EDID)
[ 16.186] (II) NVIDIA(GPU-0): "1280x960" : 1280 x 960 @ 60.0 Hz (from: EDID)
[ 16.186] (II) NVIDIA(GPU-0): "1280x960_60" : 1280 x 960 @ 60.0 Hz (from: EDID)
[ 16.186] (II) NVIDIA(GPU-0): "1280x800" : 1280 x 800 @ 59.8 Hz (from: EDID)
[ 16.186] (II) NVIDIA(GPU-0): "1280x800_60" : 1280 x 800 @ 59.8 Hz (from: EDID)
[ 16.186] (II) NVIDIA(GPU-0): "1280x720" : 1280 x 720 @ 60.0 Hz (from: EDID, CEA, Detailed)
[ 16.186] (II) NVIDIA(GPU-0): "1280x720_60" : 1280 x 720 @ 60.0 Hz (from: EDID, CEA, Detailed)
[ 16.186] (II) NVIDIA(GPU-0): "1280x720_60_0" : 1280 x 720 @ 60.0 Hz (from: EDID, CEA)
[ 16.186] (II) NVIDIA(GPU-0): "1280x720_60_1" : 1280 x 720 @ 59.9 Hz (from: EDID, CEA)
[ 16.186] (II) NVIDIA(GPU-0): "1280x720_50" : 1280 x 720 @ 50.0 Hz (from: EDID, CEA, Detailed)
[ 16.186] (II) NVIDIA(GPU-0): "1280x720_50_0" : 1280 x 720 @ 50.0 Hz (from: EDID, CEA)
[ 16.186] (II) NVIDIA(GPU-0): "1152x864" : 1152 x 864 @ 75.0 Hz (from: EDID)
[ 16.186] (II) NVIDIA(GPU-0): "1152x864_75" : 1152 x 864 @ 75.0 Hz (from: EDID)
[ 16.186] (II) NVIDIA(GPU-0): "1024x768" : 1024 x 768 @ 75.0 Hz (from: EDID)
[ 16.186] (II) NVIDIA(GPU-0): "1024x768_75" : 1024 x 768 @ 75.0 Hz (from: EDID)
[ 16.186] (II) NVIDIA(GPU-0): "1024x768_70" : 1024 x 768 @ 70.1 Hz (from: EDID)
[ 16.186] (II) NVIDIA(GPU-0): "1024x768_60" : 1024 x 768 @ 60.0 Hz (from: EDID)
[ 16.186] (II) NVIDIA(GPU-0): "832x624" : 832 x 624 @ 75.0 Hz (from: EDID)
[ 16.186] (II) NVIDIA(GPU-0): "832x624_75" : 832 x 624 @ 75.0 Hz (from: EDID)
[ 16.186] (II) NVIDIA(GPU-0): "800x600" : 800 x 600 @ 75.0 Hz (from: EDID)
[ 16.186] (II) NVIDIA(GPU-0): "800x600_75" : 800 x 600 @ 75.0 Hz (from: EDID)
[ 16.186] (II) NVIDIA(GPU-0): "800x600_72" : 800 x 600 @ 72.2 Hz (from: EDID)
[ 16.186] (II) NVIDIA(GPU-0): "800x600_60" : 800 x 600 @ 60.3 Hz (from: EDID)
[ 16.186] (II) NVIDIA(GPU-0): "800x600_56" : 800 x 600 @ 56.3 Hz (from: EDID)
[ 16.186] (II) NVIDIA(GPU-0): "720x576" : 720 x 576 @ 50.0 Hz (from: EDID, CEA, Detailed)
[ 16.186] (II) NVIDIA(GPU-0): "720x576_50" : 720 x 576 @ 50.0 Hz (from: EDID, CEA, Detailed)
[ 16.186] (II) NVIDIA(GPU-0): "720x576_50_0" : 720 x 576 @ 50.0 Hz (from: EDID, CEA)
[ 16.186] (II) NVIDIA(GPU-0): "720x480" : 720 x 480 @ 59.9 Hz (from: EDID, CEA, Detailed)
[ 16.186] (II) NVIDIA(GPU-0): "720x480_60" : 720 x 480 @ 59.9 Hz (from: EDID, CEA, Detailed)
[ 16.187] (II) NVIDIA(GPU-0): "720x480_60_0" : 720 x 480 @ 59.9 Hz (from: EDID, CEA)
[ 16.187] (II) NVIDIA(GPU-0): "720x400" : 720 x 400 @ 70.0 Hz (from: EDID)
[ 16.187] (II) NVIDIA(GPU-0): "720x400_70" : 720 x 400 @ 70.0 Hz (from: EDID)
[ 16.187] (II) NVIDIA(GPU-0): "640x480" : 640 x 480 @ 75.0 Hz (from: EDID)
[ 16.187] (II) NVIDIA(GPU-0): "640x480_75" : 640 x 480 @ 75.0 Hz (from: EDID)
[ 16.187] (II) NVIDIA(GPU-0): "640x480_73" : 640 x 480 @ 72.8 Hz (from: EDID)
[ 16.187] (II) NVIDIA(GPU-0): "640x480_67" : 640 x 480 @ 67.1 Hz (from: EDID)
[ 16.187] (II) NVIDIA(GPU-0): "640x480_60" : 640 x 480 @ 59.9 Hz (from: EDID, CEA)
[ 16.187] (II) NVIDIA(GPU-0): --- End of ModePool for Samsung SyncMaster (DFP-0): ---
Is the Samsung mentioned also black screen? Is it possible to get a copy of the Xorg.0.log with only the failing monitor attached (you can use serial console or scp over the network to get the file)? I’m assuming it isn’t the Samsung which fails. You’d have to use that exact failing Jetson; if it fails even with the Samsung, then was the attached Xorg.0.log in combination with the Samsung failing during that log? I ask because according to that log the monitor should be working for that particular Jetson+monitor combination. It is a bit confusing if we are looking at the right log for the failure case.
Why are you using a custom device tree on a devkit?
[ 0.232783] DTS File Name: /media/test/home/crodriguez/nvidia/kernels/nano-drivers/kernel/kernel-4.9/arch/arm64/boot/dts/…/…/…/…/…/…/hardware/nvidia/platform/t210/porg/kernel-dts/tegra210-p3448-0000-p3449-0000-b00.dts
Can we test this with pure jetpack? Flash it with pure jetpack first, try the monitor again.
If this monitor can work on other jetson nano boards but fail on this one, then it could be hardware problem.
The Samsung I use is not failing and works with others nano.
The Xorg.0.logI posted comes from the faulty nano.
The flashed sdcard which runs on the faulty nano enable vnc automatically at startup.
I control the faulty nano through remote vnc.
Without vnc enabled as the hdmi output is dead the nano is blind.
As the nano recognize the samsung through the hdmi port but
do no send “visual” signal to the monitor I feel the hdmi port is broken somewhere
“Why are you using a custom device tree on a devkit?”
I test different cameras and lenses.
VNC might be the reason for the failure. The Xorg.0.conf may have not have been what we thought it was since VNC is installed. I’d agree with @WayneWWW that you will probably find the simplest solution to reflash, which I’ll explain.
Linux can actually run more than one X server. Each X server is an independent GUI. When logged in locally one would use a different key binding to get to different terminals; the default is that there is one GUI and several text terminals. A GUI is just another terminal, although it is a different program than the getty which is for text. Whenever any GUI runs it has an environment variable called “DISPLAY” to identify which server GUI software will talk to. If you first “export DISPLAY=:0”, then run a GUI program, the program will run on that DISPLAY (if you have permission). That program, if it encounters X errors, will log to “/var/log/Xorg.0.log”. Had the DISPLAY been “:1”, then it would have logged to “Xorg.1.log” instead of “Xorg.0.log”. The VNC server will also be a different DISPLAY. The Xorg.0.log might not be related to the currently failed locally connected monitor.
You should try and make any logs for X correspond to the physical monitor by not connecting with VNC and using ssh or serial console (or better yet flashing again and removing VNC since this might be a configuration getting in the way of the local X server). If you reboot and run this command it will sort logs in the order they were last touched:
ls -ltr /var/log/Xorg.*.log
The last log showing up will be the most recently updated log. There might be two logs, the lowest numbered most likely (but not guaranteed) to be the local monitor; any second (higher numbered) log would be from the VNC server. Perhaps there is only one log for this reboot (check timestamps), in which case either VNC or the local log is missing. Logging in to VNC likely changes timestamps, so you’d want to check this with only the local monitor connected (serial console would guaranteeVNC might be the reason for the failure. The Xorg.0.conf may have not have been what we thought it was since VNC is installed. I’d agree with @WayneWWW that you will probably find the simplest solution to reflash, which I’ll explain.
Linux can actually run more than one X server. Each X server is an independent GUI. When logged in locally one would use a different key binding to get to different terminals; the default is that there is one GUI and several text terminals. A GUI is just another terminal, although it is a different program than the getty which is for text. Whenever any GUI runs it has an environment variable called “DISPLAY” to identify which server GUI software will talk to. If you first “export DISPLAY=:0”, then run a GUI program, the program will run on that DISPLAY (if you have permission). That program, if it encounters X errors, will log to “/var/log/Xorg.0.log”. Had the DISPLAY been “:1”, then it would have logged to “Xorg.1.log” instead of “Xorg.0.log”. The VNC server will also be a different “number”, but this is not set in stone as to what number it will be. The typical virtual server will start at “DISPLAY=:10”, which means often the log will be “Xorg.10.log”. The actual number will change dependin this, or ssh without forwarding enabled).
The log I saw posted earlier had no errors. I did not know VNC was installed, and this is often a source of causing the local server to fail due to configuring VNC getting in the way of the local server configuration. It is extremely unlikely that the successful log was associated with the monitor which was failing. More likely adding VNC is what did this (thus flashing will fix it, or else the log was the wrong one).
Regardless, if we are to use a log to debug, then we have to go through steps to make sure it isn’t the wrong log.
Thanks Mister Linuxdev for your help and your time spending.
I am going to learn how to work through ssh with a new flashed sd card
and I will let you know.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.