From owner-freebsd-arm@freebsd.org Wed Dec 13 00:47:13 2017 Return-Path: Delivered-To: freebsd-arm@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 A07F0E8B6CB for ; Wed, 13 Dec 2017 00:47:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-151.reflexion.net [208.70.210.151]) (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 4E7737B020 for ; Wed, 13 Dec 2017 00:47:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15100 invoked from network); 13 Dec 2017 00:20:31 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 13 Dec 2017 00:20:31 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 12 Dec 2017 19:20:31 -0500 (EST) Received: (qmail 13273 invoked from network); 13 Dec 2017 00:20:31 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 13 Dec 2017 00:20:31 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 30083EC814E; Tue, 12 Dec 2017 16:20:30 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: A head kernel rpi2 boot-hang bisected: -r326346 good; -r326347 and later hangs-up during boot From: Mark Millard In-Reply-To: <241F43AF-23B2-4C54-9B77-A5A7CE3F8E57@dsl-only.net> Date: Tue, 12 Dec 2017 16:20:29 -0800 Cc: FreeBSD Hackers , FreeBSD Current , Freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <32649011-1CFA-4215-BB37-00E4493882CD@dsl-only.net> <4b2420e8899.5992ee2b@mail.schwarzes.net> <241F43AF-23B2-4C54-9B77-A5A7CE3F8E57@dsl-only.net> To: Andreas Schwarz , jeff@FreeBSD.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 00:47:13 -0000 On 2017-Dec-12, at 3:19 PM, Mark Millard wrote: > On 2017-Dec-12, at 2:02 PM, Andreas Schwarz wrote: >=20 >> On 12.12.17, Mark Millard wrote: >>=20 >>> I initially jumped from -r326192 to -r326726 and >>> ended up with a rpi2 that would normally hang >>> somewhere around release APs being displayed. >>> (I have had a couple of completed boots but many >>> dozens of hung-up attempts.) Both a debug kernel >>> and a non-debug kernel hang the same way. >>>=20 >>> Bisecting the kernel (holding world -r326726 >>> constant) showed: >>>=20 >>> -r326346 did not hang (nor did before) >>> -r326347 and later hung. >>=20 >> JFYI, the latest kernel (and world) running at one of my=20 >> RPI2-B is r326631, without any issues. >=20 > Interesting. (By the way: My context > is with a V1.1 Cortex-A7 based rpi2, > not V1.2 and Cortex-A53.) >=20 > I've almost always run the root file > system being on a USB SSD instead of > on mmcsd0 . I wonder if that is > somehow involved since it may be > unusual. UFS file system. >=20 > The USB SSD is on a powered hub that > is in turn plugged into the rpi2. >=20 > [I had the hang problem before the > following and after.] >=20 > The mechanism for holding mmcsd0 in > failed recently but the ejection > mechanism still works. So I hold > in mmcsd0 until after I get a USB > SSD boot now. (Interrupt boot, unload, > boot/autoboot, picks up the kernel > from the USB SSD.) >=20 > This means that I effectively can > not avoid the USB SSD any more > unless I get my hands on a different > V1.1 rpi2. Looks like I'll get my hands on a different rpi2 V1.1 in a few days. So I should then be able to do reasonable mmcsd0-only experiments. At least once I find the time. FYI, in case boot details are involved in reproducing the problem. . . On the mmcsd0 I have /boot/loader.conf with: kern.cam.boot_delay=3D"10000" vfs.mountroot.timeout=3D"10" and /etc/fstab with: /dev/ufs/RPI2rootfs / ufs rw,noatime 1 1 /dev/label/RPI2Aswap none swap sw 0 0 /dev/label/RPI2Aboot /boot/msdos msdosfs rw,noatime 0 0 where the /dev/ufs/RPI2rootfs was the USB SSD. However, I interrupt the loader and unload and then boot or autoboot. (But the hangs started before this extra sequence was involved.) On the USB SSD I have /boot/loader.conf with: kern.cam.boot_delay=3D"10000" vfs.mountroot.timeout=3D"10" and /etc/fstab with: /dev/da0p1 / ufs rw,noatime 1 1 /dev/da0p2 none swap sw 0 0 What db> showed does point to things that -r326347 involve: chain 32: thread 100001 (pid 1, kernel) blocked on sx "umadrain" XLOCK thread 100077 (pid 23, uma) is on a run queue But for all I know -r326347 could be depending on something required to be true but not correct elsewhere in the rpi2 support. I'm not claiming that -r326347 is wrong, just that it is involved. I've way to little knowledge to claim to know what is wrong on the evidence that I have. I've not yet tried a bpi-m3 Cortex-A7 context or a pine64+ 2GB or rpi3 Cortex-A53 context. Nor powerpc64 nor powerpc. At some point I'll get the time for one or more of these. I've not had amd64 problems in this area. I may not be able to test the bpi-m3: its barrel connector for power seems flaky and it is difficult to keep the board powered for long periods in recent times. =3D=3D=3D Mark Millard markmi at dsl-only.net