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