Re: Turning TESTS on by default

2014-06-06 Thread Konstantin Belousov 
On Fri, Jun 06, 2014 at 03:14:52PM -0400, Julio Merino wrote:
> Hello all,
> 
> 
> TL;DR
> -
> 
> I plan to turn the TESTS src.conf knob ON by default on Tuesday once I
> have been able to perform enough sanity-checks of the build and all of
> them pass.
> 
> The impact of this is that the FreeBSD Test Suite (see tests(7)) will
> be built and installed by default under /usr/tests/ along with the
> private atf libraries and binaries. There should be no other changes
> and this should be transparent to everyone.
> 
> If this happens to break the world in any way, we can trivially roll
> the change back to fix the fallout.
> 
> 
> Some details
> 
> 
> TESTS was never intended to be disabled by default. However, the
> original patches that were committed months ago related to this
> feature broke the build and the easiest way out (instead of reverting
> the commits) was to set the knob to disabled. Unfortunately, it stayed
> that way even after the discovered problems were fixed.
> 
> I am confident enough now that we have ironed out all major issues
> that this might introduce, so it is about time to enable TESTS by
> default again in HEAD.
> 
> The benefits of this are that 1) we allow end users (especially
> consumers of binary releases!) to run the tests out of the box, as it
> has always been intended; and 2) we will be able to run the official
> release builds through testing via Jenkins, instead of having to issue
> custom builds.
This is very weird and unprobable.  Users cannot care less about running
the test suite, they use OS to run applications.  IMO enabling installation 
of the stuff that bloats the system but have no practical use for the
system consumer should not be allowed by default.

It is the same as the debugging kernel. The INVARIANTS, WITNESS, DEBUG
and DIAGNOSTIC options are not enabled for the user consumption. There
was a similar argument to disable compiling the profiling static
libraries, which probably should be reconsidered since lib*_p.a is
absolutely useless on current toolchain and hardware.

> 
> Actual change: https://phabric.freebsd.org/D188
> 
> 
> I will update this thread when the change is committed and/or with any 
> updates.
> 
> Please let me know if I'm missing anything.
> 
> Cheers
> ___
> 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"


pgpzdDDc5mujo.pgp
Description: PGP signature

Re: Turning TESTS on by default

2014-06-06 Thread Kubilay Kocak 
On 7/06/2014 5:14 AM, Julio Merino wrote:
> Hello all,
> 
> 
> TL;DR
> -
> 
> I plan to turn the TESTS src.conf knob ON by default on Tuesday once I
> have been able to perform enough sanity-checks of the build and all of
> them pass.
> 
> The impact of this is that the FreeBSD Test Suite (see tests(7)) will
> be built and installed by default under /usr/tests/ along with the
> private atf libraries and binaries. There should be no other changes
> and this should be transparent to everyone.
> 
> If this happens to break the world in any way, we can trivially roll
> the change back to fix the fallout.
> 
> 
> Some details
> 
> 
> TESTS was never intended to be disabled by default. However, the
> original patches that were committed months ago related to this
> feature broke the build and the easiest way out (instead of reverting
> the commits) was to set the knob to disabled. Unfortunately, it stayed
> that way even after the discovered problems were fixed.
> 
> I am confident enough now that we have ironed out all major issues
> that this might introduce, so it is about time to enable TESTS by
> default again in HEAD.
> 
> The benefits of this are that 1) we allow end users (especially
> consumers of binary releases!) to run the tests out of the box, as it
> has always been intended; and 2) we will be able to run the official
> release builds through testing via Jenkins, instead of having to issue
> custom builds.
> 
> Actual change: https://phabric.freebsd.org/D188
> 
> 
> I will update this thread when the change is committed and/or with any 
> updates.
> 
> Please let me know if I'm missing anything.
> 
> Cheers
> ___
> 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"
> 

Julio,

Awesome! I look forward to automated review lint checks that test for
addition of tests, coverage++ and issue ID's in a changeset :]

On a related note, how challenging might it be to generate and expose
coverage metrics?

This is not to say they are a perfect measure of anything in particular,
but ought to provide us a good high level idea of important candidate
areas that would benefit from coverage and don't currently.

--
Koobs
___
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: Turning TESTS on by default

2014-06-06 Thread Julio Merino 
On Fri, Jun 6, 2014 at 3:50 PM, Jilles Tjoelker  wrote:
> This is certainly useful, but please fix installworld from a read-only
> (e.g. NFS) /usr/obj first. I reported this a while ago in
> http://lists.freebsd.org/pipermail/freebsd-testing/2014-May/000384.html
> "build Kyuafile.auto during buildworld, not installworld". This message
> includes patches, although they are a bit ugly.

OK; that's a blocker and had forgotten about it. Will fix.
___
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: Turning TESTS on by default

