1 May
2012
1 May
'12
12:10 p.m.
Looks good to me, except for the two ohci_hcd and the
nvidia threads.
I
don't see those when you start rtirq but they are
there when you
query
rtirq's status. Weird. Same issue after a reboot?
And this hdspm
device,
is that an extension card (PCI, PCIe)? If so you might
want to try
another slot because having it to share the same IRQ as your GPU
isn't
ideal. And maybe you could post or pastebin your
complete
/etc/default/rtirq file.
Best,
Jeremy
Jeremy, the bad is, that I don't have another PCIe x1 slot :(.
In my experience, restarting the script tries to raise
the priorities
of the threads in RTIRQ_NAME_LIST, but the ones which are already
raised aren't lowered even if you leave them out of the list.
Try rebooting the computer.
Cheers, Pablo
*reboot*
The reboot doesn't improve anything :(.
I'll build my own kernel within the next days.
Is there anything missing to work with boot option threadirqs?
Usually I use self build kernel-rt and the nv driver. Since the nv
driver is dropped, I'm using the proprietary and I have given up to edit
the nvidia drivers header or to fake the license, since both never
worked on my machine.
spinymouse@precise:~$ cat /boot/config-* | grep PREEMPT
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_PREEMPT_NOTIFIERS=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
# CONFIG_PREEMPT_TRACER is not set
spinymouse@precise:~$ cat /boot/config-* | grep
CONFIG_IRQ_FORCED_THREADING
CONFIG_IRQ_FORCED_THREADING=y
spinymouse@precise:~$ uname -a
Linux precise 3.2.0-23-lowlatency #31-Ubuntu SMP PREEMPT Wed Apr 11
02:24:03 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
There's another issue, I've got 4GB RAM, but only 3.8GB are accessible,
resp. shown. 256MB are missing. I've got this for another install too,
while a PAE 32-bit kernel has no issue with the 4GB. No framebuffer, the
graphics has got it's own RAM.
CONFIG_PREEMPT_COUNT ???
Thanks and regards,
Ralf
1 May
1 May
12:17 p.m.
New subject: Issue with the priority of the sound cards using rtirq
On Tue, 2012-05-01 at 12:09 +0200, Ralf Mardorf wrote:
And maybe you could post or pastebin your complete
/etc/default/rtirq
file.
It was the same as for another install, where everything is ok. I run
diff. The other install has got a self-build kernel-rt and the same
kernel without rt, but threadirqs [2] now they are not equal anymore).
spinymouse@precise:~$ cat /etc/default/rtirq
#
# Copyright (c) 2004-2011 rncbc aka Rui Nuno Capela.
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
along
# with this program; if not, write to the Free Software Foundation,
Inc.,
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
#
# /etc/sysconfig/rtirq
# /etc/default/rtirq
#
# Configuration for IRQ thread tunning,
# for realtime-preempt enabled kernels.
#
# This program is free software; you can redistribute it and/or modify
it
# under the terms of the GNU General Public License version 2 or later.
#
# IRQ thread service names
# (space separated list, from higher to lower priority).
#RTIRQ_NAME_LIST="rtc snd usb i8042"
RTIRQ_NAME_LIST="rtc hdsp ice1 usb i8042"
# Highest priority.
RTIRQ_PRIO_HIGH=90
# Priority decrease step.
RTIRQ_PRIO_DECR=5
# Whether to reset all IRQ threads to SCHED_OTHER.
RTIRQ_RESET_ALL=0
# On kernel configurations that support it,
# which services should be NOT threaded
# (space separated list).
RTIRQ_NON_THREADED="rtc snd"
# Process names which will be forced to the
# highest realtime priority range (99-91)
# (space separated list, from highest to lower priority).
# RTIRQ_HIGH_LIST="timer"
spinymouse@precise:~$
[2]
spinymouse@precise:~$ cat /media/avlinux/etc/default/rtirq
#
# Copyright (c) 2004-2011 rncbc aka Rui Nuno Capela.
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
along
# with this program; if not, write to the Free Software Foundation,
Inc.,
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
#
# /etc/sysconfig/rtirq
# /etc/default/rtirq
#
# Configuration for IRQ thread tunning,
# for realtime-preempt enabled kernels.
#
# This program is free software; you can redistribute it and/or modify
it
# under the terms of the GNU General Public License version 2 or later.
#
# IRQ thread service names
# (space separated list, from higher to lower priority).
RTIRQ_NAME_LIST="rtc hdspm snd usb i8042"
# Highest priority.
RTIRQ_PRIO_HIGH=90
# Priority decrease step.
RTIRQ_PRIO_DECR=5
# Whether to reset all IRQ threads to SCHED_OTHER.
RTIRQ_RESET_ALL=0
# On kernel configurations that support it,
# which services should be NOT threaded
# (space separated list).
RTIRQ_NON_THREADED="rtc snd"
# Process names which will be forced to the
# highest realtime priority range (99-91)
# (space separated list, from highest to lower priority).
# RTIRQ_HIGH_LIST="timer"
spinymouse@precise:~$
1:17 p.m.
New subject: Issue with the priority of the sound cards using rtirq
On 05/01/12 12:09, Ralf Mardorf wrote:
So the output of /etc/init.d/rtirq status is the same as in the other
mail? That's really weird. The only thing I can think of is that
something else (another script?) is prioritizing stuff too (like the
nvidia and ohci_hcd processes). The steps between the priorities
strengthens my suspicion, it should be 5 but some processes do not get a
prio that can be divided by 5 (like nvidia which has prio 82). No one on
the Ubuntu Studio list encountered the same issue? Maybe Ubuntu (or
Ubuntu Studio) prioritizes processes somewhere else.
Best,
Jeremy
Jeremy, the bad is, that I don't have another PCIe
x1 slot:(.
Ah bummer :(
> In my
experience, restarting the script tries to raise the priorities
> of the threads in RTIRQ_NAME_LIST, but the ones which are already
> raised aren't lowered even if you leave them out of the list.
>
> Try rebooting the computer.
>
> Cheers, Pablo
*reboot*
The reboot doesn't improve anything:(. 
8:32 p.m.
New subject: Issue with the priority of the sound cards using rtirq
On 05/01/2012 04:17 AM, Jeremy Jongepier wrote:
On 05/01/12 12:09, Ralf Mardorf wrote:
So the output of /etc/init.d/rtirq status is the same as in the other
mail? That's really weird. The only thing I can think of is that
something else (another script?) is prioritizing stuff too (like the
nvidia and ohci_hcd processes).
(I don't seem to find the start of the thread in my mailbox)
ohci_hcd is there is you specify usb in the list of priorities rtirq
needs to raise. And nvidia is there probably because it shares an
interrupt with a real soundcard. Rtirq does not raise the priority of
only the soundcard, but everything that uses the interrupt that the
soundcard uses.
AFAIK it is not possible (or simple) to raise _just_ the soundcard as it
is impossible to know which irq process corresponds to a soundcard (and
which one does not). That is because the labeling of the irq process
names in the ps listing is arbitrary. At least that is what I remember
seeing last I looked at this issue. You can of course manually lower the
priorities of non-soundcard irq processes with chrt.
-- Fernando
Jeremy, the bad is, that I don't have another
PCIe x1 slot:(.
Ah bummer :(
> In
my experience, restarting the script tries to raise the priorities
> of the threads in RTIRQ_NAME_LIST, but the ones which are already
> raised aren't lowered even if you leave them out of the list.
>
> Try rebooting the computer.
>
> Cheers, Pablo
*reboot*
The reboot doesn't improve anything:(. The steps between the priorities
strengthens my suspicion, it should be 5 but some processes do not get a
prio that can be divided by 5 (like nvidia which has prio 82). No one on
the Ubuntu Studio list encountered the same issue? Maybe Ubuntu (or
Ubuntu Studio) prioritizes processes somewhere else.
2 May
2 May
9:19 a.m.
New subject: Issue with the priority of the sound cards using rtirq
On 05/01/12 20:32, Fernando Lopez-Lezcano wrote:
(I don't seem to find the start of the thread in
my mailbox)
ohci_hcd is there is you specify usb in the list of priorities rtirq
needs to raise. And nvidia is there probably because it shares an
interrupt with a real soundcard. Rtirq does not raise the priority of
only the soundcard, but everything that uses the interrupt that the
soundcard uses.
Afaik this is not true. The threadirqs kernel option (or a real-time
kernel) creates bottom halves (or tasklets, or softirqs) of each device
that has or shares an IRQ. So in Ralf's case four devices share IRQ 18,
two USB hubs, a soundcard and a graphics card. Each of those devices
gets its own specific softirq which then can get prioritized with rtirq
accordingly. Default rtprio is 50 afaik, so nvidia should get rtprio 50
and not 82.
AFAIK it is not possible (or simple) to raise _just_
the soundcard as it
is impossible to know which irq process corresponds to a soundcard (and
which one does not). That is because the labeling of the irq process
names in the ps listing is arbitrary.
It is not arbitrary, the softirqs get specific names derived from the
loaded kernel module for that device iirc. So the graphics card gets a
label 18-nvidia, the soundcard 18-snd_hdsp and both usb hubs
18-ohci_usb. And it is those labels that rtirq uses to set the rtprio
for the different softirqs.
At least that is what I remember
seeing last I looked at this issue. You can of course
manually lower the
priorities of non-soundcard irq processes with chrt.
-- Fernando
More info:
http://wiki.linuxmusicians.com/doku.php?id=system_configuration#priorities
If that Wiki page contains errors, please let me know so I can correct
those.
Best,
Jeremy
3 May
3 May
8:26 a.m.
New subject: Issue with the priority of the sound cards using rtirq
On 05/02/2012 12:19 AM, Jeremy Jongepier wrote:
For soundcard drivers there is no convention for naming the irq process
that services its interrupt. The name of the irq process does not match
the name of the kernel module (which would be an obvious choice). The
ascii that is printed by ps is defined in the kernel code for each
driver, and driver authors pick different names that are not consistent.
That means you can't pattern match for the right irq process if the
interrupt number is shared by several devices.
It would be possible to pattern match if, for example, all soundcards
used a "snd_" prefix for the name of the irq process, but that is not
the case (at least until last time I looked at the kernel code for this
very same reason).
On 05/01/12 20:32, Fernando Lopez-Lezcano wrote:
That's how we all would like things to work, regretfully that is not how
things actually work.
(I don't seem to find the start of the thread
in my mailbox)
ohci_hcd is there is you specify usb in the list of priorities rtirq
needs to raise. And nvidia is there probably because it shares an
interrupt with a real soundcard. Rtirq does not raise the priority of
only the soundcard, but everything that uses the interrupt that the
soundcard uses.
Afaik this is not true. The threadirqs kernel option (or a real-time
kernel) creates bottom halves (or tasklets, or softirqs) of each device
that has or shares an IRQ. So in Ralf's case four devices share IRQ 18,
two USB hubs, a soundcard and a graphics card. Each of those devices
gets its own specific softirq which then can get prioritized with rtirq
accordingly. Default rtprio is 50 afaik, so nvidia should get rtprio 50
and not 82. AFAIK it is
not possible (or simple) to raise _just_ the soundcard as it
is impossible to know which irq process corresponds to a soundcard (and
which one does not). That is because the labeling of the irq process
names in the ps listing is arbitrary.
It is not arbitrary, the softirqs get specific names derived from the
loaded kernel module for that device iirc. So the graphics card gets a
label 18-nvidia, the soundcard 18-snd_hdsp and both usb hubs
18-ohci_usb. And it is those labels that rtirq uses to set the rtprio
for the different softirqs.
The rtirq code does the following (simplified):
- rtirq gets the irq number from /proc/asound/cards
- that number is used to search the output of ps looking for matches
with that particular irq number
- there is no way to tell which irq process corresponds to a soundcard,
rtirq does not try AFAICT
- so, all irq processes that match the number get the elevated priority
For example, in my laptop, from /proc/interrupts:
16: 2551 516 113 95 IO-APIC-fasteoi
nouveau, snd_hda_intel, mmc0
rtirq happily gives them 75, 74 and 73:
222 FF 75 - 115 0.0 S irq/16-nouveau
11077 FF 74 - 114 0.0 S irq/16-snd_hda_
11082 FF 73 - 113 0.0 S irq/16-mmc0
Please let me know if there is a way to, given an irq number, know what
is the pid of the irq process that services that irq number for a
particular _soundcard_, I have found no way of doing that so far[*].
Note that in all other cases other than soundcards rtirq looks for the
name, not the number of the irq (for example for usb the names are well
known and unique and hardwired into rtirq).
-- Fernando
[*] other than scanning the kernel source code for the names of all
possible soundcard driver irq processes, making a list and matching
against that - it would work but it would depend on those names not
changing, and of having the list that matches the kernel you are running.
8:42 a.m.
New subject: Issue with the priority of the sound cards using rtirq
Hi Fernando,
"spinymouse at avlinux:~$ /etc/init.d/rtirq status
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
452 FF 90 - 130 0.0 S irq/8-rtc0
1028 FF 85 - 125 0.0 S irq/18-hdspm
1040 FF 80 - 120 0.0 S irq/20-ICE1712
1042 FF 80 - 120 0.0 S irq/21-ICE1712
615 FF 75 - 115 0.0 S irq/19-ehci_hcd
620 FF 75 - 115 0.2 S irq/16-ohci_hcd
622 FF 74 - 114 0.0 S irq/17-ohci_hcd
626 FF 73 - 113 0.0 S irq/17-ohci_hcd
445 FF 70 - 110 0.0 S irq/1-i8042
96 FF 50 - 90 0.0 S irq/9-acpi
621 FF 50 - 90 0.1 S irq/22-firewire
625 FF 50 - 90 0.0 S irq/18-ohci_hcd
627 FF 50 - 90 0.0 S irq/18-ohci_hcd
628 FF 50 - 90 0.0 S irq/14-pata_ati
629 FF 50 - 90 0.0 S irq/15-pata_ati
634 FF 50 - 90 0.3 S irq/22-ahci
909 FF 50 - 90 0.0 S irq/7-parport0
1414 FF 50 - 90 0.0 S irq/43-eth0
3 TS - 0 19 0.0 S ksoftirqd/0
9 TS - 0 19 0.0 S ksoftirqd/1" -
http://lists.linuxaudio.org/pipermail/linux-audio-user/2012-April/084689.ht…
As you can see, on that other Linux install IRQ 18 is shared too, but
the prio is as wanted.
Regards,
Ralf
9:08 a.m.
New subject: Issue with the priority of the sound cards using rtirq
On Wed, 2012-05-02 at 23:25 -0700, Fernando Lopez-Lezcano wrote:
222 FF 75 - 115 0.0 S irq/16-nouveau
Nouveau?
You've got no performance issues using Nouveau? Wow!
I used nv, but since nv is dropped, I use the proprietary driver. When
I've got time, I'll test the vesa driver or unmount the Nvidia graphics
and test the FLOSS ATI driver with the integrated Radeon AND I'll
compile a kernel myself for US Precise too.
Nouveau is a PITA on my machine.
2:04 p.m.
New subject: Issue with the priority of the sound cards using rtirq
On Thursday, May 03, 2012 07:50:27 AM Ralf Mardorf did opine:
On Wed, 2012-05-02 at 23:25 -0700, Fernando
Lopez-Lezcano wrote:
The last time I tried Nouveau, it worked just fine for me, but must have
had a wild pointer someplace, my uptimes were a max of a day & a half.
Using nvidia-current, dkms installed, I have 19 days now. But this card
has been cooked by a failed & too small fan once, so its days are probably
numbered. I have gkrellm watching the GPU temp now, shows in the middle
60's C. I have a cpu cooler that will fit it if there is height room for
it that I'll see if I can mount on it the next time I pull the card because
the temps are getting too close to the bus disconnect messages in the log.
Otherwise, nvidia is selling an economy model with a huge passive heat
sink, no fan. That IMO is how it _should_ be. I don't need a 10,000 fps
card burning 400 watts to play klondike.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene>
"Is this foreplay?"
"No, this is Nuke Strike. Foreplay has lousy graphics. Beat me again."
-- Duckert, in "Bad Rubber," Albedo #0 (comics)
222 FF 75 - 115 0.0 S irq/16-nouveau
Nouveau?
You've got no performance issues using Nouveau? Wow!
I used nv, but since nv is dropped, I use the proprietary driver. When
I've got time, I'll test the vesa driver or unmount the Nvidia graphics
and test the FLOSS ATI driver with the integrated Radeon AND I'll
compile a kernel myself for US Precise too.
Nouveau is a PITA on my machine.
4 May
4 May
2:10 a.m.
New subject: Issue with the priority of the sound cards using rtirq
On Thu, 2012-05-03 at 08:04 -0400, gene heskett wrote:
The last time I tried Nouveau, it worked just fine for
me
Yes, many people report that the driver is ok. OTOH also many people
report that it absolutely doesn't work.
Nice to hear from you "young man".
- Ralf
3 May
3 May
9:51 a.m.
New subject: Issue with the priority of the sound cards using rtirq
On 05/03/2012 07:25 AM, Fernando Lopez-Lezcano wrote:
On 05/02/2012 12:19 AM, Jeremy Jongepier wrote:
For soundcard drivers there is no convention for naming the irq process
that services its interrupt. The name of the irq process does not match
the name of the kernel module (which would be an obvious choice). The
ascii that is printed by ps is defined in the kernel code for each
driver, and driver authors pick different names that are not consistent.
That means you can't pattern match for the right irq process if the
interrupt number is shared by several devices.
It would be possible to pattern match if, for example, all soundcards
used a "snd_" prefix for the name of the irq process, but that is not
the case (at least until last time I looked at the kernel code for this
very same reason).
you seem to be using an old rtirq version--the latest maybe found here:
http://www.rncbc.org/jack/#rtirq
i believe the newer rtirq already addresses the above: the only irq line
that shall get prioritized will be the one of hda-intel soundcard
(irq/16-snd_hda), as long you DON'T include "nouveau" nor "mmc" on
the
RTIRQ_NAME_LIST, while "snd" stays there put.
On 05/01/12 20:32, Fernando Lopez-Lezcano wrote:
That's how we all would like things to work, regretfully that is not how
things actually work.
(I don't seem to find the start of the thread
in my mailbox)
ohci_hcd is there is you specify usb in the list of priorities rtirq
needs to raise. And nvidia is there probably because it shares an
interrupt with a real soundcard. Rtirq does not raise the priority of
only the soundcard, but everything that uses the interrupt that the
soundcard uses.
Afaik this is not true. The threadirqs kernel option (or a real-time
kernel) creates bottom halves (or tasklets, or softirqs) of each device
that has or shares an IRQ. So in Ralf's case four devices share IRQ 18,
two USB hubs, a soundcard and a graphics card. Each of those devices
gets its own specific softirq which then can get prioritized with rtirq
accordingly. Default rtprio is 50 afaik, so nvidia should get rtprio 50
and not 82. AFAIK it
is not possible (or simple) to raise _just_ the soundcard as it
is impossible to know which irq process corresponds to a soundcard (and
which one does not). That is because the labeling of the irq process
names in the ps listing is arbitrary.
It is not arbitrary, the softirqs get specific names derived from the
loaded kernel module for that device iirc. So the graphics card gets a
label 18-nvidia, the soundcard 18-snd_hdsp and both usb hubs
18-ohci_usb. And it is those labels that rtirq uses to set the rtprio
for the different softirqs.
The rtirq code does the following (simplified):
- rtirq gets the irq number from /proc/asound/cards
- that number is used to search the output of ps looking for matches
with that particular irq number
- there is no way to tell which irq process corresponds to a soundcard,
rtirq does not try AFAICT
- so, all irq processes that match the number get the elevated priority
For example, in my laptop, from /proc/interrupts:
16: 2551 516 113 95 IO-APIC-fasteoi nouveau, snd_hda_intel, mmc0
rtirq happily gives them 75, 74 and 73:
222 FF 75 - 115 0.0 S irq/16-nouveau
11077 FF 74 - 114 0.0 S irq/16-snd_hda_
11082 FF 73 - 113 0.0 S irq/16-mmc0
Please let me know if there is a way to, given an irq number, know what
is the pid of the irq process that services that irq number for a
particular _soundcard_, I have found no way of doing that so far[*].
Note that in all other cases other than soundcards
rtirq looks for the
name, not the number of the irq (for example for usb the names are well
known and unique and hardwired into rtirq).
it looks for name particle _and_ number, last time i've checked :)
[*] other than scanning the kernel source code for the names of all
possible soundcard driver irq processes, making a list and matching
against that - it would work but it would depend on those names not
changing, and of having the list that matches the kernel you are running.
that might be the case. add to that that the ps command name is
truncated to 15chars which confuses the matching of some soundcard
module names or labels, often down to 4 or 5 chars eg. "hda_" instead of
full "hda_intel", or worst, "ice1" for both "ice1712" and
"ice1724"...
byee
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
7 p.m.
New subject: Issue with the priority of the sound cards using rtirq
On 05/03/2012 12:51 AM, Rui Nuno Capela wrote:
Ah, yes, right! But see below for why this fails.
When searching for "snd" it finds this:
# grep irq /proc/asound/cards | sed 's/\(.*\) at .* irq \(.*\)/\2 \1/'
44 HDA Intel
16 HDA NVidia
From that information it eventually then calls (output of bash -x):
+ rtirq_exec_num start snd HDA-Intel 75 16
+ ACTION=start
+ NAME1=snd
+ NAME2=HDA-Intel
+ PRI2=75
+ IRQ=16
++ echo :rtc:
++ sed 's/ /:/g'
++ grep :snd:
+ '[' -n '' ']'
++ echo :8:
++ grep :16:
+ '[' -z '' ']'
++ ps -eo pid,comm
++ egrep -i IRQ.16.HDA-Inte
++ awk '{print $1}'
This is where it fails, it tries to match irq number and name and fails.
Why? Because there is no fixed relationship between what is in
/proc/asound/cards and the names of the irq processes themselves. In
this particular case ps gives (with beautiful truncation added):
12665 irq/16-snd_hda_
which has nothing to do with (not case sensitive):
"hda-inte"
which is what rtirq searches for (and this is the best it can do with
the information it has). Then it falls back to "2.6.31 compatibility"
mode which only searches for irq number and then all three irq processes
are elevated in priority.
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. It may work in some cases if the names match, but it
does not in the generic case. It certainly does not work for
snd_hda_intel in my machine. I believe others are seeing the same problem.
I'd love to find a way to reliably map from the information you get from
/proc/asound/cards to the pid of the right irq process...
-- Fernando
On 05/03/2012 07:25 AM, Fernando Lopez-Lezcano wrote:
I'm using:
rtirq-20111007-1.fc14.ccrma.i686
seems to be the latest.
On 05/02/2012 12:19 AM, Jeremy Jongepier wrote:
For soundcard drivers there is no convention for naming the irq process
that services its interrupt. The name of the irq process does not match
the name of the kernel module (which would be an obvious choice). The
ascii that is printed by ps is defined in the kernel code for each
driver, and driver authors pick different names that are not consistent.
That means you can't pattern match for the right irq process if the
interrupt number is shared by several devices.
It would be possible to pattern match if, for example, all soundcards
used a "snd_" prefix for the name of the irq process, but that is not
the case (at least until last time I looked at the kernel code for this
very same reason).
you seem to be using an old rtirq version--the latest maybe found here:
http://www.rncbc.org/jack/#rtirq On 05/01/12 20:32, Fernando Lopez-Lezcano wrote:
That's how we all would like things to work, regretfully that is not how
things actually work.
(I don't seem to find the start of the thread
in my mailbox)
ohci_hcd is there is you specify usb in the list of priorities rtirq
needs to raise. And nvidia is there probably because it shares an
interrupt with a real soundcard. Rtirq does not raise the priority of
only the soundcard, but everything that uses the interrupt that the
soundcard uses.
Afaik this is not true. The threadirqs kernel option (or a real-time
kernel) creates bottom halves (or tasklets, or softirqs) of each device
that has or shares an IRQ. So in Ralf's case four devices share IRQ 18,
two USB hubs, a soundcard and a graphics card. Each of those devices
gets its own specific softirq which then can get prioritized with rtirq
accordingly. Default rtprio is 50 afaik, so nvidia should get rtprio 50
and not 82. AFAIK it
is not possible (or simple) to raise _just_ the soundcard
as it
is impossible to know which irq process corresponds to a soundcard (and
which one does not). That is because the labeling of the irq process
names in the ps listing is arbitrary.
It is not arbitrary, the softirqs get specific names derived from the
loaded kernel module for that device iirc. So the graphics card gets a
label 18-nvidia, the soundcard 18-snd_hdsp and both usb hubs
18-ohci_usb. And it is those labels that rtirq uses to set the rtprio
for the different softirqs.
The rtirq code does the following (simplified):
- rtirq gets the irq number from /proc/asound/cards
- that number is used to search the output of ps looking for matches
with that particular irq number
- there is no way to tell which irq process corresponds to a soundcard,
rtirq does not try AFAICT
- so, all irq processes that match the number get the elevated priority
For example, in my laptop, from /proc/interrupts:
16: 2551 516 113 95 IO-APIC-fasteoi nouveau, snd_hda_intel, mmc0
rtirq happily gives them 75, 74 and 73:
222 FF 75 - 115 0.0 S irq/16-nouveau
11077 FF 74 - 114 0.0 S irq/16-snd_hda_
11082 FF 73 - 113 0.0 S irq/16-mmc0
Please let me know if there is a way to, given an irq number, know what
is the pid of the irq process that services that irq number for a
particular _soundcard_, I have found no way of doing that so far[*]. i believe the newer rtirq already addresses the above:
the only irq line
that shall get prioritized will be the one of hda-intel soundcard
(irq/16-snd_hda), as long you DON'T include "nouveau" nor "mmc"
on the
RTIRQ_NAME_LIST, while "snd" stays there put.
----
# IRQ thread service names
# (space separated list, from higher to lower priority).
RTIRQ_NAME_LIST="rtc snd usb i8042"
----
Note that in
all other cases other than soundcards rtirq looks for the
name, not the number of the irq (for example for usb the names are well
known and unique and hardwired into rtirq).
it looks for name particle _and_ number, last time i've checked :)
7:19 p.m.
New subject: Issue with the priority of the sound cards using rtirq
Could it be an issue regarding to the proprietary Nvidia driver, since
all installs on my machine using the dropped nv driver are ok, just the
install using the proprietary nvidia driver is bad regarding to the
priority?! Btw. I posted a link to a post to the Ubuntu mailing list,
regarding to an ATI driver, that had an odd high prio.
Do 3D drivers cause an issue?
What distro and release do you use Fernando?
- Ralf
7:21 p.m.
New subject: Issue with the priority of the sound cards using rtirq
On 05/03/2012 06:00 PM, Fernando Lopez-Lezcano wrote:
On 05/03/2012 12:51 AM, Rui Nuno Capela wrote:
Ah, yes, right! But see below for why this fails.
When searching for "snd" it finds this:
# grep irq /proc/asound/cards | sed 's/\(.*\) at .* irq \(.*\)/\2 \1/'
44 HDA Intel
16 HDA NVidia
oops! hda_nvidia ? hda? (what crap is that?) is that a webcam, usb
headset or sth?
:-)
you are completely right. we've both stated the shortcomings of rtirq in
face of all these discrepancies between kernel and user level
nomenclature space
besides that, the OP shall certify whether the rtirq-20111007 is being
exercised fwiw.
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On 05/03/2012 07:25 AM, Fernando Lopez-Lezcano
wrote:
I'm using:
rtirq-20111007-1.fc14.ccrma.i686
seems to be the latest.
On 05/02/2012 12:19 AM, Jeremy Jongepier wrote:
you seem to be using an old rtirq version--the latest maybe found here:
http://www.rncbc.org/jack/#rtirq On 05/01/12 20:32, Fernando Lopez-Lezcano wrote:
> (I don't seem to find the start of the thread in my mailbox)
>
> ohci_hcd is there is you specify usb in the list of priorities rtirq
> needs to raise. And nvidia is there probably because it shares an
> interrupt with a real soundcard. Rtirq does not raise the priority of
> only the soundcard, but everything that uses the interrupt that the
> soundcard uses.
Afaik this is not true. The threadirqs kernel option (or a real-time
kernel) creates bottom halves (or tasklets, or softirqs) of each device
that has or shares an IRQ. So in Ralf's case four devices share IRQ 18,
two USB hubs, a soundcard and a graphics card. Each of those devices
gets its own specific softirq which then can get prioritized with rtirq
accordingly. Default rtprio is 50 afaik, so nvidia should get rtprio 50
and not 82.
That's how we all would like things to work, regretfully that is not how
things actually work.
> AFAIK it is not possible (or simple) to raise
_just_ the soundcard
> as it
> is impossible to know which irq process corresponds to a soundcard
> (and
> which one does not). That is because the labeling of the irq process
> names in the ps listing is arbitrary.
It is not arbitrary, the softirqs get specific names derived from the
loaded kernel module for that device iirc.
For soundcard drivers there is no convention for naming the irq process
that services its interrupt. The name of the irq process does not match
the name of the kernel module (which would be an obvious choice). The
ascii that is printed by ps is defined in the kernel code for each
driver, and driver authors pick different names that are not consistent.
That means you can't pattern match for the right irq process if the
interrupt number is shared by several devices.
It would be possible to pattern match if, for example, all soundcards
used a "snd_" prefix for the name of the irq process, but that is not
the case (at least until last time I looked at the kernel code for this
very same reason).
So the graphics card gets a
label 18-nvidia, the soundcard 18-snd_hdsp and both usb hubs
18-ohci_usb. And it is those labels that rtirq uses to set the rtprio
for the different softirqs.
The rtirq code does the following (simplified):
- rtirq gets the irq number from /proc/asound/cards
- that number is used to search the output of ps looking for matches
with that particular irq number
- there is no way to tell which irq process corresponds to a soundcard,
rtirq does not try AFAICT
- so, all irq processes that match the number get the elevated priority
For example, in my laptop, from /proc/interrupts:
16: 2551 516 113 95 IO-APIC-fasteoi nouveau, snd_hda_intel, mmc0
rtirq happily gives them 75, 74 and 73:
222 FF 75 - 115 0.0 S irq/16-nouveau
11077 FF 74 - 114 0.0 S irq/16-snd_hda_
11082 FF 73 - 113 0.0 S irq/16-mmc0
Please let me know if there is a way to, given an irq number, know what
is the pid of the irq process that services that irq number for a
particular _soundcard_, I have found no way of doing that so far[*]. i believe the newer rtirq already addresses the
above: the only irq line
that shall get prioritized will be the one of hda-intel soundcard
(irq/16-snd_hda), as long you DON'T include "nouveau" nor "mmc"
on the
RTIRQ_NAME_LIST, while "snd" stays there put.
----
# IRQ thread service names
# (space separated list, from higher to lower priority).
RTIRQ_NAME_LIST="rtc snd usb i8042"
----
Note that
in all other cases other than soundcards rtirq looks for the
name, not the number of the irq (for example for usb the names are well
known and unique and hardwired into rtirq).
it looks for name particle _and_ number, last time i've checked :)
10:23 p.m.
New subject: Issue with the priority of the sound cards using rtirq
On 05/03/2012 10:21 AM, Rui Nuno Capela wrote:
On 05/03/2012 06:00 PM, Fernando Lopez-Lezcano wrote:
That's the hdmi audio interface (the laptop has an hdmi interface).
# grep irq /proc/asound/cards | sed 's/\(.*\)
at .* irq \(.*\)/\2 \1/'
44 HDA Intel
16 HDA NVidia
oops! hda_nvidia ? hda? (what crap is that?) is that a webcam, usb
headset or sth? you are completely right. we've both stated the
shortcomings of rtirq in
face of all these discrepancies between kernel and user level
nomenclature space
yeah, it is a shame, but it is not a shortcoming of rtirq but of the api
available in /proc|/sys, rtirq can do nothing about it. I don't see any
workarounds (other than a list of existing strings for doing the match).
-- Fernando
7:25 p.m.
New subject: Issue with the priority of the sound cards using rtirq
OTOH Fernando, I guess you could be right, since the "naming" of the
"drivers" for rtirq on my Ubuntu Precise install is very vague, while
the naming on the installs that do work, is absolutely matching.
4 May
4 May
1:39 a.m.
New subject: Issue with the priority of the sound cards using rtirq
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
----
far from a solution, this is a list of sound/ subdirectories in 3.2
where this does not hold true:
sound/ppc/
sound/mips/
sound/oss/
sound/arm
sound/sparc/
sound/spi
sound/soc
sound/parisc
sound/pcmcia/
sound/isa/
sound/drivers/
sound/atmel/
sound/aoa/
but it will work for a LOT of frequently used soundcards, at least when
running 3.2 ...
-- Fernando
1:46 a.m.
New subject: Issue with the priority of the sound cards using rtirq
On Thu, 2012-05-03 at 16:39 -0700, Fernando Lopez-Lezcano wrote:
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:
:)
Thank you fore sharing this.
2:42 p.m.
New subject: new rtirq release (was: Re: Issue with the priority of the sound cards using rtirq)
On 05/04/2012 12:39 AM, Fernando Lopez-Lezcano wrote:
On 05/03/2012 10:00 AM, Fernando Lopez-Lezcano wrote:
given that, which got slightly re-hacked somehow, a new rtirq release
has bumped in:
http://www.rncbc.org/jack#rtirq
packages:
http://www.rncbc.org/jack/rtirq-20120504.tar.gz
http://www.rncbc.org/jack/rtirq-20120504-28.src.rpm
http://www.rncbc.org/jack/rtirq-20120504-28.noarch.rpm
svn trunk:
https://www.rncbc.org/svn/rtirq/trunk
cheers && thanks
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
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
----
3:19 p.m.
New subject: new rtirq release (was: Re: Issue with the priority of the sound cards using rtirq)
PS: Thank you to Jeremy too :). Sorry that I forget you.
5:35 p.m.
New subject: new rtirq release
On 05/04/2012 02:39 PM, Rui Nuno Capela wrote:
This is what I love about the linux audio community
On 05/04/2012 12:39 AM, Fernando Lopez-Lezcano wrote:
> 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
>
----
given that, which got slightly re-hacked somehow, a new rtirq release
has bumped in:
http://www.rncbc.org/jack#rtirq
packages:
http://www.rncbc.org/jack/rtirq-20120504.tar.gz
http://www.rncbc.org/jack/rtirq-20120504-28.src.rpm
http://www.rncbc.org/jack/rtirq-20120504-28.noarch.rpm
svn trunk:
https://www.rncbc.org/svn/rtirq/trunk
cheers && thanks
6:26 p.m.
New subject: new rtirq release
On Fri, 2012-05-04 at 17:35 +0200, Brendan Jones wrote:
This is what I love about the linux audio community
:)
This is why I use Linux only :).
Btw. another mail is delayed, didn't came through the list.
Communication between us might need some improvement ;).
On Fri, 2012-05-04 at 16:09 +0200, Ralf Mardorf wrote:
It seems to be that an issue already was known and fixed since 12 Mar
2012
"Comment by: epicurious on Mon, 12 Mar 2012 04:51:32 +0000
It took me a few moments to notice that the script as-is wasn't
actually working for my system, because of the way IRQs are displayed
by
ps ("irq/{irqnumber}-{name}") and the way
they are expected to look in
the etc/rc.d/rtirq script ("IRQ.{irqnumber}.{name}").
I've created a PKGBUILD that fixes that, and doesn't wipe your
previous settings on a possible upgrade. I'll be happy to maintain
this
package."
- http://aur.archlinux.org/packages.php?ID=25441
I don't use current kernel-rt on Arch so I didn't notice that.
9:08 p.m.
New subject: new rtirq release
On 05/04/2012 05:39 AM, Rui Nuno Capela wrote:
On 05/04/2012 12:39 AM, Fernando Lopez-Lezcano wrote:
[MUNCH]
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:
given that, which got slightly re-hacked somehow, a new rtirq release
has bumped in:
http://www.rncbc.org/jack#rtirq
Hmm, sorry Rui but that does not seem to work, you can't rely on the
name as provided in /proc/asound/cards, it will not match in the generic
case, so this:
----
PIDS=`ps -eo pid,comm | egrep -i "irq.${IRQ}.snd.${NAME2:0:4}" | awk
'{print $1}'`
----
should be something like:
----
PIDS=`ps -eo pid,comm | egrep -i "irq.${IRQ}.snd_.*" | awk '{print
$1}'`
----
that should be enough, it would be very unlikely (impossible?) that
there is another soundcard on the same interrupt so a match with snd_
should be enough, and even if that were the case it would be processed
twice I guess, no harm done.
-- Fernando
11:56 p.m.
New subject: new rtirq release
On 05/04/2012 08:08 PM, Fernando Lopez-Lezcano wrote:
On 05/04/2012 05:39 AM, Rui Nuno Capela wrote:
what exactly happens in your particular case?
maybe "snd.${NAME2:0:4}" comes as a 1st best try (where NAME2 stands for
the name provided from /proc/qasound/cards), then "snd.*" for the
fallback (2nd try) ?
check(this)out
https://www.rncbc.org/svn/rtirq/trunk
posing for an immediate 20120505-29 stamp :)
seeya
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On 05/04/2012 12:39 AM, Fernando Lopez-Lezcano
wrote:
[MUNCH]
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:
given that, which got slightly re-hacked somehow, a new rtirq release
has bumped in:
http://www.rncbc.org/jack#rtirq
Hmm, sorry Rui but that does not seem to work, you can't rely on the
name as provided in /proc/asound/cards, it will not match in the generic
case, so this:
----
PIDS=`ps -eo pid,comm | egrep -i "irq.${IRQ}.snd.${NAME2:0:4}" | awk
'{print $1}'`
----
should be something like:
----
PIDS=`ps -eo pid,comm | egrep -i "irq.${IRQ}.snd_.*" | awk '{print
$1}'`
----
that should be enough, it would be very unlikely (impossible?) that
there is another soundcard on the same interrupt so a match with snd_
should be enough, and even if that were the case it would be processed
twice I guess, no harm done.
5 May
5 May
1:13 a.m.
New subject: new rtirq release
On 05/04/2012 02:57 PM, Rui Nuno Capela wrote:
On 05/04/2012 08:08 PM, Fernando Lopez-Lezcano wrote:
Nothing happens (ie: all processes with that particular irq number get
the high priority). I did not _really_ investigate, it just did not work
and I reverted to what I had tried before.
On 05/04/2012 05:39 AM, Rui Nuno Capela wrote:
what exactly happens in your particular case? On 05/04/2012 12:39 AM, Fernando Lopez-Lezcano
wrote:
[MUNCH]
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:
given that, which got slightly re-hacked somehow, a new rtirq release
has bumped in:
http://www.rncbc.org/jack#rtirq
Hmm, sorry Rui but that does not seem to work, you can't rely on the
name as provided in /proc/asound/cards, it will not match in the generic
case, so this:
----
PIDS=`ps -eo pid,comm | egrep -i "irq.${IRQ}.snd.${NAME2:0:4}" | awk
'{print $1}'`
----
should be something like:
----
PIDS=`ps -eo pid,comm | egrep -i "irq.${IRQ}.snd_.*" | awk '{print
$1}'`
----
that should be enough, it would be very unlikely (impossible?) that
there is another soundcard on the same interrupt so a match with snd_
should be enough, and even if that were the case it would be processed
twice I guess, no harm done. maybe "snd.${NAME2:0:4}" comes as a 1st best
try (where NAME2 stands for
the name provided from /proc/asound/cards), then "snd.*" for the
fallback (2nd try) ?
Sure, that would work...
check(this)out
https://www.rncbc.org/svn/rtirq/trunk
posing for an immediate 20120505-29 stamp :)
Hmm, I don't see a difference in that url, maybe you did not copy things
over?
-- Fernando
1:42 a.m.
New subject: new rtirq release
On 05/05/2012 12:13 AM, Fernando Lopez-Lezcano wrote:
On 05/04/2012 02:57 PM, Rui Nuno Capela wrote:
ouch, sorry, forgot to push it
check it out now (should read svn rev.5)
byee
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On 05/04/2012 08:08 PM, Fernando Lopez-Lezcano
wrote:
Nothing happens (ie: all processes with that particular irq number get
the high priority). I did not _really_ investigate, it just did not work
and I reverted to what I had tried before.
On 05/04/2012 05:39 AM, Rui Nuno Capela wrote:
what exactly happens in your particular case? On 05/04/2012 12:39 AM, Fernando Lopez-Lezcano
wrote:
> 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:
[MUNCH]
given that, which got slightly re-hacked somehow, a new rtirq release
has bumped in:
http://www.rncbc.org/jack#rtirq
Hmm, sorry Rui but that does not seem to work, you can't rely on the
name as provided in /proc/asound/cards, it will not match in the generic
case, so this:
----
PIDS=`ps -eo pid,comm | egrep -i "irq.${IRQ}.snd.${NAME2:0:4}" | awk
'{print $1}'`
----
should be something like:
----
PIDS=`ps -eo pid,comm | egrep -i "irq.${IRQ}.snd_.*" | awk '{print
$1}'`
----
that should be enough, it would be very unlikely (impossible?) that
there is another soundcard on the same interrupt so a match with snd_
should be enough, and even if that were the case it would be processed
twice I guess, no harm done. maybe "snd.${NAME2:0:4}" comes as a 1st
best try (where NAME2 stands for
the name provided from /proc/asound/cards), then "snd.*" for the
fallback (2nd try) ?
Sure, that would work...
check(this)out
https://www.rncbc.org/svn/rtirq/trunk
posing for an immediate 20120505-29 stamp :)
Hmm, I don't see a difference in that url, maybe you did not copy things
over? 
4:42 a.m.
New subject: rtirq question
Ok, here goes a stupid question. So, I got Ubuntu 12.04 lowlatency
kernel running and I installed rtirq package that comes with Ubuntu.
However, when I do sudo /etc/init.d/rtirq status, I only get the following:
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
3 TS - 0 19 0.0 S ksoftirqd/0
12221 TS - 0 19 0.0 S ksoftirqd/1
Does this mean that lowlatency kernel is not capable of providing the
needed functionality or something entirely different?
The /etc/default/rtprio config is vanilla:
(including only the relevant parts)
# IRQ thread service names
# (space separated list, from higher to lower priority).
RTIRQ_NAME_LIST="rtc snd usb i8042"
# Highest priority.
RTIRQ_PRIO_HIGH=90
# Priority decrease step.
RTIRQ_PRIO_DECR=5
# Whether to reset all IRQ threads to SCHED_OTHER.
RTIRQ_RESET_ALL=0
# On kernel configurations that support it,
# which services should be NOT threaded
# (space separated list).
RTIRQ_NON_THREADED="rtc snd"
# Process names which will be forced to the
# highest realtime priority range (99-91)
# (space separated list, from highest to lower priority).
# RTIRQ_HIGH_LIST="timer"
Any thoughts?
Best wishes,
Ico
5:02 a.m.
New subject: rtirq question
Never mind, just me being stupid. Apparently, latest set of updates
reverted default kernel to generic and I never noticed nor bothered
doing a simple uname -a...
All is well...
3 May
3 May
10:37 a.m.
New subject: Issue with the priority of the sound cards using rtirq
On 05/03/12 08:25, Fernando Lopez-Lezcano wrote:
Afaics rtirq only does this if a pattern in RTIRQ_NAME_LIST matches
'snd'. In all other cases (like you point out later too) everything
passes through the rtirq_exec_name function first which greps on
/proc/interrupts.
Best,
Jeremy
For soundcard drivers there is no convention for naming the irq process
that services its interrupt. The name of the irq process does not match
the name of the kernel module (which would be an obvious choice). The
ascii that is printed by ps is defined in the kernel code for each
driver, and driver authors pick different names that are not consistent.
That means you can't pattern match for the right irq process if the
interrupt number is shared by several devices.
It would be possible to pattern match if, for example, all soundcards
used a "snd_" prefix for the name of the irq process, but that is not
the case (at least until last time I looked at the kernel code for this
very same reason).
I wasn't aware of that, thanks.
So the
graphics card gets a
label 18-nvidia, the soundcard 18-snd_hdsp and both usb hubs
18-ohci_usb. And it is those labels that rtirq uses to set the rtprio
for the different softirqs.
The rtirq code does the following (simplified):
- rtirq gets the irq number from /proc/asound/cards
4522
days inactive
4526
days old
linux-audio-user@lists.linuxaudio.org
29 comments
7 participants
participants (7)
-
Brendan Jones -
Fernando Lopez-Lezcano -
gene heskett -
Ivica Ico Bukvic -
Jeremy Jongepier -
Ralf Mardorf -
Rui Nuno Capela