From nobody Sat Dec 25 19:38:46 2021 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8DF6B1909C8F for ; Sat, 25 Dec 2021 19:39:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JLvPg3T5Hz4pkY for ; Sat, 25 Dec 2021 19:39:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2f.google.com with SMTP id c10so6341743vkn.2 for ; Sat, 25 Dec 2021 11:39:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jea2x2QwRH30aByfLNjbEpBHQUxLGjpIo33Odoe+wy0=; b=H7MskaSRFnniaPa3pXA7TNEeQ9dlmsOLXCcq1kgUwRX/lhcYDTA49oWuwqkt2X+iN6 uN7LkMu16wxYqwfVCfisrv3veeI0nQeovIAOYqj3QuuLBzC5KGIKJY3qeZmc0i/fwgzY TPaA24fdlHQOFYXNXWyoehqU1n2fAmnxh4YML4KOvnlmh2MpCPCclyAKPJq8dJNzpfAo SfStYJYnArDyX0Ed52ucy38ad+6ZhqM9V/27/xVJ3FPjEjL3bcnDLk3MEcxwXlAmnLgT kOxnRsUMm8HYugKBixttsSg7CM8++8/pEbbbEly7/XqPd9/5+J+GUXrLKQo5oXwhO2q8 VE/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jea2x2QwRH30aByfLNjbEpBHQUxLGjpIo33Odoe+wy0=; b=h0IoZ3U5A5k0j0tK8aRPJ/1PleQqcD/Luu5oJN6QZdjfflHftWUh2adi4j+M7XueBr TiObDG3WBdP0p0OaUQ2PG1siEaR07kK6sckwsheNOOJN1bpbr39r1CQvTtU2mZSMJJrG ICoXzgEIttjgOvmDCmXrtUPTVCPlx8r4QK/C7GneZ93NLMLQ0R+1RjeeDSAunOkZSIWj /zXqSF+BXDl+sxeiZVbceDXusmMWp1m0YjpPqKXzWMPILg3cz+ump+smO9+PzWCWAYtp mkDFMnTbvBEyUhIx1KE5FY6E5Tv2NGBA5k+hUrYL1uZ0p70uKHJWbjJczy57Qm5kzT/U c1NA== X-Gm-Message-State: AOAM532hvnyLgAWayMbNw7kcLOgH3y5dRQD68v800DYgL12BUgoMrn6U 448TwRrjRdN4dLIXnt27cD97T5UGhXH2RpE8aU/PiJLiliA= X-Google-Smtp-Source: ABdhPJxfFitvUa0HegQFBfM5tHz+6wx3hwpWSIQX8hxZjT87QVo8VyhzX7ARvpR6nOr3k9bxHttvGWU2tjJ7bYmWQEc= X-Received: by 2002:a1f:c9c2:: with SMTP id z185mr3292977vkf.26.1640461136691; Sat, 25 Dec 2021 11:38:56 -0800 (PST) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sat, 25 Dec 2021 12:38:46 -0700 Message-ID: Subject: Re: FreeBSD trap under some hypervisor To: "Eugene M. Zheganin" Cc: FreeBSD Stable ML Content-Type: multipart/alternative; boundary="000000000000521a9e05d3fd9f7f" X-Rspamd-Queue-Id: 4JLvPg3T5Hz4pkY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --000000000000521a9e05d3fd9f7f Content-Type: text/plain; charset="UTF-8" On Sat, Dec 25, 2021, 12:26 PM Eugene M. Zheganin 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 > ---<>--- > 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. > > > --000000000000521a9e05d3fd9f7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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 <= br> 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=3D"bhyveload"
cpu=3D1
memory=3D2048M
network0_type=3D"virtio-net"
network0_switch=3D"public"
disk0_type=3D"virtio-blk"
disk0_name=3D"disk0.img"
uuid=3D"248d160e-0bf2-11ec-971e-ac1f6b9712f0"
network0_mac=3D"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=3D0x17b9e0 text=3D0xdd6d30 text=3D0x65b9ac data=3D= 0x140
data=3D0x1b9348+0x445cb8 syms=3D[0x8+0x178e90+0x8+0x199058]
Loading configured modules...
/boot/entropy size=3D0x1000
/boot/kernel/cryptodev.ko size 0xae38 at 0x2113000
/boot/kernel/zfs.ko size 0x67feb0 at 0x211e000
/etc/hostid size=3D0x25
---<<BOOT>>---
Copyright (c) 1992-2021 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The Regents of the Univers= ity 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 =3D 0; apic id =3D 00
fault virtual address=C2=A0=C2=A0 =3D 0x7ffb2000
fault code=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 =3D supervisor read instruction, page not present
instruction pointer=C2=A0=C2=A0=C2=A0=C2=A0 =3D 0x20:0x7ffb2000
stack pointer=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =3D 0x28:0xffffffff827b2488
frame pointer=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =3D 0x28:0xffffffff827b2510
code segment=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 =3D base 0x0, limit 0xfffff, type 0x1b
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D D= PL 0, pres 1, long 1, def32 0, gran 1
processor eflags=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D resume, IOPL= =3D 0
current process=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D 0 () trap number=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =3D 12
panic: page fault
cpuid =3D 0
time =3D 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 b= e 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.


--000000000000521a9e05d3fd9f7f--