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 <adr...@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.zhu...@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@lists.ath9k.org >> https://lists.ath9k.org/mailman/listinfo/ath9k-devel _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
