From owner-freebsd-stable@freebsd.org Thu Jul 20 13:45:46 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B204AC78ECF for ; Thu, 20 Jul 2017 13:45:46 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5F41A6AF05; Thu, 20 Jul 2017 13:45:45 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from amavis-ori.ijs.si (localhost [IPv6:::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.ijs.si (Postfix) with ESMTPS id 3xCwCB4wjTz70; Thu, 20 Jul 2017 15:45:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla4; t=1500558339; x=1503150340; bh=Ou8 wNqc3yX51cKvl0LONbvUSszcCWBC7D7kSSiEWp5w=; b=hgxiaVVZvGNfHtcDLf3 QkO/jwceEXrSTvb3hOXB8/BW4Mx8kC/8jDIJOD3nD/jLk5OdtHqWwAE6pDIu2YgQ MKHW/pZLrlezBmgxQpEH6CYgWm/FOCeGpGJpeZ/ybVFjR4dQC6rossuomt+jhhD1 8ZijHfqyYHX2GwuRVKCmBhAQ= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10026) with LMTP id HCy0JavCX1Gt; Thu, 20 Jul 2017 15:45:39 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP id 3xCwC73KGdz6x; Thu, 20 Jul 2017 15:45:39 +0200 (CEST) Received: from nabiralnik.ijs.si (nabiralnik.ijs.si [IPv6:2001:1470:ff80::80:16]) by mildred.ijs.si (Postfix) with ESMTP id 3xCwC72GCYzRm; Thu, 20 Jul 2017 15:45:39 +0200 (CEST) Received: from neli.ijs.si (2001:1470:ff80:88:21c:c0ff:feb1:8c91) by nabiralnik.ijs.si with HTTP (HTTP/1.1 POST); Thu, 20 Jul 2017 15:45:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 20 Jul 2017 15:45:39 +0200 From: Mark Martinec To: freebsd-stable@freebsd.org Cc: Mark Johnston Subject: Re: The 11.1-RC3 can only boot and attach disks in "Safe mode", otherwise gets stuck attaching Organization: Jozef Stefan Institute In-Reply-To: <20170720000325.GB9198@wkstn-mjohnston.west.isilon.com> References: <20170717232434.GB21048@wkstn-mjohnston.west.isilon.com> <9b3563aae75aa954d7fe31ffe25e1d29@ijs.si> <20170720000325.GB9198@wkstn-mjohnston.west.isilon.com> Message-ID: <81295bcacd7c44813de8d346c88cbb65@ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.2.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 13:45:46 -0000 2017-07-20 02:03, Mark Johnston wrote: > One thing to try at this point would be to disable EARLY_AP_STARTUP in > the kernel config. That is, take a configuration with which you're able > to reproduce the hang during boot, and remove "options > EARLY_AP_STARTUP". Done. And it avoids the problem altogether! Thanks. Tried a reboot several times and it succeeds every time. Here is all that I had in a config file for building a kernel, i.e. I took away the 'options DDB' which also seemingly avoided the problem: include GENERIC ident NELI nooptions EARLY_AP_STARTUP > This feature has a fairly large impact on the bootup process and has > had a few problems that manifested as hangs during boot. There was at > least one other case where an innocuous change to the kernel > configuration "fixed" the problem by introducing some second-order > effect (causing kernel threads to be scheduled in a different > order, for instance). > Regardless of whether the suggestion above makes a difference, it would > be helpful to see verbose dmesgs from both a clean boot and a boot that > hangs. If disabling EARLY_AP_STARTUP helps, then we can try adding some > assertions that will cause the system to panic when the hang occurs, > making it easier to see what's going on. Hmmm. I have now saved a couple of versions of /var/run/dmesg.boot (in boot_verbose mode) when EARLY_AP_STARTUP is disabled and the boot is successful. However, I don't know how to capture such log when booting hangs, as I have no serial interface and the boot never completes. All I have is a screen photo of the last state when a hang occurs (showing ada disks successfully attached, followed immediately by the attempt to attach a da disk, which hangs). Mark