Re: FreeBSD trap under some hypervisor

On Sat, Dec 25, 2021, 12:26 PM Eugene M. Zheganin <eugene@zhegan.in> wrote:

> Hello,
>
> I have some experience deploying FreeBSD in several clouds that don't
> initially state FreeBSD support. When I upload the sample image into
> these clouds, it usually runs just fine. I created the image from bhyve,
> using sysutils/vm-bhyve config like:
>
> loader="bhyveload"
> cpu=1
> memory=2048M
> network0_type="virtio-net"
> network0_switch="public"
> disk0_type="virtio-blk"
> disk0_name="disk0.img"
> uuid="248d160e-0bf2-11ec-971e-ac1f6b9712f0"
> network0_mac="58:9c:fc:05:a7:90"
>
> This image can then be run in several openstack-based public clouds,
> like russian VM provider Selectel one, or Rostelecom cloud.
>
> But when upploading this image into the Yandex cloud (seems to be
> KVM/Qemu-based), I get a trap immidiately after starting loading the
> kernel:
>
> Loading kernel...
> /boot/kernel/kernel text=0x17b9e0 text=0xdd6d30 text=0x65b9ac data=0x140
> data=0x1b9348+0x445cb8 syms=[0x8+0x178e90+0x8+0x199058]
> Loading configured modules...
> /boot/entropy size=0x1000
> /boot/kernel/cryptodev.ko size 0xae38 at 0x2113000
> /boot/kernel/zfs.ko size 0x67feb0 at 0x211e000
> /etc/hostid size=0x25
> ---<<BOOT>>---
> Copyright (c) 1992-2021 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>          The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261f: Fri Apr 9
> 04:24:09 UTC 2021
> root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
> amd64
> FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git
> llvmorg-11.0.1-0-g43ff75f2c3fe)
> kernel trap 12 with interrupts disabled
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0x7ffb2000
> fault code              = supervisor read instruction, page not present
> instruction pointer     = 0x20:0x7ffb2000
> stack pointer           = 0x28:0xffffffff827b2488
> frame pointer           = 0x28:0xffffffff827b2510
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                          = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = resume, IOPL = 0
> current process         = 0 ()
> trap number             = 12
> panic: page fault
> cpuid = 0
> time = 1
> KDB: stack backtrace:
> #0 0xffffffff80c57345 at ??+0
> #1 0xffffffff80c09d21 at ??+0
> #2 0xffffffff80c09b93 at ??+0
> #3 0xffffffff8108b187 at ??+0
> #4 0xffffffff8108b1df at ??+0
> #5 0xffffffff8108a83d at ??+0
> #6 0xffffffff810617a8 at ??+0
> #7 0xffffffff80b99fbf at ??+0
> #8 0xffffffff8037c02c at ??+0
> Uptime: 1s
>

A traceback with symbols would be better.. though this looks to be too
early to get them....

Warner

>
> Does anyone have a clue for this ? Or may be anyone is more successfull
> in this than I am. Asking for support via usual Yandex channel seems to
> be futile, because they don't provide FreeBSD images in their catalog,
> thus they don't state FreeBSD as supported (in fact, only Azure or
> AliCloud are).
>
> Thanks.
>
> Eugene.
>
>
>