2014-06-06 Thread Jilles Tjoelker 
On Fri, Jun 06, 2014 at 03:14:52PM -0400, Julio Merino wrote:
> TL;DR
> -

> I plan to turn the TESTS src.conf knob ON by default on Tuesday once I
> have been able to perform enough sanity-checks of the build and all of
> them pass.

> The impact of this is that the FreeBSD Test Suite (see tests(7)) will
> be built and installed by default under /usr/tests/ along with the
> private atf libraries and binaries. There should be no other changes
> and this should be transparent to everyone.

> If this happens to break the world in any way, we can trivially roll
> the change back to fix the fallout.

> Some details
> 

> TESTS was never intended to be disabled by default. However, the
> original patches that were committed months ago related to this
> feature broke the build and the easiest way out (instead of reverting
> the commits) was to set the knob to disabled. Unfortunately, it stayed
> that way even after the discovered problems were fixed.

> I am confident enough now that we have ironed out all major issues
> that this might introduce, so it is about time to enable TESTS by
> default again in HEAD.

> The benefits of this are that 1) we allow end users (especially
> consumers of binary releases!) to run the tests out of the box, as it
> has always been intended; and 2) we will be able to run the official
> release builds through testing via Jenkins, instead of having to issue
> custom builds.

> Actual change: https://phabric.freebsd.org/D188

> I will update this thread when the change is committed and/or with any
> updates.

> Please let me know if I'm missing anything.

This is certainly useful, but please fix installworld from a read-only
(e.g. NFS) /usr/obj first. I reported this a while ago in
http://lists.freebsd.org/pipermail/freebsd-testing/2014-May/000384.html
"build Kyuafile.auto during buildworld, not installworld". This message
includes patches, although they are a bit ugly.

-- 
Jilles Tjoelker
___
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: Numeric Keypad does not works in 11.0-CURRENT amd64 r266916

2014-06-06 Thread Ranjan1018 . 
2014-06-01 11:00 GMT+02:00 Ranjan1018 . <21474...@gmail.com>:

> I have upgrade to FreeBDS CURRENT amd64, with vt (newcons),  version
> r266916 from r266536 and some keys on the keypad do not work: running the
> xev command I  receive no output for the ‘/’, ‘*’ and ‘-’ keys, but even
> for the ‘+’ key I have some strange output:
>
> r266916:
>
> ButtonPress event, serial 38, synthetic NO, window 0x2a1,
>
> root 0x9d, subw 0x0, time 708649, (79,90), root:(117,172),
>
> state 0x0, button 3, same_screen YES
>
>  ButtonRelease event, serial 38, synthetic NO, window 0x2a1,
>
> root 0x9d, subw 0x0, time 708649, (79,90), root:(117,172),
>
> state 0x400, button 3, same_screen YES
>
>  ButtonPress event, serial 38, synthetic NO, window 0x2a1,
>
> root 0x9d, subw 0x0, time 708649, (79,90), root:(117,172),
>
> state 0x0, button 3, same_screen YES
>
>  ButtonRelease event, serial 38, synthetic NO, window 0x2a1,
>
> root 0x9d, subw 0x0, time 708650, (79,90), root:(117,172),
>
> state 0x400, button 3, same_screen YES
>
>
> r266536, as expected:
>
> KeyPress event, serial 38, synthetic NO, window 0x2c1,
>
> root 0x9d, subw 0x0, time 368450, (114,90), root:(1233,135),
>
> state 0x0, keycode 86 (keysym 0xffab, KP_Add), same_screen YES,
>
> XLookupString gives 1 bytes: (2b) "+"
>
> XmbLookupString gives 1 bytes: (2b) "+"
>
> XFilterEvent returns: False
>
>  KeyRelease event, serial 38, synthetic NO, window 0x2c1,
>
> root 0x9d, subw 0x0, time 368654, (114,90), root:(1233,135),
>
> state 0x0, keycode 86 (keysym 0xffab, KP_Add), same_screen YES,
>
> XLookupString gives 1 bytes: (2b) "+"
>
> XFilterEvent returns: False
>
> Regards
> Maurizio
>

I have upgraded to r267068 and the problem is gone: the keyboard works as
expected.

Maurizio
___
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"

Turning TESTS on by default

2014-06-06 Thread Julio Merino 
Hello all,


TL;DR
-

I plan to turn the TESTS src.conf knob ON by default on Tuesday once I
have been able to perform enough sanity-checks of the build and all of
them pass.

The impact of this is that the FreeBSD Test Suite (see tests(7)) will
be built and installed by default under /usr/tests/ along with the
private atf libraries and binaries. There should be no other changes
and this should be transparent to everyone.

If this happens to break the world in any way, we can trivially roll
the change back to fix the fallout.


Some details


TESTS was never intended to be disabled by default. However, the
original patches that were committed months ago related to this
feature broke the build and the easiest way out (instead of reverting
the commits) was to set the knob to disabled. Unfortunately, it stayed
that way even after the discovered problems were fixed.

