Re: [LAU] rtirq, kernels >= 3.2 and udev

On 05/09/2012 02:03 AM, Fernando Lopez-Lezcano wrote:
> Hi all (and Rui),
>
> As noted in another thread I found out that the naming of the irq
> processes of pci soundcards has changed with kernels >= 3.2 to be
> uniform and predictable. That made it possible to change rtirq so that
> (at least for pci cards) only the irq process that corresponds to the
> soundcard gets an elevated priority - this was not completely reliable
> before.
>
> Another nice (very nice I'd say) side effect of this change is that now
> udev can be trivially used to change the priorities of soundcards
> dynamically. I tested this while running 3.2.16-rt27 on a Fedora 14
> system. I removed "snd" and "usb" of the rtirq sysconfig file so that it
> would not touch those and rebooted. My hda_intel got the priority I
> wanted, inserting (or removing) a usb or a pci-express card with a
> Multiface II worked as well. Right now my simple script does not try to
> order priorities, it just sets them to a fixed one. But well, it is a
> start... Code attached (the udev rule goes into /etc/udev/rules.d/ in my
> system)...
>
> This simple script also returns the priority of the usb irq for the
> soundcard to 50 (the default) when the card is unplugged, but it does
> not check for multiple cards (ie: even if another soundcard is still
> using the same irq process it downgrades its priority), this should be
> fixed.
>

> Feedback appreciated.
> -- Fernando
>
> PS: Another rtirq script in /etc/pm/sleep.d/ could save the current
> priorities before a suspend and restore them after a resume - that does
> not happen currently.

what about just `rtirq restart` on the sleep.d script (on thaw|resume) ?

warning. there's no state salvage being done on bad old rtirq script. in
fact `rtirq stop` is a plain nop by default, unless RTIRQ_RESET_ALL=1 is
set (cf. /etc/rtirq.conf aka. /etc/sysconfig/rtirq) which makes all
target irq service threads to reset to rtprio=50 but also to "normal"
scheduling class(SCHED_OTHER). might not on par with the times :)

note that `rtirq restart` is actually the same function as `rtirq stop`
immediately followed by `rtirq start`. however, as s the very same irq
service threads are at stake, this whole remark might not be an issue
after all:)

byee

-- 
rncbc aka Rui Nuno Capela
rncbc@email-addr-hidden
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user