On Mon, Sep 26, 2016 at 11:00 AM, John Baldwin <j...@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 <allanj...@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 _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
