On 11/27/05, Pete Leigh <pete.leigh@xxxxxxxxx> wrote: > On 27/11/05, Mark Knecht <markknecht@xxxxxxxxx> 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@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 ~ $ > > 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