From owner-freebsd-stable@freebsd.org Tue May 16 16:00:36 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 8ADA0D70208 for ; Tue, 16 May 2017 16:00:36 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp002.me.com (st13p35im-asmtp002.me.com [17.164.199.65]) (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 596231089 for ; Tue, 16 May 2017 16:00:36 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp002.me.com by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OQ100600YX5QX00@st13p35im-asmtp002.me.com> for freebsd-stable@freebsd.org; Tue, 16 May 2017 16:00:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1494950422; bh=hHtUxDZFC0kKYbnnS1jayj33CqkR8J/Cp8wHNEYCjao=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=iqvvAvpZIAqRVZfnfC3ZcJqsPN9OIOt1kFV9aDFwso92mpx/JJZQ/bqsDBN/yJpNI QyusyEQ/utm5p6QIBJNwD9EmeOu1Ms7hFtVOIdU64z/DGvIgYVn9Qj2BUbO/q/V6Ha SstPEjfvgFhzzWqSVBw2Eeeztf2NmtQfUYiFGfMGZ30aN3k0xZpZ9F9hNeVtSvGky4 ywRU9oRkZK2aPkYKjKZNglpejCpUmDs2MJT6+g58sloqpY/EhB7CW0tEHhkIY/GoSu dn+zSrhmiG4jRivdyuiMFfmWDw4S3ALVsH+auPhWm1p8k57pchh9nhr9UeEi+2nvVk fme8ok2ldhAYQ== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OQ100I7CZ4G7310@st13p35im-asmtp002.me.com>; Tue, 16 May 2017 16:00:19 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-16_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1701120000 definitions=main-1705160127 From: Toomas Soome Message-id: MIME-version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: EFI loader doesn't handle md_preload (md_image) correct? Date: Tue, 16 May 2017 19:00:15 +0300 In-reply-to: <591B1EA4.600@omnilan.de> Cc: freebsd-stable@freebsd.org To: Harry Schmalzbauer References: <591B12C6.4040301@omnilan.de> <591B1A8B.6070803@omnilan.de> <591B1EA4.600@omnilan.de> X-Mailer: Apple Mail (2.3273) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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: Tue, 16 May 2017 16:00:36 -0000 > On 16. mai 2017, at 18:45, Harry Schmalzbauer = wrote: >=20 > Bez=C3=BCglich Harry Schmalzbauer's Nachricht vom 16.05.2017 17:28 = (localtime): >> Bez=C3=BCglich Toomas Soome's Nachricht vom 16.05.2017 16:57 = (localtime): >>>> On 16. mai 2017, at 17:55, Harry Schmalzbauer = wrote: >>>>=20 >>>> Hello, >>>>=20 >>>> unfortunately I had some trouble with my preferred MFS-root setups. >>>> It seems EFI loader doesn't handle type md_image correctly. >>>>=20 >>>> If I load any md_image with loader invoked by gptboot or = gptzfsboot, >>>> 'lsmod' >>>> shows "elf kernel", "elf obj module(s)" and "md_image". >>>>=20 >>>> Using the same loader.conf, but EFI loader, the md_image-file is >>>> prompted and sems to be loaded, but not registered. There's no = md_image >>>> with 'lsmod', hence it's not astonsihing that kernel doesn't attach = md0 >>>> so booting fails since there's no rootfs. >>>>=20 >>>> Any help highly appreciated, hope Toomas doesn't mind beeing = initially CC'd. >>>>=20 >>>> Thanks, >>>>=20 >>>> -harry >>>=20 >>> The first question is, how large is the md_image and what other = modules are loaded? >> Thanks for your quick response. >>=20 >> The images are 50-500MB uncompressed (provided by gzip compressed = file). >> Small ammount of elf modules, 5, each ~50kB. >=20 > On the real HW, there's vmm and some more: > Id Refs Address Size Name > 1 46 0xffffffff80200000 16M kernel > 2 1 0xffffffff8121d000 86K unionfs.ko > 3 1 0xffffffff81233000 3.1M zfs.ko > 4 2 0xffffffff81545000 51K opensolaris.ko > 5 7 0xffffffff81552000 279K usb.ko > 6 1 0xffffffff81598000 67K ukbd.ko > 7 1 0xffffffff815a9000 51K umass.ko > 8 1 0xffffffff815b6000 46K aesni.ko > 9 1 0xffffffff815c3000 54K uhci.ko > 10 1 0xffffffff815d1000 65K ehci.ko > 11 1 0xffffffff815e2000 15K cc_htcp.ko > 12 1 0xffffffff815e6000 3.4M vmm.ko > 13 1 0xffffffffa3a21000 12K ums.ko > 14 1 0xffffffffa3a24000 9.1K uhid.ko >=20 > Providing md_image uncompressed doesn't change anything. >=20 > Will deploy a /usr separated rootfs, which is only ~100MB uncompressed > and see if that changes anything. > That's all I can provide, code is far beyond my knowledge... >=20 > -harry The issue is, that current UEFI implementation is using 64MB staging = memory for loading the kernel and modules and files. When the boot is = called, the relocation code will put the bits from staging area into the = final places. The BIOS version does not need such staging area, and that = will explain the difference. I actually have different implementation to address the same problem, = but thats for illumos case, and will need some work to make it usable = for freebsd; the idea is actually simple - allocate staging area per = loaded file and relocate the bits into the place by component, not as = continuous large chunk (this would also allow to avoid the mines like = planted by hyperv;), but right now there is no very quick real solution = other than just build efi loader with larger staging size. rgds, toomas