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?
