[125] in linux-net channel archive
Re: BOCA PCI Ethernet (LONG)
daemon@ATHENA.MIT.EDU (Scott Laird)
Tue Mar 14 14:05:18 1995
To: broadley@ucdmath.ucdavis.edu (Bill Broadley)
cc: linux-net@vger.rutgers.edu
From: lair@midway.uchicago.edu (Scott Laird)
In-reply-to: Your message of "Mon, 13 Mar 1995 18:48:30 PST."
<199503140248.SAA18282@ucdmath.ucdavis.edu>
Date: Tue, 14 Mar 1995 06:54:51 -0800
> I have a BOCALANcard-PCI, which I have almost working with linux.
>
> Telnets work but ftp's hang with the following:
> eth0: Bus master arbitration failure, status 88f2
>
> I can get ftp's to work if I run some disk intensive stuff in the
> backround (I use bonnie -s 64).
>
> I've heard boca is saying that the card won't work with pentiums
> over 66 Mhz which sounds wrong since the ethernet card should only
> interact with a PCI bus which doesn't know how fast the cpu is
> running. (it runs at 30 or 33 Mhz)
>
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. Like he said, telnet works fine, WWW seems to
work fine (mostly, anyway, I haven't tried much). FTP and Samba are
another story. I can copy _some_ files from the client to the server,
and _all_ files from the server to the client, but certain files just
will not transfer from the client to the server -- a 100% failure rate.
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.
This is annoying.
I tried doing some tests with the 'cards.dll' file -- I made a copy on
the client, with a different name, and copied it to null a few times,
to make sure it was in the disk cache. That didn't work, so I figure
it's not a disk problem on the client. I copied the file to a floppy
and moved it to the server (at least _that_ works), and then used dd to
make shorter versions of the file. The entire file, or any subset
thereof, will copy fine from the server to the client (but not from the
client to the server). The first 7k (`dd if=cards.dll of=cards-1.dll
bs=1k count=7`) would copy back and forth with 0 problems. The first
8k failed 100% of the time. Remember that the Linux kernel tar file
copied fine, so it's not size related. The problem seemed to begin
occuring around 7.4k or so, and by 7.6k the errors were occuring 100%
of the time. At 7.5k, sometimes it worked, sometimes it didn't.
This was all tested using 1.1.95, and still seems to be a problem with
1.2.0. I recently took the server home, where I have a much better
testing environment :-), and found that the same problem occured when
copying the same file with FTP from my Pentium-90 running 1.1.94 (using
an NE2000) to the server. I didn't test this that extensively, but
after changing which slot the PCI card was in in the server, and then
swapping the PCI ethernet card with another identical card I have, it
seemed to work, mostly. I could copy the one file with some chance of
success, and I was able to copy a few hundred megs of tar files from
one system to the other, but I still got hangs from time to time, for
instance when I was trying to back my system on the server's DAT over
the network.
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. I can watch the client try to retransmit, but
the attempts always end in failure.
I haven't tested any of this on a loaded machine, or a loaded network,
due to a lack of time (I have a math final in about an hour...)
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.
Scott.
---
Scott A. Laird | Live each day as if it's your last, and
one
lair@midway.uchicago.edu | day--- you'll be right. - Unknown.
