From owner-svn-src-all@freebsd.org Mon Aug 22 09:44:30 2016 Return-Path: Delivered-To: svn-src-all@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 F3C76BBF385; Mon, 22 Aug 2016 09:44:29 +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 CA2531C84; Mon, 22 Aug 2016 09:44:29 +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 <0OCB00P001H08L00@st13p35im-asmtp001.me.com>; Mon, 22 Aug 2016 09:44:23 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1471859063; bh=xnymKOt5AlJbXZxgmH15WGmA9j9E8rHbsfHIvIL3mvI=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=LG8sMVVP8ina1ldpG6DojBUdDwcdFKjJ+txZ3Ql7fXYMUUdfJWBLn5aFZNWoBq/cH +m7njlCDXIUipuRArUumMb+TqGEbRgNTp8aV6FIWKiNKPKDSFZ94mMWVOdFWEb79+G jg019hFK5JnbAPvDFSPDuwiihIx7w3/eQaQOJiBoIYOKh2G8yVkBA08Als5KmEIEKF tERWgCnGER1QkDXQjJYl8RnlWuoIkr1xVmmyh3pmbXLRApbGngVzrPSEMGlYTDBeKI IyRpKv2FzxP7uM7nxB2YarmuwUvgaGcUpdhnrSoFNzU6nTFfrOsa4FbBHH6ilSvLYo 0gDt1Vp5x1cEQ== Received: from 230-11-196-88.dyn.estpak.ee (230-11-196-88.dyn.estpak.ee [88.196.11.230]) by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OCB00KSP1PWUM00@st13p35im-asmtp001.me.com>; Mon, 22 Aug 2016 09:44:22 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-08-22_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=10 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1608220104 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: svn commit: r304321 - in head/sys: boot/efi/boot1 boot/efi/loader boot/i386/boot2 boot/i386/gptboot boot/i386/gptzfsboot boot/i386/zfsboot boot/userboot/ficl boot/userboot/userboot boot/userboot/zf... From: Toomas Soome In-reply-to: <4c76efd6-146a-e70b-c065-729d223e3398@FreeBSD.org> Date: Mon, 22 Aug 2016 12:44:19 +0300 Cc: Toomas Soome , src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Content-transfer-encoding: quoted-printable Message-id: References: <201608180037.u7I0b77A095653@repo.freebsd.org> <7bdb0cf5-e139-375b-8be6-c1280e39da25@FreeBSD.org> <4c76efd6-146a-e70b-c065-729d223e3398@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.3124) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 09:44:30 -0000 > On 22. aug 2016, at 11:09, Andriy Gapon wrote: >=20 > On 22/08/2016 10:20, Andriy Gapon wrote: >> This commit breaks boot process for me and in a quite weird way. >> I don't have a serial console, so a couple of screenshots. >> This is what happens with this change: >> https://people.freebsd.org/~avg/boot-fail-1024x768.jpg >> This is what I have with the previous loader: >> https://people.freebsd.org/~avg/boot-success-1024x768.jpg >>=20 >> As you can see somehow the HDD gets misdetected as a floppy, BIOS = disk ID is 0x0 >> as opposed to 0x80. Also, the disk size is incorrect too. = Additionally the >> firewire is not detected. >>=20 >> I suspect that the problem may have to do with the increased loader = size. >> I must add that I have these in src.conf: >> LOADER_BZIP2_SUPPORT=3Dyes >> LOADER_FIREWIRE_SUPPORT=3Dyes >=20 > Removing both of those options allows the boot to succeed. > Which sort of, maybe confirms the hypothesis. >=20 yep, just enabling firewire does not blow it.=20 > Also, as extra data points, this is how SMAP is reported by a good = zfsloader: > https://people.freebsd.org/~avg/boot-smap-1024x768.jpg > And it seems to be corrupted when using the bad zfsloader: > https://people.freebsd.org/~avg/boot-smap-corrupt-1024x768.jpg >=20 > Base memory size is 634880 (almost enough for everyone). > Extended memory is ~ 3.5GB and the high memory is 64MB at the top of = it. >=20 > File size of the loader that does not work is 483328 bytes. > $ size /usr/obj/usr/src/sys/boot/i386/zfsloader/zfsloader.bin > text data bss dec hex filename > 438000 26416 130896 595312 0x91570 > /usr/obj/usr/src/sys/boot/i386/zfsloader/zfsloader.bin >=20 > File size of the loader that works is 450560 bytes. > $ size /usr/obj/usr/src/sys/boot/i386/zfsloader/zfsloader.bin > text data bss dec hex filename > 410920 23304 50636 484860 0x765fc > /usr/obj/usr/src/sys/boot/i386/zfsloader/zfsloader.bin >=20 > So, it seems that there is a practical limit on a loader size for = real-world x86 > BIOS-based systems. We are very close to the limit with the default = ZFS loader > and we cross that limit if additional loader features are enabled. >=20 > My opinion is that we should stop cramming all possible ZFS features = into the > loader. Instead we should admit that the boot pool, or at least boot > filesystem, must have certain limitations on features that it can use. = Then > there is no need to add support for those features to the loader. Well, it is arguable if its more important to have bzip in loader or = support for checksum algorithms, especially as zfs does compression, but = lets not get onto this slippery ground;) but, yes, the root cause of the issue is that if additional [relatively = large] code is included by src.conf setup, we will hit the ceiling of = <1MB memory area, as client base (0xa000) + code + data are all = occupying sequential memory and we are reaching EBDA area in low memory. And indeed, it does mean more conservative approach about what is = included and how. btw, just to compare, zfsloader with ficl 4 + zfs additionally with gzip = (as gzip is needed for for other reasons anyhow, so its =E2=80=9Cfree = lunch=E2=80=9D) in my illumos build is: -r--r--r-- 1 root sys 434176 aug 21 16:04 /boot/zfsloader and the current head + firewire in freebsd is: -rw-r--r-- 1 root wheel 454656 Aug 22 11:54 /boot/zfsloader I do suspect the size difference there is partially due to ficl, in = illumos (ficl 4): -rw-r--r-- 1 tsoome staff 132508 aug 22 09:18 libficl.a and freebsd (ficl 3): -rw-r--r-- 1 root wheel 213748 Aug 19 01:57 libficl.a so, there definitely is some space=E2=80=A6=20 rgds, toomas >=20 > Personally, I would prefer that this commit is backed out unless it = can be > strongly justified. Unless we can quickly find a way to run the = loader at a > different, less restricted memory location. >=20 >> My memory of loader's memory placement and layout has faded, so I = can't >> elaborate further on my guess. >>=20 >> Also, there is this report: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212038 >> That problem could have a different cause. It should be easier to = analyze as >> the it happens with bhyveload, i.e., in userland. >=20 >=20 > --=20 > Andriy Gapon