Re: Fresh installed Freebsd 9 don't boot from hd
Thank you! I see this fix in 9 STABLE.
Works)
2011/11/8 John Baldwin j...@freebsd.org:
On Tuesday, November 08, 2011 2:10:51 pm Pavel Timofeev wrote:
FreeBSD accessor 9.0-RC2 FreeBSD 9.0-RC2 #0: Tue Nov 8 20:52:11 MSK
2011 mox@accessor:/usr/obj/usr/src/sys/GENERIC amd64
RC2 is coming. Nothing changed.
Sorry, haven't been able to merge them to 9 yet.
2011/10/25 John Baldwin j...@freebsd.org:
On Monday, October 24, 2011 7:21:27 pm Gunnar Schaefer wrote:
On Oct 24, 2011, at 2:40 PM, Dennis Koegel wrote:
On Mon, Oct 24, 2011 at 11:33:23AM -0400, John Baldwin wrote:
Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
GCC chokes here in drv.c:{49,50}: cannot convert to a pointer type:
v86.ds = VTOPSEG(params);
v86.esi = VTOPOFF(params);
Changed this to params. Also changed sector_size to uint16_t as noted
by Andriy. Boots perfectly! (Tested with gcc and clang)
I'd like to test these patches on my Supermicro machine as well.
Unfortunately, I don't know how to go about it, but I'm hopeful to be able
to
figure it out with some basic instructions. I'm currently running a fresh
RC1
install, and I'm able to boot the system if I set the BIOS to IDE mode,
rather
than AHCI.
Any help would be much appreciated,
I just committed them to HEAD (226748 along with a cleanup in 226746).
They
should backport to 9.
--
John Baldwin
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
FreeBSD accessor 9.0-RC2 FreeBSD 9.0-RC2 #0: Tue Nov 8 20:52:11 MSK
2011 mox@accessor:/usr/obj/usr/src/sys/GENERIC amd64
RC2 is coming. Nothing changed.
2011/10/25 John Baldwin j...@freebsd.org:
On Monday, October 24, 2011 7:21:27 pm Gunnar Schaefer wrote:
On Oct 24, 2011, at 2:40 PM, Dennis Koegel wrote:
On Mon, Oct 24, 2011 at 11:33:23AM -0400, John Baldwin wrote:
Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
GCC chokes here in drv.c:{49,50}: cannot convert to a pointer type:
v86.ds = VTOPSEG(params);
v86.esi = VTOPOFF(params);
Changed this to params. Also changed sector_size to uint16_t as noted
by Andriy. Boots perfectly! (Tested with gcc and clang)
I'd like to test these patches on my Supermicro machine as well.
Unfortunately, I don't know how to go about it, but I'm hopeful to be able to
figure it out with some basic instructions. I'm currently running a fresh RC1
install, and I'm able to boot the system if I set the BIOS to IDE mode, rather
than AHCI.
Any help would be much appreciated,
I just committed them to HEAD (226748 along with a cleanup in 226746). They
should backport to 9.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Tuesday, November 08, 2011 2:10:51 pm Pavel Timofeev wrote:
FreeBSD accessor 9.0-RC2 FreeBSD 9.0-RC2 #0: Tue Nov 8 20:52:11 MSK
2011 mox@accessor:/usr/obj/usr/src/sys/GENERIC amd64
RC2 is coming. Nothing changed.
Sorry, haven't been able to merge them to 9 yet.
2011/10/25 John Baldwin j...@freebsd.org:
On Monday, October 24, 2011 7:21:27 pm Gunnar Schaefer wrote:
On Oct 24, 2011, at 2:40 PM, Dennis Koegel wrote:
On Mon, Oct 24, 2011 at 11:33:23AM -0400, John Baldwin wrote:
Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
GCC chokes here in drv.c:{49,50}: cannot convert to a pointer type:
v86.ds = VTOPSEG(params);
v86.esi = VTOPOFF(params);
Changed this to params. Also changed sector_size to uint16_t as noted
by Andriy. Boots perfectly! (Tested with gcc and clang)
I'd like to test these patches on my Supermicro machine as well.
Unfortunately, I don't know how to go about it, but I'm hopeful to be able
to
figure it out with some basic instructions. I'm currently running a fresh
RC1
install, and I'm able to boot the system if I set the BIOS to IDE mode,
rather
than AHCI.
Any help would be much appreciated,
I just committed them to HEAD (226748 along with a cleanup in 226746). They
should backport to 9.
--
John Baldwin
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
2011/10/24 Dimitry Andric d...@freebsd.org On 2011-10-23 21:56, Dennis Koegel wrote: On Sun, Oct 23, 2011 at 08:57:59PM +0300, Andriy Gapon wrote: I found a document that suggests a possibility of BIOS writing more bytes to the array than its current size of 0x42: [...] Could you please test this hypothesis by trying the following patch? With -O1 and this patch, it boots. Thank you! If you have some time, can you also re-check the other cases you listed before? E.g.: gcc -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time \ -mno-align-long-strings -mrtd [from before r225530]: gcc -Os -mrtd: gcc -O1 -mrtd: gcc -O1: gcc -O0: gcc -Os: clang -O1: clang -Os: clang -Oz: My 5 cents: tested on my HP Proliant DL360 G5 with Andriy's patch clang -O1: ok (VirtualBox with ahci boots too) clang -Os: ok clang -Oz: ok Thanks. :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
on 24/10/2011 21:23 John Baldwin said the following: On Monday, October 24, 2011 12:25:09 pm Andriy Gapon wrote: Also, perhaps edd_params_v3 and edd_params_v4 should inherit edd_params in some smarter way to avoid verbatim duplicates. Yeah, probably so. We will probably never even use them anyway (just as we don't use edd_packet_v3 even though we could probably make use of it to avoid some bounce buffering in the loader). Other than these issues the patch looks great! Perhaps later we could do detailed definitions for things like interface paths for various cases, etc. I doubt we will ever use them. In theory we could pass that information from loader to kernel, so that in a booted system we could try to build a mapping between kernel disks and bios disks, with the boot disk potentially being of the most interest. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Monday, October 24, 2011 7:21:27 pm Gunnar Schaefer wrote:
On Oct 24, 2011, at 2:40 PM, Dennis Koegel wrote:
On Mon, Oct 24, 2011 at 11:33:23AM -0400, John Baldwin wrote:
Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
GCC chokes here in drv.c:{49,50}: cannot convert to a pointer type:
v86.ds = VTOPSEG(params);
v86.esi = VTOPOFF(params);
Changed this to params. Also changed sector_size to uint16_t as noted
by Andriy. Boots perfectly! (Tested with gcc and clang)
I'd like to test these patches on my Supermicro machine as well.
Unfortunately, I don't know how to go about it, but I'm hopeful to be able to
figure it out with some basic instructions. I'm currently running a fresh RC1
install, and I'm able to boot the system if I set the BIOS to IDE mode, rather
than AHCI.
Any help would be much appreciated,
I just committed them to HEAD (226748 along with a cleanup in 226746). They
should backport to 9.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Friday, October 21, 2011 5:37:16 pm Andriy Gapon wrote: on 22/10/2011 00:27 Andriy Gapon said the following: on 21/10/2011 23:33 John Baldwin said the following: On Friday, October 21, 2011 4:58:51 am Dennis Koegel wrote: On Thu, Oct 20, 2011 at 11:28:08AM +0400, Pavel Timofeev wrote: I used FreeBSD 9 amd64 on my HP Proliant DL360 G5 (smart array p400i mirror) as test. [...] It was fresh install and I choose guided partitioning (GPT) But after reboot my server don't boot from hd. We have the same issue on a DL580 G7. Install runs fine, but when it's time for the first boot, the bootcode emits a single '-' (where usually it would be spinning for a moment while loading), hangs for about two seconds, and then reboots. 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. Hmm, this is quite unexpected... Do you have a hypothesis why not using -mrtd could cause a problem (a miscompilation?) ? I've just got one: maybe the trouble is caused by the sio_putc procedure in sys/boot/i386/btx/btx/btx.S. It seems to be the only place in the boot code where 'ret number' instruction is explicitly used. A litmus question: do those experiencing the trouble all have BTX_SERIAL defined? No, they all have an HP machine. P.S. BTW, is BTX_SERIAL documented anywhere? It is not, and I strongly doubt anyone has it enabled. You can't use it with boot2 for example due to size bloat. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
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
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
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
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Monday, October 24, 2011 9:47:42 am Andriy Gapon wrote:
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.
Ugh, it looks like in EDD 4.0 they silently expanded the path field to 16 bytes
instead of 8 as in EDD 3.0 which is why the HP BIOS is probably writing an extra
four bytes.
Ah, so the deal is that the device path bit is variable length and the caller is
supposed to set the length on input which we aren't doing. However, we don't
care about the device path stuff anyway, so we can set a smaller input value.
Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
on 24/10/2011 18:33 John Baldwin said the following:
On Monday, October 24, 2011 9:47:42 am Andriy Gapon wrote:
on 24/10/2011 16:41 John Baldwin said the following:
On Sunday, October 23, 2011 1:57:59 pm Andriy Gapon wrote:
[snip]
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.
Ugh, it looks like in EDD 4.0 they silently expanded the path field to 16
bytes
instead of 8 as in EDD 3.0 which is why the HP BIOS is probably writing an
extra
four bytes.
Yes, that's exactly what I meant above, but probably wasn't clear about that.
Ah, so the deal is that the device path bit is variable length and the caller
is
supposed to set the length on input which we aren't doing. However, we don't
care about the device path stuff anyway, so we can set a smaller input value.
Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
+struct edd_params {
+ uint16_tlen;
+ uint16_tflags;
+ uint32_tcylinders;
+ uint32_theads;
+ uint32_tsectors_per_track;
+ uint64_tsectors;
+ uint32_tsector_size;
sector_size should be uint16_t, I think. Ditto for edd_params_v3 and
edd_params_v4.
sizeof(struct edd_params) should be 30, judging from the specs.
+ uint16_tedd_params_seg;
+ uint16_tedd_params_off;
+};
Perhaps the structures should be declared __packed (if only just in case)?
Also, perhaps edd_params_v3 and edd_params_v4 should inherit edd_params in some
smarter way to avoid verbatim duplicates.
Other than these issues the patch looks great!
Perhaps later we could do detailed definitions for things like interface paths
for
various cases, etc.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Monday, October 24, 2011 12:25:09 pm Andriy Gapon wrote:
on 24/10/2011 18:33 John Baldwin said the following:
On Monday, October 24, 2011 9:47:42 am Andriy Gapon wrote:
on 24/10/2011 16:41 John Baldwin said the following:
On Sunday, October 23, 2011 1:57:59 pm Andriy Gapon wrote:
[snip]
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.
Ugh, it looks like in EDD 4.0 they silently expanded the path field to 16
bytes
instead of 8 as in EDD 3.0 which is why the HP BIOS is probably writing an
extra
four bytes.
Yes, that's exactly what I meant above, but probably wasn't clear about that.
Ah, so the deal is that the device path bit is variable length and the
caller is
supposed to set the length on input which we aren't doing. However, we
don't
care about the device path stuff anyway, so we can set a smaller input
value.
Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
+struct edd_params {
+ uint16_tlen;
+ uint16_tflags;
+ uint32_tcylinders;
+ uint32_theads;
+ uint32_tsectors_per_track;
+ uint64_tsectors;
+ uint32_tsector_size;
sector_size should be uint16_t, I think. Ditto for edd_params_v3 and
edd_params_v4.
sizeof(struct edd_params) should be 30, judging from the specs.
Oops, yeah.
+ uint16_tedd_params_seg;
+ uint16_tedd_params_off;
+};
Perhaps the structures should be declared __packed (if only just in case)?
Also, perhaps edd_params_v3 and edd_params_v4 should inherit edd_params in
some
smarter way to avoid verbatim duplicates.
Yeah, probably so. We will probably never even use them anyway (just as we
don't
use edd_packet_v3 even though we could probably make use of it to avoid some
bounce buffering in the loader).
Other than these issues the patch looks great!
Perhaps later we could do detailed definitions for things like interface
paths for
various cases, etc.
I doubt we will ever use them.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Mon, Oct 24, 2011 at 11:33:23AM -0400, John Baldwin wrote:
Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
GCC chokes here in drv.c:{49,50}: cannot convert to a pointer type:
v86.ds = VTOPSEG(params);
v86.esi = VTOPOFF(params);
Changed this to params. Also changed sector_size to uint16_t as noted
by Andriy. Boots perfectly! (Tested with gcc and clang)
Thanks!
- D.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Oct 24, 2011, at 2:40 PM, Dennis Koegel wrote:
On Mon, Oct 24, 2011 at 11:33:23AM -0400, John Baldwin wrote:
Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
GCC chokes here in drv.c:{49,50}: cannot convert to a pointer type:
v86.ds = VTOPSEG(params);
v86.esi = VTOPOFF(params);
Changed this to params. Also changed sector_size to uint16_t as noted
by Andriy. Boots perfectly! (Tested with gcc and clang)
I'd like to test these patches on my Supermicro machine as well. Unfortunately,
I don't know how to go about it, but I'm hopeful to be able to figure it out
with some basic instructions. I'm currently running a fresh RC1 install, and
I'm able to boot the system if I set the BIOS to IDE mode, rather than AHCI.
Any help would be much appreciated,
Gunnar___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
on 22/10/2011 01:22 Gunnar Schaefer said the following: On Oct 21, 2011, at 2:37 PM, Andriy Gapon wrote: A litmus question: do those experiencing the trouble all have BTX_SERIAL defined? Not sure where BTX_SERIAL would be defined, but I'm seeing the problem with the generic kernel. Does that answer your question? It's a make knob for boot code. Also, how does this relate to my observation that my system boots in IDE mode, but hangs in AHCI mode? No relation. I do not have any explanation for what you experience. I believe that FreeBSD code doesn't know anything about IDE vs AHCI and interacts with HDDs entirely through BIOS interfaces. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
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.
- D.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
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.
Could you please test this hypothesis by trying the following patch?
diff --git a/sys/boot/i386/common/drv.c b/sys/boot/i386/common/drv.c
index 11f6628..5996a80 100644
--- a/sys/boot/i386/common/drv.c
+++ b/sys/boot/i386/common/drv.c
@@ -37,10 +37,10 @@ __FBSDID($FreeBSD$);
uint64_t
drvsize(struct dsk *dskp)
{
- unsigned char params[0x42];
+ unsigned char params[0x4A];
uint64_t sectors;
- *(uint32_t *)params = sizeof(params);
+ *(uint16_t *)params = sizeof(params);
v86.ctl = V86_FLAGS;
v86.addr = 0x13;
P.S. the assembly diff to which I referred above:
--- drvsize.Os.S2011-10-23 20:17:56.871996966 +0300
+++ drvsize.O1.S2011-10-23 20:18:27.430995560 +0300
@@ -4,8 +4,8 @@
pushl %ebp
movl%esp, %ebp
subl$76, %esp
- leal-74(%ebp), %ecx
- movl$66, -74(%ebp)
+ leal-66(%ebp), %ecx
+ movl$66, -66(%ebp)
movl$262144, __v86
movl$19, __v86+4
movl$18432, __v86+24
@@ -28,20 +28,20 @@
pushl %eax
pushl $.LC4
callprintf
- xorl%eax, %eax
- xorl%edx, %edx
- popl%ecx
- popl%ecx
+ movl$0, %eax
+ movl$0, %edx
+ addl$8, %esp
jmp .L16
+ .p2align 2,,3
.L14:
pushl $8
- leal-58(%ebp), %eax
+ leal-50(%ebp), %eax
pushl %eax
- leal-8(%ebp), %eax
+ leal-76(%ebp), %eax
pushl %eax
callmemcpy
- movl-8(%ebp), %eax
- movl-4(%ebp), %edx
+ movl-76(%ebp), %eax
+ movl-72(%ebp), %edx
addl$12, %esp
.L16:
leave
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Sun, Oct 23, 2011 at 08:57:59PM +0300, Andriy Gapon wrote: I found a document that suggests a possibility of BIOS writing more bytes to the array than its current size of 0x42: [...] Could you please test this hypothesis by trying the following patch? With -O1 and this patch, it boots. Thank you! - D. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On 2011-10-23 21:56, Dennis Koegel wrote: On Sun, Oct 23, 2011 at 08:57:59PM +0300, Andriy Gapon wrote: I found a document that suggests a possibility of BIOS writing more bytes to the array than its current size of 0x42: [...] Could you please test this hypothesis by trying the following patch? With -O1 and this patch, it boots. Thank you! If you have some time, can you also re-check the other cases you listed before? E.g.: gcc -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time \ -mno-align-long-strings -mrtd [from before r225530]: gcc -Os -mrtd: gcc -O1 -mrtd: gcc -O1: gcc -O0: gcc -Os: clang -O1: clang -Os: clang -Oz: Thanks. :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Thu, Oct 20, 2011 at 11:28:08AM +0400, Pavel Timofeev wrote: I used FreeBSD 9 amd64 on my HP Proliant DL360 G5 (smart array p400i mirror) as test. [...] It was fresh install and I choose guided partitioning (GPT) But after reboot my server don't boot from hd. We have the same issue on a DL580 G7. Install runs fine, but when it's time for the first boot, the bootcode emits a single '-' (where usually it would be spinning for a moment while loading), hangs for about two seconds, and then reboots. I've used the BETA3 bsdinstall on other (amd64) hardware with GPT and it worked fine. Also, manually adding the GPT label, partitions and bootcode using gpart, then rebooting, shows the exact same behaviour (this was done using the BETA3 Live CD). I suspect it's something in the vicinity of pmbr bootcode vs. newer HP BIOS. (BTW, not related to this issue: hw.memtest.tests=0 should be default. The kernel on a system with 128 GB of RAM needs about two minutes (!) before emitting a single line of output. At first we didn't know about this test and thought there was a serious problem.) - D. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
2011/10/21 Dennis Koegel d...@neveragain.de On Thu, Oct 20, 2011 at 11:28:08AM +0400, Pavel Timofeev wrote: I used FreeBSD 9 amd64 on my HP Proliant DL360 G5 (smart array p400i mirror) as test. [...] It was fresh install and I choose guided partitioning (GPT) But after reboot my server don't boot from hd. We have the same issue on a DL580 G7. Install runs fine, but when it's time for the first boot, the bootcode emits a single '-' (where usually it would be spinning for a moment while loading), hangs for about two seconds, and then reboots. I've used the BETA3 bsdinstall on other (amd64) hardware with GPT and it worked fine. Also, manually adding the GPT label, partitions and bootcode using gpart, then rebooting, shows the exact same behaviour (this was done using the BETA3 Live CD). I suspect it's something in the vicinity of pmbr bootcode vs. newer HP BIOS. I don't know, but earlier snapshots, for example, ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201105/FreeBSD-9.0-CURRENT-201105-amd64-dvd1.iso doesn't have such problems. Does anybody have BETA-2 iso? (BTW, not related to this issue: hw.memtest.tests=0 should be default. The kernel on a system with 128 GB of RAM needs about two minutes (!) before emitting a single line of output. At first we didn't know about this test and thought there was a serious problem.) - D. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
2011/10/21 Dennis Koegel d...@neveragain.de On Thu, Oct 20, 2011 at 11:28:08AM +0400, Pavel Timofeev wrote: I used FreeBSD 9 amd64 on my HP Proliant DL360 G5 (smart array p400i mirror) as test. [...] It was fresh install and I choose guided partitioning (GPT) But after reboot my server don't boot from hd. We have the same issue on a DL580 G7. Install runs fine, but when it's time for the first boot, the bootcode emits a single '-' (where usually it would be spinning for a moment while loading), hangs for about two seconds, and then reboots. I've used the BETA3 bsdinstall on other (amd64) hardware with GPT and it worked fine. Also, manually adding the GPT label, partitions and bootcode using gpart, then rebooting, shows the exact same behaviour (this was done using the BETA3 Live CD). I suspect it's something in the vicinity of pmbr bootcode vs. newer HP BIOS. (BTW, not related to this issue: hw.memtest.tests=0 should be default. The kernel on a system with 128 GB of RAM needs about two minutes (!) before emitting a single line of output. At first we didn't know about this test and thought there was a serious problem.) My proliant have 1Gb RAM =) - D. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Fri, Oct 21, 2011 at 10:58:51AM +0200, Dennis Koegel wrote: On Thu, Oct 20, 2011 at 11:28:08AM +0400, Pavel Timofeev wrote: I used FreeBSD 9 amd64 on my HP Proliant DL360 G5 (smart array p400i mirror) as test. [...] It was fresh install and I choose guided partitioning (GPT) But after reboot my server don't boot from hd. We have the same issue on a DL580 G7. Install runs fine, but when it's time for the first boot, the bootcode emits a single '-' (where usually it would be spinning for a moment while loading), hangs for about two seconds, and then reboots. I've used the BETA3 bsdinstall on other (amd64) hardware with GPT and it worked fine. Also, manually adding the GPT label, partitions and bootcode using gpart, then rebooting, shows the exact same behaviour (this was done using the BETA3 Live CD). I suspect it's something in the vicinity of pmbr bootcode vs. newer HP BIOS. (BTW, not related to this issue: hw.memtest.tests=0 should be default. The kernel on a system with 128 GB of RAM needs about two minutes (!) before emitting a single line of output. At first we didn't know about this test and thought there was a serious problem.) Or at least there should be a message that the memtest is running... pgpY4GqxDI5oP.pgp Description: PGP signature
Re: Fresh installed Freebsd 9 don't boot from hd
On Oct 21, 2011, at 1:58 AM, Dennis Koegel wrote: On Thu, Oct 20, 2011 at 11:28:08AM +0400, Pavel Timofeev wrote: I used FreeBSD 9 amd64 on my HP Proliant DL360 G5 (smart array p400i mirror) as test. [...] It was fresh install and I choose guided partitioning (GPT) But after reboot my server don't boot from hd. We have the same issue on a DL580 G7. Install runs fine, but when it's time for the first boot, the bootcode emits a single '-' (where usually it would be spinning for a moment while loading), hangs for about two seconds, and then reboots. I'm seeing the same behavior on a Supermicro X8DT3 BIOS. The latest BIOS update changed the behavior from hanging forever to hanging for 2 seconds before rebooting. The problem occurs with BETA3 and RC1, but not with BETA2. Changing SATA mode from AHCI to IDE in the BIOS gets the OS to boot just fine. Cheers, Gunnar I've used the BETA3 bsdinstall on other (amd64) hardware with GPT and it worked fine. Also, manually adding the GPT label, partitions and bootcode using gpart, then rebooting, shows the exact same behaviour (this was done using the BETA3 Live CD). I suspect it's something in the vicinity of pmbr bootcode vs. newer HP BIOS. (BTW, not related to this issue: hw.memtest.tests=0 should be default. The kernel on a system with 128 GB of RAM needs about two minutes (!) before emitting a single line of output. At first we didn't know about this test and thought there was a serious problem.) - D. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Friday, October 21, 2011 4:58:51 am Dennis Koegel wrote: On Thu, Oct 20, 2011 at 11:28:08AM +0400, Pavel Timofeev wrote: I used FreeBSD 9 amd64 on my HP Proliant DL360 G5 (smart array p400i mirror) as test. [...] It was fresh install and I choose guided partitioning (GPT) But after reboot my server don't boot from hd. We have the same issue on a DL580 G7. Install runs fine, but when it's time for the first boot, the bootcode emits a single '-' (where usually it would be spinning for a moment while loading), hangs for about two seconds, and then reboots. 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. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
on 21/10/2011 23:33 John Baldwin said the following: On Friday, October 21, 2011 4:58:51 am Dennis Koegel wrote: On Thu, Oct 20, 2011 at 11:28:08AM +0400, Pavel Timofeev wrote: I used FreeBSD 9 amd64 on my HP Proliant DL360 G5 (smart array p400i mirror) as test. [...] It was fresh install and I choose guided partitioning (GPT) But after reboot my server don't boot from hd. We have the same issue on a DL580 G7. Install runs fine, but when it's time for the first boot, the bootcode emits a single '-' (where usually it would be spinning for a moment while loading), hangs for about two seconds, and then reboots. 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. Hmm, this is quite unexpected... Do you have a hypothesis why not using -mrtd could cause a problem (a miscompilation?) ? I previously assumed that -O1 is typically a quite safe optimization, not sure if it's even worth trying -O0 for a test. Or could this be about a size of gptboot blob? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
on 22/10/2011 00:27 Andriy Gapon said the following: on 21/10/2011 23:33 John Baldwin said the following: On Friday, October 21, 2011 4:58:51 am Dennis Koegel wrote: On Thu, Oct 20, 2011 at 11:28:08AM +0400, Pavel Timofeev wrote: I used FreeBSD 9 amd64 on my HP Proliant DL360 G5 (smart array p400i mirror) as test. [...] It was fresh install and I choose guided partitioning (GPT) But after reboot my server don't boot from hd. We have the same issue on a DL580 G7. Install runs fine, but when it's time for the first boot, the bootcode emits a single '-' (where usually it would be spinning for a moment while loading), hangs for about two seconds, and then reboots. 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. Hmm, this is quite unexpected... Do you have a hypothesis why not using -mrtd could cause a problem (a miscompilation?) ? I've just got one: maybe the trouble is caused by the sio_putc procedure in sys/boot/i386/btx/btx/btx.S. It seems to be the only place in the boot code where 'ret number' instruction is explicitly used. A litmus question: do those experiencing the trouble all have BTX_SERIAL defined? P.S. BTW, is BTX_SERIAL documented anywhere? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Oct 21, 2011, at 2:37 PM, Andriy Gapon wrote: on 22/10/2011 00:27 Andriy Gapon said the following: on 21/10/2011 23:33 John Baldwin said the following: On Friday, October 21, 2011 4:58:51 am Dennis Koegel wrote: On Thu, Oct 20, 2011 at 11:28:08AM +0400, Pavel Timofeev wrote: I used FreeBSD 9 amd64 on my HP Proliant DL360 G5 (smart array p400i mirror) as test. [...] It was fresh install and I choose guided partitioning (GPT) But after reboot my server don't boot from hd. We have the same issue on a DL580 G7. Install runs fine, but when it's time for the first boot, the bootcode emits a single '-' (where usually it would be spinning for a moment while loading), hangs for about two seconds, and then reboots. 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. Hmm, this is quite unexpected... Do you have a hypothesis why not using -mrtd could cause a problem (a miscompilation?) ? I've just got one: maybe the trouble is caused by the sio_putc procedure in sys/boot/i386/btx/btx/btx.S. It seems to be the only place in the boot code where 'ret number' instruction is explicitly used. A litmus question: do those experiencing the trouble all have BTX_SERIAL defined? Not sure where BTX_SERIAL would be defined, but I'm seeing the problem with the generic kernel. Does that answer your question? Also, how does this relate to my observation that my system boots in IDE mode, but hangs in AHCI mode? P.S. BTW, is BTX_SERIAL documented anywhere? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
