prep interrupt routing

prep interrupt routing

[David Monro]

Hi,

I've had my suspicions for a little while that all is not quite right
with the kernel interrupt routing for the IBM 850, caused by the
behaviour of my SCSI controller (the ncr53c8xx driver ended up in a loop
which looked exactly like what happens on an intel PC when the interrupt
routing is wrong). Looks like I'm right. Dumping the residual data on my
850 shows that all PCI interrupts are mapped to IRQ 15:

Integrated PCI device DevFunc 0x58 interrupt line(s)  routed to 8259
line(s) 8259
Integrated PCI device DevFunc 0x60 interrupt line(s) A routed to 8259
line(s) 15(L)
Integrated PCI device DevFunc 0x70 interrupt line(s) A routed to 8259
line(s) 15(L)
Integrated PCI device DevFunc 0x80 interrupt line(s) A routed to 8259
line(s) 15(L)
PCI Slot 1 DevFunc 0xb0 interrupt line(s) A/B/C/D routed to 8259 line(s)
15(L)/15(L)/15(L)/15(L)
PCI Slot 2 DevFunc 0x90 interrupt line(s) A/B/C/D routed to 8259 line(s)
15(L)/15(L)/15(L)/15(L)

DevFunc 0x58 is dev 0xb0, the Fire Coral ISA bridge, with no interrupts.
DevFunc 0x60 is dev 0xc0, the onboard ethernet.
DevFunc 0x70 is dev 0xe0, the onboard video.
DevFunc 0x80 is dev 0x10, which I don't have but would be onboard SCSI
on a 7248.
DevFunc 0xb0 is def 0x16, which is an ncr53c825 SCSI card.
DevFunc 0x90 is dev 0x12, which is currently a GXT-150P graphics board.

Forcing the interrupt line to be 15 for all PCI devices (by hacking
prep_pci.c) means that my SCSI host adapter is now detected and
initialized correctly.

Of course putting all of the devices on irq 15 doesn't seem like a
particularly good idea. Does anybody know a) which chip is responsible
for the mapping and b) how to reprogram it?

Cheers,

	David

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: prep interrupt routing

[Gabriel Paubert]

On Fri, 14 Apr 2000, David Monro wrote:

> I've had my suspicions for a little while that all is not quite right
> with the kernel interrupt routing for the IBM 850, caused by the
> behaviour of my SCSI controller (the ncr53c8xx driver ended up in a loop
> which looked exactly like what happens on an intel PC when the interrupt
> routing is wrong). Looks like I'm right. Dumping the residual data on my
> 850 shows that all PCI interrupts are mapped to IRQ 15:
>
> Integrated PCI device DevFunc 0x58 interrupt line(s)  routed to 8259
> line(s) 8259
> Integrated PCI device DevFunc 0x60 interrupt line(s) A routed to 8259
> line(s) 15(L)
> Integrated PCI device DevFunc 0x70 interrupt line(s) A routed to 8259
> line(s) 15(L)
> Integrated PCI device DevFunc 0x80 interrupt line(s) A routed to 8259
> line(s) 15(L)
> PCI Slot 1 DevFunc 0xb0 interrupt line(s) A/B/C/D routed to 8259 line(s)
> 15(L)/15(L)/15(L)/15(L)
> PCI Slot 2 DevFunc 0x90 interrupt line(s) A/B/C/D routed to 8259 line(s)
> 15(L)/15(L)/15(L)/15(L)

It looks like the output of my residual data dump code :-), and the first
line shows a bug in my code (harmless, but then I had never found residual
data which specifies that a device has no interrupt lines).

>
> DevFunc 0x58 is dev 0xb0, the Fire Coral ISA bridge, with no interrupts.
> DevFunc 0x60 is dev 0xc0, the onboard ethernet.
> DevFunc 0x70 is dev 0xe0, the onboard video.
> DevFunc 0x80 is dev 0x10, which I don't have but would be onboard SCSI
> on a 7248.
> DevFunc 0xb0 is def 0x16, which is an ncr53c825 SCSI card.
> DevFunc 0x90 is dev 0x12, which is currently a GXT-150P graphics board.
>
> Forcing the interrupt line to be 15 for all PCI devices (by hacking
> prep_pci.c) means that my SCSI host adapter is now detected and
> initialized correctly.

