Issue with usb device mode

Autonomous Machines Jetson & Embedded Systems Jetson Orin NX
1

When I have a usb connection from the debug usb to my PC port and I run:
sudo systemctl enable nv-l4t-usb-device-mode.service
sudo reboot
I get the l4tbr0 interface created and the file share active.
But occasionally this service does not start when I boot and it will not work if I unplug and plug in the usb port while running.

I suspect the service does not always start and it may not detect device plug in or outs?

Any ideas how to make this work?

Thanks,
Mark Satterfield

3

You can use systemctl status to check tthat service status.

4

I have 2 problems:

  1. After enabling the service it stops starting 50% of the time after reboots,
  2. If I unplug or plug in the usb cable the interface is not stopped or started.
5

Adding dmesg and the systemctl status output
dnesg and_status.txt (63.9 KB)

6

Hi,

What is the exact problem you want to ask here?

The service status you shared in yoru log is a successful case. If you want us to check, then you should at least share the NG case…

7

The problem is I did not end up with an interface on 192.168.55.1 and the shared files

8

So is there any problem in understanding this comment? or you want something else to elaborate?

The service status you shared in yoru log is a successful case. If you want us to check, then you should at least share the NG case…

9

What is the host PC? Is it Linux or Windows? If this is unreliable, then there are a lot of possible reasons. Perhaps:

  • The host PC can itself be rejecting the virtual network device. Windows is more likely to reject than is Linux.
  • In the case of micro-B USB cables (but not USB-C) about two out of three cable brands just have such terrible signal quality that they don’t work, or work unreliably (it is typical for many “charger” cables to literally have at most two strands of very thin copper, e.g., 32 gauge).
  • Perhaps hot plug detect did not detect this. In the case of a micro-OTG USB connector there is a pin for detecting device cable (type-B) versus host cable end (type-A).

If this is unreliable, then perhaps run “dmesg --follow” on both the host and the Jetson. Then, if it fails, show what the log shows on both host PC and Jetson as a result of the plug-in.

11

I noticed the the following log when the interface is created.
16.601804] tegra-xudc 3550000.xudc: EP 5 (type: intr, dir: in) enabled
[ 16.601825] tegra-xudc 3550000.xudc: EP 3 (type: bulk, dir: in) enabled
[ 16.601838] tegra-xudc 3550000.xudc: EP 2 (type: bulk, dir: out) enabled
[ 16.601908] tegra-xudc 3550000.xudc: EP 9 (type: intr, dir: in) enabled
[ 16.601922] tegra-xudc 3550000.xudc: EP 7 (type: bulk, dir: in) enabled
[ 16.601933] tegra-xudc 3550000.xudc: EP 4 (type: bulk, dir: out) enabled
[ 16.602028] tegra-xudc 3550000.xudc: EP 15 (type: intr, dir: in) enabled
[ 16.602050] tegra-xudc 3550000.xudc: EP 11 (type: bulk, dir: in) enabled
[ 16.602094] tegra-xudc 3550000.xudc: EP 6 (type: bulk, dir: out) enabled
[ 16.602097] IPv6: ADDRCONF(NETDEV_CHANGE): rndis0: link becomes ready
[ 16.602253] l4tbr0: port 1(rndis0) entered blocking state
[ 16.602259] l4tbr0: port 1(rndis0) entered forwarding state
[ 16.602341] IPv6: ADDRCONF(NETDEV_CHANGE): l4tbr0: link becomes ready
[ 16.637002] tegra-xudc 3550000.xudc: EP 13 (type: bulk, dir: in) enabled
[ 16.637023] tegra-xudc 3550000.xudc: EP 8 (type: bulk, dir: out) enabled
[ 16.637140] IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
[ 16.637243] l4tbr0: port 2(usb0) entered blocking state
[ 16.637248] l4tbr0: port 2(usb0) entered forwarding state
[ 16.639798] tegra-xudc 3550000.xudc: ep 13 disabled
[ 16.639904] tegra-xudc 3550000.xudc: ep 8 disabled
[ 16.666042] tegra-xudc 3550000.xudc: EP 13 (type: bulk, dir: in) enabled
[ 16.666059] tegra-xudc 3550000.xudc: EP 8 (type: bulk, dir: out) enabled