I am confident enough now that we have ironed out all major issues
that this might introduce, so it is about time to enable TESTS by
default again in HEAD.

The benefits of this are that 1) we allow end users (especially
consumers of binary releases!) to run the tests out of the box, as it
has always been intended; and 2) we will be able to run the official
release builds through testing via Jenkins, instead of having to issue
custom builds.

Actual change: https://phabric.freebsd.org/D188


I will update this thread when the change is committed and/or with any updates.

Please let me know if I'm missing anything.

Cheers
___
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: error during buildworld

2014-06-06 Thread David Wolfskill 
On Fri, Jun 06, 2014 at 01:53:54PM -0400, Robert Huff wrote:
> Hello:
>  On a system running:
> 
> FreeBSD 11.0-CURRENT #1 r264673: Sat Apr 19 09:43:10 EDT 2014  amd64
> 
>   and with the source updated at midnight US EST, running "make 
> buildworld"
> produces:
> ...
> cc -O2 -pipe   -gdwarf-2 -DRESCUE -std=gnu99 -Qunused-arguments  
> -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes 
> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow 
> -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs 
> -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations 
> -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
> -Wno-unused-const-variable -c /usr/src/sbin/camcontrol/camcontrol.c
> /usr/src/sbin/camcontrol/camcontrol.c:1393:29: error: use of undeclared 
> identifier 'ATA_SUPPORT_RCVSND_FPDMA_QUEUED'
>  parm->satacapabilities2 & ATA_SUPPORT_RCVSND_FPDMA_QUEUED ?
>^
> 1 error generated.
> *** Error code 1
> 
> Stop.
> make[3]: stopped in /usr/src/sbin/camcontrol
> *** Error code 1
> 
> 
>   Is anyone else seeing this?  If not, what have I most likely mangled?
>   (make.conf and src.conf are appended.)

My updates in head from r267099 -> r267149 this morning did not
encounter errors.

I started updating some "history" files (output of "uname -vp") as part
of my "smoke-test"for some of my systems (in particular, the ones I
update daily).  That information is linked off of
, which you are
welcme to examine.

> ...

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Taliban: Evil cowards with guns afraid of truth from a 14-year old girl.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpTZKTbCU4E_.pgp
Description: PGP signature

Re: panic in deadlkres() on r267110

