From owner-freebsd-current@FreeBSD.ORG Sun Sep 8 09:00:23 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0AA35B5A; Sun, 8 Sep 2013 09:00:23 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id BC59622E8; Sun, 8 Sep 2013 09:00:22 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 8BAFA4547; Sun, 8 Sep 2013 09:00:21 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id E0B2429436; Sun, 8 Sep 2013 11:00:24 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Glen Barber Subject: Re: random(4) update causes mips compile fail | mips boot fail References: <1378572186.1588.5.camel@localhost> <24DB010A-F374-491B-9203-FDDD7EA14A51@grondar.org> <1378579011.1588.16.camel@localhost> <9240BEF1-2791-4D58-A422-08AEF1CD306C@grondar.org> <1378586316.1111.524.camel@revolution.hippie.lan> <82260B0E-E2CF-4D7B-B1E2-EEFAF25BD090@grondar.org> <20130908003123.GX77463@glenbarber.us> Date: Sun, 08 Sep 2013 11:00:24 +0200 In-Reply-To: <20130908003123.GX77463@glenbarber.us> (Glen Barber's message of "Sat, 7 Sep 2013 20:31:23 -0400") Message-ID: <86fvtfhemv.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Adrian Chadd , "freebsd-current@freebsd.org" , Mark R V Murray , Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Sun, 08 Sep 2013 09:00:23 -0000 Glen Barber writes: > The correct workaround (which now I see I should have done before > locking head/) is to revert this commit so it can be properly fixed. Glen, to be fair, the mips boot fails because they're trying to use a device before it's ready. It just so happens that this device is implemented entirely in software, not in hardware, but it's no different from trying to read from an empty optical drive. The only thing that has changed, in practical terms, is that previously if they tried to read from an empty drive (to continue the analogy) we'd nod and smile and feed them zeroes, whereas now we wait for someone to insert a disc. So Mark didn't really break anything here (apart from the build breakage which has already been fixed), he just made an existing bug visible. And he's already reverted the *one* line of code that did this, so mips is now almost as broken as it was before (only almost, because the first commit also fixed some serious harvesting / entropy estimation bugs). Anyway, on platforms that support tunables, this should help: Index: sys/dev/random/randomdev_soft.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/dev/random/randomdev_soft.c (revision 255371) +++ sys/dev/random/randomdev_soft.c (working copy) @@ -102,6 +102,8 @@ =20 #endif =20 +TUNABLE_INT("kern.random.sys.seeded", &random_context.seeded); + /* List for the dynamic sysctls */ static struct sysctl_ctx_list random_clist; =20 On platforms that don't, we need to figure out a better solution; possibly Pawel's early harvesting patch, which, while not perfect, at least introduces a minimum of entropy into Yarrow before boot. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no