10.1-BETA2 ZFS boot failure on sparc64
I downloaded the 10.1-BETA disc1 iso image for sparc64, and burned it to media. I then used that media to attempt an installation onto a spare sparc64 machine that I have. Using UFS as the filesystem, and more or less just following the prompts, the system got installed OK, and boots off of ZFS OK. I then reinstalled onto a system that I manually configured for ZFS. This installation fails to boot from the hard disk, dying like this: snip, snip ok reset Res LOM event: +487d+12h37m31s host reset etting ... ? Sun Fire V120 (UltraSPARC-IIe 648MHz), No Keyboard OpenBoot 4.0, 4096 MB memory installed, Serial #53476432. Ethernet address 0:3:ba:2f:fc:50, Host ID: 832ffc50. Boot device: disk0 File and args: FreeBSD/sparc64 ZFS boot block Boot path: /pci@1f,0/pci@1/scsi@8/disk@0,0:a Consoles: Open Firmware console Memory Address not Aligned ok snip, snip I have used my exact procedure in the past to install onto a ZFS only sparc without issue. Has anyone else tried booting a ZFS only sparc64 installation recently? -Kurt ___ 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: libthr and main thread stack size
On Mon, Sep 22, 2014 at 09:19:30AM -0400, Daniel Eischen wrote: On Sun, 21 Sep 2014, Julian Elischer wrote: On 9/20/14, 3:27 AM, John Baldwin wrote: On Tuesday, September 16, 2014 11:13:24 AM Konstantin Belousov wrote: On Mon, Sep 15, 2014 at 03:47:41PM -0600, Justin T. Gibbs wrote: On Aug 8, 2014, at 5:22 AM, Konstantin Belousov kostik...@gmail.com wrote: ? Below is the patch which adds environment variable LIBPTHREAD_BIGSTACK_MAIN. Setting it to any value results in the main thread stack left as is, and other threads allocate stack below the area of RLIMIT_STACK. Try it. I do not want to set this behaviour as default. Is there a reason this should not be the default? Looking at the getrlimit() page on the OpenGroup?s site they say: RLIMIT_STACK This is the maximum size of the initial thread's stack, in bytes. The implementation does not automatically grow the stack beyond this limit. If this limit is exceeded, SIGSEGV shall be generated for the thread. If the thread is blocking SIGSEGV, or the process is ignoring or catching SIGSEGV and has not made arrangements to use an alternate stack, the disposition of SIGSEGV shall be set to SIG_DFL before it is generated. Does posix say something different? I ran into this issue when debugging a segfault on Postgres when running an (arguably quite bogus) query that should have fit within both the configured stack rlimit and Postgres? configured stack limit. The Postgres backend is really just single threaded, but happens to pull in libpthread due to the threading support in some of the libraries it uses. The segfault definitely violates POLA. ? Justin I am conservative to not disturb the address space layout in single go. If enough people test this setting, I can consider flipping the default to the reverse. I am still curious why the things were done in this way, but nobody replied. I suspect it was done out of reasons of being overly conservative in interpreting RLIMIT_STACK. I think it is quite surprising behavior though and would rather we make your option the default and implement what the Open Group says above. that is my memory.. The transition from a non threaded app to a threaded app with one thread is sort of an undefined area. Feel free to change it if Dan agrees.. I'm all for adopting what POSIX specifies as the default. I would shy away from adding another knob (LIBPTHREAD_BIGSTACK_MAIN) if possible. In the patch, default behaviour is to provide RLIMIT_STACK sized stack for the main thread. The knobs are there to restore the old AS layout if my fears of the binary compatibility become real one day, and to keep the interface compat with the stable/10, which already got a knob merged. That said, below the patch with libthr.7 man page merged to libthr.3, and with the editing applied. diff --git a/lib/libthr/libthr.3 b/lib/libthr/libthr.3 index bfbebec..aa4572c 100644 --- a/lib/libthr/libthr.3 +++ b/lib/libthr/libthr.3 @@ -1,6 +1,11 @@ .\ Copyright (c) 2005 Robert N. M. Watson +.\ Copyright (c) 2014 The FreeBSD Foundation, Inc. .\ All rights reserved. .\ +.\ Part of this documentation was written by +.\ Konstantin Belousov k...@freebsd.org under sponsorship +.\ from the FreeBSD Foundation. +.\ .\ Redistribution and use in source and binary forms, with or without .\ modification, are permitted provided that the following conditions .\ are met: @@ -24,7 +29,7 @@ .\ .\ $FreeBSD$ .\ -.Dd October 19, 2007 +.Dd September 20, 2014 .Dt LIBTHR 3 .Os .Sh NAME @@ -45,8 +50,216 @@ has been optimized for use by applications expecting system scope thread semantics, and can provide significant performance improvements compared to .Lb libkse . +.Pp +The library is tightly integrated with the run-time link editor +.Xr ld-elf.so.1 1 +and +.Lb libc ; +all three components must be built from the same source tree. +Mixing +.Li libc +and +.Nm +libraries from different versions of +.Fx +is not supported. +The run-time linker +.Xr ld-elf.so.1 1 +has some code to ensure backward-compatibility with older versions of +.Nm . +.Pp +The man page documents the quirks and tunables of the +.Nm . +When linking with +.Li -lpthread , +the run-time dependency +.Li libthr.so.3 +is recorded in the produced object. +.Sh MUTEX ACQUISITION +A locked mutex (see +.Xr pthread_mutex_lock 3 ) +is represented by a volatile variable of type +.Dv lwpid_t , +which records the global system identifier of the thread +owning the lock. +.Nm +performs a contested mutex acquisition in three stages, each of which +is more resource-consuming than the previous. +.Pp +First, a spin loop +is performed, where the library attempts to acquire the lock by +.Xr atomic 9 +operations. +The loop count is controlled by the +.Ev LIBPTHREAD_SPINLOOPS +environment variable, with a default value of 2000. +.Pp +If the spin loop +was unable to acquire the mutex, a yeild loop +is executed,
Re: make installworld for i386 fails on Kyuafile
On Mon, Sep 22, 2014 at 11:15 AM, Thomas Mueller mueller6...@bellsouth.net wrote: I was successful on make buildworld and kernel, but make installworld failed on a missing file somewhere: /usr/share/man/man3/pmclog_read.3.gz - /usr/share/man/man3/pmclog.3.gz === lib/libproc (install) install -C -o root -g wheel -m 444 libproc.a /usr/lib install -C -o root -g wheel -m 444 libproc_p.a /usr/lib install -s -o root -g wheel -m 444 libproc.so.2 /usr/lib install -l s libproc.so.2 /usr/lib/libproc.so install -C -o root -g wheel -m 444 /BETA1/usr/src/lib/libproc/libproc.h /usr/include === lib/libproc/tests (install) install -o root -g wheel -m 444 Kyuafile.auto /usr/tests/lib/libproc/Kyuafile install: /usr/tests/lib/libproc/Kyuafile: No such file or directory Julio Merino responded: Fixed in r271950. Problem introduced in r271937 which seems to have missed part of the change sent out for review in D710. Thanks for the response! Now I know it wasn't some fault at my end. I updated again with svn from NetBSD, and was successful on (FreeBSD) i386. Next is to build/update for amd64. Tom ___ 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: libthr and main thread stack size
On 23 September 2014 13:24, Konstantin Belousov kostik...@gmail.com wrote:
In the patch, default behaviour is to provide RLIMIT_STACK sized stack
for the main thread. The knobs are there to restore the old AS layout
if my fears of the binary compatibility become real one day, and to
keep the interface compat with the stable/10, which already got a knob
merged.
That said, below the patch with libthr.7 man page merged to libthr.3,
and with the editing applied.
diff --git a/lib/libthr/libthr.3 b/lib/libthr/libthr.3
index bfbebec..aa4572c 100644
--- a/lib/libthr/libthr.3
+++ b/lib/libthr/libthr.3
@@ -1,6 +1,11 @@
.\ Copyright (c) 2005 Robert N. M. Watson
+.\ Copyright (c) 2014 The FreeBSD Foundation, Inc.
.\ All rights reserved.
.\
+.\ Part of this documentation was written by
+.\ Konstantin Belousov k...@freebsd.org under sponsorship
+.\ from the FreeBSD Foundation.
+.\
.\ Redistribution and use in source and binary forms, with or without
.\ modification, are permitted provided that the following conditions
.\ are met:
@@ -24,7 +29,7 @@
.\
.\ $FreeBSD$
.\
-.Dd October 19, 2007
+.Dd September 20, 2014
.Dt LIBTHR 3
.Os
.Sh NAME
@@ -45,8 +50,216 @@ has been optimized for use by applications expecting
system scope thread
semantics, and can provide significant performance improvements
compared to
.Lb libkse .
+.Pp
+The library is tightly integrated with the run-time link editor
+.Xr ld-elf.so.1 1
+and
+.Lb libc ;
+all three components must be built from the same source tree.
+Mixing
+.Li libc
+and
+.Nm
+libraries from different versions of
+.Fx
+is not supported.
+The run-time linker
+.Xr ld-elf.so.1 1
+has some code to ensure backward-compatibility with older versions of
+.Nm .
+.Pp
+The man page documents the quirks and tunables of the
+.Nm .
+When linking with
+.Li -lpthread ,
+the run-time dependency
+.Li libthr.so.3
+is recorded in the produced object.
+.Sh MUTEX ACQUISITION
+A locked mutex (see
+.Xr pthread_mutex_lock 3 )
+is represented by a volatile variable of type
+.Dv lwpid_t ,
+which records the global system identifier of the thread
+owning the lock.
+.Nm
+performs a contested mutex acquisition in three stages, each of which
+is more resource-consuming than the previous.
+.Pp
+First, a spin loop
+is performed, where the library attempts to acquire the lock by
+.Xr atomic 9
+operations.
+The loop count is controlled by the
+.Ev LIBPTHREAD_SPINLOOPS
+environment variable, with a default value of 2000.
+.Pp
+If the spin loop
+was unable to acquire the mutex, a yeild loop
typo: yield
[...]
.Sh SEE ALSO
-.Xr pthread 3
+.Xr ktrace 1 ,
+.Xr ld-elf.so.1 1 ,
+.Xr getrlimit 2 ,
+.Xr umtx 2 ,
+.Xr dlclose 3 ,
+.Xr dlopen 3 ,
+.Xr errno 3 ,
+.Xr getenv 3 ,
+.Xr libc 3 ,
+.Xr pthread_attr 3 ,
+.Xr pthread_attr_setstacksize 3 ,
+.Xr pthread_create 3 ,
+.Xr signal 3 ,
+.Xr atomic 9 .
no pediod there per mdoc
.Sh AUTHORS
.An -nosplit
The
diff --git a/lib/libthr/thread/thr_init.c b/lib/libthr/thread/thr_init.c
index 9bf0e29..72a067a 100644
--- a/lib/libthr/thread/thr_init.c
+++ b/lib/libthr/thread/thr_init.c
@@ -445,7 +445,7 @@ init_private(void)
struct rlimit rlim;
size_t len;
int mib[2];
- char *env;
+ char *env, *env_bigstack, *env_splitstack;
_thr_umutex_init(_mutex_static_lock);
_thr_umutex_init(_cond_static_lock);
@@ -473,8 +473,9 @@ init_private(void)
len = sizeof (_usrstack);
if (sysctl(mib, 2, _usrstack, len, NULL, 0) == -1)
PANIC(Cannot get kern.usrstack from sysctl);
- env = getenv(LIBPTHREAD_BIGSTACK_MAIN);
- if (env != NULL) {
+ env_bigstack = getenv(LIBPTHREAD_BIGSTACK_MAIN);
+ env_splitstack = getenv(LIBPTHREAD_SPLITSTACK_MAIN);
+ if (bigstack != NULL || env_splitstack == NULL) {
looks like a typo: s/bigstack/env_bigstack/
if (getrlimit(RLIMIT_STACK, rlim) == -1)
PANIC(Cannot get stack rlimit);
_thr_stack_initial = rlim.rlim_cur;
--
wbr,
pluknet
___
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: libthr and main thread stack size
On Tue, Sep 23, 2014 at 02:02:01PM +0400, Sergey Kandaurov wrote:
+ env_bigstack = getenv(LIBPTHREAD_BIGSTACK_MAIN);
+ env_splitstack = getenv(LIBPTHREAD_SPLITSTACK_MAIN);
+ if (bigstack != NULL || env_splitstack == NULL) {
looks like a typo: s/bigstack/env_bigstack/
Indeed, thank you for noting. This patch actually booted, and I verified
all 5 conditions.
diff --git a/lib/libthr/libthr.3 b/lib/libthr/libthr.3
index bfbebec..a5b75d4 100644
--- a/lib/libthr/libthr.3
+++ b/lib/libthr/libthr.3
@@ -1,6 +1,11 @@
.\ Copyright (c) 2005 Robert N. M. Watson
+.\ Copyright (c) 2014 The FreeBSD Foundation, Inc.
.\ All rights reserved.
.\
+.\ Part of this documentation was written by
+.\ Konstantin Belousov k...@freebsd.org under sponsorship
+.\ from the FreeBSD Foundation.
+.\
.\ Redistribution and use in source and binary forms, with or without
.\ modification, are permitted provided that the following conditions
.\ are met:
@@ -24,7 +29,7 @@
.\
.\ $FreeBSD$
.\
-.Dd October 19, 2007
+.Dd September 20, 2014
.Dt LIBTHR 3
.Os
.Sh NAME
@@ -45,8 +50,216 @@ has been optimized for use by applications expecting system
scope thread
semantics, and can provide significant performance improvements
compared to
.Lb libkse .
+.Pp
+The library is tightly integrated with the run-time link editor
+.Xr ld-elf.so.1 1
+and
+.Lb libc ;
+all three components must be built from the same source tree.
+Mixing
+.Li libc
+and
+.Nm
+libraries from different versions of
+.Fx
+is not supported.
+The run-time linker
+.Xr ld-elf.so.1 1
+has some code to ensure backward-compatibility with older versions of
+.Nm .
+.Pp
+The man page documents the quirks and tunables of the
+.Nm .
+When linking with
+.Li -lpthread ,
+the run-time dependency
+.Li libthr.so.3
+is recorded in the produced object.
+.Sh MUTEX ACQUISITION
+A locked mutex (see
+.Xr pthread_mutex_lock 3 )
+is represented by a volatile variable of type
+.Dv lwpid_t ,
+which records the global system identifier of the thread
+owning the lock.
+.Nm
+performs a contested mutex acquisition in three stages, each of which
+is more resource-consuming than the previous.
+.Pp
+First, a spin loop
+is performed, where the library attempts to acquire the lock by
+.Xr atomic 9
+operations.
+The loop count is controlled by the
+.Ev LIBPTHREAD_SPINLOOPS
+environment variable, with a default value of 2000.
+.Pp
+If the spin loop
+was unable to acquire the mutex, a yield loop
+is executed, performing the same
+.Xr atomic 9
+acquisition attempts as the spin loop,
+but each attempt is followed by a yield of the CPU time
+of the thread using the
+.Xr sched_yield 2
+syscall.
+By default, the yield loop
+is not executed.
+This is controlled by the
+.Ev LIBPTHREAD_YIELDLOOPS
+environment variable.
+.Pp
+If both the spin and yield loops
+failed to acquire the lock, the thread is taken off the CPU and
+put to sleep in the kernel with the
+.Xr umtx 2
+syscall.
+The kernel wakes up a thread and hands the ownership of the lock to
+the woken thread when the lock becomes available.
+.Sh THREAD STACKS
+Each thread is provided with a private user-mode stack area
+used by the C runtime.
+The size of the main (initial) thread stack is set by the kernel, and is
+controlled by the
+.Dv RLIMIT_STACK
+process resource limit (see
+.Xr getrlimit 2 ) .
+.Pp
+By default, the main thread's stack size is equal to the value of
+.Dv RLIMIT_STACK
+for the process.
+If the
+.Ev LIBPTHREAD_SPLITSTACK_MAIN
+environment variable is present in the process environment
+(its value does not matter),
+the main thread's stack is reduced to 4MB on 64bit architectures, and to
+2MB on 32bit architectures, when the threading library is initialized.
+The rest of the address space area which has been reserved by the
+kernel for the initial process stack is used for non-initial thread stacks
+in this case.
+The presence of the
+.Ev LIBPTHREAD_BIGSTACK_MAIN
+environment variable overrides
+.Ev LIBPTHREAD_SPLITSTACK_MAIN ;
+it is kept for backward-compatibility.
+.Pp
+The size of stacks for threads created by the process at run-time
+with the
+.Xr pthread_create 3
+call is controlled by thread attributes: see
+.Xr pthread_attr 3 ,
+in particular, the
+.Xr pthread_attr_setstacksize 3 ,
+.Xr pthread_attr_setguardsize 3
+and
+.Xr pthread_attr_setstackaddr 3
+functions.
+If no attributes for the thread stack size are specified, the default
+non-initial thread stack size is 2MB for 64bit architectures, and 1MB
+for 32bit architectures.
+.Sh RUN-TIME SETTINGS
+The following environment variables are recognized by
+.Nm
+and adjust the operation of the library at run-time:
+.Bl -tag -width LIBPTHREAD_SPLITSTACK_MAIN
+.It Ev LIBPTHREAD_BIGSTACK_MAIN
+Disables the reduction of the initial thread stack enabled by
+.Ev LIBPTHREAD_SPLITSTACK_MAIN .
+.It Ev LIBPTHREAD_SPLITSTACK_MAIN
+Causes a reduction of the initial thread stack, as described in the
+section
+.Sx THREAD STACKS .
+This was the default
/boot/loader.efi and buildkernel
Modules and kernel are built when running make buildkernel, but the other contents of /boot/ aren't. How can I manually - and separately - build the loader, especially /boot/loader.efi? I realized that building loader.efi with any kind of optimization beyond debugging- or close-to-debugging level ends up in an unloadable loader.efi on Haswell CPUs (IvyBridge and C2D seem to be unaffected). The system in question is the most recent CURRENT, compiled with system's CLANG 3.4.1. Regards, Oliver signature.asc Description: PGP signature
Re: CURRENT: EFI boot failure
Bezüglich O. Hartmann's Nachricht vom 19.09.2014 15:22 (localtime):
…
The problem I reported about in the first place is triggered by a faulty
loader.efi that
arises, when optimisation level is -O3. -O2 works fine.
I can confirm that this problem also shows up when using
'CPUTYPE?=core-avx2'
Setting CPUTYPE to core-avx-i doesnt ehibit the problem.
I could narrow down the cause to libefi.a (sys/boot/efi).
But I don't understand the things going on there, so no clue how to fix
besides maybe
--- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.0 +0200
+++ sys/boot/efi/Makefile.inc 2014-09-23 16:25:16.0 +0200
@@ -2,6 +2,10 @@
BINDIR?= /boot
+.ifdef CPUTYPE
+.undef CPUTYPE
+.endif
+
.if ${MACHINE_CPUARCH} == i386
CFLAGS+= -march=i386
.endif
-Harry
signature.asc
Description: OpenPGP digital signature
Re: CURRENT: EFI boot failure
Bezüglich Harald Schmalzbauer's Nachricht vom 23.09.2014 16:28
(localtime):
Bezüglich O. Hartmann's Nachricht vom 19.09.2014 15:22 (localtime):
…
The problem I reported about in the first place is triggered by a faulty
loader.efi that
arises, when optimisation level is -O3. -O2 works fine.
I can confirm that this problem also shows up when using
'CPUTYPE?=core-avx2'
Setting CPUTYPE to core-avx-i doesnt ehibit the problem.
I could narrow down the cause to libefi.a (sys/boot/efi).
But I don't understand the things going on there, so no clue how to fix
besides maybe
--- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.0 +0200
+++ sys/boot/efi/Makefile.inc 2014-09-23 16:25:16.0 +0200
@@ -2,6 +2,10 @@
BINDIR?= /boot
+.ifdef CPUTYPE
+.undef CPUTYPE
+.endif
Sorry, forget the suggestion, it doesn't work since it leads to CFLAG
-march= and the same problem occurs.
For my case this works:
--- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.0 +0200
+++ sys/boot/efi/Makefile.inc 2014-09-23 16:46:30.0 +0200
@@ -2,6 +2,10 @@
BINDIR?= /boot
+.if ${CPUTYPE} == core-avx2
+CPUTYPE= core-avx-i
+.endif
+
.if ${MACHINE_CPUARCH} == i386
CFLAGS+=-march=i386
.endif
JFI
-Harry
signature.asc
Description: OpenPGP digital signature
Re: 10.1-BETA2 ZFS boot failure on sparc64
On 2014-09-23 02:13, Kurt Lidl wrote: I downloaded the 10.1-BETA disc1 iso image for sparc64, and burned it to media. I then used that media to attempt an installation onto a spare sparc64 machine that I have. Using UFS as the filesystem, and more or less just following the prompts, the system got installed OK, and boots off of ZFS OK. I then reinstalled onto a system that I manually configured for ZFS. This installation fails to boot from the hard disk, dying like this: snip, snip ok reset Res LOM event: +487d+12h37m31s host reset etting ... ? Sun Fire V120 (UltraSPARC-IIe 648MHz), No Keyboard OpenBoot 4.0, 4096 MB memory installed, Serial #53476432. Ethernet address 0:3:ba:2f:fc:50, Host ID: 832ffc50. Boot device: disk0 File and args: FreeBSD/sparc64 ZFS boot block Boot path: /pci@1f,0/pci@1/scsi@8/disk@0,0:a Consoles: Open Firmware console Memory Address not Aligned ok snip, snip I have used my exact procedure in the past to install onto a ZFS only sparc without issue. Has anyone else tried booting a ZFS only sparc64 installation recently? -Kurt ___ 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 If you have the entire drive to spare, have you tried the 'ZFS auto mode' script that Devin and I wrote? It is the bottom option in the installer partitioning menu. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: CURRENT: EFI boot failure
Could you try adding -mno-avx2 to /sys/boot/amd64/Makefile.inc line 9?
-Nathan
On 09/23/14 07:28, Harald Schmalzbauer wrote:
Bezüglich O. Hartmann's Nachricht vom 19.09.2014 15:22 (localtime):
…
The problem I reported about in the first place is triggered by a faulty
loader.efi that
arises, when optimisation level is -O3. -O2 works fine.
I can confirm that this problem also shows up when using
'CPUTYPE?=core-avx2'
Setting CPUTYPE to core-avx-i doesnt ehibit the problem.
I could narrow down the cause to libefi.a (sys/boot/efi).
But I don't understand the things going on there, so no clue how to fix
besides maybe
--- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.0 +0200
+++ sys/boot/efi/Makefile.inc 2014-09-23 16:25:16.0 +0200
@@ -2,6 +2,10 @@
BINDIR?= /boot
+.ifdef CPUTYPE
+.undef CPUTYPE
+.endif
+
.if ${MACHINE_CPUARCH} == i386
CFLAGS+= -march=i386
.endif
-Harry
___
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: /boot/loader.efi and buildkernel
Bezüglich O. Hartmann's Nachricht vom 23.09.2014 14:16 (localtime): Modules and kernel are built when running make buildkernel, but the other contents of /boot/ aren't. How can I manually - and separately - build the loader, especially /boot/loader.efi? Simply cd to src/sys/boot and do 'make clean make make DESTDIR=/altroot', the latter only if you don't want to overwrite curdev's /boot/ files. For loader.efi only, it's enough to do 'make clean make' in the following directories: src/sys/boot/ficl src/sys/boot/efi src/sys/boot/amd64/efi From amd64/efi you can 'make install' to just copy loader.efi (or copy manually from obj/$src/sys/boot/amd64/efi/loader.efi) I realized that building loader.efi with any kind of optimization beyond debugging- or close-to-debugging level ends up in an unloadable loader.efi on Haswell CPUs (IvyBridge and C2D seem to be unaffected). The system in question is the most recent CURRENT, compiled with system's CLANG 3.4.1. This is confirmed for CPUTYPE=core-avx2, see my recent post. My test machine was haswell as well, but I haven't tested on anything else! -Harry signature.asc Description: OpenPGP digital signature
Re: 10.1-BETA2 ZFS boot failure on sparc64
On 09/23/14 08:04, Allan Jude wrote: On 2014-09-23 02:13, Kurt Lidl wrote: I downloaded the 10.1-BETA disc1 iso image for sparc64, and burned it to media. I then used that media to attempt an installation onto a spare sparc64 machine that I have. Using UFS as the filesystem, and more or less just following the prompts, the system got installed OK, and boots off of ZFS OK. I then reinstalled onto a system that I manually configured for ZFS. This installation fails to boot from the hard disk, dying like this: snip, snip ok reset Res LOM event: +487d+12h37m31s host reset etting ... ? Sun Fire V120 (UltraSPARC-IIe 648MHz), No Keyboard OpenBoot 4.0, 4096 MB memory installed, Serial #53476432. Ethernet address 0:3:ba:2f:fc:50, Host ID: 832ffc50. Boot device: disk0 File and args: FreeBSD/sparc64 ZFS boot block Boot path: /pci@1f,0/pci@1/scsi@8/disk@0,0:a Consoles: Open Firmware console Memory Address not Aligned ok snip, snip I have used my exact procedure in the past to install onto a ZFS only sparc without issue. Has anyone else tried booting a ZFS only sparc64 installation recently? -Kurt ___ 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 If you have the entire drive to spare, have you tried the 'ZFS auto mode' script that Devin and I wrote? It is the bottom option in the installer partitioning menu. Allan, that script doesn't work on sparc since it doesn't know about VTOC8 and can only install to GPT and MBR. As committed, the menu item is also disabled on anything other than i386 and amd64. The partition editor in -CURRENT likely works, since it is based on code Kurt submitted, but is untested on sparc since his original patch. I think the more likely issue is that the boot blocks have bitrotted somehow on SPARC. That's certainly consistent with the Memory Address not Aligned error. -Nathan ___ 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: CURRENT: EFI boot failure
On 23 Sep 2014, at 17:00, Nathan Whitehorn nwhiteh...@freebsd.org wrote:
On 09/23/14 07:28, Harald Schmalzbauer wrote:
Bezüglich O. Hartmann's Nachricht vom 19.09.2014 15:22 (localtime):
…
The problem I reported about in the first place is triggered by a faulty
loader.efi that
arises, when optimisation level is -O3. -O2 works fine.
I can confirm that this problem also shows up when using
'CPUTYPE?=core-avx2'
Setting CPUTYPE to core-avx-i doesnt ehibit the problem.
I could narrow down the cause to libefi.a (sys/boot/efi).
But I don't understand the things going on there, so no clue how to fix
besides maybe
--- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.0 +0200
+++ sys/boot/efi/Makefile.inc 2014-09-23 16:25:16.0 +0200
@@ -2,6 +2,10 @@
BINDIR?= /boot
+.ifdef CPUTYPE
+.undef CPUTYPE
+.endif
+
.if ${MACHINE_CPUARCH} == i386
CFLAGS+= -march=i386
.endif
Could you try adding -mno-avx2 to /sys/boot/amd64/Makefile.inc line 9?
-Nathan
IMHO CPUTYPE should be ignored for any boot loader program, and the
lowest common denominator should be used instead (i486 for 32-bit, plain
x86_64 for 64-bit). It makes no sense to optimize boot loaders for e.g.
core-avx2. :-)
But indeed, it appears that we need to add more -mno-foo magic flags...
-Dimitry
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: CURRENT: EFI boot failure
Bezüglich Nathan Whitehorn's Nachricht vom 23.09.2014 17:00 (localtime): Could you try adding -mno-avx2 to /sys/boot/amd64/Makefile.inc line 9? Done so, but it doesn't fix the problem with halting loader.efi when compiled with CPUTYPE=core-avx2. The whole -mno-xyz isn't applied to sys/boot/efi/libefi: cc -O2 -pipe -march=core-avx2 -fPIC -I/usr/src/sys/boot/efi/libefi/../include -I/usr/src/sys/boot/efi/libefi/../include/amd64 -I/usr/src/sys/boot/efi/libefi/../../../../lib/libstand -I/usr/src/sys/boot/efi/libefi/../../common -DNO_PCI -fformat-extensions -ffreestanding -fshort-wchar -Wformat -std=gnu99-Qunused-arguments -c delay.c -o delay.o Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: 10.1-BETA2 ZFS boot failure on sparc64
On 2014-09-23 11:09, Nathan Whitehorn wrote: On 09/23/14 08:04, Allan Jude wrote: On 2014-09-23 02:13, Kurt Lidl wrote: I downloaded the 10.1-BETA disc1 iso image for sparc64, and burned it to media. I then used that media to attempt an installation onto a spare sparc64 machine that I have. Using UFS as the filesystem, and more or less just following the prompts, the system got installed OK, and boots off of ZFS OK. I then reinstalled onto a system that I manually configured for ZFS. This installation fails to boot from the hard disk, dying like this: snip, snip ok reset Res LOM event: +487d+12h37m31s host reset etting ... ? Sun Fire V120 (UltraSPARC-IIe 648MHz), No Keyboard OpenBoot 4.0, 4096 MB memory installed, Serial #53476432. Ethernet address 0:3:ba:2f:fc:50, Host ID: 832ffc50. Boot device: disk0 File and args: FreeBSD/sparc64 ZFS boot block Boot path: /pci@1f,0/pci@1/scsi@8/disk@0,0:a Consoles: Open Firmware console Memory Address not Aligned ok snip, snip I have used my exact procedure in the past to install onto a ZFS only sparc without issue. Has anyone else tried booting a ZFS only sparc64 installation recently? -Kurt ___ 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 If you have the entire drive to spare, have you tried the 'ZFS auto mode' script that Devin and I wrote? It is the bottom option in the installer partitioning menu. Allan, that script doesn't work on sparc since it doesn't know about VTOC8 and can only install to GPT and MBR. As committed, the menu item is also disabled on anything other than i386 and amd64. The partition editor in -CURRENT likely works, since it is based on code Kurt submitted, but is untested on sparc since his original patch. I think the more likely issue is that the boot blocks have bitrotted somehow on SPARC. That's certainly consistent with the Memory Address not Aligned error. -Nathan ___ 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 Ahh yes, I remember consider supporting sparc64, but with no one to test, and what I can only imagine is a small userbase, of hardcore people who would rather do it manually, we decided against it. -- Allan Jude signature.asc Description: OpenPGP digital signature
Poor state of the build infrastructure.
Things have regressed from last I tried (which is a while). After a clean buildworld for PowerPC I can't install it: # make installworld TARGET_ARCH=powerpc TARGET=powerpc __MAKE_CONF=/dev/null DESTDIR=/tank/scratch/powerpc mkdir -p /tmp/install.pjtGQ4J8 : make[2]: /tank/scratch/marcelm/head/share/mk/bsd.compiler.mk line 37: Unable to determine compiler type for cc. Consider setting COMPILER_TYPE. *** Error code 1 And look at share/mk/bsd.compiler.mk. Its comments with typos doesn't even fit 80 character. While technically speaking, not a problem, it does leave the impression of low quality. This has the unfortunate side-effect of deepening the low quality perception caused by not being able to do an installworld in the first place. So, ok. I add COMPILER_TYPE=fuckthat to the command line and guess what: # make installworld TARGET_ARCH=powerpc TARGET=powerpc __MAKE_CONF=/dev/null DESTDIR=/tank/scratch/powerpc COMPILER_TYPE=fuckthat mkdir -p /tmp/install.pFqalBOs : Making hierarchy : Installing everything : === lib/csu/powerpc (install) install -o root -g wheel -m 444 crt1.o crti.o crtn.o Scrt1.o gcrt1.o /tank/scratch/powerpc/usr/lib install: crt1.o: No such file or directory *** Error code 71 What??? Ok, let's check if things were build properly: % make buildenv __MAKE_CONF=/dev/null TARGET=powerpc TARGET_ARCH=powerpc $ cd lib/csu/powerpc $ make : cc -O2 -pipe ... -c crti.S crti.S:34:13: error: unexpected token in memory operand stwu 1,-16(1) ^ crti.S:35:2: error: invalid instruction mnemonic 'mflr' mflr 0 ^~~~ crti.S:36:12: error: unexpected token in memory operand stw 31,12(1) ^ crti.S:37:11: error: unexpected token in memory operand stw 0,20(1) ^ crti.S:38:2: error: invalid instruction mnemonic 'mr' mr 31,1 ^~ crti.S:45:13: error: unexpected token in memory operand stwu 1,-16(1) ^ crti.S:46:2: error: invalid instruction mnemonic 'mflr' mflr 0 ^~~~ crti.S:47:12: error: unexpected token in memory operand stw 31,12(1) ^ crti.S:48:11: error: unexpected token in memory operand stw 0,20(1) ^ crti.S:49:2: error: invalid instruction mnemonic 'mr' mr 31,1 ^~ *** Error code 1 Grrr... $ which cc /usr/bin/cc $ cc -v FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: x86_64-unknown-freebsd10.1 Thread model: posix Selected GCC installation: So, now even the very questionable but fundamentally non-broken make buildenv isn't working anymore. How is anyone going to develop for anything but the host this way. Granted we seriously sucked in this regard to begin with but we seem to have regressed to the point of having absolutely no working support whatsoever. What is going on here? Are we still in some kind of flux and people aren't done yet or is this the intended state by virtue of noone having anything left on there TODO list? -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
