Re: Trouble running in Dual bus boxes under NT

["Bender, Bernhard" <br@elsa.de>]

Hi,

the unknown bus agent is probably the legacy bus bridge (PCI to ISA or 
EISA). These bridges usually use subtractive decoding to clain all 
accesses not answered by normal agents.

Using a PCI bus analyser, you can see DEVSEL# asserted on the third or 
forth cycle after FRAME# for these bridges.

In a system with multiple busses, each bus has to known the range of 
addresses that are valid for its devices. Only those accesses will be 
forwared to the bus. This is true for both hierachical (using PCI to PCI 
bridges) and peer busses.

If the device is remapped, it may be mapped to a range belonging to the 
wrong bus. This would be a software problem in the device driver 
(miniport), the OS/HAL or the system BIOS (MPS tables).


Bernhard Bender
---
Group Manager Core Technology   ELSA Computer Graphics

ELSA GmbH             		Email: br@elsa.de
Sonnenweg 11                    Fax  : +49 (2405) 450 100
D-52 070 Aachen, Germany        WWW  : http://www.elsa.de


***  Original Message Follows  ***
Hi, all:

   We have been testing a new adapter card in some systems that have the
Orion chip set and dual PCI buses running under Windows NT. We found that
the adapter card only works if it is in bus 0 but not in bus 1. Further
investigation showed that when the card was in bus 1, all attempts to 
access
it resulted in bus cycles in bus 0. The interesting thing was that some
unknown bus agent claimed those bus cycles and after long delays (we have
seen from 105 to 138 clocks) returned "FFFFFFFF" for reads. Has anyone 
had
any experience like this? It doesn't look like a hardware problem but is 
it
a BIOS problem? or OS problem? or driver problem?

   We also found that the system's boot code mapped our card at power on 
and
NT re-mapped the card after it came up. Is this normal?


TIA

Vi Chau
Emulex Corp.
(714) 513-8132
v_chau@emulex.com

***  End of Original Message  ***
MTD