when it does not work:
[ 12.046003] rndis0: HOST MAC 1a:da:05:a7:b3:ec
[ 12.046009] rndis0: MAC 1a:da:05:a7:b3:ed
[ 12.046476] usb0: HOST MAC 1a:da:05:a7:b3:ee
[ 12.046481] usb0: MAC 1a:da:05:a7:b3:ef
[ 12.047721] tegra-xudc 3550000.xudc: EP 0 (type: ctrl, dir: out) enabled
[ 12.051269] l4tbr0: port 1(rndis0) entered blocking state
[ 12.051298] l4tbr0: port 1(rndis0) entered disabled state
[ 12.051439] device rndis0 entered promiscuous mode
[ 12.057501] l4tbr0: port 2(usb0) entered blocking state
[ 12.057528] l4tbr0: port 2(usb0) entered disabled state
[ 12.057644] device usb0 entered promiscuous mode
[ 12.478879] Generic FE-GE Realtek PHY r8169-8-100:00: attached PHY driver [Generic FE-GE Realtek PHY] (mii_bus:phy_addr=r8169-8-100:00, irq=IGNORE)
[ 12.727063] r8169 0008:01:00.0 eth0: Link is Down

It looks to me that when the link is down the interface does not get created but when the link is up the interface is created. Need to understand why the FE-GE Realtek Phy is not detecting link up. Is the just dependant on the hardware signalling?

Here is the created interface:
l4tbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.55.1 netmask 255.255.255.0 broadcast 192.168.55.255
inet6 fe80::18da:5ff:fea7:b3ed prefixlen 64 scopeid 0x20
inet6 fe80::1 prefixlen 128 scopeid 0x20
ether 1a:da:05:a7:b3:ed txqueuelen 1000 (Ethernet)
RX packets 180 bytes 32417 (32.4 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 174 bytes 30614 (30.6 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

12

Doing a comparison between when an interface gets created and it does not get created is a second attempt after the initial link down on the FE-GE Realtek PHY. Not sure what causes the second attempt after the link is up.

13

This isn’t in any particular order, but here are some notes:

  • About:
    tegra-xudc 3550000.xudc: EP 5 (type: intr, dir: in) enabled
    …This is not an error. The xudc controller at address 0x3550000, as described in the device tree, is enabled via the compatible driver tegra-xudc. It is using interrupt mode, and is end point 5.
  • Similar log lines appear for each mode, e.g., bulk is used on storage devices, sometimes on cameras, and interrupt mode is used on human interface devices, e.g., keyboards and mice. A number of devices are enabled. You might get a sense of what this is via the “lsusb -t” tree view.
  • If a given input disconnects and reconnects, then it might be a problem. As an example, a bad signal might cause a connection to disconnect and automatically reconnect. However, none of those tegra-xudc log lines are errors.
  • Later there are tegra-xudc log lines of end points being disabled. Maybe this was from autosuspend? Don’t know. It can also be because of an error which cannot be fixed by reconnecting. However, there is usually a log message when errors occur. I’m tempted to believe the above are not errors.
  • Messages about rndis0 and a MAC address are not errors. I suppose the different messages are a clue as to what is going on, but I can’t conclude anything from that because they are not actual errors. Devices going into a disabled state are of course not functional, but it doesn’t say why they went into that state. You kind of need a full serial console boot log up to and including both a working and non-working state. Serial console includes logging prior to Linux loading, and this can include information about things like device tree setup. Still, it isn’t a guaranteed answer.
  • The log which shows existence of the virtual networking via l4tbr0 verifies function of the virtual device. It doesn’t say the rest of the pipe is working. However, there are no errors or strange statistic within the ifconfig output. Note that this received 180 bytes and sent 174 bytes. This would be the DHCP request and reply. I doubt this would be possible if the USB pipe itself were not functioning correctly. So this ifconfig is from a working case. Statistics from a failing case might help, as you can conclude different things based on if there is RX or TX traffic, and if there is, whether any of the statistics on errors show issues. The virtual software is working, the question is what is going to the virtual software when it fails, and if there is a response from the virtual network software. We don’t know from the success case of ifconfig.
1 Like
14

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.