Le 05/06/2010 14:50, Robert Brown a écrit :
>
> I think I have a likely explanation for the data corruption. It looks like
> the hardware is not transferring the data to place the driver expects.
>
> I ran Wireshark on a Macintosh portable while transferring a file, so I now
> know what packets the access point is transmitting.
>
> The configuration is as before, but I now print the addresses of skb->data
> and bf. I have also modified ieee80211_invoke_rx_handlers to try to figure
> out how packets are dropped:
>
> switch (res) {
> case RX_DROP_MONITOR:
> I802_DEBUG_INC(sdata->local->rx_handlers_drop);
> printk(KERN_DEBUG "ZZ drop monitor\n");
> if (rx->sta)
> rx->sta->rx_dropped++;
> /* fall through */
> case RX_CONTINUE:
> printk(KERN_DEBUG "ZZ continue\n");
> ieee80211_rx_cooked_monitor(rx, rate);
> break;
> case RX_DROP_UNUSABLE:
> printk(KERN_DEBUG "ZZ drop unusable\n");
> I802_DEBUG_INC(sdata->local->rx_handlers_drop);
> if (rx->sta)
> rx->sta->rx_dropped++;
> dev_kfree_skb(rx->skb);
> break;
> case RX_QUEUED:
> printk(KERN_DEBUG "ZZ queued\n");
> I802_DEBUG_INC(sdata->local->rx_handlers_queued);
> break;
> }
>
> Here is some output of my debugging code while transferring a file where the
> contents of block 604273 appears in its proper place *and* where block
> 604271/604272 should have appeared in the destination file.
>
> Search for "****" below to see my comments in the debug output.
>
> As you can see from the trace below, when block 604273 was transmitted by
> the access point according to Wireshark, the Acer reports receiving block
> 604182 in ath5k_tasklet_rx. This block is discarded by mac80211 (no MACO in
> the debugging log). I think what happened is that the hardware overwrote
> block 604271/604272 with the contents of block 604273. We see 604182
> because the data for 604273 was copied to the wrong spot.
>
> Later, block 604273 is retransmitted. This time, it is not discarded.
>
> Is this consistent with Benoit's RXDP/TXDP theory?
Very good question. My theory is that the hardware & software are both
using the RXDP and RX ring at the same time. I'm trying to understand
the details. Maybe the self linked descriptor used at the end of the
list is a problem and Bruno provided a patch.
I think the best way to move forward is to carefully print the whole RX
ring including bf->daddr & ds->ds_link & Done status.
Another thing I'm thinking of, which might be way simpler is that there
might be a time window in which :
1. RX is enable, so RX descriptors are filled by hardware with incoming
data. It means that the head of the RX list is now pointing to a "Done"
descriptor.
2. RXDP is reset to the head of the RX list (which might be descriptor
already containing data then).
3. RX irq is triggered and the head of the RX list is moved to the tail.
That does not make much sense... need to think about it...
> Jun 4 21:41:58 ugg kernel: [257026.842628] ATH f280f020 block 604144 0
> Jun 4 21:41:58 ugg kernel: [257026.842635] bf f6bb23a8
> Jun 4 21:41:58 ugg kernel: [257026.842694] MACI f280f020 block
> 6041442030] ATH ea342020 block 604187 604188
> Jun 4 21:41:58 ugg kernel: [257026.862037] bf f6bb22e8
>
> **** Note garbled debugging messages above. Why does this happen?
It's probably because you are sending too much data at once. It happens
to me as well when debugging such kind of things.
Regards,
Benoit
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
