On Mon, 23 Feb 2009 00:20:50 +0100, Jiri Slaby wrote > On 22.2.2009 22:56, Jiri Slaby wrote: > > Well, maybe we should try to reproduce with jumbo packets sent to the > > ath5k receiver, since I think it (1) is not very much test-covered code > > (2) appears to be related. > > According to the spec I have for older chip, there is not `done' flag > set for descriptors which have `more' flag set. We handle this wrongly. > Am I looking correctly, Nick, Luis, Bob? > > I still don't see what could have caused this though. As I understand it, yes, we don't do the right thing when the more flag is set. We're supposed to keep processing packets until we get one with the done flag, and then all of that is supposed to be merged into a single packet. Other flags such as the rx rate are only valid on the final packet. However, I did some debugging of this a while ago and concluded that the 'jumbo' frames were largely garbage data. The dma buffer size is certainly large enough for a standard 802.11 frame and the 'more' flag is only supposed to be set if the dma buffer size is too small for a packet. In all cases the dma buffer size was 2500+ bytes and the actual contents of the packets looked like random values (I did have encryption turned on, but there were no 802.11 headers I could see.) So I am not sure if the jumbo packets are causing bad things to happen, or if they are an indication that something bad has already happened. -- Bob Copeland %% www.bobcopeland.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
