Messages in this thread | | | Date | Fri, 17 May 2002 08:51:14 -0400 (EDT) | From | "Richard B. Johnson" <> | Subject | Re: [PATCH] #2 VIA Rhine stalls: TxAbort handling |
| |
On Fri, 17 May 2002, 'Roger Luethi' wrote:
> > 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. > [SNIPPED...] > > > 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?
Well, maybe the fashion of the day. Do `grep karound *.c` in ../linux/drivers/net and see all the 'workarounds' that exist for chip problems. Some of the problems are induced by the coding and most are real hardware problems.
Cheers, Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.
- 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/
| |