> [6.] A small shell script or example program which triggers the> problem (if possible)> > Downloading amounts of data (>50MB) will eventually trigger> the problem. Transmitting data at less than full speed will> not trigger it (or at least I haven't waited long enough?)

What do you use to download? from a server on the LAN or something remote?and how do you slow down the speed of your transmission? How fast is itwhen it is fast, and how much do you slow it down?

My other machine does not have anything useful installed, but it did havechargen and discard open.

nc other.machine chargen > /dev/null iptraf says about 64Mbpsnc other.machine discard < /dev/zero iptraf says about 44MbpsSending about 1.5G in both directions, without problems. I used to have anetperf setup and that would (more or less) fill the 100Mbps.

> [X.] Other notes, patches, fixes, workarounds> > Further information from lspci, via-diag and ifconfig output as well> as well as complete kernel syslog from boot to network-lock can be> found on http://www.heureka.co.at/~david/dfe530tx/

The syslog gives a few hints that something is wrong ...

eth0: Transmit error, Tx status 00008100. 8 - transmit error 1 - transmit aborted after excessive collisionsbut at the same time the 00 part means that the "collision retry count" is0 and that it hasn't set a flag that it "experienced collisions in thistransmit event".

I think there were 3 of these, and from all but the last it recovers byitself. Perhaps the collisions (or whatever it is that the card sees ascollisions) continued for a longer period.

It ends up in "eth0: transmit timed out" and the driver tries to reset thecard. That does not appear to work at all.

It's a nice report, I wish I had something more useful to reply with.

The driver source has links to some datasheets. They might be useful inimproving the reset code.(Hmm, the tx_timeout code does: reset -> initialise ring -> wait for hw but initialise ring talks to the hw, perhaps it should wait for hw first ...)