Hi. Possibly setting CPUTYPE in make.conf (or src.conf) can cause problem for loaders. I have below in make.conf. (amd64) .if !${.CURDIR:M/usr/src/sys/boot*} CPUTYPE?= corei7-avx .endif Additionally, for something above doesn't work: .if ${.CURDIR:M/usr/ports/games/rubix} CPUTYPE= core .endif .if ${.CURDIR:M/usr/ports/lang/gcc} CPUTYPE= core2 .endif Possibly lang/gcc can handle corei7-avx now, but not yet tested. On Sun, 04 Jun 2017 14:28:09 +0200 Alexander Leidinger <Alexander_at_leidinger.net> wrote: > Hi, > > I have a zfsloader which hangs directly after "Booting". First I > attributed it to maybe a bug in meta-mode/ccache + ino64 (easy > assumption without knowing if ino64 is involved in zfsloader), but > after ccache -C, removing /usr/obj and running 2x "make cleanworld" > and 2x "make clean" before a buildworld I now get some kind of a > loader-dump (BTX halted) message. The zfsloader binary from a > downloaded release-snapshot (r318945) after ino64 update doesn't > exhibit this issue. > > Has someone seen something similar? So far I assume this is something > with the compiler flags... > > I have the broken zfsloader (r319541) available at > http://www.leidinger.net/FreeBSD/zfsloader.nok > if someone wants to play around with it. > > Here the settings I used to compile it: > > dmesg: > FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on > LLVM 4.0.0) > CPU: Intel(R) Xeon(R) CPU L5630 _at_ 2.13GHz (2133.35-MHz > K8-class CPU) > > /etc/src-env.conf > WITH_META_MODE=yes > > /etc/src.conf > WITH_IDEA=yes > WITHOUT_PROFILE=yes > CFLAGS+=-DFTP_COMBINE_CWDS > MALLOC_PRODUCTION=yes > LOADER_FIREWIRE_SUPPORT=yes > #WITH_FAST_DEPEND=yes > KERNCONF=ANDROMEDA > > /etc/make.conf > CFLAGS+= -O2 -pipe #-mfpmath=sse -msse2 > COPTFLAGS= -O2 -pipe > CPUTYPE?=native > WITH_CCACHE_BUILD=yes > > Bye, > Alexander. > > -- > http://www.Leidinger.net Alexander_at_Leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org netchild_at_FreeBSD.org : PGP 0x8F31830F9F2772BF -- Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp>Received on Sun Jun 04 2017 - 10:51:58 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:11 UTC