On Sun, May 23, 2010 at 11:49 AM, Robert Brown <robert.br...@gmail.com> wrote: > I do think it's worthwhile to think about how a repeated block of data could > get into the destination file, assuming something in the networking code is > buggy. TCP/IP should be verifying packet checksums, so isn't it likely > (necessary?) that the repeated data is a complete TCP/IP packet?
Yes, there shouldn't be a way to get corrupt data from the TCP stack generally. But we already know that ath5k corrupts memory in some corner cases due to a use-after-free which we're still trying to pin down. Sl*b debug/kmemcheck should indicate if this is your problem. I don't understand your point about repeated data: are the two files the same except one has a repeated block of data in it (and is therefore larger than file2?) If so I'd expect a much bigger set of changes from cmp. I would suggest transferring a large file with a recognizable bit pattern (like all 'A's) to make it easier to see the corruption. I looked at the data from cmp; it doesn't look like the sort of thing that ath5k would scribble in memory -- no discernable 802.11 frames etc. You may also try using fsx-linux or try a wired network to ensure the problem doesn't lie in fs/hardware. -- Bob Copeland %% www.bobcopeland.com _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
