I’m assuming that all of the network issues are the previously reported netdev watchdog timer issue. What is interesting is that the reports I found related to this were from quite some time ago on x86 machines. In one such case the distribution that the bug was reported for simply closed the bug as no longer supported because it was so old. Sometime after this issue appeared, the error seems to have simply gone away.
Since I never saw a specific fix to the related driver, I can’t say as to whether this was part of the infrastructure surrounding RTL8169 or the driver itself, nor can I say which kernel version fixed this. It seems fairly obvious the long term stable 3.14.x kernels don’t have the issue, nor did the R19.3 L4T kernel. Packages surrounding user space are unlikely the cause, as L4T uses the more modern surrounding packages both in R19.x and R21.x. What would really help is to know the first kernel version where the problem went away…other than knowing a specific kernel version to target, I’m not sure of a good way to fix this other than going to a 3.14.x kernel (very labor intensive and not easy).
From what I can tell the issue is related to gigabit speeds only. So if one of the networks were 100 Mbit, it wouldn’t show up. On gigabit, it could show up with only a single connection. Even if your outside world is connected slow, a gigabit switch between Jetson and the link could conceivably have the issue. The issue is difficult to research since it happened so far back in time in the x86 world and current distributions are long past the issue.
21.2 is behaving very odd with wifi too. I have two broadcom adapters and one atheros based. All three exhibits random connection speed changes 1Mb - 140Mbps. Random connection dropouts… Situation is somehow better when bluetooth is turned off on atheros adapter. However, it is far from usable. I’m rolling back to 19.3
Ah, great howto. Thanks! What a bummer about ethernet though.
Could you consider adding FS support for DFS and ADFS file systems? (Acorn Archimedes).
This is pretty special I admit but probably also wont hurt anybody else :)
Btw, Grinch 21.2.x is stopped temporarily, until they do not solve the problem with the network. I have only one Jetson, making it difficult for me to work on several versions L4T
Good news! work on Gribch versions 21.x 19.x will be carried out simultaneously. big thanks to Dustin Franklin, who has supported me to buy a second Jetson!
Also a big thank you to Peter Bauer for the financial support!
You might as well add the fix I outlined in the post below, we pretty much have a fully working TegraCEC implementation, activating the CEC driver still doesnt register the platform device without this fix.
*** Flashing target device started. ***
./nvflash --bct PM375_Hynix_2GB_H5TC4G63AFR_RDA_924MHz.cfg --setbct --configfile flash.cfg --create --bl fastboot.bin --odmdata 0x6009C000 --go
Nvflash 4.13.0000 started
USB device not found
Failed flashing ardbeg.
lsusb, and I get this:
Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablet
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
I’m using an NVidia shield usb cable to connect my TK1 to my Win 8 laptop, which has VirtualBox running Ubuntu. You hold down the recovery button for a second, right?
Normal USB devices like mice and keyboards end with a “type A” connector. The micro connector on the Jetson is able to work with both a type A and a type B, but this changes the function of the Jetson itself. Type B is mandatory (this is the type of the supplied cable) during flash, as well as booting the Jetson into recovery mode. So the question is whether the shield cable is type B…if not it won’t work. Combine this with powering up the Jetson while the recovery button is held down (type B plus recovery causes the Jetson to be seen as an nVidia device on the linux host lsusb).
There have also been some issues with flash from a non-linux file system, e.g., NTFS underneath a virtual linux will fail. Remember that your linux host is copying files over to Jetson and preserving file types and permissions…if the underlying file system does not preserve this the install will not work.
I have not tried to use any application to expand a partition…but the difference between the absolute maximum partition size (14580Mib) and what many people use (14GiB) is tiny. You could try to let gparted expand to maximum size, and if it fails, flash with 14580GiB instead of 14GiB. Personally I’d just ignore it.
