so, having got a workaround for yesterdays problems, I now went to upgrade my
other pair of boxes using CARP. No 'pf' on these, just one shared
address.
This is the setup I have tested in development and it works fine.
I install the new kenel and do the first reboot - and I get the panic
below. Maybe its not carp related, but seems suspicious as the last
thing it spits out is a carp message.
Note this is the first reboot - so 12.0 kernel with the 11 userland, in
perparation for the installworld step. Machine is booting from, ZFS and also
has a GELI partition contain some data which requires a manual password.
Setting hostuuid: 49434d53-0200-9031-2500-31902500d9bf.
Setting hostid: 0xf41a3f2e.
Starting file system checks:
Mounting local filesystems:.
ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib
32-bit compatibility ldconfig path: /usr/lib32
Setting hostname: serpentine-passive.telehouse-internal.ingresso.co.uk.
Setting up harvesting:
PURE_RDRAND,[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
Feeding entropy: .
lo0: link state changed to UP
em0: promiscuous mode enabled
carp: demoted by 240 to 240 (interface down)
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:0xffffffff80ca0de1
stack pointer = 0x28:0xfffffe00004da740
frame pointer = 0x28:0xfffffe00004da760
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 = 1547727391
KDB: stack backtrace:
#0 0xffffffff80be8597 at kdb_backtrace+0x67
#1 0xffffffff80b9ccf3 at vpanic+0x1a3
#2 0xffffffff80b9cb43 at panic+0x43
#3 0xffffffff8107382f at trap_fatal+0x35f
#4 0xffffffff81073889 at trap_pfault+0x49
#5 0xffffffff81072eae at trap+0x29e
#6 0xffffffff8104e1a5 at calltrap+0x8
#7 0xffffffff80ca0ce6 at ether_output+0x6b6
#8 0xffffffff80d0bda4 at arprequest+0x4c4
#9 0xffffffff80d0d9fc at garp_rexmit+0xbc
#10 0xffffffff80bb6ba9 at softclock_call_cc+0x129
#11 0xffffffff80bb7089 at softclock+0x79
#12 0xffffffff80b60e79 at ithread_loop+0x169
#13 0xffffffff80b5e012 at fork_exit+0x82
#14 0xffffffff8104f18e at fork_trampoline+0xe
Uptime: 19s
On Thu, Jan 17, 2019 at 4:21 AM Pete French <petefrench at ingresso.co.uk> wrote:> so, having got a workaround for yesterdays problems, I now went to upgrade > my > other pair of boxes using CARP. No 'pf' on these, just one shared address. > This is the setup I have tested in development and it works fine. > > I install the new kenel and do the first reboot - and I get the panic > below. Maybe its not carp related, but seems suspicious as the last > thing it spits out is a carp message. > > Note this is the first reboot - so 12.0 kernel with the 11 userland, in > perparation for the installworld step. Machine is booting from, ZFS and > also > has a GELI partition contain some data which requires a manual password. >To point out the obvious, booting a 12.0 kernel with 11 userland to multiuser mode is seriously unsupported. You really need to boot to single user and install 12.0 userland to really expect things to work. OTOH, while I would expect that MANY things might not work, panics should not come from problems in userland. Still, I would not be at all shocked if it turns out to be coincidental to CARP. I would also not be shocked if this makes no difference, but even between minor version updates, there can be issues when the kernel and userland are different versions. Is there a reason that a standalone boot is not possible? Both installworld and mergemaster should be run before moving to multiuser mode and reboot is preferred to exit. In some cases even delete-old can be required before safely going to multimode. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman at gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
On 17.01.2019 15:19, Pete French wrote:> so, having got a workaround for yesterdays problems, I now went to upgrade my > other pair of boxes using CARP. No 'pf' on these, just one shared address. > This is the setup I have tested in development and it works fine. > > I install the new kenel and do the first reboot - and I get the panic > below. Maybe its not carp related, but seems suspicious as the last > thing it spits out is a carp message. > > 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:0xffffffff80ca0de1 > stack pointer = 0x28:0xfffffe00004da740 > frame pointer = 0x28:0xfffffe00004da760 > 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 = 1547727391 > KDB: stack backtrace: > #0 0xffffffff80be8597 at kdb_backtrace+0x67 > #1 0xffffffff80b9ccf3 at vpanic+0x1a3 > #2 0xffffffff80b9cb43 at panic+0x43 > #3 0xffffffff8107382f at trap_fatal+0x35f > #4 0xffffffff81073889 at trap_pfault+0x49 > #5 0xffffffff81072eae at trap+0x29e > #6 0xffffffff8104e1a5 at calltrap+0x8 > #7 0xffffffff80ca0ce6 at ether_output+0x6b6 > #8 0xffffffff80d0bda4 at arprequest+0x4c4 > #9 0xffffffff80d0d9fc at garp_rexmit+0xbc > #10 0xffffffff80bb6ba9 at softclock_call_cc+0x129 > #11 0xffffffff80bb7089 at softclock+0x79 > #12 0xffffffff80b60e79 at ithread_loop+0x169 > #13 0xffffffff80b5e012 at fork_exit+0x82 > #14 0xffffffff8104f18e at fork_trampoline+0xe > Uptime: 19sHi, What branch and revision do you use? Can you install gdb and then obtain this information: # kgdb (kgdb) list *ether_output+0x6b6 -- WBR, Andrey V. Elsukov -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20190205/86f239ec/attachment.sig>