[ath9k-devel] ath9k_hw_addrxbuf_edma

[ath9k-devel] ath9k_hw_addrxbuf_edma

[Astrit Zhushi]

Hi,

I was wondering if someone can help me understand receiver buffer
management on the ath9k driver.

While running TCP experiments using an AP and a wireless node (both
running  AR9380 mini PCI-e cards, with PCI-e adapter) I noticed that
TCP was invoking fast retransmit. At the transmitter, the retry
counters didn't show that the frame was dropped. In addition, looking
at the over the air captured traces (by a third party wireless node),
the receiver's card actually acknowledges the missing frame and the
traces show only one transmission of the missing frame.
Instrumenting the driver I noticed that the missing frames are being
dropped because the received frame descriptor ID didn't match that of
the Athero's vendor ID.
That is, AR_DescId=0 and MS(rxsp->ds_info, AR_DescId) != 0x168c (maybe
replace it with ATHEROS_VENDOR_ID?) condition on ar9003_mac.c fails.

So I started looking at the way the receive buffers are managed by the
ath9k driver. This is my understanding so far:

Before the the card can use the DMA allocated buffers (the pool of 512
buffers kept in rx.rxbuf, they are added to ATH9K_RX_QUEUE_LP (128
buffers) or ATH9K_RX_QUEUE_HP (16 buffers) FIFO queues) and then the
hardware is told about the address by calling ath9k_hw_addrxbuf_edma
function. After which point the hardware can make use of those
buffers.

On a receive interrupt, the driver processes incoming buffers, calls
ath_edma_get_buffers, removes the buffer from rx_edma->rx_fifo
(__skb_unlink(skb, &rx_edma->rx_fifo). This buffer ends up being put
back to the rx.rxbuff pool.
I don't see any call informing the hardware that it shouldn't be using
that buffer. It could be that the equivalent of this is happening
somewhere in the code, but I am missing it?

The only place where the descriptor is memset to zero is when calling
ath_rx_edma_buf_link, before telling the hardware that it can use the
buffer. Now supposing that the card still thinks that it can use a
buffer, and memset(0) is called on the same buffer (because it is
being added back to the rx.rx_buf queue) wouldn't I end up receiving
frames where AR_DescId is 0?

I hope I was clear enough

Thanks,
Astrit

[ath9k-devel] ath9k_hw_addrxbuf_edma

[Adrian Chadd]

Hi,

The driver handles some corner case from the hardware where the NIC
indicates a frame is completed but the contents of the frame aren't
what it expects. Ie, the atheros vendor ID isn't in there.

Try printing out the contents of the RX descriptor when that happens
and take a look.

It may just be that the receive side of the EDMA code isn't entirely
checking descriptors correctly and maybe waiting a little longer would
result in the descriptor coming 'ready'.


-adrian


On 24 October 2014 09:12, Astrit Zhushi <a.zhushi@cs.ucl.ac.uk> wrote:
> Hi,
>
> I was wondering if someone can help me understand receiver buffer
> management on the ath9k driver.
>
> While running TCP experiments using an AP and a wireless node (both
> running  AR9380 mini PCI-e cards, with PCI-e adapter) I noticed that
> TCP was invoking fast retransmit. At the transmitter, the retry
> counters didn't show that the frame was dropped. In addition, looking
> at the over the air captured traces (by a third party wireless node),
> the receiver's card actually acknowledges the missing frame and the
> traces show only one transmission of the missing frame.
> Instrumenting the driver I noticed that the missing frames are being
> dropped because the received frame descriptor ID didn't match that of
> the Athero's vendor ID.
> That is, AR_DescId=0 and MS(rxsp->ds_info, AR_DescId) != 0x168c (maybe
> replace it with ATHEROS_VENDOR_ID?) condition on ar9003_mac.c fails.
>
> So I started looking at the way the receive buffers are managed by the
> ath9k driver. This is my understanding so far:
>
> Before the the card can use the DMA allocated buffers (the pool of 512
> buffers kept in rx.rxbuf, they are added to ATH9K_RX_QUEUE_LP (128
> buffers) or ATH9K_RX_QUEUE_HP (16 buffers) FIFO queues) and then the
> hardware is told about the address by calling ath9k_hw_addrxbuf_edma
> function. After which point the hardware can make use of those
> buffers.
>
> On a receive interrupt, the driver processes incoming buffers, calls
> ath_edma_get_buffers, removes the buffer from rx_edma->rx_fifo
> (__skb_unlink(skb, &rx_edma->rx_fifo). This buffer ends up being put
> back to the rx.rxbuff pool.
> I don't see any call informing the hardware that it shouldn't be using
> that buffer. It could be that the equivalent of this is happening
> somewhere in the code, but I am missing it?
>
> The only place where the descriptor is memset to zero is when calling
> ath_rx_edma_buf_link, before telling the hardware that it can use the
> buffer. Now supposing that the card still thinks that it can use a
> buffer, and memset(0) is called on the same buffer (because it is
> being added back to the rx.rx_buf queue) wouldn't I end up receiving
> frames where AR_DescId is 0?
>
> I hope I was clear enough
>
> Thanks,
> Astrit
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] ath9k_hw_addrxbuf_edma

[Astrit Zhushi]

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.

Thanks,
Astrit

On 24 October 2014 20:15, Adrian Chadd <adrian@freebsd.org> wrote:
> Hi,
>
> The driver handles some corner case from the hardware where the NIC
> indicates a frame is completed but the contents of the frame aren't
> what it expects. Ie, the atheros vendor ID isn't in there.
>
> Try printing out the contents of the RX descriptor when that happens
> and take a look.
>
> It may just be that the receive side of the EDMA code isn't entirely
> checking descriptors correctly and maybe waiting a little longer would
> result in the descriptor coming 'ready'.
>
>
> -adrian
>
>
> On 24 October 2014 09:12, Astrit Zhushi <a.zhushi@cs.ucl.ac.uk> wrote:
>> Hi,
>>
>> I was wondering if someone can help me understand receiver buffer
>> management on the ath9k driver.
>>
>> While running TCP experiments using an AP and a wireless node (both
>> running  AR9380 mini PCI-e cards, with PCI-e adapter) I noticed that
>> TCP was invoking fast retransmit. At the transmitter, the retry
>> counters didn't show that the frame was dropped. In addition, looking
>> at the over the air captured traces (by a third party wireless node),
>> the receiver's card actually acknowledges the missing frame and the
>> traces show only one transmission of the missing frame.
>> Instrumenting the driver I noticed that the missing frames are being
>> dropped because the received frame descriptor ID didn't match that of
>> the Athero's vendor ID.
>> That is, AR_DescId=0 and MS(rxsp->ds_info, AR_DescId) != 0x168c (maybe
>> replace it with ATHEROS_VENDOR_ID?) condition on ar9003_mac.c fails.
>>
>> So I started looking at the way the receive buffers are managed by the
>> ath9k driver. This is my understanding so far:
>>
>> Before the the card can use the DMA allocated buffers (the pool of 512
>> buffers kept in rx.rxbuf, they are added to ATH9K_RX_QUEUE_LP (128
>> buffers) or ATH9K_RX_QUEUE_HP (16 buffers) FIFO queues) and then the
>> hardware is told about the address by calling ath9k_hw_addrxbuf_edma
>> function. After which point the hardware can make use of those
>> buffers.
>>
>> On a receive interrupt, the driver processes incoming buffers, calls
>> ath_edma_get_buffers, removes the buffer from rx_edma->rx_fifo
>> (__skb_unlink(skb, &rx_edma->rx_fifo). This buffer ends up being put
>> back to the rx.rxbuff pool.
>> I don't see any call informing the hardware that it shouldn't be using
>> that buffer. It could be that the equivalent of this is happening
>> somewhere in the code, but I am missing it?
>>
>> The only place where the descriptor is memset to zero is when calling
>> ath_rx_edma_buf_link, before telling the hardware that it can use the
>> buffer. Now supposing that the card still thinks that it can use a
>> buffer, and memset(0) is called on the same buffer (because it is
>> being added back to the rx.rx_buf queue) wouldn't I end up receiving
>> frames where AR_DescId is 0?
>>
>> I hope I was clear enough
>>
>> Thanks,
>> Astrit
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] ath9k_hw_addrxbuf_edma

[Adrian Chadd]

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] ath9k_hw_addrxbuf_edma

