Helo all,
We have a batch of TX2I core modules, one of which cannot be connected to the network when running on the carrier board of TX2 DEVKIT. After plugging in the internet cable, there is no information printed in dmesg, but on the same baseboard, other modules It can be connected to the Internet normally.
The system is the Jetpack4.6.2 version flashed by SDKmanager,
With the cable plugged in, what do you see from “ifconfig” and “route”? Also, the content of “dmesg”.
dump_dmesg.txt (64.7 KB)
dump_ifconfig.txt (2.5 KB)
dump_route.txt (485 Bytes)
The above three files are the return values of the three commands. Normally, other TX2I modules are used on the same DEVkit development board. The above three commands can be used to view the ip address of eth0 and network related information. .
The first thing to note is that eth0 does show up, so the driver loaded. The second thing to note is that no bytes were sent or received; this means no DHCP request ever went out, and so no dynamic assignment was ever requested. “route” does not really matter under the circumstances.
The odd part is that the dmesg log shows the link (eth0) is not ready. I won’t guarantee it (it might be successful DHCP which causes a link ready message), but I think it isn’t possible to send a DHCP request until the link is ready. What sticks out is this is entirely requesting IPv6 protocol, and IPv4 is never mentioned. I doubt this matters since no bytes went out, but do you happen to know if your router supports IPv6? Do you have any other device you can connect to this same router and see if IP address assignment is IPv4 versus IPv6?
As an experiment, does anything change in “ifconfig eth0” if you run any of these (or any interesting messages):
dhclient eth0
dhclient -4 eth0
dhclient -6 eth0
(note that seeing TX bytes sent go up to non-zero value is interesting, and so is seeing bytes RX going up)
I’m very sorry, I forgot to reply to you due to other delays.
At present, in our usage, in the same batch of TX2I modules, on the bottom plate of the same Devkit, the same Jetpack version is used, only this module has such a situation.
In addition, we are all using IPV4, and the router will assign an IPV4 IP address to other modules in the same batch.
Can you post the following logs (they should be from almost the same time):
- Serial console log (one for a working unit, one for the failed unit).
-
ifconfig(one for a working unit, one for the failed unit). -
route(one for a working unit, one for the failed unit). - Output of “
head -n 1 /etc/nv_tegra_release” (one for a working unit, one for the failed unit).
It sounds like this will be a hardware issue, although flash might fix something, but with a TX2i there is no SD card model, and so if they are the same release, then I doubt flash will be the issue, nor the fix. Something to compare against though is good. If we can’t find the result from the above comparison, would you be able to swap a working TX2i module on a working unit with the failed unit as a way to test if the problem follows the module, versus following the carrier board?
The problem you mentioned, I have tested it and determined that the problem is with the TX2I module, not the carrier board.
At present, other normal modules in our hands have been sent to the customer’s site for work. Only this problematic module is left. It can be confirmed that other modules can be replaced before, and the network cable will be plugged and unplugged. The dmesg interface will have The information is printed, but this one module does not have any information printing.
In addition, it can be confirmed that the devkit carrier board tested is functional, because other modules can work normally on this carrier board, and the L4T version is 32.7.2.
It sounds like you have flashed this unit before the same as others (to R32.7.2). This, in combination with the problem following the module during module swap says it is an actual module failure. You probably need to RMA this module. I am surprised though since carrier board failures are not uncommon, but module failure seems much more rare.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.