Date: Mon, 24 Oct 2011 09:41:02 -0400 From: John Baldwin <jhb@freebsd.org> To: Andriy Gapon <avg@freebsd.org> Cc: Pavel Timofeev <timp87@gmail.com>, freebsd-current@freebsd.org, Dennis Koegel <dk@neveragain.de> Subject: Re: Fresh installed Freebsd 9 don't boot from hd Message-ID: <201110240941.02515.jhb@freebsd.org> In-Reply-To: <4EA455A7.2060301@FreeBSD.org> References: <CAAoTqftvv1t214Q9uWJR-Jug4GJEZshXyOr6uB_d19h2NV89XA@mail.gmail.com> <20111023152754.GA35505@neveragain.de> <4EA455A7.2060301@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday, October 23, 2011 1:57:59 pm Andriy Gapon wrote:
> on 23/10/2011 18:27 Dennis Koegel said the following:
> > On Fri, Oct 21, 2011 at 04:33:38PM -0400, John Baldwin wrote:
> >> Working offline with Dennis, we found that changing the CFLAGS in
> >> sys/boot/i386/gptboot/Makefile from "-O1" to "-Os -mrtd" (partially reverting
> >> an earlier commit) fixed gptboot. The next test for someone to do would be to
> >> try just adding "-mrtd" and leaving "-O1" as-is to see if that fixes it.
> >
> > More test results:
> >
> > gcc -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time \
> > -mno-align-long-strings -mrtd [from before r225530]: Boots OK
> > gcc -Os -mrtd: Boots OK
> > gcc -O1 -mrtd: Fails
> > gcc -O1: Fails
> > gcc -O0: Fails
> > gcc -Os: Boots OK
> >
> > clang -O1: Fails
> > clang -Os: Fails
> > clang -Oz: Fails
> >
> > I've put some printf()s into gpt{,boot}.c to trace where the reboot is
> > triggered. It appears to be in drvsize() (called from gptread()). OTOH
> > the debug output may have changed where the problem occurs, I don't
> > know about that.
> >
> > With 9.0R drawing near, CFLAGS should be s/-O1/-Os/, until we can figure
> > out what happens. But as for why gcc's magic -Os is required and clang's
> > output doesn't work at all, I'm clueless.
>
> Thank you for your very valuable analysis!
> I looked at a difference in assembly code of the drvsize function produced by
> gcc -Os and by gcc -O1. One thing that was immediately obvious is that gcc
> places the params array and the sectors variable in a different order for
> different options. One idea is that if BIOS actually writes beyond the end of
> the array, then in one case it could be harmless (overwrites the sector
> variable), but in the other case it could be more harmful.
> I found a document that suggests a possibility of BIOS writing more bytes to the
> array than its current size of 0x42:
> http://www.t13.org/documents/UploadedDocuments/docs2008/e08134r1-BIOS_Enhanced_Disk_Drive_Services_4.0.pdf
>
> Of course, the size of the array is passed to BIOS at the start of the array and
> so a _non-buggy_ BIOS should not write beyond the array, but we live in a
> non-perfect world.
Hmm, I think we've had to do a similar workaround in the past for a different
BIOS call (SMAP maybe?). However, I do have one request, can we declare an
actual structure instead of a silly char array? Then we can remove the weird
casts with offsets into it, etc. Having an actual struct would be far more
readable and less bug-prone.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201110240941.02515.jhb>