[ath9k-devel] ath9k_hw_addrxbuf_edma

[Ben Greear <greearb@candelatech.com>]

On 11/01/2014 05:58 AM, Astrit Zhushi wrote:
> Tracing the buffer with the "wrong" descriptor after returning
> -EINPROGRESS shows that the descriptor gets properly filled
> afterwards. I am not quiet sure what you mean with intermediary
> descriptors, but what I am observing is that there are a bunch of
> properly set descriptors, and occasionally (seems random) a descriptor
> without 0x168c is seen, after that a bunch of descriptors are properly
> set until it happens again later.
> As to why the descriptor is not fully populated and the RxDone is set,
> I don't know!

This is a bit out of my league, but perhaps a read or write
memory barrier somewhere would help?

Thanks,
Ben

>
> Astrit
>
> On 31 October 2014 22:13, Adrian Chadd <adrian@freebsd.org> wrote:
>> That's an interesting observation! But the hardware should be setting
>> RxDone once the frame reception completes, so hm, are you seeing
>> intermediary descriptors that don't have 0x168c correctly set?
>>
>>
>> -adrian
>>
>> On 31 October 2014 11:13, Astrit Zhushi <a.zhushi@cs.ucl.ac.uk> wrote:
>>> Hi,
>>>
>>> I did a bit of digging and it seems that the values on words 5 to 11
>>> are default values the hardware sets. It looks like only the first
>>> frame of an aggregate (or single frames) have non-default values on
>>> those words.
>>> Also, instead of returning -EINVAL I modified the driver to return
>>> -EINPROGRESS when the AR_DescId != 0x168c and so far I don't  see
>>> losses. I don't know what other implications this might have?
>>>
>>> Astrit
>>>
>>> On 28 October 2014 11:14, Astrit Zhushi <a.zhushi@cs.ucl.ac.uk> wrote:
>>>> Hi,
>>>>
>>>> I noticed that too, I thought it is some default value that hardware
>>>> sets. I memset(0) the buffer (used to print the values) before filling
>>>> it.
>>>> The descriptor's part of the memory is memeset(0) before it is given
>>>> to the hardware.
>>>>
>>>> Here's a (good) descriptor with data:
>>>>
>>>> Descriptor:
>>>> 0x168c000c 0x0b16241f 0x00000099 0xa6ad00af
>>>> 0x00000110 0x25050e07 0x00000000 0x00000000
>>>> 0x00000000 0x80808080 0x00008080 0x00000003
>>>>
>>>> Data (64 bytes):
>>>> 0x00000080 0xffffffff 0xcee4ffff 0x35f5638f
>>>> 0x638fcee4 0x129035f5 0xa6ad003b 0x00000079
>>>> 0x00010064 0x67610800 0x65745f67 0x08017473
>>>> 0x2498128c 0x6c6048b0 0x052c0103 0x00020004
>>>>
>>>>
>>>> and here's a (bad) descriptor with data:
>>>>
>>>> Descriptor:
>>>> 0x00000000 0x00000000 0x00000000 0x00000000
>>>> 0x00000000 0x00000000 0x00000000 0x00000000
>>>> 0x33323130 0x37363534 0x31303938 0x00030003
>>>>
>>>> Data (64 bytes):
>>>> 0x00300288 0x03535404 0xcee4990b 0x35f5638f
>>>> 0x638fcee4 0x2fd035f5 0x00d00000 0x0003aaaa
>>>> 0x00080000 0xdc050045 0x0040d819 0x3e05063f
>>>> 0x0202020a 0x0201010a 0xb74a1cb2 0x95a6a9c2
>>>>
>>>> Thanks,
>>>> Astrit
>>>>
>>>> On 27 October 2014 18:24, Adrian Chadd <adrian@freebsd.org> wrote:
>>>>> Hi,
>>>>>
>>>>> Since I don't know what ordering is going on with the descriptor data,
>>>>> can you modify the code to post the descriptor data as uint32_t's?
>>>>>
>>>>> The fact the descriptor data has that incrementing value from 0x32 ->
>>>>> 0x39 is .. disconcerting. Maybe the hardware didn't actually write
>>>>> into all of those fields and that's left-overs from your kernel malloc
>>>>> or something?
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>> -adrian
>>>>>
>>>>> On 27 October 2014 03:41, Astrit Zhushi <a.zhushi@cs.ucl.ac.uk> wrote:
>>>>>> Hi,
>>>>>> Following are the values for the descriptor and 64 bytes of data
>>>>>>
>>>>>> Descriptor:
>>>>>> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x5c
>>>>>> 0x80 0x0a 0x00 0x41 0x6b 0x6d 0x2e 0x32
>>>>>> 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x30
>>>>>> 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38
>>>>>> 0x39 0x30 0x31 0x32 0x33 0x34 0x35 0x36
>>>>>> 0x37 0x38 0x39 0x03 0x00 0x03 0x00 0x88
>>>>>>
>>>>>> 64 bytes of data:
>>>>>> 0x01 0x2c 0x00 0xe4 0xce 0x8f 0x63 0xf5
>>>>>> 0x35 0x00 0x1c 0xb3 0xc3 0x4b 0x31 0xe4
>>>>>> 0xce 0x8f 0x63 0xf5 0x35 0xe0 0xad 0x00
>>>>>> 0x00 0xe0 0x00 0xaa 0xaa 0x03 0x00 0x00
>>>>>> 0x00 0x08 0x00 0x45 0x00 0x00 0x34 0x37
>>>>>> 0xa5 0x40 0x00 0x40 0x06 0xec 0x17 0x0a
>>>>>> 0x01 0x01 0x03 0x0a 0x02 0x02 0x02 0x4a
>>>>>> 0xb7 0xcd 0x87 0xf0 0x01 0x8b 0xf5
>>>>>>
>>>>>> Thanks,
>>>>>> Astrit
>>>>>>
>>>>>> On 25 October 2014 19:31, Adrian Chadd <adrian@freebsd.org> wrote:
>>>>>>> On 25 October 2014 03:38, Astrit Zhushi <a.zhushi@cs.ucl.ac.uk> wrote:
>>>>>>>> Hi, Adrian
>>>>>>>>
>>>>>>>> Thanks for the reply.
>>>>>>>>
>>>>>>>> I did print some of the descriptor fields:
>>>>>>>>
>>>>>>>> DescId=0 datalen=92 tstamp=3289088044
>>>>>>>> DescId=0 datalen=92 tstamp=3289241267
>>>>>>>> DescId=0 datalen=0 tstamp=0
>>>>>>>> DescId=0 datalen=92 tstamp=3312687323
>>>>>>>>
>>>>>>>> (datalen seems to be wrong, I send 1500 bytes long data packets)
>>>>>>>>
>>>>>>>> I will return -EINPROGRESS on the (MS(rxsp->ds_info, AR_DescId) !=
>>>>>>>> 0x168c) check and run some experiments and see what results do I get.
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> can you print out the rest of the descriptor?
>>>>>>>
>>>>>>> Even just hexdump the descriptor fields and the first like 64 bytes of
>>>>>>> the payload (if it exists) - we can parse those here. :-)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -adrian
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

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