Ethernet interface dies during long ftp

I'm running Woody with the 2.4 kernel (and the latest updates).
My Ethernet adaptor is VT6103 on the motherboard (K7VTA3 motherboard).
The driver is the via-rhine driver, the version on the Debian Woody
download sites.
I ftp from the machine with the VT6103 to another computer on the same
LAN and get a big file ( >700MB). After getting about 200MB of the
file, the VT6103 seems to die. It recovers on reboot.
A bunch of error messages go into the syslog, first a lot of:
NETDEV WATCHDOG: eth0: transmit timed out
etho: Transmit timed out, status 0000, PHY status 786D, resetting...

which it seems to recover from, and then:
eth0: reset did not complete in 10ms

Then all 3 messages again, twice, and it gives up. The interface seems
then to be dead, will not respond to or send pings.

There's a known problem with the VT6103 on machines which have ACPI
(which I think is auto-low-power mode) but the machine does not go
into low power mode at any point.

Has anyone seen something like this or know anything about it?

Retlak wrote:
> I'm running Woody with the 2.4 kernel (and the latest updates).
> My Ethernet adaptor is VT6103 on the motherboard (K7VTA3 motherboard).
> The driver is the via-rhine driver, the version on the Debian Woody
> download sites.

Is it an on-board NI, or a PCI/ISA one?

In either case, try to find out whether there's a BIOS setting that
allows to power down the network interface, and disable it.

Is, from what You can say, the failure dependent of time or amount
of data transferred?


Cheers, Jack.

--
----------------------------------------------------------------------
My personal reading of the string "MicroSoft" expands to "NanoWeak"...

jack <(E-Mail Removed)> wrote in message news:<c1dvgm$l08$04$(E-Mail Removed)>...
> Retlak wrote:
> > I'm running Woody with the 2.4 kernel (and the latest updates).
> > My Ethernet adaptor is VT6103 on the motherboard (K7VTA3 motherboard).
> > The driver is the via-rhine driver, the version on the Debian Woody
> > download sites.
>
> Is it an on-board NI, or a PCI/ISA one?

It's on-board.

> In either case, try to find out whether there's a BIOS setting that
> allows to power down the network interface, and disable it.

There's a BIOS setting that enables/disables ACPI and I already
disabled that (sorry I forgot to mention it in the post)

> Is, from what You can say, the failure dependent of time or amount
> of data transferred?

The failure seems to happen only when a lot of data is being
transferred. The NI will stay up for hours if there's little network
traffic. But when I start a big ftp transfer, it will go down in
minutes. The actual amount of data transferred varies a lot from test
to test, though. In one test it transferred over 300MB before failing.

Retlak wrote:

>>Is it an on-board NI, or a PCI/ISA one?
>
>
> It's on-board.

Mmmh, sorry to hear that. My suspicion was that if it was a slot card,
You might have some power issues with Your busses. - But that may even
be the case with an onboard network interface on a really cheap m/b.


> There's a BIOS setting that enables/disables ACPI and I already
> disabled that (sorry I forgot to mention it in the post)

Ok, please see whether there are othe power management options in
Your bios. From what You write, I really do think that all this has
to do with insufficient power supply.

But: Don't forget to check Your configuration. Although I assume that
You already did that over and over, check Your interrupts and PCI bus
info.


> The failure seems to happen only when a lot of data is being
> transferred. The NI will stay up for hours if there's little network
> traffic. But when I start a big ftp transfer, it will go down in
> minutes. The actual amount of data transferred varies a lot from test
> to test, though. In one test it transferred over 300MB before failing.

Well, is there anything more specific that You can see, like in the logs
or something? Keep trying.


Cheers, Jack.

--
----------------------------------------------------------------------
My personal reading of the string "MicroSoft" expands to "NanoWeak"...

In article <(E-Mail Removed) >,
(E-Mail Removed) wrote:

> The failure seems to happen only when a lot of data is being
> transferred. The NI will stay up for hours if there's little network
> traffic. But when I start a big ftp transfer, it will go down in
> minutes.

All I can say is that I had exactly the same problem on a different
mainboard that uses the same onboard LAN. I was also using the
via-rhine driver.

After trying to make the interface work reliably by tweaking all kinds
of software and BIOS settings I gave up on it, disabled it and stuck in
an rtl8139 card I had lying around.

I realize that not everyone has unused NICs lying around, but those
cards are so cheap that it might well be an option to just replace the
misbehaving onboard one.

Joerg

--
OpenPGP: D14F 2782 1276 EBB4 E4E3 0BF1 838D DD4C EB56 1C99

(E-Mail Removed) (Retlak) wrote in message news:<(E-Mail Removed). com>...
> I'm running Woody with the 2.4 kernel (and the latest updates).
> My Ethernet adaptor is VT6103 on the motherboard (K7VTA3 motherboard).
> The driver is the via-rhine driver, the version on the Debian Woody
> download sites.
> I ftp from the machine with the VT6103 to another computer on the same
> LAN and get a big file ( >700MB). After getting about 200MB of the
> file, the VT6103 seems to die. It recovers on reboot.
> A bunch of error messages go into the syslog, first a lot of:
> NETDEV WATCHDOG: eth0: transmit timed out
> etho: Transmit timed out, status 0000, PHY status 786D, resetting...
>
> which it seems to recover from, and then:
> eth0: reset did not complete in 10ms
>
> Then all 3 messages again, twice, and it gives up. The interface seems
> then to be dead, will not respond to or send pings.

I found the fix. The problem was first reported by someone ona mailing
list nearly 3 years ago,
http://www.cs.helsinki.fi/linux/linu...1-12/0089.html
and a fix to the driver was first announced by Jeff Garzik. So the
solution was to download the latest version of the via-rhine driver
and build it.
There are unfortunately 2 branches of the via-rhine driver. It looks
as though the original author, Donald Becker, and Garzik don't get
along. I got the latest driver from Becker's set of Ethernet drivers
at www.scyld.com and it worked. I did not try the latest Garzik
version, but I assume it would work also.

The latest version of the driver is dated 2003 and hasn't made its way
into Debian "stable" yet. I guess this incident illustrates a drawback
of Debian's glacially slow update process.