Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 Jan 1997 16:12:37 -0700
From:      Steve Passe <smp@csn.net>
To:        Terry Lambert <terry@lambert.org>
Cc:        smp@freebsd.org
Subject:   Re: Adaptec 3940UW and SMP 
Message-ID:  <199701182312.QAA29399@clem.systemsix.com>
In-Reply-To: Your message of "Sat, 18 Jan 1997 13:04:04 MST." <199701182004.NAA12315@phaeton.artisoft.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,

>PCI interrupt sharing is (apparently) not corectly supported by the
>APIC I/O.  This should be corrected, since non-SMP systems with APIC's
>should probably be running APIC I/O anyway.

I believe the problem here is the one I documented earlier as:

> PnP board failure
>
>PnP boards can cause problems as I have not yet implimented code to "undirect"
>PCI INTs when sent to the APIC.  Since an upper ( >15 ) INT is registered
>in place of the original ( <=15 ) the original may be assigned later by
>a PnP card.  BUT the lower INT line is NOT un-redirected.
>This means both the PCI hardware (via the redirect hardware) AND the PnP
>card are yanking on the same lower INT line, causing random problems.
>
>solution:
>
>disable the PnP aspects of a board, use the BIOS "legacy ISA" settings.

---
Note his following test:

>	The BIOS printout confirmed that the interrupts were assigned as
>follows:
>
>Slot 1: SMC 10/100       (IRQ 11)
                          ^^^^^^^
>Slot 4: Adaptec 3940UW   (IRQ 14 for channel 1, IRQ 11 for channel 2)
                                                 ^^^^^^
>Slot 5: Matrox Millenium (IRQ 14)
>
>	And with MP spec v1.4 enabled in the BIOS, I got the following
>results:
>
>Uniprocessor:    works fine
>Non-APIC_IO SMP: works fine
>APIC_IO SMP:     works fine

APIC PCI INTerrupt sharing is working on the PCI bus. 
One genuine problem is when an ISA card trys to re-cycle the unused (but
STILL redirected) PCI INT.
Another is that the info contained in SOME spec 1.1 MP tables is incorrect
is a few unique cases (bridged chips, multiple PCI busses) causing the APIC
to be misprogrammed.

The general solutions are known, its just a matter of finding the
time to impliment them!

--
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?199701182312.QAA29399>