On Sun, Apr 5, 2009 at 2:01 PM, Francesco Gringoli <francesco.gring...@ing.unibs.it> wrote: > On Mar 30, 2009, at 11:35 PM, Francesco Gringoli wrote: > >> >> On Mar 28, 2009, at 12:41 AM, Michael Buesch wrote: >> >>> The RX buffer poison needs to be refreshed, if we recycle an RX >>> buffer, >>> because it might be (partially) overwritten by some DMA operations. >>> >>> Cc: sta...@kernel.org >>> Cc: Francesco Gringoli <francesco.gring...@ing.unibs.it> >>> Signed-off-by: Michael Buesch <m...@bu3sch.de> >>> >>> --- >>> >>> Francesco, please stresstest this on top of the other patch that >>> adds poisoning. >> Hi Michael, >> >> great work! No more crashes with the two patches. I will continue >> stress testing anyway but it seems stable. > Hi Michael, > > I run the patched kernel for some time and, though it is stable and > never crashes, there are still (few) some strange rx events. I will > refer to them as Wrong Frame Type I, Type II, and III. Please note > however, that we can observe them ONLY when the FCSFAIL bit is set in > the mac_ctrl_high (at least in my setup). > > - Type I: plcp length mismatch > These frames have a plcp that seems to be correct (I mean, the first > two bytes appear to be taken from a valid plcp), the padding reported > by the firmware in this cases is correct too (e.g. the padding always > point to the byte where the valid plcp seems to start). HOWEVER, the > length of such frames is different than the length encoded in their > plcp. In all these frames the B43_RX_MAC_FCSERR bit is not set, though > these frames will fail a crc check. We should check the plcp matches > the skb length and manually set the RX_FLAG_FAILED_FCS_CRC bit in the > status field so that mac80211 will skip these frames. > > - Type II: fcs is wrong > These frames have a correct plcp that matches their skb length. Their > FCS however is wrong! but the B43_RX_MAC_FCSERR is not set. Again we > should manually set the RX_FLAG_FAILED_FCS_CRC bit in the status field > so that mac80211 will skip these frames. I believe that these frames > are nothing more than Type I but the broken length collided with their > actual length. > > - Type III: plcp is not a... plcp > These frames have a plcp that is not a plcp, in the sense that the > first two bytes (with both padding 0 or 2) does not represent any > possible plcp. > > I attach a patch to correctly set the RX_FLAG_FAILED_FCS_CRC bit in > the status field on such situations so that such frames are not passed > to the upper layers. > > Cheers, > -FG >
Your patch was mangled by your email client. Maybe you should inline your patches and attach a copy of it before sending in the future. Regards, David Ellingsworth _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
