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

-----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-----
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Sun Aug 9 20:15:01 2009