2014-06-06 Thread Sean Bruno 
On Fri, 2014-06-06 at 10:12 -0400, Glen Barber wrote:
> Two machines in the cluster panic last night with the same backtrace.
> It is unclear yet exactly what was happening on the systems, but both
> are port building machines using ports-mgmt/tinderbox.
> 
> Any ideas or information on how to further debug this would be
> appreciated.
> 
> Script started on Fri Jun  6 14:01:53 2014
> command: /bin/sh
> # uname -a
> FreeBSD redbuild04.nyi.freebsd.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1 
> r267110: Thu Jun  5 15:57:43 UTC 2014 
> sbr...@redbuild04.nyi.freebsd.org:/usr/obj/usr/src/sys/REDBUILD  amd64
> # kgdb ./kernel.debug /var/crash/vmcore.0
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "amd64-marcel-freebsd"...
> 
> Unread portion of the kernel message buffer:
> panic: deadlkres: possible deadlock detected on allproc_lock
> 
> cpuid = 17
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe1838702a20
> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1838702ad0
> panic() at panic+0x155/frame 0xfe1838702b50
> deadlkres() at deadlkres+0x42a/frame 0xfe1838702bb0
> fork_exit() at fork_exit+0x9a/frame 0xfe1838702bf0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfe1838702bf0
> --- trap 0, rip = 0, rsp = 0xfe1838702cb0, rbp = 0 ---
> KDB: enter: panic
> 
> Reading symbols from /boot/kernel/zfs.ko.symbols...done.
> Loaded symbols for /boot/kernel/zfs.ko.symbols
> Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
> Loaded symbols for /boot/kernel/opensolaris.ko.symbols
> Reading symbols from /boot/kernel/ums.ko.symbols...done.
> Loaded symbols for /boot/kernel/ums.ko.symbols
> Reading symbols from /boot/kernel/linprocfs.ko.symbols...done.
> Loaded symbols for /boot/kernel/linprocfs.ko.symbols
> Reading symbols from /boot/kernel/linux.ko.symbols...done.
> Loaded symbols for /boot/kernel/linux.ko.symbols
> #0  doadump (textdump=-946873840) at pcpu.h:219
> 219 __asm("movq %%gs:%1,%0" : "=r" (td)
> (kgdb) bt
> #0  doadump (textdump=-946873840) at pcpu.h:219
> #1  0x8034e865 in db_fncall (dummy1=, 
> dummy2=, dummy3=, 
> dummy4=) at /usr/src/sys/ddb/db_command.c:578
> #2  0x8034e54d in db_command (cmd_table=0x0)
> at /usr/src/sys/ddb/db_command.c:449
> #3  0x8034e2c4 in db_command_loop ()
> at /usr/src/sys/ddb/db_command.c:502
> #4  0x80350d20 in db_trap (type=, code=0)
> at /usr/src/sys/ddb/db_main.c:231
> #5  0x809a9bd9 in kdb_trap (type=3, code=0, tf=)
> at /usr/src/sys/kern/subr_kdb.c:656
> #6  0x80dc00e3 in trap (frame=0xfe1838702a00)
> at /usr/src/sys/amd64/amd64/trap.c:551
> #7  0x80da29c2 in calltrap ()
> at /usr/src/sys/amd64/amd64/exception.S:231
> #8  0x809a933e in kdb_enter (why=0x81039a72 "panic", 
> msg=) at cpufunc.h:63
> #9  0x8096a8b5 in panic (fmt=)
> at /usr/src/sys/kern/kern_shutdown.c:749
> #10 0x8090d16a in deadlkres () at /usr/src/sys/kern/kern_clock.c:203
> #11 0x8093170a in fork_exit (callout=0x8090cd40 , 
> arg=0x0, frame=0xfe1838702c00) at /usr/src/sys/kern/kern_fork.c:977
> ---Type  to continue, or q  to quit---
> #12 0x80da2efe in fork_trampoline ()
> at /usr/src/sys/amd64/amd64/exception.S:605
> #13 0x in ?? ()
> Current language:  auto; currently minimal
> (kgdb) fr 10
> #10 0x8090d16a in deadlkres () at /usr/src/sys/kern/kern_clock.c:203
> 203 panic("%s: possible deadlock detected on 
> allproc_lock\n",
> (kgdb) l
> 198  * priority inversion problem leading to starvation.
> 199  * If the lock can't be held after 100 tries, panic.
> 200  */
> 201 if (!sx_try_slock(&allproc_lock)) {
> 202 if (tryl > 100)
> 203 panic("%s: possible deadlock detected on 
> allproc_lock\n",
> 204 __func__);
> 205 tryl++;
> 206 pause("allproc", sleepfreq * hz);
> 207 continue;
> (kgdb) up
> #11 0x8093170a in fork_exit (callout=0x8090cd40 , 
> arg=0x0, frame=0xfe1838702c00) at /usr/src/sys/kern/kern_fork.c:977
> 977 callout(arg, frame);
> (kgdb) l
> 972  * cpu_set_fork_handler intercepts this function call to
> 973  * have this call a non-return function to stay in kernel 
> mode.
> 974  * initproc has its own fork handler, but it does return.
> 975

error during buildworld

2014-06-06 Thread Robert Huff 

Hello:
On a system running:

FreeBSD 11.0-CURRENT #1 r264673: Sat Apr 19 09:43:10 EDT 2014  amd64

and with the source updated at midnight US EST, running "make 
buildworld"
produces:

cc -O2 -pipe   -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh 
-D_PATH_TCSHELL='"/rescue/csh"' -DNO_NLS_CATALOGS -gdwarf-2 -DRESCUE -std=gnu99 
-Qunused-arguments  -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c 
/usr/src/bin/csh/../../contrib/tcsh/tc.os.c
cc -O2 -pipe   -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh 
-D_PATH_TCSHELL='"/rescue/csh"' -DNO_NLS_CATALOGS -gdwarf-2 -DRESCUE -std=gnu99 
-Qunused-arguments  -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c 
/usr/src/bin/csh/../../contrib/tcsh/tc.printf.c
cc -O2 -pipe   -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh 
-D_PATH_TCSHELL='"/rescue/csh"' -DNO_NLS_CATALOGS -gdwarf-2 -DRESCUE -std=gnu99 
-Qunused-arguments  -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c 
/usr/src/bin/csh/../../contrib/tcsh/tc.prompt.c
cc -O2 -pipe   -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh 
-D_PATH_TCSHELL='"/rescue/csh"' -DNO_NLS_CATALOGS -gdwarf-2 -DRESCUE -std=gnu99 
-Qunused-arguments  -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c 
/usr/src/bin/csh/../../contrib/tcsh/tc.sched.c
cc -O2 -pipe   -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh 
-D_PATH_TCSHELL='"/rescue/csh"' -DNO_NLS_CATALOGS -gdwarf-2 -DRESCUE -std=gnu99 
-Qunused-arguments  -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c 
/usr/src/bin/csh/../../contrib/tcsh/tc.sig.c
cc -O2 -pipe   -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh 
-D_PATH_TCSHELL='"/rescue/csh"' -DNO_NLS_CATALOGS -gdwarf-2 -DRESCUE -std=gnu99 
-Qunused-arguments  -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c 
/usr/src/bin/csh/../../contrib/tcsh/tc.str.c
cc -O2 -pipe   -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh 
-D_PATH_TCSHELL='"/rescue/csh"' -DNO_NLS_CATALOGS -gdwarf-2 -DRESCUE -std=gnu99 
-Qunused-arguments  -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c 
/usr/src/bin/csh/../../contrib/tcsh/tc.vers.c
cc -O2 -pipe   -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh 
-D_PATH_TCSHELL='"/rescue/csh"' -DNO_NLS_CATALOGS -gdwarf-2 -DRESCUE -std=gnu99 
-Qunused-arguments  -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c 
/usr/src/bin/csh/../../contrib/tcsh/tc.who.c
cc -O2 -pipe   -I. -I/usr/src/bin/csh -I/usr/src/bin/csh/../../contrib/tcsh 
-D_PATH_TCSHELL='"/rescue/csh"' -DNO_NLS_CATALOGS -gdwarf-2 -DRESCUE -std=gnu99 
-Qunused-arguments  -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign 
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-switch -Wno-switch-enum -Wno-knr-promoted-

Re: panic in deadlkres() on r267110

2014-06-06 Thread Ryan Stone 
On Fri, Jun 6, 2014 at 11:33 AM, Glen Barber  wrote:
> #4  0x8092fa39 in fork1 (td=0xf813ae7f4920, flags=20, 
> pages=Cannot access memory at address 0x4
> )
> at /usr/src/sys/kern/kern_fork.c:268

