[lkml]   [2002]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] VIA Rhine stalls: TxAbort handling
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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:22    [W:0.147 / U:2.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site