On 11/27/05, Pete Leigh <pete.leigh@email-addr-hidden> wrote:
> On 27/11/05, Mark Knecht <markknecht@email-addr-hidden> 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?
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@email-addr-hidden ~ $ 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@email-addr-hidden ~ $
>
> http://users.informatik.uni-halle.de/~ladischc/linux_interrupt_priorities.html
>
> ... 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 :-)
I did not read it that way but you may be correct.
- Mark
Received on Mon Nov 28 00:15:04 2005
This archive was generated by hypermail 2.1.8 : Mon Nov 28 2005 - 00:15:05 EET