Bug 460967

Summary: [RHEL4.7] kernel panics when stopping on iptables on kernel 2.6.9-78.0.1
Product: Red Hat Enterprise Linux 4 Reporter: Scott Ramshaw <sramshaw>
Component: kernelAssignee: Thomas Graf <tgraf>
Status: CLOSED DUPLICATE QA Contact: Martin Jenner <mjenner>
Severity: high Docs Contact:
Priority: medium    
Version: 4.7CC: enrique.bonet, nixuser, rkhan, shughes, sramshaw
Target Milestone: rc   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-11-18 00:57:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
image of console screenshot of kernel panic none

Description Scott Ramshaw 2008-09-03 01:06:56 UTC 
Description of problem:
After upgrading to the new RHEL 5.2 kernel 2.6.9-78.0.1 we are experiencing a kernel panic when we shutdown the server, it appears to be when iptables is stopped.  This problem appeared in kernel 2.6.9-78.0.1.

Version-Release number of selected component (if applicable):
kernel 2.6.9-78.0.1
iptables-1.3.5-4.el5

We were able to reproduce this 100% of this time of various hardware and in VMWare, doesn't appear to be any kind of HW driver issue.

How reproducible:
always

Steps to Reproduce:
1. perform stock RHEL 5.2 install
2. modprobe ip_conntrack_ftp
3. /etc/init.d/iptables stop
  
