On Mar 22, 2009, at 7:18 PM, Larry Finger wrote: > Lorenzo Nava wrote: >> Once again... >> >> Reported-by: Lorenzo Nava >> Signed-off-by: Lorenzo Nava <[email protected]> > Cc: Stable <[email protected]> [2.6.28, 2.6.27] > > Sorry to join this party late, but the line above should be added as > this bug > goes back at least to 2.6.27 and should be applied to stable. I > didn't check any > further. > > > Larry > Larry, Michael,
I checked within the firmware to understand what happens when the rate_idx is not successfully resolved. First of all, this never happens with FCS good frames, at least in my experiments. When FCS is wrong, instead, I noticed that padding could be set to 2 by the firmware (by setting bit 0x20 of SPR_RXE_FIFOCTL1) even if it is not necessary, e.g., an error forces both from_ds and to_ds bits to 1, so the firmware thinks the frame is a WDS one, while it is not. This wrong setting, however, is not responsible for the wrong rate_idx. When a frame is wrong, in fact, we can face two scenarios: A)- some modulated symbols were not correctly decoded but the packet is preserved (of course its content is wrong) B)- what we think is a frame in the rx buffer is not a frame but it is a halved frame (reception stopped before packet ended), or it is a mix of multiple frames on the air In the first scenario the length of the frame (basically, the SPR_RXE_FRAMELEN value that was used by the firmware to push the frame to the host) is consistent with the length reported inside the plcp, that is always correct (the plcp) as it is protected on its own and we do discard plcp bad frames. In this case I _NEVER_ experienced a mismatch between the padding advertised by the firmware with that I computed by checking the first eight bytes as said before. In the second case, instead, I saw that sometimes the reported padding is wrong, e.g., a pad = 2 is reported while the plcp begins on the first byte, or viceversa. The conclusion is that Michael is right, there is a bug in the rx engine, and this bug causes a mis-alignment of the frame pushed through the dma, although this issue is limited to wrong frames of type B. The bad thing is that sometimes a bad alignment is not resolved in a rate_idx = -1 as the first byte of the plcp (which is not actually the first since the pad was wrong) is mistakenly resolved to a valid encoding. This case can be funny since the determined speed could be wrong. Cheers, -FG > > > _______________________________________________ > Bcm43xx-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/bcm43xx-dev ------- Francesco Gringoli, PhD - Assistant Professor Dept. of Electrical Engineering for Automation University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://www.ing.unibs.it/~gringoli _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