This looks like a suspicious piece of code.  Could something be
causing the kernel to go into an infinite loop there?
___
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: panic in deadlkres() on r267110

2014-06-06 Thread Glen Barber 
On Fri, Jun 06, 2014 at 11:06:40AM -0400, Glen Barber wrote:
> On Fri, Jun 06, 2014 at 07:23:49AM -0700, Sean Bruno wrote:
> > On Fri, 2014-06-06 at 10:12 -0400, Glen Barber wrote:
> > > Two machines in the cluster panic last night with the same backtrace.
> > > It is unclear yet exactly what was happening on the systems, but both
> > > are port building machines using ports-mgmt/tinderbox.
> > > 
> > > Any ideas or information on how to further debug this would be
> > > appreciated.
> > > 
> > These machines were happily running r266621 previously to this update
> > yesterday.  So, that gives us a bisection point.
> > 
> 
> Some more debug information.  Thank you to Attilio for information on
> what data to get.
> 

Sorry, I did not mask the bits properly.

Script started on Fri Jun  6 15:20:14 2014
command: /bin/sh
# kgdb ./kernel.debug /var/crash/vmcore.0
[...]
#0  doadump (textdump=-946873840) at pcpu.h:219
219 __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) p/x allproc_lock.sx_lock
$1 = 0xf813ae7f4924
Current language:  auto; currently minimal
(kgdb) p ((struct thread *)0xf813ae7f4920)
$4 = (struct thread *) 0xf813ae7f4920
(kgdb) p $4->td_tid
$5 = 195038
(kgdb) tid 195038
[Switching to thread 94414 (Thread 195038)]#0  0x80daf1f8 in 
cpustop_handler () at /usr/src/sys/amd64/amd64/mp_machdep.c:1432
1432savectx(&stoppcbs[cpu]);
(kgdb) bt
#0  0x80daf1f8 in cpustop_handler ()
at /usr/src/sys/amd64/amd64/mp_machdep.c:1432
#1  0x80daf1bf in ipi_nmi_handler ()
at /usr/src/sys/amd64/amd64/mp_machdep.c:1417
#2  0x80dbfcba in trap (frame=0xfe17d5389f30)
at /usr/src/sys/amd64/amd64/trap.c:189
#3  0x80da2e03 in nmi_calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:504
#4  0x8092fa39 in fork1 (td=0xf813ae7f4920, flags=20, pages=Cannot 
access memory at address 0x4
)
at /usr/src/sys/kern/kern_fork.c:268
#5  0x8092f00f in sys_fork (td=0xf813ae7f4920, 
uap=) at /usr/src/sys/kern/kern_fork.c:106
#6  0x80dc118b in amd64_syscall (td=0xf813ae7f4920, traced=0)
at subr_syscall.c:133
#7  0x80da2cab in Xfast_syscall ()
at /usr/src/sys/amd64/amd64/exception.S:390
#8  0x000800d46d1a in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) 

Glen



pgpI1kaMzAPLk.pgp
Description: PGP signature

Re: panic in deadlkres() on r267110

2014-06-06 Thread Attilio Rao 
On Fri, Jun 6, 2014 at 5:06 PM, Glen Barber  wrote:
> On Fri, Jun 06, 2014 at 07:23:49AM -0700, Sean Bruno wrote:
>> On Fri, 2014-06-06 at 10:12 -0400, Glen Barber wrote:
>> > Two machines in the cluster panic last night with the same backtrace.
>> > It is unclear yet exactly what was happening on the systems, but both
>> > are port building machines using ports-mgmt/tinderbox.
>> >
>> > Any ideas or information on how to further debug this would be
>> > appreciated.
>> >
>> These machines were happily running r266621 previously to this update
>> yesterday.  So, that gives us a bisection point.
>>
>
> Some more debug information.  Thank you to Attilio for information on
> what data to get.
>
> Script started on Fri Jun  6 15:00:53 2014
> command: /bin/sh
> # kgdb ./kernel.debug /var/crash/vmcore.0
> [...]
> #0  doadump (textdump=-946873840) at pcpu.h:219
> 219 __asm("movq %%gs:%1,%0" : "=r" (td)
> (kgdb) p/x allproc_lock.sx_lock
> $1 = 0xf813ae7f4924
> Current language:  auto; currently minimal
> (kgdb) p ((struct thread *)0xf813ae7f4924)

The actual thread address is: 0xf813ae7f4920.

Then look at the GDB threads list and match with the tid.

Attilio
___
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: panic in deadlkres() on r267110

2014-06-06 Thread Glen Barber 
On Fri, Jun 06, 2014 at 07:23:49AM -0700, Sean Bruno wrote:
> On Fri, 2014-06-06 at 10:12 -0400, Glen Barber wrote:
> > Two machines in the cluster panic last night with the same backtrace.
> > It is unclear yet exactly what was happening on the systems, but both
> > are port building machines using ports-mgmt/tinderbox.
> > 
> > Any ideas or information on how to further debug this would be
> > appreciated.
> > 
> These machines were happily running r266621 previously to this update
> yesterday.  So, that gives us a bisection point.
> 

Some more debug information.  Thank you to Attilio for information on
what data to get.

Script started on Fri Jun  6 15:00:53 2014
command: /bin/sh
# kgdb ./kernel.debug /var/crash/vmcore.0
[...]
#0  doadump (textdump=-946873840) at pcpu.h:219
219 __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) p/x allproc_lock.sx_lock
$1 = 0xf813ae7f4924
Current language:  auto; currently minimal
(kgdb) p ((struct thread *)0xf813ae7f4924)
$2 = (struct thread *) 0xf813ae7f4924
(kgdb) p $2->td_tid
$3 = 0
(kgdb) ^D
# ^D
Script done on Fri Jun  6 15:03:19 2014

Glen



pgpAoA_3Wzmb1.pgp
Description: PGP signature

Re: panic in deadlkres() on r267110

2014-06-06 Thread Ryan Stone 
On Fri, Jun 6, 2014 at 10:12 AM, Glen Barber  wrote:
> Two machines in the cluster panic last night with the same backtrace.
> It is unclear yet exactly what was happening on the systems, but both
> are port building machines using ports-mgmt/tinderbox.
>
> Any ideas or information on how to further debug this would be
> appreciated.

The first thing that I would do is try to figure out who holds the
allproc_lock.  If the lock is held exclusively then
the pointer to the thread struct will be in allproc_lock.sx_lock.

If the lock is held shared then it gets trickier.  I'm not sure if
there is a better possible way than doing a thread apply all bt in
kgdb and finding which stack(s) could hold allproc_lock.
___
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: panic in deadlkres() on r267110

2014-06-06 Thread Sean Bruno 
On Fri, 2014-06-06 at 10:12 -0400, Glen Barber wrote:
> Two machines in the cluster panic last night with the same backtrace.
> It is unclear yet exactly what was happening on the systems, but both
> are port building machines using ports-mgmt/tinderbox.
> 
> Any ideas or information on how to further debug this would be
> appreciated.
> 
These machines were happily running r266621 previously to this update
yesterday.  So, that gives us a bisection point.

sean


