Re: something strange - is it p2x4?

Colin Coe (coec@justice.moj.wa.gov.au)
Tue, 21 Apr 1998 21:05:44 +0800


I am no expert, however, I believe that the first PCI device found by the
BIOS is *always* IRQ 9, the second PCI device IRQ is dependant on whether
IRQ 10 is being used by an ISA or EISA device.

This is from my limited understanding...

CC

-----Original Message-----
From: Doug Ledford <dledford@dialnet.net>
To: Neal Becker <neal@ctd.comsat.com>
Cc: linux-kernel@vger.rutgers.edu <linux-kernel@vger.rutgers.edu>
Date: Tuesday, 21 April 1998 20:52
Subject: Re: something strange - is it p2x4?

>Neal Becker wrote:
>>
>> I have an Intel AL440LX board. I have an AHA2940UW pci card. No
>> matter what slot I plug the AHA2940 into, /proc/pci says it's INT9.
>>
>> The Intel doc on the AL440LX board says that the interrupt line will
>> vary with the slot, from INTA - INTD. It says the p2x4 PCI/ISA chip
>> will map INTA-INTD to various interrupts. I have NO interrupts
>> reserved for ISA. I have NO other PCI cards. I have one AGP video
>> card, which also reports it's on INT9 (which is the reason I have a
>> problem).
>>
>> What sets up the mapping of PCI interrupts to INT1-15? I understand
>> it's handled by the P2X4 chip. Is this strictly a bios function, or
>> does the linux P2X4 driver set this up?
>>
>> Stranger still, if I stop the boot process when prompted by the
>> AHA2940 bios and view the config, it claims it's using INT11. Did
>> linux change it when it booted? Is /proc/pci lying?
>>
>> This is 2.1.96 BTW.
>
>Actually, from what I can tell so far, this isn't an isolated case. It
>appears to be related to the switch over from pcibios_* function usage to
>the newer pci_* functions. In the past, we could reliably read the irq
>value for the card from the pcibios config space by reading the
>PCI_CONFIG_IRQLINE area (I think that's the right mnemonic). Now, in
2.1.96
>and above, we instead get the irq value from the pdev->irq structure value.
>If that value isn't right (and it appears to not be right on certain
>machines, such as this) then we don't get any interrupts and the system
ends
>up hanging, or going into a timeout/reset loop. I would guess that the
>actual PCI BIOS areas and the PCI CONFIG areas are disagreeing on what the
>IRQ is, and that's causing the problem, but I'm not a PCI expert, so I
would
>defer the actual determination to Martin Mares. Any comments on this
>Martin?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu