Cannot assign priority to single IRQ

[olm52]

I have an USB CARD connected to USB 3.0 port.

All is working fine if I configure rtirq with RTIRQ_NAME_LIST="xhci" It is not working If I am using for example: RTIRQ_NAME_LIST="126-xhci_hcd" (I have used 126-xhci_hcd because is the value displayed in rtirq status)

The problem here is that recent motherboards have a lot of IRQs assigned to xhci. Since in my case here are 25 (!) I would like to assign high priority only to the irq associated to my sound card. (to find it also was not so easy...)

[rncbc]

you may try investigating with cat /proc/interrupts and cat /proc/asound/cards which on is actually the USB sound card you're after... but if nothing distinct appears on the last column to /proc/interrupts (but just xhci_hcd) then I'm afraid you're out of luck with rtirq use...

[olm52]

The relevant line in /proc/interrupts is 126: 0 0 30151 0 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI 6297600-edge xhci_hcd

And note that I can set the priority manually for iRQ 126 with this code:

`echo "Please enter the IRQ of your audio card"

read -p "?" your_irq

your_pid=$(ps -eo rtprio,pid,cmd --sort -rtprio | | grep -v grep | grep -E "RTPRIO|$RTIRQ_NAME_LIST" | grep $your_irq | awk '{print $2}' )

chrt -f -a -p "$RTIRQ_PRIO_HIGH" $your_pid`

So is possible. See the result: RTPRIO PID CMD **95 431 [irq/126-xhci_hcd]** 50 414 [irq/108-xhci_hcd] 50 415 [irq/109-xhci_hcd] 50 416 [irq/110-xhci_hcd] 50 417 [irq/111-xhci_hcd] 50 418 [irq/112-xhci_hcd] 50 419 [irq/113-xhci_hcd] 50 420 [irq/114-xhci_hcd] 50 421 [irq/115-xhci_hcd] 50 422 [irq/116-xhci_hcd] 50 423 [irq/117-xhci_hcd] 50 424 [irq/118-xhci_hcd] 50 425 [irq/119-xhci_hcd] 50 426 [irq/120-xhci_hcd] 50 427 [irq/121-xhci_hcd] 50 428 [irq/122-xhci_hcd] 50 429 [irq/123-xhci_hcd] 50 430 [irq/124-xhci_hcd] 50 432 [irq/127-xhci_hcd] 50 433 [irq/128-xhci_hcd] 50 434 [irq/129-xhci_hcd] 50 435 [irq/130-xhci_hcd] 50 436 [irq/131-xhci_hcd] 50 437 [irq/132-xhci_hcd] 50 438 [irq/133-xhci_hcd]

[rncbc]

and TF difference is what?

it seems that is nowadays pointless to isolate an usb3.0 end-point in your case it's about a single usb device -- it get all or none, that's the deal or...? some time ago, in usb2 and earlier, one could differentiate on host ports (eg. usb1, usb2, etc.) but given your case (and probably recent kernels there is) you have what you have, all tropes on one single hole.

as it stands now, given the situation on usb 2+ (ie xhci_hcd being a true sucker) current rtirq won't help you any much, and given what you exposed, nor your custom chrt scripts either

as another question: is that actually an USB 3.0 full-fledged sound card? which one? why not plug it on an USB 2.0 as for what's (probably) the h/w vendor really supports? if not, then, live with facts (or wait for the kernel guys/gals make it discernible alright;))

cheers

ps. otoh. is this a real problem or are you just nitpicking? how many devices have you there plugged-in actual usb3+ ports when hard-working with your sound device? just asking :)