RTNETLINK ANSWERS : Network is unreachable

Since one month, I am trying to use jetson tx1. I installed jetpack 2.2.1 64 bit. It given keybord locking. Then I installed jetpack 2.2.1 32 bit. It was ok but I given ‘monitor closing’ in short time.
I want to load again jetpack 2.2.1 32 bit. But I do anything any more.

1- My serial console does not response by pl2303. It gives error in attachment.’ RTNETLINK ANSWERS : Network is unreachable’
(Ago four days, I tried previously. I saw ‘ubuntu gui’ of jetson tx1. Now it does not work).

2- In addtion, I am trying flashing and loading jetpack 2.2.1 on host pc.

It is not determining IP adress.

3- I am writing ‘ping tx1_ip-address’ on host pc . It gives unreachable.

What is problem?

You should check if this might be the issue (this causes network problems):
https://devtalk.nvidia.com/default/topic/901180/jetson-tx1/my-jetson-tx1-is-not-able-to-connect-to-wifi/

The picture shows an OOPS message. This may have made it to a log file in “/var/log/”, perhaps kern.log, dmesg, or syslog. If the problem is not from the above web URL, then the OOPS log becomes more important. A copy would help.

If the log is needed, and if the log files do not have the OOPS, you can possibly use a serial console program to do this. Serial console setup is listed here:
http://elinux.org/Jetson/TX1_Serial_Console

My problem is not Wi-fi. I am using cable.

I am using minicom. Hos pc gives ’ RTNETLINK ANSWERS : Network is unreachable’ or jetson tx1 does not open.

When wifi firmware is bad it interferes with other parts of the system. Once this can be dismissed as a cause, it’s basically just standard DHCP setup, e.g., making sure firewalls do not interfere, making sure the router has the MAC address if security is set for this, so on.

I attached My syslog

Looks like the syslog did not make it.

I attached them. Thanks for answers

Unfortunately it looks like the logs did not make it. I noticed they were in PDF format, they were being scanned, and eventually they just went away. The log files in question should be able to work with just “.txt” names, I’m not sure where the PDF came from, maybe that is part of why they failed to attach.

I attached them. Thanks for answers as txt.

In addition I received new oops after some ssh and wifi firewall adjusment. I added syslog as jpg.

I completed flashing of TX1. But I have problem on post installation.
1- Host pc are not determining IP of tx1.
or
2- Host pc are determining IP of tx1 but it stops in the middle of post installation.

Later I trying tx1 on own monitor without post installation and host pc.
1-tx1 monitor and Ubuntu Gui run immediately and keyboard and monitor freeze
or
2- tx1 monitor does not run immediately and I am trying tx1 to open after 2-3 hours and it run that time but keyboard and monitor freeze in 1- 2 minutes.

Is this manufacturing problem?

At my first running, I used HDMI TV. I saw instlaler.sh in TX1. Since Monitor and keyborad freeze, I could not run instller.sh. Later I used Jetpack on host Pc. I connected to TX1 monitor by VGA-HDMIconverter. Always I have freezing and autoclosing. I tried flashing and post installation again and again. Even I tried 32 bit and 64 of jetpack 2.2.1, and jetpach 2.1.
I consider that tx1 has a manufacturing problem.

syslog1.txt (3.15 MB)
kern1.txt (6.7 MB)

A note on monitor cables and adapters: Older 15-pin VGA lacks the wire required for the system to query a monitor, and adapters also cut that wire. If the video is in a default mode which the monitor can use, then you’re in luck. Otherwise, video will always fail with 15-pin VGA since there is no ability to query the monitor for valid modes.

The kern1.txt log looks like it is from the PC host, not the Jetson. Logs for Jetson are needed.

Is the host losing its network connection too? Or just the ability to reach a Jetson? On your PC host, and if you can reach the Jetson, what is the output of “ifconfig” for each? Is host connected to a router, and Jetson connected to the same router, or is Jetson connected to host over an ordinary switch (if via router, then the router has to do DHCP work…if via switch, then host PC does DHCP work…JetPack alters its behavior depending on this wiring)?

Many thanks for answers. I hope that problem is from host or monitor.

Finally I will buy hdmi monitor.

On the other hand, I had tried with HDMI TV at the begining. TV runned. I saw Black screen and installer.sh and later keybord locked (Capslock was off) or monitor had freezed.

Moreover in my first 32 bit installation afteer 64 bit instlations again again due to kyboard locking and motir freezing, I had used TX1 monitor with VGA-HDMI converter. Even I installed Caffe. But when I runned caffe, after finishig mnist example, monitor closed and I did not take a look to its results.Leds of tx1 was on

1- Is the host losing its network connection too?
No. Host leads with netwrok connection. Host does not just reach to jetson.

