Real-time process stalls after USB device insertion

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Real-time process stalls after USB device insertion

493 Views
johnadamson
Contributor III

Yocto Linux, gatesgarth.  We have a thread that must meet a deadline.  We start the thread with SCHED_FIFO and set the thread priority to 54.  (the policy and number was determined through experimentation) This has worked well on the i.MX8MQ in previous kernels.  We then ported the code to the i.MX8MP and gatesgarth, kernel 5.10.9.  And for the most part, it still works.  

But new to the mix is a USB port with USB type A 2.0 connector.  We've used the USB port previously, but the device was hardwired, no connector.  

When I insert a USB memory stick, the thread misses its deadline, every time.  I removed any systemd automounts or other reactions to the stick insertion, only what is built into the kernel remains, AFAICT, but no change.  

What follows is what is emitted to dmesg on insertion.   Any clues as to what could be going wrong, or what I might do to lower the impact of the USB driver?

John

 

[ 173.488190] usb 1-1.4: New USB device found, idVendor=058f, idProduct=6387, bcdDevice= 1.02
[ 173.496583] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 173.504058] usb 1-1.4: Product: Flash Disk
[ 173.508349] usb 1-1.4: SerialNumber: 68174233
[ 173.516238] usb-storage 1-1.4:1.0: USB Mass Storage device detected
[ 173.522909] scsi host0: usb-storage 1-1.4:1.0
[ 174.589628] scsi 0:0:0:0: Direct-Access Flash Disk 8.07 PQ: 0 ANSI: 2
[ 174.599359] sd 0:0:0:0: [sda] 120832 512-byte logical blocks: (61.9 MB/59.0 MiB)
[ 174.607241] sd 0:0:0:0: [sda] Write Protect is off
[ 174.612086] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
[ 174.612466] sd 0:0:0:0: [sda] No Caching mode page found
[ 174.617800] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 174.633985] sda: sda1
[ 174.638844] sd 0:0:0:0: [sda] Attached SCSI removable disk

 

 

0 Kudos
3 Replies

376 Views
johnadamson
Contributor III

For what it's worth, 5.15.71 has the same issue.   (and so does the imx8mq running 5.4.24)

More about the methodology...assuming the device has audio ins and outs, configure JACK to use both, with frames=512 (for relatively low latency). 

/usr/bin/jackd -s -d alsa -p 512 -r 48000 -C hw:your_input -P hw:your_output -i your_channels -o your_channels

Connect in to out.

jack_connect system:capture_1 system:playback_1

Supply a signal to 'in' (sine waves, in my case), listen to the output.  Insert a USB stick.  Listen to the pops and clicks that result, coinciding with the 'scsi' and 'sd' messages sent to the console.  

So again, is there any way to reduce the impact of the USB system during enumeration and device recognition, or maybe even just keep it from emitting messages to the console?  

John

0 Kudos

467 Views
johnadamson
Contributor III

This would be a helpful response if it was prefaced by any information indicating that it might actually fix something.  Do you have any knowledge of bugs in the 5.10.9 USB code that have been fixed in 5.15?  There's a vendor's BSP between my layer and the Freescale layer, and changing kernel versions is a non-trivial exercise.  Seems like 5.10.9 was the recommended kernel for the i.MX8MP/gatesgarth at some point.  

0 Kudos

476 Views
Bio_TICFSL
NXP TechSupport
NXP TechSupport

Hello,

Sorry but 5.10.9 is not supported by nxp, you should change to 5.15.71 bsp based.

Regards

 

0 Kudos