#2 VIA Rhine stalls: TxAbort handling
Quoted 9 lines
Quoted 4 lines
All the three conditions caused the TXON bit of CR1 went off. the driver must wait a little while until the bit go off, reset the pointer of [...]
do {} while (BYTE_REG_BITS_IS_ON(CR0_TXON,&pMacRegs->byCR0));The driver "waits a little" in the interrupt handler? How long can that take, worst case? I don't know of many places where the kernel stops to wait for an external device to change some value.
It's not that uncommon: Most network drivers busy-wait after stopping the tx process during netif_close().
But I would add a maximum timeout and a printk - just to avoid unexplainable system hangs. One example would be natsemi_stop_rxtx() in drivers/net/natsemi.c. IIRC all register reads from the addresses that belong to a pulled out PCMCIA card return 0xFFFFFFFF ;-)
Shing, I don't like the empty body of the while loop. It's not a bug, but doesn't that generate a large load on the pci bus?
I've always added an udelay(1), i.e. wait one microsecond, into such loops.
--
Manfred
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
do {} while (
BYTE_REG_BITS_IS_ON(CR0_TXON,&pMacRegs->byCR0));The driver "waits a little" in the interrupt handler? How long can that take, worst case? I don't know of many places where the kernel stops to wait for an external device to change some value.
It's not that uncommon: Most network drivers busy-wait after stopping the tx process during
netif_close().
Yeah, but they don't depend on the chip to behave. They will break out at some point. That's the issue several people pointed out.
Quoted 4 lines
Shing, I don't like the empty body of the while loop. It's not a bug, but doesn't that generate a large load on the pci bus?
I've always added an udelay(1), i.e. wait one microsecond, into such loops.
Sounds reasonable. I will add that later. Currently I have no delay, either, because I want to collect some numbers about how long we expect to wait.
Roger
Quoted 2 lines · [email protected] said:
IIRC all register reads from the addresses that belong to a pulled out
PCMCIA card return0xFFFFFFFF;-)
Not necessarily. It can lock up the bus and require a hard reset.
That's why they make some pins longer than others -- so you can get an interrupt which lets you know it's going away a split second before it's actually gone, and you have time to remove power from the socket and call some kind of abort method on the driver so it knows it must never touch the hardware again.
--
dwmw2