On Sun, May 30, 2010 at 8:51 PM, Bruno Randolf <b...@einfach.org> wrote: > On Saturday 29 May 2010 02:39:38 Robert Brown wrote: >> My repeated packet detection hack is not perfect and given how often it >> fires it's probably showing TCP retransmissions or something similar >> that's totally normal.. > > sure, you are only comparing bytes 1000-1100
Yes, but I'm transferring a binary file containing random data. With random data the chance that 100 bytes are identical in 2 adjacent packets is basically zero, unless the exact same packet is being resent. >> > also i am wondering why you have so many resets? (a review of the reset >> > code is the next thing we should do... it gives us trouble in other >> > places too...) >> >> I have no clue about the frequency of resets. I'll have to track down >> the reasons >> the chip can be reset and make the code print out why each reset happened. > > that would be great. there are only a few places from where ath5k_reset() is > called: ath5k_chan_set() or ath5k_init() which are configuration from > mac80211/userspace. no need to worry about these. then it could be called from > tasklet_calibrate() or the ath5k_reset_tasklet(). the tasklet is scheduled > from ath5k_intr() on INTR_FATAL and INTR_RXORN (i sent a patch to remove the > latter, but it hasn't been merged yet). and then there it could be called from > ath5k_beacon_send() but in STA mode this doesnt apply. so most likely debug > "intr" might show you. > > have you tried "[PATCH] ath5k: disable ASPM"? I'll try to figure out the cause of the resets. I have not tried the patch. bob _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
