There were a few places where the sc->rxlink pointer was set to NULL "just in
case". This helps nothing - quite to the contrary it is problematic since it
can create self-linked rx descriptors in the middle of the list of receive
buffers.
Here is an example how this could happen (thanks Bob!):
cp
On Wed July 14 2010 00:32:41 Bob Copeland wrote:
> Based on a patch from Bruno Randolf, attempting useful
> work while we are resetting the chip just leads to interface
> lockups and bad descriptor data, and possibly DMAing to
> freed buffers. Let's suspend all tasklets while
> reprogramming the r
On Wed July 14 2010 00:32:40 Bob Copeland wrote:
> We currently trigger a reset via a tasklet when certain error
> conditions are detected so that the card will (eventually)
> restart. Unfortunately this makes locking complicated since
> reset can also be called in process context (e.g. for channe
On Tue, Jul 13, 2010 at 08:32:40AM -0700, Bob Copeland wrote:
> We currently trigger a reset via a tasklet when certain error
> conditions are detected so that the card will (eventually)
> restart. Unfortunately this makes locking complicated since
> reset can also be called in process context (e.
We currently trigger a reset via a tasklet when certain error
conditions are detected so that the card will (eventually)
restart. Unfortunately this makes locking complicated since
reset can also be called in process context (e.g. for channel
change). Currently nothing protects against concurrent
Based on a patch from Bruno Randolf, attempting useful
work while we are resetting the chip just leads to interface
lockups and bad descriptor data, and possibly DMAing to
freed buffers. Let's suspend all tasklets while
reprogramming the registers in the card to avoid such
problems.
In the future
