NT 4 vs. PCI vs. DELL Precision 420

I have a PCI device with an NT 4.0 device driver. The driver generally
works fine, but I’m having trouble with some systems not succeeding
the HalTranslateBusAddress:

/* Get the address of the I/O registers for the device. The
target specific code uses this values to access its
registers with the readl and writel macros. */
{
BOOLEAN rc;
unsigned tmp = 0;
PHYSICAL_ADDRESS addr, scr;
addr.LowPart = config.u.type0.BaseAddresses[0] & ~0xf;
addr.HighPart = 0;

rc = HalTranslateBusAddress(PCIBus, bus_no, addr, &tmp, &scr);
[…]

For some reason, HalTranslateBusAddress is returning FALSE on DELL
Precision 420 systems. The system has lots of PCI-to-PCI bridges,
with the BIOS placing my board on bus 3. I look with PCIVIEW and I
see that the resources are allocated on the PCI bus reasonably (the
BIOS is doing its job) but the HalTranslateBusAddress simply doesn’t
work.

HalGetBusData and HalGetInterruptVector seem to work just fine.

I have an NT5 (Sorry, “Windows 2000”) driver in the works that will
get all its resources via the PnP monster, but I would still like to
get past this problem in the short term.


Steve Williams “The woods are lovely, dark and deep.
xxxxx@icarus.com But I have promises to keep,
xxxxx@picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Did you pass the DeviceObject as the 4th parameter to
HalAssignSlotResources()? While this is “optional” under NT4, it is
required under W2K - much time lost on that one! Perhaps this has some
bearing on your problem; I also have a 420.

Bill Casey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Stephen Williams
Sent: Tuesday, April 24, 2001 12:26 PM
To: NT Developers Interest List
Subject: [ntdev] NT 4 vs. PCI vs. DELL Precision 420

I have a PCI device with an NT 4.0 device driver. The driver generally
works fine, but I’m having trouble with some systems not succeeding
the HalTranslateBusAddress:

/* Get the address of the I/O registers for the device. The
target specific code uses this values to access its
registers with the readl and writel macros. */
{
BOOLEAN rc;
unsigned tmp = 0;
PHYSICAL_ADDRESS addr, scr;
addr.LowPart = config.u.type0.BaseAddresses[0] & ~0xf;
addr.HighPart = 0;

rc = HalTranslateBusAddress(PCIBus, bus_no, addr, &tmp, &scr);
[…]

For some reason, HalTranslateBusAddress is returning FALSE on DELL
Precision 420 systems. The system has lots of PCI-to-PCI bridges,
with the BIOS placing my board on bus 3. I look with PCIVIEW and I
see that the resources are allocated on the PCI bus reasonably (the
BIOS is doing its job) but the HalTranslateBusAddress simply doesn’t
work.

HalGetBusData and HalGetInterruptVector seem to work just fine.

I have an NT5 (Sorry, “Windows 2000”) driver in the works that will
get all its resources via the PnP monster, but I would still like to
get past this problem in the short term.


Steve Williams “The woods are lovely, dark and deep.
xxxxx@icarus.com But I have promises to keep,
xxxxx@picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”


You are currently subscribed to ntdev as: xxxxx@advstor.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

xxxxx@advstor.com said:

Did you pass the DeviceObject as the 4th parameter to
HalAssignSlotResources()? While this is “optional” under NT4, it is
required under W2K - much time lost on that one!

This is an NT4 driver.

My fix may be to go to NT5 (where all the resource assignment is
handled completely differently) but I’m curious why on NT4 the
HalTranslateBusAddress doesn’t work when given the PCI bus number
and the bus address pulled from the BAR.

Steve Williams “The woods are lovely, dark and deep.
xxxxx@icarus.com But I have promises to keep,
xxxxx@picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

I think he was suggesting to supply the DeviceObject even though it is
optional. As it happens, I have a customers Dell Precision 420 with
NT4 loaded right here. My driver has the same problem on this box.
As it also happens I call Hal assignSlotResources using the optional
parameter:
funcStatus = HalAssignSlotResources(
RegistryPath,
NULL,
pDriverObject,
pDeviceObject, /* optional */
PCIBus,
pDeviceExtension->hwInfo.busNumber,
pDeviceExtension->hwInfo.slotNumber.u.AsULONG,
&pFGResources );

If you find an answer to this problem, I’d love to hear about it.

Greg

On Tue, 24 Apr 2001 11:50:54 -0700, Stephen Williams
wrote:

>
>
>xxxxx@advstor.com said:
>> Did you pass the DeviceObject as the 4th parameter to
>> HalAssignSlotResources()? While this is “optional” under NT4, it is
>> required under W2K - much time lost on that one!
>
>This is an NT4 driver.
>
>My fix may be to go to NT5 (where all the resource assignment is
>handled completely differently) but I’m curious why on NT4 the
>HalTranslateBusAddress doesn’t work when given the PCI bus number
>and the bus address pulled from the BAR.


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

xxxxx@imagenation.com said:

As it happens, I have a customers Dell Precision 420 with NT4 loaded
right here. My driver has the same problem on this box. As it also
happens I call Hal assignSlotResources using the optional parameter:

So to clarify, you *do* pass the device object to HalAssignSlotResources
and it still doesn’t work. Hmm…

Steve Williams “The woods are lovely, dark and deep.
xxxxx@icarus.com But I have promises to keep,
xxxxx@picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

I want to know that r u sure that BIOS has done proper
lay out of the PCI card when the card is inserted on a
PCI slot that is on PCI-PCI bridge(s). Just do this
verification. In registry go
to “HKLM\Hardware\Resources\Others\UrDrivername..”. If
BIOS and HAL properly laid out memory map and i/o map
for ur PCI card u will find the entries here. The
HALtranslate API uses this region. If u don’t find ur
driver in this area that means ur driver is not mapped
out properly in the system space. If so the culprit
would be the BIOS.
Please verify this and let us know.

thanks

Girish H.

xxxxx@imagenation.com said:
> As it happens, I have a customers Dell Precision 420 with NT4 loaded
> right here. My driver has the same problem on this box. As it also
> happens I call Hal assignSlotResources using the optional parameter:

So to clarify, you *do* pass the device object to HalAssignSlotResources
and it still doesn’t work. Hmm…

Steve Williams “The woods are lovely, dark and deep.
xxxxx@icarus.com But I have promises to keep,
xxxxx@picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”


You are currently subscribed to ntdev as: xxxxx@att.net
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Hi,
What size is the PCI bus? 32- or 64-bit? I believe there is some trouble
with PCI 64 and HalAssign on Windows NT 4. I also believe that it is
resolved in SP5 or later.

Lee
----- Original Message -----
From:
To: NT Developers Interest List
Sent: Wednesday, April 25, 2001 5:41 AM
Subject: [ntdev] Re: NT 4 vs. PCI vs. DELL Precision 420

> I want to know that r u sure that BIOS has done proper
> lay out of the PCI card when the card is inserted on a
> PCI slot that is on PCI-PCI bridge(s). Just do this
> verification. In registry go
> to “HKLM\Hardware\Resources\Others\UrDrivername..”. If
> BIOS and HAL properly laid out memory map and i/o map
> for ur PCI card u will find the entries here. The
> HALtranslate API uses this region. If u don’t find ur
> driver in this area that means ur driver is not mapped
> out properly in the system space. If so the culprit
> would be the BIOS.
> Please verify this and let us know.
>
> thanks
> –
> Girish H.
>
> >
> > xxxxx@imagenation.com said:
> > > As it happens, I have a customers Dell Precision 420 with NT4 loaded
> > > right here. My driver has the same problem on this box. As it also
> > > happens I call Hal assignSlotResources using the optional parameter:
> >
> > So to clarify, you do pass the device object to HalAssignSlotResources
> > and it still doesn’t work. Hmm…
> > –
> > Steve Williams “The woods are lovely, dark and deep.
> > xxxxx@icarus.com But I have promises to keep,
> > xxxxx@picturel.com and lines to code before I sleep,
> > http://www.picturel.com And lines to code before I sleep.”
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@att.net
> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
> —
> You are currently subscribed to ntdev as: xxxxx@oceanfree.net
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

I’ve had this problem, and the only solution I found was a 2000 PnP driver.
I theorize that for some reason, NT4 has the where-withal to resolve all the
PCI-ness that is going on. I’ve wondered about taking the data from the
HalGet… routines and then using IoAssignResources and avoiding using the
HAL to assign the slot resources.

Gary

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Greg Huntzinger
Sent: Tuesday, April 24, 2001 4:07 PM
To: NT Developers Interest List
Subject: [ntdev] Re: NT 4 vs. PCI vs. DELL Precision 420

I think he was suggesting to supply the DeviceObject even though it is
optional. As it happens, I have a customers Dell Precision 420 with
NT4 loaded right here. My driver has the same problem on this box.
As it also happens I call Hal assignSlotResources using the optional
parameter:
funcStatus = HalAssignSlotResources(
RegistryPath,
NULL,
pDriverObject,
pDeviceObject, /* optional */
PCIBus,
pDeviceExtension->hwInfo.busNumber,
pDeviceExtension->hwInfo.slotNumber.u.AsULONG,
&pFGResources );

If you find an answer to this problem, I’d love to hear about it.

Greg

On Tue, 24 Apr 2001 11:50:54 -0700, Stephen Williams
wrote:

>
>
>xxxxx@advstor.com said:
>> Did you pass the DeviceObject as the 4th parameter to
>> HalAssignSlotResources()? While this is “optional” under NT4, it is
>> required under W2K - much time lost on that one!
>
>This is an NT4 driver.
>
>My fix may be to go to NT5 (where all the resource assignment is
>handled completely differently) but I’m curious why on NT4 the
>HalTranslateBusAddress doesn’t work when given the PCI bus number
>and the bus address pulled from the BAR.


You are currently subscribed to ntdev as: xxxxx@delphieng.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

> My fix may be to go to NT5 (where all the resource assignment is

handled completely differently) but I’m curious why on NT4 the
HalTranslateBusAddress doesn’t work when given the PCI bus number
and the bus address pulled from the BAR.

Trace its assembly to understand the failure case. Maybe IoAssignResources
fail.

Max


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

> PCI-ness that is going on. I’ve wondered about taking the data from the

HalGet… routines and then using IoAssignResources and avoiding using the

This is the same what HAL does in HalAssignSlotResources.

Max


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

xxxxx@att.net said:

I want to know that r u sure that BIOS has done proper lay out of the
PCI card when the card is inserted on a PCI slot that is on PCI-PCI
bridge(s).

Bingo!

I can see with PCI View that the device BARs are set up reasonably. In
fact my BAR has 0xf4000008. Fine.

However, when I look at the PCI-to-PCI bridge, I see a problem. The
non-prefetchable memory base/memory limit registers are set correctly:

0xfbf0fa00 –> 0xfa000000 through 0xfbf00000

but the *prefetchable* region is set oddly:

0xf3f1f401 –> 0xf4000000 through 0xf3f10000

A descending address range? That turns bridges off. (The `1’ in there
says that this supports 64bit addressing) It appears that the BIOS simply
swapped the 16bit words in the 32bit field.

Now did the BIOS d this, or did NT4 (service pack 6) try to shuffle
things and in the process f[oul] it up? More anon.

Steve Williams “The woods are lovely, dark and deep.
xxxxx@icarus.com But I have promises to keep,
xxxxx@picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

xxxxx@inland.net said:

I’ve had this problem, and the only solution I found was a 2000 PnP
driver.

That’s likely the answer, though that might not be enough, even after
upgrading the BIOS to MW420A11 from their web page.

I rummaged around and found that the BIOS seems to be messing up the
mapping. The card in question is an i960RD based board. It is actually
a multi-function PCI device, with function 0 a bridge, and function 1
the device in question. I see that BAR0 of my device gets the value:

0xf4000008

Perfect. Note that it is prefetchable (the 8). The device is on bus 3,
so I look at the bridge that connects bus 3:

BAR4: 0xfbf0fa00
BAR5: 0xf3f1f401

The BAR4 DWORD for a bridge gives the base and limit addresses for
non-prefetchable memory, in this case 0xfa000000 through 0xfbf00000.
BAR5 gives the base and limit addresses for prefetchable memory, in
this case 0xf4000000 through 0xf3f00000. Say what!? The region is the
one that includes my device, but it is given in *descending* order?

I look at the device ID for the bridge, and find that it is a DEC21152
bridge chip. Pull the machine apart, and sure enough it is an Intel
manufactured DEC21152. Goody, I use these chips inside the board, I
know lots about these chips, so I’m probably right about how it works.
Hell, I’ve written my *own* BIOS to program 21152 chips in embedded
systems.

With DEC21152 chips, setting a region to a descending order turns
it off. Hell, that’s true of any PCI-to-PCI bridge.

So I called DELL Technical support, and I must say I don’t remember
the last time I was so thoroughly insulted. I started to tell the lady
about PCI problems, how the bridge was apparently not being set up
correctly (I was willing to be set straight, I’ve been known to be
wrong) and I told the person that the PCI card was an i960RD based
board, PCI 2.1 compliant.

The conversation ended there. “It won’t work. DELL only supports PCI 2.2
devices, PCI 2.1 devices probably will not work.” Any attempt to get a
word in edgewise got the same mantra, including the part about “DELL only
ships PCI 2.2 devices with the Precision 420 systems.” I couldn’t
convince her to escalate the problem or anything.

Of course, the DEC (er, Intel) 21152 bridge chip soldered onto the
motherboard is a PCI 2.1 device, the same as my card. (And of course
my card words in a great many other places, including my alpha.)

So unless someone can get a DELL support drone who knows how to treat
a professional engineer with deference and respect, The Precision 420
systems are on my blacklist.

The conclusion is that the BIOS is fubar. Windows 98 and Windows 2000
work because they do not rely on the BIOS to do PCI mapping… and
now we know why:-)

Steve Williams “The woods are lovely, dark and deep.
xxxxx@icarus.com But I have promises to keep,
xxxxx@picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

afraid so. They also ship some weird-assed plug-and-play manager
thing with NT4 and I worry that there’s something going on with that.
I assume that the PNP thing is to get the USB ports working. My first
inclination was to just blow the whole system back to nothing and
start with a fresh install. However, it IS a customer system so…

The whole thing is one amazing pile of hardware.

Greg

On Tue, 24 Apr 2001 19:19:46 -0700, Stephen Williams
wrote:

>
>
>xxxxx@imagenation.com said:
>> As it happens, I have a customers Dell Precision 420 with NT4 loaded
>> right here. My driver has the same problem on this box. As it also
>> happens I call Hal assignSlotResources using the optional parameter:
>
>So to clarify, you do pass the device object to HalAssignSlotResources
>and it still doesn’t work. Hmm…


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Max,

True, and the information coming out of the HalGet… functions are correct.
What I found when I had this problem was after HalAssignSlotResources, the
resources I got were NOT the resources I saw after HalGet… and they did
not work. The base port addresses from HASR addressed thin air. We made the
decision to drop the bughunt and go for the 2000 port since this was a
legacy NT4 driver we were trying to have function under 2K.

Gary

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Wednesday, April 25, 2001 8:18 AM
To: NT Developers Interest List
Subject: [ntdev] Re: NT 4 vs. PCI vs. DELL Precision 420

PCI-ness that is going on. I’ve wondered about taking the data from the
HalGet… routines and then using IoAssignResources and avoiding using the

This is the same what HAL does in HalAssignSlotResources.

Max


You are currently subscribed to ntdev as: xxxxx@delphieng.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

xxxxx@inland.net said:

True, and the information coming out of the HalGet… functions are
correct. What I found when I had this problem was after
HalAssignSlotResources, the resources I got were NOT the resources I
saw after HalGet… and they did not work. The base port addresses
from HASR addressed thin air.

The problem I’ve been seeing seems to be not a problem with the NT4
HAL or the driver but the BIOS. NT4 relies on the system BIOS to do the
mapping of PCI devices, and so far as I can tell, the DELL BIOS does
not configure the PCI-to-PCI bridges for prefetchable memory regions.

You may be facing different problems.


Steve Williams “The woods are lovely, dark and deep.
xxxxx@icarus.com But I have promises to keep,
xxxxx@picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep.”


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Ah the nightmare of Dell and HalAssignSlotResources…

I think there are multiple problems here.

The first is the Precision 420. On the Dell website buried in the
support database I found information that states the any PCI card which
requires prefetchable memory will not work in certain slots of the 420.
Very nice. (This must be a problem for anyone using the BT848/878 right
Greg?) There is also an article about the 820 chipset, 2.2 compliance and
basically how its everybody elses fault that things don’t work. This is
complete BS. The motherboard layout completely confuses the BIOS since the
820 system chip set pretends to be a PCI-PCI bridge but isn’t. The device
presents itself as a bridge with the rest of the devices downstream to it,
including another real bridge, the 21152. However it has a tiny memory
region allocated which is not really a PCI bridge memory window but a
memory region used for the device itself. If you draw out the memory
regions and the bus heirarchy it is all very ugly. However had Dell done
the BIOS correctly they could have made all of this work anyhow and we
could all use /PCILOCK and be happy. Of course this is not the case.

Not only does the BIOS refuse to assign prefetch memory in some slots it
also will assign the wrong IRQ to devices if your add-in board has another
21152 or 21150 on it. I have found that boards with bridges and devices at
IDSEL 0 and 2 will only get the correct IRQ assignment in slot one. Its a
horrible mess. Until I got familiar with the Precision 420 I thought there
couldn’t be a computer with a worse combination of layout and BIOS than the
Dell Optiplex. Unfortunately Dell topped themselves. (Don’t get me started
on the interrupt latency of the older Dell Dimensions! :slight_smile: ) Anyhow, I would
not suggest a customer use the Precision 420 unless you are sure your
device will be put in slot 1.

(Rant here: Its amazing to me that Compaq, Dell and IBM all have these kind
of problems. They really build their PCs for a market in which nobody adds
cards to the box after delivery. And their support people always give the
same response, “Your add-in card must be non-compliant call the vendor.” I
once gave detailed info on a BIOS/bridge issue to Dell support and the
response was “What are you talking about?” They couldn’t understand it and
couldn’t forward it to an engineer who might know something. I have had
much better luck with generic and industrial PCs than with any of the big
vendors.)

Now for HalAssignSlotResources. I stopped using this more than a year
ago since it also is unreliable for boards with bridges and for
multifunction devices. It will change devices which have been correctly
programmed by the BIOS and create overlaps in non-prefetchable memory
regions. I now rely on getting the BIOS based values and using
IOAssignResources. If the BIOS has failed I request a new hunk of PCI
address space and reprogram my devices (even the bridge on the board). Of
course to reprogram the bridge you have to go around HalSetBusData since it
won’t let you fix up messes created by the BIOS and OS.

In 2000 things seem better. The people who did the Plug-n-Play stuff
seemed to have done a very good job. I have seen old PCs (Pre-PII) which
were a mess under 98 and NT work beautifully with 2000. So, as much as
microsoft gets ripped, somebody on the Win2K team at least understands the
PCI bus.

I don’t know if this helped anyone but I feel better!


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Amen to ALL of that !!! If you want to be made to feel like an idiot, talk
to Dell tech support - or TRY. I got the same response: it must be MY
problem!

Bill Casey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of xxxxx@acut.com
Sent: Thursday, April 26, 2001 9:40 AM
To: NT Developers Interest List
Subject: [ntdev] Re: NT 4 vs. PCI vs. DELL Precision 420

Ah the nightmare of Dell and HalAssignSlotResources…

I think there are multiple problems here.

The first is the Precision 420. On the Dell website buried in the
support database I found information that states the any PCI card which
requires prefetchable memory will not work in certain slots of the 420.
Very nice. (This must be a problem for anyone using the BT848/878 right
Greg?) There is also an article about the 820 chipset, 2.2 compliance and
basically how its everybody elses fault that things don’t work. This is
complete BS. The motherboard layout completely confuses the BIOS since the
820 system chip set pretends to be a PCI-PCI bridge but isn’t. The device
presents itself as a bridge with the rest of the devices downstream to it,
including another real bridge, the 21152. However it has a tiny memory
region allocated which is not really a PCI bridge memory window but a
memory region used for the device itself. If you draw out the memory
regions and the bus heirarchy it is all very ugly. However had Dell done
the BIOS correctly they could have made all of this work anyhow and we
could all use /PCILOCK and be happy. Of course this is not the case.

Not only does the BIOS refuse to assign prefetch memory in some slots it
also will assign the wrong IRQ to devices if your add-in board has another
21152 or 21150 on it. I have found that boards with bridges and devices at
IDSEL 0 and 2 will only get the correct IRQ assignment in slot one. Its a
horrible mess. Until I got familiar with the Precision 420 I thought there
couldn’t be a computer with a worse combination of layout and BIOS than the
Dell Optiplex. Unfortunately Dell topped themselves. (Don’t get me started
on the interrupt latency of the older Dell Dimensions! :slight_smile: ) Anyhow, I would
not suggest a customer use the Precision 420 unless you are sure your
device will be put in slot 1.

(Rant here: Its amazing to me that Compaq, Dell and IBM all have these kind
of problems. They really build their PCs for a market in which nobody adds
cards to the box after delivery. And their support people always give the
same response, “Your add-in card must be non-compliant call the vendor.” I
once gave detailed info on a BIOS/bridge issue to Dell support and the
response was “What are you talking about?” They couldn’t understand it and
couldn’t forward it to an engineer who might know something. I have had
much better luck with generic and industrial PCs than with any of the big
vendors.)

Now for HalAssignSlotResources. I stopped using this more than a year
ago since it also is unreliable for boards with bridges and for
multifunction devices. It will change devices which have been correctly
programmed by the BIOS and create overlaps in non-prefetchable memory
regions. I now rely on getting the BIOS based values and using
IOAssignResources. If the BIOS has failed I request a new hunk of PCI
address space and reprogram my devices (even the bridge on the board). Of
course to reprogram the bridge you have to go around HalSetBusData since it
won’t let you fix up messes created by the BIOS and OS.

In 2000 things seem better. The people who did the Plug-n-Play stuff
seemed to have done a very good job. I have seen old PCs (Pre-PII) which
were a mess under 98 and NT work beautifully with 2000. So, as much as
microsoft gets ripped, somebody on the Win2K team at least understands the
PCI bus.

I don’t know if this helped anyone but I feel better!


You are currently subscribed to ntdev as: xxxxx@advstor.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

> couldn’t forward it to an engineer who might know something. I have had

much better luck with generic and industrial PCs than with any of the big
vendors.)

Agree completely.

In not-so-rich countries (like Russia I’m from), people rarely purchase the
brand-name computers like Dell. Nearly the only purchasers of them are huge
structures like the national bank.
SOHO and middle business use the “self-assembled” machines assembled
immediately at the retailer/dealer store from parts like Asus motherboards
(the most popular) etc. The retailer also sells these parts separately.

This is not only due to price (Compaq can be 2 times more expensive than the
custom-made machine with the same performance).
This is not only due to the fact that the brand’s technical support (which
can possibly justify the high price) are not so good in the not-so-rich
country.

This is due to the fact that brands like Compaq, Dell, HP (especially they!
top expensive and compatibility problems), Acer etc are known to be not 100%
PC-compatible.

  • they can have problems with PCI cards which work fine on Asus
  • tthey can have problems with the disk drives of the vendor other than the
    embedded drive’s vendor (I saw Acer’s 486 machines refusing to identify the
    Conner’s drive - but working fine with Seagates)
  • they have problems with memory sticks which are not of the same brand
  • and worst of all - they have terrible problems with upgrade path.

Assembling the computer from parts is nearly guarantees that it will be 100%
compatible and reliable, provided the parts are good quality.
Even the lack of reputation of the tiny retailer company compared to, say,
Compaq does not spoil the quality - the quality depends on parts quality
only, and parts are usually good (they are not produced by the tiny
retailer).
Upgrade paths of such machines are usually great too (except for AT/ATX
case).

Max


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com