Date: Wed, 13 May 1998 23:22:33 +0200 From: Stefan Esser <se@FreeBSD.ORG> To: Stephen Roome <steve@visint.co.uk>, Terry Lambert <tlambert@primenet.com> Cc: David Greenman <dg@root.com>, freebsd-current@FreeBSD.ORG, Stefan Esser <se@FreeBSD.ORG> Subject: Re: Intel Etherexpress PRO/100+ PCI Message-ID: <19980513232233.49213@mi.uni-koeln.de> In-Reply-To: <Pine.BSF.3.96.980512102848.18433C-100000@dylan.visint.co.uk>; from Stephen Roome on Tue, May 12, 1998 at 11:56:49AM %2B0100 References: <199805111740.KAA03878@usr08.primenet.com> <Pine.BSF.3.96.980512102848.18433C-100000@dylan.visint.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1998-05-12 11:56 +0100, Stephen Roome <steve@visint.co.uk> wrote:
> On Mon, 11 May 1998, Terry Lambert wrote:
> % I find it unlikely that they are both on INT a. This may be a bug in
> % the probe routines, or in your motherboard BIOS. It could also account
> % for the start IRQ (say one was on 'INT b', but it wasn't seen).
>
> I think this is possibly probe related, although I can't be sure, but I've
> just checked another six machines none of which use are probed as using
> anything but int A.
>
> Which is really unlikely! Especially machines like this:
>
> chip1 <Intel 82371SB PCI-ISA bridge> rev 1 on pci0:7:0
> I/O Recovery Timing: 8-bit 3 clocks, 16-bit 2 clocks
> Extended BIOS: enabled
> Lower BIOS: enabled
> Coprocessor IRQ13: enabled
> Mouse IRQ12: disabled
> Interrupt Routing: A: disabled, B: IRQ11, C: IRQ10, D: IRQ9
> ^^^^^^^^^
Those A, B, C, D are chip-set pins, which are not directly
related to PCI interrupt names!
Terry sent a *very* nice line graphic, that shows how PCI
wires interrupts between neighbour slots:
% Generally, PCI traces are cascaded:
%
% S L O T
% 1 2 3 4 5
% ,-. ,-. ,-. ,-. ,-.
% a--| |-----. ,---| |-----. ,---| |-----. ,---| |------------| |
% I | | '-/--. | | '-/--. | | '-/--. | | | |
% b--| |---. / `-| |---. / `-| |---. / `-| |------------| |
% N | | `-/-. | | `-/-. | | `-/-. | | | |
% c--| |-. / `----| |-. / `----| |-. / `----| |------------| |
% T | | `-/-. | | `-/-. | | `-/-. | | | |
% d--| |--' `------| |--' `------| |--' `------| |------------| |
% `-' `-' `-' `-' `-'
There is no way to know which of pin A, B, C, D is connected
to PCI interrupt a, b, c, d at slot 1 in above drawing, and
you don't know, whether int a of slot 1 is connected to int b
of slot 2 (as drawn) or int a of slot 2 to int b of slot 1
(which would make the drawing look upside down). Both ways
are permitted, as are many more, including individual pins
for each interrupt pin of each slot (but that doesn't work
well in a PC compatible for backwards compatibility reasons).
The knowledge about the interrupt traces on your motherboard
is coded into the PCI BIOS, which writes the IRQ numbers assigned
to the chip-set pins into the devices' interrupt line registers
(where the device driver finds it and sets up the handler ...).
> MB0: IRQ15, MB1:
> chip2 <Intel 82371SB IDE interface> rev 0 on pci0:7:1
> mapreg[20] type=1 addr=0000f000 size=0010.
> Primary IDE: enabled
> Secondary IDE: enabled
> de0 <Digital 21140A Fast Ethernet> rev 32 int a irq 11 on pci0:10
> ^^^^^^^^^^^^
> That looks wrong to me, shouldn't that de0 be on int b ?
No. It just tells you, that chip-set pin B is wired to the PCI
interrupt trace which is connected to PCI IntA on the connector
that got a slot ID of 10 in config space.
> I moved everything around as you suggest, but everything always comes up
> as int A in the card probe, if what you say is true then it looks like
> it's got to be the probe code, in more than one version.
Yes, it's always interrupt pin a, since this is the way PCI
interrupts are specified!
A single function device (e.g. the DEC Ethernet chip) is not
allowed to use any interrupt other than "a".
If there is a PCI bridge on a PCI card, then each "slot"
number behind the bridge got its interrupt pins connected to
the interrupt pins on the primary side in a similar way as
shown for the motherboard, above. Just that there is only
one way to interconnect interrupt pins in that case, since
the systems PCI BIOS couldn't possibly know about how the
interrupt traces are connected to devices behind the bridge,
else ...
Regards, STefan
PS: I don't know, what your original problem was (have not
been able to read mail for several days and have a back
log of more than 1000 messages ...).
Let me know if you think there is something wrong with
the PCI code.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980513232233.49213>