# mpd5, PPPoE, STABLE-9, kernel panics



## flv (Aug 20, 2013)

I'm having some issues running a KVM-virtualized FreeBSD 9-STABLE (somewhat four weeks old, so it has the latest netgraph code). I'm also running a 7.4-RELEASE (also virtualized) system on the same machine which has a way better stability record, although not stellar, but I think it would be way more interesting to find out what is keeping my 9-STABLE from being rock solid instead of relying on FreeBSD 7.4.

Right now it serves a 4000 clients network as a PPPoE server. There's also another six servers (non-virtualized), all running 7.4-RELEASE, serving the same network, so I can experiment with my 9-STABLE installation.

I will copy the stack trace from one of the four core.txt files I currently have. If requested I can copy more info, recompile my kernel with debugging flags to test etc. Just ask.


```
Unread portion of the kernel message buffer:
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 32079 (mpd5)
trap number             = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
#0 0xffffffff804b0c86 at kdb_backtrace+0x66
#1 0xffffffff80476bee at panic+0x1ce
#2 0xffffffff806fbc30 at trap_fatal+0x290
#3 0xffffffff806fbf91 at trap_pfault+0x211
#4 0xffffffff806fc544 at trap+0x344
#5 0xffffffff806e5873 at calltrap+0x8
#6 0xffffffff80553e47 at ng_add_hook+0xb7
#7 0xffffffff8055598f at ng_apply_item+0x3bf
#8 0xffffffff80554934 at ng_snd_item+0x3b4
#9 0xffffffff8056400f at ngc_send+0x1df
#10 0xffffffff804e71c6 at sosend_generic+0x3f6
#11 0xffffffff804eaaa3 at kern_sendit+0x1a3
#12 0xffffffff804ead5c at sendit+0xdc
#13 0xffffffff804eae4d at sys_sendto+0x4d
#14 0xffffffff806fb3da at amd64_syscall+0x5ea
#15 0xffffffff806e5b57 at Xfast_syscall+0xf7
Uptime: 3h42m8s
Dumping 118 out of 1011 MB:..14%..27%..41%..54%..68%..81%..95%

#0  doadump (textdump=<value optimized out>) at pcpu.h:234
234     pcpu.h: No such file or directory.
        in pcpu.h
(kgdb) #0  doadump (textdump=<value optimized out>) at pcpu.h:234
#1  0xffffffff804766c6 in kern_reboot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:449
#2  0xffffffff80476bc7 in panic (fmt=0x1 <Address 0x1 out of bounds>)
    at /usr/src/sys/kern/kern_shutdown.c:637
#3  0xffffffff806fbc30 in trap_fatal (frame=0xc, eva=<value optimized out>)
    at /usr/src/sys/amd64/amd64/trap.c:879
#4  0xffffffff806fbf91 in trap_pfault (frame=0xffffff80003c7610, usermode=0)
    at /usr/src/sys/amd64/amd64/trap.c:795
#5  0xffffffff806fc544 in trap (frame=0xffffff80003c7610)
    at /usr/src/sys/amd64/amd64/trap.c:463
#6  0xffffffff806e5873 in calltrap ()
    at /usr/src/sys/amd64/amd64/exception.S:232
#7  0xffffffff80556f86 in ng_bpf_newhook (node=<value optimized out>, 
    hook=0xfffffe0001b9c380, name=0xfffffe0011e71258 "0-0-m")
    at /usr/src/sys/netgraph/ng_bpf.c:249
#8  0xffffffff80553e47 in ng_add_hook (node=0xfffffe0026021100, 
    name=0xfffffe0011e71258 "0-0-m", hookp=0xffffff80003c7808)
    at /usr/src/sys/netgraph/ng_base.c:1092
#9  0xffffffff8055598f in ng_apply_item (node=0xfffffe0026021100, 
    item=0xfffffe0011d90980, rw=1) at /usr/src/sys/netgraph/ng_base.c:1544
#10 0xffffffff80554934 in ng_snd_item (item=<value optimized out>, flags=0)
    at /usr/src/sys/netgraph/ng_base.c:2314
#11 0xffffffff8056400f in ngc_send (so=<value optimized out>, 
    flags=<value optimized out>, m=0xfffffe0011c36000, 
    addr=<value optimized out>, control=<value optimized out>, 
    td=<value optimized out>) at /usr/src/sys/netgraph/ng_socket.c:317
#12 0xffffffff804e71c6 in sosend_generic (so=0xfffffe0001982000, 
    addr=0xfffffe002602fa20, uio=0xffffff80003c7a00, top=0xfffffe0011c36000, 
    control=0x0, flags=<value optimized out>, td=0xfffffe00018ba000)
    at /usr/src/sys/kern/uipc_socket.c:1367
#13 0xffffffff804eaaa3 in kern_sendit (td=0xfffffe00018ba000, s=5, 
    mp=0xffffff80003c7ad0, flags=0, control=0x0, segflg=<value optimized out>)
    at /usr/src/sys/kern/uipc_syscalls.c:811
#14 0xffffffff804ead5c in sendit (td=0xfffffe00018ba000, s=5, 
    mp=0xffffff80003c7ad0, flags=0) at /usr/src/sys/kern/uipc_syscalls.c:739
#15 0xffffffff804eae4d in sys_sendto (td=<value optimized out>, 
    uap=<value optimized out>) at /usr/src/sys/kern/uipc_syscalls.c:863
#16 0xffffffff806fb3da in amd64_syscall (td=0xfffffe00018ba000, traced=0)
    at subr_syscall.c:135
#17 0xffffffff806e5b57 in Xfast_syscall ()
    at /usr/src/sys/amd64/amd64/exception.S:391
#18 0x000000080225adcc in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)
```

Thanks. Any help will be greatly appreciated.


----------



## SirDice (Aug 20, 2013)

Page faults are usually caused by bad hardware, especially memory. So I'd check that first and make sure the hardware is in order. I'd also try to get the latest -STABLE, just to make sure the issue hasn't been resolved yet. If everything is in order I would suggest posting to the mailing lists. I don't think this will be easily solved and may need a developer's attention. There aren't a lot of FreeBSD developers on this board unfortunately. The freebsd-net@ mailing list is probably the right place to ask.


----------

