Hello everyone ,
i have a board with # R28 (release), REVISION: 1.0, GCID: 9379712, BOARD: t186ref, EABI: aarch64, DATE: Thu Jul 20 07:59:31 UTC 2017
Sometimes it became unresponsive - doesn’t let SSH login , reply to pings for 400-500 ms on a LAN .
The only visible mean to recover - power reset . Usually it takes 2-3 mniutes , but today it took about 20 minutes and finally board came up right before i decided to attach UART console .
System is headless , normally UART pins are occupied with some peripheral device and developers are working with code quite intensively.
The problem is that i can’t find any reason for such behaviour in logs . Kernel messages stops at some time and re-appear only after successful reboot.
If it’s a sort of software crash - why does it take so long to recover ? could filesystem check take so much time ? Any ideas are appreciated .
Thanks in advance !
Dmitry
The serial pins which are being used…are they from J21? This is serial console and using them for other purposes without disabling serial console could result in some very odd issues.
Now that you do have serial console you could run “dmesg --follow” to see any updates as they occur, and when the system freezes you’ll see the last messages…this might include more than what the logs show after a reboot.
You could also run something like “htop” on serial console to see what this shows as the system freezes. Perhaps one process will show up as consuming everything.
Reboot time could be extended with file system repair, but because of the journal this is not likely most of the time. Something which does happen often is reliance on a network service when network is unable to connect for that service, e.g., it is possible for a DHCP request pause and wait for timeout prior to continuing.
On the topic of networks, if your passwords are not strong and if the Jetson is on a network accessible by anyone but you, then I would expect to be hacked and have things go wrong since default Ubuntu passwords are known to the world.
Thanks for your reply!
I think that since UART is used for other purpose i should disable serial console. What exactly should i do for this ?
As for the network - during that “silent booting” there was no CD from eth0 of TX2 , port on the switch where it connected was down and I even thought the port got broken.
From all the said, it looks like some issue before the system turns on the network. Could it be just fsck ?
Many thanks in advance !
Dmitry
The method for changing this is different in R28.1 versus earlier releases, so I’m not sure what would be required. U-Boot itself is part of the issue since serial console is enabled there as well as separately in the Linux kernel. If the serial port is not used until after reboot, then it should be ok to disable just the kernel serial console.
Once the Linux kernel takes over these arguments are what enable serial console:
console=ttyS0,115200n8
However, this part of command line seems to now be passed via device tree. Can someone comment if serial console can be disabled via device tree for both U-Boot and Linux?
NOTE: It looks like kernel command line is part of “chosen” DTS entry, but I doubt this disables in both Linux and U-Boot.