Robin Gareus wrote: of course. it happens all the time the rt-preempt devs make their way it happened before it will happen again. world is turning :)

this issue on 2.6.31-rt has been already reported privately and i'll get to it as soon i get back home from vacation. meanwhile, it really looks like a regex trickery is all that's needed,

keeping in mind that backward compability with pre-2.6.31-rt kernels is in order (eg. i do still run on 2.56.29.5-rt22 for which the current rtirq script is perfect, of course) as a quick suggestion, try this for instance (re. line 120): PIDS=`ps -eo pid,comm | egrep "(IRQ.${IRQ}|irq\/${IRQ}\-.+)\$" | awk '{print $1}'`

> [..] > > Yes I'm also baffled at the high PIDs for IRQs. I hazard a guess that > those are a result of a suspend/resume cycle; and I'll check later if > the chrt settings do persist after a suspend/resume.

Robin Gareus wrote: which is the exact and old behavior of rtirq for kernel-rt < 2.6.31-rt. this time however it looks that you can actually improve things when several device drivers are hanging on a irq line. that is, one can tune up the one and only the one actually intended (eg. "snd" => "irq/17-HDA Inte" and nothing else) not just a simple regex oneliner anymore and i'm afraid it might need a deeper retouch...

Rui Nuno Capela wrote: Almost - it fails because "HDA Inte" has a space in it. So ${NAME2} is only "HDA" instead of "HDA Intel". I've added quotation marks around ${NAME2} to the rtirq_exec_num and rtirq_exec_name function calls (line 167 and line 231) and then it works. However, there's still an issue with RTIRQ_TRAIL. If one wants to raise two drivers on the same IRQ line. For example "HDA Intel" and "ohci1394" but not uhci_hcd:usb3 (all on IRQ 17 here) rtirq will only do the first device and skip the remaining. Thanks for your help, it must be fun to code on the beach ;)

Rui Nuno Capela wrote: Tested on 2.6.29-rt and 2.6.31-rc-rt. It works fine and sets the priorities as expected. Thank you very much for attending to this so quickly! Now we just need to wait for 2.6.31 to be released ;) A minor thing: the status regexp in line 291: egrep '(^[[:blank:]]*PID|IRQ|irq)' also matches the rtirq.sh script itself. Thus I proposed to use egrep '(^[[:blank:]]*PID|IRQ|irq\/|sirq\-|softirq)' Also on the 64studio (with 2.6.29 and mawk) there's no additional info shown for the interrupts (due to the [:blank:]) but I can live with that.

Rui Nuno Capela wrote: yeah, forget about the [:blank:] issue with mawk; but I still consider rtirq itself being listed on `rtirq status` a minor bug ;)

On Fri, Aug 7, 2009 at 9:32 AM, Rui Nuno Capela&lt;rncbc(a)rncbc.org&gt; wrote: not so fast. unless things have *really* changed in h/w (and they may have) when the CPU sees a IRQ 17, it will still have to execute at least every handler until one of them says "yes it was me", and depending on the kernel design right now, possibly all of them. ergo, its not clear you will benefit from raising the priority of one versus the others.

i'd be interested in hearing/reading the arguments for per-driver threads for this - on the face of it it seems rather odd to me.

Hello rt-users and -devs, I have a question about per-device-IRQ-threads in 2.6.31-rc5-rt1.1: After a suspend/resume cycle some IRQ-threads come up with a new PID. The scheduling policy of those threads is reset to default values instead of retaining the previously set values. Is this an issue that is being worked on? Or must userspace from now on re-init rtprio settings after each suspend/resume cycle? As you can see from the information below (from linux-audio-dev @ linuxaudio.org) not all IRQ-threads are re-started, but for example the HDA-Intel is. It may just as well be a specific issue with snd_hda_intel (and sdhci, e1000e, i810/intelfb,..). Robin Gareus wrote: Sorry I was too quick, there. After some more suspend/resumes cycles and a closer look: the previous statement is not correct. RTPRIO is reset when the IRQ handler process restarts under new PID. However not all IRQ threads are re-launched: [from /proc/interrupts] 17: 78393056 873204 IO-APIC-fasteoi uhci_hcd:usb3, HDA Intel, ohci1394 18: 451927 2099364 IO-APIC-fasteoi uhci_hcd:usb4, mmc0 before suspend: PID CLS RTPRIO NI PRI %CPU STAT COMMAND 1418 FF 90 - 130 0.0 S< irq/8-rtc0 1450 FF 89 - 129 0.0 S< irq/18-uhci_hcd 32506 FF 88 - 128 0.1 S< irq/17-HDA Inte 32507 FF 87 - 127 0.0 S< irq/17-ohci1394 1447 FF 50 - 90 0.2 S< irq/17-uhci_hcd 32508 FF 50 - 90 0.0 S< irq/18-mmc0 ... after resume: PID CLS RTPRIO NI PRI %CPU STAT COMMAND 1418 FF 90 - 130 0.0 S< irq/8-rtc0 1450 FF 89 - 129 0.0 S< irq/18-uhci_hcd 388 FF 50 - 90 0.0 S< irq/17-HDA Inte 389 FF 50 - 90 0.0 S< irq/17-ohci1394 390 FF 50 - 90 0.0 S< irq/18-mmc0 1447 FF 50 - 90 0.2 S< irq/17-uhci_hcd ... As you can see all IRQ17 threads get reset completely; on IRQ18 only mmc0 gets a new PID but the usb retains it's PID and rtprio. My first assumption - that it could correlate with the device being in use while suspending - did also proove wrong: I tried suspending with JACKd using an USB audio device on IRQ18 (instead of HDA-Intel on IRQ17) and after resume IRQ18 has still high rtprio, while IRQ17 has been reset whether in use or not. However, after unloading the HDA-Intel module, the other IRQ-threads on IRQ17 (ohci1394 and uhci_hcd:usb3) retain their PID and rtprio. So it seems there's something with the HDA driver and/or hardware that causes the kernel to re-initialize IRQ process. <OT> I usually unload the sd-card mmc0 driver and connect a USB-UA25 on uhci_hcd:usb4; It then is the sole device on IRQ18 and works without x-runs even at 64 spp * 3p / 48000sps = 4ms audio latency with JACKd. With 2.6.29.6-rt23 I get x-runs at these low latencies when not unloading the mmc0 driver. With 2.6.31-rc5-rt1.1 I don't. So the per-driver IRQ priority does work.. YAY. </OT>