2010/10/14 Ben Greear <greearb@xxxxxxxxxxxxxxx>:
> On 10/14/2010 02:52 PM, BjÃrn Smedman wrote:
>>
>> 2010/10/13 BjÃrn Smedman<bjorn.smedman@xxxxxxxxxxx>:
>>>
>>> Hi Ben,
>>>
>>> First of all keep up the good work. :)
>>>
>>> On Wed, Oct 13, 2010 at 6:39 PM, Ben Greear<greearb@xxxxxxxxxxxxxxx>
>>> Âwrote:
>>> [snip]
>>>>
>>>> Either way, it seems safer to null out the bf_ampdu field after
>>>> the memory is consumed..it could prevent some tricky bugs later.
>>>
>>> I think this is a good idea. But it probably wont be enough to null
>>> out bf_mpdu. You also need to look at bf_buf_addr (which if I
>>> understand correctly is the physical address the DMA engine will
>>> actually write RXed frames to) and bf_dmacontext (which seems in most
>>> cases to hold an identical address and may in fact be where the DMA
>>> engine will really write the frame).
>>
>> I took another look at the code. It turns out both bf_buf_addr and
>> bf_dmacontext are in fact meaningless to the DMA. Instead each bf
>> holds a pointer (bf_desc) to the real DMA descriptor which in turn
>> holds the address (ds_data) where the DMA will really (really this
>> time) write the frame. There is also a field to hold the virtual
>> address of the same place (ds_vdata).
>>
>> It's a little too much work for me to set up the testbed you have Ben
>> but would be interesting to see what happens if you set
>> bf->bf_desc->ds_{data,vdata} = 0 as well. No?
>
> I'll investigate those suggestions.
>
> But setting up a test-bed is as easy
> as getting an ath9k NIC in a system, with a few APs around, and run the
> script below.
>
> You do not need any traffic generation, dhcp, etc...seems just beacons and
> whatever
> wpa_supplicant is doing is enough to hit the problem fast. Â(Make sure
> you are compiled to detect memory poisoning, of course).
>
> You'll need to fix the paths to the executables most likely.
>
You don't need such complicated scripts, I've managed to reproduce now
by creating a lot of monitor interfaces and then looping with a
regular interface issuing a scan command over and over. I suspect
I'll be able to do this as well by changing channels instead of doing
a scan. I believe the issue may be due to races in hardware on resets
and enabling RX on an already freed buffer.
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
