Le 04/06/2010 22:24, Robert Brown a écrit : > > Here's another instance of data corruption. One block containing labels > 110413 & 110414 is duplicated in the output file. > > I've instrumented ath5k_tasklet_rx to print "ATH" followed by packet block > information. Function __ieee80211_rx_handle_packet prints MACI. Function > ieee80211_deliver_skb prints MACO right before calling netif_rx to deliver > the skb to higher networking layers. > [cut] > Later, where we would expect to see the block with label 110413/110414 > received, we instead see ath5k_tacklet_rx sending along a block containing > 107233. This block is not sent to higher levels (no MACO output in the > debug log). Block 110412 is passed along, however; it's the block that's > later missing in the output file. > > Jun 4 14:40:35 ugg kernel: [238080.728324] ATH 0 block 110410 110411 > Jun 4 14:40:35 ugg kernel: [238080.728376] MACI 0 block 110410 110411 > Jun 4 14:40:35 ugg kernel: [238080.728453] MACO 0 block 110410 110411 > Jun 4 14:40:35 ugg kernel: [238080.728817] ATH 0 block 110412 0 > Jun 4 14:40:35 ugg kernel: [238080.728875] MACI 0 block 110412 0 > Jun 4 14:40:35 ugg kernel: [238080.728978] MACO 0 block 110412 0 > Jun 4 14:40:35 ugg kernel: [238080.730060] ATH 0 block 107223 0 > Jun 4 14:40:35 ugg kernel: [238080.730120] MACI 0 block 107223 0 > Jun 4 14:40:35 ugg kernel: [238080.730962] ATH 0 block 110415 0 > Jun 4 14:40:35 ugg kernel: [238080.731022] MACI 0 block 110415 0 > Jun 4 14:40:35 ugg kernel: [238080.731105] MACO 0 block 110415 0 > Jun 4 14:40:35 ugg kernel: [238080.733191] ATH 0 block 110416 110417 > Jun 4 14:40:35 ugg kernel: [238080.733250] MACI 0 block 110416 110417 > Jun 4 14:40:35 ugg kernel: [238080.733335] MACO 0 block 110416 110417 > > There seems to be stale data in the skb that ath5k_tacklet_rx passes to > __ieee80211_rx_handle_packet. Note that ieee80211_deliver_skb does not pass > it along to netif_rx. > > Does this information help figure out the problem? Both instances of > corruption that I've seen today appear related to stale data in > ath5k_tasklet_rx's skb.
It helps for sure. But i'm not seeing in your log where do you receive the duplicate 110413 & 110414 packet. Is it in the log? Is it indeed missing in the log? It might be likely that the problem is caused by background scan done by network manager since this calls ath5k_reset. So, one way to trigger the problem more often is by doing more scanning. Could you try a script like below when downloading ? while true; do iw dev wlan0 scan ; sleep 1 ; done My feeling is that both RXDP & TXDP registers are not properly initialized after a reset causing duplicate in both directions. So I believe you should see duplicate on the TX side as well. Regards, Benoit _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
