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
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
mowzr@mowzr:~$ ls /lib/modules
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.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.