Re: IRQ assignment on my IBM X24

[Karl Hammar]

> this seems really poor bios design:
> @mini rminnich]#  lspci -v -v | grep Interrupt
>         Interrupt: pin A routed to IRQ 11
>         Interrupt: pin B routed to IRQ 11
>         Interrupt: pin C routed to IRQ 11
>         Interrupt: pin A routed to IRQ 11
>         Interrupt: pin B routed to IRQ 11
>         Interrupt: pin B routed to IRQ 11
>         Interrupt: pin B routed to IRQ 11
>         Interrupt: pin A routed to IRQ 11
>         Interrupt: pin A routed to IRQ 11
>         Interrupt: pin B routed to IRQ 11
>         Interrupt: pin A routed to IRQ 11
>         Interrupt: pin A routed to IRQ 11
>
> Pretty much everyone goes to IRQ 11.
>
> And a bunch of Interrupts go unused:
>        CPU0       
>
> 0:    3381694          XT-PIC  timer
>   1:      13873          XT-PIC  keyboard
>   2:          0          XT-PIC  cascade
>   8:          1          XT-PIC  rtc
>  11:      77842          XT-PIC  usb-uhci, usb-uhci, usb-uhci, eth0, 
> wlan0, Ricoh Co Ltd RL5c476 II, Ricoh Co Ltd RL5c476 II (#2)
>  12:     360259          XT-PIC  PS/2 Mouse
>  14:      85559          XT-PIC  ide0
> NMI:          0 
> ERR:          0
>
> Is there any reason a BIOS would do this?
>
> ron

...

You can go into your laptops bios and reassign them if you don't like
that setup, I had the same setting in my tpx20.

Is there anyone who knows if that setup is bad or not? Does it do any
difference?

The things I can think of is:

. drivers don't like to share interrupts, possible resulting in errors
  I have seen this previously, but not tested it resently

. I have heard something like:
  "to use the irq 0-15 you have to access the interrupt controller
  (8259) and to that end you have to access the ISA bus, which means
  slow access"
  Is that true?

The only hint I can find is:

$ grep -A3 'Interrupt ReQuest'  /usr/src/kernel-source-2.4.20/Documentation/Configure.help 
  (there is a small number of Interrupt ReQuest lines in your computer
  that are used by the attached devices to gain the CPU's attention --
  often a source of trouble if two devices are mistakenly configured
  to use the same IRQ). The program procinfo to display some

$ grep -A2 distributing /usr/src/kernel-source-2.4.20/Documentation/i386/IO-APIC.txt 
between the PIRQ lines. (distributing IRQ sources properly is not a
necessity, PCI IRQs can be shared at will, but it's a good for performance
to have non shared interrupts). Slot5 should be used for videocards, they

$ grep -A16 'Level-Triggered Interrupts'  /usr/src/kernel-source-2.4.20/Documentation/mca.txt 
Level-Triggered Interrupts
==========================

Because MCA uses level-triggered interrupts, a few problems arise with
what might best be described as the ISA mindset and its effects on
drivers.  These sorts of problems are expected to become less common as
more people use shared IRQs on PCI machines.

In general, an interrupt must be acknowledged not only at the ICU (which
is done automagically by the kernel), but at the device level.  In
particular, IRQ 0 must be reset after a timer interrupt (now done in
arch/i386/kernel/time.c) or the first timer interrupt hangs the system.
There were also problems with the 1.3.x floppy drivers, but that seems
to have been fixed.

IRQs are also shareable, and most MCA-specific devices should be coded
with shared IRQs in mind.

$ grep -A1 'SA_SHIRQ'  /usr/src/kernel-source-2.4.20/Documentation/pci.txt 
   All interrupt handlers should be registered with SA_SHIRQ and use the devid
to map IRQs to devices (remember that all PCI interrupts are shared).

$ grep -A1 'Switching between'  /usr/src/kernel-source-2.4.20/arch/i386/kernel/i8259.c 
 * This function assumes to be called rarely. Switching between
 * 8259A registers is slow.

$ grep -A1 'interr'  /usr/src/kernel-source-2.4.20/arch/i386/kernel/io_apic.c | grep pola
/* EISA interrupts are always polarity zero and can be edge or level
/* ISA interrupts are always polarity zero edge triggered,
/* PCI interrupts are always polarity one level triggered,
/* MCA interrupts are always polarity zero level triggered,

Are there any other issues abut irq assignments?

BTW, does things crash on you, do you get worse performance, can't
different drivers function with the same irq, or what?

Regards,
/Karl

-----------------------------------------------------------------------
Karl Hammar                    Aspö Data           [e-mail]
Lilla Aspö 2340                                                Networks
S-742 94 Östhammar          [phone]                   Computers
Sweden                     [phone]                 Consulting
-----------------------------------------------------------------------

IRQ assignment on my IBM X24

[ron minnich]

On Mon, 7 Apr 2003, Karl Hammar wrote:
> BTW, does things crash on you, do you get worse performance, can't
> different drivers function with the same irq, or what?

I am looking at the interrupt-assignment problem again and was checking 
what my x24 did.

ron

IRQ assignment on my IBM X24

[ollie lho]

On Mon, 2003-04-07 at 16:42, Karl Hammar wrote:
> You can go into your laptops bios and reassign them if you don't like
> that setup, I had the same setting in my tpx20.
>
> Is there anyone who knows if that setup is bad or not? Does it do any
> difference?

Theoretically, this will give you larger interrupt latency. When the 
kernel is handling some specific IRQ line, it disable further interrupts
on that line (but enable all other lines). If there are other devices
sharing the same line, their interrupts can not be served by the kernel
until the first one is completed. On the other hand, if a device is on
the other IRQ line, the kernel can service the interrupt by entering 
another level of interrupt context. (BTW, this is the case in 2.4.x 
kernel, I am not sure if it is true for 2.5.x.)