Messages in this thread |  | | Date | Tue, 14 May 2002 19:47:02 +0200 (CEST) | From | Urban Widmark <> | Subject | Re: [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.
/Urban
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |