> What you can try is to turn on slab debugging. Set the FORCED_DEBUG
> define in mm/slab.c to one and recompile. Does it change any pattern
> when you dump the data in the skbs or pings?
> If yes someone is playing with already freed packets.
I think the dump that i got suggests something more
> Coudl the problem be in the NIC driver not in the alloc_skb?
No, i don't think so...i got the dump of the packet at the local_out and
post routing hooks& found it in bad shape there. Here it is what it
looks like:
45 0 0 80 0 0 40 0 ff 1 2d f8 c0 a8 66 16 c0 a8 66 1d 0 0 e4 48 11 d 0 0 14
> -Original Message-
> From: ext Dave Airlie [mailto:[EMAIL PROTECTED]]
> Sent: 11. April 2001 20:20
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: RE: skb allocation problems (More Brain damage!)
>
>
>
> What compi
> Well, I don't know then. You have to debug it. It's probably
> something stupid
> (if fundamental services like alloc_skb/kfree_skb were
> completely buggy
> someone surely would have noticed earlier)
yep, at first i thought it was because of sume stupidity in my module...but
now it seems tha
> On Mon, Apr 09, 2001 at 07:03:46PM +0300, [EMAIL PROTECTED] wrote:
> > I have written a test module which closely mirrors what my
> code tries to
> > do(attached below). This is what i get:
> >
> > PRE_R: old skb:c371ee40 new skb:c371ee30
>
> I guess oldskb->len is <=0xc, and the slab alloc
hello all,
For the past week, i am having problems with (possibly BUGGY) memory
allocation by the kernel in my NAT-PT module. I posted this to netdev before
but did not get any response. So, here i am with some more proof:)
In my IPV6-IPV4 translator module, i capture an IPV4 packet by register
6 matches
Mail list logo
