Re: [TIP] BUG kmalloc-4096: Poison overwritten (ath5k_rx_skb_alloc)

["Bob Copeland" <me@bobcopeland.com>]

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