atom feed29 messages in org.freebsd.freebsd-currentRe: Fresh installed Freebsd 9 don't b...
FromSent OnAttachments
Pavel TimofeevOct 20, 2011 12:27 am 
Dennis KoegelOct 21, 2011 1:58 am 
Pavel TimofeevOct 21, 2011 2:44 am 
Lars EngelsOct 21, 2011 4:08 am 
Pavel TimofeevOct 21, 2011 4:12 am 
Gunnar SchaeferOct 21, 2011 12:19 pm 
John BaldwinOct 21, 2011 1:33 pm 
Andriy GaponOct 21, 2011 2:27 pm 
Andriy GaponOct 21, 2011 2:36 pm 
Gunnar SchaeferOct 21, 2011 3:22 pm 
Andriy GaponOct 23, 2011 5:50 am 
Dennis KoegelOct 23, 2011 8:27 am 
Andriy GaponOct 23, 2011 10:57 am 
Dennis KoegelOct 23, 2011 12:55 pm 
Dimitry AndricOct 23, 2011 1:08 pm 
John BaldwinOct 24, 2011 5:18 am 
John BaldwinOct 24, 2011 6:40 am 
Andriy GaponOct 24, 2011 6:47 am 
John BaldwinOct 24, 2011 8:33 am 
Andriy GaponOct 24, 2011 9:24 am 
John BaldwinOct 24, 2011 11:23 am 
Dennis KoegelOct 24, 2011 2:39 pm 
Gunnar SchaeferOct 24, 2011 4:20 pm 
Pavel TimofeevOct 25, 2011 12:13 am 
Andriy GaponOct 25, 2011 4:26 am 
John BaldwinOct 25, 2011 12:55 pm 
Pavel TimofeevNov 8, 2011 11:10 am 
John BaldwinNov 8, 2011 11:31 am 
Pavel TimofeevNov 9, 2011 10:48 pm 
Subject:Re: Fresh installed Freebsd 9 don't boot from hd
From:Andriy Gapon (av@FreeBSD.org)
Date:Oct 24, 2011 6:47:19 am
List:org.freebsd.freebsd-current

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.