Actual results:
Aug 29 18:44:35 STOCK4ES32Test iptables: succeeded 
Aug 29 18:44:35 STOCK4ES32Test iptables: succeeded 
Aug 29 18:44:35 STOCK4ES32Test kernel: Unable to handle kernel paging request at virtual address f892c168 
Aug 29 18:44:35 STOCK4ES32Test kernel: printing eip: 
Aug 29 18:44:35 STOCK4ES32Test kernel: c02d4877 
Aug 29 18:44:35 STOCK4ES32Test kernel: *pde = 37f09067 
Aug 29 18:44:35 STOCK4ES32Test kernel: Oops: 0000 [#1] 
Aug 29 18:44:35 STOCK4ES32Test kernel: Modules linked in: parport_pc lp parport autofs4 i2c_dev i2c_core sunrpc ip_conntrack cpufreq_powersave dm_mirror dm_mod button battery ac md5 ipv6 e1000 floppy ext3 jbd ata_piix libata mptscsih mptsas mptspi mptscsi mptbase sd_mod scsi_mod 
Aug 29 18:44:35 STOCK4ES32Test kernel: CPU: 0 
Aug 29 18:44:35 STOCK4ES32Test kernel: EIP: 0060:[<c02d4877>] Not tainted VLI 
Aug 29 18:44:35 STOCK4ES32Test kernel: EFLAGS: 00010212 (2.6.9-78.0.1.EL) 
Aug 29 18:44:35 STOCK4ES32Test kernel: EIP is at nf_unregister_sockopt+0x47/0x81 
Aug 29 18:44:35 STOCK4ES32Test kernel: eax: 00000002 ebx: c03a2020 ecx: f6b7ef40 edx: f892c160 
Aug 29 18:44:35 STOCK4ES32Test kernel: esi: f89b0380 edi: 00000000 ebp: f5591000 esp: f5591f5c 
Aug 29 18:44:35 STOCK4ES32Test kernel: ds: 007b es: 007b ss: 0068 
Aug 29 18:44:35 STOCK4ES32Test kernel: Process modprobe (pid: 5698, threadinfo=f5591000 task=f5c198f0) 
Aug 29 18:44:35 STOCK4ES32Test kernel: Stack: 00000000 c037d800 f89a7732 f89b0880 c014030d 00000000 635f7069 746e6e6f 
Aug 29 18:44:35 STOCK4ES32Test kernel: 6b636172 00000000 c195f080 b7f17000 b7f18000 c01602d6 c195f080 f61a5414 
Aug 29 18:44:35 STOCK4ES32Test kernel: c016067b f6be6804 c195f080 c195f0b0 00000000 f5591000 09f42820 00000000 
Aug 29 18:44:35 STOCK4ES32Test kernel: Call Trace: 
Aug 29 18:44:35 STOCK4ES32Test kernel: [<f89a7732>] init_or_cleanup+0x1e6/0x1ea [ip_conntrack] 
Aug 29 18:44:35 STOCK4ES32Test kernel: [<c014030d>] sys_delete_module+0x139/0x180 
Aug 29 18:44:35 STOCK4ES32Test kernel: [<c01602d6>] unmap_vma_list+0xe/0x17 
Aug 29 18:44:35 STOCK4ES32Test kernel: [<c016067b>] do_munmap+0x1a7/0x1b1 
Aug 29 18:44:35 STOCK4ES32Test kernel: [<c0327973>] syscall_call+0x7/0xb 
Aug 29 18:44:35 STOCK4ES32Test kernel: Code: 17 05 00 89 d9 ff 0d 20 20 3a c0 0f 88 40 0d 00 00 8b 0d 48 20 3a c0 8b 01 0f 18 00 90 81 f9 48 20 3a c0 74 2f 8b 51 08 8b 46 08 <39> 42 08 8b 11 75 1e 8b 41 04 89 42 04 89 10 89 c8 c7 01 00 01 
Aug 29 18:44:35 STOCK4ES32Test kernel: <0>Fatal exception: panic in 5 seconds 
[ Show ยป ] Scott Ferry - 02/Sep/08 03:30 PM This issue has been reproduced on a completely stock installation. The steps to reproduce are: modprobe ip_conntrack_ftp /etc/init.d/iptables stop Aug 29 18:44:35 STOCK4ES32Test iptables: succeeded Aug 29 18:44:35 STOCK4ES32Test iptables: succeeded Aug 29 18:44:35 STOCK4ES32Test kernel: Unable to handle kernel paging request at virtual address f892c168 Aug 29 18:44:35 STOCK4ES32Test kernel: printing eip: Aug 29 18:44:35 STOCK4ES32Test kernel: c02d4877 Aug 29 18:44:35 STOCK4ES32Test kernel: *pde = 37f09067 Aug 29 18:44:35 STOCK4ES32Test kernel: Oops: 0000 [#1] Aug 29 18:44:35 STOCK4ES32Test kernel: Modules linked in: parport_pc lp parport autofs4 i2c_dev i2c_core sunrpc ip_conntrack cpufreq_powersave dm_mirror dm_mod button battery ac md5 ipv6 e1000 floppy ext3 jbd ata_piix libata mptscsih mptsas mptspi mptscsi mptbase sd_mod scsi_mod Aug 29 18:44:35 STOCK4ES32Test kernel: CPU: 0 Aug 29 18:44:35 STOCK4ES32Test kernel: EIP: 0060:[<c02d4877>] Not tainted VLI Aug 29 18:44:35 STOCK4ES32Test kernel: EFLAGS: 00010212 (2.6.9-78.0.1.EL) Aug 29 18:44:35 STOCK4ES32Test kernel: EIP is at nf_unregister_sockopt+0x47/0x81 Aug 29 18:44:35 STOCK4ES32Test kernel: eax: 00000002 ebx: c03a2020 ecx: f6b7ef40 edx: f892c160 Aug 29 18:44:35 STOCK4ES32Test kernel: esi: f89b0380 edi: 00000000 ebp: f5591000 esp: f5591f5c Aug 29 18:44:35 STOCK4ES32Test kernel: ds: 007b es: 007b ss: 0068 Aug 29 18:44:35 STOCK4ES32Test kernel: Process modprobe (pid: 5698, threadinfo=f5591000 task=f5c198f0) Aug 29 18:44:35 STOCK4ES32Test kernel: Stack: 00000000 c037d800 f89a7732 f89b0880 c014030d 00000000 635f7069 746e6e6f Aug 29 18:44:35 STOCK4ES32Test kernel: 6b636172 00000000 c195f080 b7f17000 b7f18000 c01602d6 c195f080 f61a5414 Aug 29 18:44:35 STOCK4ES32Test kernel: c016067b f6be6804 c195f080 c195f0b0 00000000 f5591000 09f42820 00000000 Aug 29 18:44:35 STOCK4ES32Test kernel: Call Trace: Aug 29 18:44:35 STOCK4ES32Test kernel: [<f89a7732>] init_or_cleanup+0x1e6/0x1ea [ip_conntrack] Aug 29 18:44:35 STOCK4ES32Test kernel: [<c014030d>] sys_delete_module+0x139/0x180 Aug 29 18:44:35 STOCK4ES32Test kernel: [<c01602d6>] unmap_vma_list+0xe/0x17 Aug 29 18:44:35 STOCK4ES32Test kernel: [<c016067b>] do_munmap+0x1a7/0x1b1 Aug 29 18:44:35 STOCK4ES32Test kernel: [<c0327973>] syscall_call+0x7/0xb Aug 29 18:44:35 STOCK4ES32Test kernel: Code: 17 05 00 89 d9 ff 0d 20 20 3a c0 0f 88 40 0d 00 00 8b 0d 48 20 3a c0 8b 01 0f 18 00 90 81 f9 48 20 3a c0 74 2f 8b 51 08 8b 46 08 <39> 42 08 8b 11 75 1e 8b 41 04 89 42 04 89 10 89 c8 c7 01 00 01 Aug 29 18:44:35 STOCK4ES32Test kernel: <0>Fatal exception: panic in 5 seconds 


Expected results:
service stops normally without kernel panic

Additional info:
Comment 1 Scott Ramshaw 2008-09-03 01:08:04 UTC 
Created attachment 315609 [details]
image of console screenshot of kernel panic
Comment 2 Scott Ramshaw 2008-09-08 21:05:07 UTC 
OOPS I accidentally put Redhat 5 when this bug is for RHEL 4.7

it won't let me edit it now...
Comment 3 Linda Wang 2008-09-19 14:07:24 UTC 
no problem. change Product from RHEL5 to RHEL4,
and reset version to 4.7.
Comment 4 Ian Laurie 2008-09-20 06:34:03 UTC 
Same problem here on a Dell PowerEdge 600SC with 1G RAM.
Comment 5 Enrique V. Bonet Esteban 2008-10-11 11:43:21 UTC 
The kernels 2.6.9-78.0.1.ELsmp and 2.6.9-78.0.5.ELsmp have the same problem in
a Intel SE7520AF2 motherboard.
Comment 6 Thomas Graf 2008-11-18 00:57:55 UTC 

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