Date: Mon, 22 Aug 2016 10:20:10 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: 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: <7bdb0cf5-e139-375b-8be6-c1280e39da25@FreeBSD.org> In-Reply-To: <201608180037.u7I0b77A095653@repo.freebsd.org> References: <201608180037.u7I0b77A095653@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18/08/2016 03:37, Toomas Soome wrote: > Author: tsoome > Date: Thu Aug 18 00:37:07 2016 > New Revision: 304321 > URL: https://svnweb.freebsd.org/changeset/base/304321 > > Log: > Add SHA512, skein, large blocks support for loader zfs. > > Updated sha512 from illumos. > Using skein from freebsd crypto tree. > Since loader itself is using 64MB memory for heap, updated zfsboot to > use same, and this also allows to support zfs large blocks. > > Note, adding additional features does increate zfsboot code, therefore > this update does increase zfsboot code to 128k, also I have ported gptldr.S > update to zfsldr.S to support 64k+ code. 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 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. 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=yes LOADER_FIREWIRE_SUPPORT=yes My memory of loader's memory placement and layout has faded, so I can't elaborate further on my guess. Also, there is this report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212038 That problem could have a different cause. It should be easier to analyze as the it happens with bhyveload, i.e., in userland. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7bdb0cf5-e139-375b-8be6-c1280e39da25>