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?
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.
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.