Robin Gareus wrote: > 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> > picking on old subject, why not doing a plain `/etc/init.d/rtirq restart` on resume? byee -- rncbc aka Rui Nuno Capela rncbc@xxxxxxxxx -- 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
