Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp5784006ybe; Tue, 17 Sep 2019 13:29:39 -0700 (PDT) X-Google-Smtp-Source: APXvYqxj+C26UfNhIuR4q0DNxFWqzX/bG58LGLzPUGbvEInCF6/vA5zcDwetylXrpL6aFgGnMNVI X-Received: by 2002:a17:906:9703:: with SMTP id k3mr1242939ejx.159.1568752179595; Tue, 17 Sep 2019 13:29:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568752179; cv=none; d=google.com; s=arc-20160816; b=sGoih7QDfB/vVIEKKet6rpXpunOjuR9/Dhg8WmQApbksaSQMhV3uXG88ewI64Y3mtX qMuDypkol0LYEHxKOqv5vWiee0CxYzATfRb0oy7PV9FKkpNciw8CTqXpqnX9+NmK0UQQ i8AzKlb4/gGr55NSg2C+mlbvT1nU48xQ2OTDIN5+bTZlI7EhLmAgB7r8UKe9DdOqJAdV tHBsubVijJcFUM3ruHUKbWKHcG4+Issgl2+5NhLZkVyCMMQS6Ju5XekIEktp88Fk7k0d G5K7Ypbr/ftw9GZ/xyDECVBIoT4APb0QgyERJF8/3slUSCeaFtYuy1DkxovTQ7FqoH8j jf8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=q98F695NopI5HOeI9nhiZkKjC9G0SLpvtSO0RER8F3U=; b=Ik6LK+3xDrDgCVHZRWTn5b4UAjloWn8sHgMVhzXwYv4lMt5yC5su9nVg/CjxM/nUsK f5vfarZvMZgRoKWg8meyMsyxP3cLFLp9Pmzw7i2xYwUK2SQ5tkoepsFFWtPHpurjBmbu nfPvjxEZThS1U/MlV9E1JjjNtuYZ1QGsdtDR3fgHrDrfUjEpWbn84IJmsY+P8B3VVzI5 iBRubMYvNKG0bYNz57MvQ+br/5F8JjeMKYwoasdc9l1IrLL9lpVcvnrLSIWfsCPYAHkz Govk7Ox0nTk5qDFDyXLZIw+NSAc11tA5L9I9tHtV7XXizUpMRYjOF+nzCWaOdFpQjBjB Kkkw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id fk4si1867215ejb.161.2019.09.17.13.29.13; Tue, 17 Sep 2019 13:29:39 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727479AbfIQU2u convert rfc822-to-8bit (ORCPT + 99 others); Tue, 17 Sep 2019 16:28:50 -0400 Received: from luna.lichtvoll.de ([194.150.191.11]:45411 "EHLO mail.lichtvoll.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726285AbfIQU2u (ORCPT ); Tue, 17 Sep 2019 16:28:50 -0400 Received: from 127.0.0.1 (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.lichtvoll.de (Postfix) with ESMTPSA id 7A6C8776D7; Tue, 17 Sep 2019 22:28:47 +0200 (CEST) From: Martin Steigerwald To: Linus Torvalds Cc: Lennart Poettering , "Ahmed S. Darwish" , "Theodore Y. Ts'o" , Willy Tarreau , Matthew Garrett , Vito Caputo , Andreas Dilger , Jan Kara , Ray Strode , William Jon McCann , "Alexander E. Patrakov" , zhangjs , linux-ext4@vger.kernel.org, lkml Subject: Re: Linux 5.3-rc8 Date: Tue, 17 Sep 2019 22:28:47 +0200 Message-ID: <2658007.Cequ2ms4lF@merkaba> In-Reply-To: References: <20190917174219.GD31798@gardel-login> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="UTF-8" Authentication-Results: mail.lichtvoll.de; auth=pass smtp.auth=martin smtp.mailfrom=martin@lichtvoll.de Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Linus Torvalds - 17.09.19, 20:01:23 CEST: > > We can make boot hang in "sane", discoverable way. > > That is certainly a huge advantage, yes. Right now I suspect that what > has happened is that this has probably been going on as some > low-level background noise for a while, and people either figured it > out and switched away from gdm (example: Christoph), or more likely > some unexplained boot problems that people just didn't chase down. So > it took basically a random happenstance to make this a kernel issue. > > But "easily discoverable" would be good. Well I meanwhile remembered how it was with sddm: Without CPU assistance (RDRAND) or haveged or any other source of entropy, sddm would simply not appear and I'd see the tty1 login. Then I start to type something and after a while sddm popped up. If I would not type anything it took easily at least have a minute till it appeared. Actually I used my system like this quite a while, cause I did not feel comfortable with haveged and RDRAND. AFAIR this was as this Debian still ran with Systemd. What Debian maintainer for sddm did was this: sddm (0.18.0-1) unstable; urgency=medium […] [ Maximiliano Curia ] * Workaround entropy starvation by recommending haveged * Release to unstable -- Maximiliano Curia […] Sun, 22 Jul 2018 13:26:44 +0200 With Sysvinit I still have neither haveged nor RDRAND enabled, but behavior changed a bit. crng init still takes a while % zgrep -h "crng init" /var/log/kern.log* Sep 16 09:06:23 merkaba kernel: [ 16.910096][ C3] random: crng init done Sep 8 14:08:39 merkaba kernel: [ 16.682014][ C2] random: crng init done Sep 9 09:16:43 merkaba kernel: [ 46.084188][ C2] random: crng init done Sep 11 10:52:37 merkaba kernel: [ 47.209825][ C3] random: crng init done Sep 12 08:32:08 merkaba kernel: [ 76.624375][ C3] random: crng init done Sep 12 20:07:29 merkaba kernel: [ 10.726349][ C2] random: crng init done Sep 8 10:02:42 merkaba kernel: [ 37.391577][ C2] random: crng init done Aug 26 09:23:51 merkaba kernel: [ 40.555337][ C3] random: crng init done Aug 28 09:45:28 merkaba kernel: [ 39.446847][ C1] random: crng init done Aug 20 10:14:59 merkaba kernel: [ 12.242467][ C1] random: crng init done and there might be a slight delay before sddm appears, before tty has been initialized. I am not completely sure whether it is related to sddm or something else. But AFAIR delays have been in the range of a maximum of 5-10 seconds, so I did not bother to check more closely. Note this is on a ThinkPad T520 which is a PC. And if I read above kernel log excerpts right, it can still take up to 76 second for crng to be initialized with entropy. Would be interesting to see other people's numbers there. There might be a different ordering with Sysvinit and it may still be sddm. But I never have seen a delay of 76 seconds AFAIR… so something else might be different or I just did not notice the delay. Sometimes I switch on the laptop and do something else to come back in a minute or so. I don't have any kernel logs old enough to see whether whether crng init times have been different with Systemd due to asking for randomness for UUID/hashmaps. Thanks, -- Martin