> Script started on Fri Jun  6 14:01:53 2014
> command: /bin/sh
> # uname -a
> FreeBSD redbuild04.nyi.freebsd.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1 
> r267110: Thu Jun  5 15:57:43 UTC 2014 
> sbr...@redbuild04.nyi.freebsd.org:/usr/obj/usr/src/sys/REDBUILD  amd64
> # kgdb ./kernel.debug /var/crash/vmcore.0
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "amd64-marcel-freebsd"...
> 
> Unread portion of the kernel message buffer:
> panic: deadlkres: possible deadlock detected on allproc_lock
> 
> cpuid = 17
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe1838702a20
> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1838702ad0
> panic() at panic+0x155/frame 0xfe1838702b50
> deadlkres() at deadlkres+0x42a/frame 0xfe1838702bb0
> fork_exit() at fork_exit+0x9a/frame 0xfe1838702bf0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfe1838702bf0
> --- trap 0, rip = 0, rsp = 0xfe1838702cb0, rbp = 0 ---
> KDB: enter: panic
> 
> Reading symbols from /boot/kernel/zfs.ko.symbols...done.
> Loaded symbols for /boot/kernel/zfs.ko.symbols
> Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
> Loaded symbols for /boot/kernel/opensolaris.ko.symbols
> Reading symbols from /boot/kernel/ums.ko.symbols...done.
> Loaded symbols for /boot/kernel/ums.ko.symbols
> Reading symbols from /boot/kernel/linprocfs.ko.symbols...done.
> Loaded symbols for /boot/kernel/linprocfs.ko.symbols
> Reading symbols from /boot/kernel/linux.ko.symbols...done.
> Loaded symbols for /boot/kernel/linux.ko.symbols
> #0  doadump (textdump=-946873840) at pcpu.h:219
> 219 __asm("movq %%gs:%1,%0" : "=r" (td)
> (kgdb) bt
> #0  doadump (textdump=-946873840) at pcpu.h:219
> #1  0x8034e865 in db_fncall (dummy1=, 
> dummy2=, dummy3=, 
> dummy4=) at /usr/src/sys/ddb/db_command.c:578
> #2  0x8034e54d in db_command (cmd_table=0x0)
> at /usr/src/sys/ddb/db_command.c:449
> #3  0x8034e2c4 in db_command_loop ()
> at /usr/src/sys/ddb/db_command.c:502
> #4  0x80350d20 in db_trap (type=, code=0)
> at /usr/src/sys/ddb/db_main.c:231
> #5  0x809a9bd9 in kdb_trap (type=3, code=0, tf=)
> at /usr/src/sys/kern/subr_kdb.c:656
> #6  0x80dc00e3 in trap (frame=0xfe1838702a00)
> at /usr/src/sys/amd64/amd64/trap.c:551
> #7  0x80da29c2 in calltrap ()
> at /usr/src/sys/amd64/amd64/exception.S:231
> #8  0x809a933e in kdb_enter (why=0x81039a72 "panic", 
> msg=) at cpufunc.h:63
> #9  0x8096a8b5 in panic (fmt=)
> at /usr/src/sys/kern/kern_shutdown.c:749
> #10 0x8090d16a in deadlkres () at /usr/src/sys/kern/kern_clock.c:203
> #11 0x8093170a in fork_exit (callout=0x8090cd40 , 
> arg=0x0, frame=0xfe1838702c00) at /usr/src/sys/kern/kern_fork.c:977
> ---Type  to continue, or q  to quit---
> #12 0x80da2efe in fork_trampoline ()
> at /usr/src/sys/amd64/amd64/exception.S:605
> #13 0x in ?? ()
> Current language:  auto; currently minimal
> (kgdb) fr 10
> #10 0x8090d16a in deadlkres () at /usr/src/sys/kern/kern_clock.c:203
> 203 panic("%s: possible deadlock detected on 
> allproc_lock\n",
> (kgdb) l
> 198  * priority inversion problem leading to starvation.
> 199  * If the lock can't be held after 100 tries, panic.
> 200  */
> 201 if (!sx_try_slock(&allproc_lock)) {
> 202 if (tryl > 100)
> 203 panic("%s: possible deadlock detected on 
> allproc_lock\n",
> 204 __func__);
> 205 tryl++;
> 206 pause("allproc", sleepfreq * hz);
> 207 continue;
> (kgdb) up
> #11 0x8093170a in fork_exit (callout=0x8090cd40 , 
> arg=0x0, frame=0xfe1838702c00) at /usr/src/sys/kern/kern_fork.c:977
> 977 callout(arg, frame);
> (kgdb) l
> 972  * cpu_set_fork_handler intercepts this function call to
> 973  * have this call a non-ret

panic in deadlkres() on r267110

2014-06-06 Thread Glen Barber 
Two machines in the cluster panic last night with the same backtrace.
It is unclear yet exactly what was happening on the systems, but both
are port building machines using ports-mgmt/tinderbox.

Any ideas or information on how to further debug this would be
appreciated.

Script started on Fri Jun  6 14:01:53 2014
command: /bin/sh
# uname -a
FreeBSD redbuild04.nyi.freebsd.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1 
r267110: Thu Jun  5 15:57:43 UTC 2014 
sbr...@redbuild04.nyi.freebsd.org:/usr/obj/usr/src/sys/REDBUILD  amd64
# kgdb ./kernel.debug /var/crash/vmcore.0
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
panic: deadlkres: possible deadlock detected on allproc_lock

cpuid = 17
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe1838702a20
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1838702ad0
panic() at panic+0x155/frame 0xfe1838702b50
deadlkres() at deadlkres+0x42a/frame 0xfe1838702bb0
fork_exit() at fork_exit+0x9a/frame 0xfe1838702bf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe1838702bf0
--- trap 0, rip = 0, rsp = 0xfe1838702cb0, rbp = 0 ---
KDB: enter: panic

Reading symbols from /boot/kernel/zfs.ko.symbols...done.
Loaded symbols for /boot/kernel/zfs.ko.symbols
Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
Loaded symbols for /boot/kernel/opensolaris.ko.symbols
Reading symbols from /boot/kernel/ums.ko.symbols...done.
Loaded symbols for /boot/kernel/ums.ko.symbols
Reading symbols from /boot/kernel/linprocfs.ko.symbols...done.
Loaded symbols for /boot/kernel/linprocfs.ko.symbols
Reading symbols from /boot/kernel/linux.ko.symbols...done.
Loaded symbols for /boot/kernel/linux.ko.symbols
#0  doadump (textdump=-946873840) at pcpu.h:219
219 __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) bt
#0  doadump (textdump=-946873840) at pcpu.h:219
#1  0x8034e865 in db_fncall (dummy1=, 
dummy2=, dummy3=, 
dummy4=) at /usr/src/sys/ddb/db_command.c:578
#2  0x8034e54d in db_command (cmd_table=0x0)
at /usr/src/sys/ddb/db_command.c:449
#3  0x8034e2c4 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:502
#4  0x80350d20 in db_trap (type=, code=0)
at /usr/src/sys/ddb/db_main.c:231
#5  0x809a9bd9 in kdb_trap (type=3, code=0, tf=)
at /usr/src/sys/kern/subr_kdb.c:656
#6  0x80dc00e3 in trap (frame=0xfe1838702a00)
at /usr/src/sys/amd64/amd64/trap.c:551
#7  0x80da29c2 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:231
#8  0x809a933e in kdb_enter (why=0x81039a72 "panic", 
msg=) at cpufunc.h:63
#9  0x8096a8b5 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:749
#10 0x8090d16a in deadlkres () at /usr/src/sys/kern/kern_clock.c:203
#11 0x8093170a in fork_exit (callout=0x8090cd40 , 
arg=0x0, frame=0xfe1838702c00) at /usr/src/sys/kern/kern_fork.c:977
---Type  to continue, or q  to quit---
#12 0x80da2efe in fork_trampoline ()
at /usr/src/sys/amd64/amd64/exception.S:605
#13 0x in ?? ()
Current language:  auto; currently minimal
(kgdb) fr 10
#10 0x8090d16a in deadlkres () at /usr/src/sys/kern/kern_clock.c:203
203 panic("%s: possible deadlock detected on 
allproc_lock\n",
(kgdb) l
198  * priority inversion problem leading to starvation.
199  * If the lock can't be held after 100 tries, panic.
200  */
201 if (!sx_try_slock(&allproc_lock)) {
202 if (tryl > 100)
203 panic("%s: possible deadlock detected on 
allproc_lock\n",
204 __func__);
205 tryl++;
206 pause("allproc", sleepfreq * hz);
207 continue;
(kgdb) up
#11 0x8093170a in fork_exit (callout=0x8090cd40 , 
arg=0x0, frame=0xfe1838702c00) at /usr/src/sys/kern/kern_fork.c:977
977 callout(arg, frame);
(kgdb) l
972  * cpu_set_fork_handler intercepts this function call to
973  * have this call a non-return function to stay in kernel mode.
974  * initproc has its own fork handler, but it does return.
975  */
976 KASSERT(callout != NULL, ("NULL callout in fork_exit"));
977 callout(arg, frame);
978 
979 /*
980  * Check if a kernel thread misbehaved and returned from its 
main
981  * function.

Re: ZFS secondarycache on SSD problem on r255173

2014-06-06 Thread Matthew D. Fuller 
On Fri, Apr 25, 2014 at 08:26:52PM -0500 I heard the voice of
Matthew D. Fuller, and lo! it spake thus:
> On Mon, Mar 03, 2014 at 11:17:05AM +0200 I heard the voice of
> Andriy Gapon, and lo! it spake thus:
> > 
> > I noticed that on some of our systems we were getting a clearly
> > abnormal number of l2arc checksum errors accounted in l2_cksum_bad.
> > [...]
> > I propose the following patch which has been tested and seems to fix
> > the problem without introducing any side effects:
> 
> I've been running this for >2 weeks now without any cksum_bad's
> showing up (long enough that without it, I'd have expected them),
> and no other obvious side effects.

Another 6 weeks on, still working fine and still seems to fix the
issue.  Any reason not to commit it?


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
___
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: official pkg repo with WITHOUT_X11=true

2014-06-06 Thread Jean-Sébastien Pédron 
On 28.05.2014 18:10, Dirk Engling wrote:
> set during poudriere builds. Default options for some graphic related
> ports like graphics/gd unfortunally litter all my jails with their libX*
> dependencies.

For those graphics libraries, the dependency to libX11 is only required
to support the XPM image format, AFAIK. I believe this format isn't
widely used nowadays. Would it make sense to disable this support by
default?

-- 
Jean-Sébastien Pédron



signature.asc
Description: OpenPGP digital signature