please try this patch and tell us if it helped...
bruno
commit 0379d1e5a850f8e63832516af4245b9824d8623d
Author: Bruno Randolf <b...@einfach.org>
Date: Wed May 26 11:58:11 2010 +0900
ath5k: better checks for rx descriptor processing
- add check not to process self-linked rx descriptor at the end
- add DMA sync
diff --git a/drivers/net/wireless/ath/ath5k/base.c
b/drivers/net/wireless/ath/ath5k/base.c
index 4ea31dc..db63789 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -1948,6 +1948,10 @@ ath5k_tasklet_rx(unsigned long data)
if (ath5k_hw_get_rxdp(sc->ah) == bf->daddr)
break;
+ /* never process the self-linked entry at the end */
+ if (ds->ds_link == bf->daddr)
+ break;
+
ret = sc->ah->ah_proc_rx_desc(sc->ah, ds, &rs);
if (unlikely(ret == -EINPROGRESS))
break;
@@ -2015,6 +2019,8 @@ accept:
if (!next_skb)
goto next;
+ pci_dma_sync_single_for_cpu(sc->pdev, bf->skbaddr,
+ rs.rs_datalen, PCI_DMA_FROMDEVICE);
pci_unmap_single(sc->pdev, bf->skbaddr, common->rx_bufsize,
PCI_DMA_FROMDEVICE);
skb_put(skb, rs.rs_datalen);
On Wednesday 26 May 2010 04:10:17 Robert Brown wrote:
> Your description of the symptom is exactly correct. With one corruption
> the bad data was 1368 bytes long, with another 1448 bytes.
>
> The sender is an access point. I've noticed the problem with three
> different access points. The receiver is an Acer with ath5k driver.
>
> My home access point is configured with RTS threshold 2346, fragmentation
> 2346, beacon interval 100ms, DTIM interval 1, short preamble, CTS mode
> auto, WEP encryption.
>
> I should be able to collect packet traces with wireshark. Can you
> recommend wireshark configuration options that are maximally helpful? I
> can transfer small files containing ASCII data until I see a mismatch.
>
> bob
>
> ====================
>
> On Tue, May 25, 2010 at 2:45 PM, Bob Copeland <m...@bobcopeland.com> wrote:
> > On Tue, May 25, 2010 at 1:40 PM, Robert Brown <robert.br...@gmail.com>
wrote:
> >> The symptom is a block of data, roughly 1400 bytes in size, that appears
> >> twice in a row in the destination file. The first instance of the
> >> repeated data is erroneous. It does not match the source file. The
> >> second instance of the repeated data block is correct.
> >
> > Ok, just to make sure I have it: one 1400ish-byte block in the file gets
> > replaced with the data from the subsequent block, and the data that was
> > supposed to be in that block was lost?
> >
> > 1400 is about the size of an MTU... ath5k is the receiver and the
> > sender is some AP? Do you have the frag threshold configured?
> >
> > Ok, yes, a block of 'As' wouldn't help, but perhaps alternating different
> > letters every 500 bytes or so. If you have enough space, a wireshark
> > packet capture of the transfer may give clues.
> >
> > --
> > Bob Copeland %% www.bobcopeland.com
>
> _______________________________________________
> ath5k-devel mailing list
> ath5k-devel@lists.ath5k.org
> https://lists.ath5k.org/mailman/listinfo/ath5k-devel
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
