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

[Ben Greear <greearb@candelatech.com>]

On 10/15/2010 04:33 PM, Ben Greear wrote:
> On 10/15/2010 04:21 PM, Luis R. Rodriguez wrote:
>> Ben, please give this patch a shot. I addresses three races on the PCU:
>>
>> * When we were stopping the CPU for non-EDMA cards we never locked
>> against
>> anything starting the PCU again
>>
>> * ath9k_hw_startpcureceive() was being called without locking
>>
>> * Although we lock on the rxbuf lock for contention against
>> starting/stopping
>> the PCU, we also need to lock on the driver in locations where we
>> start/stop
>> the PCU within the same location otherwise we end up in inconsistant
>> states
>> and the hardware may end up proessing an incorrect buffer for DMA. To
>> protect against this we use a new PCU lock on the main part of the
>> driver to
>> ensure each start/stop/reset operation is done atomically.
>>
>> And fixes one issue as a side effect:
>>
>> * No more packet loss on ping flood when you have one STA associated :)
>>
>> The only issue I see with this is I eventually run out of memory and
>> my box
>> becomes useless, unless I am mistaking that for some other issue.
>>
>> Please give this a shot and if it cures your woes I'll split it up into
>> 3 separate patches, or maybe just two, one for the first two and one for
>> the last issue.
>
> Sounds good, but this lockdep splat happens almost immediately upon
> starting
> my app:
>
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> 2.6.36-rc8-wl+ #32

It ran for a bit..never did see the poison warning, but system hard-locked
(sysrq b on the serial console got no response) after a bit.  Hopefully
just because it hit this potential deadlock.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com