On Thu, 16 May 2002 10:37:52 -0600, Ivan G. wrote:
> > What tickles my curiosity is that my previous patch didn't fix the stalling
> > for Ivan G. on his VT86C100A. Maybe the chip just wasn't ready to be
> > restarted.
> 
> With your patch #2, the chip would actually "wait forever"
> in some cases...it didn't timeout and recover 

What does the log file say? (with debug = 7) The most interesting
information (buffer descriptors and various registers) doesn't get logged,
but the log file may contain a clue that goes beyond "wait forever".

Hanging without timeout seems to indicate that all buffers were
successfully sent (if all frames have been sent, there is no transfer
left to time out). But I'm shooting in the dark here, somebody with
access to such a card needs to look into it.

I have a wonderful unified theory to explain everything but I'm afraid I'm
not looking forward to see it make contact with reality. Anyway, here goes:
On my system, it's almost impossible for the Tx engine to be still on by
the time we enter the error handler. In fact, even checking in
via_rhine_tx() gave me only one instance in hundreds of aborts. If the
VT86C100A (or something else about your setup) is slower, we might turn the
engine back on before the chip is ready. Patch #2 has a faster path to the
point where we set TXON which might explain why things got worse for you.

The problem with this idea is that the VIA driver does the error handling
as soon as it finds an abort, while the LK driver frees the skb first and
returns back to the interrupt handler before it enters the error handler to
finally do something about the error, which should give the chip ample time
to stop the Tx engine meanwhile. I attach a quick hack which will complain
if the driver had to wait for the chip. It will make up to four attempts
before it shrugs and proceeds as it used to. If you have time to give the
patch a spin, I'd be interested if you find any iteration counters in your
log file.

The patch is against the new version Jeff sent out earlier today. Please
note that with the current driver tx underruns are likely to cause a time
out. My patch doesn't even make an attempt at addressing errors other than
aborts.

Roger