Re: [ath9k-devel] Script to crash ath9k with DMA errors.

["Luis R. Rodriguez" <lrodriguez@atheros.com>]

On Mon, Dec 06, 2010 at 01:00:05PM -0800, Ben Greear wrote:
> On 12/06/2010 12:42 PM, Luis R. Rodriguez wrote:
> > On Mon, Dec 06, 2010 at 12:22:26PM -0800, Ben Greear wrote:
> >> On 12/06/2010 12:11 PM, Björn Smedman wrote:
> >>> On Mon, Dec 6, 2010 at 8:47 PM, Ben Greear<greearb@candelatech.com>   wrote:
> >>>> With 16 properly configured non-encrypted stations, running with
> >>>> wpa-supplicant
> >>>> with netlink driver&   sharing scan results,  the interfaces quickly
> >>>> associate.
> >>>>
> >>>> However, I do continue to see DMA warnings such as these (I had picked up my
> >>>> portable phone, and it knocked all the interfaces offline ..here
> >>>> they are coming back up after I hung up the phone).
> >>>
> >>> Is there some theory as to why using multiple interfaces cause so many
> >>> problems with DMA?
> >>
> >> Seems pretty directly related to channel changes and/or resets, and exacerbated
> >> by other interfaces sending data while another is scanning, for instance.
> >>
> >> Other issues we've found in the past have been various races that you wouldn't
> >> normally see with a single VIF.
> >
> > Right, there might be some other hot path we need to lock around over.
> > Not sure what it could be though we should be locking stopping RX
> > over resets already though. These should all be atomic, in fact
> > starting TX too IIRC, hence the name change of the lock to be
> > specific to the PCU together. There may be other PCU changes
> > we may need to contend against.
> 
> Maybe the hardware/firmware guys could give us some clues as to what
> types of things can cause stopping RMA to fail?  Maybe that could
> point us to what might be racing with the attempts to stop RMA?

We have no firmware, but yeah understanding how the hardware
blocks would be key here. Good point.

 Luis