Incorrect IRQ mappings by PCI BIOS'es?

Incorrect IRQ mappings by PCI BIOS'es?

Post by Kendall Benne » Tue, 06 Apr 1999 04:00:00



Hi All,

I just had a really strange problem when I plugged two different graphics
controllers into my system. Normally when I plug a single controller into
my system, if the PCI device requests an IRQ line it usually gets IRQ 9.
Now this caused me problems in the past in our 32-bit DOS test harness,
because of the funky PC-AT backwards compatibility handling of IRQ 9 by
the system BIOS. For some reason the system boots up with this IRQ
*unmasked*, which means that if I do stuff that causes an IRQ to be
triggered by the card (such as triple buffering) it will lock the system
because no-one is there to handle the IRQ. Under Linux this does not
happen, because Linux is nice about this stuff ;-)

Now to solve the first problem under DOS, I check to see if the IRQ line
is allocated for my controller, and until I need to install an interrupt
handler for it I mask it in the PIC so that it will be ignored.

Now the second problem happens when I plug a second card into my system
(an AGP 2x Intel 440BX PII system with an Award BIOS). For some reason
the PnP BIOS gives the disabled card IRQ 9, but then gives the active
card IRQ 3 which has *already* been alloted to the network controller
(and strangely enough the USB controller)! Since there are now 3 PCI
devices all configured to use the same IRQ, all hell breaks loose.

So I can fix this by re-assigning the IRQ (actually I will probably just
disable it by setting it to 0), but it seemse ridiculous to me that the
BIOS would assign the same IRQ to three separate PCI devices. Not to
mention that USB support would probably barf if the network controller is
already on IRQ 3. I am assuming this is a bug; has anyone else seen this
anomolous behaviour? Does anyone know if the Linux kernel re-assigns
IRQ's at bootup to get around this problem?

Regards,

--

+----------------------------------------------------------------------+
|      SciTech Software - Building Truly Plug'n'Play Software!         |
+----------------------------------------------------------------------+
| Kendall Bennett          | To reply via email, remove nospam from    |
| Director of Engineering  | the reply to email address. Do NOT send   |
| SciTech Software, Inc.   | unsolicited commercial email!             |
| 505 Wall Street          | ftp  : ftp.scitechsoft.com                |
| Chico, CA 95928, USA     | www  : http://www.scitechsoft.com         |
+----------------------------------------------------------------------+

 
 
 

Incorrect IRQ mappings by PCI BIOS'es?

Post by Peter Samuels » Thu, 08 Apr 1999 04:00:00



Quote:> So I can fix this by re-assigning the IRQ (actually I will probably
> just disable it by setting it to 0), but it seemse ridiculous to me
> that the BIOS would assign the same IRQ to three separate PCI
> devices.

The PCI spec allows IRQ sharing, and the Linux kernel supports this.
Each relevent driver IRQ handler just has to take the trouble to check
to make sure the interrupt is from the right device, and if not, to
ignore it (the kernel will then call the next handler in the chain).
Which means some drivers might have buggy handling for shared IRQs but
basically the kernel infrastructure is in place and working.

Whether it's a BIOS bug or not I don't know.  Maybe Award had a reason
to want to do it this way.  In any case it's within spec.

--
Peter Samuelson
<sampo.creighton.edu!psamuels>

 
 
 

Incorrect IRQ mappings by PCI BIOS'es?

Post by Dale Shuttlewor » Thu, 08 Apr 1999 04:00:00


Hi,

[...]

: Now the second problem happens when I plug a second card into my system
: (an AGP 2x Intel 440BX PII system with an Award BIOS). For some reason
: the PnP BIOS gives the disabled card IRQ 9, but then gives the active
: card IRQ 3 which has *already* been alloted to the network controller
: (and strangely enough the USB controller)! Since there are now 3 PCI
: devices all configured to use the same IRQ, all hell breaks loose.

[...]

Why does all hell break loose?  PCI is designed to to allow interrupts
to be shared.  With correctly written software all PCI devices could
be on a single interrupt with no problems.  I've used machines with
graphics, SCSI and WinTV cards all on the same interrupt.

Windows 95 and up seems to correctly handle multiple PCI devices on a
single interrupt.  I am not so sure about Linux, I know that there
are a number of restrictions on sharing in 2.0 and I know that these
have changed in 2.2, but I haven't got round to investigating 2.2
sufficiently to determine how they have changed.

: So I can fix this by re-assigning the IRQ (actually I will probably just
: disable it by setting it to 0), but it seemse ridiculous to me that the
: BIOS would assign the same IRQ to three separate PCI devices. Not to
: mention that USB support would probably barf if the network controller is
: already on IRQ 3. I am assuming this is a bug; has anyone else seen this
: anomolous behaviour? Does anyone know if the Linux kernel re-assigns
: IRQ's at bootup to get around this problem?

Some BIOSs allow the IRQ allocation strategy to be set in their
setup options.  If your BIOS doesn't, it is possible through other
means since Win95 OSR2 and up allow you to do it.  I assume that OSR2
does this through some BIOS PCI configuration routines or by playing
with the PCI bus directly.

                Dale.
--
**************************************************************************
*  Dale Shuttleworth                                                     *

**************************************************************************

 
 
 

Incorrect IRQ mappings by PCI BIOS'es?

Post by David Groth » Thu, 08 Apr 1999 04:00:00



> <big snip>
> Now the second problem happens when I plug a second card into my system
> (an AGP 2x Intel 440BX PII system with an Award BIOS). For some reason
> the PnP BIOS gives the disabled card IRQ 9, but then gives the active
> card IRQ 3 which has *already* been alloted to the network controller
> (and strangely enough the USB controller)! Since there are now 3 PCI
> devices all configured to use the same IRQ, all hell breaks loose.

Be aware that PCI IRQs tend to be level triggered rather than edge
triggered.  If you somehow fail to make your adapter withdraw its interrupt
request you will get hit with another interrupt entry just as soon as the
kernel dismisses this interrupt.  Dunno if that's your problem, but it's
something to watch out for.
-- Dave