On 05/03/2012 10:00 AM, Fernando Lopez-Lezcano wrote:
The failure is because there is (as I pointed
out) no fixed greppable
relationship between the textual information found in /proc/asound/cards
and the names of the processes that service the interrupts - I have
looked at the relevant kernel code and the names of the processes are
arbitrary strings.
Some good news! Something has changed from 2.6.33 to 3.2.x...
This finds all irq setup calls on the 3.2 kernel tree:
find sound/ -type f -exec grep -2 request_irq {] \; -print
The fourth argument to that call is what is going to be shown in the ps
listing. Now, I found that all _pci_ cards in 3.2.x have KBUILD_MODNAME
as the fourth argument (that was not the case before!). So anything
starting with "snd_" is going to be a soundcard, so rtirq could have
another special case for that.
Rui: this addition/hack in rtirq takes care of snd_hda_intel in my
3.2.16-rt27 system and will presumably do the right thing for any other
pci soundcards:
----
# Special for kernel-rt >= 2.6.31, where one can
# prioritize shared IRQs by device driver (NAME2)...
# first try with irq names that start with snd_
PIDS=`ps -eo pid,comm | egrep -i "IRQ.${IRQ}.snd_.*" | awk '{print
$1}'`
if [ -n "${PIDS}" ]
then
RTIRQ_TRAIL=":${IRQ}${RTIRQ_TRAIL}"
else
# try with the name reported in /proc/asound/cards
PIDS=`ps -eo pid,comm | egrep -i "IRQ.${IRQ}.${NAME2:0:8}" | awk '{print
$1}'`
if [ -n "${PIDS}" ]
then
RTIRQ_TRAIL=":${IRQ}${RTIRQ_TRAIL}"
else
# Backward compability for older kernel-rt < 2.6.31...
PIDS=`ps -eo pid,comm | egrep -i "IRQ.${IRQ}" | awk '{print $1}'`
if [ -n "${PIDS}" ]
then
RTIRQ_TRAIL=":${IRQ}${RTIRQ_TRAIL}"
fi
fi
fi
----
given that, which got slightly re-hacked somehow, a new rtirq release
has bumped in: