[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
RE: 2.1.130 and pppd
- From: "B. James Phillippe" <bryan terran org>
- To: axp-list redhat com
- Subject: RE: 2.1.130 and pppd
- Date: Mon, 14 Dec 1998 00:20:55 -0800 (PST)
On Mon, 14 Dec 1998, Vignaud Jean-Baptiste wrote:
> > From: B. James Phillippe [mailto:bryan@terran.org]
...
> > YES. There IS a fatal bug in the 2.1 kernel with networking. I have
> > observed several Kernel panics, all from skput:over. All but one were
> > dev:ppp0 (the oddball was eth0). The address is consistant across each
> > panic (even the oddball for eth0) so this should not be hard to find.
> > Without a -g compiled kernel, the closest I could see was
> > rcv_proto_vjc_uncomp. However, I am rebuilding a 2.1.131 with -g and will
> > try to nail this bastard tonight. It's already caused me major grief and
> > some filesystem damage.
>
> I'v observed exactly the same behaviour on my sx164, the ppp compressor
> was provocating kernel panic in rcv_proto_vjc_uncomp. To continue using
> pppd you have to specify the "novj" option to the pppd...
Yes, I have since found the exact line where the Panic occurs (with the
symbol kernel and gdb). I put in a new check to catch the problem and give
me more information. It has just succeeded this evening, after nearly two
days of uptime. Here is the patch showing my test code (this is for
debugging only, but has the side-effect of avoiding the panic):
--- drivers/net/ppp.c.orig Mon Dec 14 00:18:06 1998
+++ drivers/net/ppp.c Sat Dec 12 01:30:37 1998
@@ -2047,6 +2047,11 @@
"ppp: error in VJ decompression\n");
return 0;
}
+ /*BP*/if( skb->tail+(new_count+PPP_HDRLEN-skb->len) > skb->end ) {
+ printk( KERN_ERR "Avoiding PPP Panic! t:%p,e:%p c:%d,l:%d\n",
+ skb->tail, skb->end, new_count, skb->len );
+ return 0;
+ }/*BP*/
skb_put(skb, new_count + PPP_HDRLEN - skb->len);
return rcv_proto_ip(ppp, skb);
}
And here it is in action:
Dec 13 23:54:25 earth kernel: Avoiding PPP Panic! t:fffffc0000a1bdce,e:fffffc0000a1be70 c:0,l:1470
I have not had time to look further. It is possible there is a bug other
than just trusting the return value of the VJ decompression algorithm.
I'll post here and linux-kernel when I have more info.
cheers,
-bp
--
B. James Phillippe . bryan@terran.org
Linux Engineer/Admin . http://www.terran.org/~bryan
Member since 1.1.59 . finger:bryan@earth.terran.org
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
[]