Re: Fresh installed Freebsd 9 don't boot from hd

on 24/10/2011 16:41 John Baldwin said the following:
> 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.
> 

I am all for this.
Unfortunately. ENOTIME to do this properly at the moment.

-- 
Andriy Gapon