From owner-freebsd-current@FreeBSD.ORG Mon Oct 24 13:41:04 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 122AF106564A; Mon, 24 Oct 2011 13:41:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DBC288FC12; Mon, 24 Oct 2011 13:41:03 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 7AF9546B46; Mon, 24 Oct 2011 09:41:03 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 046A18A02E; Mon, 24 Oct 2011 09:41:03 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Mon, 24 Oct 2011 09:41:02 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <20111023152754.GA35505@neveragain.de> <4EA455A7.2060301@FreeBSD.org> In-Reply-To: <4EA455A7.2060301@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201110240941.02515.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 24 Oct 2011 09:41:03 -0400 (EDT) Cc: Pavel Timofeev , freebsd-current@freebsd.org, Dennis Koegel Subject: Re: Fresh installed Freebsd 9 don't boot from hd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 13:41:04 -0000 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