19 Nov
2005
19 Nov
'05
7:19 p.m.
Hello pd and lau lists,
I am having trouble figuring out how to actually change the irq's of specific
devices.
I read the ardour thread pointed to by http://puredata.info/community/pdwiki/Optimize
and the linux hardware stability guide
(http://www-128.ibm.com/developerworks/library/l-hw2.html),
and I now know how to find the current IRQ's used on my machine, and I also know what
they SHOULD be, but I still do not know how to actually change them.
My BIOS only allows me to disable my touchpad, parellel port (disabled) and IR port
(disabled).
My goals with this project are to have a faster audio machine, and hopefully to not have
to
disable acpi in order to run linux. I am not sure of the motherboard in this laptop, and
the
laptop distributor will not return my emails. (If someone can help me to figure that out
I
would be grateful! The host bridge is an SiS 755 - is that the motherboard or just the
IDE
controller?)
From the ardour thread (the Mark Knecht part)
Here"s the order of interrupt priority on a non-APIC machine:
0, 1, 8, 9, 10, 11, 12, 13, 14, 15, 3, 4, 5, 6, 7
0 is the highest priority
7 is the lowest priority
my irq's:
cat /proc/interrupts
CPU0
0: 15819314 XT-PIC timer
1: 15630 XT-PIC i8042
2: 0 XT-PIC cascade
3: 0 XT-PIC ohci_hcd:usb3
4: 0 XT-PIC ohci_hcd:usb2
5: 3769675 XT-PIC ehci_hcd:usb1, yenta, yenta, hdsp, ohci1394, eth0
8: 1 XT-PIC rtc
10: 13339 XT-PIC SiS SI7012, SiS SI7013 Modem
12: 9093 XT-PIC i8042
14: 39815 XT-PIC ide0
15: 141222 XT-PIC ide1
NMI: 0
ERR: 1
What I would like to have:
cat /proc/interrupts
CPU0
0: 15819314 XT-PIC timer
1: 15630 XT-PIC i8042
2: 0 XT-PIC cascade
3: 0 XT-PIC ohci_hcd:usb3
4: 0 XT-PIC ohci_hcd:usb2
5: 3769675 XT-PIC ehci_hcd:usb1
7: ??? XT-PIC eth0
8: 1 XT-PIC rtc
9: ??? XT-PIC ohci1394
10: ??? XT-PIC yenta, yenta, hdsp (I think this is both the cardbus and
the multiface?)
11: 13339 XT-PIC SiS SI7012
12: 9093 XT-PIC i8042
13: ??? XT-PIC SiS SI7013 Modem
14: 39815 XT-PIC ide0
15: 141222 XT-PIC ide1
NMI: 0
ERR: 1
The acpi problem is that the system hangs (with acpi on) when fedora tried to activate
eth0.
Thank you for your help? I would open my laptop but I doubt that there is much I can do in
there. Probably not
a whole lot of shuffling I can do in a laptop.
-thewade
19 Nov
19 Nov
8:24 p.m.
my irq's:
cat /proc/interrupts
CPU0
0: 15819314 XT-PIC timer
1: 15630 XT-PIC i8042
2: 0 XT-PIC cascade
3: 0 XT-PIC ohci_hcd:usb3
4: 0 XT-PIC ohci_hcd:usb2
5: 3769675 XT-PIC ehci_hcd:usb1, yenta, yenta, hdsp,
ohci1394, eth0 8: 1 XT-PIC rtc
10: 13339 XT-PIC SiS SI7012, SiS SI7013 Modem
12: 9093 XT-PIC i8042
14: 39815 XT-PIC ide0
15: 141222 XT-PIC ide1
NMI: 0
ERR: 1
interesting. I'm also interested in decreasing latencies for my USB
cards, and my interrupts read as follows:
0: 1620247 XT-PIC timer
1: 4669 XT-PIC i8042
2: 0 XT-PIC cascade
8: 2 XT-PIC rtc
11: 1636542 XT-PIC Intel 82801CA-ICH3, Intel 82801CA-ICH3
Modem, uhci_hcd:usb1, uhci_hcd:usb2,eth0, yenta, yenta, ohci1394,
nvidia
12: 114 XT-PIC i8042
14: 52911 XT-PIC ide0
NMI: 0
LOC: 0
ERR: 0
MIS: 0
11 really seems to be overcrowded, so I wonder if I could use another
IRQ for the USB bus. Unfortunately it's a notebook, so changing card
slots isn't possible.
Best regards
ce
8:33 p.m.
On Sun, 2005-11-20 at 01:25 +0100, Christoph Eckert wrote:
11: 1636542 XT-PIC Intel 82801CA-ICH3,
Intel 82801CA-ICH3
Modem, uhci_hcd:usb1, uhci_hcd:usb2,eth0, yenta, yenta, ohci1394,
nvidia
You have your USB audio device on the same interrupt as the binary only
nvidia driver?!?
You won't get a lot of help from the open source community if you insist
on loading proprietary kernel modules. The FIRST thing you should do if
you're trying to optimize your system is don't load any binary only
kernel modules!!!
Lee
9:14 p.m.
On Sat, Nov 19, 2005 at 07:33:21PM -0500, Lee Revell wrote:
On Sun, 2005-11-20 at 01:25 +0100, Christoph Eckert
wrote:
regardless of the license-nazi issues of his kernel modules, all those things on IRQ 11
looks questionable. i run the nvidia binary driver but it gets its own IRQ, same as the
ATI fglrx...these are both on amd64 motherboards... on my ~2001 ASUS athlon32 mobo, with
win32, everything _would_ end up on a single IRQ, unless disabling ACPI, in which case
they would be nicely distributed. no idea what this all means, but someone else agrees:
http://service.steinberg.de/webdoc_ps_int.nsf/show/acpi_vs_audio_performanc…
11: 1636542 XT-PIC Intel
82801CA-ICH3, Intel 82801CA-ICH3
Modem, uhci_hcd:usb1, uhci_hcd:usb2,eth0, yenta, yenta, ohci1394,
nvidia
You have your USB audio device on the same interrupt as the binary only
nvidia driver?!?
You won't get a lot of help from the open source community if you insist
on loading proprietary kernel modules. The FIRST thing you should do if
you're trying to optimize your system is don't load any binary only
kernel modules!!!
Lee
9:27 p.m.
You won't get a lot of help from the open source
community if you
insist on loading proprietary kernel modules. The FIRST thing you
should do if you're trying to optimize your system is don't load any
binary only kernel modules!!!
well, better a working closed-source driver, than no driver at all..
t
--
mailto:TimBlechmann@gmx.de ICQ: 96771783
http://www.mokabar.tk
latest mp3: kMW.mp3
http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone
http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space
would say "I want to see the manager."
William S. Burroughs
9:55 p.m.
Tim Blechmann wrote:
I use the nvidia driver too. Please try to disable your NIC, as someone
else also suggested. And yes I forgot to say I had to disable ACPI, as
carmen said.
c.
You won't
get a lot of help from the open source community if you
insist on loading proprietary kernel modules. The FIRST thing you
should do if you're trying to optimize your system is don't load any
binary only kernel modules!!!
well, better a working closed-source driver, than no driver at all..
t
20 Nov
20 Nov
12:58 p.m.
On Sun, 2005-11-20 at 02:28 +0000, Tim Blechmann wrote:
The nvidia driver is only necessary for hardware accelerated 3D which
doesn't have much use on an audio box.
Lee
You won't
get a lot of help from the open source community if you
insist on loading proprietary kernel modules. The FIRST thing you
should do if you're trying to optimize your system is don't load any
binary only kernel modules!!!
well, better a working closed-source driver, than no driver at all.. 
1:14 p.m.
Lee Revell wrote:
On Sun, 2005-11-20 at 02:28 +0000, Tim Blechmann
wrote:
The nvidia driver is only necessary for hardware accelerated 3D which
doesn't have much use on an audio box.
Unless you're using Pd + GEM, of course.
Or if you happen to like the OpenGL spectral display in Snd.
Windows users would point out CsoundAV as well.
Best,
dp
You
won't get a lot of help from the open source community if you
insist on loading proprietary kernel modules. The FIRST thing you
should do if you're trying to optimize your system is don't load any
binary only kernel modules!!!
well, better a working closed-source driver, than no driver at all..
2:08 p.m.
On Sun, 2005-11-20 at 12:28 -0500, Dave Phillips wrote:
Lee Revell wrote:
As long as you realize that you're trading those bells and whistles for
a completely undebuggable setup, feel free. It's not "license Nazism"
as someone else suggested - we have NO IDEA what the nvidia driver is
doing thus we CANNOT help you with any kernel problem at all.
Lee
On Sun, 2005-11-20 at 02:28 +0000, Tim Blechmann
wrote:
The nvidia driver is only necessary for hardware accelerated 3D which
doesn't have much use on an audio box.
Unless you're using Pd + GEM, of course.
Or if you happen to like the OpenGL spectral display in Snd.
Windows users would point out CsoundAV as well. You
won't get a lot of help from the open source community if you
insist on loading proprietary kernel modules. The FIRST thing you
should do if you're trying to optimize your system is don't load any
binary only kernel modules!!!
well, better a working closed-source driver, than no driver at all..
3:57 p.m.
On 20/11/05, Lee Revell <rlrevell(a)joe-job.com> wrote:
[...] a completely undebuggable setup [...]
we have NO IDEA what the nvidia driver is
doing thus we CANNOT help you with any kernel problem at all.
Bleh :-) All that's necessary is to verify the same problem exists
without the closed driver loaded, then go back to using it and
debug away, isn't it?
Then, you may not know what the closed driver is doing, but you
do know what it's not doing - ie. causing the problem you're
trying to debug.
Additionally, since it's very likely that debugging of setups which
make use of closed drivers has occured, and will continue to
occur, often with success, it's far from true to say that such a setup
is "completely undebuggable". Because, simply, in many cases
the fault being debugged is just not due to the closed driver,
which is working perfectly well, and according to the manufacturer's
description. (For examples of this, look at the many instances on
distro support lists of people debugging their installations of non-free
drivers. glxgears, anyone? ;-)
If you want to take an ethical stance of not helping anyone who
uses closed drivers, that may be a defensible position. But it's no
use pretending there are well-founded and absolute technical
reasons for it -- it's an ethical choice, a thoroughgoing boycott if
you like, not a technical necessity.
It's true that the use of closed drivers brings with it an element
of uncertainty, which may deter people from getting involved in
solving a problem, but that doesn't make it "completely
undebuggable".
So it seems to me, anyway.
- Pete.
8:05 p.m.
On Sun, Nov 20, 2005 at 07:56:56PM +0000, Pete Leigh wrote:
If you want to take an ethical stance of not helping
anyone who
uses closed drivers, that may be a defensible position. But it's no
use pretending there are well-founded and absolute technical
reasons for it -- it's an ethical choice, a thoroughgoing boycott if
you like, not a technical necessity.
Well, partially true. The whole tainted kernel thing started after
a bunch of developers got sick of seeing crashes that were only
reproduced with the nvidia module.
Alan Cox ran a go at reverse engineering it, and what he found was
that it does a lot of reads and writes to aparantly random memory
locations - an extremely unwise thing to do if you value stability.
There's no hardware documentation, so there's no way to know what is
going on or why.
The tainting was added to weed out bug reports that were specious -
not because the systems were necessarily "undebuggable", but rather
because when code is reading and writing to undocumentable places in
memory, you really have no idea what is going on.
So, you're right - it's not completely undebuggable. But it's
certainly not worth the time of a dev with better things to do.
--
Ross Vandegrift
ross(a)lug.udel.edu
"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
3:08 p.m.
The nvidia driver is only necessary for hardware
accelerated 3D which
doesn't have much use on an audio box.
1. there are programs that do audio and video at the same time / that
use the graphics acceleration to display the gui
2. the open-source nvidia driver didn't work for more than 3 minutes,
but when doing audio, i need to see, what i'm doing ...
cheers ... tim
--
mailto:TimBlechmann@gmx.de ICQ: 96771783
http://www.mokabar.tk
latest mp3: kMW.mp3
http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone
http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space
would say "I want to see the manager."
William S. Burroughs
5:09 p.m.
Tim Blechmann wrote:
Agree:
Unfortunately the open-src nv driver has had a havyweight
display bug with some programs (e.g. rosegarden) on my system
Installing the closed-src nvidia driver was no fun, but
now it does the job, and openGl stuff is a lot faster...
btw:
where would I disable acpi? In the bios or in the kernel-config?
I have the UA-25 card too but also cannot get latencies lower than 16ms
(according to qjackctl)
(kernel 2.6.13, full rt-preemt, pam patched)
regards, emanuel
The nvidia
driver is only necessary for hardware accelerated 3D which
doesn't have much use on an audio box.
1. there are programs that do audio and video at the same time / that
use the graphics acceleration to display the gui
2. the open-source nvidia driver didn't work for more than 3 minutes,
but when doing audio, i need to see, what i'm doing ...
cheers ... tim
5:26 p.m.
where would I disable acpi? In the bios or in the
kernel-config?
There's even the possibility to pass it to the kernel at boot time/via
the boot manager, so you can experiment a bit without recompiling the
kernel.
On mine I find something like
acpi=ht
which I once set to make the machine powering off automatically after
shutdown, but interestingly it doesn't on 2.6.14.2. I have to
investigate further, but maybe it's a good starting point for your
search too.
Best regards
ce
5:17 p.m.
1. there are programs that do audio and video at the
same time / that
use the graphics acceleration to display the gui
there are occasions where I like the nvidia driver, maybe for twin view
etc.
2. the open-source nvidia driver didn't work for
more than 3 minutes,
but when doing audio, i need to see, what i'm doing ...
mine works for far more than three minutes ;-) .
Lee always is *very* supportive and spends lots of time helping others.
I think it's absolutely OK if he asks not to use binary modules. For
sure there are various good reasons for not using the binary drivers.
It's absolutely OK if he says "If you use the binary drivers don't
expect too much help".
Just to clarify: I for myself have used the nvidia driver for a long
time :) .
Best regards
ce
5:13 a.m.
You won't get a lot of help from the open source
community if you
insist on loading proprietary kernel modules. The FIRST thing you
should do if you're trying to optimize your system is don't load any
binary only kernel modules!!!
To be honest, I do not really need the capabilities of the binary
driver, but using the nv driver instead causes the fonts to be very
huge on my desktop and less colour depth so watching imgaes and
gradients isn't as joyful as it can be.
The problem on notebooks is that you have no choice in the hardware
components :( .
But anyway, it's a good hint and I'll try out if latency decreases when
switching the nvidia driver off as well as the NIC.
Best regards
ce
7:15 a.m.
11: 1636542 XT-PIC Intel 82801CA-ICH3,
Intel
82801CA-ICH3 Modem, uhci_hcd:usb1, uhci_hcd:usb2,eth0, yenta, yenta,
ohci1394,
Thanks a lot for all IRQ hints. Well, I disabled the nvidia driver and
ensured ALSA does not load the module for the internal AC '97 chip.
IRQ11 now looks as
11: 2428122 XT-PIC uhci_hcd:usb1, uhci_hcd:usb2, eth0,
yenta, yenta, ohci1394
Disabling the NIC is a no no, I really do not want to reboot for writing
an email ;-) .
Result: Better latency, so I can recommend to avoid IRQ sharing.
I can now run JACKD with -p128- This still gives some glitches every now
and then, *but* at -p256 as I used before the glitches seem to be gone.
I wonder if I could force the USB bus to another IRQ or if I could move
eth0 and yenta to another IRQ.
Best regards
ce
5:21 p.m.
I wonder if I
could force the USB bus to another IRQ or if I could
move eth0 and yenta to another IRQ.
This is the part that I am afraid is hard wired, at least on most
laptops.
19 Nov
19 Nov
8:30 p.m.
On Sat, 2005-11-19 at 15:19 -0800, thewade wrote:
Hello pd and lau lists,
I am having trouble figuring out how to actually change the irq's of specific
devices.
You are wasting your time. Those IRQ settings are hard wired. Even if
this was possible there's no point - there's no meaningful relationship
between which IRQ your device is on and the performance.
Lee
9:44 p.m.
On Sat, 19 Nov 2005 19:18:13 -0500
Lee Revell <rlrevell(a)joe-job.com> wrote:
On Sat, 2005-11-19 at 15:19 -0800, thewade wrote:
I beg to differ. Especially with RT setups, it can make very much sense
when the audio device does have an irq for itself. On a -rt system this
opens the possibility of raising the soundcard's irq handler priority to
a value higher than the prios of all other irq handlers (i.e. 90). Also
rising i.e. jackd's prio higher (70) than the other irq handlers (around
50) will give rocksolid performance. Compiling a kernel while jack is
running? No problem. Heavy network load? No problem. This would not work
quite as nice with several devices sharing the soundcard irq.
I wonder how non -rt systems (or not properly setup -rt systems) hold up
to loads like this..
Have fun,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
Hello pd and lau lists,
I am having trouble figuring out how to actually change the irq's of specific
devices.
You are wasting your time. Those IRQ settings are hard wired. Even if
this was possible there's no point - there's no meaningful relationship
between which IRQ your device is on and the performance.
10:04 p.m.
On 19/11/05, thewade <pdman(a)aproximation.org> wrote:
My goals with this project are to have a faster audio
machine, and hopefully to not have to
disable acpi in order to run linux. I am not sure of the motherboard in this laptop,
You could try a look at
http://www.motherboards.org/articles/tech-planations/13_1.html
but laptop m/bs are sometimes shrouded in mystery and impossible to identify..
The acpi problem is that the system hangs (with acpi
on) when fedora tried to activate eth0.
Perhaps it would be best to focus on solving your eth0 problem, with different
kernel versions, distro support forums, and so on, in order to get acpi working?
Are you running straight fedora or ccrma? If ccrma, I've read there's a package
called rtirq which seems to have something to do with re-prioritizing interrupts
(in software) though I don't know the details. I think you'd need to be running
the planet ccrma kernel (or equivalent) for it to work..
I would open my laptop but I doubt that there is much
I can do in there. Probably not
a whole lot of shuffling I can do in a laptop.
-thewade
I think you're right there!
- Pete.
26 Nov
26 Nov
9:40 p.m.
On 11/19/05, thewade <pdman(a)aproximation.org> wrote:
Hello pd and lau lists,
Hi.
I am having trouble figuring out how to actually change the irq's of specific
devices.
<SNIP>
I am not sure of the motherboard in this laptop
<SNIP>
Changing interrupt priorities of internal devices on a laptop is not
possible. The devices are on the motherboard and are hard wired to
specific inputs on the PIC. You cannot change them at all.
For clarity, the only way you can change IRQs in a desktop machine is
to move PCI cards from slot to slot. The slots are hard wired, but the
cards are movable.
I haven't read the whole thread. It got sort of long. While Lee's
comment about interrupt priorities was technically correct, in the old
days where ISR's could (and did) block lower priority interrupts this
was an issue. It is not such an issue today, at least for Linux
machines.
As for your laptop, if it is a modern machine is possibly has an APIC.
(Advanced PIC) If it does then enabling it in your kernel and using it
would allow you to change priorities of each hardware device. I
suppose the Fedora kernel has this and that possibly your motherboard
does not, but finding more info on that might lead you to improved
results down the road.
Good luck with whatever you do.
cheers,
Mark
27 Nov
27 Nov
9:34 a.m.
On Sat, 2005-11-26 at 17:40 -0800, Mark Knecht wrote:
Changing interrupt priorities of internal devices on a
laptop is not
possible. The devices are on the motherboard and are hard wired to
specific inputs on the PIC. You cannot change them at all.
i am not sure that this is strictly true. my impression of modern intel-
based architecture is that the inputs to the (A)PIC do not map
deterministically to IRQ lines feeding the CPU. the (A)PIC and its
cousins can be programmed to do many different things. the problem with
laptops is generally that they come with a BIOS that offers no options
to "reprogram" the (A)PIC, and then you boot into a kernel that
generally seems to want to leave this stuff alone. this is increasingly
the case on non-laptops as well, which is quite depressing.
i wrote a little perl script sometime this year or last to dump the PIC
routings. it was quite instructional :)
--p
11:44 a.m.
On 11/27/05, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Sat, 2005-11-26 at 17:40 -0800, Mark Knecht wrote:
This is true. APIC inputs != IRQs. If a PC (laptop, desktop, etc.)
uses an APIC then the idea is that each hardware device can have it's
own input on the APIC and eventually it's own APIC IRQ.
However, if a PC (laptop, desktop, etc.) shares interrupts going into
an APIC then these (TTBOMK) cannot be separated. If they are the same
trace on the motherboard then they map to a single shared IRQ.
(TTBOMK)
Changing interrupt priorities of internal devices
on a laptop is not
possible. The devices are on the motherboard and are hard wired to
specific inputs on the PIC. You cannot change them at all.
i am not sure that this is strictly true. my impression of modern intel-
based architecture is that the inputs to the (A)PIC do not map
deterministically to IRQ lines feeding the CPU. the (A)PIC and its
cousins can be programmed to do many different things. the problem with
laptops is generally that they come with a BIOS that offers no options
to "reprogram" the (A)PIC, and then you boot into a kernel that
generally seems to want to leave this stuff alone. this is increasingly
the case on non-laptops as well, which is quite depressing.
You raise a very valuable point. Whether using a PIC or an APIC some
BIOS's do allow the user to:
1) Disable the APIC in favor of an old style PIC
2) Change the IRQ number of a limited number of internal hardware devices.
As far as I know Linux does leave BIOS IRQ settings alone, or can be
told to.Possibly thewade should look at what BIOS control, if any, his
machine gives him.
- Mark
12:15 p.m.
On 27/11/05, Mark Knecht <markknecht(a)gmail.com> wrote:
>>Changing interrupt priorities of internal
devices on a laptop is not
>>possible. The devices are on the motherboard and are hard wired to
>>specific inputs on the PIC. You cannot change them at all.
Hmm, probably I didn't understand very well, but I didn't think the
situation was quite as bleak as this...
Didn't Clemens Ladisch write a (now outdated) patch to re-assign
APIC priorities in software, and a program to change PIC interrupt
priorities?
http://users.informatik.uni-halle.de/~ladischc/linux_interrupt_priorities.h…
... And isn't part of the point of running the rt kernel patch that
you can give your choice of priorities to the different interrupt
handling threads?
Is the latter an intrinsically inferior solution?
As far as I know Linux does leave BIOS IRQ settings
alone, or can be
told to.Possibly thewade should look at what BIOS control, if any, his
machine gives him.
I think his BIOS doesn't give him any control, which is why he was
trying to identify the motherboard, to get a less restrictive BIOS :-)
- Pete.
2:23 p.m.
On 11/27/05, Pete Leigh <pete.leigh(a)gmail.com> wrote:
I did not read it that way but you may be correct.
- Mark
On 27/11/05, Mark Knecht <markknecht(a)gmail.com>
wrote:
For APIC - yes
For PIC - no
The PIC (Programmable Interrupt Controller) architecture, as
implemented in the original PC, had fixed priorities:
0,1,2,3,4,5,6,7
Since there were two chips the second chip was cascaded off of IRQ2 of
the first chip, creating:
0,1,(2),8,9,10,11,12,13,14,15,3,4,5,6,7
where IRQ8 took the place of the original IRQ2. (simple, 'eh?)
Unfortunately this was all hard wired and couldn't be changed, and
ended up with too few interrupts which had to be shared between
onboard devices and PCI cards which resulted in lots of shared
interrupts.
With the introduction of the APIC (Advanced PIC) there were far more
inputs to the APIC, allowing individual devices to get their own
inputs. Further the APIC setup didn't set priorities in stone but
allowed them to be reorded, so that input 5 could be high priority or
low priority.
You'll see that my machine here is not limited to the numbers 0-15.
Unfortunately, even with an APIC I still have shared interrupts on
this machine:
mark@lightning ~ $ cat /proc/interrupts
CPU0
0: 1871565 IO-APIC-edge timer
1: 1980 IO-APIC-edge i8042
7: 2 IO-APIC-edge lpptest
8: 0 IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
12: 17334 IO-APIC-edge i8042
14: 48 IO-APIC-edge ide0
50: 2 IO-APIC-level ehci_hcd:usb1
58: 0 IO-APIC-level hdsp
66: 2 IO-APIC-level ohci1394
217: 187320 IO-APIC-level ohci_hcd:usb2, eth0
225: 0 IO-APIC-level libata, NVidia CK804
233: 6897 IO-APIC-level libata
NMI: 127
LOC: 1871221
ERR: 1
MIS: 0
mark@lightning ~ $
>>Changing interrupt priorities of internal
devices on a laptop is not
>>possible. The devices are on the motherboard and are hard wired to
>>specific inputs on the PIC. You cannot change them at all.
Hmm, probably I didn't understand very well, but I didn't think the
situation was quite as bleak as this...
Didn't Clemens Ladisch write a (now outdated) patch to re-assign
APIC priorities in software, and a program to change PIC interrupt
priorities?
http://users.informatik.uni-halle.de/~ladischc/linux_interrupt_priorities.h…
... And isn't part of the point of running the rt kernel patch that
you can give your choice of priorities to the different interrupt
handling threads?
Well, partially true. Running the -rt kernel gives you priority
setting capabilities but that cannot change the operation of the
hardware in the machine you are running.
Is the latter an intrinsically inferior solution?
I didn't follow. Sorry.
As far as I know Linux does leave BIOS IRQ
settings alone, or can be
told to.Possibly thewade should look at what BIOS control, if any, his
machine gives him.
I think his BIOS doesn't give him any control, which is why he was
trying to identify the motherboard, to get a less restrictive BIOS :-)
2:45 p.m.
On 27/11/05, Mark Knecht <markknecht(a)gmail.com> wrote:
On 11/27/05, Pete Leigh <pete.leigh(a)gmail.com>
wrote:
> Didn't Clemens Ladisch write a (now outdated)
patch to re-assign
> APIC priorities in software, and a program to change PIC interrupt
> priorities?
For APIC - yes
For PIC - no
Oh, perhaps I misread at
http://users.informaik.uni-halle.de/~ladischc/pic_priorities.html
where he says:
(quote on)
To configure the PIC, use the following little program:
set8259priorities.c (source code only).
[...]
The above example configuration with interrupt 5 at the
top can be set with "set8259priorities 5 8". For interrupt 11
at the top, run "set8259priorities 2 11".
(quote off)
Or perhaps I didn't understand what he was saying. It seems
to be saying that the PIC controller can be programmed to
some extent from software, at least in principle (perhaps it
needs some hardware support?)
> Is the latter an intrinsically inferior solution?
I didn't follow. Sorry.
I meant to ask: is using the irq handling thread priority control
from the rt kernel patches necessarily a worse way to go about
things than hardware re-prioritisation?
Cheers,
- Pete.
3:03 p.m.
On 11/27/05, Pete Leigh <pete.leigh(a)gmail.com> wrote:
No, not at all. In fact, I think that both are necessary to gain the
most control over the hardware. With a PIC system set up things with a
sound card on IRQ9 or IRQ10. Then set the -rt priority to a value of
80. With an APIC system I believe all you have to do is set the -rt
priority and not worry so much about the hardware setting.
- Mark
On 27/11/05, Mark Knecht <markknecht(a)gmail.com>
wrote:
OK, this 'priority' is the Linux kernel's priority. The 'priority' I
was speaking of was the actual hardware priority. They are different
things.
In the older PIC when an ISR was entered all lower hardware 'priority'
IRQ are blocked until the ISR tells the PIC it is ready to release.
That is the numerical list I gave earlier. In that list is something
at IRQ14 starts and doesn't release then all interrupts of lower
hardware priority (15,3,4,5,6,7) will not happen.
The setting of Linux kernel 'priority' doesn't care whether you are
using a PIC or an APIC. Clemen's app works for both I'm sure.
Sorry for the confusion!
On 11/27/05, Pete Leigh
<pete.leigh(a)gmail.com> wrote:
> Didn't Clemens Ladisch write a (now
outdated) patch to re-assign
> APIC priorities in software, and a program to change PIC interrupt
> priorities?
For APIC - yes
For PIC - no
Oh, perhaps I misread at
http://users.informaik.uni-halle.de/~ladischc/pic_priorities.html
where he says:
(quote on)
To configure the PIC, use the following little program:
set8259priorities.c (source code only).
[...]
The above example configuration with interrupt 5 at the
top can be set with "set8259priorities 5 8". For interrupt 11
at the top, run "set8259priorities 2 11".
(quote off)
Or perhaps I didn't understand what he was saying. It seems
to be saying that the PIC controller can be programmed to
some extent from software, at least in principle (perhaps it
needs some hardware support?) > Is the
latter an intrinsically inferior solution?
I didn't follow. Sorry.
I meant to ask: is using the irq handling thread priority control
from the rt kernel patches necessarily a worse way to go about
things than hardware re-prioritisation?
Cheers,
- Pete.
3:30 p.m.
On 27/11/05, Mark Knecht <markknecht(a)gmail.com> wrote:
OK, this 'priority' is the Linux kernel's
priority. The 'priority' I
was speaking of was the actual hardware priority. They are different
things.
Right, this was where I was getting confused! Thanks for
clarifying that!
both are necessary to gain the
most control over the hardware. With a PIC system set up things with a
sound card on IRQ9 or IRQ10. Then set the -rt priority to a value of
80. With an APIC system I believe all you have to do is set the -rt
priority and not worry so much about the hardware setting.
That makes sense, now. Thanks a lot.. :)
- Pete.
4:07 p.m.
On Sun, 2005-11-27 at 11:03 -0800, Mark Knecht wrote:
OK, this 'priority' is the Linux kernel's
priority. The 'priority' I
was speaking of was the actual hardware priority. They are different
things.
In the older PIC when an ISR was entered all lower hardware 'priority'
IRQ are blocked until the ISR tells the PIC it is ready to release.
That is the numerical list I gave earlier. In that list is something
at IRQ14 starts and doesn't release then all interrupts of lower
hardware priority (15,3,4,5,6,7) will not happen.
Wrong. PIC or APIC, interrupts do not delay other interrupts in this
way. If a disk interrupt happens on IRQ14 then a soundcard interrupt on
IRQ5 fires immediately after then the disk interrupt handler will be
interrupted by the sound card interrupt handler. That's why they are
called interrupts! This is why I keep trying to explain that there is
no "priority" relationship between interrupts.
In the above scenario if BOTH devices were sharing IRQ14 then the second
interrupt handler WOULD be delayed until the first finished.
The ability to prioritize interrupts with the -rt kernel is useful
because interrupts can be prevented from interrupting USERSPACE code.
I think people might be confused because Windows has a notion of the
interrupt priority level?
Lee
4:49 p.m.
On Sun, 2005-11-27 at 15:07 -0500, Lee Revell wrote:
On Sun, 2005-11-27 at 11:03 -0800, Mark Knecht wrote:
wrong, at least on PIC based systems. the PIC doesn't allow the IRQ line
to the CPU to be raised by a lower priority line until the CPU has acked
the higher priority IRQ. if the CPU never resets the relevant bit on the
PIC, you can completely wedge the system. all linux kernels clear this
bit long before the interrupt handler for the device is ever invoked, so
you can be forgiven for thinking it works the way you've described :)
--p
OK, this 'priority' is the Linux
kernel's priority. The 'priority' I
was speaking of was the actual hardware priority. They are different
things.
In the older PIC when an ISR was entered all lower hardware 'priority'
IRQ are blocked until the ISR tells the PIC it is ready to release.
That is the numerical list I gave earlier. In that list is something
at IRQ14 starts and doesn't release then all interrupts of lower
hardware priority (15,3,4,5,6,7) will not happen.
Wrong. PIC or APIC, interrupts do not delay other interrupts in this
way. If a disk interrupt happens on IRQ14 then a soundcard interrupt on
IRQ5 fires immediately after then the disk interrupt handler will be
interrupted by the sound card interrupt handler. That's why they are
called interrupts! This is why I keep trying to explain that there is
no "priority" relationship between interrupts.
6:01 p.m.
On Sun, 2005-11-27 at 16:51 -0500, Paul Davis wrote:
On Sun, 2005-11-27 at 15:07 -0500, Lee Revell wrote:
Ah, OK. I should have prefaced my statement with "from the Linux
kernel's perspective".
Anyway my point (that the OP is not going to improve his PD performance
by twiddling with the interrupt controller) remains valid.
Lee
Wrong. PIC or APIC, interrupts do not delay
other interrupts in this
way. If a disk interrupt happens on IRQ14 then a soundcard interrupt on
IRQ5 fires immediately after then the disk interrupt handler will be
interrupted by the sound card interrupt handler. That's why they are
called interrupts! This is why I keep trying to explain that there is
no "priority" relationship between interrupts.
wrong, at least on PIC based systems. the PIC doesn't allow the IRQ line
to the CPU to be raised by a lower priority line until the CPU has acked
the higher priority IRQ. if the CPU never resets the relevant bit on the
PIC, you can completely wedge the system. all linux kernels clear this
bit long before the interrupt handler for the device is ever invoked, so
you can be forgiven for thinking it works the way you've described :)
5:12 p.m.
On 11/27/05, Lee Revell <rlrevell(a)joe-job.com> wrote:
On Sun, 2005-11-27 at 11:03 -0800, Mark Knecht wrote:
Sorry, but while this is correct at the software level it is,
unfortunately, completely incorrect at the hardware level. While I am
not a programmer and do not know myself how to do it, if I write (as
an example only) an ISR that simply turns off interrupts and goes into
a loop, then since interrupts are off no other interrupt will get
through and since the ISR is in a loop it will never return. The
machine is locked and you're hung.
While I do not suggest that this example is anything other than
pathological, it demonstrates the problem.
OK, this 'priority' is the Linux
kernel's priority. The 'priority' I
was speaking of was the actual hardware priority. They are different
things.
In the older PIC when an ISR was entered all lower hardware 'priority'
IRQ are blocked until the ISR tells the PIC it is ready to release.
That is the numerical list I gave earlier. In that list is something
at IRQ14 starts and doesn't release then all interrupts of lower
hardware priority (15,3,4,5,6,7) will not happen.
Wrong. PIC or APIC, interrupts do not delay other interrupts in this
way. If a disk interrupt happens on IRQ14 then a soundcard interrupt on
IRQ5 fires immediately after then the disk interrupt handler will be
interrupted by the sound card interrupt handler. That's why they are
called interrupts! This is why I keep trying to explain that there is
no "priority" relationship between interrupts.
In the above scenario if BOTH devices were sharing IRQ14 then the second
interrupt handler WOULD be delayed until the first finished.
Correct and agreed to.
The ability to prioritize interrupts with the -rt kernel is useful
because interrupts can be prevented from interrupting USERSPACE code.
Cool!
I think people might be confused because Windows has a notion of the
interrupt priority level?
This I'm not sure of.
Thanks,
Mark
Lee
5:33 p.m.
On Sun, 27 Nov 2005 13:12:46 -0800
Mark Knecht <markknecht(a)gmail.com> wrote:
Actually sttictly speaking this isn't true. Any code will be preempted
by an IRQ unless it is running with IRQ's off. The cool thing about -rt
is now that every interrupt handler is split into top half and bottom
half (if it before already was split like this, it is now split in 3
pieces). The top half basically just clears the IRQ line and sets up
some stuff, so the kernel thread _bottom half_ irq handler is notified,
there's something to do.
The top half is extremely fast, so the time which might ever be spent in
IRQ off situation is very short. So any IRQ interrupts user space for
only a very very very short time. And everything else (working on the
interrupt requests, etc) is now subject to scheduler decisions.
The kernel threads which are the IRQ bottom half handlers can be
prioritized with -rt. This gives the user the control to i.e. make the
soundcard bottom half irq handler always have priority over the hd
bottom half irq handler. And even jackd can have higher prio than the hd
bottom half irq handler.
To get this control (to prioritize one over the other) they each have to
have their own kernel thread bottom half irq handler which doesn't work
when they share an irq (though this might evenbe possible).
Anyways, the XT-PIC/APIC priorities only count very little on a -rt
system as the possible time windows in which each top half irq handler
runs is very small, so collisions are unlikely.. It is important though
to have individual irq's to be able to priritize on the level where it
counts.
Regards,
Florian Schmidt
--
Palimm Palimm!
http://tapas.affenbande.org
The ability to
prioritize interrupts with the -rt kernel is useful
because interrupts can be prevented from interrupting USERSPACE code.
Cool!
6:01 p.m.
On Sun, 2005-11-27 at 13:12 -0800, Mark Knecht wrote:
Sorry, but while this is correct at the software level
it is,
unfortunately, completely incorrect at the hardware level. While I am
not a programmer and do not know myself how to do it, if I write (as
an example only) an ISR that simply turns off interrupts and goes into
a loop, then since interrupts are off no other interrupt will get
through and since the ISR is in a loop it will never return. The
machine is locked and you're hung.
While I do not suggest that this example is anything other than
pathological, it demonstrates the problem.
It does not demonstrate a real world problem. If this were to happen it
would be a grave kernel bug.
In the Linux kernel only drivers that register their ISR with
SA_INTERRUPT block out ALL other interrupts until they complete.
Currently the ALSA drivers and system timer do this as the handling of
those interrupts has RT constraints, and the handlers execute quickly
anyway.
Lee
6:34 p.m.
On 11/27/05, Lee Revell <rlrevell(a)joe-job.com> wrote:
On Sun, 2005-11-27 at 13:12 -0800, Mark Knecht wrote:
Agreed.
Sorry, but while this is correct at the software
level it is,
unfortunately, completely incorrect at the hardware level. While I am
not a programmer and do not know myself how to do it, if I write (as
an example only) an ISR that simply turns off interrupts and goes into
a loop, then since interrupts are off no other interrupt will get
through and since the ISR is in a loop it will never return. The
machine is locked and you're hung.
While I do not suggest that this example is anything other than
pathological, it demonstrates the problem.
It does not demonstrate a real world problem. If this were to happen it
would be a grave kernel bug.
I do not think so. The Linux kernel doesn't have a bug if the hardware
interrupt to the processor is never asserted. This is what happened on
the PIC if a lower priority interrupt came along at the wrong time.
In the Linux kernel only drivers that register their ISR with
SA_INTERRUPT block out ALL other interrupts until they complete.
Currently the ALSA drivers and system timer do this as the handling of
those interrupts has RT constraints, and the handlers execute quickly
anyway.
Lee
I agree that things are in pretty good shape as far as Linux ISR's
seem to go, but that was not always the case...
Cheers,
Mark
6937
days inactive
6945
days old
linux-audio-user@lists.linuxaudio.org
36 comments
13 participants
participants (13)
-
carmen -
Cesare Marilungo -
Christoph Eckert -
Dave Phillips -
Emanuel Rumpf -
Florian Schmidt -
Lee Revell -
Mark Knecht -
Paul Davis -
Pete Leigh -
ross＠jose.lug.udel.edu -
thewade -
Tim Blechmann