Date: Tue, 27 Sep 2016 11:36:34 -0600 From: Warner Losh <imp@bsdimp.com> To: Allan Jude <allanjude@freebsd.org> Cc: John Baldwin <jhb@freebsd.org>, Warner Losh <imp@freebsd.org>, src-committers <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, Ed Maste <emaste@freebsd.org> Subject: Re: svn commit: r305353 - in head/sys/boot: i386 i386/boot0 i386/boot2 i386/btx/btx i386/btx/btxldr i386/cdboot i386/gptboot i386/gptzfsboot i386/mbr i386/pmbr i386/pxeldr i386/zfsboot pc98 pc98/boot0 ... Message-ID: <CANCZdfq81O-xD5PuvCxW128G1BiLPUBeQg6=14VQ=8H0V%2B-Nkw@mail.gmail.com> In-Reply-To: <88d79107-7fbc-1dfd-4ea9-feceaf4a4fac@freebsd.org> References: <201609031526.u83FQSCZ017350@repo.freebsd.org> <4af03d4b-5e5e-2482-c21f-538d95e921b6@freebsd.org> <CANCZdfos2GFH%2BH8Auo3e2uR8OCy2Ed750P=BfQ3P5aayybaAOg@mail.gmail.com> <1577832.dOPa6L4zTd@ralph.baldwin.cx> <CANCZdfr=uL6_FLJMjggmwBeaGvwR8CauMo1v6ToZ4pyf_YBkvw@mail.gmail.com> <88d79107-7fbc-1dfd-4ea9-feceaf4a4fac@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 27, 2016 at 2:14 AM, Allan Jude <allanjude@freebsd.org> wrote: > On 2016-09-27 01:02, Warner Losh wrote: >> On Mon, Sep 26, 2016 at 11:00 AM, John Baldwin <jhb@freebsd.org> wrote: >>> On Saturday, September 24, 2016 02:56:05 PM Warner Losh wrote: >>>> On Fri, Sep 23, 2016 at 4:17 PM, Allan Jude <allanjude@freebsd.org> wrote: >>>>> On 09/03/16 11:26 AM, Warner Losh wrote: >>>>>> Author: imp >>>>>> Date: Sat Sep 3 15:26:28 2016 >>>>>> New Revision: 305353 >>>>>> URL: https://svnweb.freebsd.org/changeset/base/305353 >>>>>> >>>>>> Log: >>>>>> Don't use -N to set the OMAGIC with data and text writeable and data >>>>>> not page aligned. To do this, use the ld script gnu ld installs on my >>>>>> system. >>>>>> >>>>>> This is imperfect: LDFLAGS_BIN and LD_FLAGS_BIN describe different >>>>>> things. The loader script could be better named and take into account >>>>>> other architectures. And having two different mechanisms to do >>>>>> basically the same thing needs study. However, it's blocking forward >>>>>> progress on lld, so I'll work in parallel to sort these out. >>>>>> >>>>>> Differential Revision: https://reviews.freebsd.org/D7409 >>>>>> Reviewed by: emaste >>>>>> >>>>> >>>>> This breaks booting on my Lenovo laptop. The BTX client crashes and >>>>> dumps the registers. >>>>> >>>>> Reverting this commit solved it. >>>>> >>>>> Is there something I can do to help investigate this? >>>> >>>> I assume you bisected all boot loader changes and it fails across this >>>> commit? If not, that's the first step. >>>> >>>> If so, perhaps the place to start is with the dump? >>> >>> The dump is a good place to start, but it would also be useful to know >>> >>> 1) Which stage dies (e.g. can you get into the gptboot/boot2 prompt meaning >>> it it is probably btxldr.S dying trying to parse a.out header from >>> /boot/loader vs are you dying before that point meaning it is in boot1.S >>> or gptldr.S)? >> >> Yes. This is absolutely critical. Until we know what dies, what the >> trace backs are, what options were in effect and how the binaries were >> broken there's little more that I can do because it works for me >> everywhere I've tried it. >> >>> 2) Once we know which stage, it would be good to compare the a.out headers >>> and possibly the contents of the relevant binaries. The aforementioned >>> .S files all parse the a.out header in assembly as well as the BTX >>> header (they assume that BTX itself is present in the bits loaded from >>> disk immediately followed by the binary header). That code isn't very >>> flexible and it doesn't seem far fetched for this change to break it. >> >> I just wonder why it works on the amd64 servers and laptops, the i386 >> laptops and in qemu for me, but fails for the OP. If it broke a.out, >> I contend it would break for everybody since a.out headers are 'hit >> dinosaur over the head' level of complexity and subtly. While I don't >> doubt there's a problem, I suspect it is very specific to a particular >> set of laptops that were on the edge before and this kicks us over the >> edge just enough to stomp on some area that was protected before. >> >> Warner >> > > It works fine for me with a regular boot, but when booting a GELI > encrypted disk, is dies. > > It is in boot2, before it reads the loader. > > Specifically, it seems to be at the call to: enc_xform_aes_xts.reinit > [opencrypto aes_xts_reinit()] > > Now that I am back home, I'll try to narrow it down further, and look at > the difference between gptzfsboot compiled with and without the > different LD flags. > > It works perfectly fine with the makefile changes reverted. OK. Thanks Allan. Since I didn't test gel-booting, I can believe it failed there. Please let me know if you need more help or followup. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfq81O-xD5PuvCxW128G1BiLPUBeQg6=14VQ=8H0V%2B-Nkw>