GNICs, SMP Linux, and the GX chipset

[Anthony Caola]

Hello --

We are having ongoing problems with the both the GNIC I and II cards under 
Linux.  Based on what I have heard, it's possible that there is some kind of 
compatibility issue between the Intel AP450GX (GX chipset) platform and the 
GNICs.  From the Intel website, I have obtained a couple of technical 
documents that struck me as possibly relevant, and have reproduced them below: 
 Ted and Don:  Could these indicate the root of the problem?  Am I dead trying 
to use these computers?

Both the GNIC I and GNIC II cause the same symptoms when sending large 
IP messages (using TTCP) -- the computers crash so violently that even the 
front panel LCD display goes blank!

Does anybody have any suggestions?

Tony

Anthony Caola                Massachusetts Institute of Technology
Phone:  (617) 253-6547       Department of Chemical Engineering
Fax:    (617) 258-8224       25 Ames St., Building 66-250
Email:  caola@mit.edu        Cambridge, MA  02139


INTEL DOCUMENTS ========================================================
1 - http://support.intel.com/support/chipsets/450gx/KB49QMA7.HTM
(This one is the most disturbing:  On bootup, the machine claims:
PCI BIOS revision 2.10 entry at 0xfd091!)

Abstract: This document discusses that the 450GX was designed
to meet PCI 2.0 specification and does not support the PCI 2.1
requirement of issuing a RETRY if a target cannot complete the
initial data phase of a transaction in 16 or 32 PCI clocks.

Solution: The 16/32 PCI clock rule is new to the PCI 2.1
specification(section 3.5.1.1). This rule was added to prevent
situations in which a PCI target will hold off a transaction
indefinitely if it cannot access or provide the requested data for the
current transaction. The 450GX was designed to meet the PCI 2.0
specification and does not support the 16/32 PCI clock rule.
Therefore, the 450GX may take longer than 16 or 32 PCI clocks to
complete the first phase of a PCI request.

2 - http://support.intel.com/support/chipsets/450gx/KB8W5BA8.HTM
Abstract: This document discusses possible PCI to main memory
write burst lengths on a Pentium(R) Pro processor/450GX system
when using memory_write versus memory_write_invalidate PCI
instructions.

Solution: The PCI command type (memory_write vs.
memory_write_invalidate) does not necessarily determine the
length of a PCI burst cycle to the PCI->Host bridge. PCI write burst
length is determined by the number of available PCI->Host posting
buffers and available IOQ buffers to assemble the requests.
Provided both are available, the PCI master should be able to
continue bursting to the bridge. The 450GX will disconnect a
PCI->memory write burst on the PCI bus if an outbound request is
made from the host side (e.g., an I/O read or write, or memory read
to PCI), or if the burst crosses a 4K (page) boundary.
A drawback for issuing PCI memory_writes instead of
memory_write_invalidates is that the 450GX bridge can then only
turn the writes into a Pentium(R) Pro bus memory_write (LEN<=8)
instruction rather than a line_write (LEN=32). This would cause
poor performance on both the PCI bus and the Pentium Pro
processor bus.



COMPUTER DESCRIPTION =======================================================
The machines we are attempting to use are:
Intel computers with the model number "ALPCD200512C".  
The CPU stepping is C0, and the processors are 200 Mhz Pentium Pros, 
"Processor ID 619" -- only 512kb of L2 on them.
"450GX" chipset
We have upgraded to the latest BIOS (1.00.14CD0 -- I think they were  
1.00.08CD0 originally), and I think they date back to September of 1997.
============================================================================



 | To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the
 |  body of the mail, include only the text:
 |   unsubscribe this-list-name youraddress@wherever.org
 | You will be unsubscribed as speedily as possible.