-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, after migrating some of our older servers to FeeBSD 8.3-stable (cvsupped May 4th), they don't boot anymore after installing the new boot blocks with gpart. These servers either boot in an endless loop or stop in BTX loader, due to different hardware environments. This behavior is restricted to 32-bit servers (i386), all 64-bit servers (amd64) work without any problem, as expected. After some analyzing, it seems to me that the actual size of gptboot does matter (16723 bytes, >16kB). In amd64 environment (same source version) the actual size of /boot/gptboot is only 15443 bytes. Since there is only one single Makefile for both architectures (/sys/boot/i386/gptboot/Makefile), some recent changes of CFLAGS seem to be responsible for this (Version 1.62 does work, Version 1.62.6.4 does not). Is there any advice available to solve this (compiler) problem, or is at last /sbin/gpart the culprit? - -- Kind regards Alfred Bartsch Data-Service GmbH mailto:bartsch@dssgmbh.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+qORIACgkQ5QGe2JdVf3jK9wCglOGPKHMuPfUr8YUU2N8Mw1++ NuIAoLQhibZk+PIHGc1/ql0nHkUx3qO2 =z29F -----END PGP SIGNATURE-----
on 09/05/2012 12:29 Alfred Bartsch said the following:> Hello, after migrating some of our older servers to FeeBSD 8.3-stable > (cvsupped May 4th), they don't boot anymore after installing the new boot > blocks with gpart. These servers either boot in an endless loop or stop in > BTX loader, due to different hardware environments. > > This behavior is restricted to 32-bit servers (i386), all 64-bit servers > (amd64) work without any problem, as expected. > > After some analyzing, it seems to me that the actual size of gptboot does > matter (16723 bytes, >16kB). In amd64 environment (same source version) the > actual size of /boot/gptboot is only 15443 bytes.Weird. Both amd64 and i386 builds should produce the same binaries as the boot code is built with -m32 -march=i386 on amd64. But I can reproduce this, so it seems that the compilation is indeed done differently. Heh, it seems that it is -march=i386 flag that makes all the difference. Maybe we should use this flag even when doing native i386 builds... Anyway, the pmbr code is supposed to read the whole content of a GPT boot partition into memory (actually limited to 545KB), so 16KB limit should not matter/exist. What size are your GPT boot partitions?> Since there is only one single Makefile for both architectures > (/sys/boot/i386/gptboot/Makefile), some recent changes of CFLAGS seem to be > responsible for this (Version 1.62 does work, Version 1.62.6.4 does not). > > Is there any advice available to solve this (compiler) problem, or is at > last /sbin/gpart the culprit?You can always try to locally revert the commit that changed the CFLAGS, but as I've said above there should not be any 16KB limit for GPT boot. Or you can try to add -march=i386 to CFLAGS for your i386 boot block build. -- Andriy Gapon
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 11.05.2012 08:42, schrieb Andriy Gapon:> on 10/05/2012 10:57 Alfred Bartsch said the following: >> Our i386 hardware is sufficiently old, and IMHO mainstream, e.g.: >> Intel SR1325 with Pentium-4 CPU, 2GB RAM Intel SR2200 with >> Pentium-III CPU(s), 2/4 GB RAM, Intel SR2300 with dual XEON, 4 GB >> RAM >> >> Even on my desktop (Intel MB DQ965CO, Intel Core2 CPU), this >> (wrong) behavior can be reproduced. dmesg output: > > There is also an interest in what board models and BIOS versions > you have there. >Here you are (partial output of kenv): 1. Intel SR1325: smbios.bios.reldate="01/26/2006" smbios.bios.vendor="Intel Corporation" smbios.bios.version="SE7210TP10.86B.P.10.00.0042.012620061107" smbios.chassis.maker="Intel Corporation" smbios.chassis.serial="ECKA4190241 " smbios.chassis.tag="0000000000 " smbios.chassis.version="SR1325TP1 " smbios.memory.enabled="2097152" smbios.planar.maker="Intel " smbios.planar.product="SE7210TP1-E " smbios.planar.serial="BZTP41xxxxxx " smbios.planar.version="FRU Ver 0.01 " smbios.socket.enabled="1" smbios.socket.populated="1" smbios.system.maker="Intel " smbios.system.product="SE7210TP1-E " smbios.system.serial="0000000000 " smbios.system.version="1.0 " smbios.version="2.3" 2. Intel SR2200: smbios.bios.reldate="02/04/2003" smbios.bios.vendor="Intel Corporation" smbios.bios.version="SCB20.86B.0077.P22.0302041652 " smbios.chassis.maker=" " smbios.chassis.serial=" " smbios.chassis.tag=" " smbios.chassis.version="SR2200 " smbios.memory.enabled="2097152" smbios.planar.maker="Intel " smbios.planar.product="SCB2S " smbios.planar.serial="KKC22020xxxx " smbios.planar.version="A46044-607 " smbios.socket.enabled="2" smbios.socket.populated="2" smbios.system.maker="Intel " smbios.system.product=" " smbios.system.serial=" " smbios.system.uuid="e42007cf-4106-d611-0080-xxxxxxxxxxxx" smbios.system.version=" " smbios.version="2.3" 3. Intel SR2300: smbios.bios.reldate="01/25/2005" smbios.bios.vendor="Intel Corporation" smbios.bios.version="SWV25.86B.0250.P39.0501252032 " smbios.chassis.maker="Intel Corporation " smbios.chassis.serial=" " smbios.chassis.tag=" " smbios.chassis.version=" " smbios.memory.enabled="4194304" smbios.planar.maker="Intel " smbios.planar.product="SE7501WV2S" smbios.planar.serial="000E0C66Exxxxxx" smbios.planar.version="A99386-112 " smbios.socket.enabled="2" smbios.socket.populated="2" smbios.system.maker="Intel " smbios.system.product=" " smbios.system.serial=" " smbios.system.uuid="6f48ea00-3d14-11d9-bf93-xxxxxxxxxxxx" smbios.system.version=" " smbios.version="2.3" 4. Desktop: smbios.bios.reldate="04/07/2008" smbios.bios.vendor="Intel Corp." smbios.bios.version="CO96510J.54T.0033.2008.0407.2320" smbios.memory.enabled="2097152" smbios.planar.maker="Intel Corporation" smbios.planar.product="DQ965CO" smbios.planar.serial="AZCO6xxxxxxG" smbios.planar.version="AAD46478-501" smbios.socket.enabled="1" smbios.socket.populated="1" smbios.system.maker="MAXDATA" smbios.system.uuid="fec14987-6d67-11db-a763-xxxxxxxxxxxx" smbios.system.version="5123660003" smbios.version="2.4" HTH - -- Alfred Bartsch Data-Service GmbH mailto:bartsch@dssgmbh.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+swjkACgkQ5QGe2JdVf3ip0gCfYP9pcBTjEhnchroKlFG87wco H+YAn3tUYcYd5nLLkizBDAUmZKuLMBpE =VXvj -----END PGP SIGNATURE-----
Konstantin Belousov
2012-May-11 08:09 UTC
i386 -march=xxx behavior [Was: FreeBSD 8 i386 gptboot corrupt - SOLVED]
On Fri, May 11, 2012 at 09:37:10AM +0300, Andriy Gapon wrote:> on 09/05/2012 15:09 Alfred Bartsch said the following: > > Am 09.05.2012 12:42, schrieb Andriy Gapon: > >> on 09/05/2012 12:29 Alfred Bartsch said the following: > >>> This behavior is restricted to 32-bit servers (i386), all 64-bit > >>> servers (amd64) work without any problem, as expected. > >>> > >>> After some analyzing, it seems to me that the actual size of gptboot > >>> does matter (16723 bytes, >16kB). In amd64 environment (same source > >>> version) the actual size of /boot/gptboot is only 15443 bytes. > > > >> Weird. Both amd64 and i386 builds should produce the same binaries as > >> the boot code is built with -m32 -march=i386 on amd64. But I can > >> reproduce this, so it seems that the compilation is indeed done > >> differently. > > > >> Heh, it seems that it is -march=i386 flag that makes all the difference. > >> Maybe we should use this flag even when doing native i386 builds... > > > > > > after adding "-march=i386" to CFLAGS in Makefile everything looks ok > > (filesize: 15443, as you predicted), so I would opt for using this flag in > > the future. > > Here is a small investigation into the -march flag. Not sure if it is of any > practical significance, I just was curious. > > First, seems that neither of i386/i486/i586/i686 values for this flag nor > absence of it implies features like MMX, SSE, and so on. (Saying this because > of some assumptions about i686) > > For the base GCC specifying -march with the above values is equivalent to > specifying -mtune with the same values, when mtune is not explicitly set. > Using "i686" or omitting the flag is equivalent to -mtune=generic. > > Note that this happens despite a FreeBSD-specific change to (base) GCC that > makes i486 a default arch. Derivation of the tune value from the arch value, > if any, or defaulting it otherwise is done earlier than defaulting of the arch > value. > Specifically I am talking about the block that deals with ix86_tune_string > that precedes the block for ix86_arch_string. > > So it seems that at the moment our sys/boot code is effectively compiled with > -mtune=generic for i386 target (amd64 target has an explicit -march=i386 - I > wonder why not i486). > > I think that in terms of instructions repertoire the difference is only in > availability of cmpxchg, cmpxchg8b, and xadd instructions (ignoring the > "system" instructions that should not be generated by a compiler from C code). > And I guess that the sys/boot code is simple enough to not require these > instructions? > Otherwise, mtune seems to affect layout of the generated code and preference > for some instructions over others. > > Again, not sure what conclusions can be made...-march=i686 also turns on use of cmov*. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120511/9f346ced/attachment.pgp
on 11/05/2012 11:09 Konstantin Belousov said the following:> On Fri, May 11, 2012 at 09:37:10AM +0300, Andriy Gapon wrote: >> on 09/05/2012 15:09 Alfred Bartsch said the following: >>> Am 09.05.2012 12:42, schrieb Andriy Gapon: >>>> on 09/05/2012 12:29 Alfred Bartsch said the following: >>>>> This behavior is restricted to 32-bit servers (i386), all 64-bit >>>>> servers (amd64) work without any problem, as expected. >>>>> >>>>> After some analyzing, it seems to me that the actual size of >>>>> gptboot does matter (16723 bytes, >16kB). In amd64 environment >>>>> (same source version) the actual size of /boot/gptboot is only >>>>> 15443 bytes. >>> >>>> Weird. Both amd64 and i386 builds should produce the same binaries >>>> as the boot code is built with -m32 -march=i386 on amd64. But I can >>>> reproduce this, so it seems that the compilation is indeed done >>>> differently. >>> >>>> Heh, it seems that it is -march=i386 flag that makes all the >>>> difference. Maybe we should use this flag even when doing native i386 >>>> builds... >>> >>> >>> after adding "-march=i386" to CFLAGS in Makefile everything looks ok >>> (filesize: 15443, as you predicted), so I would opt for using this flag >>> in the future. >> >> Here is a small investigation into the -march flag. Not sure if it is of >> any practical significance, I just was curious. >> >> First, seems that neither of i386/i486/i586/i686 values for this flag >> nor absence of it implies features like MMX, SSE, and so on. (Saying >> this because of some assumptions about i686) >> >> For the base GCC specifying -march with the above values is equivalent >> to specifying -mtune with the same values, when mtune is not explicitly >> set. Using "i686" or omitting the flag is equivalent to -mtune=generic. >> >> Note that this happens despite a FreeBSD-specific change to (base) GCC >> that makes i486 a default arch. Derivation of the tune value from the >> arch value, if any, or defaulting it otherwise is done earlier than >> defaulting of the arch value. Specifically I am talking about the block >> that deals with ix86_tune_string that precedes the block for >> ix86_arch_string. >> >> So it seems that at the moment our sys/boot code is effectively compiled >> with -mtune=generic for i386 target (amd64 target has an explicit >> -march=i386 - I wonder why not i486). >> >> I think that in terms of instructions repertoire the difference is only >> in availability of cmpxchg, cmpxchg8b, and xadd instructions (ignoring >> the "system" instructions that should not be generated by a compiler from >> C code). And I guess that the sys/boot code is simple enough to not >> require these instructions? Otherwise, mtune seems to affect layout of >> the generated code and preference for some instructions over others. >> >> Again, not sure what conclusions can be made... > > -march=i686 also turns on use of cmov*.So, this is the important thing that I missed. Then, it seems our default gcc behavior is -march=i486 -mtune=generic after all. -- Andriy Gapon