From: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com>
To: netdev@vger.kernel.org
Cc: LKML <linux-kernel@vger.kernel.org>,
Linux-IA64 <linux-ia64@vger.kernel.org>
Subject: IPF Montvale machine panic when running a network-relevent testing
Date: Fri, 13 Jun 2008 08:19:20 +0000 [thread overview]
Message-ID: <1213345160.25608.3.camel@ymzhang> (raw)
With kernel 2.6.26-rc5 and a git kernel just between rc4 and rc5, my
kernel panic on my Montvale machine when I did an initial specweb2005
testing between 2 machines.
Below is the log.
LOGIN: Unable to handle kernel NULL pointer dereference (address 0000000000000000)
Thread-7266[13494]: Oops 8804682956800 [1]
Modules linked in:
Pid: 13494, CPU 0, comm: Thread-7266
psr : 0000101008026018 ifs : 800000000000050e ip : [<a00000010087a4b0>] Not tainted (2.6.26-rc4git)
ip is at tcp_rcv_established+0x1450/0x16e0
unat: 0000000000000000 pfs : 000000000000050e rsc : 0000000000000003
rnat: 0000000000000000 bsps: 0000000000000000 pr : 000000000059656b
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70033f
csd : 0000000000000000 ssd : 0000000000000000
b0 : a00000010087a410 b6 : a0000001004c7ac0 b7 : a0000001004c64e0
f6 : 000000000000000000000 f7 : 1003e0000000000000b80
f8 : 10000821f080500000000 f9 : 1003efffffffffffffa58
f10 : 1003edbb7db5f6be58df8 f11 : 1003e0000000000000015
r1 : a0000001010cce90 r2 : e0000003d4530c40 r3 : 0000000000000105
r8 : e000000402533d68 r9 : e000000402533a80 r10 : e000000402533bfc
r11 : 0000000000000004 r12 : e0000003d4537df0 r13 : e0000003d4530000
r14 : 0000000000000000 r15 : e000000401fca180 r16 : e0000003d4530c68
r17 : e000000402572238 r18 : 00000000000000ff r19 : a0000001012c6630
r20 : e0000003d4530c68 r21 : e000000401fca480 r22 : e000000402572658
r23 : e000000402572240 r24 : a0000001012c4e04 r25 : 0000000000000003
r26 : e000000401fca4a8 r27 : e000000402572660 r28 : e00000040a2d2a00
r29 : e00000040a6f83a8 r30 : e00000040a6f8300 r31 : 000000000000000a
Call Trace:
[<a000000100014de0>] show_stack+0x40/0xa0
spà000003d45379c0 bspà000003d4531440
[<a0000001000156f0>] show_regs+0x850/0x8a0
spà000003d4537b90 bspà000003d45313e0
[<a000000100038d10>] die+0x230/0x360
spà000003d4537b90 bspà000003d4531398
[<a00000010005cec0>] ia64_do_page_fault+0x8e0/0xa40
spà000003d4537b90 bspà000003d4531348
[<a00000010000b120>] ia64_leave_kernel+0x0/0x280
spà000003d4537c20 bspà000003d4531348
[<a00000010087a4b0>] tcp_rcv_established+0x1450/0x16e0
spà000003d4537df0 bspà000003d45312d8
[<a000000100888370>] tcp_v4_do_rcv+0x70/0x500
spà000003d4537df0 bspà000003d4531298
[<a00000010088cd30>] tcp_v4_rcv+0xfb0/0x1060
spà000003d4537e00 bspà000003d4531248
As a matter of fact, kernel paniced at statement
"queue->rskq_accept_tail->dl_next = req" in function reqsk_queue_add, because
queue->rskq_accept_tail is NULL. The call chain is:
tcp_rcv_established => inet_csk_reqsk_queue_add => reqsk_queue_add.
As I was running an initial specweb2005(configured 3500 sessions) testing between
2 machines, there were lots of failure and many network connections were
reestablished during the testing.
In function tcp_v4_rcv, bh_lock_sock_nested(sk) (a kind of spinlock) is used to
avoid race. But inet_csk_accept uses lock_sock(sk) (a kind of sleeper). Although
lock_sock also accesses sk->sk_lock.slock, it looks like there is a race.
-yanmin
WARNING: multiple messages have this Message-ID (diff)
From: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com>
To: netdev@vger.kernel.org
Cc: LKML <linux-kernel@vger.kernel.org>,
Linux-IA64 <linux-ia64@vger.kernel.org>
Subject: IPF Montvale machine panic when running a network-relevent testing
Date: Fri, 13 Jun 2008 16:19:20 +0800 [thread overview]
Message-ID: <1213345160.25608.3.camel@ymzhang> (raw)
With kernel 2.6.26-rc5 and a git kernel just between rc4 and rc5, my
kernel panic on my Montvale machine when I did an initial specweb2005
testing between 2 machines.
Below is the log.
LOGIN: Unable to handle kernel NULL pointer dereference (address 0000000000000000)
Thread-7266[13494]: Oops 8804682956800 [1]
Modules linked in:
Pid: 13494, CPU 0, comm: Thread-7266
psr : 0000101008026018 ifs : 800000000000050e ip : [<a00000010087a4b0>] Not tainted (2.6.26-rc4git)
ip is at tcp_rcv_established+0x1450/0x16e0
unat: 0000000000000000 pfs : 000000000000050e rsc : 0000000000000003
rnat: 0000000000000000 bsps: 0000000000000000 pr : 000000000059656b
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70033f
csd : 0000000000000000 ssd : 0000000000000000
b0 : a00000010087a410 b6 : a0000001004c7ac0 b7 : a0000001004c64e0
f6 : 000000000000000000000 f7 : 1003e0000000000000b80
f8 : 10000821f080500000000 f9 : 1003efffffffffffffa58
f10 : 1003edbb7db5f6be58df8 f11 : 1003e0000000000000015
r1 : a0000001010cce90 r2 : e0000003d4530c40 r3 : 0000000000000105
r8 : e000000402533d68 r9 : e000000402533a80 r10 : e000000402533bfc
r11 : 0000000000000004 r12 : e0000003d4537df0 r13 : e0000003d4530000
r14 : 0000000000000000 r15 : e000000401fca180 r16 : e0000003d4530c68
r17 : e000000402572238 r18 : 00000000000000ff r19 : a0000001012c6630
r20 : e0000003d4530c68 r21 : e000000401fca480 r22 : e000000402572658
r23 : e000000402572240 r24 : a0000001012c4e04 r25 : 0000000000000003
r26 : e000000401fca4a8 r27 : e000000402572660 r28 : e00000040a2d2a00
r29 : e00000040a6f83a8 r30 : e00000040a6f8300 r31 : 000000000000000a
Call Trace:
[<a000000100014de0>] show_stack+0x40/0xa0
sp=e0000003d45379c0 bsp=e0000003d4531440
[<a0000001000156f0>] show_regs+0x850/0x8a0
sp=e0000003d4537b90 bsp=e0000003d45313e0
[<a000000100038d10>] die+0x230/0x360
sp=e0000003d4537b90 bsp=e0000003d4531398
[<a00000010005cec0>] ia64_do_page_fault+0x8e0/0xa40
sp=e0000003d4537b90 bsp=e0000003d4531348
[<a00000010000b120>] ia64_leave_kernel+0x0/0x280
sp=e0000003d4537c20 bsp=e0000003d4531348
[<a00000010087a4b0>] tcp_rcv_established+0x1450/0x16e0
sp=e0000003d4537df0 bsp=e0000003d45312d8
[<a000000100888370>] tcp_v4_do_rcv+0x70/0x500
sp=e0000003d4537df0 bsp=e0000003d4531298
[<a00000010088cd30>] tcp_v4_rcv+0xfb0/0x1060
sp=e0000003d4537e00 bsp=e0000003d4531248
As a matter of fact, kernel paniced at statement
"queue->rskq_accept_tail->dl_next = req" in function reqsk_queue_add, because
queue->rskq_accept_tail is NULL. The call chain is:
tcp_rcv_established => inet_csk_reqsk_queue_add => reqsk_queue_add.
As I was running an initial specweb2005(configured 3500 sessions) testing between
2 machines, there were lots of failure and many network connections were
reestablished during the testing.
In function tcp_v4_rcv, bh_lock_sock_nested(sk) (a kind of spinlock) is used to
avoid race. But inet_csk_accept uses lock_sock(sk) (a kind of sleeper). Although
lock_sock also accesses sk->sk_lock.slock, it looks like there is a race.
-yanmin
WARNING: multiple messages have this Message-ID (diff)
From: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com>
To: netdev@vger.kernel.org
Cc: LKML <linux-kernel@vger.kernel.org>,
Linux-IA64 <linux-ia64@vger.kernel.org>
Subject: IPF Montvale machine panic when running a network-relevent testing
Date: Fri, 13 Jun 2008 16:19:20 +0800 [thread overview]
Message-ID: <1213345160.25608.3.camel@ymzhang> (raw)
With kernel 2.6.26-rc5 and a git kernel just between rc4 and rc5, my
kernel panic on my Montvale machine when I did an initial specweb2005
testing between 2 machines.
Below is the log.
LOGIN: Unable to handle kernel NULL pointer dereference (address 0000000000000000)
Thread-7266[13494]: Oops 8804682956800 [1]
Modules linked in:
Pid: 13494, CPU 0, comm: Thread-7266
psr : 0000101008026018 ifs : 800000000000050e ip : [<a00000010087a4b0>] Not tainted (2.6.26-rc4git)
ip is at tcp_rcv_established+0x1450/0x16e0
unat: 0000000000000000 pfs : 000000000000050e rsc : 0000000000000003
rnat: 0000000000000000 bsps: 0000000000000000 pr : 000000000059656b
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70033f
csd : 0000000000000000 ssd : 0000000000000000
b0 : a00000010087a410 b6 : a0000001004c7ac0 b7 : a0000001004c64e0
f6 : 000000000000000000000 f7 : 1003e0000000000000b80
f8 : 10000821f080500000000 f9 : 1003efffffffffffffa58
f10 : 1003edbb7db5f6be58df8 f11 : 1003e0000000000000015
r1 : a0000001010cce90 r2 : e0000003d4530c40 r3 : 0000000000000105
r8 : e000000402533d68 r9 : e000000402533a80 r10 : e000000402533bfc
r11 : 0000000000000004 r12 : e0000003d4537df0 r13 : e0000003d4530000
r14 : 0000000000000000 r15 : e000000401fca180 r16 : e0000003d4530c68
r17 : e000000402572238 r18 : 00000000000000ff r19 : a0000001012c6630
r20 : e0000003d4530c68 r21 : e000000401fca480 r22 : e000000402572658
r23 : e000000402572240 r24 : a0000001012c4e04 r25 : 0000000000000003
r26 : e000000401fca4a8 r27 : e000000402572660 r28 : e00000040a2d2a00
r29 : e00000040a6f83a8 r30 : e00000040a6f8300 r31 : 000000000000000a
Call Trace:
[<a000000100014de0>] show_stack+0x40/0xa0
sp=e0000003d45379c0 bsp=e0000003d4531440
[<a0000001000156f0>] show_regs+0x850/0x8a0
sp=e0000003d4537b90 bsp=e0000003d45313e0
[<a000000100038d10>] die+0x230/0x360
sp=e0000003d4537b90 bsp=e0000003d4531398
[<a00000010005cec0>] ia64_do_page_fault+0x8e0/0xa40
sp=e0000003d4537b90 bsp=e0000003d4531348
[<a00000010000b120>] ia64_leave_kernel+0x0/0x280
sp=e0000003d4537c20 bsp=e0000003d4531348
[<a00000010087a4b0>] tcp_rcv_established+0x1450/0x16e0
sp=e0000003d4537df0 bsp=e0000003d45312d8
[<a000000100888370>] tcp_v4_do_rcv+0x70/0x500
sp=e0000003d4537df0 bsp=e0000003d4531298
[<a00000010088cd30>] tcp_v4_rcv+0xfb0/0x1060
sp=e0000003d4537e00 bsp=e0000003d4531248
As a matter of fact, kernel paniced at statement
"queue->rskq_accept_tail->dl_next = req" in function reqsk_queue_add, because
queue->rskq_accept_tail is NULL. The call chain is:
tcp_rcv_established => inet_csk_reqsk_queue_add => reqsk_queue_add.
As I was running an initial specweb2005(configured 3500 sessions) testing between
2 machines, there were lots of failure and many network connections were
reestablished during the testing.
In function tcp_v4_rcv, bh_lock_sock_nested(sk) (a kind of spinlock) is used to
avoid race. But inet_csk_accept uses lock_sock(sk) (a kind of sleeper). Although
lock_sock also accesses sk->sk_lock.slock, it looks like there is a race.
-yanmin
--
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next reply other threads:[~2008-06-13 8:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-13 8:19 Zhang, Yanmin [this message]
2008-06-13 8:19 ` IPF Montvale machine panic when running a network-relevent testing Zhang, Yanmin
2008-06-13 8:19 ` Zhang, Yanmin
2008-06-13 16:35 ` Rafael J. Wysocki
2008-06-13 16:35 ` Rafael J. Wysocki
2008-06-13 16:35 ` Rafael J. Wysocki
2008-06-18 3:27 ` IPF Montvale machine panic when running a network-relevent Zhang, Yanmin
2008-06-18 3:27 ` IPF Montvale machine panic when running a network-relevent testing Zhang, Yanmin
2008-06-18 3:27 ` Zhang, Yanmin
2008-06-18 3:37 ` IPF Montvale machine panic when running a network-relevent David Miller
2008-06-18 3:37 ` IPF Montvale machine panic when running a network-relevent testing David Miller
2008-06-18 3:37 ` David Miller
2008-06-18 5:12 ` IPF Montvale machine panic when running a network-relevent Zhang, Yanmin
2008-06-18 5:12 ` IPF Montvale machine panic when running a network-relevent testing Zhang, Yanmin
2008-06-18 5:12 ` Zhang, Yanmin
2008-06-18 5:25 ` IPF Montvale machine panic when running a network-relevent David Miller
2008-06-18 5:25 ` IPF Montvale machine panic when running a network-relevent testing David Miller
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=1213345160.25608.3.camel@ymzhang \
--to=yanmin_zhang@linux.intel.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.