can not ssh to nano after running over night

Autonomous Machines Jetson & Embedded Systems Jetson Nano
1

Hi,

I am running Jetson nano over night. and sometime i found that i can not ssh to the device. I rebooted and the log shows following . any help is apperciated .

====================================================
[2:50 PM] Jordan Hurwitz

Oct 21 13:19:43 cupertino kernel: [256891.476208] pcieport 0000:00:01.0: AER: Corrected error received: id=0010
Oct 21 13:19:43 cupertino kernel: [256891.476218] pcieport 0000:00:01.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=0008(Receiver ID)
Oct 21 13:19:43 cupertino kernel: [256891.486555] pcieport 0000:00:01.0: device [10de:0fae] error status/mask=00000001/00002000
Oct 21 13:19:43 cupertino kernel: [256891.495038] pcieport 0000:00:01.0: [ 0] Receiver Error (First)
Oct 21 13:45:09 cupertino kernel: [258417.162700] pcieport 0000:00:01.0: AER: Corrected error received: id=0010
Oct 21 13:45:09 cupertino kernel: [258417.162713] pcieport 0000:00:01.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=0008(Receiver ID)
Oct 21 13:45:09 cupertino kernel: [258417.175880] pcieport 0000:00:01.0: device [10de:0fae] error status/mask=00000001/00002000
Oct 21 13:45:09 cupertino kernel: [258417.185352] pcieport 0000:00:01.0: [ 0] Receiver Error (First)
Oct 21 14:03:31 cupertino kernel: [259519.699818] pcieport 0000:00:01.0: AER: Corrected error received: id=0010
Oct 21 14:03:31 cupertino kernel: [259519.699829] pcieport 0000:00:01.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=0008(Receiver ID)
Oct 21 14:03:31 cupertino kernel: [259519.711249] pcieport 0000:00:01.0: device [10de:0fae] error status/mask=00000001/00002000
Oct 21 14:03:31 cupertino kernel: [259519.720001] pcieport 0000:00:01.0: [ 0] Receiver Error (First)
Oct 21 14:20:46 cupertino kernel: [260554.237133] r8168: eth0: link up
Oct 21 14:34:14 cupertino kernel: [261362.156228] r8168: eth0: link up
Oct 21 14:39:44 cupertino kernel: [261691.942375] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
Oct 21 14:39:44 cupertino kernel: [261692.000973] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
Oct 21 14:39:45 cupertino kernel: [261693.060069] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
Oct 21 14:39:45 cupertino kernel: [261693.118631] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
Oct 21 14:39:45 cupertino kernel: [261693.177173] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
Oct 21 14:40:08 cupertino kernel: [261716.249313] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
Oct 21 14:40:08 cupertino kernel: [261716.307861] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).
Oct 21 14:40:08 cupertino kernel: [261716.366431] uvcvideo: Failed to query (GET_CUR) UVC control 1 on unit 3: -32 (exp. 1024).

====================================================

2

What is the device connected and used when this error happened?

According to the log, there is one pcie(m.2?) and usb camera.

3

There are usb camera and wifi moudle are connected .

4

SSHD is unresponsive until a successful login via a directly connected terminal. SSHD has also become unresponsive again after a period of inactivity. A successful login via a directly connected terminal works to re-awaken SSHD under these circumstances as well. This is also true with no monitor connected. It is also true when a usb keyboard is connected after boot with an unresponsive SSHD running. I’ve tried a few things attempting to wake networking up internally without having to login and then access via SSH over a shared, unfiltered LAN. They have been failed attempts so far:

  1. Altering the configuration located at /boot/extlinux/extlinux.conf to (addition in bold):

TIMEOUT 30
DEFAULT primary

MENU TITLE L4T boot options

LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
INITRD /boot/initrd
APPEND ${cbootargs} quiet pcie_aspm=off

  1. adding “@reboot ping -c 1 4.2.2.2” to the root crontab
  2. adding “@reboot service sshd restart” to the root crontab
  3. generating a failed login attempt on a directly connected terminal.

I am actively working on this problem right now and I’m open to try other ideas if they happen.

This is the network adapter that is installed:

I’m still looking into things not booting in an order that allows network access via ssh. Maybe the power state of the M.2 card? Additionally, these effects occur even after a custom Linux Kernel has been generated on board of the Nano using these methods:

https://github.com/JetsonHacksNano/buildKernelAndModules

5

Following this suggestion from many years ago corrects this behavior for me:

https://askubuntu.com/questions/16376/connect-to-network-before-user-login

“I found out how to do it :) Simply go into Network Manager > Edit Connections. Select your connection, click Edit and check Available to all users.”

Edit:

making a new directory in here: /etc/update-motd.d/
and moving these files into the new directory (for possible later use):

10-help-text
50-motd-news
60-unminimize
90-updates-available
91-release-upgrade
95-hwe-eol

really speeds up a login via ssh.

To make the wireless adapter hyper-available, I also did this:

touch /etc/pm/sleep.d/wireless

Also to remove a lot of lag during login I edited:

/etc/NetworkManager/conf.d/default-wifi-powersave-on.conf

and changed “wifi.powersave = 3” to “wifi.powersave = 2”