Date: Tue, 12 Feb 2019 13:54:21 -0600 From: Eric van Gyzen <eric@vangyzen.net> To: Pete French <petefrench@ingresso.co.uk>, "Andrey V. Elsukov" <bu7cher@yandex.ru>, freebsd-stable@freebsd.org, freebsd-current <freebsd-current@freebsd.org> Subject: Re: Networking panic on 12 - found the cause Message-ID: <0a0f2668-19f7-ad62-dff4-e2997e57ea5c@vangyzen.net> In-Reply-To: <cc6e7f23-6dfd-e6f7-b001-288da9edc58c@ingresso.co.uk> References: <E1gr2IV-000BqA-VD@dilbert.ingresso.co.uk> <4a350f47-eaca-5aca-9268-bf7a6618e71c@yandex.ru> <cc6e7f23-6dfd-e6f7-b001-288da9edc58c@ingresso.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/12/19 8:53 AM, Pete French wrote:
> I found my panic. If I take everything out of rc.conf and loader.conf
> and sysctl.conf and boot the system it works fine when I add an IP
> address. If I add this one line to sysctl.conf
>
> net.link.ether.inet.garp_rexmit_count=2
>
> Then I get a panic when I configure the interface:
>
> root@serpentine-passive:~ # ifconfig igb0 inet 10.32.10.4/16 up
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0x28
> fault code = supervisor read data, page not present
> instruction pointer = 0x20:0xffffffff80c987f1
> stack pointer = 0x28:0xfffffe00004d5730
> frame pointer = 0x28:0xfffffe00004d5750
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 12 (swi4: clock (0))
> trap number = 12
> panic: page fault
> cpuid = 0
> time = 1549981620
> KDB: stack backtrace:
> #0 0xffffffff80bdfdc7 at kdb_backtrace+0x67
> #1 0xffffffff80b93fa3 at vpanic+0x1a3
> #2 0xffffffff80b93df3 at panic+0x43
> #3 0xffffffff8106a7bf at trap_fatal+0x35f
> #4 0xffffffff8106a819 at trap_pfault+0x49
> #5 0xffffffff81069e3e at trap+0x29e
> #6 0xffffffff810450c5 at calltrap+0x8
> #7 0xffffffff80c986f6 at ether_output+0x6b6
> #8 0xffffffff80d03354 at arprequest+0x4c4
> #9 0xffffffff80d0515c at garp_rexmit+0xbc
> #10 0xffffffff80bade19 at softclock_call_cc+0x129
> #11 0xffffffff80bae2f9 at softclock+0x79
> #12 0xffffffff80b57c57 at ithread_loop+0x1a7
> #13 0xffffffff80b54da2 at fork_exit+0x82
> #14 0xffffffff810460be at fork_trampoline+0xe
I see the same behavior on head (and stable/12).
(kgdb) f
#16 0xffffffff80ce5331 in ether_output_frame (ifp=0xfffff80003672800,
m=0xfffff8000c88b100) at /usr/src/sys/net/if_ethersubr.c:468
468 switch (pfil_run_hooks(V_link_pfil_head, &m, ifp, PFIL_OUT,
0xffffffff80ce5321 <+81>: mov %gs:0x0,%rax
0xffffffff80ce532a <+90>: mov 0x500(%rax),%rax
=> 0xffffffff80ce5331 <+97>: mov 0x28(%rax),%rax
I think this is part of the V_link_pfil_head. I'm not very familiar
with vnet. Does this need a CURVNET_SET(), maybe in garp_rexmit()?
Eric
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0a0f2668-19f7-ad62-dff4-e2997e57ea5c>