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