Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 14 Jan 1997 22:05:20 -0700
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 
Message-ID:  <199701150505.WAA00551@clem.systemsix.com>
In-Reply-To: Your message of "Tue, 14 Jan 1997 20:10:58 EST." <199701150110.UAA00835@weenix.guru.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701150505.WAA00551>