Nano can detect the rtl8821ce, but tx2 can’t, why?
Hi garretzou,
Are Jetson Nano and TX2 on same L4T version? Can rtl8821ce work normally with Jetson Nano?
Yes, both on version 32.1. Jeston Nano can dectect rtl8821ce, but modprobe its driver will crash.
Here I most care is why my tx2 can’t detect any pci device but lspci command on jetso nano result,
ISBU:~$ lspci
00:01.0 PCI bridge: NVIDIA Corporation Device 0fae (rev a1)
00:02.0 PCI bridge: NVIDIA Corporation Device 0faf (rev a1)
01:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8821CE 802.11ac PCIe Wireless Network Adapter
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
If you log in via serial console you’ll be able to log and see messages even if the system crashes. If you run “dmesg --follow”, and then insmod the driver, what do you see?
Thanks,linuxdev.
Here I just care why TX2 can’t detect any pci device. And we changed a wifi chip. So I don’t care the driver any more.
The log I flash emmc, please refer the attach file.
I see something which looks relatively normal, but no insmod or lspci. The goal is to see any change in output to “dmesg --follow” on one terminal while on another terminal you run the insmod command for the driver module, plus the output of “lspci” after that module insmod.
I don’t know about this particular chip, but I saw references that there may not be a driver (although some people worked on it):
[url]networking - Wi-Fi not working on Lenovo ThinkPad E570 (Realtek RTL8821CE) - Ask Ubuntu
[url]networking - How to install Wi-Fi driver for Realtek RTL8821CE on Ubuntu 18.04? - Ask Ubuntu
[url]https://github.com/tomaspinho/rtl8821ce[/url]
Or in some cases where the custom drivers were added bluetooth failed if the correct firmware is not added:
[url]https://github.com/tomaspinho/rtl8821ce/issues/19#issuecomment-452196840[/url]
In the case of PCIe you should see the existence of the hardware with lspci even if there is no driver. Is this the full sized PCIe slot on the dev carrier?
I can’t imagine that if it is detected on the Nano it wouldn’t detect on the TX2, but sometimes the more modular M.2 slots are not always what you expect (e.g., there are sometimes alternate use of USB instead of PCI even though the slot might support both…the device tree can change whether this works or fails). Seeing the lspci from the Nano might help.
Thanks, linuxdev.
We changed a wifi chip. So don’t care rtl8821ce any more.
What make us confused is why "lspci on nano shows as follow,
Last login: Thu Aug 29 05:44:03 2019
ISBU:~$ lspci
00:02.0 PCI bridge: NVIDIA Corporation Device 0faf (rev a1)
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
but on tx2 nothing. Both kits(nano and tx2) are not plugged into any wifi chip.
And the logs of “dmesg --follow” on nano and tx2 are attached as bellow.
tx2_dmesg.log (57.9 KB)
nano_dmesg.log (56.5 KB)
The different Jetson models have at times wired the ethernet chip interface differently. In one case it may be wired directly to a memory controller (neither lsusb nor lspci will show such a device), in another type of Jetson to USB (a case where the device shows in lsusb only and might go away during USB autosuspend), and in yet another Jetson design this may be wired to PCI (a case where the device shows in lspci). In any case where PCI does not detect anything there during boot you can expect it to power down PCI and you won’t even see a PCIe bridge.
For the logs I see entire boot. Although the whole boot is useful, did you notice anything specifically during an insmod of the driver? I do see this on the TX2, so this is probably a 10Gb/s Intel NIC:
[ 3.295627] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
[ 3.295630] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[ 3.295725] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k
[ 3.295728] igb: Copyright (c) 2007-2014 Intel Corporation.
[ 3.295824] igbvf: Intel(R) Gigabit Virtual Function Network Driver - version 2.4.0-k
[ 3.295827] igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
[ 3.295910] Intel(R) 10GbE PCI Express Linux Network Driver - version 4.6.4
Later I see a Broadcom (bcm54xx) log note, which would probably be the default NIC on the module.
I also see a lot of filesystem errors were corrected, a deletion of 12 orphan nodes. The system was not shut down correctly, and although ext4 was not corrupt, you are now missing part of what was stored on eMMC. The filesystem has a hole in it, and I couldn’t tell you if the hole matters or not.
I see a similar boot note on the Nano that the Intel 10Gb/s adapter is found. I also specifically see the r8168 ethernet driver for the integrated NIC. The Nano also has filesystem errors being recovered, and some nodes were removed from the filesystem (with no way to know if what was cut out is of value or not).
Another question on both units is what do you see from “ifconfig”? I am curious if the Intel NIC maybe shows up there despite some other part of its existence is in doubt.
Thanks linuxdev,
“ifconfig” and “lsmod” show as below.
ISBU:~$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.7.4 netmask 255.255.255.0 broadcast 192.168.7.255
inet6 fe80::592d:28c6:b14:5c99 prefixlen 64 scopeid 0x20<link>
ether 00:04:4b:c5:4f:52 txqueuelen 1000 (Ethernet)
RX packets 4599 bytes 5970791 (5.9 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2807 bytes 222561 (222.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 41
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1 (Local Loopback)
RX packets 214 bytes 15628 (15.6 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 214 bytes 15628 (15.6 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
rndis0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 36:39:56:82:68:59 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
usb0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 36:39:56:82:68:5b txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 00:04:4b:c5:4f:50 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ISBU:~$ lsmod
Module Size Used by
bnep 16562 2
fuse 103841 3
zram 26166 4
overlay 48691 0
bcmdhd 934274 0
cfg80211 589351 1 bcmdhd
nvgpu 1569917 23
bluedroid_pm 13912 0
ip_tables 19441 0
x_tables 28951 1 ip_tables
We use sdk-manager to flash the tx2 kit without changing any official files.
On the dmesg for both Nano and TX2 I see the e1000e driver listed the same way. This guarantees that regardless of whether the e1000 is on USB, PCIe, or any other kind of bus, that the kernel sees the device and the driver is able to load. What shows up in lspci might be a mystery, but we do know the hardware is there and functioning. Since you are not using the RTL chip anymore it may be academic to figure out why lspci isn’t showing what you expect, but it is still a curiosity (it sounds like you worked around the problem, but I am also curious now).
Is that ifconfig from the default ethernet chip? Is the ifconfig any different after replacing the RTL chip (especially the IRQ)?
The IRQ 41 from ifconfig of eth0 tends to be the same IRQ I would expect for the integrated wired ethernet, although I suppose this would be the IRQ you would end up no matter which chipset is providing wired ethernet if you’d replaced the RTL with the e1000e (then you might still end up with IRQ 41, but if you had both, then the two different drivers would have taken two different IRQs). Do both Nano and TX2 show ifconfig exactly the same, and do both units have the RTL chip replaced?
To clarify a bit, lspci is not set up as hot plug on Jetsons (for example, this is a problem for people with a PCIe FPGA which may not respond in time during boot and will go away unless extra steps are taken to do a late enumeration). During boot power is applied to PCIe, and if devices are detected, then PCIe remains active. After boot is complete, if there was no serviceable PCIe device detected during boot, then I believe it powers down the rail/clocks and thus the bridge chip would not show up (why waste power on a PCIe bus which isn’t active?). Not seeing the bridge chip or lspci output for a unit without a PCIe device on the bus (or a device which did not enumerate in time) is normal in such a case.
I can’t say whether or not a correctly detected PCIe device, when failing to load a driver, would leave the bus up or not for lspci to see the device. I suspect the kernel would leave the bus powered, but it isn’t something I can say with confidence (I doubt it is the job of PCIe to care whether some other software further up in the chain makes use of the device or not…PCIe should see something or not without caring about the usefulness of the device). What I mentioned earlier about the ifconfig IRQ is because each driver to hardware will have an IRQ, and the final driver to the hardware on a PCIe device cannot exist if the PCIe itself is not powered up. It would be a contradiction if PCIe powered down and yet the IRQ existed for the driver to the hardware. On the other hand, the IRQ for the integrated ethernet is not necessarily PCIe on all Jetsons (I forget which ones were over USB, which are over PCI, and which are directly integrated to the memory controller).
Someone else would have to comment, but it is possible the chip you replaced is wired directly to the memory controller.