Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#80 Possible bug in tulip_interrupt

Receive (4)

I'm reporting this based on a project where I did a bugfix on a modified tulip driver. I'm not sure if the current behavior is intended or not, but it made the RX processing on the chip in question(DM9103) RX never be restarted when an error was reported in the interrupt.
In tulip_interrupt the error reports bits in CSR5 are cleared early in the function(a local copy is kept). Then if the NoRxBuf bit is set, tulip_refill_rx is called. This function again reads CSR5 and has a conditional on the bits that were actually cleared in the interrupt handler and this is the place where the RX processing is restarted upon failure. I do realize that tulip_refill_rx is called from other places as well, so this might have been the intended behavior from the start, but for our chipset it caused a hang.