I'm having a problem with kernel 2.4.2-SMP on my HP Vectra XU 5/90. This is
an old dual-pentium (Neptune chipset) machine.
The machine has an on-board SCSI and ethernet controller, and I have added a
Netgear FA310TX card. Due to the "unique" design of the motherboard, all the
PCI slots share an interrupt with the SCSI controller.
I have narrowed the problem down to the fact that the kernel is assigning
the PCI devices edge-triggered interrupts (IO-APIC-edge) instead of level
(IO-APIC-level). This causes the SCSI controller to hang if there is any
network activity during disk activity.
The machine identifies itself as an MPC type #5 machine (ISA/PCI), but it
seems to have EISA-style ELCR configuration information. If I hack mpparse.c
to force my machine type to #6 (EISA), the PCI interrupts are correctly
identified as level triggered.
Could someone please help me develop a correct workaround for this problem?
I have been thinking about the following options:
If there is no MP-table interrupt configuration information for an ISA/PCI
system, try falling back to ELCR information before giving up and using a
standard "ISA" scheme? It seems that HP may have done this on several of
their early SMP systems.
OR
If PCI interrupts are shared, force them to be level triggered? Can shared
PCI interrupts be edge triggered? If not, then wouldn't this be the correct
solution? This isn't specific to the Vectra, but could possibly prevent
problems on any machine with a broken BIOS?
"/proc/interrupts" on the hacked kernel looks like:
CPU0 CPU1
0: 411243 337583 IO-APIC-edge timer
1: 1095 1260 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
4: 603 116 IO-APIC-edge serial
5: 21400 20657 IO-APIC-edge soundblaster
8: 0 2 IO-APIC-edge rtc
9: 3398 3158 IO-APIC-level PCnet/PCI 79C970
10: 504852 505145 IO-APIC-level tmscsim, eth1
NMI: 749766 749768
LOC: 748736 748797
ERR: 0
I can post the dmesg output, if that would help.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
> -----Original Message-----
> From: John William [mailto:[email protected]]
>
> I'm having a problem with kernel 2.4.2-SMP on my HP Vectra XU
> 5/90. This is an old dual-pentium (Neptune chipset) machine.
>
...
>
> OR
>
> If PCI interrupts are shared, force them to be level
> triggered? Can shared
> PCI interrupts be edge triggered? If not, then wouldn't this
> be the correct
> solution? This isn't specific to the Vectra, but could
> possibly prevent problems on any machine with a broken BIOS?
PCI interrupts are defined as "level sensitive" and must
be shareable.
~Randy
>From: "Dunlap, Randy" <[email protected]>
>
> > -----Original Message-----
> > From: John William [mailto:[email protected]]
<snip>
> > If PCI interrupts are shared, force them to be level
> > triggered? Can shared
> > PCI interrupts be edge triggered? If not, then wouldn't this
> > be the correct
> > solution? This isn't specific to the Vectra, but could
> > possibly prevent problems on any machine with a broken BIOS?
>
>PCI interrupts are defined as "level sensitive" and must
>be shareable.
>
>~Randy
So PCI interrupts must always be level triggered? If so, then the kernel
should never program the IO APIC to use an edge triggered interrupt on a PCI
device. If that's true, then why not force the interrupt type to level
triggered for all PCI devices (to work around a potentially broken MP
table)?
What about this solution:
1) In pci-irq.c, in pcibios_fixup_irqs(), if we are using the IO APIC, check
to see if the IRQ has been set to level triggered.
2a) If YES, then do nothing different.
2b) If NO, then set the IRQ type to level triggered and write the changed
configuration to the IO APIC for that interrupt.
The other alternative I considered is adding a check for the presence of
ELCR data to construct_default_ISA_mptable() in mpparse.c, but there doesn't
seem to be an easy way to verify that there really is (or isn't) valid ELCR
data.
Apparently, HP chose to use the ELCR to provide IRQ information on their
early SMP machines, but since the system is defined as type 5 (ISA/PCI), the
kernel doesn't check for the presence of ELCR data, and the machine's MP
table does not appear to have any IRQ information.
But if PCI interrupts have to be level triggered, then the first alternative
would seem to be a more general solution.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
> So PCI interrupts must always be level triggered? If so, then the kernel
> should never program the IO APIC to use an edge triggered interrupt on a PCI
> device. If that's true, then why not force the interrupt type to level
> triggered for all PCI devices (to work around a potentially broken MP
> table)?
Its not that simple. Its common to edge trigger some of the built in devices
like IDE controllers.
> maintainers about the problem. If this isn't ok, then maybe the sanity check
> in pci-irq.c would be to force level triggering only on shared PCI
> interrupts?
This seems a sensible path to take for such machines
> I'm going down this path because I can't see a good way to check for the
> presence of a valid ELCR, so I'm hoping a PCI IRQ sanity check would fix my
> problem (but someone please correct me if I'm wrong). Are SMP standard type
> #5 machines (ISA/PCI) or just the Vectra's so rare that I'm the only one
> having this problem? Or am I the only one to try putting a PCI card in one
> of it's two slots... :-)
HP/XU boxes have a history of weird (and sometimes invalid) MP tables. In this
case its not clear to me whether HP or the kernel is right (or indeed if both
are right and the standard doesnt help)
>From: Alan Cox <[email protected]>
>
> > So PCI interrupts must always be level triggered? If so, then the kernel
> > should never program the IO APIC to use an edge triggered interrupt on a
>PCI
> > device. If that's true, then why not force the interrupt type to level
> > triggered for all PCI devices (to work around a potentially broken MP
> > table)?
>
>Its not that simple. Its common to edge trigger some of the built in
>devices
>like IDE controllers.
Ok, I guess I'm a little confused again. My SCSI controller hangs when the
interrupt it shares with the network card is configured as edge triggered.
When I force the interrupt to be level triggered, everything works fine.
Does this sound like a problem in one of the two drivers (unable to share an
edge triggered interrupt) or is it a no-no to set up a shared PCI interrupt
as edge triggered?
If shared, edge triggered interrupts are ok then I will talk to the driver
maintainers about the problem. If this isn't ok, then maybe the sanity check
in pci-irq.c would be to force level triggering only on shared PCI
interrupts?
I'm going down this path because I can't see a good way to check for the
presence of a valid ELCR, so I'm hoping a PCI IRQ sanity check would fix my
problem (but someone please correct me if I'm wrong). Are SMP standard type
#5 machines (ISA/PCI) or just the Vectra's so rare that I'm the only one
having this problem? Or am I the only one to try putting a PCI card in one
of it's two slots... :-)
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
On Sun, 11 Mar 2001, John William wrote:
> If shared, edge triggered interrupts are ok then I will talk to the driver
> maintainers about the problem. If this isn't ok, then maybe the sanity check
> in pci-irq.c would be to force level triggering only on shared PCI
> interrupts?
DEFINITELY NO!
Given a PCI device + driver pair, level triggerred interrupt may be
required for them to work properly, even when the line is not shared.
Anyway, it is a requirement. OTOH, the PCI device must know how to
trigger the interrupt.
Edge triggerred interrupts cannot be shared. Level triggerred (level
sensitive is a better wording, in my opinion) can be shared.
Even when it is not shared (as it is required), an edge triggerred
interrupt can be lost by the driver. Using level sensitive interrupt let
the interrupt condition active as long as the condition is present at, at
least, one device that wants to interrupt the CPU.
Apart sharing of interrupt lines, level sensitive interrupt allows the
device firmware to run concurrently to the CPU (software driver) without
losing interrupt condition, providing that both driver and firmware use
appropriate barriers against buffering in the bridge.
In the same situation, using edge triggerred interrupt (not shared) can
lead to interrupt condition being lost by the software driver.
G?rard.