this is the output of dmesg
https://drive.google.com/open?id=1x52-BCy1N0kzmDd9SIBimYSH1A3x7wCn
dmesglog.txt (67.5 KB)
1 Like
The filesystem is corrupt. Is something causing an improper shutdown?
[ 318.443972] EXT4-fs (mmcblk0p1): error count since last fsck: 35
[ 318.450064] EXT4-fs (mmcblk0p1): initial error at time 1558955956: ext4_journal_check_start:56
[ 318.458759] EXT4-fs (mmcblk0p1): last error at time 1559313301: __ext4_get_inode_loc:4072: inode 1086186: block 4196686
What is the PCI device (details)?
there is no output when doing “lspci”
no display output when connecting external monitor through hdmi , and even through “vnc” there’s no display output.
usb is not working.
i am only able to connect to jetson through “ssh”.
have u seen the total log file?
Yes, the log ends with filesystem corruption messages. This may be why it never gets further (and the reason I quoted the ext4 parts).
“lspci”, when nothing is attached, won’t show anything (and I believe power rails disable).
When something is connected, then the PCIe tries to enumerate and goes through a series of steps to determine best settings for signal quality. Depending on quality and the capabilities of the PCIe card, the PCIe revision level may step from fastest (rev. 3) down to slowest (rev. 1). If signal quality is further degraded, then the lspci won’t show anything because the PCI has marked the device as not capable of operating at even revision 1 speeds. The power bus would also shut down since PCI thinks no valid devices are connected. The PCIe bus on the TX2 is not hot plug, and thus unless special edits are used one cannot simply tell the bus to scan again later on after boot (typically users of PLCs need to make this edit because the PLC won’t be fully booted at the time the Jetson scans, and after boot it is too late unless the edits are made).
Whether your system is not getting to later stages of boot due to filesystem corruption, or because of side effects of the PCIe card, I don’t know. If there was some point in your testing where the PCIe card (or any other reason) caused a boot failure and corruption which the journal system couldn’t handle, then it may be USB was just never reached before boot stopped (I’m speaking of the PHY…drivers won’t matter if no PHY is brought up, and I see no PHY being available). It could be power issues with the PCIe card caused the initial failures even if signal quality was good. Even if the card is removed it may be a filesystem corrupted beyond repair still blocks further boot.
It would be useful to know details and a description of the card which is being connected.
thanks a lot for the detailed explanation.
I would like to clarify that we are not trying to connect any external pci devices. The on board usb, hdmi port and lan are not working. We also see a strange cpu killed message in dmesg logs.
[ 22.883876] CPU1: shutdown
[ 22.886589] psci: CPU1 killed.
[ 22.911993] CPU2: shutdown
[ 22.914726] psci: CPU2 killed.
CPU1 and CPU2 are the Denver cores. These are normally shut down in some (including default) performance modes. If you are using an older release, then you can enable those cores and make available the full range of clocks with “sudo ~ubuntu/nvpmodel -m 0”. The location of that file differs on the most recent releases, and the command would instead be just “sudo nvpmodel -m 0”. This is not an error.
Incidentally, making the full range of performance available with “sudo nvpmodel -m 0” is often also accompanied by setting clocks and fan to max. In older releases, “sudo ~ubuntu/jetson_clocks.sh”. In newer releases, “sudo jetson_clocks”. You don’t have to max out clocks, you can just turn on the Denver cores with nvpmodel.
With nothing in external PCIe slots lspci should not show anything, not even a bridge.
HDMI may have a number of complicated issues, especially with virtual desktop software. This should probably be saved for last.
The USB is probably a legitimate issue. Which connectors are being used? Is this a development board or custom carrier? If you log in via ssh and run “dmesg --follow”, what changes do you see as you unplug or plug in various USB devices, e.g., keyboard?
thank you for the reply …
“is this a development board” - it is a development board , it’s the original jetson TX2 dev board.
“which connectors are being used” - we have just connected Logitech wired usb to USB 3.1(full sized usb)
we have tried connecting and disconnecting mouse ,keyboard , usb cam. we see no message(no error message nor detected message ) while running “dmesg --follow”
So none of the PHYs are ever brought up for USB (explaining the lack of log lines upon connector insert), and this is a legitimate error. Much of the other was explained as not really an error, so now it is time to find out why the USB PHYs are not showing up.
Often this is related to device tree or something incompatible during the flash. On rare occasion some software is left out from a flash when the host PC doesn’t have enough disk space. Which L4T release is this (“head -n 1 /etc/nv_tegra_release”)? What was flashed to it with which JetPack or SDKM? Is the carrier board custom or the standard dev board? Have there been any kernel or device tree modifications?
thank you for the fast response.
“Which L4T release is this” - # R28 (release), REVISION: 2.1, GCID: 11272647, BOARD: t186ref, EABI: aarch64, DATE: Thu May 17 07:29:06 UTC 2018
“What was flashed to it with which JetPack or SDKM” - jetpack
“Is the carrier board custom or the standard dev board?” - standard dev board
" Have there been any kernel or device tree modifications? " - no .
In this case you might have an actual hardware failure and need RMA. If you are willing, then I would suggest that you try a fresh flash using a JetPack download and directory which are completely new (remove any previous content on the PC host).
Either way, if you are interested in saving the content, then you might consider cloning first. Ask if you need clone information. It goes something like this with a recovery mode Jetson:
sudo ./flash.sh -r -k APP -G "backup.img" jetson-tx2 mmcblk0p1
You can search for information on RMA near the top of this:
https://devtalk.nvidia.com/default/topic/793798/embedded-systems/some-jetson-web-links/