From owner-freebsd-current@freebsd.org Thu Feb 9 15:31:32 2017 Return-Path: Delivered-To: freebsd-current@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 D9FA6CD7A78 for ; Thu, 9 Feb 2017 15:31:32 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp001.me.com (st13p35im-asmtp001.me.com [17.164.199.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9E76AE96 for ; Thu, 9 Feb 2017 15:31:32 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp001.me.com by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OL4008005SINY00@st13p35im-asmtp001.me.com> for freebsd-current@freebsd.org; Thu, 09 Feb 2017 15:31:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1486654291; bh=JNi1N45ad7uVpQhLg0DVtxfBt0zWIO/GGLkvJTxi/7E=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=daB8UWPIkisyDdQuLeaK/lBGmvHtLOq4UByvioiBzsWx25bQBhTxJmu98m6FLZm3d LiMgBvT1wlejSeSh2oW7lTxPfqT2C11E7qMSai4FXHAlGLMEvmU4+gMuWCwLoumG+G vYoixh+lpRiuSvT04m2nPv4iJVKWAIvRpaoBdtxQ7JReOCYvj1tIhwL6LMYww929IO uMf6NXVJdq8RLpKJsdxhxBGCsCsWo3GtIoD9q8LFcQo4YJvCcDNN5XOZ5z4ALnD2Jv So3x+xrLlcNpCbe7a8Bj6rHNDQoERB8QAXSpVoOyBxNtmjhqxDhZm1DSFuIHkKBD2t TdHO4wKP+0/8A== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OL400CRH5SG5H40@st13p35im-asmtp001.me.com>; Thu, 09 Feb 2017 15:31:31 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-02-09_10:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1702090139 From: Toomas Soome Message-id: <0B4B40AA-E654-4A71-92B0-D8E6CD234B63@me.com> MIME-version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Crochet build for Pi3 fails to boot on r313441 (and later), works on r313109 Date: Thu, 09 Feb 2017 17:31:28 +0200 In-reply-to: <5128b9a9-1186-8c6c-6227-e5e8a087cf89@denninger.net> Cc: freebsd-current@freebsd.org To: Karl Denninger References: <517ab0d5-412a-35dd-7d0d-d8297af43b46@denninger.net> <4a6f872b-cee1-57e5-7a72-a1d445f9926f@denninger.net> <5128b9a9-1186-8c6c-6227-e5e8a087cf89@denninger.net> X-Mailer: Apple Mail (2.3259) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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: Thu, 09 Feb 2017 15:31:33 -0000 > On 9. veebr 2017, at 17:05, Karl Denninger wrote: >=20 >=20 > On 2/9/2017 08:58, Toomas Soome wrote: >>> On 9. veebr 2017, at 16:36, Karl Denninger = wrote: >>>=20 >>>=20 >>> On 2/8/2017 16:18, Karl Denninger wrote: >>>> r313441 blows up on the Pi3 in /boot/loader.efi with: >>>>=20 >>>> FreeBSD/arm64 EFI loader, Revision 1.1 >>>> (Tue Feb 7 15:15:52 CST 2017 freebsd@NewFS.denninger.net = ) >>>> Failed to start image provided by UFS (14) >>>> "Synchronous Abort" handler, esr 0x96000004 >>>> ELR: 3af62cec >>>> LR: 3af61d60 >>>> x0 : 0000000000000001 x1 : 0000000000000001 >>>> x2 : 000000003afeb000 x3 : 000000000000003f >>>> x4 : 0000000000000020 x5 : 0000000000000010 >>>> x6 : 0000000000000000 x7 : 0000000039b260a4 >>>> x8 : 000000003af61d48 x9 : 000000000000000d >>>> x10: 0000000000000030 x11: 0000000000000000 >>>> x12: 0000000000000000 x13: 0000000000000002 >>>> x14: 0000000000000000 x15: 0000000000000000 >>>> x16: 0000000000000000 x17: 0000000000000000 >>>> x18: 000000003ab30df8 x19: 0000000037a16008 >>>> x20: 0000000000000000 x21: 0000000000000000 >>>> x22: 0000000039b28000 x23: 0000000039b1d49c >>>> x24: 0000000039b28850 x25: 000000003ab3d740 >>>> x26: 000000003af839a0 x27: 0000000039b2e3e8 >>>> x28: 0000000000000000 x29: 000000003ab2ef60 >>>>=20 >>>> Resetting CPU ... >>>>=20 >>>> If you copy in a loader.efi from an earlier build (e.g. r313109) = then the system boots but complains about SMP problems, fails to start = any of the other CPUs (although it sees them) and panics before it = reaches a login prompt with what appears to be a problem reading the SD = card (I also get a couple of lor's in here too..... not sure if those = are "real" or false positives) >>>>=20 >>>> B >>> This has been isolated to r313333 in sys/boot/efi; reverting the EFI >>> loader to a previous revision stops the crash. >>>=20 >>> Filed here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216940= = = >>>=20 >> Does it still crash with r313442? I think it does and this is why: >>=20 >> =46rom your log above, the hint is "Failed to start image provided by = UFS (14)=E2=80=9D, so what we can guess here is that for some reason the = loader.efi main() failed to detect the boot device, and did return back = to boot1. >>=20 >> Boot1 did print out this error message and did call panic(). So, the = question is, why it is failing to detect the root fs handle. I=E2=80=99ll = try to check if I can replicate the issue with x86 + ufs. >>=20 >> BTW: sorry for trouble:) >>=20 >> rgds, >> toomas >>=20 > Yes. >=20 > It's isolated to that particular revision, which appears to have = reworked the enumeration of the available devices to boot from. = Reverting only sys/boot/efi to anything before 313333 (e.g. "svn update = -r 313332 ." in src/sys/boot/efi) and rebuilding results in a loader.efi = that successfully loads and starts the kernel. >=20 Well, the x86 version does not appear to have problems with finding the = ufs devices. So this has to be some sort of corner case related to arm:( = unfortunately I do not have much variants to test arm, except qemu=E2=80=A6= so some help would be needed there. Since the only crash is from boot1 = call to panic, I am pretty sure the disk detection and setup was ok, so = we should get disk list if we insert something like: for (i =3D 0; devsw[i] !=3D NULL; i++) { if (devsw[i]->dv_print !=3D NULL){ if (devsw[i]->dv_print(verbose)) break; } } after dv_init() loop. If thats true, then it should not take too much to find why we fail to = get the handle for root fs in case of arm=E2=80=A6=20 rgds, toomas