* [ath9k-devel] ath9k_hw_addrxbuf_edma @ 2014-10-24 16:12 Astrit Zhushi 2014-10-24 19:15 ` Adrian Chadd 0 siblings, 1 reply; 13+ messages in thread From: Astrit Zhushi @ 2014-10-24 16:12 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [ath9k-devel] ath9k_hw_addrxbuf_edma 2014-10-24 16:12 [ath9k-devel] ath9k_hw_addrxbuf_edma Astrit Zhushi @ 2014-10-24 19:15 ` Adrian Chadd 2014-10-25 10:38 ` Astrit Zhushi 0 siblings, 1 reply; 13+ messages in thread From: Adrian Chadd @ 2014-10-24 19:15 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [ath9k-devel] ath9k_hw_addrxbuf_edma 2014-10-24 19:15 ` Adrian Chadd @ 2014-10-25 10:38 ` Astrit Zhushi 2014-10-25 18:31 ` Adrian Chadd 0 siblings, 1 reply; 13+ messages in thread From: Astrit Zhushi @ 2014-10-25 10:38 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [ath9k-devel] ath9k_hw_addrxbuf_edma 2014-10-25 10:38 ` Astrit Zhushi @ 2014-10-25 18:31 ` Adrian Chadd 2014-10-27 10:41 ` Astrit Zhushi 0 siblings, 1 reply; 13+ messages in thread From: Adrian Chadd @ 2014-10-25 18:31 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [ath9k-devel] ath9k_hw_addrxbuf_edma 2014-10-25 18:31 ` Adrian Chadd @ 2014-10-27 10:41 ` Astrit Zhushi 2014-10-27 18:24 ` Adrian Chadd 0 siblings, 1 reply; 13+ messages in thread From: Astrit Zhushi @ 2014-10-27 10:41 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [ath9k-devel] ath9k_hw_addrxbuf_edma 2014-10-27 10:41 ` Astrit Zhushi @ 2014-10-27 18:24 ` Adrian Chadd 2014-10-28 11:14 ` Astrit Zhushi 0 siblings, 1 reply; 13+ messages in thread From: Adrian Chadd @ 2014-10-27 18:24 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [ath9k-devel] ath9k_hw_addrxbuf_edma 2014-10-27 18:24 ` Adrian Chadd @ 2014-10-28 11:14 ` Astrit Zhushi 2014-10-31 18:13 ` Astrit Zhushi 0 siblings, 1 reply; 13+ messages in thread From: Astrit Zhushi @ 2014-10-28 11:14 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [ath9k-devel] ath9k_hw_addrxbuf_edma 2014-10-28 11:14 ` Astrit Zhushi @ 2014-10-31 18:13 ` Astrit Zhushi 2014-10-31 22:13 ` Adrian Chadd 0 siblings, 1 reply; 13+ messages in thread From: Astrit Zhushi @ 2014-10-31 18:13 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [ath9k-devel] ath9k_hw_addrxbuf_edma 2014-10-31 18:13 ` Astrit Zhushi @ 2014-10-31 22:13 ` Adrian Chadd 2014-11-01 12:58 ` Astrit Zhushi 0 siblings, 1 reply; 13+ messages in thread From: Adrian Chadd @ 2014-10-31 22:13 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [ath9k-devel] ath9k_hw_addrxbuf_edma 2014-10-31 22:13 ` Adrian Chadd @ 2014-11-01 12:58 ` Astrit Zhushi 2014-11-01 14:46 ` Ben Greear 0 siblings, 1 reply; 13+ messages in thread From: Astrit Zhushi @ 2014-11-01 12:58 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [ath9k-devel] ath9k_hw_addrxbuf_edma 2014-11-01 12:58 ` Astrit Zhushi @ 2014-11-01 14:46 ` Ben Greear 2014-11-01 20:11 ` Adrian Chadd 0 siblings, 1 reply; 13+ messages in thread From: Ben Greear @ 2014-11-01 14:46 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [ath9k-devel] ath9k_hw_addrxbuf_edma 2014-11-01 14:46 ` Ben Greear @ 2014-11-01 20:11 ` Adrian Chadd 2014-11-01 20:17 ` Astrit Zhushi 0 siblings, 1 reply; 13+ messages in thread From: Adrian Chadd @ 2014-11-01 20:11 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [ath9k-devel] ath9k_hw_addrxbuf_edma 2014-11-01 20:11 ` Adrian Chadd @ 2014-11-01 20:17 ` Astrit Zhushi 0 siblings, 0 replies; 13+ messages in thread From: Astrit Zhushi @ 2014-11-01 20:17 UTC (permalink / raw) To: ath9k-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2014-11-01 20:17 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-10-24 16:12 [ath9k-devel] ath9k_hw_addrxbuf_edma Astrit Zhushi 2014-10-24 19:15 ` Adrian Chadd 2014-10-25 10:38 ` Astrit Zhushi 2014-10-25 18:31 ` Adrian Chadd 2014-10-27 10:41 ` Astrit Zhushi 2014-10-27 18:24 ` Adrian Chadd 2014-10-28 11:14 ` Astrit Zhushi 2014-10-31 18:13 ` Astrit Zhushi 2014-10-31 22:13 ` Adrian Chadd 2014-11-01 12:58 ` Astrit Zhushi 2014-11-01 14:46 ` Ben Greear 2014-11-01 20:11 ` Adrian Chadd 2014-11-01 20:17 ` Astrit Zhushi
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.