Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 Nov 1996 14:04:52 -0700
From:      Steve Passe <smp@csn.net>
To:        "J.M. Chuang" <smp@bluenose.na.tuns.ca>
Cc:        smp@freebsd.org
Subject:   Re: Tyan Tomcat III (S1563D) 
Message-ID:  <199611192104.OAA19927@clem.systemsix.com>
In-Reply-To: Your message of "Mon, 18 Nov 1996 09:37:31 -0400." <199611181337.JAA15924@bluenose.na.tuns.ca> 

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

I think we have a new class of "not connected" INTs for the IO APIC.
Jim Chuang was testing the APIC_IO option to the SMP kernel (thanx Jim),
and found the following problem:

---
> Jim wrote:
>>> >wd0: interrupt timeout:
>>> >wd0: status 58 <rdy, seekdone, drq> erro 0
>>> ...

---
> I (smp) replied:
>I guess I need to look at the chipsets to see how the IDE INTs are routed.
>Since these are on a motherboard chipset, they might now get "off the chip"
>and thus are not available to route to the APIC chip.  This is a common
>problem with EISA chipsets and the system timer, as both timer and 8259 ICUs
>are on the same chip, and they didn't think there would ever be a need
>to bring the line off the chip.
>
>--
>thanx for replying, I will get back to you when I have thought it over
>a bit...

---
so I looked at the chipset, specifically the 82371SB (aka PIIX3) and am
currently of the opinion that the chip directly routes interrupts from the IDE
controller core to INTs 14/15 on the 8259 core.  The datasheet
lists INTs 14/15 as INPUTS ONLY, and I cannot find any other pin on the
chip that would bring IDE INTs off-chip.  If I am correct this means that
the IO APIC (which is on a separate piece of silicon) cannot service
IDE INTs with this hardware.

This chip is used in both the Natoma and Triton-II (Triton-I?) chip sets.
Whether this affects other sets like Neptune is unknown to me at this point,
but I would guess it does.

The implication of this is that we will probably never support IDE drives
in the SMP kernel with APIC_IO mode enabled on these chipsets.
"mixed-mode" programming might be possible, but IMHO, would BLOW CHUNKS!

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

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2

mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE
04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX
WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR
tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+
=ds99
-----END PGP PUBLIC KEY BLOCK-----





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