Re: [PATCH] VIA Rhine stalls: TxAbort handling

[Urban Widmark]

On Tue, 14 May 2002, Roger Luethi wrote:

> The simple reason: The AMD backoff algorithm always triggered TxAborts,
> the others didn't.
> 
> However, once I had the driver recover from TxAbort without waiting for the
> time out reset, the AMD solution provided over 20% higher throughput than
> the DEC algorithm. YMMV, depending on the specific setup. I'd vote for a
> module parameter. For now, I hardcoded AMD: it's what the eeprom picks when
> reloaded. Also, every other algorithm masked the TxAbort problem (by not
> triggering any).

The backoff algorithm bits have different names (and possibly different
meaning) for the vt86c100a. My vt86c100a eeprom sets all backoff bits to
0000, but my vt6102 sets it to 0010. Since the eeprom is reloaded when the
driver opens, why force it to "amd"?

A module parameter would be nice for testing.

Ivan, have you tried playing with these bits?

Donalds suggestion is that the TxAborts is simply too much collisions.
Perhaps the eeprom selection of backoff algorithm isn't working well in
your environment.

/Urban