tulip v0.90q with Linksys 10/100 LAN Card (LNE100TX)

Christopher C. Chen ccchen@polymail.cpunix.calpoly.edu
Tue Apr 6 15:23:11 1999


I change the tulip options to 13 from 14.  All the problems went away. 
I was able to send video's from both ends.  Things worked great. 
Thanks.


Donald Becker wrote:
> 
> On Sat, 3 Apr 1999, Christopher C. Chen wrote:
> 
> > Here is the dmesg output of an ftp session on the local side:
> > 2. The ftp session went fine.  Should I be concerned about the "Receive
> > errors" from tulip?
> ..
> > Found Lite-On 82c168 PNIC at PCI I/O address 0xf800.
> > tulip.c:v0.90q 2/23/99 becker@cesdis.gsfc.nasa.gov
> > eth0: Lite-On 82c168 PNIC rev 32 at 0xf800, 00:A0:CC:24:D3:FE, IRQ 4.
> > eth0:  MII transceiver #1 config 3100 status 7829 advertising 01e1.
> > eth0:  Advertising 0101 on PHY 1, previously advertising 01e1.
> 
> Hmmm, you must have set the media type to MII-100baseTx-FDX.
> 
> > eth0: PNIC MII PHY status 782d, Link partner report 0001, csr6
> > 810c0200/810c2202.
> 
> Your link partner doesn't autnegotiate -- I'm guessing that it's an old
> switch.
> 
> > eth0: The transmitter stopped!  CSR5 is 2678016, CSR6 814e2202.
> > eth0: Changing PNIC configuration to full-duplex, CSR6 814e0200.
> 
> Normal.  You must stop the transmitter to change the transmit duplex.
> (I've removed this message in subsequent versions.)
> 
> > eth0: Receive error, Rx status 039e8302.
> > eth0: Receive error, Rx status 03dd8306.
> 
> Hmmmm, CRC and frame errors.  Not my problem.
> You should check your cables, especially for split pairs.
> 
> On a loosely-related topic:
> The Pentium-II apparently doesn't flush the write buffer before some
> I/O operations?!  (Despite the documentation...)
> That means occasionally the PNIC will get a transmit demand, and the
> already-queued packet won't be seen on the descriptor list.
> 
> The previous suggestion of doing "udelay(2)" before sending the transmit
> demand, or checking the status of the transmit unit will allow the write
> buffer to empty and avoid this.  But so will doing just about *anything*
> that delays or does I/O.
> 
> The next version of the Tulip driver re-orders the statements and does a
> clear_bit() operation to avoid this issue.
> 
> The real Tulip occasionally polls the transmit list, and thus will send the
> packet anyway.  The PNIC relies only on the transmit demand command, and in
> rare cases might leave a packet in the transmit queue until the next packet
> is queued.
> 
> Donald Becker                                     becker@cesdis.gsfc.nasa.gov
> USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
> Code 930.5, Goddard Space Flight Center,  Greenbelt, MD.  20771
> 301-286-0882         http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html