> This bug has been around for many months; judging from other posts, it
> affects several 3Com cards (we have a 3C905). As far as I can see, this
> problem persists in 2.0.28 or 2.0.29.
This bug has been plaguing Linux long enough; if you have a test case
where you can reproduce the repeated "access conflict" scenario, then by
all means get into contact with the author who might be able to send some
debugging code to help him sort it out.
> Print "trasmitter timed out"
> Send a TxReset to the board
> Check at most 20 times to see if the reset has completed
> Send a TxEnable to re-enable transmit
> Silently drop the packet
> So I decided to try and handle "Transmitter access conflict" in the same
> way (patch included below). Although this _seems_ to have made the
> system more stable, I still did get hangs when I really pushed the network.
> I haven't field tested it yet on a real network. I've sent this report
> to the linux-vortex-bug mailing list.
I was just about to knock up a patch like this.... it _still_ hangs??
Could you elaborate more?
Note that the code claims an access conflict can only occur if, quote,
"the queue layer is doing something evil". Is this likely to be the case?
> One other thing that may be worth trying is that a known way to recover
> from a hang is to do a "/sbin/ifconfig eth0 down;/sbin/ifconfig eth0 up;
> /etc/rc.d/rc.inet1". The first two correspond to vortex_close() and
> vortex_open(). But that seems rather brutal and one would probably
> also have to reconstruct the routes ...
If I just bring the network interface down the up, thats not really good
enough. A hang tends to occur soon after this. So I unload then load the
module as well.
> If anyone has suggestions or fixes, by all means please post!
> Thanks very much in advance.
Time I sent a ratty e-mail to 3-com for not writing a driver themselves
> -- Paul