Re: kevent has bug?
Kohji Okuno wrote this message on Wed, Apr 02, 2014 at 11:45 +0900:
I think, kevent() has a bug.
I tested sample programs by attached sources.
This sample tests about EVFILT_SIGNAL.
I build sample programs by the following commands.
% gcc -O2 -o child child.c
% gcc -O2 -o parent parent.c
The expected result is the following.
% ./parent
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
OK
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
OK
But, sometimes the result was the following.
% ./parent
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
This result means the number of times the signal has occured was
incorrect.
I was able to reproduce this...
In case of EVFILT_SIGNAL, according to `man kevent', `data' retuns the
number of times the signal has occurred since the last call to
kevent(). This `data' is recorded by filt_signal() (This is f_event in
struct filterops).
The system call kevent()'s events are processed by kqueue_scan() in
kern_event.c. In kqueue_scan(), kn-kn_fop-f_event() is allways
called after KN_INFLUX is set to kn-kn_status.
On the other hand, kernel events are occured by knote() in
kern_event.c. (In EVFILT_SIGNAL, knote() is called from tdsendsignal()
in kern_sig.c.) In knote(), kn-kn_fop-f_event() is called only when
KN_INFLUX is not set in kn-kn_status.
In race condition between kqueue_scan() and knote(),
kn-kn_fop-f_event() from knote() may not be called, I think.
Considering that both are called w/ a lock, that cannot happen..
KN_LIST_LOCK(kn) locks the same lock that is asserted that is held
by knote...
In knote(), because the context holds knlist's lock, the context can
not sleep. So, KN_INFLUX should not be set on calling
kn-kn_fop-f_event() in kqueue_scan(), I think.
No, it needs to be set:
* Setting the KN_INFLUX flag enables you to unlock the kq that this knote
* is on, and modify kn_status as if you had the KQ lock.
As this comment says, _INFLUX allows you to unlock the KQ w/o fear that
the knote will disappear out from under you causing you to dereference
possibly free'd memory..
If you just tried to lock the list lock w/o unlocking the KQ lock, you
could end up w/ a dead lock, as you aren't maintaining lock order
properly.. The correct lock order if knlist - kq...
What do you think about this issue?
This is a real issue, but not due to the race you described
above...
I have verified on my machine that it isn't because there is a knote
waiting that isn't getting woken up, and the knote on my hung process
has data == 0, so it definately lost one of the signals:
(kgdb) print $14.kq_knhash[20].slh_first[0]
$20 = {kn_link = {sle_next = 0x0}, kn_selnext = {sle_next = 0x0},
kn_knlist = 0xf8005a9c5840, kn_tqe = {tqe_next = 0xf801fdab4500,
tqe_prev = 0xf8004bb10038}, kn_kq = 0xf8004bb1, kn_kevent = {
ident = 20, filter = -6, flags = 32, fflags = 0, data = 0, udata = 0x0},
kn_status = 0, kn_sfflags = 0, kn_sdata = 0, kn_ptr = {
p_fp = 0xf8005a9c54b8, p_proc = 0xf8005a9c54b8,
p_aio = 0xf8005a9c54b8, p_lio = 0xf8005a9c54b8,
p_v = 0xf8005a9c54b8}, kn_fop = 0x81405ef0, kn_hook = 0x0,
kn_hookid = 0}
If you want to find this yourself, you can run kgdb on a live system,
switch to the thread of the parent (info threads, thread XXX), and
do:
frame 7
(or a frame that has td, which is struct thread *), then:
print *(struct kqueue *)td-td_proc[0].p_fd[0].fd_ofiles[3].fde_file[0].f_data
This will give you the struct kqueue * of the parent, and then:
print $XX.kq_knhash[0]@63
to figure out where the knote is in the hash, and then you can print
it out yourself...
I'm going to take a look at this a bit more later... I'm thinking of
using dtrace to collect the stacks where filt_signal is called, and
match them up... dtrace might even be able to get us the note's data
upon return helping to make sure things got tracked properly...
Thanks for finding this bug! Hopefully we can find a solution to it..
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
___
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: ZFS panic in -CURRENT
on 01/04/2014 16:57 R. Tyler Croy said the following: On Tue, 01 Apr 2014 09:41:45 +0300 Andriy Gapon a...@freebsd.org wrote: on 01/04/2014 02:22 R. Tyler Croy said the following: ... Also in addition to the photo from before of the panic, here's another reproduction photo: https://www.flickr.com/photos/agentdero/13472248423/ Are you or have you even been running with any ZFS-related kernel patches? Negative, I've never run any specific ZFS patches on this machine (or any machine for that matter!) One other unique clue might be that I'm running with an encrypted zpool, other than that, nothing fancy here. Your problem looks like a corruption of on-disk data. I can not say how it came to be or how to fix it now. -- 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: kevent has bug?
From: John-Mark Gurney j...@funkthat.com
Date: Tue, 1 Apr 2014 23:15:51 -0700
Kohji Okuno wrote this message on Wed, Apr 02, 2014 at 11:45 +0900:
I think, kevent() has a bug.
I tested sample programs by attached sources.
This sample tests about EVFILT_SIGNAL.
I build sample programs by the following commands.
% gcc -O2 -o child child.c
% gcc -O2 -o parent parent.c
The expected result is the following.
% ./parent
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
OK
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
OK
But, sometimes the result was the following.
% ./parent
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
This result means the number of times the signal has occured was
incorrect.
I was able to reproduce this...
In case of EVFILT_SIGNAL, according to `man kevent', `data' retuns the
number of times the signal has occurred since the last call to
kevent(). This `data' is recorded by filt_signal() (This is f_event in
struct filterops).
The system call kevent()'s events are processed by kqueue_scan() in
kern_event.c. In kqueue_scan(), kn-kn_fop-f_event() is allways
called after KN_INFLUX is set to kn-kn_status.
On the other hand, kernel events are occured by knote() in
kern_event.c. (In EVFILT_SIGNAL, knote() is called from tdsendsignal()
in kern_sig.c.) In knote(), kn-kn_fop-f_event() is called only when
KN_INFLUX is not set in kn-kn_status.
In race condition between kqueue_scan() and knote(),
kn-kn_fop-f_event() from knote() may not be called, I think.
Considering that both are called w/ a lock, that cannot happen..
KN_LIST_LOCK(kn) locks the same lock that is asserted that is held
by knote...
In knote(), because the context holds knlist's lock, the context can
not sleep. So, KN_INFLUX should not be set on calling
kn-kn_fop-f_event() in kqueue_scan(), I think.
No, it needs to be set:
* Setting the KN_INFLUX flag enables you to unlock the kq that this knote
* is on, and modify kn_status as if you had the KQ lock.
As this comment says, _INFLUX allows you to unlock the KQ w/o fear that
the knote will disappear out from under you causing you to dereference
possibly free'd memory..
If you just tried to lock the list lock w/o unlocking the KQ lock, you
could end up w/ a dead lock, as you aren't maintaining lock order
properly.. The correct lock order if knlist - kq...
What do you think about this issue?
This is a real issue, but not due to the race you described
above...
I beleave it's the result of the race.
Could you try to add printf() in knote()?
Please refer to attached patch.
I have verified on my machine that it isn't because there is a knote
waiting that isn't getting woken up, and the knote on my hung process
has data == 0, so it definately lost one of the signals:
(kgdb) print $14.kq_knhash[20].slh_first[0]
$20 = {kn_link = {sle_next = 0x0}, kn_selnext = {sle_next = 0x0},
kn_knlist = 0xf8005a9c5840, kn_tqe = {tqe_next = 0xf801fdab4500,
tqe_prev = 0xf8004bb10038}, kn_kq = 0xf8004bb1, kn_kevent = {
ident = 20, filter = -6, flags = 32, fflags = 0, data = 0, udata = 0x0},
kn_status = 0, kn_sfflags = 0, kn_sdata = 0, kn_ptr = {
p_fp = 0xf8005a9c54b8, p_proc = 0xf8005a9c54b8,
p_aio = 0xf8005a9c54b8, p_lio = 0xf8005a9c54b8,
p_v = 0xf8005a9c54b8}, kn_fop = 0x81405ef0, kn_hook = 0x0,
kn_hookid = 0}
If you want to find this yourself, you can run kgdb on a live system,
switch to the thread of the parent (info threads, thread XXX), and
do:
frame 7
(or a frame that has td, which is struct thread *), then:
print *(struct kqueue *)td-td_proc[0].p_fd[0].fd_ofiles[3].fde_file[0].f_data
This will give you the struct kqueue * of the parent, and then:
print $XX.kq_knhash[0]@63
to figure out where the knote is in the hash, and then you can print
it out yourself...
I'm going to take a look at this a bit more later... I'm thinking of
using dtrace to collect the stacks where filt_signal is called, and
match them up... dtrace might even be able to get us the note's data
upon return helping to make sure things got tracked properly...
Thanks for finding this bug! Hopefully we can find a solution to it..
--
John-Mark GurneyVoice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
diff --git a/sys/kern/kern_event.c b/sys/kern/kern_event.c
index b3fb23d..7791447 100644
--- a/sys/kern/kern_event.c
+++ b/sys/kern/kern_event.c
@@ -1868,6 +1868,8 @@ knote(struct knlist *list, long hint, int lockflags)
if ((kn-kn_status KN_INFLUX) != KN_INFLUX) {
KQ_LOCK(kq);
if ((kn-kn_status KN_INFLUX) == KN_INFLUX) {
+if (hint NOTE_SIGNAL)
+ printf(Aee2\n);
KQ_UNLOCK(kq);
} else if ((lockflags KNF_NOKQLOCK) != 0) {
kn-kn_status |= KN_INFLUX;
@@ -1886,6 +1888,10 @@ knote(struct knlist *list, long hint, int lockflags)
Re: Leaving the Desktop Market
On 1 Apr 2014, at 23:10, Kevin Oberman rkober...@gmail.com wrote: Audio output is pretty system dependent, but I had little problem getting my audio to auto-switch to headphones when I plugged them in. The setup is a bit ugly,but I only had to check the available PINs (ugly, ugly) and set up stuff once. It just works. If you want my example set-up, I can post it somewhere or you can look in the archives for it as I have posted it in the past. It would be good to have this in the handbook (and to see what we can do to improve it). FreeBSD audio typically works out of the box and it's great when it does[1], but it can be underdocumented black magic to make it work when it doesn't. For example, I believe it's possible to tell pcm that when it receives a stereo stream it should redirect the left channel to the front and rear left, and the right channel to the front and rear right, but I haven't yet worked out how to do this - I'd have thought it was the kind of default that we'd want to have. The use case that PulseAudio was [over]designed to fix was plugging in USB headphones (or connecting a Bluetooth headset) and having existing audio streams redirected there. This should be possible with the existing sound stack, but there are some bits of plumbing missing. We already do in-kernel mixing and resampling, which are the hard bits. Duplicating streams and redirecting them are trivial by comparison. David [1] Although I had a slightly embarrassing moment when I spent an hour hunting for docs to tell me how to configure my media centre box do 5.1 output and then decided to just try it and found it worked out of the box. ___ 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
[head tinderbox] failure on arm/arm
TB --- 2014-04-02 06:00:42 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-02 06:00:42 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-02 06:00:42 - starting HEAD tinderbox run for arm/arm TB --- 2014-04-02 06:00:42 - cleaning the object tree TB --- 2014-04-02 06:00:42 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-02 06:00:47 - At svn revision 264031 TB --- 2014-04-02 06:00:48 - building world TB --- 2014-04-02 06:00:48 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 06:00:48 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 06:00:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 06:00:48 - SRCCONF=/dev/null TB --- 2014-04-02 06:00:48 - TARGET=arm TB --- 2014-04-02 06:00:48 - TARGET_ARCH=arm TB --- 2014-04-02 06:00:48 - TZ=UTC TB --- 2014-04-02 06:00:48 - __MAKE_CONF=/dev/null TB --- 2014-04-02 06:00:48 - cd /src TB --- 2014-04-02 06:00:48 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Wed Apr 2 06:00:55 UTC 2014 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Apr 2 09:21:09 UTC 2014 TB --- 2014-04-02 09:21:09 - generating LINT kernel config TB --- 2014-04-02 09:21:09 - cd /src/sys/arm/conf TB --- 2014-04-02 09:21:09 - /usr/bin/make -B LINT TB --- 2014-04-02 09:21:09 - cd /src/sys/arm/conf TB --- 2014-04-02 09:21:09 - /obj/arm.arm/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-04-02 09:21:09 - building LINT kernel TB --- 2014-04-02 09:21:09 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 09:21:09 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 09:21:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 09:21:09 - SRCCONF=/dev/null TB --- 2014-04-02 09:21:09 - TARGET=arm TB --- 2014-04-02 09:21:09 - TARGET_ARCH=arm TB --- 2014-04-02 09:21:09 - TZ=UTC TB --- 2014-04-02 09:21:09 - __MAKE_CONF=/dev/null TB --- 2014-04-02 09:21:09 - cd /src TB --- 2014-04-02 09:21:09 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Apr 2 09:21:10 UTC 2014 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/dev/iicbus/iicsmb.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/dev/iicbus/iicoc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/dev/iicbus/s35390a.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq
[head tinderbox] failure on armv6/arm
TB --- 2014-04-02 06:00:42 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-02 06:00:42 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-02 06:00:42 - starting HEAD tinderbox run for armv6/arm TB --- 2014-04-02 06:00:42 - cleaning the object tree TB --- 2014-04-02 06:00:42 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-02 06:00:47 - At svn revision 264031 TB --- 2014-04-02 06:00:48 - building world TB --- 2014-04-02 06:00:48 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 06:00:48 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 06:00:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 06:00:48 - SRCCONF=/dev/null TB --- 2014-04-02 06:00:48 - TARGET=arm TB --- 2014-04-02 06:00:48 - TARGET_ARCH=armv6 TB --- 2014-04-02 06:00:48 - TZ=UTC TB --- 2014-04-02 06:00:48 - __MAKE_CONF=/dev/null TB --- 2014-04-02 06:00:48 - cd /src TB --- 2014-04-02 06:00:48 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Wed Apr 2 06:00:55 UTC 2014 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Apr 2 09:21:09 UTC 2014 TB --- 2014-04-02 09:21:09 - generating LINT kernel config TB --- 2014-04-02 09:21:09 - cd /src/sys/arm/conf TB --- 2014-04-02 09:21:09 - /usr/bin/make -B LINT TB --- 2014-04-02 09:21:09 - cd /src/sys/arm/conf TB --- 2014-04-02 09:21:09 - /obj/arm.armv6/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-04-02 09:21:09 - skipping LINT kernel TB --- 2014-04-02 09:21:09 - cd /src/sys/arm/conf TB --- 2014-04-02 09:21:09 - /obj/arm.armv6/src/tmp/legacy/usr/sbin/config -m AC100 TB --- 2014-04-02 09:21:10 - building AC100 kernel TB --- 2014-04-02 09:21:10 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 09:21:10 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 09:21:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 09:21:10 - SRCCONF=/dev/null TB --- 2014-04-02 09:21:10 - TARGET=arm TB --- 2014-04-02 09:21:10 - TARGET_ARCH=armv6 TB --- 2014-04-02 09:21:10 - TZ=UTC TB --- 2014-04-02 09:21:10 - __MAKE_CONF=/dev/null TB --- 2014-04-02 09:21:10 - cd /src TB --- 2014-04-02 09:21:10 - /usr/bin/make -B buildkernel KERNCONF=AC100 Kernel build for AC100 started on Wed Apr 2 09:21:10 UTC 2014 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for AC100 completed on Wed Apr 2 09:24:20 UTC 2014 TB --- 2014-04-02 09:24:20 - cd /src/sys/arm/conf TB --- 2014-04-02 09:24:20 - /obj/arm.armv6/src/tmp/legacy/usr/sbin/config -m ARMADAXP TB --- 2014-04-02 09:24:21 - building ARMADAXP kernel TB --- 2014-04-02 09:24:21 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 09:24:21 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 09:24:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 09:24:21 - SRCCONF=/dev/null TB --- 2014-04-02 09:24:21 - TARGET=arm TB --- 2014-04-02 09:24:21 - TARGET_ARCH=armv6 TB --- 2014-04-02 09:24:21 - TZ=UTC TB --- 2014-04-02 09:24:21 - __MAKE_CONF=/dev/null TB --- 2014-04-02 09:24:21 - cd /src TB --- 2014-04-02 09:24:21 - /usr/bin/make -B buildkernel KERNCONF=ARMADAXP Kernel build for ARMADAXP started on Wed Apr 2 09:24:21 UTC 2014 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for ARMADAXP completed on Wed Apr 2 09:28:25 UTC 2014 TB --- 2014-04-02 09:28:25 - cd /src/sys/arm/conf TB --- 2014-04-02 09:28:25 - /obj/arm.armv6/src/tmp/legacy/usr/sbin/config -m ARNDALE TB --- 2014-04-02 09:28:25 - building ARNDALE kernel TB --- 2014-04-02 09:28:25 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 09:28:25 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 09:28:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 09:28:25 - SRCCONF=/dev/null TB --- 2014-04-02 09:28:25 - TARGET=arm TB --- 2014-04-02 09:28:25 - TARGET_ARCH=armv6 TB --- 2014-04-02 09:28:25 - TZ=UTC TB --- 2014-04-02 09:28:25 - __MAKE_CONF=/dev/null TB --- 2014-04-02 09:28:25 - cd /src TB --- 2014-04-02 09:28:25 - /usr/bin/make -B buildkernel KERNCONF=ARNDALE Kernel build for ARNDALE started on Wed Apr 2 09:28:25 UTC 2014 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for ARNDALE completed on Wed Apr 2 09:33:16 UTC 2014 TB --- 2014-04-02
[head tinderbox] failure on i386/i386
TB --- 2014-04-02 06:00:42 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-02 06:00:42 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-02 06:00:42 - starting HEAD tinderbox run for i386/i386 TB --- 2014-04-02 06:00:42 - cleaning the object tree TB --- 2014-04-02 06:00:42 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-02 06:00:47 - At svn revision 264031 TB --- 2014-04-02 06:00:48 - building world TB --- 2014-04-02 06:00:48 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 06:00:48 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 06:00:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 06:00:48 - SRCCONF=/dev/null TB --- 2014-04-02 06:00:48 - TARGET=i386 TB --- 2014-04-02 06:00:48 - TARGET_ARCH=i386 TB --- 2014-04-02 06:00:48 - TZ=UTC TB --- 2014-04-02 06:00:48 - __MAKE_CONF=/dev/null TB --- 2014-04-02 06:00:48 - cd /src TB --- 2014-04-02 06:00:48 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Wed Apr 2 06:00:55 UTC 2014 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Apr 2 09:31:19 UTC 2014 TB --- 2014-04-02 09:31:19 - generating LINT kernel config TB --- 2014-04-02 09:31:19 - cd /src/sys/i386/conf TB --- 2014-04-02 09:31:19 - /usr/bin/make -B LINT TB --- 2014-04-02 09:31:19 - cd /src/sys/i386/conf TB --- 2014-04-02 09:31:19 - /obj/i386.i386/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-04-02 09:31:19 - building LINT kernel TB --- 2014-04-02 09:31:19 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 09:31:19 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 09:31:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 09:31:19 - SRCCONF=/dev/null TB --- 2014-04-02 09:31:19 - TARGET=i386 TB --- 2014-04-02 09:31:19 - TARGET_ARCH=i386 TB --- 2014-04-02 09:31:19 - TZ=UTC TB --- 2014-04-02 09:31:19 - __MAKE_CONF=/dev/null TB --- 2014-04-02 09:31:19 - cd /src TB --- 2014-04-02 09:31:19 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Apr 2 09:31:19 UTC 2014 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -c ipwibssfw.c uudecode -o ipw_ibss.fw /src/sys/contrib/dev/ipw/ipw2100-1.3-i.fw.uu ld -b binary --no-warn-mismatch -d -warn-common -r -o ipw_ibss.fwo ipw_ibss.fw cc -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -c ipwmonitorfw.c uudecode -o ipw_monitor.fw /src/sys/contrib/dev/ipw/ipw2100-1.3-p.fw.uu ld -b binary --no-warn-mismatch -d -warn-common -r -o ipw_monitor.fwo ipw_monitor.fw cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/dev/iscsi/icl.c
Re: vt text cursor invisible in reverse video
On 03/28/2014 19:15, Adrian Chadd wrote: Hi, Would you mind filing it as a PR? www.freebsd.org/send-pr.html kern/188196 After 19 years of FreeBSD use and not being part of any chapel/coterie/mafia I don't keep much illusion about the outcome.. CBu ___ 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: Leaving the Desktop Market
On Wed, Apr 02, 2014 at 10:22:32AM +0100, David Chisnall wrote: On 1 Apr 2014, at 23:10, Kevin Oberman rkober...@gmail.com wrote: Audio output is pretty system dependent, but I had little problem getting my audio to auto-switch to headphones when I plugged them in. The setup is a bit ugly,but I only had to check the available PINs (ugly, ugly) and set up stuff once. It just works. If you want my example set-up, I can post it somewhere or you can look in the archives for it as I have posted it in the past. It would be good to have this in the handbook (and to see what we can do to improve it). FreeBSD audio typically works out of the box and it's great when it does[1], but it can be underdocumented black magic to make it work when it doesn't. For example, I believe it's possible to tell pcm that when it receives a stereo stream it should redirect the left channel to the front and rear left, and the right channel to the front and rear right, but I haven't yet worked out how to do this - I'd have thought it was the kind of default that we'd want to have. The use case that PulseAudio was [over]designed to fix was plugging in USB headphones (or connecting a Bluetooth headset) and having existing audio streams redirected there. This should be possible with the existing sound stack, but there are some bits of plumbing missing. We already do in-kernel mixing and resampling, which are the hard bits. Duplicating streams and redirecting them are trivial by comparison. David [1] Although I had a slightly embarrassing moment when I spent an hour hunting for docs to tell me how to configure my media centre box do 5.1 output and then decided to just try it and found it worked out of the box. AFAIK we already can configure HDA's sound output and input in many ways using sysctl(8). What's still missing is a user-friendly way to configure sound. There are some things that can be handled in one little program / script / TUI / GUI / CLI: - Default sound unit (hw.snd.default_unit) - Use the last inserted sound device as default? (hw.snd.default_auto) - PIN Routing (dev.hdaa.%d.config) - Mixer settings Putting it all together in something called sndcontrol should not be too hard. It just takes someone(TM) to do it pgpm1Mkt0Pad2.pgp Description: PGP signature
Adding Encryption Algorithm to Kernel
Hi I am working on a project and i want to add an encryption algorithm to freeBSD kernel. What are the steps ? Which files should i change ? I have searched the internet and the forums and mailing lists, but couldn't find anything. I was hoping you could help me out. Thanks in advance, Shady ___ 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: Leaving the Desktop Market
On Apr 1, 2014, at 9:12 PM, Jim Thompson j...@netgate.com wrote: I have Macs at work (typing on one now), and a mac at home. I like them. [ … ] It’s just like being back in the 80s, when Unix had a desktop market, only much, much faster. Worry not, there’s a product just for you now! http://www.macstories.net/mac/cathode-is-a-vintage-terminal-for-os-x/ Of course I have a copy. I couldn’t resist buying it. - Jordan ___ 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: kevent has bug?
On Wed, Apr 02, 2014 at 04:06:16PM +0900, Kohji Okuno wrote:
From: John-Mark Gurney j...@funkthat.com
Date: Tue, 1 Apr 2014 23:15:51 -0700
Kohji Okuno wrote this message on Wed, Apr 02, 2014 at 11:45 +0900:
I think, kevent() has a bug.
I tested sample programs by attached sources.
This sample tests about EVFILT_SIGNAL.
I build sample programs by the following commands.
% gcc -O2 -o child child.c
% gcc -O2 -o parent parent.c
The expected result is the following.
% ./parent
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
OK
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
OK
But, sometimes the result was the following.
% ./parent
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
This result means the number of times the signal has occured was
incorrect.
I was able to reproduce this...
In case of EVFILT_SIGNAL, according to `man kevent', `data' retuns the
number of times the signal has occurred since the last call to
kevent(). This `data' is recorded by filt_signal() (This is f_event in
struct filterops).
The system call kevent()'s events are processed by kqueue_scan() in
kern_event.c. In kqueue_scan(), kn-kn_fop-f_event() is allways
called after KN_INFLUX is set to kn-kn_status.
On the other hand, kernel events are occured by knote() in
kern_event.c. (In EVFILT_SIGNAL, knote() is called from tdsendsignal()
in kern_sig.c.) In knote(), kn-kn_fop-f_event() is called only when
KN_INFLUX is not set in kn-kn_status.
In race condition between kqueue_scan() and knote(),
kn-kn_fop-f_event() from knote() may not be called, I think.
Considering that both are called w/ a lock, that cannot happen..
KN_LIST_LOCK(kn) locks the same lock that is asserted that is held
by knote...
In knote(), because the context holds knlist's lock, the context can
not sleep. So, KN_INFLUX should not be set on calling
kn-kn_fop-f_event() in kqueue_scan(), I think.
No, it needs to be set:
* Setting the KN_INFLUX flag enables you to unlock the kq that this knote
* is on, and modify kn_status as if you had the KQ lock.
As this comment says, _INFLUX allows you to unlock the KQ w/o fear that
the knote will disappear out from under you causing you to dereference
possibly free'd memory..
If you just tried to lock the list lock w/o unlocking the KQ lock, you
could end up w/ a dead lock, as you aren't maintaining lock order
properly.. The correct lock order if knlist - kq...
What do you think about this issue?
This is a real issue, but not due to the race you described
above...
I beleave it's the result of the race.
Could you try to add printf() in knote()?
Please refer to attached patch.
I have verified on my machine that it isn't because there is a knote
waiting that isn't getting woken up, and the knote on my hung process
has data == 0, so it definately lost one of the signals:
(kgdb) print $14.kq_knhash[20].slh_first[0]
$20 = {kn_link = {sle_next = 0x0}, kn_selnext = {sle_next = 0x0},
kn_knlist = 0xf8005a9c5840, kn_tqe = {tqe_next = 0xf801fdab4500,
tqe_prev = 0xf8004bb10038}, kn_kq = 0xf8004bb1, kn_kevent =
{
ident = 20, filter = -6, flags = 32, fflags = 0, data = 0, udata = 0x0},
kn_status = 0, kn_sfflags = 0, kn_sdata = 0, kn_ptr = {
p_fp = 0xf8005a9c54b8, p_proc = 0xf8005a9c54b8,
p_aio = 0xf8005a9c54b8, p_lio = 0xf8005a9c54b8,
p_v = 0xf8005a9c54b8}, kn_fop = 0x81405ef0, kn_hook = 0x0,
kn_hookid = 0}
If you want to find this yourself, you can run kgdb on a live system,
switch to the thread of the parent (info threads, thread XXX), and
do:
frame 7
(or a frame that has td, which is struct thread *), then:
print *(struct kqueue
*)td-td_proc[0].p_fd[0].fd_ofiles[3].fde_file[0].f_data
This will give you the struct kqueue * of the parent, and then:
print $XX.kq_knhash[0]@63
to figure out where the knote is in the hash, and then you can print
it out yourself...
I'm going to take a look at this a bit more later... I'm thinking of
using dtrace to collect the stacks where filt_signal is called, and
match them up... dtrace might even be able to get us the note's data
upon return helping to make sure things got tracked properly...
Thanks for finding this bug! Hopefully we can find a solution to it..
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
diff --git a/sys/kern/kern_event.c b/sys/kern/kern_event.c
index b3fb23d..7791447 100644
--- a/sys/kern/kern_event.c
+++ b/sys/kern/kern_event.c
@@ -1868,6 +1868,8 @@ knote(struct knlist *list, long hint, int lockflags)
if ((kn-kn_status KN_INFLUX) != KN_INFLUX) {
KQ_LOCK(kq);
if ((kn-kn_status KN_INFLUX) == KN_INFLUX) {
+
Re: Leaving the Desktop Market
On Apr 1, 2014, at 9:33 PM, Person, Roderick perso...@upmc.edu wrote: Why aren't all the nerds and small businesses out there a market? Too few of you to justify the capital outlay. Now, if we were talking about a $1500 watch that was very nerdy and appealed to the inner James Bond in lots of non-nerds, the margins might just justify it. If Apple hardware is too expensive for you, there is always Windows and a cheap PC clone. Between those two poles, the entirety of the desktop market is pretty much spoken for. I get that there are some (mostly on these mailing lists) who don’t want either, but religious / personal preferences to the contrary don’t create markets until there are at least a few million of you. ___ 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
make in dir
Hi,
it seems that recent changes to share/mk broke the ability to do anything
in subdir of the source tree. As example, on the HEAD r264012 installed
yesterday:
sandy% make /usr/home/pooma/build/bsd/DEV/src/tools/regression/kqueue
make: /usr/share/mk/bsd.own.mk line 436: MK_MAN can't be set by a user.
Also, on stable/9 hosting the HEAD cross-env:
cd src MAKEOBJDIRPREFIX=/usr/home/kostik/build/bsd/DEV/obj-amd64
DESTDIR=/usr/home/kostik/build/bsd/DEV/netboot/sandy-amd64
SYSDIR=/usr/home/kostik/build/bsd/DEV/src/sys TARGET=amd64 make buildenv
Entering world for amd64:amd64
# cd share/mk
# make install
bsd.own.mk, line 435: Malformed conditional (${.MAKE.LEVEL} == 0)
bsd.own.mk, line 436: MK_PROFILE can't be set by a user.
# ^D
I believe I am not the first person reporting the problem.
pgp71PvCxEAPv.pgp
Description: PGP signature
Re: Leaving the Desktop Market
On Apr 1, 2014, at 10:11 PM, Matt Olander m...@ixsystems.com wrote: This is like trying to predict automobile technology and dominant car-makers by 1905. There's always room for competition. Take a look at what's happening right now in the auto-industry. Tesla came out of nowhere 125 years after the invention of the automobile and is doing pretty well. I think you’re kind of making my point for me, Matt. :-) Tesla benefitted entirely from deep pockets on the part of its investors. Over $160M went into starting the company, of which $70M came from the personal checking account of Elon Musk, the current visionary and CEO, and to quote the wikipedia page: Tesla Motors is a public company that trades on the NASDAQ stock exchange under the symbol TSLA.[5] In the first quarter of 2013, Tesla posted profits for the first time in its ten year history.” Yep, in other words, Tesla has been losing money for over 10 years and only just started turning a profit, after raising a “mere $187M in investment and $485M in loans from the US DOE. Your tax dollars at work! On top of all that Tesla has only managed to make money at all by focusing exclusively the highest end of the luxury car market, where profit margins are also the highest (the first car, the roadster, would set you back $110,000). Getting back to computer operating systems, it would make most readers of these lists choke on their Doritos to know how much Apple had to invest in Mac OS X before it became a viable desktop operating system and of course you’ve already seen folks screaming about how Apple gear is too expensive and they’ll never buy it. You just don’t get a consumer-grade desktop Unix OS, or a practical all-electric sedan, without serious monetary investment and a luxury marquee to match, assuming you’d like to actually make any of that money *back*. So, back to BSD on the desktop. Anyone got a spare $200M they’d like to just throw away? That’s what it’s going to take! :) Don’t believe me? Go ask someone who knows first-hand then. Ask Mark Shuttleworth: http://arstechnica.com/information-technology/2013/08/why-ubuntus-creator-still-invests-his-fortune-in-an-unprofitable-company/ :-) - Jordan ___ 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: kevent has bug?
From: Konstantin Belousov kostik...@gmail.com
Date: Wed, 2 Apr 2014 15:07:45 +0300
On Wed, Apr 02, 2014 at 04:06:16PM +0900, Kohji Okuno wrote:
From: John-Mark Gurney j...@funkthat.com
Date: Tue, 1 Apr 2014 23:15:51 -0700
Kohji Okuno wrote this message on Wed, Apr 02, 2014 at 11:45 +0900:
I think, kevent() has a bug.
I tested sample programs by attached sources.
This sample tests about EVFILT_SIGNAL.
I build sample programs by the following commands.
% gcc -O2 -o child child.c
% gcc -O2 -o parent parent.c
The expected result is the following.
% ./parent
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
OK
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
OK
But, sometimes the result was the following.
% ./parent
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
This result means the number of times the signal has occured was
incorrect.
I was able to reproduce this...
In case of EVFILT_SIGNAL, according to `man kevent', `data' retuns the
number of times the signal has occurred since the last call to
kevent(). This `data' is recorded by filt_signal() (This is f_event in
struct filterops).
The system call kevent()'s events are processed by kqueue_scan() in
kern_event.c. In kqueue_scan(), kn-kn_fop-f_event() is allways
called after KN_INFLUX is set to kn-kn_status.
On the other hand, kernel events are occured by knote() in
kern_event.c. (In EVFILT_SIGNAL, knote() is called from tdsendsignal()
in kern_sig.c.) In knote(), kn-kn_fop-f_event() is called only when
KN_INFLUX is not set in kn-kn_status.
In race condition between kqueue_scan() and knote(),
kn-kn_fop-f_event() from knote() may not be called, I think.
Considering that both are called w/ a lock, that cannot happen..
KN_LIST_LOCK(kn) locks the same lock that is asserted that is held
by knote...
In knote(), because the context holds knlist's lock, the context can
not sleep. So, KN_INFLUX should not be set on calling
kn-kn_fop-f_event() in kqueue_scan(), I think.
No, it needs to be set:
* Setting the KN_INFLUX flag enables you to unlock the kq that this knote
* is on, and modify kn_status as if you had the KQ lock.
As this comment says, _INFLUX allows you to unlock the KQ w/o fear that
the knote will disappear out from under you causing you to dereference
possibly free'd memory..
If you just tried to lock the list lock w/o unlocking the KQ lock, you
could end up w/ a dead lock, as you aren't maintaining lock order
properly.. The correct lock order if knlist - kq...
What do you think about this issue?
This is a real issue, but not due to the race you described
above...
I beleave it's the result of the race.
Could you try to add printf() in knote()?
Please refer to attached patch.
I have verified on my machine that it isn't because there is a knote
waiting that isn't getting woken up, and the knote on my hung process
has data == 0, so it definately lost one of the signals:
(kgdb) print $14.kq_knhash[20].slh_first[0]
$20 = {kn_link = {sle_next = 0x0}, kn_selnext = {sle_next = 0x0},
kn_knlist = 0xf8005a9c5840, kn_tqe = {tqe_next = 0xf801fdab4500,
tqe_prev = 0xf8004bb10038}, kn_kq = 0xf8004bb1, kn_kevent
= {
ident = 20, filter = -6, flags = 32, fflags = 0, data = 0, udata =
0x0},
kn_status = 0, kn_sfflags = 0, kn_sdata = 0, kn_ptr = {
p_fp = 0xf8005a9c54b8, p_proc = 0xf8005a9c54b8,
p_aio = 0xf8005a9c54b8, p_lio = 0xf8005a9c54b8,
p_v = 0xf8005a9c54b8}, kn_fop = 0x81405ef0, kn_hook = 0x0,
kn_hookid = 0}
If you want to find this yourself, you can run kgdb on a live system,
switch to the thread of the parent (info threads, thread XXX), and
do:
frame 7
(or a frame that has td, which is struct thread *), then:
print *(struct kqueue
*)td-td_proc[0].p_fd[0].fd_ofiles[3].fde_file[0].f_data
This will give you the struct kqueue * of the parent, and then:
print $XX.kq_knhash[0]@63
to figure out where the knote is in the hash, and then you can print
it out yourself...
I'm going to take a look at this a bit more later... I'm thinking of
using dtrace to collect the stacks where filt_signal is called, and
match them up... dtrace might even be able to get us the note's data
upon return helping to make sure things got tracked properly...
Thanks for finding this bug! Hopefully we can find a solution to it..
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
diff --git a/sys/kern/kern_event.c b/sys/kern/kern_event.c
index b3fb23d..7791447 100644
--- a/sys/kern/kern_event.c
+++ b/sys/kern/kern_event.c
@@ -1868,6 +1868,8 @@ knote(struct knlist *list, long hint, int lockflags)
if ((kn-kn_status KN_INFLUX) != KN_INFLUX) {
Re: Adding Encryption Algorithm to Kernel
On 4/2/14, Shady Elhamy shady.elh...@securemisr.net wrote: Hi I am working on a project and i want to add an encryption algorithm to freeBSD kernel. What are the steps ? Which files should i change ? I have searched the internet and the forums and mailing lists, but couldn't find anything. I was hoping you could help me out. http://2009.asiabsdcon.org/papers/abc2009-P1B-paper.pdf http://www.daemon-systems.org/man/opencrypto.9.html Thanks in advance, Shady ___ 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: Leaving the Desktop Market
On 02.04.14 12:22, David Chisnall wrote: The use case that PulseAudio was [over]designed to fix was plugging in USB headphones (or connecting a Bluetooth headset) and having existing audio streams redirected there. Please don't ever make this behavior the default! Imagine, you have an audio setup mixing sound and pushing it out and then you plug in some USB device that also has audio capability and your production sound gets redirected there. A nightmare! Knowing what you do and the system behaving in predictable way is one of the beauties of UNIX and FreeBSD in particular. Don't make it so that even idiots can use it because then, only idiots will be using it! My 0.02, Daniel ___ 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: Leaving the Desktop Market
On 2 Apr 2014, at 13:40, Daniel Kalchev dan...@digsys.bg wrote: On 02.04.14 12:22, David Chisnall wrote: The use case that PulseAudio was [over]designed to fix was plugging in USB headphones (or connecting a Bluetooth headset) and having existing audio streams redirected there. Please don't ever make this behavior the default! Imagine, you have an audio setup mixing sound and pushing it out and then you plug in some USB device that also has audio capability and your production sound gets redirected there. A nightmare! Do you really think that someone is going to be setting up an audio mixing environment without configuring their sound setup? Or that people doing this make up the majority of users? Knowing what you do and the system behaving in predictable way is one of the beauties of UNIX and FreeBSD in particular. I agree, however sane defaults are also very important to a useable system and these are not mutually exclusive. It is perfectly possible to have a system that has defaults that do what most users do (or a choice of defaults based on a simple selection of typical uses), but which is also configurable if you have unusual requirements. This is what we aim to do with FreeBSD. Don't make it so that even idiots can use it because then, only idiots will be using it! This kind of argument has no place in FreeBSD. You are not a better person because you use things that are hard to use. You are not a better person because you choose to do things the difficult way. You are not a better person because you prove your superiority by making life hard for others. David ___ 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: Leaving the Desktop Market
On 02.04.14 15:52, David Chisnall wrote: On 2 Apr 2014, at 13:40, Daniel Kalchev dan...@digsys.bg wrote: On 02.04.14 12:22, David Chisnall wrote: The use case that PulseAudio was [over]designed to fix was plugging in USB headphones (or connecting a Bluetooth headset) and having existing audio streams redirected there. Please don't ever make this behavior the default! Imagine, you have an audio setup mixing sound and pushing it out and then you plug in some USB device that also has audio capability and your production sound gets redirected there. A nightmare! Do you really think that someone is going to be setting up an audio mixing environment without configuring their sound setup? Or that people doing this make up the majority of users? Twenty years ago, very unlikely. Today, very much possible. Especially if the behavior is not explicitly documented. Knowing what you do and the system behaving in predictable way is one of the beauties of UNIX and FreeBSD in particular. I agree, however sane defaults are also very important to a useable system and these are not mutually exclusive. It is perfectly possible to have a system that has defaults that do what most users do (or a choice of defaults based on a simple selection of typical uses), but which is also configurable if you have unusual requirements. This is what we aim to do with FreeBSD. I have no problems with the sound system supporting different setups. I just fail to see the usefulness of such configuration, except in the very trivial setup, where you have only one output device and add another. What if there are three output audio devices in the systems? Trivial with all the HDMI etc today. An overly auto-configuring system is a pain to deal with, sometimes. Especially if you cannot control some aspects of it's behavior. In such cases, you end up with a more complicated setup. Don't make it so that even idiots can use it because then, only idiots will be using it! This kind of argument has no place in FreeBSD. You are not a better person because you use things that are hard to use. You are not a better person because you choose to do things the difficult way. You are not a better person because you prove your superiority by making life hard for others. David This was uncalled for, really. Daniel ___ 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: Leaving the Desktop Market
On 02.04.14 04:26, Adrian Chadd wrote: It's no longer xorg just speaks to the graphics chip. This is a common trend in computing recently. What once required tightly integrated OS/applications is now distributed, in the widest sense. The so called Personal Computer is nowadays actually spread out all around the globe -- some of your desktop applications or parts of them might actually run in a data center far, far away. Having lots of diskless workstations in my office, all running FreeBSD and fact being dumb X Windows terminals to a bunch of servers, where the actually applications run -- it is sometimes very difficult to even begin explaining this concept to colleagues who have seen nothing but the Windows PC. The display, keyboard, mouse etc might be running their own and different OS each. Therefore, I don't see this adding of abstraction layers as a bad thing, as it lets you have a FreeBSD workstation, running on an Android STB as the interface to your physical monitor/mouse/etc. What we should do instead is make sure that FreeBSD supports the respective APIs. Considering that today visualization is everywhere, I also don't see any problem running that particular Windows, or Linux only application in an VirtualBox window. Or (in my example office case), running something (Linux?) on the diskless workstations that handles the peculiarities of the particular video chip/audio etc and still providing you with the same desktop session on your FreeBSD servers. Daniel ___ 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
[head tinderbox] failure on i386/pc98
TB --- 2014-04-02 09:29:19 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-02 09:29:19 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-02 09:29:19 - starting HEAD tinderbox run for i386/pc98 TB --- 2014-04-02 09:29:19 - cleaning the object tree TB --- 2014-04-02 09:29:19 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-02 09:29:32 - At svn revision 264031 TB --- 2014-04-02 09:29:33 - building world TB --- 2014-04-02 09:29:33 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 09:29:33 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 09:29:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 09:29:33 - SRCCONF=/dev/null TB --- 2014-04-02 09:29:33 - TARGET=pc98 TB --- 2014-04-02 09:29:33 - TARGET_ARCH=i386 TB --- 2014-04-02 09:29:33 - TZ=UTC TB --- 2014-04-02 09:29:33 - __MAKE_CONF=/dev/null TB --- 2014-04-02 09:29:33 - cd /src TB --- 2014-04-02 09:29:33 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Wed Apr 2 09:29:41 UTC 2014 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Apr 2 13:09:09 UTC 2014 TB --- 2014-04-02 13:09:09 - generating LINT kernel config TB --- 2014-04-02 13:09:09 - cd /src/sys/pc98/conf TB --- 2014-04-02 13:09:09 - /usr/bin/make -B LINT TB --- 2014-04-02 13:09:09 - cd /src/sys/pc98/conf TB --- 2014-04-02 13:09:09 - /obj/pc98.i386/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-04-02 13:09:09 - building LINT kernel TB --- 2014-04-02 13:09:09 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 13:09:09 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 13:09:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 13:09:09 - SRCCONF=/dev/null TB --- 2014-04-02 13:09:09 - TARGET=pc98 TB --- 2014-04-02 13:09:09 - TARGET_ARCH=i386 TB --- 2014-04-02 13:09:09 - TZ=UTC TB --- 2014-04-02 13:09:09 - __MAKE_CONF=/dev/null TB --- 2014-04-02 13:09:09 - cd /src TB --- 2014-04-02 13:09:09 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Apr 2 13:09:09 UTC 2014 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/dev/iicbus/iicbus.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/iicbus/iicbus_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg iicbus_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/dev/iicbus/iiconf.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option
Re: Leaving the Desktop Market
On Tue, 1 Apr 2014 15:10:22 -0700 Kevin Oberman rkober...@gmail.com wrote: No, mutt, with vim as mail composer. :) +1 matthias (FreeBSD since 2.2.5 and sending this from an EeePC 900, netbook, UMTS connected, KDE4 desktop, sound, webcam, vim, mutt, sendmail, ...) FreeBSD desktop since 3.3 (makes me a newbie!) FreeBSD server and desktop since 2.0 (replaced Ultrix 4.3 system). Does it makes me an oldie? I'm stuck since with FreeBSD on private systems and a couple of years ago, I had no problems even run servers based on FreeBSD for my department. I dislike this unspecific terminus desktop, since people seem to associate entertainment systems with neat graphics, mouse and other interesting human stuff (even audio). On the other hand, server seems hardcoded to unfancy 19inch rack-based plastic-metal-based clumsy and noisy high-performance systems stored in a dark air-conditioned cellar. But what is with the old-fashioned terminus workstation? In a more scientific environment, systems with the performance needs of a server but with the exterior habitus of a desktop were very often called workstation. Nowadays, we run a single remaining FreeBSD server and I kept my desktop system also working on FreeBSD (11.0, recent hardware, by the way). We had to change the other desktops (I prefer workstation) towards Linux due to the need of OpenCL in combination with some expensive TESLA boards for numerical modelling and datellite image processing. The software we used was mostly home-brewn so we didn't rely on commercial Linux-only stuff and it would have been an easy task to run the software also on FreeBSD based workstations - if the GPU could be used. Even the SoC platforms come with OpenCL support (also for the GPU) these days and i do not see anything useful on FreeBSD (except POCL for CPU usage, but no GPU). My contribution to 1st of April ... Oliver signature.asc Description: PGP signature
Re: make in dir
On Apr 2, 2014, at 6:15 AM, Konstantin Belousov kostik...@gmail.com wrote:
Hi,
it seems that recent changes to share/mk broke the ability to do anything
in subdir of the source tree. As example, on the HEAD r264012 installed
yesterday:
sandy% make
/usr/home/pooma/build/bsd/DEV/src/tools/regression/kqueue
make: /usr/share/mk/bsd.own.mk line 436: MK_MAN can't be set by a user.
I’ve had reports of this, but couldn’t recreate it. Will try again...
Also, on stable/9 hosting the HEAD cross-env:
cd src MAKEOBJDIRPREFIX=/usr/home/kostik/build/bsd/DEV/obj-amd64
DESTDIR=/usr/home/kostik/build/bsd/DEV/netboot/sandy-amd64
SYSDIR=/usr/home/kostik/build/bsd/DEV/src/sys TARGET=amd64 make buildenv
Entering world for amd64:amd64
# cd share/mk
# make install
bsd.own.mk, line 435: Malformed conditional (${.MAKE.LEVEL} == 0)
bsd.own.mk, line 436: MK_PROFILE can't be set by a user.
# ^D
This is news to me...
I believe I am not the first person reporting the problem.
Half true…
Warner
___
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: [CFT] ASLR and PIE on amd64
On 4/2/14, Oliver Pinter oliver.p...@gmail.com wrote: On 3/31/14, Shawn Webb latt...@gmail.com wrote: On Mar 31, 2014 02:07 AM +0200, Oliver Pinter wrote: On 3/22/14, Shawn Webb latt...@gmail.com wrote: Hey All, First off, I hope that even as a non-committer, it's okay that I post a call for testing. If not, please excuse my newbishness in this process. This is my first time submitting a major patch upstream to FreeBSD. Over the past few months, I've had the opportunity and pleasure to enhance existing patches to FreeBSD that implement a common exploit mitigation technology called Address Space Layout Randomization (ASLR) along with support for Position Independent Executables (PIE). ASLR+PIE has been a long-requested feature by many people I've met on IRC. I've submitted my patch to PR kernel/181497. I'm currently in the process of adding PIE support to certain high-visibility applications in base (mainly network daemons). I've added a make.conf knob that's default to enabled (WITH_PIE=1). An application has to also explicitly support PIE as well by defining CAN_PIE in the Makefile prior to including bsd.prog.mk. After I get a decent amount of applications enabled with PIE support, I'll submit one last patch. The following sysctl's can be set with a kernel compiled with the PAX_ASLR option: security.pax.aslr.status: 1 security.pax.aslr.debug: 0 security.pax.aslr.mmap_len: 16 security.pax.aslr.stack_len: 12 security.pax.aslr.exec_len: 12 The security.pax.aslr.status sysctl enables and disables the ASLR system as a whole. The debug sysctl gives debugging output. The mmap_len sysctl tells the ASLR system how many bits to randomize with mmap() is called. The stack_len sysctl tells the ASLR system how many bits to randomize in the stack. The exec_len sysctl tells the ASLR system how many bits to randomize the execbase (this controls PIE). These sysctls can be set as a per-jail basis. If you have an application which doesn't support ASLR, yet you want ASLR enabled for everything else, you can simply place that misbehaving application in a jail with only that jail's ASLR settings turned off. Please let me know how your testing goes. I'm giving a presentation at BSDCan regarding this. If you want to keep tabs on my bleeding-edge development process, please follow my progress on GitHub: https://github.com/lattera/freebsd (branch: soldierx/lattera/aslr). Thank you very much, Hi! Please apply this patch. This fixed an issue with tunables. Patch merged successfully into my GitHub repo. Fixed with commit d2c0813. I'll include it in my next patch submission upstream when I submit my PIE work. Thanks! please see the attached patch, compile and boot tested on amd64 Some more patches, and one critical fix (0006-PAX-ASLR-use-the-right-sysent-before-this-commit-cal.patch). 0001-PAX-ASLR-remove-dirty-hack-to-determine-which-pax_in.patch Description: Binary data 0002-PAX-ASLR-updated-debug-messages.patch Description: Binary data 0003-PAX-ASLR-removed-unused-variable.patch Description: Binary data 0004-PaX-ASLR-added-more-debug-messages.patch Description: Binary data 0005-PAX-ASLR-fix-debug-messages-added-new-line.patch Description: Binary data 0006-PAX-ASLR-use-the-right-sysent-before-this-commit-cal.patch Description: Binary data ___ 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: [CFT] ASLR and PIE on amd64
On Apr 02, 2014 04:54 PM +0200, Oliver Pinter wrote: On 4/2/14, Oliver Pinter oliver.p...@gmail.com wrote: On 3/31/14, Shawn Webb latt...@gmail.com wrote: On Mar 31, 2014 02:07 AM +0200, Oliver Pinter wrote: On 3/22/14, Shawn Webb latt...@gmail.com wrote: Hey All, First off, I hope that even as a non-committer, it's okay that I post a call for testing. If not, please excuse my newbishness in this process. This is my first time submitting a major patch upstream to FreeBSD. Over the past few months, I've had the opportunity and pleasure to enhance existing patches to FreeBSD that implement a common exploit mitigation technology called Address Space Layout Randomization (ASLR) along with support for Position Independent Executables (PIE). ASLR+PIE has been a long-requested feature by many people I've met on IRC. I've submitted my patch to PR kernel/181497. I'm currently in the process of adding PIE support to certain high-visibility applications in base (mainly network daemons). I've added a make.conf knob that's default to enabled (WITH_PIE=1). An application has to also explicitly support PIE as well by defining CAN_PIE in the Makefile prior to including bsd.prog.mk. After I get a decent amount of applications enabled with PIE support, I'll submit one last patch. The following sysctl's can be set with a kernel compiled with the PAX_ASLR option: security.pax.aslr.status: 1 security.pax.aslr.debug: 0 security.pax.aslr.mmap_len: 16 security.pax.aslr.stack_len: 12 security.pax.aslr.exec_len: 12 The security.pax.aslr.status sysctl enables and disables the ASLR system as a whole. The debug sysctl gives debugging output. The mmap_len sysctl tells the ASLR system how many bits to randomize with mmap() is called. The stack_len sysctl tells the ASLR system how many bits to randomize in the stack. The exec_len sysctl tells the ASLR system how many bits to randomize the execbase (this controls PIE). These sysctls can be set as a per-jail basis. If you have an application which doesn't support ASLR, yet you want ASLR enabled for everything else, you can simply place that misbehaving application in a jail with only that jail's ASLR settings turned off. Please let me know how your testing goes. I'm giving a presentation at BSDCan regarding this. If you want to keep tabs on my bleeding-edge development process, please follow my progress on GitHub: https://github.com/lattera/freebsd (branch: soldierx/lattera/aslr). Thank you very much, Hi! Please apply this patch. This fixed an issue with tunables. Patch merged successfully into my GitHub repo. Fixed with commit d2c0813. I'll include it in my next patch submission upstream when I submit my PIE work. Thanks! please see the attached patch, compile and boot tested on amd64 Some more patches, and one critical fix (0006-PAX-ASLR-use-the-right-sysent-before-this-commit-cal.patch). You are awesome. I'll integrate those patches today. In reviewing your patches, I noticed a few places where I'm keying off the local pax_aslr_debug variable. I ought to switch that to keying off the jail's pr_pax_aslr_debug variable. pgp_l2AgaRe3M.pgp Description: PGP signature
[head tinderbox] failure on powerpc/powerpc
TB --- 2014-04-02 12:51:25 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-02 12:51:25 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-02 12:51:25 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2014-04-02 12:51:25 - cleaning the object tree TB --- 2014-04-02 12:51:25 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-02 12:51:30 - At svn revision 264031 TB --- 2014-04-02 12:51:31 - building world TB --- 2014-04-02 12:51:31 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 12:51:31 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 12:51:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 12:51:31 - SRCCONF=/dev/null TB --- 2014-04-02 12:51:31 - TARGET=powerpc TB --- 2014-04-02 12:51:31 - TARGET_ARCH=powerpc TB --- 2014-04-02 12:51:31 - TZ=UTC TB --- 2014-04-02 12:51:31 - __MAKE_CONF=/dev/null TB --- 2014-04-02 12:51:31 - cd /src TB --- 2014-04-02 12:51:31 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Wed Apr 2 12:51:38 UTC 2014 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Apr 2 15:33:42 UTC 2014 TB --- 2014-04-02 15:33:42 - generating LINT kernel config TB --- 2014-04-02 15:33:42 - cd /src/sys/powerpc/conf TB --- 2014-04-02 15:33:42 - /usr/bin/make -B LINT TB --- 2014-04-02 15:33:42 - cd /src/sys/powerpc/conf TB --- 2014-04-02 15:33:42 - /obj/powerpc.powerpc/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-04-02 15:33:42 - building LINT kernel TB --- 2014-04-02 15:33:42 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 15:33:42 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 15:33:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 15:33:42 - SRCCONF=/dev/null TB --- 2014-04-02 15:33:42 - TARGET=powerpc TB --- 2014-04-02 15:33:42 - TARGET_ARCH=powerpc TB --- 2014-04-02 15:33:42 - TZ=UTC TB --- 2014-04-02 15:33:42 - __MAKE_CONF=/dev/null TB --- 2014-04-02 15:33:42 - cd /src TB --- 2014-04-02 15:33:42 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Apr 2 15:33:42 UTC 2014 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/iicbus/ds1374.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/iicbus/ds1672.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/iicbus/if_ic.c cc -c -O -pipe -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL
Re: make in dir
On Apr 2, 2014, at 6:15 AM, Konstantin Belousov kostik...@gmail.com wrote:
Hi,
it seems that recent changes to share/mk broke the ability to do anything
in subdir of the source tree. As example, on the HEAD r264012 installed
yesterday:
sandy% make
/usr/home/pooma/build/bsd/DEV/src/tools/regression/kqueue
make: /usr/share/mk/bsd.own.mk line 436: MK_MAN can't be set by a user.
I was able to recreate this with ‘make -m /blah-blah-blah -C
tools/regression/kqueue clean’
The important bit being -m. I have a fix that I’ll commit shortly.
Also, on stable/9 hosting the HEAD cross-env:
cd src MAKEOBJDIRPREFIX=/usr/home/kostik/build/bsd/DEV/obj-amd64
DESTDIR=/usr/home/kostik/build/bsd/DEV/netboot/sandy-amd64
SYSDIR=/usr/home/kostik/build/bsd/DEV/src/sys TARGET=amd64 make buildenv
Entering world for amd64:amd64
# cd share/mk
# make install
bsd.own.mk, line 435: Malformed conditional (${.MAKE.LEVEL} == 0)
bsd.own.mk, line 436: MK_PROFILE can't be set by a user.
This will happen with fmake. I’ve put some safety belts in place in another fix
to keep this from tripping people up (and plan on using a similar technique
to keep people from hitting the aicasm bug on such systems).
Warner
___
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: kevent has bug?
Konstantin Belousov wrote this message on Wed, Apr 02, 2014 at 15:07 +0300:
On Wed, Apr 02, 2014 at 04:06:16PM +0900, Kohji Okuno wrote:
From: John-Mark Gurney j...@funkthat.com
Date: Tue, 1 Apr 2014 23:15:51 -0700
Kohji Okuno wrote this message on Wed, Apr 02, 2014 at 11:45 +0900:
I think, kevent() has a bug.
I tested sample programs by attached sources.
This sample tests about EVFILT_SIGNAL.
I build sample programs by the following commands.
% gcc -O2 -o child child.c
% gcc -O2 -o parent parent.c
The expected result is the following.
% ./parent
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
OK
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
OK
But, sometimes the result was the following.
% ./parent
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
This result means the number of times the signal has occured was
incorrect.
I was able to reproduce this...
In case of EVFILT_SIGNAL, according to `man kevent', `data' retuns the
number of times the signal has occurred since the last call to
kevent(). This `data' is recorded by filt_signal() (This is f_event in
struct filterops).
The system call kevent()'s events are processed by kqueue_scan() in
kern_event.c. In kqueue_scan(), kn-kn_fop-f_event() is allways
called after KN_INFLUX is set to kn-kn_status.
On the other hand, kernel events are occured by knote() in
kern_event.c. (In EVFILT_SIGNAL, knote() is called from tdsendsignal()
in kern_sig.c.) In knote(), kn-kn_fop-f_event() is called only when
KN_INFLUX is not set in kn-kn_status.
In race condition between kqueue_scan() and knote(),
kn-kn_fop-f_event() from knote() may not be called, I think.
Looks like I misunderstood your point, sorry...
Considering that both are called w/ a lock, that cannot happen..
KN_LIST_LOCK(kn) locks the same lock that is asserted that is held
by knote...
In knote(), because the context holds knlist's lock, the context can
not sleep. So, KN_INFLUX should not be set on calling
kn-kn_fop-f_event() in kqueue_scan(), I think.
No, it needs to be set:
* Setting the KN_INFLUX flag enables you to unlock the kq that this knote
* is on, and modify kn_status as if you had the KQ lock.
As this comment says, _INFLUX allows you to unlock the KQ w/o fear that
the knote will disappear out from under you causing you to dereference
possibly free'd memory..
If you just tried to lock the list lock w/o unlocking the KQ lock, you
could end up w/ a dead lock, as you aren't maintaining lock order
properly.. The correct lock order if knlist - kq...
What do you think about this issue?
This is a real issue, but not due to the race you described
above...
I beleave it's the result of the race.
Could you try to add printf() in knote()?
Please refer to attached patch.
I have verified on my machine that it isn't because there is a knote
waiting that isn't getting woken up, and the knote on my hung process
has data == 0, so it definately lost one of the signals:
(kgdb) print $14.kq_knhash[20].slh_first[0]
$20 = {kn_link = {sle_next = 0x0}, kn_selnext = {sle_next = 0x0},
kn_knlist = 0xf8005a9c5840, kn_tqe = {tqe_next = 0xf801fdab4500,
tqe_prev = 0xf8004bb10038}, kn_kq = 0xf8004bb1, kn_kevent
= {
ident = 20, filter = -6, flags = 32, fflags = 0, data = 0, udata =
0x0},
kn_status = 0, kn_sfflags = 0, kn_sdata = 0, kn_ptr = {
p_fp = 0xf8005a9c54b8, p_proc = 0xf8005a9c54b8,
p_aio = 0xf8005a9c54b8, p_lio = 0xf8005a9c54b8,
p_v = 0xf8005a9c54b8}, kn_fop = 0x81405ef0, kn_hook = 0x0,
kn_hookid = 0}
If you want to find this yourself, you can run kgdb on a live system,
switch to the thread of the parent (info threads, thread XXX), and
do:
frame 7
(or a frame that has td, which is struct thread *), then:
print *(struct kqueue
*)td-td_proc[0].p_fd[0].fd_ofiles[3].fde_file[0].f_data
This will give you the struct kqueue * of the parent, and then:
print $XX.kq_knhash[0]@63
to figure out where the knote is in the hash, and then you can print
it out yourself...
I'm going to take a look at this a bit more later... I'm thinking of
using dtrace to collect the stacks where filt_signal is called, and
match them up... dtrace might even be able to get us the note's data
upon return helping to make sure things got tracked properly...
Thanks for finding this bug! Hopefully we can find a solution to it..
diff --git a/sys/kern/kern_event.c b/sys/kern/kern_event.c
index b3fb23d..7791447 100644
--- a/sys/kern/kern_event.c
+++ b/sys/kern/kern_event.c
@@ -1868,6 +1868,8 @@ knote(struct knlist *list, long hint, int lockflags)
if ((kn-kn_status KN_INFLUX) != KN_INFLUX) {
Re: ZFS panic in -CURRENT
On Wed, 02 Apr 2014 09:58:37 +0300 Andriy Gapon a...@freebsd.org wrote: on 01/04/2014 16:57 R. Tyler Croy said the following: On Tue, 01 Apr 2014 09:41:45 +0300 Andriy Gapon a...@freebsd.org wrote: on 01/04/2014 02:22 R. Tyler Croy said the following: ... Also in addition to the photo from before of the panic, here's another reproduction photo: https://www.flickr.com/photos/agentdero/13472248423/ Are you or have you even been running with any ZFS-related kernel patches? Negative, I've never run any specific ZFS patches on this machine (or any machine for that matter!) One other unique clue might be that I'm running with an encrypted zpool, other than that, nothing fancy here. Your problem looks like a corruption of on-disk data. I can not say how it came to be or how to fix it now. This is concerning to me, I'm using an intel 128GB SSD which is less than 6 months old. If there is an actual disk-level corruption, shouldn't that manifest itself as a zpool error? :/ -- - R. Tyler Croy -- Code: https://github.com/rtyler Chatter: https://twitter.com/agentdero % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F -- ___ 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: Adding Encryption Algorithm to Kernel
Shady Elhamy wrote this message on Wed, Apr 02, 2014 at 13:00 +0200: I am working on a project and i want to add an encryption algorithm to freeBSD kernel. Well, what are you going to do with the algorithm? and what algorithm are you trying to add? Currently we have two interfaces for algorithms... The OpenCrypto framework designed for allowing providers to be abstracted out such that they can be accelerated... And of course the direct call interface, which implies that it will not need acceleration (only one or two blocks processed at a time)... In that case, just adding it as another KPI is easiest... What are the steps ? Which files should i change ? I have searched the internet and the forums and mailing lists, but couldn't find anything. I was hoping you could help me out. I'm doing work right now to add AES-GCM and a couple other algorithms to OpenCrypto... If you let me know more about what you're trying to do, I'll help you.. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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
login.conf -- UTF-8
I'd like to make this change to login.conf for default installs. This removes some amount of hackery in the ports system that is working around our lack of UTF-8 in the base. This should be step 0 in a language agnostic installer project that is beyond the scope of making the system more useable. --- login.conf 2013-10-21 15:51:14.553992170 -0700 +++ /etc/login.conf 2014-03-31 09:26:17.588503798 -0700 @@ -45,7 +45,9 @@ :kqueues=unlimited:\ :priority=0:\ :ignoretime@:\ - :umask=022: + :umask=022:\ + :lang=en_US.UTF-8:\ + :charset=UTF-8: # signature.asc Description: This is a digitally signed message part
Re: login.conf -- UTF-8
Sean, On Wed, Apr 02, 2014 at 09:53:49AM -0700, Sean Bruno wrote: S I'd like to make this change to login.conf for default installs. S S This removes some amount of hackery in the ports system that is working S around our lack of UTF-8 in the base. S S This should be step 0 in a language agnostic installer project that is S beyond the scope of making the system more useable. S S S --- login.conf 2013-10-21 15:51:14.553992170 -0700 S +++ /etc/login.conf 2014-03-31 09:26:17.588503798 -0700 S @@ -45,7 +45,9 @@ S :kqueues=unlimited:\ S :priority=0:\ S :ignoretime@:\ S -:umask=022: S +:umask=022:\ S +:lang=en_US.UTF-8:\ S +:charset=UTF-8: And I'd like to do same change for the 'russian' login class in /etc/login.conf. I've got a few things that still need to be fixed, before this change, but I definitely target to achieve that before stable/11. -- Totus tuus, Glebius. ___ 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: Leaving the Desktop Market
On Wed, Apr 2, 2014 at 5:24 AM, Jordan Hubbard j...@ixsystems.com wrote: On Apr 1, 2014, at 10:11 PM, Matt Olander m...@ixsystems.com wrote: This is like trying to predict automobile technology and dominant car-makers by 1905. There's always room for competition. Take a look at what's happening right now in the auto-industry. Tesla came out of nowhere 125 years after the invention of the automobile and is doing pretty well. I think you're kind of making my point for me, Matt. :-) Tesla benefitted entirely from deep pockets on the part of its investors. Over $160M went into starting the company, of which $70M came from the personal checking account of Elon Musk, the current visionary and CEO, and to quote the wikipedia page: Tesla Motors is a public company that trades on the NASDAQ stock exchange under the symbol TSLA.[5] In the first quarter of 2013, Tesla posted profits for the first time in its ten year history. Yep, in other words, Tesla has been losing money for over 10 years and only just started turning a profit, after raising a mere $187M in investment and $485M in loans from the US DOE. Your tax dollars at work! On top of all that Tesla has only managed to make money at all by focusing exclusively the highest end of the luxury car market, where profit margins are also the highest (the first car, the roadster, would set you back $110,000). Getting back to computer operating systems, it would make most readers of these lists choke on their Doritos to know how much Apple had to invest in Mac OS X before it became a viable desktop operating system and of course you've already seen folks screaming about how Apple gear is too expensive and they'll never buy it. You just don't get a consumer-grade desktop Unix OS, or a practical all-electric sedan, without serious monetary investment and a luxury marquee to match, assuming you'd like to actually make any of that money *back*. So, back to BSD on the desktop. Anyone got a spare $200M they'd like to just throw away? That's what it's going to take! :) Don't believe me? Go ask someone who knows first-hand then. Ask Mark Shuttleworth: http://arstechnica.com/information-technology/2013/08/why-ubuntus-creator-still-invests-his-fortune-in-an-unprofitable-company/ Yeah, no doubt it will cost a bit of money to compete on that level. However, have you ever heard the phrase pioneers suffer where settlers prosper? Meaning it may (or may not!) take significantly less to compete once a lot of the harder problems are solved. If we take the fact that PCs are on the decline but device adoption is on the rise, perhaps we could focus on an Android competitor (*cough* Cyb0rg *cough). Wouldn't it be possible to run Android apps on *BSD via a java vm? I will get you an Ubuntu phone for Christmas and we can try it :P -matt P.S., I do not have 200 million but I'm good for 10k :P ___ 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: kevent has bug?
On Wed, Apr 02, 2014 at 09:45:43AM -0700, John-Mark Gurney wrote:
Konstantin Belousov wrote this message on Wed, Apr 02, 2014 at 15:07 +0300:
Well, it's not that its preventing waking up the waiter, but failing to
register the event on the knote because of the _INFLUX flag...
Yes, I used the wrong terminology.
Patch below fixed your test case for me, also tools/regression/kqueue did
not noticed a breakage. I tried to describe the situation in the
comment in knote(). Also, I removed unlocked check for the KN_INFLUX
in knote, since it seems to be an optimization for rare case, and is
the race on its own.
Comments below...
diff --git a/sys/kern/kern_event.c b/sys/kern/kern_event.c
index b3fb23d..380f1ff 100644
--- a/sys/kern/kern_event.c
+++ b/sys/kern/kern_event.c
[...]
@@ -1506,7 +1506,7 @@ retry:
KQ_LOCK(kq);
kn = NULL;
} else {
- kn-kn_status |= KN_INFLUX;
+ kn-kn_status |= KN_INFLUX | KN_SCAN;
KQ_UNLOCK(kq);
if ((kn-kn_status KN_KQUEUE) == KN_KQUEUE)
KQ_GLOBAL_LOCK(kq_global, haskqglobal);
Is there a reason you don't add the KN_SCAN to the other cases in
kqueue_scan that set the _INFLUX flag?
Other cases in kqueue_scan() which set influx do the detach and drop,
so I do not see a need to ensure that note is registered. Except I missed
one case, which you pointed out.
[...]
@@ -1865,28 +1866,33 @@ knote(struct knlist *list, long hint, int lockflags)
*/
SLIST_FOREACH(kn, list-kl_list, kn_selnext) {
kq = kn-kn_kq;
- if ((kn-kn_status KN_INFLUX) != KN_INFLUX) {
+ KQ_LOCK(kq);
+ if ((kn-kn_status (KN_INFLUX | KN_SCAN)) == KN_INFLUX) {
+ /*
+* Do not process the influx notes, except for
+* the influx coming from the kq unlock in the
+* kqueue_scan(). In the later case, we do
+* not interfere with the scan, since the code
+* fragment in kqueue_scan() locks the knlist,
+* and cannot proceed until we finished.
+*/
We might want to add a marker node, and reprocess the list from the
marker node, because this might introduce other races in the code too...
but the problem with that is that knote is expected to keep the list
locked throughout the call if called w/ it already locked, and so we
can't do that, without major work... :(
Why ? If the knlist lock is not dropped, I do not see a need for the
marker. The patch does not introduce the sleep point for the KN_SCAN
knotes anyway.
I added a similar comment in knote_fork:
* XXX - Why do we skip the kn if it is _INFLUX? Does this
* mean we will not properly wake up some notes?
and it looks like it was true...
So, upon reading the other _INFLUX cases, it looks like we should change
_SCAN to be, _CHANGING or something similar, and any place we don't end
up dropping the knote, we set this flag also... Once such case is at
the end of kqueue_register, just before the label done_ev_add, where we
update the knote w/ new udata and other fields.. Or change the logic
of the flag, and set it for all the cases we are about to drop the
knote..
So do you prefer KN_CHANGING instead of KN_SCAN ? I do not have any
objections against renaming the flag, but _CHANGING seems to not say
anything about the flag intent. I would say that KN_STABLE is more
useful, or KN_INFLUX_NODEL, or whatever.
The done_ev_add case is indeed missed in my patch, thank you for noting.
The case of EV_ADD does not need the KN_SCAN workaround, IMO, since the
race is possible just by the nature of adding the knote.
+ KQ_UNLOCK(kq);
+ } else if ((lockflags KNF_NOKQLOCK) != 0) {
+ kn-kn_status |= KN_INFLUX;
+ KQ_UNLOCK(kq);
+ error = kn-kn_fop-f_event(kn, hint);
KQ_LOCK(kq);
I believe we can drop this unlock/lock pair as it's safe to hold the
KQ lock over f_event, we do that in knote_fork...
The knote_fork() is for the special kinds of knote only, where we indeed know
in advance that having the kqueue locked around f_event does not break things.
Updated patch below.
diff --git a/sys/kern/kern_event.c b/sys/kern/kern_event.c
index b3fb23d..fadb8fd 100644
--- a/sys/kern/kern_event.c
+++ b/sys/kern/kern_event.c
@@ -474,7 +474,7 @@ knote_fork(struct knlist *list, int pid)
continue;
kq = kn-kn_kq;
KQ_LOCK(kq);
- if ((kn-kn_status KN_INFLUX) == KN_INFLUX) {
+ if ((kn-kn_status (KN_INFLUX | KN_SCAN)) == KN_INFLUX) {
KQ_UNLOCK(kq);
continue;
Re: make in dir
On Wed, Apr 02, 2014 at 09:46:34AM -0600, Warner Losh wrote:
On Apr 2, 2014, at 6:15 AM, Konstantin Belousov kostik...@gmail.com wrote:
Hi,
it seems that recent changes to share/mk broke the ability to do anything
in subdir of the source tree. As example, on the HEAD r264012 installed
yesterday:
sandy% make
/usr/home/pooma/build/bsd/DEV/src/tools/regression/kqueue
make: /usr/share/mk/bsd.own.mk line 436: MK_MAN can't be set by a user.
I was able to recreate this with ?make -m /blah-blah-blah -C
tools/regression/kqueue clean?
The important bit being -m. I have a fix that I?ll commit shortly.
Also, on stable/9 hosting the HEAD cross-env:
cd src MAKEOBJDIRPREFIX=/usr/home/kostik/build/bsd/DEV/obj-amd64
DESTDIR=/usr/home/kostik/build/bsd/DEV/netboot/sandy-amd64
SYSDIR=/usr/home/kostik/build/bsd/DEV/src/sys TARGET=amd64 make buildenv
Entering world for amd64:amd64
# cd share/mk
# make install
bsd.own.mk, line 435: Malformed conditional (${.MAKE.LEVEL} == 0)
bsd.own.mk, line 436: MK_PROFILE can't be set by a user.
This will happen with fmake. I?ve put some safety belts in place in another
fix
to keep this from tripping people up (and plan on using a similar technique
to keep people from hitting the aicasm bug on such systems).
I noted that this is from stable/9-hosted buildenv. Shouldn't buildenv
mangle the path to select and possibly build bmake if needed ?
Anyway, your recent commits seems to fix my problems, thank you.
pgp8b5xlXmaJB.pgp
Description: PGP signature
Re: make in dir
On Apr 2, 2014, at 12:15 PM, Konstantin Belousov kostik...@gmail.com wrote:
On Wed, Apr 02, 2014 at 09:46:34AM -0600, Warner Losh wrote:
On Apr 2, 2014, at 6:15 AM, Konstantin Belousov kostik...@gmail.com wrote:
Hi,
it seems that recent changes to share/mk broke the ability to do anything
in subdir of the source tree. As example, on the HEAD r264012 installed
yesterday:
sandy% make
/usr/home/pooma/build/bsd/DEV/src/tools/regression/kqueue
make: /usr/share/mk/bsd.own.mk line 436: MK_MAN can't be set by a user.
I was able to recreate this with ?make -m /blah-blah-blah -C
tools/regression/kqueue clean?
The important bit being -m. I have a fix that I?ll commit shortly.
Also, on stable/9 hosting the HEAD cross-env:
cd src MAKEOBJDIRPREFIX=/usr/home/kostik/build/bsd/DEV/obj-amd64
DESTDIR=/usr/home/kostik/build/bsd/DEV/netboot/sandy-amd64
SYSDIR=/usr/home/kostik/build/bsd/DEV/src/sys TARGET=amd64 make buildenv
Entering world for amd64:amd64
# cd share/mk
# make install
bsd.own.mk, line 435: Malformed conditional (${.MAKE.LEVEL} == 0)
bsd.own.mk, line 436: MK_PROFILE can't be set by a user.
This will happen with fmake. I?ve put some safety belts in place in another
fix
to keep this from tripping people up (and plan on using a similar technique
to keep people from hitting the aicasm bug on such systems).
I noted that this is from stable/9-hosted buildenv. Shouldn't buildenv
mangle the path to select and possibly build bmake if needed ?
Yea, I would have thought so...
Anyway, your recent commits seems to fix my problems, thank you.
You are welcome. Don’t hesitate to give a yell if you discover other
problems…
Warner
___
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: ZFS panic in -CURRENT
on 02/04/2014 19:48 R. Tyler Croy said the following: On Wed, 02 Apr 2014 09:58:37 +0300 Andriy Gapon a...@freebsd.org wrote: on 01/04/2014 16:57 R. Tyler Croy said the following: On Tue, 01 Apr 2014 09:41:45 +0300 Andriy Gapon a...@freebsd.org wrote: on 01/04/2014 02:22 R. Tyler Croy said the following: ... Also in addition to the photo from before of the panic, here's another reproduction photo: https://www.flickr.com/photos/agentdero/13472248423/ Are you or have you even been running with any ZFS-related kernel patches? Negative, I've never run any specific ZFS patches on this machine (or any machine for that matter!) One other unique clue might be that I'm running with an encrypted zpool, other than that, nothing fancy here. Your problem looks like a corruption of on-disk data. I can not say how it came to be or how to fix it now. This is concerning to me, I'm using an intel 128GB SSD which is less than 6 months old. If there is an actual disk-level corruption, shouldn't that manifest itself as a zpool error? I am afraid that this is a different kind of corruption. Either a bug (possibly old, already fixes) in ZFS or a corruption that happened in RAM before a buffer was sent to a disk. -- 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: login.conf -- UTF-8
On Wed, 02 Apr 2014 09:53:49 -0700, Sean Bruno sbr...@ignoranthack.me wrote: I'd like to make this change to login.conf for default installs. This removes some amount of hackery in the ports system that is working around our lack of UTF-8 in the base. This should be step 0 in a language agnostic installer project that is beyond the scope of making the system more useable. --- login.conf2013-10-21 15:51:14.553992170 -0700 +++ /etc/login.conf 2014-03-31 09:26:17.588503798 -0700 @@ -45,7 +45,9 @@ :kqueues=unlimited:\ :priority=0:\ :ignoretime@:\ - :umask=022: + :umask=022:\ + :lang=en_US.UTF-8:\ + :charset=UTF-8: # Changing the default LC_COLLATE is risky, how about keeping LC_COLLATE=C by default? --- /usr/src/etc/login.conf 2013-09-30 19:04:24.0 + +++ /etc/login.conf 2013-09-30 19:02:22.0 + @@ -26,7 +26,7 @@ :passwd_format=sha512:\ :copyright=/etc/COPYRIGHT:\ :welcome=/etc/motd:\ - :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ + :setenv=MAIL=/var/mail/$,BLOCKSIZE=K,LC_COLLATE=C:\ :path=/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin /usr/local/bin ~/bin:\ :nologin=/var/run/nologin:\ :cputime=unlimited:\ @@ -44,7 +44,9 @@ :pseudoterminals=unlimited:\ :priority=0:\ :ignoretime@:\ - :umask=022: + :umask=022:\ + :charset=UTF-8:\ + :lang=en_US.UTF-8: # -- Benjamin Lee http://www.b1c1l1.com/ signature.asc Description: PGP signature
gcc compilation broken with SVN r264042
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Seems that GCC doesn't like/understand the cast .. imb@mail:/usr/src/lib/libc sudo make cc -O2 -pipe -march=pentium4 -I/usr/src/lib/libc/include - -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS - -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa - -I/usr/src/lib/libc/../../contrib/libc-vis -DINET6 - -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE - -DPOSIX_MISTAKE -I/usr/src/lib/libc/../../contrib/jemalloc/include - -DMALLOC_PRODUCTION -I/usr/src/lib/libc/../../contrib/tzcode/stdtime - -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES - -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING - -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers - -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libc/stdlib/atexit.c -o atexit.o /usr/src/lib/libc/stdlib/atexit.c: In function 'atexit_b': /usr/src/lib/libc/stdlib/atexit.c:157: error: cannot convert to a pointer type *** Error code 1 Stop. make: stopped in /usr/src/lib/libc -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlM8YbcACgkQQv9rrgRC1JIucgCfRPm79qcKX9XpAfazKfGRsOry lOAAnRiHdpdRzLS5MtC7YPOsNeWZtiBS =2y7B -END PGP SIGNATURE- ___ 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
r264048 broke kernel build
r264048 breaks kernel build ( sys/kern/kern_et.c) , r264047 builds perfectly ... rm -f .newdep make -V CFILES_NOZFS -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP=cc -E CC=cc xargs mkdep -a -f .newdep -pipe -O3 -fno-strict-aliasing -march=native -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb -I/usr/src/sys/dev/cxgbe -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector /usr/src/sys/kern/kern_et.c:37:10: fatal error: 'opt_timer.h' file not found #include opt_timer.h signature.asc Description: PGP signature
Re: r264048 broke kernel build
On Wed, Apr 2, 2014 at 7:16 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: r264048 breaks kernel build ( sys/kern/kern_et.c) , r264047 builds perfectly ... +1. cheers, Hiren rm -f .newdep make -V CFILES_NOZFS -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP=cc -E CC=cc xargs mkdep -a -f .newdep -pipe -O3 -fno-strict-aliasing -march=native -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb -I/usr/src/sys/dev/cxgbe -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector /usr/src/sys/kern/kern_et.c:37:10: fatal error: 'opt_timer.h' file not found #include opt_timer.h ___ 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: r264048 broke kernel build
+ Ian On Wed, Apr 2, 2014 at 7:17 PM, hiren panchasara hiren.panchas...@gmail.com wrote: On Wed, Apr 2, 2014 at 7:16 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: r264048 breaks kernel build ( sys/kern/kern_et.c) , r264047 builds perfectly ... +1. cheers, Hiren rm -f .newdep make -V CFILES_NOZFS -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP=cc -E CC=cc xargs mkdep -a -f .newdep -pipe -O3 -fno-strict-aliasing -march=native -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb -I/usr/src/sys/dev/cxgbe -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector /usr/src/sys/kern/kern_et.c:37:10: fatal error: 'opt_timer.h' file not found #include opt_timer.h ___ 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: login.conf -- UTF-8
On Wed, Apr 2, 2014 at 6:53 PM, Sean Bruno sbr...@ignoranthack.me wrote: I'd like to make this change to login.conf for default installs. This removes some amount of hackery in the ports system that is working around our lack of UTF-8 in the base. This should be step 0 in a language agnostic installer project that is beyond the scope of making the system more useable. --- login.conf 2013-10-21 15:51:14.553992170 -0700 +++ /etc/login.conf 2014-03-31 09:26:17.588503798 -0700 @@ -45,7 +45,9 @@ :kqueues=unlimited:\ :priority=0:\ :ignoretime@:\ - :umask=022: + :umask=022:\ + :lang=en_US.UTF-8:\ + :charset=UTF-8: Hi, Don't forget to request an exp-run from portmgr before committing this change, we never know what can break. Cheers, Antoine ___ 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: gcc compilation broken with SVN r264042
Hi,
I'm trying to reproduce this, but I don't seem to be able to get the same error
as you. I do get a warning with GCC about a cast to an anonymous struct, which
the attached patch fixes, but even without this I'm able to build both with the
gcc in 9 and the gcc in ports. Can you let me know your gcc version?
Unfortunately, the gcc error reporting isn't very helpful, so I don't know what
it thinks it can't convert to a pointer type. It would be great if you could
try this patch, and if that doesn't fix it then try splitting the casts and
dereferences into separate lines and see which part of this it is the gcc
doesn't like.
David
Index: include/block_abi.h
===
--- include/block_abi.h (revision 264042)
+++ include/block_abi.h (working copy)
@@ -50,14 +50,16 @@
} *name
#define CALL_BLOCK(name, ...) (name)-invoke(name, __VA_ARGS__)
#endif // __BLOCKS__
+struct generic_block
+{
+ void *isa;
+ int flags;
+ int reserved;
+ void (*invoke)(void *, ...);
+};
/**
* Returns the pointer to the block-invoke function. This is used for passing
* blocks to functions that want a function pointer and a data pointer.
*/
#define GET_BLOCK_FUNCTION(x) \
- (((struct {\
- void *isa;\
- int flags;\
- int reserved;\
- void (*invoke)(void *, ...);\
- }*)x)-invoke)
+ (((struct generic_block*)x)-invoke)
On 2 Apr 2014, at 20:15, Michael Butler i...@protected-networks.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Seems that GCC doesn't like/understand the cast ..
imb@mail:/usr/src/lib/libc sudo make
cc -O2 -pipe -march=pentium4 -I/usr/src/lib/libc/include
- -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS
- -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa
- -I/usr/src/lib/libc/../../contrib/libc-vis -DINET6
- -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE
- -DPOSIX_MISTAKE -I/usr/src/lib/libc/../../contrib/jemalloc/include
- -DMALLOC_PRODUCTION -I/usr/src/lib/libc/../../contrib/tzcode/stdtime
- -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES
- -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING
- -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers
- -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c
/usr/src/lib/libc/stdlib/atexit.c -o atexit.o
/usr/src/lib/libc/stdlib/atexit.c: In function 'atexit_b':
/usr/src/lib/libc/stdlib/atexit.c:157: error: cannot convert to a
pointer type
*** Error code 1
Stop.
make: stopped in /usr/src/lib/libc
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iEYEARECAAYFAlM8YbcACgkQQv9rrgRC1JIucgCfRPm79qcKX9XpAfazKfGRsOry
lOAAnRiHdpdRzLS5MtC7YPOsNeWZtiBS
=2y7B
-END PGP SIGNATURE-
___
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
Build failed in Jenkins: FreeBSD_HEAD #388
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/388/changes Changes: [ian] Fix build breakage. Apparently all ARM configs build kern_et.c, but only a few of them also build kern_clocksource.c. That strikes me as insane, but maybe there's a good reason for it. Until I figure that out, un-break the build by not referencing functions in kern_clocksource if NO_EVENTTIMERS is defined. [gjb] Use xz(1) instead of gzip(1) to compress release images when WITH_COMPRESSED_IMAGES is used. Requested by: delphij, brooks, Nikolai Lifanov MFC After: 1 week X-MFC-With: r264027,r264028,r264029,r264030 Sponsored by: The FreeBSD Foundation [imp] Move setting of the MK_xxx variables based on NO_xxx to avoid triggering the you aren't allowed to set this warning when building stand alone in directories whose Makefile sets NO_MAN, for example. [imp] FreeBSD make (aka fmake) doesn't grok .MAKE.LEVEL. Failsafe and assume that it is OK to set MK_xxx flags. [theraven] Move scandir_b to a later symbol version. [theraven] Add support for some block functions that come from OS X. These are intended to build with any C compiler. Reviewed by:pfg MFC after: 3 weeks [ian] Add support for event timers whose clock frequency can change while running. [pfg] MFV r258379; 4248 dtrace(1M) should never create DOF with empty probes section 4249 Only probes from the first DTrace object file will be included Illumos Revision: 4a20ab41aadcb81c53e72fc65886e964e9add59 Reference: https://www.illumos.org/issues/4248 https://www.illumos.org/issues/4249 Obtained from: Illumos MFC after: 1 month -- [...truncated 219226 lines...] --- .depend --- rm -f .depend CC='cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC -std=iso9899:1999 iwn5150fw.c === iwnfw/iwn6000 (depend) --- /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC/modules/builds/FreeBSD_HEAD/sys/modules/iwnfw/iwn6000/@ --- --- /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC/modules/builds/FreeBSD_HEAD/sys/modules/iwnfw/iwn6000/machine --- --- /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC/modules/builds/FreeBSD_HEAD/sys/modules/iwnfw/iwn6000/x86 --- --- /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC/modules/builds/FreeBSD_HEAD/sys/modules/iwnfw/iwn6000/@ --- @ - https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys --- /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC/modules/builds/FreeBSD_HEAD/sys/modules/iwnfw/iwn6000/machine --- machine - https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/amd64/include --- /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC/modules/builds/FreeBSD_HEAD/sys/modules/iwnfw/iwn6000/x86 --- x86 - https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/x86/include --- iwn6000fw.c --- awk -f @/tools/fw_stub.awk iwlwifi-6000-9.221.4.1.fw:iwn6000fw -miwn6000fw -ciwn6000fw.c --- .depend --- rm -f .depend CC='cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC -std=iso9899:1999 iwn6000fw.c === iwnfw/iwn6000g2a (depend) --- /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC/modules/builds/FreeBSD_HEAD/sys/modules/iwnfw/iwn6000g2a/@ --- --- /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC/modules/builds/FreeBSD_HEAD/sys/modules/iwnfw/iwn6000g2a/machine --- --- /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC/modules/builds/FreeBSD_HEAD/sys/modules/iwnfw/iwn6000g2a/x86 --- --- /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC/modules/builds/FreeBSD_HEAD/sys/modules/iwnfw/iwn6000g2a/@ --- @ - https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys --- /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC/modules/builds/FreeBSD_HEAD/sys/modules/iwnfw/iwn6000g2a/machine --- machine - https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/amd64/include --- /usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC/modules/builds/FreeBSD_HEAD/sys/modules/iwnfw/iwn6000g2a/x86 --- x86 - https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/x86/include --- iwn6000g2afw.c --- awk -f @/tools/fw_stub.awk iwlwifi-6000g2a-18.168.6.1.fw:iwn6000g2afw -miwn6000g2afw -ciwn6000g2afw.c --- .depend --- rm -f .depend CC='cc ' mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I/usr/objhttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/sys/GENERIC -std=iso9899:1999
Re: r264048 broke kernel build
Sorry about that, hopefully I've fixed it for now with r264054 (but whenever you're checking in a fix for a fix you're on pretty shakey ground). This is a temporary workaround while I spend a few days rewriting some legacy arm code to fix the problem for real. -- Ian On Wed, 2014-04-02 at 19:18 +, hiren panchasara wrote: + Ian On Wed, Apr 2, 2014 at 7:17 PM, hiren panchasara hiren.panchas...@gmail.com wrote: On Wed, Apr 2, 2014 at 7:16 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: r264048 breaks kernel build ( sys/kern/kern_et.c) , r264047 builds perfectly ... +1. cheers, Hiren rm -f .newdep make -V CFILES_NOZFS -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP=cc -E CC=cc xargs mkdep -a -f .newdep -pipe -O3 -fno-strict-aliasing -march=native -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/cxgb -I/usr/src/sys/dev/cxgbe -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector /usr/src/sys/kern/kern_et.c:37:10: fatal error: 'opt_timer.h' file not found #include opt_timer.h ___ 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: gcc compilation broken with SVN r264042
On 04/02/14 15:30, David Chisnall wrote: I'm trying to reproduce this, but I don't seem to be able to get the same error as you. I do get a warning with GCC about a cast to an anonymous struct, which the attached patch fixes, but even without this I'm able to build both with the gcc in 9 and the gcc in ports. Can you let me know your gcc version? Unfortunately, the gcc error reporting isn't very helpful, so I don't know what it thinks it can't convert to a pointer type. It would be great if you could try this patch, and if that doesn't fix it then try splitting the casts and dereferences into separate lines and see which part of this it is the gcc doesn't like. This is .. cc (GCC) 4.2.1 20070831 patched [FreeBSD] .. on .. FreeBSD 11.0-CURRENT #22 r263969: Mon Mar 31 10:45:56 EDT 2014 Splitting it like .. - fn.fn_ptr.cxa_func = (void(*)(void*))GET_BLOCK_FUNCTION(func); + fn.fn_ptr.cxa_func = + (void(*)(void*)) + GET_BLOCK_FUNCTION(func); .. causes the reported error to point at the GET_BLOCK_FUNCTION. I guess it's time for me to migrate that box to clang :-) imb ___ 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: gcc compilation broken with SVN r264042
On 2 Apr 2014, at 20:53, Michael Butler i...@protected-networks.net wrote: cc (GCC) 4.2.1 20070831 patched [FreeBSD] .. on .. FreeBSD 11.0-CURRENT #22 r263969: Mon Mar 31 10:45:56 EDT 2014 Splitting it like .. - fn.fn_ptr.cxa_func = (void(*)(void*))GET_BLOCK_FUNCTION(func); + fn.fn_ptr.cxa_func = + (void(*)(void*)) + GET_BLOCK_FUNCTION(func); .. causes the reported error to point at the GET_BLOCK_FUNCTION. Sorry, I meant split it into different statements. Along the lines of: struct generic_block *b = (struct generic_block*)func; void (*fn)(void*,...) = b-invoke; fn.fn_ptr.cxa_func = (void (*)(void*))fn; I guess it's time for me to migrate that box to clang :-) Well, I wouldn't object to that, but it would be good to fix this - we still want to be able to build the base system with gcc (or another compiler), even if we don't encourage it... David ___ 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: gcc compilation broken with SVN r264042
On Wed, Apr 02, 2014 at 08:58:21PM +0100, David Chisnall wrote: Well, I wouldn't object to that, but it would be good to fix this - we still want to be able to build the base system with gcc (or another compiler), even if we don't encourage it... Who is we in even if we don't encourage it...? In fact, this is a fairly dumb idea, and *we* should encourage building the base system with as many different compilers as possible. It's called portability and allows one to find bugs that the annointed compiler might miss or actually cause. -- Steve ___ 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
[head tinderbox] failure on arm/arm
TB --- 2014-04-02 17:00:23 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-02 17:00:23 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-02 17:00:23 - starting HEAD tinderbox run for arm/arm TB --- 2014-04-02 17:00:23 - cleaning the object tree TB --- 2014-04-02 17:02:59 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-02 17:03:02 - At svn revision 264046 TB --- 2014-04-02 17:03:03 - building world TB --- 2014-04-02 17:03:03 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 17:03:03 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 17:03:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 17:03:03 - SRCCONF=/dev/null TB --- 2014-04-02 17:03:03 - TARGET=arm TB --- 2014-04-02 17:03:03 - TARGET_ARCH=arm TB --- 2014-04-02 17:03:03 - TZ=UTC TB --- 2014-04-02 17:03:03 - __MAKE_CONF=/dev/null TB --- 2014-04-02 17:03:03 - cd /src TB --- 2014-04-02 17:03:03 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Wed Apr 2 17:03:10 UTC 2014 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Apr 2 20:18:40 UTC 2014 TB --- 2014-04-02 20:18:40 - generating LINT kernel config TB --- 2014-04-02 20:18:40 - cd /src/sys/arm/conf TB --- 2014-04-02 20:18:40 - /usr/bin/make -B LINT TB --- 2014-04-02 20:18:40 - cd /src/sys/arm/conf TB --- 2014-04-02 20:18:40 - /obj/arm.arm/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-04-02 20:18:40 - building LINT kernel TB --- 2014-04-02 20:18:40 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 20:18:40 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 20:18:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 20:18:40 - SRCCONF=/dev/null TB --- 2014-04-02 20:18:40 - TARGET=arm TB --- 2014-04-02 20:18:40 - TARGET_ARCH=arm TB --- 2014-04-02 20:18:40 - TZ=UTC TB --- 2014-04-02 20:18:40 - __MAKE_CONF=/dev/null TB --- 2014-04-02 20:18:40 - cd /src TB --- 2014-04-02 20:18:40 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Apr 2 20:18:40 UTC 2014 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/dev/iicbus/iicsmb.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/dev/iicbus/iicoc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/dev/iicbus/s35390a.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq
[head tinderbox] failure on i386/i386
TB --- 2014-04-02 17:00:23 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-02 17:00:23 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-02 17:00:23 - starting HEAD tinderbox run for i386/i386 TB --- 2014-04-02 17:00:23 - cleaning the object tree TB --- 2014-04-02 17:03:14 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-02 17:03:18 - At svn revision 264046 TB --- 2014-04-02 17:03:19 - building world TB --- 2014-04-02 17:03:19 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 17:03:19 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 17:03:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 17:03:19 - SRCCONF=/dev/null TB --- 2014-04-02 17:03:19 - TARGET=i386 TB --- 2014-04-02 17:03:19 - TARGET_ARCH=i386 TB --- 2014-04-02 17:03:19 - TZ=UTC TB --- 2014-04-02 17:03:19 - __MAKE_CONF=/dev/null TB --- 2014-04-02 17:03:19 - cd /src TB --- 2014-04-02 17:03:19 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Wed Apr 2 17:03:26 UTC 2014 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Apr 2 20:28:50 UTC 2014 TB --- 2014-04-02 20:28:50 - generating LINT kernel config TB --- 2014-04-02 20:28:50 - cd /src/sys/i386/conf TB --- 2014-04-02 20:28:50 - /usr/bin/make -B LINT TB --- 2014-04-02 20:28:50 - cd /src/sys/i386/conf TB --- 2014-04-02 20:28:50 - /obj/i386.i386/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-04-02 20:28:50 - building LINT kernel TB --- 2014-04-02 20:28:50 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 20:28:50 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 20:28:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 20:28:50 - SRCCONF=/dev/null TB --- 2014-04-02 20:28:50 - TARGET=i386 TB --- 2014-04-02 20:28:50 - TARGET_ARCH=i386 TB --- 2014-04-02 20:28:50 - TZ=UTC TB --- 2014-04-02 20:28:50 - __MAKE_CONF=/dev/null TB --- 2014-04-02 20:28:50 - cd /src TB --- 2014-04-02 20:28:50 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Apr 2 20:28:50 UTC 2014 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -c ipwibssfw.c uudecode -o ipw_ibss.fw /src/sys/contrib/dev/ipw/ipw2100-1.3-i.fw.uu ld -b binary --no-warn-mismatch -d -warn-common -r -o ipw_ibss.fwo ipw_ibss.fw cc -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -c ipwmonitorfw.c uudecode -o ipw_monitor.fw /src/sys/contrib/dev/ipw/ipw2100-1.3-p.fw.uu ld -b binary --no-warn-mismatch -d -warn-common -r -o ipw_monitor.fwo ipw_monitor.fw cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/dev/iscsi/icl.c
[head tinderbox] failure on armv6/arm
TB --- 2014-04-02 17:00:23 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-02 17:00:23 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-02 17:00:23 - starting HEAD tinderbox run for armv6/arm TB --- 2014-04-02 17:00:23 - cleaning the object tree TB --- 2014-04-02 17:03:35 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-02 17:03:39 - At svn revision 264046 TB --- 2014-04-02 17:03:40 - building world TB --- 2014-04-02 17:03:40 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 17:03:40 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 17:03:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 17:03:40 - SRCCONF=/dev/null TB --- 2014-04-02 17:03:40 - TARGET=arm TB --- 2014-04-02 17:03:40 - TARGET_ARCH=armv6 TB --- 2014-04-02 17:03:40 - TZ=UTC TB --- 2014-04-02 17:03:40 - __MAKE_CONF=/dev/null TB --- 2014-04-02 17:03:40 - cd /src TB --- 2014-04-02 17:03:40 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Wed Apr 2 17:03:47 UTC 2014 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Apr 2 20:18:40 UTC 2014 TB --- 2014-04-02 20:18:40 - generating LINT kernel config TB --- 2014-04-02 20:18:40 - cd /src/sys/arm/conf TB --- 2014-04-02 20:18:40 - /usr/bin/make -B LINT TB --- 2014-04-02 20:18:40 - cd /src/sys/arm/conf TB --- 2014-04-02 20:18:40 - /obj/arm.armv6/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-04-02 20:18:40 - skipping LINT kernel TB --- 2014-04-02 20:18:40 - cd /src/sys/arm/conf TB --- 2014-04-02 20:18:40 - /obj/arm.armv6/src/tmp/legacy/usr/sbin/config -m AC100 TB --- 2014-04-02 20:18:40 - building AC100 kernel TB --- 2014-04-02 20:18:40 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 20:18:40 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 20:18:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 20:18:40 - SRCCONF=/dev/null TB --- 2014-04-02 20:18:40 - TARGET=arm TB --- 2014-04-02 20:18:40 - TARGET_ARCH=armv6 TB --- 2014-04-02 20:18:40 - TZ=UTC TB --- 2014-04-02 20:18:40 - __MAKE_CONF=/dev/null TB --- 2014-04-02 20:18:40 - cd /src TB --- 2014-04-02 20:18:40 - /usr/bin/make -B buildkernel KERNCONF=AC100 Kernel build for AC100 started on Wed Apr 2 20:18:40 UTC 2014 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for AC100 completed on Wed Apr 2 20:21:48 UTC 2014 TB --- 2014-04-02 20:21:48 - cd /src/sys/arm/conf TB --- 2014-04-02 20:21:48 - /obj/arm.armv6/src/tmp/legacy/usr/sbin/config -m ARMADAXP TB --- 2014-04-02 20:21:48 - building ARMADAXP kernel TB --- 2014-04-02 20:21:48 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 20:21:48 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 20:21:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 20:21:48 - SRCCONF=/dev/null TB --- 2014-04-02 20:21:48 - TARGET=arm TB --- 2014-04-02 20:21:48 - TARGET_ARCH=armv6 TB --- 2014-04-02 20:21:48 - TZ=UTC TB --- 2014-04-02 20:21:48 - __MAKE_CONF=/dev/null TB --- 2014-04-02 20:21:48 - cd /src TB --- 2014-04-02 20:21:48 - /usr/bin/make -B buildkernel KERNCONF=ARMADAXP Kernel build for ARMADAXP started on Wed Apr 2 20:21:48 UTC 2014 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for ARMADAXP completed on Wed Apr 2 20:25:51 UTC 2014 TB --- 2014-04-02 20:25:51 - cd /src/sys/arm/conf TB --- 2014-04-02 20:25:51 - /obj/arm.armv6/src/tmp/legacy/usr/sbin/config -m ARNDALE TB --- 2014-04-02 20:25:51 - building ARNDALE kernel TB --- 2014-04-02 20:25:51 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 20:25:51 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 20:25:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 20:25:51 - SRCCONF=/dev/null TB --- 2014-04-02 20:25:51 - TARGET=arm TB --- 2014-04-02 20:25:51 - TARGET_ARCH=armv6 TB --- 2014-04-02 20:25:51 - TZ=UTC TB --- 2014-04-02 20:25:51 - __MAKE_CONF=/dev/null TB --- 2014-04-02 20:25:51 - cd /src TB --- 2014-04-02 20:25:51 - /usr/bin/make -B buildkernel KERNCONF=ARNDALE Kernel build for ARNDALE started on Wed Apr 2 20:25:52 UTC 2014 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for ARNDALE completed on Wed Apr 2 20:30:44 UTC 2014 TB --- 2014-04-02
Re: gcc compilation broken with SVN r264042
On 2 Apr 2014, at 21:21, Steve Kargl s...@troutmask.apl.washington.edu wrote: Who is we in even if we don't encourage it...? We is the FreeBSD project, collectively. For a larger list of things that we recommend, look at the src.conf man page, which contains a long list of things that we encourage, codified as the defaults for a build. Building FreeBSD-HEAD/i386 with gcc is just one of a long list of things that we don't encourage. In fact, this is a fairly dumb idea, Having a recommended compiler is a dumb idea? and *we* should encourage building the base system with as many different compilers as possible. I didn't say otherwise, which is why I'm working to fix this. I'd love to have the Jenkins jobs set up with external toolchain support and be able to plug in compilers from ports to try to build / boot / test the base system on a regular basis. If you're developing FreeBSD or testing, then please compile with as many other compilers as you have and contribute patches (or even just detailed reports) if they find bugs in the code. If, however, you want to run FreeBSD in production... well, there's a reason for those defaults. Building the base system with a compiler that can't build the C++ stack that ports expects for FreeBSD 10 or 11 on i386, for example, is going to make your life exciting... It's called portability and allows one to find bugs that the annointed compiler might miss or actually cause. And, more importantly, it helps determine whether bugs are bugs in the compiler or in the code that they're compiling. Being able to say that a bug goes away with one compiler gives you a good hint that it's a compiler bug. Or something in the source code that relies on undefined behaviour... But all of that is irrelevant to this bug report, so perhaps we can end this digression. Unless, of course, you can reproduce this failure and would like to help fix it, in which case I'd be very grateful for your assistance. David ___ 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
[head tinderbox] failure on mips/mips
TB --- 2014-04-02 20:41:25 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-02 20:41:25 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-02 20:41:25 - starting HEAD tinderbox run for mips/mips TB --- 2014-04-02 20:41:25 - cleaning the object tree TB --- 2014-04-02 20:41:25 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-02 20:41:28 - At svn revision 264046 TB --- 2014-04-02 20:41:29 - building world TB --- 2014-04-02 20:41:29 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 20:41:29 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 20:41:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 20:41:29 - SRCCONF=/dev/null TB --- 2014-04-02 20:41:29 - TARGET=mips TB --- 2014-04-02 20:41:29 - TARGET_ARCH=mips TB --- 2014-04-02 20:41:29 - TZ=UTC TB --- 2014-04-02 20:41:29 - __MAKE_CONF=/dev/null TB --- 2014-04-02 20:41:29 - cd /src TB --- 2014-04-02 20:41:29 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Wed Apr 2 20:41:36 UTC 2014 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] cc -O -pipe -G0 -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/mips -DNLS -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/mips.mips/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/mips/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_gethex.c -o gdtoa_gethex.o cc -O -pipe -G0 -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/mips -DNLS -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/mips.mips/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/mips/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_gmisc.c -o gdtoa_gmisc.o cc -O -pipe -G0 -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/mips -DNLS -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/mips.mips/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/mips/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_hd_init.c -o gdtoa_hd_init.o cc -O -pipe -G0 -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/mips -DNLS -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/mips.mips/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/mips/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_hexnan.c -o gdtoa_hexnan.o cc -O -pipe -G0 -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/mips -DNLS -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/mips.mips/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/mips/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_misc.c -o gdtoa_misc.o cc -O -pipe -G0 -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/mips -DNLS -DSOFTFLOAT -D__DBINTERFACE_PRIVATE
[head tinderbox] failure on ia64/ia64
TB --- 2014-04-02 20:40:47 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-02 20:40:47 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-02 20:40:47 - starting HEAD tinderbox run for ia64/ia64 TB --- 2014-04-02 20:40:47 - cleaning the object tree TB --- 2014-04-02 20:40:47 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-02 20:40:50 - At svn revision 264046 TB --- 2014-04-02 20:40:51 - building world TB --- 2014-04-02 20:40:51 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 20:40:51 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 20:40:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 20:40:51 - SRCCONF=/dev/null TB --- 2014-04-02 20:40:51 - TARGET=ia64 TB --- 2014-04-02 20:40:51 - TARGET_ARCH=ia64 TB --- 2014-04-02 20:40:51 - TZ=UTC TB --- 2014-04-02 20:40:51 - __MAKE_CONF=/dev/null TB --- 2014-04-02 20:40:51 - cd /src TB --- 2014-04-02 20:40:51 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Wed Apr 2 20:40:59 UTC 2014 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/ia64.ia64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_gethex.c -o gdtoa_gethex.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/ia64.ia64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_gmisc.c -o gdtoa_gmisc.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/ia64.ia64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_hd_init.c -o gdtoa_hd_init.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/ia64.ia64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_hexnan.c -o gdtoa_hexnan.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/ia64.ia64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_misc.c -o gdtoa_misc.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/ia64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/ia64.ia64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_smisc.c -o gdtoa_smisc.o cc -O2 -pipe -I/src/lib/libc/include
[head tinderbox] failure on mips64/mips
TB --- 2014-04-02 20:52:46 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-02 20:52:46 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-02 20:52:46 - starting HEAD tinderbox run for mips64/mips TB --- 2014-04-02 20:52:46 - cleaning the object tree TB --- 2014-04-02 20:52:46 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-02 20:52:50 - At svn revision 264046 TB --- 2014-04-02 20:52:51 - building world TB --- 2014-04-02 20:52:51 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 20:52:51 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 20:52:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 20:52:51 - SRCCONF=/dev/null TB --- 2014-04-02 20:52:51 - TARGET=mips TB --- 2014-04-02 20:52:51 - TARGET_ARCH=mips64 TB --- 2014-04-02 20:52:51 - TZ=UTC TB --- 2014-04-02 20:52:51 - __MAKE_CONF=/dev/null TB --- 2014-04-02 20:52:51 - cd /src TB --- 2014-04-02 20:52:51 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Wed Apr 2 20:52:58 UTC 2014 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] cc -O -pipe -G0 -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/mips -DNLS -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/mips.mips64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/mips/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_gethex.c -o gdtoa_gethex.o cc -O -pipe -G0 -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/mips -DNLS -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/mips.mips64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/mips/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_gmisc.c -o gdtoa_gmisc.o cc -O -pipe -G0 -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/mips -DNLS -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/mips.mips64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/mips/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_hd_init.c -o gdtoa_hd_init.o cc -O -pipe -G0 -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/mips -DNLS -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/mips.mips64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/mips/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_hexnan.c -o gdtoa_hexnan.o cc -O -pipe -G0 -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/mips -DNLS -DSOFTFLOAT -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/mips.mips64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -I/src/lib/libc/mips/softfloat -I/src/lib/libc/softfloat -DSOFTFLOAT_FOR_GCC -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -w -c gdtoa_misc.c -o gdtoa_misc.o cc -O -pipe -G0 -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/mips -DNLS -DSOFTFLOAT -D__DBINTERFACE_PRIVATE
[head tinderbox] failure on powerpc/powerpc
TB --- 2014-04-02 20:52:59 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-02 20:52:59 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-02 20:52:59 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2014-04-02 20:52:59 - cleaning the object tree TB --- 2014-04-02 20:54:03 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-02 20:54:06 - At svn revision 264046 TB --- 2014-04-02 20:54:07 - building world TB --- 2014-04-02 20:54:07 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 20:54:07 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 20:54:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 20:54:07 - SRCCONF=/dev/null TB --- 2014-04-02 20:54:07 - TARGET=powerpc TB --- 2014-04-02 20:54:07 - TARGET_ARCH=powerpc TB --- 2014-04-02 20:54:07 - TZ=UTC TB --- 2014-04-02 20:54:07 - __MAKE_CONF=/dev/null TB --- 2014-04-02 20:54:07 - cd /src TB --- 2014-04-02 20:54:07 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Wed Apr 2 20:54:14 UTC 2014 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/powerpc.powerpc/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_gethex.c -o gdtoa_gethex.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/powerpc.powerpc/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_gmisc.c -o gdtoa_gmisc.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/powerpc.powerpc/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_hd_init.c -o gdtoa_hd_init.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/powerpc.powerpc/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_hexnan.c -o gdtoa_hexnan.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/powerpc.powerpc/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_misc.c -o gdtoa_misc.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/powerpc.powerpc/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN
Re: gcc compilation broken with SVN r264042
On Wed, Apr 02, 2014 at 09:46:19PM +0100, David Chisnall wrote: On 2 Apr 2014, at 21:21, Steve Kargl s...@troutmask.apl.washington.edu wrote: Who is we in even if we don't encourage it...? We is the FreeBSD project, collectively. For a larger list of things that we recommend, There is a significant difference between we recommend and we don't encourage. In fact, this is a fairly dumb idea, Having a recommended compiler is a dumb idea? Having a recommended compiler is fine. Actively discouraging the use of other compilers is a dumb idea. and *we* should encourage building the base system with as many different compilers as possible. I didn't say otherwise, Ah, yes you did. Here's the complete quote (with context): butler I guess it's time for me to migrate that box to clang :-) you Well, I wouldn't object to that, but it would be good to fix this - we still want to be able to build the base system with gcc (or another compiler), even if we don't encourage it... You are actively discouraging the use of gcc (or another compiler). How else is one to interpret the last 5 word + 1 contraction in your above quote? If you're developing FreeBSD or testing, then please compile with as many other compilers as you have and contribute patches I do development on libm (as you know!). I test with clang and base system gcc on i386, amd64, and sparc64. In the past, I also used pcc and newer versions of gcc to do some libm testing. (or even just detailed reports) if they find bugs in the code. I do report problems with the compilers, but they are typically ignored. http://lists.freebsd.org/pipermail/freebsd-toolchain/2014-March/001147.html You can also read some follow-up analysis here: http://lists.freebsd.org/pipermail/freebsd-numerics/2014-March/000549.html -- Steve ___ 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
[head tinderbox] failure on powerpc64/powerpc
TB --- 2014-04-02 21:03:46 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-02 21:03:46 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-02 21:03:46 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2014-04-02 21:03:46 - cleaning the object tree TB --- 2014-04-02 21:03:46 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-02 21:03:49 - At svn revision 264046 TB --- 2014-04-02 21:03:50 - building world TB --- 2014-04-02 21:03:50 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 21:03:50 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 21:03:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 21:03:50 - SRCCONF=/dev/null TB --- 2014-04-02 21:03:50 - TARGET=powerpc TB --- 2014-04-02 21:03:50 - TARGET_ARCH=powerpc64 TB --- 2014-04-02 21:03:50 - TZ=UTC TB --- 2014-04-02 21:03:50 - __MAKE_CONF=/dev/null TB --- 2014-04-02 21:03:50 - cd /src TB --- 2014-04-02 21:03:50 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Wed Apr 2 21:03:57 UTC 2014 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/powerpc.powerpc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_gethex.c -o gdtoa_gethex.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/powerpc.powerpc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_gmisc.c -o gdtoa_gmisc.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/powerpc.powerpc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_hd_init.c -o gdtoa_hd_init.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/powerpc.powerpc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_hexnan.c -o gdtoa_hexnan.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/powerpc.powerpc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_misc.c -o gdtoa_misc.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/powerpc64 -DNLS -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/powerpc.powerpc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale
[head tinderbox] failure on sparc64/sparc64
TB --- 2014-04-02 21:09:23 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-02 21:09:23 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-02 21:09:23 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2014-04-02 21:09:23 - cleaning the object tree TB --- 2014-04-02 21:09:23 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-02 21:09:26 - At svn revision 264046 TB --- 2014-04-02 21:09:27 - building world TB --- 2014-04-02 21:09:27 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 21:09:27 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 21:09:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 21:09:27 - SRCCONF=/dev/null TB --- 2014-04-02 21:09:27 - TARGET=sparc64 TB --- 2014-04-02 21:09:27 - TARGET_ARCH=sparc64 TB --- 2014-04-02 21:09:27 - TZ=UTC TB --- 2014-04-02 21:09:27 - __MAKE_CONF=/dev/null TB --- 2014-04-02 21:09:27 - cd /src TB --- 2014-04-02 21:09:27 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Wed Apr 2 21:09:35 UTC 2014 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -DNLS -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/sparc64.sparc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_gethex.c -o gdtoa_gethex.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -DNLS -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/sparc64.sparc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_gmisc.c -o gdtoa_gmisc.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -DNLS -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/sparc64.sparc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_hd_init.c -o gdtoa_hd_init.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -DNLS -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/sparc64.sparc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_hexnan.c -o gdtoa_hexnan.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -DNLS -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa -I/src/lib/libc/../../contrib/libc-vis -DINET6 -I/obj/sparc64.sparc64/src/lib/libc -I/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/src/lib/libc/../../contrib/jemalloc/include -I/src/lib/libc/../../contrib/tzcode/stdtime -I/src/lib/libc/stdtime -I/src/lib/libc/locale -I/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -w -c gdtoa_misc.c -o gdtoa_misc.o cc -O2 -pipe -I/src/lib/libc/include -I/src/lib/libc/../../include -I/src/lib/libc/sparc64 -DNLS -I/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/src/lib/libc/../../contrib/gdtoa
Re: login.conf -- UTF-8
On 02.04.2014 21:15, Gleb Smirnoff wrote: S + :lang=en_US.UTF-8:\ S + :charset=UTF-8: And I'd like to do same change for the 'russian' login class in /etc/login.conf. Please everybody remember that we don't have UTF-8 collation implemented, just fallback to bytecode comparison. -- http://ache.vniz.net/ ___ 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
Jenkins build is back to normal : FreeBSD_HEAD #389
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/389/changes ___ 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: login.conf -- UTF-8
In article 1396457629.2280.2.ca...@powernoodle.corp.yahoo.com, sbr...@freebsd.org writes: I'd like to make this change to login.conf for default installs. This removes some amount of hackery in the ports system that is working around our lack of UTF-8 in the base. I'm not sure what the connection is here. Surely the ports system runs with the locale of the user running make (which in my case is going to be C). Any port that requires a specific locale to build properly needs to be setting that locale explicitly. -GAWollman ___ 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: login.conf -- UTF-8
On Wed, 2014-04-02 at 18:06 -0400, Garrett Wollman wrote: In article 1396457629.2280.2.ca...@powernoodle.corp.yahoo.com, sbr...@freebsd.org writes: I'd like to make this change to login.conf for default installs. This removes some amount of hackery in the ports system that is working around our lack of UTF-8 in the base. I'm not sure what the connection is here. Surely the ports system runs with the locale of the user running make (which in my case is going to be C). Any port that requires a specific locale to build properly needs to be setting that locale explicitly. -GAWollman I have been informed by folks that this change I suggest would help in the case of ports having to declare UTF-8 support explicitly or something. I'm hand-wavy on the details and ignorant of the hacks in place. I only know that I've been *told* this. sean signature.asc Description: This is a digitally signed message part
Re: login.conf -- UTF-8
On Wed, Apr 02, 2014 at 03:56:35PM -0700, Sean Bruno wrote: I have been informed by folks that this change I suggest would help in the case of ports having to declare UTF-8 support explicitly or something. Clearly ports that need to do this are broken -- but this very much an edge-case of brokenness. There's so much other lower-hanging fruit than to fix the individual offenders. mcl ___ 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: gcc compilation broken with SVN r264042
On Apr 2, 2014, at 1:15 PM, Michael Butler i...@protected-networks.net wrote: /usr/src/lib/libc/stdlib/atexit.c: In function 'atexit_b': /usr/src/lib/libc/stdlib/atexit.c:157: error: cannot convert to a pointer type *** Error code 1 This also breaks mips*, sparc64, armeb and ia64. I’ve seen the carping about discouraging using gcc on i386, but this isn’t even an edge case. Our simple, default build is broken for many platforms. Sure looks like a universe wasn’t done before it was committed. So less carping and more fixing is needed here. Warner ___ 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
[head tinderbox] failure on i386/pc98
TB --- 2014-04-02 20:26:38 - tinderbox 2.21 running on freebsd-current.sentex.ca TB --- 2014-04-02 20:26:38 - FreeBSD freebsd-current.sentex.ca 9.2-STABLE FreeBSD 9.2-STABLE #0 r263721: Tue Mar 25 09:27:39 EDT 2014 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-04-02 20:26:38 - starting HEAD tinderbox run for i386/pc98 TB --- 2014-04-02 20:26:38 - cleaning the object tree TB --- 2014-04-02 20:27:56 - /usr/local/bin/svn stat --no-ignore /src TB --- 2014-04-02 20:28:09 - At svn revision 264046 TB --- 2014-04-02 20:28:10 - building world TB --- 2014-04-02 20:28:10 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 20:28:10 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 20:28:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 20:28:10 - SRCCONF=/dev/null TB --- 2014-04-02 20:28:10 - TARGET=pc98 TB --- 2014-04-02 20:28:10 - TARGET_ARCH=i386 TB --- 2014-04-02 20:28:10 - TZ=UTC TB --- 2014-04-02 20:28:10 - __MAKE_CONF=/dev/null TB --- 2014-04-02 20:28:10 - cd /src TB --- 2014-04-02 20:28:10 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Wed Apr 2 20:28:18 UTC 2014 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Apr 2 23:55:33 UTC 2014 TB --- 2014-04-02 23:55:33 - generating LINT kernel config TB --- 2014-04-02 23:55:33 - cd /src/sys/pc98/conf TB --- 2014-04-02 23:55:33 - /usr/bin/make -B LINT TB --- 2014-04-02 23:55:33 - cd /src/sys/pc98/conf TB --- 2014-04-02 23:55:33 - /obj/pc98.i386/src/tmp/legacy/usr/sbin/config -m LINT TB --- 2014-04-02 23:55:33 - building LINT kernel TB --- 2014-04-02 23:55:33 - CROSS_BUILD_TESTING=YES TB --- 2014-04-02 23:55:33 - MAKEOBJDIRPREFIX=/obj TB --- 2014-04-02 23:55:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-04-02 23:55:33 - SRCCONF=/dev/null TB --- 2014-04-02 23:55:33 - TARGET=pc98 TB --- 2014-04-02 23:55:33 - TARGET_ARCH=i386 TB --- 2014-04-02 23:55:33 - TZ=UTC TB --- 2014-04-02 23:55:33 - __MAKE_CONF=/dev/null TB --- 2014-04-02 23:55:33 - cd /src TB --- 2014-04-02 23:55:33 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Apr 2 23:55:33 UTC 2014 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/dev/iicbus/iicbus.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/iicbus/iicbus_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg iicbus_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-unused-function -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -DGPROF -DGPROF4 -DGUPROF -fno-builtin -mno-aes -mno-avx -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -Werror -pg /src/sys/dev/iicbus/iiconf.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option
Re: login.conf -- UTF-8
On Wed, Apr 02, 2014 at 03:56:35PM -0700, Sean Bruno wrote: On Wed, 2014-04-02 at 18:06 -0400, Garrett Wollman wrote: In article 1396457629.2280.2.ca...@powernoodle.corp.yahoo.com, sbr...@freebsd.org writes: I'd like to make this change to login.conf for default installs. This removes some amount of hackery in the ports system that is working around our lack of UTF-8 in the base. I'm not sure what the connection is here. Surely the ports system runs with the locale of the user running make (which in my case is going to be C). Any port that requires a specific locale to build properly needs to be setting that locale explicitly. You'd think so, but that's not what's happening. What's happening is the software builds as long as the locale isn't C. Hence, ugly hacks like this: http://svnweb.freebsd.org/ports/head/Mk/bsd.ruby.mk?annotate=348863#l257 Why? Because the people writing it have never encountered a system where LANG isn't set or is set to C. Yes, it's a bug in their software. No, they never have and never will encounter it. Because every other operating system sets LANG to whatever the user specifies. And so they have no interest in fixing it, because neither they nor any one they know will ever encounter it, and even if you report it to them they will tell you it's a bug in your system for not having LANG specified. And I have no interest in patching it hundreds of times. And this is just one example. There are others, I think, that aren't ruby related at all. I have been informed by folks that this change I suggest would help in the case of ports having to declare UTF-8 support explicitly or something. I'm hand-wavy on the details and ignorant of the hacks in place. I only know that I've been *told* this. I think we should join the club of asking the user, but that's more work and until then having a reasonable default and having people change it seems sane. Steve ___ 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: login.conf -- UTF-8
On Thu, 3 Apr 2014, Steve Wills wrote: On Wed, Apr 02, 2014 at 03:56:35PM -0700, Sean Bruno wrote: On Wed, 2014-04-02 at 18:06 -0400, Garrett Wollman wrote: In article 1396457629.2280.2.ca...@powernoodle.corp.yahoo.com, sbr...@freebsd.org writes: I'd like to make this change to login.conf for default installs. This removes some amount of hackery in the ports system that is working around our lack of UTF-8 in the base. I'm not sure what the connection is here. Surely the ports system runs with the locale of the user running make (which in my case is going to be C). Any port that requires a specific locale to build properly needs to be setting that locale explicitly. You'd think so, but that's not what's happening. What's happening is the software builds as long as the locale isn't C. Hence, ugly hacks like this: http://svnweb.freebsd.org/ports/head/Mk/bsd.ruby.mk?annotate=348863#l257 Why? Because the people writing it have never encountered a system where LANG isn't set or is set to C. Yes, it's a bug in their software. No, they never have and never will encounter it. Because every other operating system sets LANG to whatever the user specifies. And so they have no interest in fixing it, because neither they nor any one they know will ever encounter it, and even if you report it to them they will tell you it's a bug in your system for not having LANG specified. And I have no interest in patching it hundreds of times. And this is just one example. There are others, I think, that aren't ruby related at all. The first thing I do when I get a Linux system is set LANG to C. I hate all the colorizations and incorrect ordering from ls when LANG isn't C. So you are saying, that ports will be broken when I set LANG back to C again? I have been informed by folks that this change I suggest would help in the case of ports having to declare UTF-8 support explicitly or something. I'm hand-wavy on the details and ignorant of the hacks in place. I only know that I've been *told* this. I think we should join the club of asking the user, but that's more work and until then having a reasonable default and having people change it seems sane. A default is fine, but saying that ports will be broken when not using the default is not fine. This is LANG, not a gcc/clang machine-specific optimization that someone has set to get an extra 0.001% improvement, but happens to break the compiler for some ports. -- DE ___ 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: login.conf -- UTF-8
On Wed, Apr 02, 2014 at 09:31:08PM -0400, Daniel Eischen wrote: On Thu, 3 Apr 2014, Steve Wills wrote: On Wed, Apr 02, 2014 at 03:56:35PM -0700, Sean Bruno wrote: On Wed, 2014-04-02 at 18:06 -0400, Garrett Wollman wrote: In article 1396457629.2280.2.ca...@powernoodle.corp.yahoo.com, sbr...@freebsd.org writes: I'd like to make this change to login.conf for default installs. This removes some amount of hackery in the ports system that is working around our lack of UTF-8 in the base. I'm not sure what the connection is here. Surely the ports system runs with the locale of the user running make (which in my case is going to be C). Any port that requires a specific locale to build properly needs to be setting that locale explicitly. You'd think so, but that's not what's happening. What's happening is the software builds as long as the locale isn't C. Hence, ugly hacks like this: http://svnweb.freebsd.org/ports/head/Mk/bsd.ruby.mk?annotate=348863#l257 Why? Because the people writing it have never encountered a system where LANG isn't set or is set to C. Yes, it's a bug in their software. No, they never have and never will encounter it. Because every other operating system sets LANG to whatever the user specifies. And so they have no interest in fixing it, because neither they nor any one they know will ever encounter it, and even if you report it to them they will tell you it's a bug in your system for not having LANG specified. And I have no interest in patching it hundreds of times. And this is just one example. There are others, I think, that aren't ruby related at all. The first thing I do when I get a Linux system is set LANG to C. I hate all the colorizations and incorrect ordering from ls when LANG isn't C. So you are saying, that ports will be broken when I set LANG back to C again? I have been informed by folks that this change I suggest would help in the case of ports having to declare UTF-8 support explicitly or something. I'm hand-wavy on the details and ignorant of the hacks in place. I only know that I've been *told* this. I think we should join the club of asking the user, but that's more work and until then having a reasonable default and having people change it seems sane. A default is fine, but saying that ports will be broken when not using the default is not fine. This is LANG, not a gcc/clang machine-specific optimization that someone has set to get an extra 0.001% improvement, but happens to break the compiler for some ports. I suppose you're right. Ugly hacks to work around ugly hacks will stay. :) (Not that I'd planned to remove them any time soon anyway, because such a change would take a long time to propogate to all supported versions anyway.) Steve ___ 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: Leaving the Desktop Market
On Tue, Apr 01, 2014 at 06:40:18PM -0400, Garrett Wollman wrote: Hmmm. I'm a bit biased here, but I've been using FreeBSD on the desktop since, well, before it was called FreeBSD. It's still my primary platform for nearly everything (except photo management, which drove me to a Mac laptop so I could run Lightroom, and those few There are a few alternatives to Lightroom available in Ports Collection, you might want to give them a try one day. remaining Web sites that still bury all their content inside Flash). That's easy: Flash sites should be avoided. Most of them are using this technology for showing stupid ads anyway, not for something useful. I still recall a friend of mine actually *loved* that his iPhone does not support Flash: it essentially enabled (ad|spam)-free Web browsing (alas, those fuckers had caught up since then). But let's be clear that different people have different requirements for a desktop. My requirements are relatively simple: twm, xterm, XEmacs, vlc, LaTeX, xpdf, a Jabber client (psi), $VCS_OF_CHOICE, gnucash, and at least two Web browsers (I use Opera for most stuff and Firefox for promiscuous-mode browsing). [...] Other people have rather different requirements, and that's OK. But let's please not break the applications for which FreeBSD is very good now (and has actually gotten substantially better). Application availability does not, unfortunately, round up some perfect desktop. I fear that Linux-centric development of hardware drivers, X.org and all that shit is getting more and more divergent from FreeBSD, and soon enough we'll get the situation I haven't seen for some 15 years: we are again far behind on modern HW support. Power-saving techniques, most notably working sleep-resume and competitive batter life are also our weak points at the moment. I'd like to replace my old laptop (which runs 8.4-STABLE almost perfectly), but how far can I go with, say, recent MacBook Pro? ./danfe ___ 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: Leaving the Desktop Market
No wifi. Someone has to step up and own broadcom wifi or this will never change. -a On 2 April 2014 18:44, Alexey Dokuchaev da...@nsu.ru wrote: On Tue, Apr 01, 2014 at 06:40:18PM -0400, Garrett Wollman wrote: Hmmm. I'm a bit biased here, but I've been using FreeBSD on the desktop since, well, before it was called FreeBSD. It's still my primary platform for nearly everything (except photo management, which drove me to a Mac laptop so I could run Lightroom, and those few There are a few alternatives to Lightroom available in Ports Collection, you might want to give them a try one day. remaining Web sites that still bury all their content inside Flash). That's easy: Flash sites should be avoided. Most of them are using this technology for showing stupid ads anyway, not for something useful. I still recall a friend of mine actually *loved* that his iPhone does not support Flash: it essentially enabled (ad|spam)-free Web browsing (alas, those fuckers had caught up since then). But let's be clear that different people have different requirements for a desktop. My requirements are relatively simple: twm, xterm, XEmacs, vlc, LaTeX, xpdf, a Jabber client (psi), $VCS_OF_CHOICE, gnucash, and at least two Web browsers (I use Opera for most stuff and Firefox for promiscuous-mode browsing). [...] Other people have rather different requirements, and that's OK. But let's please not break the applications for which FreeBSD is very good now (and has actually gotten substantially better). Application availability does not, unfortunately, round up some perfect desktop. I fear that Linux-centric development of hardware drivers, X.org and all that shit is getting more and more divergent from FreeBSD, and soon enough we'll get the situation I haven't seen for some 15 years: we are again far behind on modern HW support. Power-saving techniques, most notably working sleep-resume and competitive batter life are also our weak points at the moment. I'd like to replace my old laptop (which runs 8.4-STABLE almost perfectly), but how far can I go with, say, recent MacBook Pro? ./danfe ___ 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
another Make (maybe) problem
Warner:
This will happen with fmake. I?ve put some safety belts in place in
another fix to keep this from tripping people up (and plan on using
a similar technique to keep people from hitting the aicasm bug on
such systems).
As long as make-related issues are on the table ...
I have a system, running
FreeBSD 11.0-CURRENT #0 r263263: Mon Mar 17 15:09:18 EDT 2014 amd64
where make buildworld fails. The immediate problem can be seen at:
http://users.rcn.com/roberthuff/bw_tail
the full log at
http://users.rcn.com/roberthuff/bwl.bz2
make.conf is appended. There is no src.conf.
I never seen anything like this before; nothing like has come across
current@ (recently); and nothing in src/UPDATING appears relevant.
Help, please?
Robert Huff
◙♪
make.conf
BDBCFLAGS+= -O -pipe
DEBUG_FLAGS+= -g
STRIP=
SYMVER_ENABLED= yes
X_WINDOW_SYSTEM=xorg
HAVE_MOTIF= yes
#FC=gfortran42
KERNCONF=JERUSALEM
# To avoid building various parts of the base system:
# (copied from /usr/share/examples/etc/make.conf
NO_BIND_ETC= true# Do not install files to /etc/namedb
NO_BLUETOOTH= true# do not build Bluetooth related stuff
NO_PROFILE= true# Avoid compiling profiled libraries
# to get automatic SASL in sendmail
SENDMAIL_CFLAGS+= -I/usr/local/include/ -DSASL=2
SENDMAIL_LDFLAGS+= -L/usr/local/lib
SENDMAIL_LDADD+=-lsasl2
#
# to make CUPS magically keep working
# See: http://www.csua.berkeley.edu/~ranga/notes/freebsd_cups.html
#
CUPS_OVERWRITE_BASE=yes
NO_LPR= true
# added per /usr/ports/UPDATING entry 20090401
OVERRIDE_LINUX_BASE_PORT=f10
OVERRIDE_LINUX_NONBASE_PORTS=f10
#
WITH_MOZILLA= libxul
WITH_GECKO= libxul
#
# added 2007/03/04 per advice of free...@troback.com
# in re science/gramps
#
WITH_BERKELEYDB=db6
WITH_BDB_VER=6
WANT_OPENLDAP_VER=24
WANT_OPENLDAP_SASL=true
#
# as required by ports/UPDATING of 20121012
#
SAMBA_ENABLE=YES
#
# PORTS: use clang unless gcc is explicitly required
#
#
# default to using clang for all port builds, with the following
# exceptions
.if !empty(.CURDIR:M/usr/ports/graphics/libcdr)
exists(/usr/local/bin/gcc47)
CC=gcc47
CXX=g++47
CPP=cpp47
.endif
.if ${.CURDIR:M*/usr/ports/*}
.if !defined(USE_GCC)
.if !defined(CC) || ${CC} == cc
CC=clang
.endif
.if !defined(CXX) || ${CXX} == c++
CXX=clang++
.endif
.if !defined(CPP) || ${CPP} == cpp
CPP=clang-cpp
.endif
.endif
.endif
WITH_NEW_XORG=yes
WITH_GALLIUM=yes
WITH_BSD_SORT=
WITH_PKGNG=yes
___
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: vt text cursor invisible in reverse video
On Wed, Apr 02, 2014 at 01:01:11PM +0200, Claude Buisson wrote: After 19 years of FreeBSD use and not being part of any chapel/coterie/mafia I don't keep much illusion about the outcome.. I'm sorry that you feel that way. Rest assured that a large number of those of us that work on FreeBSD do try to improve the software. We also try to figure out ways to get more people involved as contributors, to keep things from becoming stagnant. Yes, I know we're not always successful. mcl ___ 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
