-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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: > Rui Nuno Capela wrote: >>> [..] >>> >>> 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. > > It looks like the guess was correct. The PIDs change after > suspend/resume and the chrt settings are retained here. 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> so long, robin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkp+4pEACgkQeVUk8U+VK0KZXACgiJCtcEfH6syPYsyoEVp19VS1 mE8AnRTyEwKD+kMI39+HSfLl4Ms8Zd58 =SEQi -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