[Astrit Zhushi]

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] ath9k_hw_addrxbuf_edma

[Adrian Chadd]

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] ath9k_hw_addrxbuf_edma

[Astrit Zhushi]

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] ath9k_hw_addrxbuf_edma

[Astrit Zhushi]

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] ath9k_hw_addrxbuf_edma

[Adrian Chadd]

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] ath9k_hw_addrxbuf_edma

[Astrit Zhushi]

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!

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] ath9k_hw_addrxbuf_edma

[Ben Greear]

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

[ath9k-devel] ath9k_hw_addrxbuf_edma

[Adrian Chadd]

Hm, so:

#define AR_rx_done           0x00000001
#define AR_rx_frame_ok        0x00000002

Your final dword has 0x3 in the last two bits - so, amusingly, it
should've been completed. I _think_ the hardware is supposed to DMA
out that word as the last DWORD being DMAed.

For non-cache-snooping platforms I'd expect this to be the case and
you'd need a sync before you read that memory. However, you've said
it's a PCIE card, so hm, is this on an intel computer, or something
MIPS/ARM/PPC-y?

I'll go ask the atheros hardware people and see if the descriptor
identifier value is DMAed out before or after the final DWORD is DMAed
out.

Thanks,


-adrian


On 1 November 2014 07:46, Ben Greear <greearb@candelatech.com> wrote:
>
>
> 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

[ath9k-devel] ath9k_hw_addrxbuf_edma

[Astrit Zhushi]

Hi,

This is a mini-PCIE card on a Intel machine.

Thanks,
Astrit
On 1 Nov 2014 20:12, "Adrian Chadd" <adrian@freebsd.org> wrote:

> Hm, so:
>
> #define AR_rx_done           0x00000001
> #define AR_rx_frame_ok        0x00000002
>
> Your final dword has 0x3 in the last two bits - so, amusingly, it
> should've been completed. I _think_ the hardware is supposed to DMA
> out that word as the last DWORD being DMAed.
>
> For non-cache-snooping platforms I'd expect this to be the case and
> you'd need a sync before you read that memory. However, you've said
> it's a PCIE card, so hm, is this on an intel computer, or something
> MIPS/ARM/PPC-y?
>
> I'll go ask the atheros hardware people and see if the descriptor
> identifier value is DMAed out before or after the final DWORD is DMAed
> out.
>
> Thanks,
>
>
> -adrian
>
>
> On 1 November 2014 07:46, Ben Greear <greearb@candelatech.com> wrote:
> >
> >
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20141101/df9d05e5/attachment-0001.htm