From: cagri coltekin <cagri@ripe•net>
To: Herbert Xu <herbert@gondor•apana.org.au>
Cc: netdev@vger•kernel.org, davem@davemloft•net, pekkas@netcore•fi
Subject: Re: PROBLEM: kernel BUG at net/ipv6/ip6_output.c:718
Date: Fri, 1 Sep 2006 18:22:48 +0200 [thread overview]
Message-ID: <20060901162248.GI19284@ripe.net> (raw)
In-Reply-To: <20060901070557.GA15731@gondor.apana.org.au>
On Fri, Sep 01, 2006 at 05:05:57PM +1000, Herbert Xu wrote:
> On Thu, Aug 31, 2006 at 05:12:43PM +0200, cagri coltekin wrote:
> >
> > It took a while to find equipment for test environment, but now I
> > have a test environment that I can test.
> >
> > Here is the result:
> >
> > ---------------------------------------------------------------------------
> > [17180051.768000] ip6_fragment: hlen = 0x818, len = 0x7ce, nexthdr=4
>
> Thanks for the result. It looks like something is screwed up with the
> extension headers. What version of bind are you using?
It's bind 9.3.2, the version we were using had a specific patch.
However, I've just tested with non-patched bind 9.3.2, it does it
too. The system has large number of zones, with most of them
DNSSEC enabled. That may be the reason for the peculiarity. I can
send configuration/zone files etc. if it would be helpful.
> Please try the following patch instead to see if we can further isolate
> the problem.
The second causes the system to give the bug a couple of seconds
after bind starts, and loads the zones, without any traffic going
on. BTW, patch applied with some offset difference (3 for the
first -48 for the other two changes), on a pristine 2.6.17.11
source tree.
Here is the new result:
---------------------------------------------------------------------------------------------
[17199663.616000] ip6_push: hlen = 0x388, len = 0x8f, nexthdr1 = 0, nexthdr2 = 162, proto = 0
[17199663.712000] ip6_push: opt = 0x0, flen = 0, nflen = 0
[17199663.776000] ------------[ cut here ]------------
[17199663.836000] kernel BUG at net/ipv6/ip6_output.c:1215!
[17199663.896000] invalid opcode: 0000 [#1]
[17199663.944000] SMP
[17199663.972000] Modules linked in: ipmi_si ipmi_msghandler ide_cd cdrom
[17199664.048000] CPU: 1
[17199664.048000] EIP: 0060:[<c02bd7b9>] Not tainted VLI
[17199664.048000] EFLAGS: 00010282 (2.6.17.11-ns-pri-debug-p2 #1)
[17199664.220000] EIP is at ip6_push_pending_frames+0x39d/0x42e
[17199664.288000] eax: 0000003e ebx: f60fae80 ecx: c038f5bc edx: 00000286
[17199664.372000] esi: f7258d80 edi: f782ea40 ebp: f6171d00 esp: f60f7c0c
[17199664.456000] ds: 007b es: 007b ss: 0068
[17199664.508000] Process named (pid: 15561, threadinfo=f60f6000 task=f7ae9030)
[17199664.592000] Stack: c03246e0 00000000 00000000 00000000 000000a2 00000000 f6171e88 f7258d80
[17199664.696000] 00000000 f6171edc f782ea48 f60f7c40 00000000 00000000 00000000 00000000
[17199664.800000] 00000000 f6171e90 f6171ea0 f6171e88 f782ea40 c02ce42e f6171d00 00000008
[17199664.904000] Call Trace:
[17199664.936000] <c02ce42e> udp_v6_push_pending_frames+0x13d/0x1a4 <c02cea1f> udpv6_sendmsg+0x58a/0x953
[17199665.048000] <c02a6032> inet_sendmsg+0x4a/0x56 <c0260b82> sock_sendmsg+0xeb/0x105
[17199665.144000] <c01c18cc> __next_cpu+0x22/0x31 <c01167c7> find_busiest_group+0xd6/0x305
[17199665.244000] <c0173c22> file_update_time+0x48/0xcb <c01177e6> dependent_sleeper+0x1ec/0x32d
[17199665.348000] <c012f91e> autoremove_wake_function+0x0/0x57 <c01c662e> copy_from_user+0x46/0x7c
[17199665.456000] <c0267b9c> verify_iovec+0x3c/0x94 <c02626c9> sys_sendmsg+0x191/0x1f8
[17199665.548000] <c02e4ff7> schedule_timeout+0xa8/0xaa <c0133356> unqueue_me+0x56/0x9d
[17199665.644000] <c012f726> add_wait_queue+0x1a/0x46 <c013356a> futex_wait+0x1cd/0x238
[17199665.740000] <c014b75c> find_extend_vma+0x29/0x7e <c01c18cc> __next_cpu+0x22/0x31
[17199665.832000] <c01177e6> dependent_sleeper+0x1ec/0x32d <c01c662e> copy_from_user+0x46/0x7c
[17199665.936000] <c0262b6f> sys_socketcall+0x236/0x254 <c0102be3> syscall_call+0x7/0xb
[17199666.032000] Code: 20 89 44 24 0c 31 c0 85 d2 74 08 8b 54 24 20 0f b7 42 04 89 44 24 08 c7 04 24 e0 46 32 c0 8b 44 24 20 89 44 24 04 e8 54 f6 e5 ff <0f> 0b bf 04 41 13 32 c0 e9 b8 fe ff ff 66 c7 41 04 00 00 e9 21
[17199666.268000] EIP: [<c02bd7b9>] ip6_push_pending_frames+0x39d/0x42e SS:ESP 0068:f60f7c0c
---------------------------------------------------------------------------------------------
Cheers,
--
cagri
next prev parent reply other threads:[~2006-09-01 16:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-27 14:23 PROBLEM: kernel BUG at net/ipv6/ip6_output.c:718 cagri coltekin
2006-08-28 0:16 ` Herbert Xu
2006-08-28 0:49 ` cagri coltekin
2006-08-29 8:28 ` Herbert Xu
2006-08-31 15:12 ` cagri coltekin
2006-09-01 7:05 ` Herbert Xu
2006-09-01 16:22 ` cagri coltekin [this message]
2006-09-25 12:15 ` Herbert Xu
2006-09-26 11:21 ` cagri coltekin
2006-09-28 0:38 ` Herbert Xu
2006-09-28 8:40 ` cagri coltekin
2006-10-03 5:49 ` Herbert Xu
2006-10-03 6:28 ` Herbert Xu
2006-10-03 14:57 ` cagri coltekin
2006-10-03 13:56 ` James Morris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060901162248.GI19284@ripe.net \
--to=cagri@ripe$(echo .)net \
--cc=davem@davemloft$(echo .)net \
--cc=herbert@gondor$(echo .)apana.org.au \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pekkas@netcore$(echo .)fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox