Skip site navigation (1)Skip section navigation (2)
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>