On Mon, Oct 11, 2010 at 8:27 PM, Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote: > On 10/11/2010 06:03 PM, Luis R. Rodriguez wrote: >> >> On Mon, Oct 11, 2010 at 1:51 PM, Ben Greear<greearb@xxxxxxxxxxxxxxx> >> Âwrote: >>> >>> On 10/07/2010 02:59 PM, Luis R. Rodriguez wrote: >>>> >>>> On Thu, Oct 7, 2010 at 2:36 PM, Luis R. Rodriguez<mcgrof@xxxxxxxxx> >>>> Âwrote: >>> >>>>>> But other than this I got nothing. I left the box sit there for about >>>>>> 1 hour and came back and it was still going with no issues. Mind you, >>>>>> I can't ping but that seems like another issue. >>>>>> >>>>>> You can find my logs here: >>>>>> >>>>>> >>>>>> >>>>>> http://www.kernel.org/pub/linux/kernel/people/mcgrof/logs/2010/10-07-stress-sta-01/ >>>>> >>>>> Doh, I did not have CONFIG_SLUB_DEBUG_ON=y so building now with that. >>>> >>>> Yay I can reproduce now. I'll be back, going to dig now. >>> >>> Any luck tracking this down? >> >> No, today for example I just finished reading e-mail and its already >> 6pm PST... But Friday I did get do do a lot of work and testing on >> this. The only pattern I see so far is that skb_copy() is used on the >> poison all the time. I am not sure if its because skb_copy() happens >> to run the poison check or what. I'll work on this tomorrow. > > I know how that goes. > > Do you happen to have any magic tools that could be instrumented to show > when DMA was happening in the chip, and to see if it somehow happens to dma > to something after it is supposedly un-mapped? Um, not sure, I'd have to dig. But I was looking at this as an idea to borrow to test if its a DMA issue: https://patchwork.kernel.org/patch/22127/ However right now I'm thinking this is simply a free and then a race to try to use the free'd buffer. > Another thing I was thinking about: ÂMaybe the queue of skbs and dma > addresses > in ath9k is getting corrupted by multiple VIFs trying to write at once? > ÂMaybe > some locking is needed in the xmit path? That was my second hunch. My first shot was to use spin_lock_irqsave() over the the uses of the rxbuf list and that seemed to help but I still managed to get a poison eventually. My next item to check for is of the permissibility of creating too much pressure to the point we end up looping over the rxbuf list and race against mac80211 free'ing a buffer. Will test that tomorrow if nothing else comes up creeping my priority queue. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