2- Host ip: 10.47.0.82 jetson ip: 10.47.0.19. They uses same router.

Today I opend Jetson. I saw ubuntu gui. Later monitor converted into black. Keybord did not worked. Leds of tx1 was on but my usb hub led was off. I plugged out power cable.

One problem when video appears to go away is that there can be many causes. Without a serial console to see what is going on, it is difficult to offer advice on what step to take next. If you can, perhaps set up a serial console (this is immune to video and network driver failure):
http://elinux.org/Jetson/TX1_Serial_Console

However, if your host can ping the Jetson, but later on ping no longer works, then you probably do have a system lockup…but a serial console would still be of use because it will probably dump the OOPS message.

My serial console outputs are. Monitor led is on but screen is black.

Ok, the file attachments in the thread are now showing up. FYI, I see this in some of the logs, and so my answers may be wrong if mixing host and Jetson errors:

Dell Inc. Inspiron 7559/0H0CC0

…on the other hand, if there are OOPS or other issues being reported from the host, this could also explain a few things…but really we almost need to start over and collect fresh logs and information which is not mixed together. Answers below are probably sometimes wrong due to mixing of logs (this does not mean the logs are not useful, and whatever happens in the host is also of interest).

Starting at an earlier attachment, I see a lot of messages like this:

Aug 12 11:56:03 selman-Inspiron-7559 avahi-daemon[681]: Invalid response packet from host 10.47.0.57.

…many addresses from inside of the router are responding to something with an invalid response. The response is considered corrupted. At first I thought this must be a DHCP response from multiple machines configured as DHCP servers, but avahi may be be looking at multicast as well. Do you have multiple devices on the router, and is it possible those devices have any kind of router configuration? The dotted-decimal addresses within the private router network which are sending packets to the Jetson are:

10.47.0.57
10.47.205.172
10.47.206.21

…this may be a log from the Dell instead of the Jetson, in which case the concept is still correct, but the machine responding is the Dell instead of the Jetson…there would still be an issue, just not directly on the Jetson.

Later JPEG images show a kernel OOPS message, but a lot is cut off so I can’t tell what the complete OOPS is. These would basically be a crash of a driver or some part of the kernel…this is not normal on a Jetson (nor on any Linux machine); this makes me think of either the firmware issue of WiFi mentioned in my first reply (you don’t even need to configure WiFi for this to cause havoc with other parts of the kernel and networking since this essentially is bad hardware), or of a custom compiled kernel with a different feature set versus the default feature set.

The second OOPS I glimpsed from a partial JPEG is an undefined instruction. I have seen something similar before on a custom compiled JTX1 kernel. The issue was not present with one 4.8 Linaro compiler, but was present on several others. The default compiler which comes with documentation download from the driver package (“baggage” subdirectory of the html help) does not do this, many other compilers do. I have never seen this with the pre-compiled kernel arriving with a fresh Jetson or with the kernel included by default during a flash update. Was this kernel ever custom compiled? If so, both configuration and compiler version need to be considered (if you compiled, what compiler was used?).

There is no way from this to give an exact answer, but it is quite possible that the corrupt packet message for DHCP response is not handled properly in networking code…this code could probably run for a long time with no issues if the packet response were valid, and so invalid handling of a bad packet may have never been considered.

I also noticed the kern.log mostly shows an uninteresting kernel load at boot, but towards the end, once common tasks are complete, things go bad. This log does appear to be the Dell though, not the Jetson. Your host does interact with the Jetson, so a failure like this from the host is also important. Just FYI, when JetPack runs it can do some network setup (the setup is designed for Ubuntu 14.04 hosts)…manual driver flash without JetPack does not set up anything on host. This is particularly interesting:

CPU: 6 PID: 0 Comm: swapper/6 Tainted: P           OE  3.19.0-30-generic #33~14.04.1-Ubuntu
Hardware name: Dell Inc. Inspiron 7559/0H0CC0, BIOS 1.1.3 11/05/2015

I also saw some PCI messages of interest…is there any PCIe device on the Jetson? If not, then the device messages are from the Dell host. If the Jetson has anything connected on PCIe, can you describe this? Non-functioning hardware, regardless of whether it is just firmware or software, can interfere in unexpected ways with otherwise unrelated parts of the system.

I’m not sure where to start, but basically I think that provided the WiFi firmware bug is not interfering with hardware, then the Jetson can be flashed manually with the driver package+sample rootfs and it would work normally. If the Dell is host and not running correctly though (is it a VM install? Does it have at least 20GB of free space?), then this would be a cause of the flash being incorrect. Can you describe the host, including if the CPU is 64-bit and free space reported from “df -H”, along with which Linux distribution/version it runs?