From owner-freebsd-current@freebsd.org Thu May 9 22:23:06 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E20BB158F737; Thu, 9 May 2019 22:23:05 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (ns-b.lerctr.org [IPv6:2001:470:1f0f:3ad::53:2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "*.lerctr.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 40FB7847D5; Thu, 9 May 2019 22:23:05 +0000 (UTC) (envelope-from ler@lerctr.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lerctr.org; s=ler2019; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date: Content-Transfer-Encoding:Content-Type:MIME-Version:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=PyyHME1vY+8r3xBVHVKzsVpDZ23v+CeUbAtd4mEoBvM=; b=jRHpLUAOhk4cqOPNOd4QPFUltE yGdx44ga903w+mtGPeyExF9VebdhFHrZNBbtwaZVTagK9N1r+f5nnH2E4vFmAy2ZxBIu1EvgGaoKq /uX1CflxVdKqN+znIiA7sqLaC4yHIk9sXNRb+4mfg/nJ7tCEkrbE4l+baNmhNOSpoL8WSnwPECXJF qYXdAmE8cRwVuO2dfufdG2/PI8UvfkZ6LQaSlm5HWAp7OgG+ZDzM1jJ6GjYeVnTWm3cVojOg41CYv tcJcZ8ygKEQoqDVUNobGyJSflqxdtMz7j6PANVvvROc1klJX51beN63LiK+0A2Ip7TpUoTxYpq66L iPbrBwYg==; Received: from thebighonker.lerctr.org ([2001:470:1f0f:3ad:bb:dcff:fe50:d900]:10838 helo=webmail.lerctr.org) by thebighonker.lerctr.org with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92 (FreeBSD)) (envelope-from ) id 1hOrRQ-00043X-1H; Thu, 09 May 2019 17:23:04 -0500 Received: from 2600:1700:210:b180:fc68:4319:5577:5de1 by webmail.lerctr.org with HTTP (HTTP/1.1 POST); Thu, 09 May 2019 17:23:03 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 09 May 2019 17:23:03 -0500 From: Larry Rosenman To: =?UTF-8?Q?Trond_Endrest=C3=B8l?= Cc: freebsd-current@freebsd.org, owner-freebsd-current@freebsd.org Subject: Re: Panic in fbt_provide_module_function() on head amd64 r347403 In-Reply-To: References: Message-ID: <3040f1dad5052ef2074a8370bc0af078@lerctr.org> X-Sender: ler@lerctr.org User-Agent: Roundcube Webmail/1.3.9 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 22:23:06 -0000 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