Messages in this thread | | | Date | Fri, 17 May 2002 02:16:54 +0200 | From | "'Roger Luethi'" <> | Subject | Re: [PATCH] #2 VIA Rhine stalls: TxAbort handling |
| |
> I think one has to <somehow> find that the chip has halted besides > the current way (noticing that it can't transmit anymore). I don't
There seems to be a misunderstanding. We already get an interrupt and a status to indicate what kind of problem occured. Thanks to Shing's recent posting we even have confirmed information about what events stop the Tx engine. _Plus_ there is a bit flag TXON in a chip status register which indicates whether the Tx engine is active.
So what's left as a (potential) problem? -- The code snippet that Shing shared with us suggests that there is potential for a race between the chip and an ISR which is already scavenging Tx buffers: the chip has updated the buffer descriptors and set the interrupt status to reflect the error, but is not yet done halting the Tx engine (if it had only failed to update the TXON status bit, there would be no special handling required, since we are writing that bit anyway in a next step, so the issue has to be that the chip is in a transitional state and restarting the Tx engine at this point would be premature). Of course this description assumes that the VIA coders made that particular recent change in their driver for a reason.
> In the chip-halted work-around that everybody seems to use now, > reprogram it from scratch. The last program operation being to remove > loop-back. I don't even know if this chip can be set to loop-back, > though, so the whole idea may be moot.
It can be set to loopback, but I'm not keen on having my chip reprogrammed by every traffic burst (excessive collisions -> abort). Is that really the fashion of the year now?
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/
| |