[realtek] NFS problem (using realtek)

[Florian Friesdorf]

--6c2NcOVqGQ03X4Wi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Oct 20, 2000 at 08:49:43PM -0600, Lynn Winebarger wrote:
>=20
>    I've got a little 4 machine network, with one machine an nfs server and
> another running an active webserver (on a separate interface to the
> outside world).  The other 2 machines aren't currently being used much
> (but will be).  All the NICs hooked up to the 4 machine network are DLink
> 530TX's with rtl8139 chips. =20
>    This morning I was copying a few hundred megabytes worth of files over
> NFS from machine #3, and the webserver machine's load went through the
> roof (because all the httpd processes were in an uninterruptable sleep,
> waiting on NFS).  I tried pinging the nfs server, and got back responses
> in pairs, where one would be about 0.3 ms, and the other 1000 ms.  I shut
> down the copying process, waited a couple of minutes, and pinging the nfs
> server got the same results.  I waited a few minutes more, tested again,
> same results, rebooted the server, worked fine. (machine #3 didn't
> experience any of these problems, though it also uses the rtl8139 driver).
>    Anyway, I see similar problems are reported for the rtl8139 driver in
> the archives.  I'm using Redhat 6.2, with kernel 2.2.16-3 on the
> webserver.  Looks like the rtl8139 driver is 1.07.  Would upgrading to
> 1.10 fix this problem?  Is there a fix in the near future?
>    I'm going to be building a small cluster of webservers using this nfs
> server, and buying a bunch of NICs, so I'd like to know whether avoiding
> realtek 8139 based cards is necessary (looking at the tulip list, looks
> like they're not suffering from the same problem).

I experience the same phenomenon with stock 2.2.15 rtl8139 driver.

(ifconfig eth0 down && ifconfig eth0 up) &

on the problematic machine will work as a temporary fix.
(btw: save to executed over ssh, without loosing connectivity)

I think there is "some type of overflow" as using the following cron.d
entry worked fine up till now.

00 *  * * * root /sbin/ifconfig eth0 down && /sbin/ifconfig eth0 up

ok, it's not the elegant way, but works fine 'til I have some more spare
time.

regards ff

--=20
     Florian Friesdorf <42ff@gmx.net>
OpenPGP key available on public key servers

------> Save the future of Open Source <------
-> Online-Petition against Software Patents <-
------> http://petition.eurolinux.org <-------

--6c2NcOVqGQ03X4Wi
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE58dsMf/ev6c/2/tARAmv7AKCcuKX8Zc3DJzXyIX9oUTaUZ1ssHgCfdY1+
fBFL9l5lHV50DqEDlnsg9N4=
=Tc19
-----END PGP SIGNATURE-----

--6c2NcOVqGQ03X4Wi--