Bug 197997

Summary: [panic] ng_pppoe sometimes panics with trap 12 when server drops session
Product: Base System Reporter: Lev A. Serebryakov <lev>
Component: kernAssignee: freebsd-net (Nobody) <net>
Status: Closed Feedback Timeout    
Severity: Affects Only Me CC: eugen, ports
Priority: --- Keywords: needs-qa
Version: CURRENT   
Hardware: amd64   
OS: Any   

Description Lev A. Serebryakov freebsd_committer freebsd_triage 2015-02-24 18:15:15 UTC 
ng_pppoe client (used via net/mpd5) sometimes panics with Trap 12 when server drops session.

It looks like this:

ng_pppoe[f]: no matching session
ng_pppoe[f]: no matching session
ng_pppoe[f]: no matching session
ng_pppoe[f]: no matching session
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x800625008
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff805fb6c0
stack pointer           = 0x28:0xfffffe00f7b175e0
frame pointer           = 0x28:0xfffffe00f7b17620
code segment            = base rx0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 11 (irq259: em1:rx 0)
trap number             = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00f7b17200
panic() at panic+0x1c1/frame 0xfffffe00f7b172c0
trap_fatal() at trap_fatal+0x379/frame 0xfffffe00f7b17320
trap_pfault() at trap_pfault+0x284/frame 0xfffffe00f7b173c0
trap() at trap+0x425/frame 0xfffffe00f7b17520
calltrap() at calltrap+0x8/frame 0xfffffe00f7b17520
--- trap 0xc, rip = 0xffffffff805fb6c0, rsp = 0xfffffe00f7b175e0, rbp = 0xfffffe00f7b17620 ---
pppoe_findsession() at pppoe_findsession+0x80/frame 0xfffffe00f7b17620
ng_pppoe_rcvdata_ether() at ng_pppoe_rcvdata_ether+0x2a3/frame 0xfffffe00f7b176c0
ng_apply_item() at ng_apply_item+0x22e/frame 0xfffffe00f7b17750
ng_snd_item() at ng_snd_item+0x1a3/frame 0xfffffe00f7b17790
ether_demux() at ether_demux+0x204/frame 0xfffffe00f7b177c0
ether_nh_input() at ether_nh_input+0x36c/frame 0xfffffe00f7b17820
netisr_dispatch_src() at netisr_dispatch_src+0x62/frame 0xfffffe00f7b17890
ether_input() at ether_input+0x26/frame 0xfffffe00f7b178b0
vlan_input() at vlan_input+0x14a/frame 0xfffffe00f7b17930
ether_demux() at ether_demux+0x94/frame 0xfffffe00f7b17960
ether_nh_input() at ether_nh_input+0x36c/frame 0xfffffe00f7b179c0
netisr_dispatch_src() at netisr_dispatch_src+0x62/frame 0xfffffe00f7b17a30
ether_input() at ether_input+0x26/frame 0xfffffe00f7b17a50
if_input() at if_input+0xa/frame 0xfffffe00f7b17a60
em_rxeof() at em_rxeof+0x248/frame 0xfffffe00f7b17af0
em_msix_rx() at em_msix_rx+0x33/frame 0xfffffe00f7b17b20
intr_event_execute_handlers() at intr_event_execute_handlers+0xf9/frame 0xfffffe00f7b17b60
ithread_loop() at ithread_loop+0x9c/frame 0xfffffe00f7b17bb0
fork_exit() at fork_exit+0x75/frame 0xfffffe00f7b17bf0
Comment 1 Eugene Grosbein 2015-02-28 13:56:05 UTC 
Do you have crashdump and kgdb backtrace?
Comment 2 Lev A. Serebryakov freebsd_committer freebsd_triage 2015-03-01 12:13:42 UTC 
(In reply to eugen from comment #1)

No :( It is NanoBSD system without any space for crashump & with autoreboot.
Only thing I have is posted panic message from "dmesg" buffer.

I could mot reproduce this now. It happened when my ISP turn off my access for missed payment. Additional complication is, that I place provider link to VLAN with switch (to be able to have 2 links with 1 physical port on router)...
Comment 3 Eugene Grosbein 2015-03-02 10:46:16 UTC 
(In reply to Lev A. Serebryakov from comment #2)

You could attach USB flash drive, create two partitions something like da0s1a and da0s1b and enable dumpdev="/dev/da0s1b" in /etc/rc.conf. There is no need to enable swapping to it. After crashdump generation, you can manually mount da0s1a partition and use savecore(1) to unload crashdump there.
Comment 4 Lev A. Serebryakov freebsd_committer freebsd_triage 2015-03-02 12:22:04 UTC 
(In reply to eugen from comment #3)
Yep, I know, and I prepared already, but I don't know how to trigger this again :)
Comment 5 Eugene Grosbein 2015-03-03 08:02:26 UTC 
(In reply to Lev A. Serebryakov from comment #4)

You could try to install your own PPPoE access server and direct your NanoBSD to it. Access server should always deny login attempts.
Comment 6 Eugene Grosbein freebsd_committer freebsd_triage 2018-07-28 08:25:01 UTC 
Feedback timeout over 3 years.