From owner-svn-src-all@FreeBSD.ORG Sun Nov 2 00:00:43 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E7D14851; Sun, 2 Nov 2014 00:00:42 +0000 (UTC) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DC21E949; Sun, 2 Nov 2014 00:00:41 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id bs8so3867154wib.11 for ; Sat, 01 Nov 2014 17:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=n9mia2D4FsCst9JjaYfQjPGzYba3y4s5O4gmh8Wh0Sw=; b=HP7tIp31zLK1YrDNjJK+cOQB6ubpy7zQnhru8CwXMiHATtzen6X0655fhvFjA87yjh yCbqULdSlMLgtB/g+W/W3CFpn9MRTVkj6ie7jCYHhrWmD7Pv/RhgV/JBOir0WFtKqpL2 3CkcAsrjdBlViRFdINWIwhqzP4yUJAWPRxWbFlPA79MuS7Cj/6WQ8VAwg0/+2atMmZc/ wDZsecf4dp9OzO8uQ/qDDU/Fypoi3WrhavkQKJlDkh2N01YL1seIVQ4D6p1hf5e/o6Qg VKqsMSK3x9CjYYp3f8cT6Xryje4SfLEEi+em4ejDeAlDb5gKllHXqVCtdq+TDG0VP07D oetg== MIME-Version: 1.0 X-Received: by 10.180.188.41 with SMTP id fx9mr6315057wic.59.1414886440142; Sat, 01 Nov 2014 17:00:40 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Sat, 1 Nov 2014 17:00:40 -0700 (PDT) In-Reply-To: <1414886231.17308.238.camel@revolution.hippie.lan> References: <201410302121.s9ULLsEw055630@svn.freebsd.org> <20141101181536.2b6a5911@kan> <627C5F71-939A-4579-8A1B-45933662DAED@FreeBSD.org> <1414882185.17308.221.camel@revolution.hippie.lan> <86r3xm5wt6.fsf@nine.des.no> <86mw8a5we0.fsf@nine.des.no> <1414886231.17308.238.camel@revolution.hippie.lan> Date: Sat, 1 Nov 2014 17:00:40 -0700 X-Google-Sender-Auth: DZgrE81Em8f_oKxmnWDJY3zgeMA Message-ID: Subject: Re: svn commit: r273872 - in head: etc/defaults etc/rc.d libexec/save-entropy share/examples/kld/random_adaptor sys/conf sys/dev/glxsb sys/dev/random sys/kern sys/modules sys/modules/padlock_rng sys/mo... From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" , =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= , Mark R V Murray , Alexander Kabaev X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 00:00:43 -0000 Hi, Right - but I'm not even getting to anywhere near this point. It's hanging in hostapd when hostapd tries reading random data. again, if i try ctrl-C'ing whilst the random device is inside random_adaptor_read(), it's just .. broken. The read doesn't finish, the process doesn't accept any new input, signals or anything - it just doesn't work. So, is there some way to go back to whatever the previous revision before this did? It at least comes up and doesn't hang things. Thanks, -adrian On 1 November 2014 16:57, Ian Lepore wrote: > On Sun, 2014-11-02 at 00:33 +0100, Dag-Erling Sm=C3=B8rgrav wrote: >> Dag-Erling Sm=C3=B8rgrav writes: >> > From the code. This is a portion of the rc script that only runs at >> > shutdown. If random_stop() runs during boot, something is seriously >> > wrong *somewhere else* and you are welcome to help find out what. >> >> I found it - postrandom triggers it. For now, just remove >> /etc/rc.d/postrandom (I'm not sure it's really needed, there are better >> ways to do this). >> >> DES > > It appears another quick easy workaround is to set entropy_file=3DNO in > rc.conf, which may be the right thing to do for people using a varmfs > that isn't going to survive a reboot anyway, even after this glitch is > fixed. > > -- Ian > >