I'm running 2.6.23-rc9 on my laptop, and when in a coffee shop I use

a Verizon EVDO card to get network access.  This is a kyocera device

that looks like a serial adapter behind an ohci usb controller, and

uses the airprime driver (for usb device 0c88:17da).  The actual IP

networking is ppp over that serial adapter.
The connection is slightly flaky (I blame this on the Verizon

coverage), so I end up restarting things every so often.  The point of

this email (at last) is that I've just seen my second panic (only

info: blinking caps lock led, since I've been in X) that seems

correlated to stopping/restarting pppd.
Sorry for the lack of detail -- I've just switched to running in the

console so if I can provoke the crash again I'll get a little more

info.  I just wanted to mention this in case someone has seen

something similar or has any good ideas about how to capture debugging

output on a laptop (when I'm not home and have no other boxes handy).
 - R.

-

Just as a quick update -- I seem to only be able to reproduce this

crash when my ppp session drops, which seems associated with marginal

signal.  And unfortunately I have great coverage at home so I haven't

been able to reproduce this again today.  Maybe on the train tomorrow

I can crash my laptop...
 - R.

-

From: Roland Dreier <rdreier@cisco.com>
I don't want to jump the gun on the analysis but it just might

be the packet sharing fixes Herbert put in a short time ago.
What you could do is go back to say rc2 and see if you still get

the panics, then bisect from there to narrow it down.
If rc2 still gives the panic, it's something else, perhaps device

specific.

-

I think the only change of mine that could affect ppp over a

serial line is this one.  I couldn't see anything obvious in

it but maybe someone else can.
Cheers,

--

Visit Openswan at http://www.openswan.org/

Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>

Home Page: http://gondor.apana.org.au/~herbert/

PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

--

2a38b775b77f99308a4e571c13d908df78ac5e57

diff --git a/drivers/net/ppp_generic.c b/drivers/net/ppp_generic.c

index 7e21342..4b49d0e 100644

--- a/drivers/net/ppp_generic.c

+++ b/drivers/net/ppp_generic.c

@@ -1525,7 +1525,7 @@ ppp_input_error(struct ppp_channel *chan, int code)

 static void

 ppp_receive_frame(struct ppp *ppp, struct sk_buff *skb, struct channel *pch)

 {

-	if (skb->len >= 2) {

+	if (pskb_may_pull(skb, 2)) {

 #ifdef CONFIG_PPP_MULTILINK

 		/* XXX do channel-level decompression here */

 		if (PPP_PROTO(skb) == PPP_MP)

@@ -1577,7 +1577,7 @@ ppp_receive_nonmp_frame(struct ppp *ppp, struct sk_buff *skb)

 		if (ppp->vj == 0 || (ppp->flags & SC_REJ_COMP_TCP))

 			goto err;
-		if (skb_tailroom(skb) < 124) {

+		if (skb_tailroom(skb) < 124 || skb_cloned(skb)) {

 			/* copy to a new sk_buff with more tailroom */

 			ns = dev_alloc_skb(skb->len + 128);

 			if (ns == 0) {

@@ -1648,23 +1648,29 @@ ppp_receive_nonmp_frame(struct ppp *ppp, struct sk_buff *skb)

 		/* check if the packet passes the pass and active filters */

 		/* the filter instructions are constructed assuming

 		   a four-byte PPP header on each packet */

-		*skb_push(skb, 2) = 0;

-		if (ppp->pass_filter

-		    && sk_run_filter(skb, ppp->pass_filter,

-				     ppp->pass_len) == 0) {

-			if (ppp->debug & 1)

-				printk(KERN_DEBUG "PPP: inbound frame not passed\n");

-			kfree_skb(skb);

-			return;

-		}

-		if (!(ppp->active_filter

-		      && sk_run_filter(skb, ppp->active_filter,

-				       ppp->active_len) == 0))

-			ppp->last_recv = jiffies;

-		skb_p...
[ message continues ]

> I don't want to jump the gun on the analysis but it just might

 > be the packet sharing fixes Herbert put in a short time ago.

 >

 > What you could do is go back to say rc2 and see if you still get

 > the panics, then bisect from there to narrow it down.

 >

 > If rc2 still gives the panic, it's something else, perhaps device

 > specific.
OK thanks.  I'm still trying to find a good way to reproduce it, so

I'm going to try to get it to happen with -rc9 while running in the

console, and at least take a picture of the backtrace.  If I find a

good way to make it happen then I'll try rc2 and let you know.
 - R.

-