USB doesn't show as serial with PREEMPT-RT

Using a Jetson Nano on a custom carrier board. I have some timing-critical inputs for monitoring quadrature-encoded digital hall sensors so I enabled PREEMPT-RT.

However, I’ve noticed once enabling full realtime preemption my USB devices no longer show in /dev/ttyUSB. I’m using a USB 4G modem that’s critical for my application.

The Jetson still appears to recognize the modem, it just doesn’t show up as /dev/ttyUSB. When I plug it in I see the following in /var/log/syslog:

Jul 19 23:19:31 mowzr kernel: [ 1321.350142] usb 1-2.3: new high-speed USB device number 5 using tegra-xusb
Jul 19 23:19:31 mowzr kernel: [ 1321.387918] usb 1-2.3: New USB device found, idVendor=05c6, idProduct=90b2
Jul 19 23:19:31 mowzr kernel: [ 1321.387980] usb 1-2.3: New USB device strings: Mfr=3, Product=2, SerialNumber=4
Jul 19 23:19:31 mowzr kernel: [ 1321.388027] usb 1-2.3: Product: Qualcomm CDMA Technologies MSM
Jul 19 23:19:31 mowzr kernel: [ 1321.388070] usb 1-2.3: Manufacturer: Qualcomm, Incorporated
Jul 19 23:19:31 mowzr kernel: [ 1321.388112] usb 1-2.3: SerialNumber: 1a1bacb8

Anyone know how to get USB devices to work with PREEMPT-RT?

Are you sure your modem was working fine when you don’t enable PREEMPT-RT? Also, what is your method to enable prempt-rt?

Yes, I was using it regularly.

I enabled by running the script:
sudo kernel/kernel-4.9/scripts/rt-patch.sh apply-patches

Then checked full realtime preemption in the menuconfig

Then rebuild the full kernel:and copied modules to
sudo -E make -j8 ARCH=arm64

Copied Image to /boot/Image

Exported modules
sudo -E make ARCH=arm64 modules_install
Copied the /lib directory output over the /lib on the device

Device boots ok, I can confirm PREEMPT-RT is enabled, and other drivers like the quadrature signal monitors seem to be working. Only USB appears to be affected.

Can you share the full dmesg before and after applying the patch?

Because of the above, I am wondering what you see from “uname -r”, and what do you see from “ls /lib/modules/”? Just thinking that if the kernel needs a module (e.g., for USB), and the “uname -r” changed, then copying “/lib” will only add modules to the new module path, and old modules will be unreachable. If and only if your configuration was a perfect match (plus additions of features) to the old kernel would copy of “/lib” be sufficient for modules.

@linuxdev Thanks for the response, here’s the output you asked for:

mowzr@mowzr:~$ uname -r
4.9.201-rt134-tegra
mowzr@mowzr:~$ ls /lib/modules
4.9.201-rt134-tegra  4.9.201-tegra

You are correct that the path changed, the rt134 path is new.

I’m not really sure what that tells me, am I correct to assume the new kernel uses the -rt134 version only?

I did a diff of the contents of the /kernel/driver/usb between each of those two folders under /lib/modules and they appear to have the same list of files (but file contents are different).

What linuxdev tries to say is the “uname -r” will affect where the module gets loaded.

For example, if uname -r gives you “4.9.201”, then modprobe will go to /lib/modules/4.9.201 to search the module. And it would fail because there is no such folder exists.

Thus, make sure 4.9.201-rt134-tegra folder really contains the same driver you need.

Thanks, I think it does, as I noted both directories appear to have the /kernel/driver/usb with the same files inside but I don’t know exactly what I’m looking for USB to work. I’m pulling the dmesg now with PREEMPT-RT disabled/enabled, will post in a few minutes

THANKS!!! I just figured it out - your suggestion got me thinking to double-check the /lib directory on the device. I recopied the directory and it works like a charm now.

When I copied the /lib directory to the device last time it must’ve been an incomplete or corrupt copy.

1 Like