From owner-freebsd-current Wed May 13 15:34:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA03916 for freebsd-current-outgoing; Wed, 13 May 1998 15:34:18 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA03706; Wed, 13 May 1998 15:33:55 -0700 (PDT) (envelope-from se@dialup124.zpr.uni-koeln.de) Received: from dialup124.zpr.Uni-Koeln.DE (dialup124.zpr.Uni-Koeln.DE [134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE (8.8.8/8.8.8) with ESMTP id AAA25885; Thu, 14 May 1998 00:33:05 +0200 (MET DST) Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.8.8/8.6.9) id XAA04452; Wed, 13 May 1998 23:22:35 +0200 (CEST) X-Face: " Date: Wed, 13 May 1998 23:22:33 +0200 From: Stefan Esser To: Stephen Roome , Terry Lambert Cc: David Greenman , freebsd-current@FreeBSD.ORG, Stefan Esser Subject: Re: Intel Etherexpress PRO/100+ PCI Mail-Followup-To: Stephen Roome , Terry Lambert , David Greenman , freebsd-current@FreeBSD.ORG, Stefan Esser References: <199805111740.KAA03878@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: ; from Stephen Roome on Tue, May 12, 1998 at 11:56:49AM +0100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1998-05-12 11:56 +0100, Stephen Roome 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 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 rev 0 on pci0:7:1 > mapreg[20] type=1 addr=0000f000 size=0010. > Primary IDE: enabled > Secondary IDE: enabled > de0 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