I am trying to use my usb to ethernet dongle (https://www.anker.com/products/A7611011) with my TX1 but when I plug it in, it doesnt get recognized. Following is my dmesg output after plugging in the hardware:
[ 2326.000322] usb 2-2: new SuperSpeed USB device number 3 using tegra-xhci
[ 2326.021666] usb 2-2: New USB device found, idVendor=0bda, idProduct=8153
[ 2326.021674] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[ 2326.021680] usb 2-2: Product: USB 10/100/1000 LAN
[ 2326.021684] usb 2-2: Manufacturer: Realtek
[ 2326.021688] usb 2-2: SerialNumber: 000002
[ 2326.030498] usb 1-3: USB disconnect, device number 2
[ 2326.030572] platform ca.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 2326.030789] platform cb.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 2326.030915] platform cc.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 2326.031029] platform cd.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 2326.031126] reg-fixed-sync-voltage ce.regulator: Consumer c0 does not have device name
[ 2326.031148] platform ce.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 2326.031267] platform d1.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 2326.031386] platform d3.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 2326.031489] reg-fixed-sync-voltage 5.regulator: Consumer c1 does not have device name
[ 2326.031512] platform 5.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 2326.031633] platform 7.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 2326.031748] platform c9.regulator: Driver reg-fixed-sync-voltage requests probe deferral
[ 2326.172816] usb 2-2: reset SuperSpeed USB device number 3 using tegra-xhci
[ 2326.195755] r8152 2-2:1.0 (unregistered net_device): Unknown version 0x5c30
[ 2326.195857] r8152 2-2:1.0 (unregistered net_device): Unknown Device
I think the problem is that r8152 driver is not recognizing it.I am using tegra-ubuntu with kernel 3.10.96+.
Also, when I use the same dongle with my laptop with Ubuntu 16.04 and 4.8.0 it is getting recognized immediately. Following is the dmesg output from my laptop:
[32212.500122] usb 3-4: new high-speed USB device number 4 using xhci_hcd
[32212.641395] usb 3-4: New USB device found, idVendor=0bda, idProduct=8153
[32212.641408] usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[32212.641410] usb 3-4: Product: USB 10/100/1000 LAN
[32212.641412] usb 3-4: Manufacturer: Realtek
[32212.641413] usb 3-4: SerialNumber: 000002
[32213.797325] usbcore: registered new interface driver r8152
[32213.916330] usb 3-4: reset high-speed USB device number 4 using xhci_hcd
[32213.930492] usbcore: registered new interface driver cdc_ether
[32214.121119] r8152 3-4:1.0 eth0: v1.08.6
[32214.963671] r8152 3-4:1.0 enx00e1510084af: renamed from eth0
[32215.259206] IPv6: ADDRCONF(NETDEV_UP): enx00e1510084af: link is not ready
[32215.286934] IPv6: ADDRCONF(NETDEV_UP): enx00e1510084af: link is not ready
Any help in this regard would be highly appreciated.
Thank you.
You’re probably right about a missing driver. It looks like this requires both the CONFIG_USB_USBNET and CONFIG_USB_RTL8152. I see you have a customized kernel (else there would not be a “uname -r” with “+”). While this system runs, what is the output of this (which will tell you if the kernel has those features):
I’m not sure about which CDC driver would be involved, there are NET_CDCETHER and NET_CDC_EEM (perhaps not all apply). Other NET_CDC_ exist as well…some research may be needed.
CONFIG_USB_RTL8152=y
CONFIG_USB_USBNET=y
CONFIG_USB_NET_CDCETHER=y
# CONFIG_USB_NET_CDC_EEM is not set
CONFIG_USB_NET_CDC_NCM=y
# CONFIG_USB_NET_CDC_MBIM is not set
CONFIG_USB_NET_CDC_SUBSET=y
It’s interesting that the desktop showed cdc_ether, and here you have USB_NET_CDCETHER, but there are multiple possible CDC sub-options. On your desktop computer where this works, what is the output of:
lsmod | egrep -i '(cdc|ether)'
…I’m trying to figure out if the PC has loaded one of those sub-options as a module. If the desktop it works on doesn’t give the answer you could just build the modules for USB_NET_CDC_EEM and USB_NET_CDC_MBIM and see if it works (or research further…but it’s likely one of those two).
make -C /lib/modules/3.10.96/build SUBDIRS=/home/ubuntu/Downloads/r8152-2.05.0 modules
make[1]: *** /lib/modules/3.10.96/build: No such file or directory. Stop.
Makefile:13: recipe for target 'modules' failed
make: *** [modules] Error 2
According to your “/proc/config.gz” you have the same cdc_ether and usbnet provided as modules on the PC (except it is integrated in to the kernel on the Jetson, and not a module format). Going back to the ethernet driver itself (the rest other drivers are USB and USB device classes not specific to this chipset), what does your PC say when the device is connected for this:
lsmod | egrep -i '(realtek|815[0-9]|rtl)'
Also, if you look at “lsusb” you’ll see the device has an ID similar to “0955:7721”. You can select just that device with “lsusb -d ‘1234:5678’”, but with the actual ID numbers for your device. You can then list verbosely, e.g., “lsusb -d ‘1234:5678’ -vvv”…what is the output for this? The output is probably the same from both the desktop and the Jetson.
I see this on PC which could be verified on Jetson (if not a module it won’t show up under lsmod, but might in config.gz):
<b>mii</b> 16384 3 <b>r8169</b>,usbnet,r8152
Does “mii” and “r8169” show up from this? The r8169 in addition to r8152 is new, so this might be it if it isn’t enabled in your config:
gunzip < /proc/config.gz | egrep '(MII|8169)'
Unfortunately I don’t see anything to specifically identify a driver in lsusb other than confirming it uses CDC and has a custom driver for other parts of the hardware. It’s that custom driver part which is being elusive.
I noticed some MII PHY drivers which don’t actually have “MII” in their config name, you might want to compare this on host versus Jetson (it is possible none will show up as enabled on either, it’s just an extra detail to look at if r8169 doesn’t do he job, I’d save this for last if other configs listed above show a need for a new kernel config…this could probably be built as a module):
Is it possible that 8152 on Jetson is outdated as the kernel on Jetson is 3.9 but mainstream kernel for linux is 4.11. Also, if that is the case, or a case of missing driver, how can I add it as a module?
Features with “=y” won’t show as a module, they are always there and integrated. It is possible the 8152 is sufficiently different between the 3.x and 4.x kernel versions to cause an issue. However, I’d first look at this kernel config item:
CONFIG_REALTEK_PHY
Does this show up from the Jetson with:
gunzip < /proc/config.gz | egrep 'REALTEK'
If this is not set, I would suggest adding it as a module because mii could require this for the case of the Realtek chipset (in addition to the other items). If this is there, then I’d suspect as you mention, that there are differences between the 3.x kernel drivers and 4.x kernel drivers.
This is the one I’d try to add as a module (I don’t know if this will help, but it is probably the least invasive next step…I don’t know the exact model of that hardware so I wasn’t able to definitively find out what chipset it has…the naming convention in the advertisement didn’t seem to be specific):
CONFIG_REALTEK_PHY
Under something like menuconfig or nconfig (make targets while building the kernel) I’d enable this. It’d be under “drivers/net/phy” (I suggest using menuconfig or nconfig to make sure any chain of dependencies are met if any).
Just be sure to pay particular attention to the CONFIG_LOCALVERSION part to match the “uname -r” on your running kernel…and use its “/proc/config.gz” for the starting config (don’t use tegra21_defconfig). If your “uname -r” is “3.10.96+”, then CONFIG_LOCALVERSION will be “+”. Just to be sure things are set up right I’d compile the full kernel, but you only need to copy that single file (something with a “.ko” suffix) to the right place. I’m guessing it’ll be “/lib/modules/3.10.96+/kernel/drivers/net/phy/something.ko”. If you don’t have a subdirectory you can use mkdir, e.g., you might not already have “phy”. Run “sudo depmod -a”, and either reboot, or run “modprobe something” (where “something” is the prefix name of “something.ko” file). If it doesn’t help it won’t hurt to leave it there or remove it (in which case you’d run “depmod -a” after removing it).