Re: memory clobber in rx path, maybe related to ath9k.

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

On Thu, Oct 14, 2010 at 03:44:49PM -0700, Ben Greear wrote:
> On 10/14/2010 03:35 PM, Luis R. Rodriguez wrote:
> > On Thu, Oct 14, 2010 at 3:29 PM, Luis R. Rodriguez<mcgrof@gmail.com>  wrote:
> >> Fun enough if I just create one monitor interface and loop quickly
> >> over some 2 GHz channels where I know I have traffic nearby I don't
> >> see the poison. So channel changes don't seem to do much because this
> >> is changing channels as fast as possible from userspace. I also can
> >> confirm that I see frames from the different channels as I move along.
> >
> > Even forcing a band change doesn't help trigger it with just one mon0
> > and one regular device scanning in a loop;
> >
> > while true; do for i in 2412 5745 2417 5745 2422 5745 2427 5745 2432
> > 5745 2442; do echo $i iw dev mon0 set freq $i; done; done
> > while true; do iw dev wlan0 scan; done
> 
> What if you just make a bunch of skb copies in ath9k before it
> sends them up the stack, and then delete them?  (That's basically
> what a bunch of monitor devices would be doing, eh?)
 
Sure, as you can see from my patch I at least do it all the time
now on RX and TX. The TX poison never shows though so currently I'm
more suspicious about RX. The other idea I had was to just run
check_bytes_and_report() often around the code, but haven't tried that
yet.

I'm also poking harware folks about some of the registers we use
to better understand how DMA works here.

  Luis