From owner-freebsd-hackers  Tue Jan 14 21:07:55 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id VAA06636
          for hackers-outgoing; Tue, 14 Jan 1997 21:07:55 -0800 (PST)
Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131])
          by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id VAA06100;
          Tue, 14 Jan 1997 21:05:33 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id WAA00551; Tue, 14 Jan 1997 22:05:20 -0700
Message-Id: <199701150505.WAA00551@clem.systemsix.com>
X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol
X-Mailer: exmh version 1.6.5 12/11/95
From: Steve Passe <smp@csn.net>
To: Keith Mitchell <kmitch@weenix.guru.org>
cc: hackers@freebsd.org, smp@freebsd.org
Subject: Re: Adaptec 3940UW and SMP 
In-reply-to: Your message of "Tue, 14 Jan 1997 20:10:58 EST."
             <199701150110.UAA00835@weenix.guru.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 14 Jan 1997 22:05:20 -0700
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Hi,

I have been looking over your data and saw something "not right".  In
the first mailing, ie the one with APIC_IO NOT enabled, I see:

de0 <Digital 21040 Ethernet> rev 35 int a irq 9 on pci0:17
 ...                                          ^^^^^
ahc1 <Adaptec 3940 Ultra SCSI host adapter> rev 0 int a irq 9 on pci1:5
                                                        ^^^^^

I know that generically PCI INTerrupts can be shared, but I didn't think
that they could when redirected via the ISA bus, but perhaps they can,
as this version appears to work.

Now in the second mailing, ie the one with APIC_IO enabled, I see:

de0 <Digital 21040 Ethernet> rev 35 int a irq 19 on pci0:17
Freeing (NOT implimented) irq 9 for ISA cards.
                          ^^^^^
 ...
ahc1 <Adaptec 3940 Ultra SCSI host adapter> rev 0 int a irq 9 on pci1:5
                                                        ^^^^^

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.

--
Steve Passe	| powered by
smp@csn.net	|            FreeBSD