Date: Mon, 22 Aug 2016 12:44:19 +0300 From: Toomas Soome <tsoome@me.com> To: Andriy Gapon <avg@FreeBSD.org> Cc: Toomas Soome <tsoome@FreeBSD.org>, src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org 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... Message-ID: <AE24A37C-51F5-4CEC-9399-D7FDEBC93972@me.com> In-Reply-To: <4c76efd6-146a-e70b-c065-729d223e3398@FreeBSD.org> References: <201608180037.u7I0b77A095653@repo.freebsd.org> <7bdb0cf5-e139-375b-8be6-c1280e39da25@FreeBSD.org> <4c76efd6-146a-e70b-c065-729d223e3398@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 22. aug 2016, at 11:09, Andriy Gapon <avg@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AE24A37C-51F5-4CEC-9399-D7FDEBC93972>