[126] in linux-net channel archive
Re: BOCA PCI Ethernet (LONG)
daemon@ATHENA.MIT.EDU (Dave Platt)
Tue Mar 14 20:06:38 1995
Date: Tue, 14 Mar 95 11:59:29 PST
From: dplatt@3do.com (Dave Platt)
To: linux-net@vger.rutgers.edu
> I have similar problems with the same card on a AMD 486DX4/100. It's
> on its own network, with just one 486 running WfWG as a client, so I've
> had a hard time convincing myself that it's a Linux problem and not a
> Windows problem :-). I've seen the bus-master arbitration failures
> that everyone else has seen, but I'm much more likely to have receives
> die silently, marked only with an increasing receive error count
> reported by netstat -i.
I have noticed something similar (the increasing receive-error count)
when running CAP using UAR or Native EtherTalk.
> Like he said, telnet works fine, WWW seems to
> work fine (mostly, anyway, I haven't tried much).
For me, FTP and other TCP transfers seem to work fine. _Some_ EtherTalk
works (copies from the Linux machine to the Mac seem to run very reliably).
Other EtherTalk does not work (copies from the Mac to the Linux machine tend
to hang after a few megabytes).
> Size is not an issue -- the Linux 1.1.94 kernel tar.gz file works
> fine, I was bouncing copies back and forth with Samba and FTP with 0
> problems. A 3 Mb Excel file I have refuses to copy. The 100k
> CARDS.DLL that comes with Windows (or at least WfWG) won't copy more
> than about 9k without hanging.
Again, similar results - certain files seem to result in sudden death.
> This is annoying.
Indeed!
> It looks like this problem occurs when a full network packet with a
> specific bit- or byte-pattern is being transfered, and the BOCA card is
> unable to receive it.
That's the preliminary conclusion I have come to, as well. In my case,
it looks as if there may be problems with _short_ packets - specifically,
packets with an embedded length less than the Ethernet minimum of 46.
These EtherTalk packets are padded out to the minimum with zeros (per
the spec). My SparcStation-10-clone can see these packets just fine
in etherwatch (it has a Lance-family chip). Some of them get through to
Linux just fine. Others cause the Boca to gag (it reports an FCS error
and a packet overrun) and never seem to get through.
> I can watch the client try to retransmit, but
> the attempts always end in failure.
Ditto here.
I have a couple of hunches, which I haven't had time to explore:
[1] It may have to do with short-packet reception (embedded length < 46).
The Lance chips are supposed to be able to handle these OK, doing automatic
zero-padding during transmission, [optionally] stripping off the zeros
on reception rather than passing them into the FIFO, and doing the FCS
calculations based on the padded packet.
It's possible that there are some boundary conditions which cause the
short-packet reception to fail.
[2] There might be certain data patterns which could cause the receiver PLL
to lose lock on the signal, or cause the carrier-detection / end-of-
message processing to malfunction somehow. This could cause extra
bits to be laminated onto the end of the packet, resulting in an
FCS miscalculation and a dribbling-bits warning.
It'd be interesting to modify lance.c to report the receive errors, but
still let the bad packets through to the higher-level protocol code (and
see whether they're rejected via UDP/DDP checksums, etc.). This could tell
us whether the packets are really bad "as received", or are just being
flagged as bad due to a bug in the receiver logic.
> I really hope someone can fix this problem through software, but if I
> can't get it working in about another week, I'm going to have to go out
> and buy a cheap WD8013 clone card, and see if that works.
I bought a surplus NE2000 clone this weekend just for that sort of testing.