Good...

>
> Of course putting all of the devices on irq 15 doesn't seem like a
> particularly good idea. Does anybody know a) which chip is responsible
> for the mapping and b) how to reprogram it?

The chip is often the PCI<->ISA bridge which has registers to route PCI
interrupts to specific 8259 inputs. But I dno't know have the spec of your
PCI/ISA bridge at hand. For example a WinBond 83c553F has 4 inputs for PCI
interrupts which are routed to specific 8259 inputs by a 16 bit
configuration space register in which each hex nibble determines the
routing of one of the PCI interrupt inputs.

Intel chipsets often have a 32 bit register with one byte for each
interrupt line (but the high order nibble is stuck at zero).

It is still possible that your ISA bridge has only one input pin for PCI
interrupts and that its routing hardwired to IRQ 15. Actually I suspect
that this is the case. Just try lspci -xxxsb.0:

[root@vlab1 linux-test]# lspci -xxxsb.0
00:0b.0 ISA bridge: Symphony Labs W83C553 (rev 04)
[snipped]
40: 24 04 00 00 ef ab 78 00 f1 00 00 00 00 33 04 00
                ^^^^^
Or 0xabef in right byte order: meaning routing to IRQs 10/11/14/15,
although I don't use these any more since the board has an OpenPIC (but
PPCBUUG disagnostics would be very upset if I changed it).

	Regards,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: prep interrupt routing

[David Monro]

Gabriel Paubert wrote:
>
> On Fri, 14 Apr 2000, David Monro wrote:
>
[..]
> It looks like the output of my residual data dump code :-), and the first
> line shows a bug in my code (harmless, but then I had never found residual
> data which specifies that a device has no interrupt lines).

Yup; I found the commented out call to print_residual_device_info() in
prep_setup.c

>
> >
[..]
>
> Good...
>
> >
> > Of course putting all of the devices on irq 15 doesn't seem like a
> > particularly good idea. Does anybody know a) which chip is responsible
> > for the mapping and b) how to reprogram it?
>
[..]

The PCI-ISA bridge is the "IBM Fire Coral" chip - does anybody actually
have a part number for this chip so I can look it up on IBM's site?
>
> [root@vlab1 linux-test]# lspci -xxxsb.0
> 00:0b.0 ISA bridge: Symphony Labs W83C553 (rev 04)
> [snipped]
> 40: 24 04 00 00 ef ab 78 00 f1 00 00 00 00 33 04 00
>                 ^^^^^
> Or 0xabef in right byte order: meaning routing to IRQs 10/11/14/15,
> although I don't use these any more since the board has an OpenPIC (but
> PPCBUUG disagnostics would be very upset if I changed it).
>
>         Regards,
>         Gabriel.

Output from the above command:
prozac:~# lspci -xxxsb.0
00:0b.0 ISA bridge: IBM Fire Coral (rev 02)
00: 14 10 0a 00 07 00 00 04 02 00 01 06 00 00 00 00
10: 01 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

I have no idea what any of this means :-) If I could find the IBM
datasheet I might have half a clue though.

Cheers,

	David

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: prep interrupt routing

[Gabriel Paubert]

> The PCI-ISA bridge is the "IBM Fire Coral" chip - does anybody actually
> have a part number for this chip so I can look it up on IBM's site?

Open your box and look at the chip ?

> Output from the above command:
> prozac:~# lspci -xxxsb.0
> 00:0b.0 ISA bridge: IBM Fire Coral (rev 02)
> 00: 14 10 0a 00 07 00 00 04 02 00 01 06 00 00 00 00
> 10: 01 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00

Standard header, not much to say except for the 0xff which looks crazy.

> 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 50: 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Only one non zero bit in the whole device specific area. It does not look
like you can do much about interrupt routing if it's similar to
WinBond and Intel bridges.

	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/