Date: Thu, 09 May 2019 17:23:03 -0500 From: Larry Rosenman <ler@lerctr.org> To: =?UTF-8?Q?Trond_Endrest=C3=B8l?= <trond.endrestol@ximalas.info> Cc: freebsd-current@freebsd.org, owner-freebsd-current@freebsd.org Subject: Re: Panic in fbt_provide_module_function() on head amd64 r347403 Message-ID: <3040f1dad5052ef2074a8370bc0af078@lerctr.org> In-Reply-To: <alpine.BSF.2.21.9999.1905092328550.6389@enterprise.ximalas.info> References: <alpine.BSF.2.21.9999.1905092328550.6389@enterprise.ximalas.info>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05/09/2019 5:19 pm, Trond Endrestøl wrote: > Host is Windows 7 x64 SP1. > CPU is Core i7 960. > Hypervisor is VirtualBox 6.0.6. > VM is using UEFI. > Kernel config is > https://ximalas.info/~trond/create-zfs/canmount/VBOXGUEST-amd64-head > > Crash happens early during boot, right after launching the APs. > > fault virtual address = 0x0 > [...] > KDB backtrace: > db_trace_self_wrapper() at > vpanic() at > panic() at > trap_fatal() at > trap_pfault() at > trap() at > calltrap() at > -- trap 0xc, rip = 0xffffffff8196d63a, rsp = 0xffffffff8198d730, rbp = > 0xffffffff8198d790 --- > fbt_provide_module_function() at 0xffffffff8196d63a = > fbt_provide_module_function+0x7a/frame 0xffffffff8198d790 > link_elf_each_function_nameval() at 0xffffffff80822ae5 = > link_elf_each_function_nameval+0x115/frame 0xffffffff8198d7e0 > fbt_provide_module() at 0xffffffff8196c33e = > fbt_provide_module+0xde/frame 0xffffffff8198dc10 > fbt_linker_file_cb() at 0xffffffff8196c242 = > fbt_linker_file_cb+0x12/frame 0xffffffff8198dc20 > linker_file_foreach() at 0xffffffff807c47b7 = > linker_file_foreach+0x67/frame 0xffffffff8198dc60 > mi_startup() at 0xffffffff80786de6 = mi_startup+0x216/frame > 0xffffffff8198dcb0 > btext() at 0xffffffff8030da2c = btext+0x2c > Uptime: 1s > > Previous BE is r346969 and works flawlessly. > No dumpdev is enabled to capture the details this early during boot. > Suggestions are welcome. There is a patch: From: markj@FreeBSD.org (on my Crash loading dtraceall thread): I see, my theory above is not the real problem here. The resolver for x86_rng_store() may return NULL, which we do not expect. Can you show the CPU info and features lines from the dmesg to confirm? Also see if this patch helps: diff --git a/sys/dev/random/ivy.c b/sys/dev/random/ivy.c index 57f3d0a1d80b..71065d788cf9 100644 --- a/sys/dev/random/ivy.c +++ b/sys/dev/random/ivy.c @@ -97,6 +97,13 @@ x86_rdseed_store(u_long *buf) return (retry); } +static int +x86_dead_store(u_long *buf __unused) +{ + + panic("missing hardware PRNG support"); +} + DEFINE_IFUNC(static, int, x86_rng_store, (u_long *buf), static) { has_rdrand = (cpu_feature2 & CPUID2_RDRAND); @@ -107,7 +114,7 @@ DEFINE_IFUNC(static, int, x86_rng_store, (u_long *buf), static) else if (has_rdrand) return (x86_rdrand_store); else - return (NULL); + return (x86_dead_store); } /* It is required that buf length is a multiple of sizeof(u_long). */ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: ler@lerctr.org US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3040f1dad5052ef2074a8370bc0af078>