Thanks very much for the patch suggestion. I ran some large "scp" commands today with the patch installed. Several died with error message: "Corrupted MAC on input." so it's likely the patch has not fixed the problem. I'll run some more tests at home where I can use FTP and have control over the data being copied.
bob On Tue, May 25, 2010 at 11:04 PM, Bruno Randolf <b...@einfach.org> wrote: > 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
