Re: [LAD] remembering rt-sched attributes - was: rtirq script is broken with 2.6.31

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@email-addr-hidden
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev