From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Greear Date: Sat, 01 Nov 2014 07:46:28 -0700 Subject: [ath9k-devel] ath9k_hw_addrxbuf_edma In-Reply-To: References: Message-ID: <5454F244.3040309@candelatech.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org 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 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 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 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 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 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 wrote: >>>>>>> On 25 October 2014 03:38, Astrit Zhushi 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 Candela Technologies Inc http://www.candelatech.com