Re: ZFS panic in -CURRENT

[Andriy Gapon]

on 01/04/2014 16:57 R. Tyler Croy said the following:
> On Tue, 01 Apr 2014 09:41:45 +0300
> Andriy Gapon  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:
>>> 
>>
>> 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?

[Kohji Okuno]

From: John-Mark Gurney 
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 ((lockfl

Re: Leaving the Desktop Market

[David Chisnall]

On 1 Apr 2014, at 23:10, Kevin Oberman  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

[FreeBSD Tinderbox]

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   -no

[head tinderbox] failure on armv6/arm

[FreeBSD Tinderbox]

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: 

[head tinderbox] failure on i386/i386

[FreeBSD Tinderbox]

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-prot

Re: vt text cursor invisible in reverse video

[Claude Buisson]

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

[Lars Engels]

On Wed, Apr 02, 2014 at 10:22:32AM +0100, David Chisnall wrote:
> On 1 Apr 2014, at 23:10, Kevin Oberman  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

[Shady Elhamy]

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

[Jordan Hubbard]

On Apr 1, 2014, at 9:12 PM, Jim Thompson  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?

[Konstantin Belousov]

On Wed, Apr 02, 2014 at 04:06:16PM +0900, Kohji Okuno wrote:
> From: John-Mark Gurney 
> 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/ke

Re: Leaving the Desktop Market

[Jordan Hubbard]

On Apr 1, 2014, at 9:33 PM, Person, Roderick  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

[Konstantin Belousov]

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

[Jordan Hubbard]

On Apr 1, 2014, at 10:11 PM, Matt Olander  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?

[Kohji Okuno]

From: Konstantin Belousov 
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 
>> 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 wi

Re: Adding Encryption Algorithm to Kernel

[Oliver Pinter]

On 4/2/14, Shady Elhamy  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

[Daniel Kalchev]

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

[David Chisnall]

On 2 Apr 2014, at 13:40, Daniel Kalchev  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

[Daniel Kalchev]

On 02.04.14 15:52, David Chisnall wrote:

On 2 Apr 2014, at 13:40, Daniel Kalchev  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

[Daniel Kalchev]

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

[FreeBSD Tinderbox]

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  
-Wmis

Re: Leaving the Desktop Market

[O. Hartmann]

On Tue, 1 Apr 2014 15:10:22 -0700
Kevin Oberman  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

[Warner Losh]

On Apr 2, 2014, at 6:15 AM, Konstantin Belousov  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

[Oliver Pinter]

On 4/2/14, Oliver Pinter  wrote:
> On 3/31/14, Shawn Webb  wrote:
>> On Mar 31, 2014 02:07 AM +0200, Oliver Pinter wrote:
>>> On 3/22/14, Shawn Webb  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

[Shawn Webb]

On Apr 02, 2014 04:54 PM +0200, Oliver Pinter wrote:
> On 4/2/14, Oliver Pinter  wrote:
> > On 3/31/14, Shawn Webb  wrote:
> >> On Mar 31, 2014 02:07 AM +0200, Oliver Pinter wrote:
> >>> On 3/22/14, Shawn Webb  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

[FreeBSD Tinderbox]

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/contr

Re: make in dir

[Warner Losh]

On Apr 2, 2014, at 6:15 AM, Konstantin Belousov  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?

[John-Mark Gurney]

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 
> > 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 t

Re: ZFS panic in -CURRENT

[R. Tyler Croy]

On Wed, 02 Apr 2014 09:58:37 +0300
Andriy Gapon  wrote:

> on 01/04/2014 16:57 R. Tyler Croy said the following:
> > On Tue, 01 Apr 2014 09:41:45 +0300
> > Andriy Gapon  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:
> >>> 
> >>
> >> 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: 
  Chatter: 

  % 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

[John-Mark Gurney]

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

[Sean Bruno]

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

[Gleb Smirnoff]

  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

[Matt Olander]

On Wed, Apr 2, 2014 at 5:24 AM, Jordan Hubbard  wrote:
>
> On Apr 1, 2014, at 10:11 PM, Matt Olander  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?

[Konstantin Belousov]

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 ((

Re: make in dir

[Konstantin Belousov]

On Wed, Apr 02, 2014 at 09:46:34AM -0600, Warner Losh wrote:
> 
> On Apr 2, 2014, at 6:15 AM, Konstantin Belousov  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

[Warner Losh]

On Apr 2, 2014, at 12:15 PM, Konstantin Belousov  wrote:

> On Wed, Apr 02, 2014 at 09:46:34AM -0600, Warner Losh wrote:
>> 
>> On Apr 2, 2014, at 6:15 AM, Konstantin Belousov  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

[Andriy Gapon]

on 02/04/2014 19:48 R. Tyler Croy said the following:
> On Wed, 02 Apr 2014 09:58:37 +0300
> Andriy Gapon  wrote:
> 
>> on 01/04/2014 16:57 R. Tyler Croy said the following:
>>> On Tue, 01 Apr 2014 09:41:45 +0300
>>> Andriy Gapon  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:
> 

 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

[Benjamin Lee]

On Wed, 02 Apr 2014 09:53:49 -0700, Sean Bruno  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

[Michael Butler]

-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

[O. Hartmann]

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

[hiren panchasara]

On Wed, Apr 2, 2014 at 7:16 PM, O. Hartmann  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

[hiren panchasara]

+ Ian


On Wed, Apr 2, 2014 at 7:17 PM, hiren panchasara
 wrote:
> On Wed, Apr 2, 2014 at 7:16 PM, O. Hartmann  
> 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

[Antoine Brodin]

On Wed, Apr 2, 2014 at 6:53 PM, Sean Bruno  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

[David Chisnall]

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  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

[jenkins-admin]

See 

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/obj 
-std=iso9899:1999   iwn5150fw.c
===> iwnfw/iwn6000 (depend)
--- 
/usr/obj
 ---
--- 
/usr/obj
 ---
--- 
/usr/obj
 ---
--- 
/usr/obj
 ---
@ -> 
--- 
/usr/obj
 ---
machine -> 

--- 
/usr/obj
 ---
x86 -> 
--- 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/obj 
-std=iso9899:1999   iwn6000fw.c
===> iwnfw/iwn6000g2a (depend)
--- 
/usr/obj
 ---
--- 
/usr/obj
 ---
--- 
/usr/obj
 ---
--- 
/usr/obj
 ---
@ -> 
--- 
/usr/obj
 ---
machine -> 

--- 
/usr/obj
 ---
x86 -> 
--- 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/obj

Re: r264048 broke kernel build

[Ian Lepore]

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
>  wrote:
> > On Wed, Apr 2, 2014 at 7:16 PM, O. Hartmann  
> > 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

[Michael Butler]

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

[David Chisnall]

On 2 Apr 2014, at 20:53, Michael Butler  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

[Steve Kargl]

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

[FreeBSD Tinderbox]

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   -no

[head tinderbox] failure on i386/i386

[FreeBSD Tinderbox]

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-prot

[head tinderbox] failure on armv6/arm

[FreeBSD Tinderbox]

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: 

Re: gcc compilation broken with SVN r264042

[David Chisnall]

On 2 Apr 2014, at 21:21, Steve Kargl  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

[FreeBSD Tinderbox]

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__DBINTERFAC

[head tinderbox] failure on ia64/ia64

[FreeBSD Tinderbox]

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   

[head tinderbox] failure on mips64/mips

[FreeBSD Tinderbox]

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 

[head tinderbox] failure on powerpc/powerpc

[FreeBSD Tinderbox]

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 -DBROKE

Re: gcc compilation broken with SVN r264042

[Steve Kargl]

On Wed, Apr 02, 2014 at 09:46:19PM +0100, David Chisnall wrote:
> On 2 Apr 2014, at 21:21, Steve Kargl  
> 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

[FreeBSD Tinderbox]

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

[head tinderbox] failure on sparc64/sparc64

[FreeBSD Tinderbox]

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/

Re: login.conf --> UTF-8

[Andrey Chernov]

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

[jenkins-admin]

See 

___
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

[Garrett Wollman]

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

[Sean Bruno]

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

[Mark Linimon]

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

[Warner Losh]

On Apr 2, 2014, at 1:15 PM, Michael Butler  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

[FreeBSD Tinderbox]

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  
-Wmis

Re: login.conf --> UTF-8

[Steve Wills]

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

[Daniel Eischen]

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

[Steve Wills]

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

[Alexey Dokuchaev]

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

[Adrian Chadd]

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  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

[Robert Huff]

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 
#   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

[Mark Linimon]

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"

Re: Leaving the Desktop Market

[Kevin Oberman]

On Wed, Apr 2, 2014 at 7:14 PM, Alexey Dokuchaev  wrote:

> On Tue, Apr 01, 2014 at 03:10:22PM -0700, Kevin Oberman wrote:
> > FreeBSD desktop since 3.3 (makes me a newbie!) I really dislike
> pulseaudio
> > and have managed to live without it. Firefox works fine without it.
> > Unfortunately they dropped OSS support a while go, so I now must use
> alsa,
> > but it works well and without the pain of dealing with pulseaudio, a
> > solution in search of a problem it I ever saw one.
>
> PA should just die, of course, just like that kid's other "products".  OSS
> is so nice; it supports all those nifty features like per-application
> mixing
> and stuff, we have a very strong implementation of it (kudos to ariff@,
> let
> me remind us all: http://people.freebsd.org/~ariff/SOUND_4.TXT.html).
>
> Giving Firerox back its OSS support is my on TODO list, unfortunately I do
> not have any idea when (or if) I can look at it, but that would be a nice
> step in dealsificaion of our Ports Collection.  OSS was, and should remain,
> the standard Unixish sound system API.
>

Wow! That would be great! It's really annoying that some tools won't (not
can't)
do OSS. PA really had no reason to exist, but some people have such
determination
to do their own thing, even if it means throwing out a better solution.
(OK, so the
author did play some unfortunate games with licensing, but that was years
ago.)

> 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.
>
> Not always, unfortunately.  I also had a working pin override configuration
> in /boot/loader.conf, but after r236750 (major snd_hda driver rewrite) it
> stopped working.  I've reported it and tried to get some support from mav@
> but he never replied.  Since then, I have to carry pre-r236750 version of
> snd_hda(4) to have working sound.
>

Is that just in head? Do I have more fun to look forward to?

> Power is an issue and I find the current defaults suck. Read mav's article
> > on the subject on the wiki.
>
> From reading that article, I've only added hw.pci.do_power_nodriver="3" and
> hw.pci.do_power_resume="0" to /boot/loader.conf.  More aggressive settings,
> like cx_lowest="C2", made my laptop very sluggish and unpleasant to
> operate;
> powerd(8) behaves sanely with no tuning, so I wouldn't say that our current
> defaults suck.  The reason why we're behind on the "green" lane is because
> we generally do not pay much attention when it comes to power-saving during
> development of FreeBSD.  (I'd like to be proven wrong.)
>

The key poblem with power, as I have written several times is the
conflation of
TCC or throttling as power management tools. Mix them (they really don't
save power)
with Cx states is often worse than what you are seeing. It canl cause many
systems to
lock up .

Try setting:
powerd_enable="YES"
performance_cx_lowest="Cmax"
economy_cx_lowest="Cmax"
into /etc/rc.conf and putting:
# Disable CPU throttling
hint.p4tcc.0.disabled=1
hint.acpi_throttle.0.disabled=1
into /boot/loader.conf. That should work MUCH better and will really save
power (assuming
that your system supports better than C2 as C2 usually is a pretty minor
power savings.
C3 or higher is usually where things really start to improve.

I've read a paper from SDSC (San Diego Supercomputer Center) showing that
CX states
are by far and away the most significant power saver and they should cause
only very
trivial and unnoticeable impact on performance. Number two is EST, but that
is almost
always enabled on FreeBSD, so I assume that you have that running already
(or the
AMD equivalent).


> ./danfe
>
-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
___
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"