From owner-freebsd-current Tue May 12 03:57:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA12174 for freebsd-current-outgoing; Tue, 12 May 1998 03:57:39 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from mail.visint.co.uk (wakko.visint.co.uk [194.207.134.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA12167 for ; Tue, 12 May 1998 03:57:36 -0700 (PDT) (envelope-from steve@visint.co.uk) Received: from dylan.visint.co.uk (dylan.visint.co.uk [194.207.134.180]) by mail.visint.co.uk (8.8.8/8.8.5) with SMTP id LAA03459; Tue, 12 May 1998 11:57:35 +0100 (BST) Date: Tue, 12 May 1998 11:56:49 +0100 (BST) From: Stephen Roome Reply-To: Stephen Roome To: Terry Lambert cc: David Greenman , freebsd-current@FreeBSD.ORG Subject: Re: Intel Etherexpress PRO/100+ PCI In-Reply-To: <199805111740.KAA03878@usr08.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 11 May 1998, David Greenman wrote: > Due to the design of the interrupt system on PC machines, stray irq 7's > can occur when any irq is asserted and then removed before it is > properly ACKed. I was under the (wrong?) impression that that would only be IRQ's less than 7 ? Anyway, I did have an ISA NE2000 card in the machine, which I removed, but that didn't solve the problem and was on IRQ 10 anyway. I've now turned on the COM/LPT ports from the BIOS, as the BIOS doesn't turn them off (does it just ignore them ? would be nice if the BIOS would disable the COM ports if you turn them off from the BIOS!) That seems to have cleared up the stray IRQ problem. (I can't beleive it was just that simple.) 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 ^^^^^^^^^ 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 ? (I've got more machines that tell me this as well.) 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. Many thanks for the help, and apologies for combining replies, saves me spamming the lists though. Steve Steve Roome - Vision Interactive Ltd. Tel:+44(0)117 9730597 Home:+44(0)976 241342 WWW: http://dylan.visint.co.uk/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message