On Wednesday 11 November 2009 23:28:45 Larry Finger wrote: > On 11/11/2009 04:03 PM, Michael Buesch wrote: > > On Wednesday 11 November 2009 22:43:46 Larry Finger wrote: > >> Michael, > >> > >> I don't know whether this came to you. I did not get it and I had to read > >> it on > >> the LKML archive. > >> > >>> What is the meaning of PageCompound(page) being zero? > >> > >> From Pekka Enberg: > >> > >> "You're passing a pointer to kfree() that did not come from kmalloc(). > >> If a page is not PageSlab(), it needs to be a compound page if it came > >> from the page allocator pass-through." > >> > >> I guess that helps a little. > > > > Ok, very weird. > > > > I'd guess priv_info->bouncebuffer contains garbage, for whatever reason. > > With 64-bit DMA, under what circumstances would a bounce buffer be needed?
Well, theoretically it could _try_ to use a bouncebuffer, because the mapping of the skb failed for whatever non-addressspace-related reason (dma_mapping_error() returned error). I don't think that happens, however. And in case it did happen, it should not produce this BUG(). It should silently work. But my guess is that some memory corruption is going on which corrupts skb->cb. I don't see other kfree()s in the path that matches the backtrace, so for now I'm assuming it's the bouncebuffer kfree() that causes the crash due to a crap pointer. I guess a few WARN_ONs should be added for debugging. One to the bouncebuffer allocation path to check whether it allocates one or not. And one to the bouncebuffer free path which warns (and prints the pointer) if bouncebuffer!=NULL. Also notice that the stack in this oops seems slightly corrupted. update_curr_rt should not show up in the trace, as far as I can see. There also are a few interesting numbers on the stack "7fff7fff dededede" and in EAX. -- Greetings, Michael. _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
