How a different abort handling could cause a slow down is beyond me,
especially if you used the old code where the aborted frame got
reactivated. With the vanilla code, you were bound to stall on the first tx
error, which should certainly decrease troughput by a fair bit. And unless
a tx error occurs, both versions (of the code) behave identically. I'm
afraid I don't understand what's going on with the VT86C100A.
> On Urban's question, I test without MMIO so this is not a related issue. I
> was merely curious since I don't feel comfortable trusting something which
> A) does not match any of the other Rhine-based cards (2's and 3's)
> B) says RESERVED in the docs which I have.
>
> Funny, I was going to send you a link to the newer docs, but I ran into the
> older ones which I had never seen before. Yes, they do agree with the current
> code. Hmm. Perhaps we should ask VIA why it was changed...
I'd take the docs with a grain of salt, especially the VT86C100A data sheet
(the one I have, anyway) contains so blatant mistakes it's downright
confusing.
Roger
-
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/