This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 167396 - Kernel panic with high network load
Kernel panic with high network load
Status: CLOSED DUPLICATE of bug 167389
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.0
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-02 06:41 EDT by Ilkka Pietikäinen
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-02 13:37:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ilkka Pietikäinen 2005-09-02 06:41:59 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050827 Firefox/1.0.6

Description of problem:
When we execute high load tests overnigth with our cluster. Every morning at least one of the nodes has crashed with kernel panic. Here is the output from netdump:

Unable to handle kernel NULL pointer dereference at virtual address
00000018
 printing eip:
c01a387f
*pde = 3663c001
Oops: 0000 [#1]
SMP
Modules linked in: arpt_mangle arptable_filter arp_tables iptable_filter
ip_tables ip_queue parport_pc lp parport netconsole netdump autofs4
i2c_dev i2c_core sunrpc dm_mod button battery acEIP is at
selinux_ip_postroute_last+0x6a/0x1de
eax: 00000000   ebx: 00000000   ecx: f7b04bb0   edx: 00000003
esi: e81ee680   edi: c0455780   ebp: 00000004   esp: f7b04b8c
ds: 007b   es: 007b   ss: 0068
Process dispatcher (pid: 2625, threadinfo=f7b04000 task=f763f3b0)
Stack: 00000000 ed9b8e00 00000000 dc00cd80 00000002 f88a965a 37e51e9e
00000000
       00000206 000000f5 f88a983c c026f163 e81f0580 f72956e8 c02c3188
000000f2  __kfree_skb+0xf4/0xf7
 [<c02c3188>] packet_rcv+0x2ca/0x2d4
 [<c0273ca8>] dev_queue_xmit_nit+0xc1/0xd3
 [<c01a3a02>] selinux_ipv4_postroute_last+0xf/0x13
 [<c028d11f>] ip_finish_output2+0x0/0x16d
 [<c027cb23>] nf_iterate+0x40/0x81
 [<c028d11f>] ip_finish_output2+0x0/0x16d
 [<c027ce21>] nf_hook_slow+0x47/0xb4
 [<c028d11f>] ip_finish_output2+0x0/0x16d
 [<c028d116>] ip_finish_output+0x1a5/0x1ae
 [<c028d11f>] ip_finish_output2+0x0/0x16d
 [<c028cf66>] dst_output+0xf/0x1a
 [<c027cfdb>] nf_reinject+0x14d/0x1a9
 [<f891401e>] ipq_issue_verdict+0x1e/0x2b [ip_queue]
 [<f8914676>] ipq_set_verdict+0x53/0x5a [ip_queue]
 [<f891472c>] ipq_receive_peer+0x3d/0x46 [ip_queue]
 [<f891487d>] ipq_rcv_sk+0xfc/0x175 [ip_queue]
 [<c0285b11>] netlink_data_ready+0x14/0x44
 [<c028525b>] netlink_sendskb+0x52/0x6c
 [<c028592c>] netlink_sendmsg+0x254/0x263
 [<c011dcf5>] __wake_up+0x29/0x3c
 [<c026b92d>] sock_sendmsg+0xdb/0xf7
 [<c0285ae9>] netlink_recvmsg+0x1ae/0x1c2
 [<c026ba64>] sock_recvmsg+0xef/0x10c
 [<c02c7d34>] common_interrupt+0x18/0x20
 [<c011f6ee>] autoremove_wake_function+0x0/0x2d
 [<c02709ba>] verify_iovec+0x76/0xc2
 [<c026d07c>] sys_sendmsg+0x1ee/0x23b
 [<c026b4fe>] move_addr_to_user+0x67/0x7f
 [<c01335b7>] get_futex_key+0x39/0x108
 [<c0133b04>] unqueue_me+0x73/0x79
 [<c014b9b5>] find_extend_vma+0x12/0x4f
 [<c01335b7>] get_futex_key+0x39/0x108
 [<c026d465>] sys_socketcall+0x1c1/0x1dd
 [<c0125351>] sys_gettimeofday+0x53/0xac
 [<c02c7377>] syscall_call+0x7/0xb
 [<c02c007b>] unix_release_sock+0x15a/0x201
Code: 89 d3 83 c3 2c 0f 84 8c 01 00 00 8b 44 24 7c 31 c9 8d 54 24 24 e8
df 29

The kernel version was 2.6.9-11 that was patched with patch from https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159815
The kernel was compiled for SMP i686.

Version-Release number of selected component (if applicable):
kernel-2.6.9-11

How reproducible:
Always

Steps to Reproduce:
1. Compile the kernel
2. Start the tests with high load (our application does mysql clustering there are lot of connections to database and CPU is used heavily. All connections will go truough ip_queue module).

  

Actual Results:  In 24 hours the panic will happen

Expected Results:  Kernel should continue working

Additional info:

This may be related to

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159815
Comment 1 Suzanne Hillman 2005-09-02 13:37:53 EDT

*** This bug has been marked as a duplicate of 167389 ***

Note You need to log in before you can comment on or make changes to this bug.