| From | Sent On | Attachments |
|---|---|---|
| Pavel Timofeev | Oct 20, 2011 12:27 am | |
| Dennis Koegel | Oct 21, 2011 1:58 am | |
| Pavel Timofeev | Oct 21, 2011 2:44 am | |
| Lars Engels | Oct 21, 2011 4:08 am | |
| Pavel Timofeev | Oct 21, 2011 4:12 am | |
| Gunnar Schaefer | Oct 21, 2011 12:19 pm | |
| John Baldwin | Oct 21, 2011 1:33 pm | |
| Andriy Gapon | Oct 21, 2011 2:27 pm | |
| Andriy Gapon | Oct 21, 2011 2:36 pm | |
| Gunnar Schaefer | Oct 21, 2011 3:22 pm | |
| Andriy Gapon | Oct 23, 2011 5:50 am | |
| Dennis Koegel | Oct 23, 2011 8:27 am | |
| Andriy Gapon | Oct 23, 2011 10:57 am | |
| Dennis Koegel | Oct 23, 2011 12:55 pm | |
| Dimitry Andric | Oct 23, 2011 1:08 pm | |
| John Baldwin | Oct 24, 2011 5:18 am | |
| John Baldwin | Oct 24, 2011 6:40 am | |
| Andriy Gapon | Oct 24, 2011 6:47 am | |
| John Baldwin | Oct 24, 2011 8:33 am | |
| Andriy Gapon | Oct 24, 2011 9:24 am | |
| John Baldwin | Oct 24, 2011 11:23 am | |
| Dennis Koegel | Oct 24, 2011 2:39 pm | |
| Gunnar Schaefer | Oct 24, 2011 4:20 pm | |
| Pavel Timofeev | Oct 25, 2011 12:13 am | |
| Andriy Gapon | Oct 25, 2011 4:26 am | |
| John Baldwin | Oct 25, 2011 12:55 pm | |
| Pavel Timofeev | Nov 8, 2011 11:10 am | |
| John Baldwin | Nov 8, 2011 11:31 am | |
| Pavel Timofeev | Nov 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.
-- Andriy Gapon
_______________________________________________ free...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "free...@freebsd.org"





