Re: Long transmission times on SMC8432T - fix (hack) included

>What driver releases are you using?
>I suspect that it's not one of my releases, but rather a modified
>driver.  Let me know if you encounter a 21041 problem with my release.

Various. I was using the stock one from the 2.4 kernel distribution, the old 
and new ones from SourceForge, the de4x5 version, and now I've tested yours 
too. Your version appears to not send any packets at all without the change. 
With the hack in place (and neither of the other changes) it works perfectly.

>> To cut a long story short, after substituting many variables, it turned out
>> that the problem is with the way tulip.o configures the card - the card
>> ends up thinking the link is intermittently going down.
>
>More likely, the transceiver wasn't configured correctly and the packet
>isn't transmitted until the transmit times out.

In the versions of the driver where the packets do get transmitted, it seems 
to be fairly random as to whether the packet will be transmitted immediately 
or after a delay. Oddly, tx_timeout was never getting called when this 
happened - I didn't bother trying to figure out why since fixing that 
wouldn't have helped.

The only common variable was that when the packet was delayed, CSR12 was 
asserting that the link was in the failed state.

There seems to be a defect on this particular board (or perhaps in some 
version of the DC21041) that causes the chip to falsely believe the link is 
down.

As I said, I was cutting a long story short - there were a lot of tests to 
isolate the problem before I even got to the point of determining how Windows 
configured the card.

>The only reason to delay writing CSR1 is as a hack to work around
>cache-PCI coherency issues.

Yes, that's what I figured.

_______________________________________________
tulip mailing list, [email protected]
To change to digest mode or unsubscribe visit
http://www.scyld.com/mailman/listinfo/tulip