From owner-freebsd-hackers  Wed Jan 15 05:45:29 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id FAA02381
          for hackers-outgoing; Wed, 15 Jan 1997 05:45:29 -0800 (PST)
Received: from weenix.guru.org (unix.guru.org [198.82.200.65])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id FAA02353;
          Wed, 15 Jan 1997 05:44:41 -0800 (PST)
Received: (from kmitch@localhost)
          by weenix.guru.org (8.8.4/8.8.4)
	  id IAA00395; Wed, 15 Jan 1997 08:44:27 -0500 (EST)
From: Keith Mitchell <kmitch@weenix.guru.org>
Message-Id: <199701151344.IAA00395@weenix.guru.org>
Subject: Re: Adaptec 3940UW and SMP
In-Reply-To: <199701150505.WAA00551@clem.systemsix.com> from Steve Passe at "Jan 14, 97 10:05:20 pm"
To: smp@csn.net (Steve Passe)
Date: Wed, 15 Jan 1997 08:44:27 -0500 (EST)
Cc: hackers@freebsd.org, smp@freebsd.org
X-Mailer: ELM [version 2.4ME+ PL25 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> The "Freeing (NOT implimented) irq 9 for ISA cards." line is saying that
> since the APIC_IO code is using the CORRECT PCI irq 19 to service the de0
> card, it SHOULD be "undirecting" the ISA irq 9 from it.  The "NOT implimented"
> part notes the fact that this code hasn't been written yet (because its
> chipset dependant and I don't have all the info I need to support all
> the possible chipsets yet).  So we have a situation where the upper level
> PCI code knows that 2 distinct IRQs are being used for de0 and ahc1 (19 & 9)
> BUT the hardware is delivering INTs generated by the ahc1 via both the
> ahc1 vector (irq 9) AND the de0 vector (irq 19).  This could explain the
> missing INTs as well as the "sometimes" locks.
> 
> Test this theory by booting the APIC_IO SMP kernel with the de0 card removed
> from the system.  Note that with this card removed the BIOS will probably
> re-assign the PCI INTs, possibly causing de1 to provoke the same problem,
> remove it also for this test.

In my system, I have the on-board IDE stuff disabled.  I also have nothing
on IRQ 5.  Which leaves IRQs: 5, 14, and 15 totally unused.  I have them
marked for PCI/PNP use in my bios yet it still won't use them.

After discovering this, I removed one of the ethernet cards like you
suggested.  The result was it was still sharing (IRQ 10 this time).  It didn't
use IRQ 9 at all.  So then I removed the other ethernet card.  Now nothing
was sharing an IRQ but the kernel still failed in the same way (not passing
control over to init).