From owner-freebsd-current Mon May 11 11:00:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA18883 for freebsd-current-outgoing; Mon, 11 May 1998 11:00:30 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp04.primenet.com (daemon@smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA18809 for ; Mon, 11 May 1998 11:00:10 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id LAA16699; Mon, 11 May 1998 11:00:09 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpd016631; Mon May 11 11:00:05 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id KAA03878; Mon, 11 May 1998 10:40:53 -0700 (MST) From: Terry Lambert Message-Id: <199805111740.KAA03878@usr08.primenet.com> Subject: Re: Intel Etherexpress PRO/100+ PCI To: steve@visint.co.uk (Stephen Roome) Date: Mon, 11 May 1998 17:40:52 +0000 (GMT) Cc: tlambert@primenet.com, freebsd-current@FreeBSD.ORG In-Reply-To: from "Stephen Roome" at May 11, 98 10:08:55 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The second machine has a noise generator on the bus. You need to locate > > it. It may be a sound card without a driver byt with an open source. > > Ah, that would be this : > lpt0 at 0x378-0x37f irq 7 on isa > lpt0: Interrupt-driven port > > I'll turn it off from the BIOS next time I get a chance, although it's > been configured on the second machine all the time it was running SMP. This will not help. The problem is not the LPT port. Part of the original ISA design was to send any undesignated interrupts to IRQ 7. IRQ 7 is the "garbage" interrupt. Most likely, the board causing the problem is *NOT* on IRQ 7, and *NOT* on any of the IRQ's that have been claimed by any of the drivers. Specifically, look for hardware that FreeBSD doesn't have a driver for. I've often thought that all interrupts should be given a "stray IRQ" driver by default, to aid in identifying these problems. None of my hardware has this type of problem (I'm *very*, *very* picky), so I'm unable to test an implementation of this. The most likely culprit is a sound card with an open collector input and no microphone attached, or a microphone attached and turned on. The next most likely culprit is a video card that sends INT 2 on vertical retrace. In general, PCI interrupts are allocated by PCI, so it's probably an ISA device, whatever it is. > > I also notice that the interrupt is a shared PCI interrupt in both cases. > > > > You should try to do something about this for performance reasons as well, > > but this *may* be where the problem is lurking. At the very least, it's > > a suspicious "coincidence". > > How do I do something about this? (I Hope that's not too stupid a > question!) I don't know; I don't know because I don't know what slots you have the cards in, and what the motherboard wiring looks like, or how many slots it purports to understand. 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). If your ethernet throughput is in the toilet, but still seems to sort of work, or doesn't work at all, this is the problem. Generally, PCI traces are cascaded: S L O T 1 2 3 4 5 ,-. ,-. ,-. ,-. ,-. a--| |-----. ,---| |-----. ,---| |-----. ,---| |------------| | I | | '-/--. | | '-/--. | | '-/--. | | | | b--| |---. / `-| |---. / `-| |---. / `-| |------------| | N | | `-/-. | | `-/-. | | `-/-. | | | | c--| |-. / `----| |-. / `----| |-. / `----| |------------| | T | | `-/-. | | `-/-. | | `-/-. | | | | d--| |--' `------| |--' `------| |--' `------| |------------| | `-' `-' `-' `-' `-' Which is to say, if a card needs only a single interrupt, all PCI cards will get their own interrupts, except slot 5 (if it exists), which will share interrupts with slot 4 (and if it needs two, will also share with slot 1, which is why you avoid putting cards that need multiple interrupts in slot 4 or slot 5) It's unlikely that an SMP motherboard does not cascade the traces. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message