Date: Wed, 03 Sep 1997 00:47:44 -0600 From: Steve Passe <smp@csn.net> To: Simon Shapiro <Shimon@i-connect.net> Cc: mef@cs.washington.edu, FreeBSD-SMP@FreeBSD.ORG Subject: Re: Open Issues on P6DNH Message-ID: <199709030647.AAA03305@Ilsa.StevesCafe.com> In-Reply-To: Your message of "Tue, 02 Sep 1997 22:57:50 PDT." <XFMail.970902225750.Shimon@i-Connect.Net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
> According to the expert on this matters at SuperMicro, this exactly how it
> should be when you have more than one PCI bus.
there are 2 things wrong with that theory:
1st, with 2 busses you could have at most 2 duplicates, NOT 3.
2nd, there is a bus field to distinguish the PCI device:int pair on each bus.
re-examine the HP table (an example I claim is correct),
sorted by PCI device:int. Note that this shows 2 PCI busses, but NEVER more
than 2 of any one device:int, and that NO pair ever claims to use the same
APIC pin. NOR do both members of a pair exist on the same bus PCI bus:
INT active-hi level 0 11:A 13 0
INT active-hi level 0 11:B 13 5
INT active-hi level 0 11:C 13 6
INT active-hi level 0 11:D 13 7
INT active-hi level 0 12:A 13 1
INT active-hi level 1 12:A 13 3
INT active-hi level 0 12:B 13 7
INT active-hi level 1 12:B 13 5
INT active-hi level 0 12:C 13 5
INT active-hi level 1 12:C 13 6
INT active-hi level 0 12:D 13 6
INT active-hi level 1 12:D 13 7
INT active-hi level 0 13:A 13 2
INT active-hi level 1 13:A 13 12
INT active-hi level 0 13:B 13 6
INT active-hi level 0 13:C 13 7
INT active-hi level 0 13:D 13 5
INT active-hi level 1 14:A 13 13
INT active-hi level 1 15:A 13 4
INT active-hi level 1 15:B 13 7
INT active-hi level 1 15:C 13 5
INT active-hi level 1 15:D 13 6
while the P6DNH sorted shows the same device:int connected to 3 different
APIC pins in six different cases:
INT active-lo level 1 0:A 2 16
INT active-lo level 1 0:A 2 18
INT active-lo level 1 0:A 2 19
INT active-lo level 1 1:A 2 16
INT active-lo level 1 1:A 2 18
INT active-lo level 1 1:A 2 19
INT active-lo level 0 16:A 2 16
INT active-lo level 0 16:A 2 18
INT active-lo level 0 16:A 2 19
INT active-lo level 0 17:A 2 16
INT active-lo level 0 17:A 2 18
INT active-lo level 0 17:A 2 19
INT active-lo level 0 18:A 2 17
INT active-lo level 0 19:A 2 16
INT active-lo level 0 19:A 2 18
INT active-lo level 0 19:A 2 19
INT active-lo level 0 20:A 2 16
INT active-lo level 0 20:A 2 18
INT active-lo level 0 20:A 2 19
In summary, they are failing to distinguish the PCI int pin, ie A,B,C,D
---
> With no ofense to anyone,
> in declining order of probability, here is my BELIEF:
>
> a. SuperMicro is mistaken
> b. SuperMicro is ``plastering our eyes'' with nonsense as they try to get
> out of something they have no clue about.
> c. Steve is wrong.
any one or more of these is possible, I would assign the same order to the
possibilities.
---
> Why does it work with NT? Probably, the NT driver does some sort of ``if
> board_id == p6dnh then reverse these pins.
MP Config Table Header:
OEM ID: 'INTEL '
Product ID: '440FX '
what board id, supermicro didn't even bother to replace the generic id
tags with something product specific, and I'm supposed to believe the
rest of the table?
Even if they did, it all falls apart when you start to plug in bridged PCI
cards. Knowing the motherboard make & model is of no help then. Remember
a bridged PCI card is yet another PCI bus!
---
> Should we do that too?
>
> Being true to my heritage, I will anser a question with a question:
>
> Do we want to be right about it or do we want it to work?
Both, in that order! The problem is that M$ doesn't even have to go out
and buy one of every board made, every manufacturer sends M$ as many as
M$ wants if they want the board qualified. So M$ can program around
these sorts of problems as they have the hardware to test. (actually I dont
think M$ even messes with NT at that level, the OEM has to do the HAL code
themselves if I remember correctly.)
I don't have the luxury of access to 1 of everything, my ONLY defense is
to insist that the manufacturers adhere to the published standards.
--
Steve Passe | powered by
smp@csn.net | Symmetric MultiProcessor FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709030647.AAA03305>