GNICs, SMP Linux, and the GX chipset

[Kim Stearns]

Ted:

Please see Tony points below..... We need to assist him.

Kim
> -----Original Message-----
> From:	Anthony Caola [SMTP:caola@MIT.EDU]
> Sent:	Tuesday, November 17, 1998 7:07 AM
> To:	yellowfin@cesdis1.gsfc.nasa.gov
> Subject:	GNICs, SMP Linux, and the GX chipset
> 
> 
> 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.