Bug #1154
closedKernel panic after connecting to OpenVPN
0%
Description
I have 2.0-BETA5 (i386) built on Fri Dec 31 14:08:23 EST 2010.
After connecting from a client to the firewall via openvpn the kernel panics with:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address= 0x0
fault code= supervisor read, page not present
instruction pointer= 0x20:0x0
stack pointer = 0x28:0xcca52bbc
frame pointer = 0x28:0xcca52bc8
code segment= base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process= 0 (em0 taskq)
trap number= 12
panic: page fault
cpuid = 0
Uptime: 1h22m12s
Cannot dump. Device not defined or unavailable.
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
There is also a report in the forum:
http://forum.pfsense.org/index.php/topic,31721.0.html
Updated by Chris Buechler almost 14 years ago
- Subject changed from Kernel panic to Kernel panic after connecting to OpenVPN
- Category set to Operating System
- Target version set to 2.0
- Affected Version set to 2.0
We've done multiple production 2.0 OpenVPN deployments within the past week even and haven't seen this. Please attach a back trace.
Updated by vito B almost 14 years ago
Chris,
Here is my thread on this also from dec 13
Old snaps worked fine. (oct) this happens on a few different firewalls (diff hardware)
http://forum.pfsense.org/index.php/topic,31031.msg163019.html#msg163019
Hope this helps.
Updated by Nick K almost 14 years ago
We also reference the problem in http://forum.pfsense.org/index.php/topic,31721.0.html
Updated by Nick K almost 14 years ago
Successfully grabbed the panic in developer:
Kernel page fault with the following non-sleepable locks held:
exclusive sleep mutex em0 (EM TX Lock) r = 0 (0xc2f52580) locked @ /usr/pfSensesrc/src/sys/dev/e1000/if_lem.c:1350
KDB: stack backtrace:
X_db_sym_numargs(c0eb7066,e302aa90,c0a41d45,546,0,...) at X_db_sym_numargs+0x146
kdb_backtrace(546,0,ffffffff,c145d1ac,e302aac8,...) at kdb_backtrace+0x29
witness_display_spinlock(c0eb957e,e302aadc,4,1,0,...) at witness_display_spinlock+0x75
witness_warn(5,0,c0ef792d,14,c131b140,...) at witness_warn+0x20d
trap(e302ab68) at trap+0x19e
alltraps(c336dc00,dedeadc0,c336dc00,c336dc00,e302abf0,...) at alltraps+0x1b
m_tag_delete_chain(c336dc00,0,c0e6e512,0,c2ed9bc0,...) at m_tag_delete_chain+0x3f
reallocf(c336dc00,100,0,c0a42798,df,...) at reallocf+0x8a5
uma_zfree_arg(c1d7e380,c336dc00,0,bc,e302ac84,...) at uma_zfree_arg+0x29
m_freem(c336dc00,4,c0e6e512,b87,c2f4e000,...) at m_freem+0x43
ed_probe_RTL80x9(c2f52580,0,c0e6e512,546,c2f525bc,...) at 0xc06ec448
ed_probe_RTL80x9(c2f4e000,1,c0eb8937,4f,c2edb918,...) at 0xc06efe10
taskqueue_run(c2edb900,c2edb918,c0ea5cf0,0,c0eb1f96,...) at taskqueue_run+0x103
taskqueue_thread_loop(c2f525ec,e302ad38,c0eaeb05,344,c131b140,...) at taskqueue_thread_loop+0x68
fork_exit(c0a3afc0,c2f525ec,e302ad38) at fork_exit+0xb8
fork_trampoline() at fork_trampoline+0x8
--- trap 0, eip = 0, esp = 0xe302ad70, ebp = 0 ---
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address= 0xdedeadc0
fault code= supervisor read, page not present
instruction pointer= 0x20:0xc0a60fe8
stack pointer = 0x28:0xe302aba8
frame pointer = 0x28:0xe302abb8
code segment= base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process= 0 (em0 taskq)
[thread pid 0 tid 64050 ]
Stopped at m_tag_delete+0x48: movl 0(%ecx),%eax
db>
Updated by Ermal Luçi almost 14 years ago
Please test with the kernel located at http://files.pfsense.org/kernel.gz
Just copy it to /boot/kernel/kernel.gz and reboot
Updated by Ermal Luçi almost 14 years ago
- Status changed from New to Feedback
You can even update at the next snapshot that will come out.
It should fix the issues.
Updated by Chris Buechler almost 14 years ago
I can't replicate this - anyone else?
Updated by Jim Pingle almost 14 years ago
It's probably one that ermal fixed a few weeks ago. Several people hit it on the forums and they are no longer able to crash it on current snapshots.
Updated by Ermal Luçi almost 14 years ago
- Status changed from Feedback to Closed
- Target version changed from 2.0 to 2.1
This is cause from mbuf tag patch and for 2.0 this is fixed.
I will close it since it is not anymore relevant.
Updated by Peter O almost 14 years ago
I don't know when it's supposed to be fixed but when trying yesterday on a fresh 1.2.3 install with openvm tools, I still got a kernel panic.
Updated by Jim Pingle almost 14 years ago
Peter Overtoom wrote:
I don't know when it's supposed to be fixed but when trying yesterday on a fresh 1.2.3 install with openvm tools, I still got a kernel panic.
That has nothing to do with this ticket. This is for OpenVPN crashing only on 2.0. You may be thinking of another ticket.