Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
From: Paul Mackerras <[EMAIL PROTECTED]> Date: Sun, 15 Apr 2007 11:05:53 +1000 > I wrote: > > > So this doesn't change process_input_packet(), which treats the case > > where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is > > 0x03 (PPP_UI) as indicating a packet with a PPP protocol number of > > I meant "the second byte is NOT 0x03", of course. I've applied this patch, thanks Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
Herbert Xu <[EMAIL PROTECTED]> wrote:
>
> Paul Mackerras <[EMAIL PROTECTED]> wrote:
>>
>> So this doesn't change process_input_packet(), which treats the case
>> where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
>> 0x03 (PPP_UI) as indicating a packet with a PPP protocol number of
>> 0xff. Arguably that's wrong since PPP protocol 0xff is reserved, and
>> the RFC does envision the possibility of receiving frames where the
>> control field has values other than 0x03.
>
> Your fix is probably needed too. However, I think the issue that Patrick
> was trying to fix is the case where p[0] != PPP_ALLSTATIONS and therefore
> we'd still have a problem there.
Nevermind, I mixed up != with == so your patch is all we need.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
Your fix is probably needed too. However, I think the issue that Patrick was trying to fix is the case where p[0] != PPP_ALLSTATIONS and therefore we'd still have a problem there. I tested Paul's patch for last few days and I think everything seems ok. The system is stable. Regards Bartek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
Hi Paul:
Paul Mackerras <[EMAIL PROTECTED]> wrote:
>
> So this doesn't change process_input_packet(), which treats the case
> where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
> 0x03 (PPP_UI) as indicating a packet with a PPP protocol number of
> 0xff. Arguably that's wrong since PPP protocol 0xff is reserved, and
> the RFC does envision the possibility of receiving frames where the
> control field has values other than 0x03.
Your fix is probably needed too. However, I think the issue that Patrick
was trying to fix is the case where p[0] != PPP_ALLSTATIONS and therefore
we'd still have a problem there.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
Hi,
I didn't analyse this bug report but probably it
is nearly connected with one of the bugs visible in
a log from this submit:
http://bugzilla.kernel.org/show_bug.cgi?id=8132
On 15-04-2007 02:50, Paul Mackerras wrote:
> David Miller writes:
>
>> Here is Patrick McHardy's patch:
>
> So this doesn't change process_input_packet(), which treats the case
> where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
> 0x03 (PPP_UI) as indicating a packet with a PPP protocol number of
> 0xff. Arguably that's wrong since PPP protocol 0xff is reserved, and
> the RFC does envision the possibility of receiving frames where the
> control field has values other than 0x03.
>
> Therefore I think this patch is probably better. Could people try it
> out and let me know if it fixes the problem?
>
> Paul.
>
> diff --git a/drivers/net/ppp_async.c b/drivers/net/ppp_async.c
> index 933e2f3..caabbc4 100644
> --- a/drivers/net/ppp_async.c
> +++ b/drivers/net/ppp_async.c
> @@ -802,9 +802,9 @@ process_input_packet(struct asyncppp *ap)
>
> /* check for address/control and protocol compression */
> p = skb->data;
> - if (p[0] == PPP_ALLSTATIONS && p[1] == PPP_UI) {
> + if (p[0] == PPP_ALLSTATIONS) {
> /* chop off address/control */
> - if (skb->len < 3)
> + if (p[1] != PPP_UI || skb->len < 3)
> goto err;
> p = skb_pull(skb, 2);
> }
Let's look farther:
>proto = p[0];
>if (proto & 1) {
>/* protocol is compressed */
>skb_push(skb, 1)[0] = 0;
BTW - about Patrick's patch:
skb_push seems to be dependent here on the 1-st char of
skb->data, if above (p[0] != PPP_ALLSTATIONS), but on the
3-rd char otherwise (after skb_pull). But, Patrick's patch
reserves the place for this, looking always at 1-st char
(buf[0]) independently of PPP_ALLSTATIONS char presence,
or otherwise - always treating this char as protocol char.
It looks safe because of PPP_ALLSTATION current value,
but isn't too understandable.
On the other hand, without any reservation in the
ppp_async_input for the (buf[0] == PPP_ALLSTATIONS) case,
probably 4-byte alignement isn't achieved as planned.
>} else {
>if (skb->len < 2)
>goto err;
>proto = (proto << 8) + p[1];
>if (proto == PPP_LCP)
>async_lcp_peek(ap, p, skb->len, 1);
>}
>
>/* queue the frame to be processed */
>skb->cb[0] = ap->state;
>skb_queue_tail(&ap->rqueue, skb);
>ap->rpkt = NULL;
>ap->state = 0;
>return;
>
> err:
>/* frame had an error, remember that, reset SC_TOSS & SC_ESCAPE */
>ap->state = SC_PREV_ERROR;
>if (skb) {
>/* make skb appear as freshly allocated */
Probably this isn't always true and here the problem
started...
>skb_trim(skb, 0);
>skb_reserve(skb, - skb_headroom(skb));
Isn't here lost e.g. NET_SKB_PAD probably reserved by
dev_alloc_skb?
On the other hand - this kind of pad can very good hide
similar reservation problems in many other places - maybe
it should be omitted or somehow counted in WARNs when some
debugging options are active?
Regards,
Jarek P.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
Bartek wrote: > 2007/4/14, David Miller <[EMAIL PROTECTED]>: > >> From: Patrick McHardy <[EMAIL PROTECTED]> >> Date: Thu, 12 Apr 2007 07:43:39 +0200 >> >> > It seems we fail to reserve enough headroom for the case >> > buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI. >> > >> > Can you try this patch please? >> >> Any confirmation of this fix yet? > > > I'm testing that patch, till now everything seems ok. Please test Paul's patch instead and keep everyone CCed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
2007/4/14, David Miller <[EMAIL PROTECTED]>: From: Patrick McHardy <[EMAIL PROTECTED]> Date: Thu, 12 Apr 2007 07:43:39 +0200 > It seems we fail to reserve enough headroom for the case > buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI. > > Can you try this patch please? Any confirmation of this fix yet? I'm testing that patch, till now everything seems ok. Regards Bartek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
I wrote: > So this doesn't change process_input_packet(), which treats the case > where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is > 0x03 (PPP_UI) as indicating a packet with a PPP protocol number of I meant "the second byte is NOT 0x03", of course. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
David Miller writes:
> Here is Patrick McHardy's patch:
So this doesn't change process_input_packet(), which treats the case
where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
0x03 (PPP_UI) as indicating a packet with a PPP protocol number of
0xff. Arguably that's wrong since PPP protocol 0xff is reserved, and
the RFC does envision the possibility of receiving frames where the
control field has values other than 0x03.
Therefore I think this patch is probably better. Could people try it
out and let me know if it fixes the problem?
Paul.
diff --git a/drivers/net/ppp_async.c b/drivers/net/ppp_async.c
index 933e2f3..caabbc4 100644
--- a/drivers/net/ppp_async.c
+++ b/drivers/net/ppp_async.c
@@ -802,9 +802,9 @@ process_input_packet(struct asyncppp *ap)
/* check for address/control and protocol compression */
p = skb->data;
- if (p[0] == PPP_ALLSTATIONS && p[1] == PPP_UI) {
+ if (p[0] == PPP_ALLSTATIONS) {
/* chop off address/control */
- if (skb->len < 3)
+ if (p[1] != PPP_UI || skb->len < 3)
goto err;
p = skb_pull(skb, 2);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
David Miller wrote: > From: Paul Mackerras <[EMAIL PROTECTED]> > Date: Sun, 15 Apr 2007 02:49:28 +1000 > > >>I didn't see the patch (the message that this is a reply to is the >>first one that I have seen in this thread), so I can't comment on it. > > > Here is Patrick McHardy's patch: > > [..] I haven't heard back from Bartek yet. In case the patch is correct, ppp_synctty seems to need the same fix. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Sun, 15 Apr 2007 02:49:28 +1000
> I didn't see the patch (the message that this is a reply to is the
> first one that I have seen in this thread), so I can't comment on it.
Here is Patrick McHardy's patch:
diff --git a/drivers/net/ppp_async.c b/drivers/net/ppp_async.c
index 933e2f3..c68e37f 100644
--- a/drivers/net/ppp_async.c
+++ b/drivers/net/ppp_async.c
@@ -890,6 +890,8 @@ ppp_async_input(struct asyncppp *ap, const unsigned char
*buf,
ap->rpkt = skb;
}
if (skb->len == 0) {
+ int headroom = 0;
+
/* Try to get the payload 4-byte aligned.
* This should match the
* PPP_ALLSTATIONS/PPP_UI/compressed tests in
@@ -897,7 +899,10 @@ ppp_async_input(struct asyncppp *ap, const unsigned char
*buf,
* enough chars here to test buf[1] and buf[2].
*/
if (buf[0] != PPP_ALLSTATIONS)
- skb_reserve(skb, 2 + (buf[0] & 1));
+ headroom += 2;
+ if (buf[0] & 1)
+ headroom += 1;
+ skb_reserve(skb, headroom);
}
if (n > skb_tailroom(skb)) {
/* packet overflowed MRU */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
David Miller writes: > > It seems we fail to reserve enough headroom for the case > > buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI. > > > > Can you try this patch please? > > Any confirmation of this fix yet? Indeed, ppp_async doesn't handle that case correctly. RFC 1662 says: The Control field is a single octet, which contains the binary sequence 0011 (hexadecimal 0x03), the Unnumbered Information (UI) command with the Poll/Final (P/F) bit set to zero. The use of other Control field values may be defined at a later time, or by prior agreement. Frames with unrecognized Control field values SHOULD be silently discarded. In what situation were we getting the frames that cause the problem? I didn't see the patch (the message that this is a reply to is the first one that I have seen in this thread), so I can't comment on it. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
David Miller <[EMAIL PROTECTED]> wrote:
>
>> It seems we fail to reserve enough headroom for the case
>> buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI.
>>
>> Can you try this patch please?
>
> Any confirmation of this fix yet?
FWIW the fix definitely looks correct (the bug has been there for
years at least) and it does match the crash dump. In fact, there
is only a single skb_push (the only thing that can generate an under
panic) in ppp_async.c and this is the one that Patrick has fixed.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Thu, 12 Apr 2007 07:43:39 +0200 > Bartek wrote: > > Hopefully, this time it my bug report should be ok :): > > > > Apr 11 23:53:38 localhost pppd[31289]: rcvd [proto=0x7689] e1 cd 33 f6 > > fd f7 52 e6 58 c9 73 98 bc ff ad d5 b5 a3 e5 d9 1e 77 76 0a 1c 87 59 > > bf 44 cc ac 3b ... > > Apr 11 23:53:38 localhost pppd[31289]: Unsupported protocol 0x7689 received > > Apr 11 23:53:38 localhost pppd[31289]: sent [LCP ProtRej id=0x9 76 89 > > e1 cd 33 f6 fd f7 52 e6 58 c9 73 98 bc ff ad d5 b5 a3 e5 d9 1e 77 76 > > 0a 1c 87 59 bf 44 cc ...] > > Apr 11 23:53:38 localhost pppd[31289]: rcvd [proto=0xda7d] 15 19 45 3c > > e0 ac 44 92 3b c4 8e 75 6b b8 4a 9f 4a 3a 22 63 d3 a1 56 98 47 62 bc > > cd a6 8e d5 77 ... > > Apr 11 23:53:38 localhost pppd[31289]: Unsupported protocol 0xda7d received > > Apr 11 23:53:38 localhost pppd[31289]: sent [LCP ProtRej id=0xa da 7d > > 15 19 45 3c e0 ac 44 92 3b c4 8e 75 6b b8 4a 9f 4a 3a 22 63 d3 a1 56 > > 98 47 62 bc cd a6 8e ...] > > Apr 11 23:53:40 localhost kernel: skb_under_panic: text:f8c62c0e > > len:291 put:1 head:ddc94800 data:ddc947ff tail:ddc94922 end:ddc94e00 > > dev: > > > It seems we fail to reserve enough headroom for the case > buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI. > > Can you try this patch please? Any confirmation of this fix yet? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
Bartek wrote:
> Hopefully, this time it my bug report should be ok :):
>
> Apr 11 23:53:38 localhost pppd[31289]: rcvd [proto=0x7689] e1 cd 33 f6
> fd f7 52 e6 58 c9 73 98 bc ff ad d5 b5 a3 e5 d9 1e 77 76 0a 1c 87 59
> bf 44 cc ac 3b ...
> Apr 11 23:53:38 localhost pppd[31289]: Unsupported protocol 0x7689 received
> Apr 11 23:53:38 localhost pppd[31289]: sent [LCP ProtRej id=0x9 76 89
> e1 cd 33 f6 fd f7 52 e6 58 c9 73 98 bc ff ad d5 b5 a3 e5 d9 1e 77 76
> 0a 1c 87 59 bf 44 cc ...]
> Apr 11 23:53:38 localhost pppd[31289]: rcvd [proto=0xda7d] 15 19 45 3c
> e0 ac 44 92 3b c4 8e 75 6b b8 4a 9f 4a 3a 22 63 d3 a1 56 98 47 62 bc
> cd a6 8e d5 77 ...
> Apr 11 23:53:38 localhost pppd[31289]: Unsupported protocol 0xda7d received
> Apr 11 23:53:38 localhost pppd[31289]: sent [LCP ProtRej id=0xa da 7d
> 15 19 45 3c e0 ac 44 92 3b c4 8e 75 6b b8 4a 9f 4a 3a 22 63 d3 a1 56
> 98 47 62 bc cd a6 8e ...]
> Apr 11 23:53:40 localhost kernel: skb_under_panic: text:f8c62c0e
> len:291 put:1 head:ddc94800 data:ddc947ff tail:ddc94922 end:ddc94e00
> dev:
It seems we fail to reserve enough headroom for the case
buf[0] == PPP_ALLSTATIONS and buf[1] != PPP_UI.
Can you try this patch please?
diff --git a/drivers/net/ppp_async.c b/drivers/net/ppp_async.c
index 933e2f3..c68e37f 100644
--- a/drivers/net/ppp_async.c
+++ b/drivers/net/ppp_async.c
@@ -890,6 +890,8 @@ ppp_async_input(struct asyncppp *ap, const unsigned char
*buf,
ap->rpkt = skb;
}
if (skb->len == 0) {
+ int headroom = 0;
+
/* Try to get the payload 4-byte aligned.
* This should match the
* PPP_ALLSTATIONS/PPP_UI/compressed tests in
@@ -897,7 +899,10 @@ ppp_async_input(struct asyncppp *ap, const unsigned char
*buf,
* enough chars here to test buf[1] and buf[2].
*/
if (buf[0] != PPP_ALLSTATIONS)
- skb_reserve(skb, 2 + (buf[0] & 1));
+ headroom += 2;
+ if (buf[0] & 1)
+ headroom += 1;
+ skb_reserve(skb, headroom);
}
if (n > skb_tailroom(skb)) {
/* packet overflowed MRU */
Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
It is not enough to unload proprietary modules. As long as they have ever been loaded at all the kernel is tainted. You need to ensure that the proprietary modules never get loaded at all. I guess you probably already worked that out, just wanted to point it out just in case :-) Hopefully, this time it my bug report should be ok :): Apr 11 23:53:38 localhost pppd[31289]: rcvd [proto=0x7689] e1 cd 33 f6 fd f7 52 e6 58 c9 73 98 bc ff ad d5 b5 a3 e5 d9 1e 77 76 0a 1c 87 59 bf 44 cc ac 3b ... Apr 11 23:53:38 localhost pppd[31289]: Unsupported protocol 0x7689 received Apr 11 23:53:38 localhost pppd[31289]: sent [LCP ProtRej id=0x9 76 89 e1 cd 33 f6 fd f7 52 e6 58 c9 73 98 bc ff ad d5 b5 a3 e5 d9 1e 77 76 0a 1c 87 59 bf 44 cc ...] Apr 11 23:53:38 localhost pppd[31289]: rcvd [proto=0xda7d] 15 19 45 3c e0 ac 44 92 3b c4 8e 75 6b b8 4a 9f 4a 3a 22 63 d3 a1 56 98 47 62 bc cd a6 8e d5 77 ... Apr 11 23:53:38 localhost pppd[31289]: Unsupported protocol 0xda7d received Apr 11 23:53:38 localhost pppd[31289]: sent [LCP ProtRej id=0xa da 7d 15 19 45 3c e0 ac 44 92 3b c4 8e 75 6b b8 4a 9f 4a 3a 22 63 d3 a1 56 98 47 62 bc cd a6 8e ...] Apr 11 23:53:40 localhost kernel: skb_under_panic: text:f8c62c0e len:291 put:1 head:ddc94800 data:ddc947ff tail:ddc94922 end:ddc94e00 dev: Apr 11 23:53:40 localhost kernel: [ cut here ] Apr 11 23:53:40 localhost kernel: kernel BUG at net/core/skbuff.c:111! Apr 11 23:53:40 localhost kernel: invalid opcode: [#1] Apr 11 23:53:40 localhost kernel: Modules linked in: nfs nfsd exportfs lockd nfs_acl sunrpc button xt_TCPMSS xt_limit xt_tcpudp nf_nat_irc nf_nat_ftp iptable_nat iptable_mangle ipt_LOG ipt_MASQUERADE nf_nat ipt_TOS ipt_REJECT nf_conntrack_irc nf_conntrack_ftp nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink iptable_filter ip_tables x_tables ppp_async ipv6 ppp_generic slhc xfs fuse eeprom w83781d w83627hf hwmon_vid i2c_isa ide_generic parport_pc parport i2c_viapro floppy i2c_core serio_raw snd_via82xx snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc snd_mpu401_uart via_ircc snd_rawmidi snd_seq_device irda rtc psmouse via_agp agpgart snd soundcore pcspkr crc_ccitt evdev ext3 jbd mbcache usbhid ide_cd cdrom ide_disk generic uhci_hcd usbcore via82cxxx ide_core e100 mii thermal processor fan Apr 11 23:53:40 localhost kernel: CPU:0 Apr 11 23:53:40 localhost kernel: EIP:0060:[]Not tainted VLI Apr 11 23:53:40 localhost kernel: EFLAGS: 00010096 (2.6.21-rc6 #3) Apr 11 23:53:40 localhost kernel: EIP is at skb_under_panic+0x59/0x5d Apr 11 23:53:40 localhost kernel: eax: 0072 ebx: ddc94800 ecx: edx: Apr 11 23:53:40 localhost kernel: esi: edi: ddc94924 ebp: ddc9491e esp: c1ce5ed8 Apr 11 23:53:40 localhost kernel: ds: 007b es: 007b fs: 00d8 gs: ss: 0068 Apr 11 23:53:40 localhost kernel: Process events/0 (pid: 3, ti=c1ce4000 task=dfd02030 task.ti=c1ce4000) Apr 11 23:53:40 localhost kernel: Stack: c02c47d0 f8c62c0e 0123 0001 ddc94800 ddc947ff ddc94922 ddc94e00 Apr 11 23:53:40 localhost kernel:c02b7ed8 dfd23a60 00ff f8c62c13 0282 dfff5c20 f7e67c00 0208 Apr 11 23:53:40 localhost kernel:f0e45d34 f0e45c34 f7e67c00 0202 e0f7d600 0006 f0e45c00 f7e67c0c Apr 11 23:53:40 localhost kernel: Call Trace: Apr 11 23:53:40 localhost kernel: [] ppp_asynctty_receive+0x3b0/0x584 [ppp_async] Apr 11 23:53:40 localhost kernel: [] ppp_asynctty_receive+0x3b5/0x584 [ppp_async] Apr 11 23:53:40 localhost kernel: [] flush_to_ldisc+0xe6/0x124 Apr 11 23:53:40 localhost kernel: [] flush_to_ldisc+0x0/0x124 Apr 11 23:53:40 localhost kernel: [] run_workqueue+0x70/0x101 Apr 11 23:53:40 localhost kernel: [] worker_thread+0x105/0x12e Apr 11 23:53:40 localhost kernel: [] default_wake_function+0x0/0xc Apr 11 23:53:40 localhost kernel: [] worker_thread+0x0/0x12e Apr 11 23:53:40 localhost kernel: [] kthread+0xa0/0xc8 Apr 11 23:53:40 localhost kernel: [] kthread+0x0/0xc8 Apr 11 23:53:40 localhost kernel: [] kernel_thread_helper+0x7/0x10 Apr 11 23:53:40 localhost kernel: === Apr 11 23:53:40 localhost kernel: Code: 00 00 89 5c 24 14 8b 98 a0 00 00 00 89 54 24 0c 89 5c 24 10 8b 40 60 89 4c 24 04 c7 04 24 d0 47 2c c0 89 44 24 08 e8 af c5 ef ff <0f> 0b eb fe 56 53 bb d8 7e 2b c0 83 ec 24 8b 70 14 85 f6 0f 45 Apr 11 23:53:40 localhost kernel: EIP: [] skb_under_panic+0x59/0x5d SS:ESP 0068:c1ce5ed8 Apr 11 23:54:01 localhost /USR/SBIN/CRON[32147]: (root) CMD (/usr/local/bin/pppd_test.sh) Apr 11 23:54:31 localhost pppd[31289]: No response to 5 echo-requests Apr 11 23:54:31 localhost pppd[31289]: Serial link appears to be disconnected. Apr 11 23:54:31 localhost pppd[31289]: Connect time 34.0 minutes. Apr 11 23:54:31 localhost pppd[31289]: Sent 6451377 bytes, received 21004296 bytes. Apr 11 23:54:31 localhost pppd[31289]: Script /etc/ppp/ip-down started (pid 32149) Apr 11 23:54:31 localhost pppd[31289]: sent [LCP TermReq id=0xb "Peer not responding"] Apr 11 23:54:31 localhos
Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
On 10/04/07, Bartek <[EMAIL PROTECTED]> wrote: > Apr 8 21:47:22 localhost kernel: EIP:0060:[] > Tainted: P VLI Someone in private took me a noticed of a still tainted kernel. I didn't noticed that, I am sorry for that. I was sure that unloaded proprietary modules should resolve the problem. My fault. I will try to reproduce the crash again. It is not enough to unload proprietary modules. As long as they have ever been loaded at all the kernel is tainted. You need to ensure that the proprietary modules never get loaded at all. I guess you probably already worked that out, just wanted to point it out just in case :-) -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
Apr 8 21:47:22 localhost kernel: EIP:0060:[] Tainted: P VLI Someone in private took me a noticed of a still tainted kernel. I didn't noticed that, I am sorry for that. I was sure that unloaded proprietary modules should resolve the problem. My fault. I will try to reproduce the crash again. Regards Bartek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
Please reproduce and provide a new crash dump without the nvidia binary-only module loaded. Hi again, Here is a new crash dump (I also removed vmnet and vmmon properitary modules), this time I also included a lspci output: Apr 8 21:47:21 localhost pppd[2114]: rcvd [proto=0xfc3b] bc d4 80 eb 43 62 d0 7e 6d 27 0a e0 22 e4 8d e6 3e f1 a3 10 39 c8 fd cb e7 23 db f1 cf a8 e0 4d ... Apr 8 21:47:21 localhost pppd[2114]: Unsupported protocol 0xfc3b received Apr 8 21:47:21 localhost pppd[2114]: sent [LCP ProtRej id=0x75 fc 3b bc d4 80 eb 43 62 d0 7e 6d 27 0a e0 22 e4 8d e6 3e f1 a3 10 39 c8 fd cb e7 23 db f1 cf a8 ...] Apr 8 21:47:22 localhost pppd[2114]: rcvd [proto=0xcd] f7 4e 69 54 c1 d2 82 d3 bf 1c 33 46 a1 ee 90 97 14 7c a7 23 9d 84 c3 d4 ff 6c ec 25 a7 65 a3 bd ... Apr 8 21:47:22 localhost pppd[2114]: Unsupported protocol 0xcd received Apr 8 21:47:22 localhost pppd[2114]: sent [LCP ProtRej id=0x76 00 cd f7 4e 69 54 c1 d2 82 d3 bf 1c 33 46 a1 ee 90 97 14 7c a7 23 9d 84 c3 d4 ff 6c ec 25 a7 65 ...] Apr 8 21:47:22 localhost kernel: skb_under_panic: text:f8c3cc0e len:1268 put:1 head:c399f800 data:c399f7ff tail:c399fcf3 end:c399fe00 dev: Apr 8 21:47:22 localhost kernel: [ cut here ] Apr 8 21:47:22 localhost kernel: kernel BUG at net/core/skbuff.c:111! Apr 8 21:47:22 localhost kernel: invalid opcode: [#1] Apr 8 21:47:22 localhost kernel: Modules linked in: nfs nfsd exportfs lockd nfs_acl sunrpc button xt_TCPMSS xt_limit xt_tcpudp nf_nat_irc nf_nat_ftp iptable_nat iptable_mangle ipt_LOG ipt_MASQUERADE nf_nat ipt_TOS ipt_REJECT nf_conntrack_irc nf_conntrack_ftp nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink iptable_filter ip_tables x_tables ppp_async ipv6 ppp_generic slhc xfs eeprom w83781d w83627hf hwmon_vid i2c_isa ide_generic snd_via82xx snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc i2c_viapro snd_mpu401_uart i2c_core via_ircc snd_rawmidi snd_seq_device floppy snd serio_raw soundcore irda rtc psmouse via_agp agpgart crc_ccitt pcspkr evdev ext3 jbd mbcache usbhid ide_cd cdrom ide_disk generic uhci_hcd usbcore via82cxxx ide_core e100 mii thermal processor fan Apr 8 21:47:22 localhost kernel: CPU:0 Apr 8 21:47:22 localhost kernel: EIP:0060:[] Tainted: P VLI Apr 8 21:47:22 localhost kernel: EFLAGS: 00010096 (2.6.21-rc6 #3) Apr 8 21:47:22 localhost kernel: EIP is at skb_under_panic+0x59/0x5d Apr 8 21:47:22 localhost kernel: eax: 0073 ebx: c399f800 ecx: edx: Apr 8 21:47:22 localhost kernel: esi: edi: c399fcf5 ebp: c399fcf1 esp: c1ce5ed8 Apr 8 21:47:22 localhost kernel: ds: 007b es: 007b fs: 00d8 gs: ss: 0068 Apr 8 21:47:22 localhost kernel: Process events/0 (pid: 3, ti=c1ce4000 task=dfd02030 task.ti=c1ce4000) Apr 8 21:47:22 localhost kernel: Stack: c02c47d0 f8c3cc0e 04f4 0001 c399f800 c399f7ff c399fcf3 c399fe00 Apr 8 21:47:22 localhost kernel:c02b7ed8 f7ef5600 00ff f8c3cc13 dfff5c20 c1fee800 0208 Apr 8 21:47:22 localhost kernel:c1fee5ad c1fee4ad c1fee800 0202 dfd7ce00 0004 c1fee400 c1fee80c Apr 8 21:47:22 localhost kernel: Call Trace: Apr 8 21:47:22 localhost kernel: [] ppp_asynctty_receive+0x3b0/0x584 [ppp_async] Apr 8 21:47:22 localhost kernel: [] ppp_asynctty_receive+0x3b5/0x584 [ppp_async] Apr 8 21:47:22 localhost kernel: [] flush_to_ldisc+0xe6/0x124 Apr 8 21:47:22 localhost kernel: [] flush_to_ldisc+0x0/0x124 Apr 8 21:47:22 localhost kernel: [] run_workqueue+0x70/0x101 Apr 8 21:47:22 localhost kernel: [] worker_thread+0x105/0x12e Apr 8 21:47:22 localhost kernel: [] default_wake_function+0x0/0xc Apr 8 21:47:22 localhost kernel: [] worker_thread+0x0/0x12e Apr 8 21:47:23 localhost kernel: [] kthread+0xa0/0xc8 Apr 8 21:47:23 localhost kernel: [] kthread+0x0/0xc8 Apr 8 21:47:23 localhost kernel: [] kernel_thread_helper+0x7/0x10 Apr 8 21:47:23 localhost kernel: === Apr 8 21:47:23 localhost kernel: Code: 00 00 89 5c 24 14 8b 98 a0 00 00 00 89 54 24 0c 89 5c 24 10 8b 40 60 89 4c 24 04 c7 04 24 d0 47 2c c0 89 44 24 08 e8 af c5 ef ff <0f> 0b eb fe 56 53 bb d8 7e 2b c0 83 ec 24 8b 70 14 85 f6 0f 45 Apr 8 21:47:23 localhost kernel: EIP: [] skb_under_panic+0x59/0x5d SS:ESP 0068:c1ce5ed8 Apr 8 21:48:01 localhost /USR/SBIN/CRON[6287]: (root) CMD (/usr/local/bin/pppd_test.sh) Apr 8 21:48:09 localhost pppd[2114]: No response to 5 echo-requests Apr 8 21:48:09 localhost pppd[2114]: Serial link appears to be disconnected. Apr 8 21:48:09 localhost pppd[2114]: Connect time 522.7 minutes. Apr 8 21:48:09 localhost pppd[2114]: Sent 57811374 bytes, received 186299345 bytes. Apr 8 21:48:09 localhost pppd[2114]: Script /etc/ppp/ip-down started (pid 6289) Apr 8 21:48:09 localhost pppd[2114]: sent [LCP TermReq id=0x77 "Peer not responding"] Apr 8 21:48:09 localhost pppd[2114]: Script /etc/ppp/ip-down finished (pid 6289), status = 0x0 Apr 8 21:48:12 localhost pppd[2114]: sent [LCP TermReq id=0x78 "Peer no
Re: kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
From: Bartek <[EMAIL PROTECTED]> Date: Sat, 7 Apr 2007 20:11:13 +0200 > I have problem with a Linux kernel oops. It mostly appears when I > download files using bittorrent or other large file. I have a phone > modem based Internet access using Home Internet Solution > (http://en.wikipedia.org/wiki/Home_internet_Solution). I use Debian > testing, Linux vanilla version: 2.6.21-rc6 (however I noticed that > problem since Linux ver. 2.6.15, doesn't matter if that was vanilla > kernel or from Debian distro), Here my sys info: Please reproduce and provide a new crash dump without the nvidia binary-only module loaded. Thank you. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kernel BUG at net/core/skbuff.c in linux-2.6.21-rc6
Hallo I have problem with a Linux kernel oops. It mostly appears when I download files using bittorrent or other large file. I have a phone modem based Internet access using Home Internet Solution (http://en.wikipedia.org/wiki/Home_internet_Solution). I use Debian testing, Linux vanilla version: 2.6.21-rc6 (however I noticed that problem since Linux ver. 2.6.15, doesn't matter if that was vanilla kernel or from Debian distro), Here my sys info: Linux mars 2.6.21-rc6 #3 Sat Apr 7 16:11:12 CEST 2007 i686 GNU/Linux Gnu C 4.1.2 Gnu make 3.81 binutils 2.17 util-linux 2.12r mount 2.12r module-init-tools 3.3-pre2 e2fsprogs 1.40-WIP xfsprogs 2.8.11 PPP2.4.4 Linux C Library2.3.6 Dynamic linker (ldd) 2.3.6 Procps 3.2.7 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.97 udev 105 Modules Loaded nvidia vmnet vmmon nfs nfsd exportfs lockd nfs_acl sunrpc button xt_TCPMSS xt_limit xt_tcpudp nf_nat_irc nf_nat_ftp iptable_nat iptable_mangle ipt_LOG ipt_MASQUERADE nf_nat ipt_TOS ipt_REJECT nf_conntrack_irc nf_conntrack_ftp nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink iptable_filter ip_tables x_tables ppp_async ipv6 ppp_generic slhc xfs eeprom w83781d w83627hf hwmon_vid i2c_isa ide_generic parport_pc parport rtc floppy serio_raw pcspkr psmouse i2c_viapro snd_via82xx snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc snd_mpu401_uart i2c_core via_ircc snd_rawmidi snd_seq_device via_agp agpgart snd irda crc_ccitt soundcore evdev ext3 jbd mbcache usbhid ide_cd cdrom ide_disk generic uhci_hcd usbcore via82cxxx ide_core e100 mii thermal processor fan If there are needs for more info, don't hesitate to ask. If anyone can help me and write a patch, I'll be appreciated. Here is a log from syslog: Apr 7 17:45:52 localhost kernel: skb_under_panic: text:f8e36c0e len:107 put:1 head:df928000 data:df927fff tail:df92806a end:df928600 dev: Apr 7 17:45:52 localhost kernel: [ cut here ] Apr 7 17:45:52 localhost kernel: kernel BUG at net/core/skbuff.c:111! Apr 7 17:45:52 localhost kernel: invalid opcode: [#1] Apr 7 17:45:52 localhost kernel: Modules linked in: w83781d w83627hf i2c_dev nvidia(P) nfs nfsd exportfs lockd nfs_acl sunrpc button xt_TCPMSS xt_limit xt_tcpudp nf_nat_irc nf_nat_ftp iptable_nat iptable_mangle ipt_LOG ipt_MASQUERADE nf_nat ipt_TOS ipt_REJECT nf_conntrack_irc nf_conntrack_ftp nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink iptable_filter ip_tables x_tables ppp_async ipv6 ppp_generic slhc xfs eeprom hwmon_vid i2c_isa ide_generic rtc snd_via82xx snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc snd_mpu401_uart i2c_viapro i2c_core serio_raw snd_rawmidi snd_seq_device via_ircc psmouse pcspkr floppy irda snd crc_ccitt soundcore via_agp agpgart evdev ext3 jbd mbcache usbhid ide_cd cdrom ide_disk generic uhci_hcd usbcore via82cxxx ide_core e100 mii thermal processor fan Apr 7 17:45:52 localhost kernel: CPU:0 Apr 7 17:45:52 localhost kernel: EIP:0060:[] Tainted: P VLI Apr 7 17:45:52 localhost kernel: EFLAGS: 00010096 (2.6.21-rc6 #2) Apr 7 17:45:52 localhost kernel: EIP is at skb_under_panic+0x59/0x5d Apr 7 17:45:52 localhost kernel: eax: 0072 ebx: df928000 ecx: edx: Apr 7 17:45:52 localhost kernel: esi: edi: df92806c ebp: df92806b esp: c17e5ed8 Apr 7 17:45:52 localhost kernel: ds: 007b es: 007b fs: 00d8 gs: ss: 0068 Apr 7 17:45:52 localhost kernel: Process events/0 (pid: 3, ti=c17e4000 task=dfd02030 task.ti=c17e4000) Apr 7 17:45:52 localhost kernel: Stack: c02c4d51 f8e36c0e 006b 0001 df928000 df927fff df92806a df928600 Apr 7 17:45:52 localhost kernel:c02b83d5 e366f8e0 00ff f8e36c13 c01044d7 c17e4000 Apr 7 17:45:52 localhost kernel:f7f9f576 f7f9f476 f6b9a800 0202 dfe60c00 0001 f7f9f400 f6b9a80c Apr 7 17:45:52 localhost kernel: Call Trace: Apr 7 17:45:52 localhost kernel: [] ppp_asynctty_receive+0x3b0/0x584 [ppp_async] Apr 7 17:45:52 localhost kernel: [] ppp_asynctty_receive+0x3b5/0x584 [ppp_async] Apr 7 17:45:52 localhost kernel: [] common_interrupt+0x23/0x28 Apr 7 17:45:52 localhost kernel: [] flush_to_ldisc+0xe6/0x124 Apr 7 17:45:52 localhost kernel: [] flush_to_ldisc+0x0/0x124 Apr 7 17:45:52 localhost kernel: [] run_workqueue+0x70/0x101 Apr 7 17:45:52 localhost kernel: [] worker_thread+0x105/0x12e Apr 7 17:45:52 localhost kernel: [] default_wake_function+0x0/0xc Apr 7 17:45:52 localhost kernel: [] worker_thread+0x0/0x12e Apr 7 17:45:52 localhost kernel: [] kthread+0xa0/0xc8 Apr 7 17:45:52 localhost kernel: [] kthread+0x0/0xc8 Apr 7 17:45:52 localhost kernel: [] kernel_thread_helper+0x7/0x10 Apr 7 17:45:52 localhost kernel: === Apr 7 17:45:52 localhost kernel: Code: 00 00 89 5c 24 14
