date:20141105

Build failed in Jenkins: FreeBSD_HEAD #1780

2014-11-05 Thread jenkins-admin

See 

Changes:

[gjb] Bump __FreeBSD_version after SA-14:23, SA-14:24,
SA-14:25.

Approved by:re (implicit)
Sponsored by:   The FreeBSD Foundation

[dteske] Upon second-thought (following r274144), remove spurious (unused)
line-noise (libdialog never lived in lib/ -- but rather the noise
came from translating a comment that was introduced 16 years ago
via r40306; translation from comment to code occurred via r267511).

MFC after:  3 days
Reviewed by:ngie
X-MFC-to:   stable/10

[mav] Add to CTL support for logical block provisioning threshold notifications.

For ZVOL-backed LUNs this allows to inform initiators if storage's used or
available spaces get above/below the configured thresholds.

MFC after:  2 weeks
Sponsored by:   iXsystems, Inc.

--
[...truncated 139428 lines...]
--- gnu.all__D ---
--- groff_www.7 ---
Making groff_www.7 from 

--- lib.all__D ---
--- h_stpncpy ---
cc  -O2 -pipe   -std=gnu99 -fstack-protector -Wsystem-headers -Wall 
-Wno-format-y2k -Wno-uninitialized -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 
-Qunused-arguments  -o h_stpncpy h_stpncpy.o 
(cd 
 && 
make -f 

 _RECURSING_PROGS=  SUBDIR= PROG=h_strcat  DEPENDFILE=.depend.h_strcat 
.MAKE.DEPENDFILE=.depend.h_strcat  )
--- gnu.all__D ---
--- groff_ms.7.gz ---
gzip -cn groff_ms.7 > groff_ms.7.gz
--- groff_man.7.gz ---
--- lib.all__D ---
--- h_strcat.o ---
--- gnu.all__D ---
gzip -cn groff_man.7 > groff_man.7.gz
--- lib.all__D ---
cc  -O2 -pipe   -std=gnu99 -fstack-protector -Wsystem-headers -Wall 
-Wno-format-y2k -Wno-uninitialized -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 
-Qunused-arguments -c 

--- gnu.all__D ---
--- groff_me.7.gz ---
gzip -cn groff_me.7 > groff_me.7.gz
--- groff_mdoc.7.gz ---
gzip -cn groff_mdoc.7 > groff_mdoc.7.gz
--- lib.all__D ---
--- h_strcat ---
cc  -O2 -pipe   -std=gnu99 -fstack-protector -Wsystem-headers -Wall 
-Wno-format-y2k -Wno-uninitialized -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 
-Qunused-arguments  -o h_strcat h_strcat.o 
--- gnu.all__D ---
--- groff_trace.7.gz ---
gzip -cn groff_trace.7 > groff_trace.7.gz
--- lib.all__D ---
(cd 
 && 
make -f 

 _RECURSING_PROGS=  SUBDIR= PROG=h_strcpy  DEPENDFILE=.depend.h_strcpy 
.MAKE.DEPENDFILE=.depend.h_strcpy  )
--- gnu.all__D ---
--- groff_www.7.gz ---
gzip -cn groff_www.7 > groff_www.7.gz
--- all_subdir_rcs ---
===> gnu/usr.bin/rcs (all)
--- _sub.all ---
===> gnu/usr.bin/rcs/lib (all)
--- lib.all__D ---
--- h_strcpy.o ---
cc  -O2 -pipe   -std=gnu99 -fstack-protector -Wsystem-headers -Wall 
-Wno-format-y2k -Wno-uninitialized -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 
-Qunused-arguments -c 

--- h_strcpy ---
cc  -O2 -pipe   -std=gnu99 -fstack-protector -Wsystem-headers -Wall 
-Wno-format-y2k -Wno-uninitialized -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 
-Qunused-arguments  -o h_strcpy h_strcpy.o 
--- rescue.all__D ---
--- geom_bsd_enc.o ---
cc  -O2 -pipe   -DRESCUE -std=gnu99 -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

Re: android bsd connectivity tools etc ?

2014-11-05 Thread Chris H

On Thu, 06 Nov 2014 00:02:59 + Jamie Landeg-Jones 
wrote

> "Julian H. Stacey"  wrote:
> 
> Firstly, if you haven't already, I'd recommend 'Android terminal
> emulator' and 'hackers keyboard' - both free from the Play store.
> 
> To be able to create startup scripts without reflashing etc. you
> must have root, and be able to write the file
> "/system/etc/install_recovery.sh"
> 
> > NFS [& AMD] [& SSH] would be ideal for me.
> >
> > I had a look on my Samsung Galaxy Note 3, with Android 4.4.2 kernel
> > 3.4.0, & skimmed index of the 182 page pdf, but I dont know how to
> > tell if mine has NFS ? Or how to get it.
> 
> I have the dropbear ssh client and server. I've not managed to compile
> them or openssh yet - instead I grabbed the binaries (opened source)
> from inside one of the free sshd server apps on the play store.
> 
> One of my newer devices doesn't come with NFS, the others do. You need
> to find the correct nfs.ko kernel module for your kernel, and/or
> recompile the linux kernel - both things I've not achieved yet
> (running FreeBSD and not Linux/Windows makes things harder with no
> SDK etc.) but all this is part of what I'm investigating at the
> moment, so it would be great to be able to share notes with someone
> else sith a FreeBSD mindset.
> 
> If you have nfs already, the standard mount should work from root:
> 
>  | 23:29 [3] (1) root@tabbycat:"/usr/users/jamie" # mkdir /tmp/test
>  | 23:29 [3] (2) root@tabbycat:"/usr/users/jamie" # mount -o nolock,hard,ro
> lnfs:/nfs/b/tabbycat/ /tmp/test  | 23:30 [3] (3)
> root@tabbycat:"/usr/users/jamie" # df -h  | Filesystem  Size 
> Used Available Capacity  Mounted on  | tmpfs 176.7M  
>   52.0K176.7M 0%/dev  | devpts 0
> 0 0 0%/dev/pts  | proc   0 0 
>0 0%/proc  | sysfs  0 0   
>  0 0%/sys  | none   0 0 0
> 0%/acct  | tmpfs 176.7M 0176.7M 0%   
> /mnt/asec  | tmpfs 176.7M 0176.7M 0%   
> /mnt/obb  | /dev/block/nandd 1007.9M282.6M725.3M28%   
> /system  | /dev/block/nande 1007.9M137.4M870.5M14%   
> /data  | /dev/block/nandh  252.0M  4.3M247.7M 2%   
> /cache  | /dev/block/nandd 1007.9M282.6M725.3M28%/bin
>  | hidden 0 0 0 0%   
> /system/.bin_mount  | tmpfs 128.0M  8.0K128.0M   
>  0%/tmp  | /dev/block/nandj2 718.0M404.7M313.3M56%   
> /usr  | /dev/block/nandj3 100.4M 19.3M 81.1M19%/var
>  | tmpfs   1.0M  4.0K   1020.0K 0%/var/run
>  | /dev/block/mmcblk0p2   18.6G  1.3G 16.4G 7%/data2
>  | /dev/block/vold/93:76  23.5M  8.0K 23.5M 0%/mnt/extsd
>  | /dev/block/vold/179:3  10.5G  5.5G  5.0G52%/mnt/sdcard
>  | /dev/block/vold/179:3  10.5G  5.5G  5.0G52%   
> /mnt/secure/asec  | tmpfs  0 0 0
> 0%/mnt/sdcard/.android_secure  | lnfs:/nfs/j/Misc/   1.8T 
> 1.5T143.7G91%/mnt/sdcard/Misc  | lnfs:/nfs/j/Music/  1.8T
>  1.5T143.7G91%/mnt/sdcard/Music/lapcat  | lnfs:/nfs/j/Videos/
> 1.8T  1.5T143.7G91%/mnt/sdcard/Videos/lapcat
>  | lnfs:/nfs/j/Pictures/   1.8T  1.5T143.7G91%   
> /mnt/sdcard/Pictures/lapcat  | lnfs:/nfs/APK-archives/ 1.8T  1.5T
>143.7G91%/APK-archives  | lnfs:/nfs/b/tabbycat/   1.8T 
> 1.5T143.7G91%/backups  | lnfs:/nfs/b/tabbycat/   1.8T 
> 1.5T143.7G91%/tmp/test  | 
>  | 23:30 [3] (4) root@tabbycat:"/usr/users/jamie" # l /tmp/test
>  | total 32
>  |  4 drwxr-x---9 root root   512 Nov  1 07:28 ./
>  |  0 drwxrwxrwt3 root root   160 Nov  5 23:33 ../
>  |  4 drwxr-xr-x   20 rootfs   rootfs1024 Nov  5 09:23 BASE/
>  |  4 drwxr-x---2 root root   512 Nov  5 16:35 logs/
>  |  4 drwxr-x---2 root root   512 Oct 25 11:49 monthly/
>  |  4 drwxr-x---7 root root   512 Nov  5 16:36 often/
>  |  4 drwxr-x---5 root root   512 Nov  1 07:49 old/
>  |  4 drwxr-x---2 root root   512 Oct 29 09:20 partial/
>  |  4 drwxr-x---4 root root   512 Nov  3 03:35 weekly/
>  | 
>  | 23:30 [3] (5) root@tabbycat:"/usr/users/jamie" #
> 
> I'd be more than happy to share my findings/code/ etc. with you,
> maybe private mail would be better?
> 
> As a quick 'summary', I use FreeBSD exclusively on my servers etc., but
> do have 5 Android devices.
> 
> My achievements with them (not currently comple

Build failed in Jenkins: FreeBSD_HEAD-tests2 #193

2014-11-05 Thread jenkins-admin

See 

--
Started by build flow Build_Image_and_Run_Tests_in_Bhyve_HEAD#190
Building remotely on havoc.ysv.freebsd.org (FreeBSD-10) in workspace 

[FreeBSD_HEAD-tests2] $ /bin/sh -xe /tmp/hudson9166051534485122562.sh
+ sudo python /vm/freebsd-ci/scripts/test/run-tests.py -f 
/vm/freebsd-ci/scripts/test/config/config.json

bhyveload -m 2G -d 
/net/jenkins-10.freebsd.org/builds/Build-UFS-image/image/FreeBSD_HEAD/test.img 
vm_test
Consoles: userboot  

FreeBSD/amd64 User boot, Revision 1.1
(rodr...@havoc.ysv.freebsd.org, Tue Oct 21 05:39:14 UTC 2014)
|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|Loading
 /boot/defaults/loader.conf 
/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\[H[J[7;46H
 ````[8;46Hs` `.---...--.```   -/[9;46H+o   
.--` /y:`  +.[10;46H yo`:.:o  `+-[11;46H  y/  
 -/`   -o/[12;46H .-  ::/sy+:.[13;46H /   
  `--  /[14;46H`:  :`[15;46H`:
  :`[16;46H /  /[17;46H .-
-.[18;46H  --  -.[19;46H   `:`  
`:`[20;46H .-- `--.[21;46H.---..[25;0H[1;2H 
__      _ _  [2;2H|  | |  _ \ / 
|  __ \ [3;2H| |___ _ __ ___  ___ | |_) | (___ | |  | |[4;2H|  ___| '__/ 
_ \/ _ \|  _ < \___ \| |  | |[5;2H| |   | | |  __/
   __/| |_) |) | |__| |[6;2H| |   | | |||| |  |  
|[7;2H|_|   |_|  \___|\___||/|_/|_/ 
[25;0H[10;2H|[11;2H|[12;2H|[13;2H|[14;2H|[15;2H|[16;2H|[17;2H|[18;2H|[19;2H|[20;2H|[21;2H|[10;44H|[11;44H|[12;44H|[13;44H|[14;44H|[15;44H|[16;44H|[17;44H|[18;44H|[19;44H|[20;44H|[21;44H|[9;3H-[22;3H-[9;2H+[22;2H+[9;44H+[22;44H+[25;0H|/-\|/-\|/-\[9;15HWelcome
 to FreeBSD[11;5H1 [11;6H.[11;8HBoot Multi User [Enter][12;5H2 
[12;6H.[12;8HBoot [S]ingle User[13;5H3 [13;6H.[13;8H[Esc]ape to loader 
prompt[14;5H4 [14;6H.[14;8HReboot[16;5HOptions:[17;5H5 
[17;6H.[17;8H[K]ernel: kernel (1 of 2)[18;5H6 [18;6H.[18;8HConfigure Boot 
[O]ptions...[25;0H[23;4HAutoboot in 9 seconds. [Space] to 
pause[25;0H[23;4HAutoboot in 8 seconds. [Space] to 
pause[25;0H[23;4HAutoboot in 7 seconds. [Space] to 
pause[25;0H[23;4HAutoboot in 6 seconds. [S
 pace] to pause[25;0H[23;4HAutoboot in 5 seconds. [Space] to 
pause[25;0H[23;4HAutoboot in 4 seconds. [Space] to 
pause[25;0H[23;4HAutoboot in 3 seconds. [Space] to 
pause[25;0H[23;4HAutoboot in 2 seconds. [Space] to 
pause[25;0H[23;4HAutoboot in 1 seconds. [Space] to pause[25;0H[23;4H
   
[25;0H|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/boot/kernel/kernel
 text=0x101cd38 
/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\
 
|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/
 
-\|/-\|/-\|/-\|/-

Re: Build Fail: r274159

2014-11-05 Thread Garrett Cooper

On Nov 5, 2014, at 18:25, Larry Rosenman  wrote:

> (cd /usr/src/rescue/rescue/../../sbin/fdisk &&  make -DRESCUE 
> CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/fdisk/ depend && make -DRESCUE 
> CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/fdisk/ fdisk.o geom_mbr_enc.o)
> cc  -O2 -pipe -fno-omit-frame-pointer   -DRESCUE -std=gnu99 -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 
> -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
> -Wno-unused-const-variable -Qunused-arguments -c /usr/src/sbin/fdisk/fdisk.c
> In file included from /usr/src/sbin/fdisk/fdisk.c:30:
> /usr/obj/usr/src/tmp/usr/include/sys/disk.h:132:3: error: unknown type name 
> 'off_t'
>off_t off;
>^
> 1 error generated.
> *** Error code 1

Probably related to r274154


signature.asc
Description: Message signed with OpenPGP using GPGMail

Build Fail: r274159

2014-11-05 Thread Larry Rosenman

(cd /usr/src/rescue/rescue/../../sbin/fdisk &&  make -DRESCUE 
CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/fdisk/ depend && make 
-DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/fdisk/ fdisk.o 
geom_mbr_enc.o)
cc  -O2 -pipe -fno-omit-frame-pointer   -DRESCUE -std=gnu99 
-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 -Wno-uninitialized 
-Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Qunused-arguments -c 
/usr/src/sbin/fdisk/fdisk.c

In file included from /usr/src/sbin/fdisk/fdisk.c:30:
/usr/obj/usr/src/tmp/usr/include/sys/disk.h:132:3: error: unknown type 
name 'off_t'

off_t off;
^
1 error generated.
*** Error code 1

Stop.
make[6]: stopped in /usr/src/sbin/fdisk
*** Error code 1

Stop.
make[5]: stopped in /usr/obj/usr/src/rescue/rescue
*** Error code 1

Stop.
make[4]: stopped in /usr/src/rescue/rescue
*** Error code 1

Stop.
make[3]: stopped in /usr/src/rescue
*** Error code 1

Stop.
make[2]: stopped in /usr/src
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src
^C
[1]   Done(1) nohup make -DNO_CLEAN buildworld 
buildkernel >>make.noc.out 2>&1

borg.lerctr.org /usr/src #
borg.lerctr.org /usr/src # svn info
Path: .
Working Copy Root Path: /usr/src
URL: svn://svn.freebsd.org/base/head
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 274159
Node Kind: directory
Schedule: normal
Last Changed Author: dteske
Last Changed Rev: 274159
Last Changed Date: 2014-11-05 19:46:33 -0600 (Wed, 05 Nov 2014)

borg.lerctr.org /usr/src #

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 108 Turvey Cove, Hutto, TX 78634-5688
___
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: android bsd connectivity tools etc ?

2014-11-05 Thread Jamie Landeg-Jones

"Julian H. Stacey"  wrote:

Firstly, if you haven't already, I'd recommend 'Android terminal
emulator' and 'hackers keyboard' - both free from the Play store.

To be able to create startup scripts without reflashing etc. you
must have root, and be able to write the file
"/system/etc/install_recovery.sh"

> NFS [& AMD] [& SSH] would be ideal for me.
>
> I had a look on my Samsung Galaxy Note 3, with Android 4.4.2 kernel
> 3.4.0, & skimmed index of the 182 page pdf, but I dont know how to
> tell if mine has NFS ? Or how to get it.

I have the dropbear ssh client and server. I've not managed to compile
them or openssh yet - instead I grabbed the binaries (opened source)
from inside one of the free sshd server apps on the play store.

One of my newer devices doesn't come with NFS, the others do. You need
to find the correct nfs.ko kernel module for your kernel, and/or
recompile the linux kernel - both things I've not achieved yet
(running FreeBSD and not Linux/Windows makes things harder with no
SDK etc.) but all this is part of what I'm investigating at the
moment, so it would be great to be able to share notes with someone
else sith a FreeBSD mindset.

If you have nfs already, the standard mount should work from root:

 | 23:29 [3] (1) root@tabbycat:"/usr/users/jamie" # mkdir /tmp/test
 | 23:29 [3] (2) root@tabbycat:"/usr/users/jamie" # mount -o nolock,hard,ro 
lnfs:/nfs/b/tabbycat/ /tmp/test
 | 23:30 [3] (3) root@tabbycat:"/usr/users/jamie" # df -h
 | Filesystem  Size  Used Available Capacity  Mounted on
 | tmpfs 176.7M 52.0K176.7M 0%/dev
 | devpts 0 0 0 0%/dev/pts
 | proc   0 0 0 0%/proc
 | sysfs  0 0 0 0%/sys
 | none   0 0 0 0%/acct
 | tmpfs 176.7M 0176.7M 0%/mnt/asec
 | tmpfs 176.7M 0176.7M 0%/mnt/obb
 | /dev/block/nandd 1007.9M282.6M725.3M28%/system
 | /dev/block/nande 1007.9M137.4M870.5M14%/data
 | /dev/block/nandh  252.0M  4.3M247.7M 2%/cache
 | /dev/block/nandd 1007.9M282.6M725.3M28%/bin
 | hidden 0 0 0 0%
/system/.bin_mount
 | tmpfs 128.0M  8.0K128.0M 0%/tmp
 | /dev/block/nandj2 718.0M404.7M313.3M56%/usr
 | /dev/block/nandj3 100.4M 19.3M 81.1M19%/var
 | tmpfs   1.0M  4.0K   1020.0K 0%/var/run
 | /dev/block/mmcblk0p2   18.6G  1.3G 16.4G 7%/data2
 | /dev/block/vold/93:76  23.5M  8.0K 23.5M 0%/mnt/extsd
 | /dev/block/vold/179:3  10.5G  5.5G  5.0G52%/mnt/sdcard
 | /dev/block/vold/179:3  10.5G  5.5G  5.0G52%
/mnt/secure/asec
 | tmpfs  0 0 0 0%
/mnt/sdcard/.android_secure
 | lnfs:/nfs/j/Misc/   1.8T  1.5T143.7G91%
/mnt/sdcard/Misc
 | lnfs:/nfs/j/Music/  1.8T  1.5T143.7G91%
/mnt/sdcard/Music/lapcat
 | lnfs:/nfs/j/Videos/ 1.8T  1.5T143.7G91%
/mnt/sdcard/Videos/lapcat
 | lnfs:/nfs/j/Pictures/   1.8T  1.5T143.7G91%
/mnt/sdcard/Pictures/lapcat
 | lnfs:/nfs/APK-archives/ 1.8T  1.5T143.7G91%
/APK-archives
 | lnfs:/nfs/b/tabbycat/   1.8T  1.5T143.7G91%/backups
 | lnfs:/nfs/b/tabbycat/   1.8T  1.5T143.7G91%/tmp/test
 | 
 | 23:30 [3] (4) root@tabbycat:"/usr/users/jamie" # l /tmp/test
 | total 32
 |  4 drwxr-x---9 root root   512 Nov  1 07:28 ./
 |  0 drwxrwxrwt3 root root   160 Nov  5 23:33 ../
 |  4 drwxr-xr-x   20 rootfs   rootfs1024 Nov  5 09:23 BASE/
 |  4 drwxr-x---2 root root   512 Nov  5 16:35 logs/
 |  4 drwxr-x---2 root root   512 Oct 25 11:49 monthly/
 |  4 drwxr-x---7 root root   512 Nov  5 16:36 often/
 |  4 drwxr-x---5 root root   512 Nov  1 07:49 old/
 |  4 drwxr-x---2 root root   512 Oct 29 09:20 partial/
 |  4 drwxr-x---4 root root   512 Nov  3 03:35 weekly/
 | 
 | 23:30 [3] (5) root@tabbycat:"/usr/users/jamie" #

I'd be more than happy to share my findings/code/ etc. with you,
maybe private mail would be better?

As a quick 'summary', I use FreeBSD exclusively on my servers etc., but
do have 5 Android devices.

My achievements with them (not currently complete with all of them) is to
give them a decent Unix environment, all running NFS to my home FreeBSD
server, sshd, IP6 (FreeBSD server is my IP6 router - it uses tunnelbroker.net
to get IP6 over my consumer IP4 only ISP), c

Re: Strange failure with 10.x jail in poudriere on head

2014-11-05 Thread Guido Falsi

On 11/06/14 00:28, Guido Falsi wrote:
> Hi,
> 
> Today I updated my system to r274133, it works fine, but I see a strange
> problem in 10.x jails, which, even stranger, is not happening in 9.x and
> 8.x jails.
> 
> the jails are created using ftp, so downloading official binaries.
> 
> The python ports fail with this error at staging time:
> 
> running install_lib
> error: error listing files in 'build/lib.freebsd-10.1-RC4-i386-2.7':
> Operation not supported
> *** Error code 1
> 
> full log here, against 10.0-p12 on amd64 jail:

correction, the log is from 10.1-RC4-p1 i386, but I have the same error
and log from 10.0 amd64 and i386.

-- 
Guido Falsi 
___
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"

Strange failure with 10.x jail in poudriere on head

2014-11-05 Thread Guido Falsi

Hi,

Today I updated my system to r274133, it works fine, but I see a strange
problem in 10.x jails, which, even stranger, is not happening in 9.x and
8.x jails.

the jails are created using ftp, so downloading official binaries.

The python ports fail with this error at staging time:

running install_lib
error: error listing files in 'build/lib.freebsd-10.1-RC4-i386-2.7':
Operation not supported
*** Error code 1

full log here, against 10.0-p12 on amd64 jail:

http://www.madpilot.net/~mad/python27-2.7.8_6.log

the code (python) is trying to perform
os.listdir('build/lib.freebsd-10.1-RC4-i386-2.7') at that point. The
directory exists and does not have strange permissions.

Installing python in a 10.1 VM in Virtualbox works fine.

I suspect some recent change to head kernel is causing it to produce
this failure in 10.x jails, But I'm at a loss on how this could be
happening.

Any suggestion on how I can debug this? Anyone has an idea what could be
causing this?

I upgraded from r273455.

Thanks in advance.

-- 
Guido Falsi 
___
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: HEADS UP: Enabling vt(4) by default

2014-11-05 Thread Chris H

On Wed, 05 Nov 2014 22:29:53 +0100 Hans Petter Selasky  wrote

> On 11/05/14 22:27, Chris H wrote:
> > On Wed, 5 Nov 2014 12:55:51 -0700 (MST) Warren Block 
> > wrote >
> >> On Wed, 5 Nov 2014, Chris H wrote:
> >>
> >>> On Wed, 5 Nov 2014 08:15:04 -0700 (MST) Warren Block 
> >>> wrote >
>  On Wed, 5 Nov 2014, Chris H wrote:
> > On Wed, 5 Nov 2014 10:19:51 +0100 Gary Jennejohn 
> > wrote >>
> >> No, video mode won't work with the nVidia blob.  That requires
> >> a KMS (in-kernel) driver.
> >
> > Thank you for the reply, Gary.
> >
> > Ahh. I see. So unless I have ATI hardware, I'm pretty much out of luck?
> 
>  Or Intel, or anything with KMS drivers.
> >>>
> >>> Thanks. Everything I manage, is using nVidia. Looks like
> >>> the kms VESA might work. But I'm not sure if there would
> >>> be any appreciable gain going that route (assuming it's even
> >>> possible).
> >>
> >> It's worth asking Nvidia directly.  I would not be optimistic about
> >> that, but it's easy to try, and they might surprise everyone.
> >>
> >> Another option might be nouveau.  Don't know the current status of
> >> whether that works on FreeBSD, though.
> > LOL funny you should bring that up, just now.
> > Prior to a fresh install on bare metal. I always boot to a gpartd
> > CD. I use it to easily see, and quickly blank the disk(s). I only
> > choose it, because it's quick-n-easy. It is also the perfect tool
> > to wipe that evil grub[2] off the MBR. Which has given me no end
> > of grief after evaluating some Linux distro. Anyhow, point being;
> > the desktop is powered by nouveau. I've never had an issue with it,
> > and it always seems to pick the "right" resolution/frequency. So,
> > because of that. I was already thinking of investigating that route.
> > As to talking to nVidia. My past experiences in that regard were,
> > shall I say; less than ideal. They're always friendly. But getting
> > anything that might "uncover" any coveted driver info, always fell
> > short of helpful. :)
> >
> > Thanks for the reply, and helpful information, Warren.
> >
> > --Chris
> 
> Hi,
> 
> FYI:
> 
> The KMS stuff seems to work on my intel HD graphics based MAC. Finally I 
> can switch back to the console!
Thanks for sharing that, Hans. I'm looking to pick up some Mac hardware
to put FreeBSD on. Now, I'm even more anxious to get it. :)

--Chris

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

Build failed in Jenkins: Build-UFS-image #330

2014-11-05 Thread jenkins-admin

See 

--
[...truncated 5350 lines...]

 -> 


 -> 


 -> 


 -> 


 -> 


 -> 


 -> 


 -> 


 -> 


 -> 


 -> 


 -> 


 -> 


 -> 


 -> 


 -> 


 -> 


 -> 


 -> 


 ->

Jenkins build is back to normal : FreeBSD_HEAD #1778

2014-11-05 Thread 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: HEADS UP: Enabling vt(4) by default

2014-11-05 Thread Hans Petter Selasky


On 11/05/14 22:27, Chris H wrote:

On Wed, 5 Nov 2014 12:55:51 -0700 (MST) Warren Block  wrote


On Wed, 5 Nov 2014, Chris H wrote:


On Wed, 5 Nov 2014 08:15:04 -0700 (MST) Warren Block 
wrote >

On Wed, 5 Nov 2014, Chris H wrote:

On Wed, 5 Nov 2014 10:19:51 +0100 Gary Jennejohn 
wrote >>

No, video mode won't work with the nVidia blob.  That requires
a KMS (in-kernel) driver.


Thank you for the reply, Gary.

Ahh. I see. So unless I have ATI hardware, I'm pretty much out of luck?


Or Intel, or anything with KMS drivers.


Thanks. Everything I manage, is using nVidia. Looks like
the kms VESA might work. But I'm not sure if there would
be any appreciable gain going that route (assuming it's even
possible).


It's worth asking Nvidia directly.  I would not be optimistic about
that, but it's easy to try, and they might surprise everyone.

Another option might be nouveau.  Don't know the current status of
whether that works on FreeBSD, though.

LOL funny you should bring that up, just now.
Prior to a fresh install on bare metal. I always boot to a gpartd
CD. I use it to easily see, and quickly blank the disk(s). I only
choose it, because it's quick-n-easy. It is also the perfect tool
to wipe that evil grub[2] off the MBR. Which has given me no end
of grief after evaluating some Linux distro. Anyhow, point being;
the desktop is powered by nouveau. I've never had an issue with it,
and it always seems to pick the "right" resolution/frequency. So,
because of that. I was already thinking of investigating that route.
As to talking to nVidia. My past experiences in that regard were,
shall I say; less than ideal. They're always friendly. But getting
anything that might "uncover" any coveted driver info, always fell
short of helpful. :)

Thanks for the reply, and helpful information, Warren.

--Chris


Hi,

FYI:

The KMS stuff seems to work on my intel HD graphics based MAC. Finally I 
can switch back to the console!


--HPS


___
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: HEADS UP: Enabling vt(4) by default

2014-11-05 Thread Chris H

On Wed, 5 Nov 2014 12:55:51 -0700 (MST) Warren Block  wrote

> On Wed, 5 Nov 2014, Chris H wrote:
> 
> > On Wed, 5 Nov 2014 08:15:04 -0700 (MST) Warren Block 
> > wrote >
> >> On Wed, 5 Nov 2014, Chris H wrote:
> >>> On Wed, 5 Nov 2014 10:19:51 +0100 Gary Jennejohn 
> >>> wrote >>
>  No, video mode won't work with the nVidia blob.  That requires
>  a KMS (in-kernel) driver.
> >>>
> >>> Thank you for the reply, Gary.
> >>>
> >>> Ahh. I see. So unless I have ATI hardware, I'm pretty much out of luck?
> >>
> >> Or Intel, or anything with KMS drivers.
> >
> > Thanks. Everything I manage, is using nVidia. Looks like
> > the kms VESA might work. But I'm not sure if there would
> > be any appreciable gain going that route (assuming it's even
> > possible).
> 
> It's worth asking Nvidia directly.  I would not be optimistic about 
> that, but it's easy to try, and they might surprise everyone.
> 
> Another option might be nouveau.  Don't know the current status of 
> whether that works on FreeBSD, though.
LOL funny you should bring that up, just now.
Prior to a fresh install on bare metal. I always boot to a gpartd
CD. I use it to easily see, and quickly blank the disk(s). I only
choose it, because it's quick-n-easy. It is also the perfect tool
to wipe that evil grub[2] off the MBR. Which has given me no end
of grief after evaluating some Linux distro. Anyhow, point being;
the desktop is powered by nouveau. I've never had an issue with it,
and it always seems to pick the "right" resolution/frequency. So,
because of that. I was already thinking of investigating that route.
As to talking to nVidia. My past experiences in that regard were,
shall I say; less than ideal. They're always friendly. But getting
anything that might "uncover" any coveted driver info, always fell
short of helpful. :)

Thanks for the reply, and helpful information, Warren.

--Chris


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

2014-11-05 Thread jenkins-admin

See 

Changes:

[ngie] Expect lib.libc.sys.getcontext_test.setcontext_link to fail on amd64; add
additional debugging to make the underlying problem more visible

Calling setcontext(2) on amd64 as shown in the test program is failing on
amd64, not i386, with a return code of -1 and an errno of EINVAL

Further investigation is being done in the PR to determine the root cause for
the failure

PR: 194828
Tested with the following configuration:
- amd64/i386
- 11.0-CURRENT @ r273153
- 100 times in a tight loop as root with the following commands...
-- kyua test lib/libc
-- kyua test lib/libc/sys
-- kyua test lib/libc/sys/getcontext_test

[ngie] Remove expected failure from lib.libc.sys.t_mincore:mincore_resid

The failure was added based on observation seen on 11.0-CURRENT @ r273153, not
based on internal testing at EMC/Isilon

PR: 194829
Tested with the following configuration:
- amd64/i386
- 11.0-CURRENT @ r273153
- 100 times in a tight loop as root with the following commands...
-- kyua test lib/libc
-- kyua test lib/libc/sys
-- kyua test lib/libc/sys/mincore_test

[des] Hook up OpenPAM's own unit tests to the build.

[bapt] ftp(1) uses nothing from libutil, do not link to it

--
[...truncated 173588 lines...]
===> lib/libpam/modules/pam_opieaccess (all)
--- usr.sbin.all__D ---
--- nswalk.o ---
cc  -O2 -pipe   -DACPI_ASL_COMPILER -I. 
-I
 -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k 
-Wno-uninitialized -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 -Qunused-arguments -c 

--- lib.all__D ---
--- pam_opieaccess.8.gz ---
gzip -cn 

 > pam_opieaccess.8.gz
===> lib/libpam/modules/pam_passwdqc (all)
--- usr.sbin.all__D ---
--- all_subdir_amd ---
--- fsi_dict.o ---
cc  -O2 -pipe   
-I
 -I. 
-I 
-I
 
-I/usr/obj
 
-I
 
-I
 -DHAVE_CONFIG_H -DHOST_CPU=\"amd64\" -DHOST_ARCH=\"amd64\" -std=gnu99 
-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 -Qunused-
 arguments -c 

--- all_subdir_acpi ---
--- tbdata.o ---
cc  -O2 -pipe   -DACPI_ASL_COMPILER -I. 
-I
 -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k 
-Wno-uninitialized -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 -Qunused-arguments -c 

--- lib.all__D ---
--- pam_passwdqc.8.gz ---
gzip -cn 

 > pam_passwdqc.8.gz
===> lib/libpam/modules/pam_permit (all)
--- pam_permit.8.gz ---
gzip -cn 

 > pam_permit.8.gz
--- usr.sbin.all__D ---
--- tbfadt.o ---
--- lib.all__D ---
===> lib/libpam/modules/pam_radius (all)
--- usr.sbin.all__D ---
cc  -O2 -pipe   -DACPI_ASL_COMPILER -I. 
-I
 -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k 
-Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-con

Re: HEADS UP: Enabling vt(4) by default

2014-11-05 Thread Warren Block


On Wed, 5 Nov 2014, Chris H wrote:


On Wed, 5 Nov 2014 08:15:04 -0700 (MST) Warren Block  wrote


On Wed, 5 Nov 2014, Chris H wrote:

On Wed, 5 Nov 2014 10:19:51 +0100 Gary Jennejohn 
wrote >>

No, video mode won't work with the nVidia blob.  That requires
a KMS (in-kernel) driver.


Thank you for the reply, Gary.

Ahh. I see. So unless I have ATI hardware, I'm pretty much out of luck?


Or Intel, or anything with KMS drivers.


Thanks. Everything I manage, is using nVidia. Looks like
the kms VESA might work. But I'm not sure if there would
be any appreciable gain going that route (assuming it's even
possible).


It's worth asking Nvidia directly.  I would not be optimistic about 
that, but it's easy to try, and they might surprise everyone.


Another option might be nouveau.  Don't know the current status of 
whether that works on FreeBSD, though.

___
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: ctfconvert: aaa_bbb.o doesn't have type data to convert

2014-11-05 Thread Mark Johnston

On Wed, Nov 05, 2014 at 11:03:46AM -0800, Chris H wrote:
> Greetings,
>  I'm building/installing world/kernel on a fresh 11-CURRENT.
> As I write this, the kernel is building, and emitting 100's
> of lines with the following:
> ERROR: ctfconvert: aaa_bbb.o doesn't have type data to convert
> where aaa_bbb is the driver file being created.
> Should I be concerned? What would cause this?

For posterity, we determined off-list that this was due to removing
DEBUG=-g from the kernel config. In this case the ctf tools have no
debug symbols to work with, hence the errors.
___
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"

ERROR: ctfconvert: aaa_bbb.o doesn't have type data to convert

2014-11-05 Thread Chris H

Greetings,
 I'm building/installing world/kernel on a fresh 11-CURRENT.
As I write this, the kernel is building, and emitting 100's
of lines with the following:
ERROR: ctfconvert: aaa_bbb.o doesn't have type data to convert
where aaa_bbb is the driver file being created.
Should I be concerned? What would cause this?

Thank you for all your time, and consideration.

--Chris


___
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: LOR on CURRENT

2014-11-05 Thread Chris H

On Wed, 5 Nov 2014 13:38:01 -0500 (EST) Benjamin Kaduk  wrote

> On Wed, 5 Nov 2014, Chris H wrote:
> 
> > Greetings,
> >  a fresh install off the 2014-10-26 bootonly iso, generates the
> > following LOR:
> >
> > lock order reversal:
> >  1st 0xfe00f7626b48 bufwait (bufwait) @
> >  /usr/src/sys/kern/vfs_bio.c:3093 2nd 0xf8000404aa00 dirhash (dirhash)
> >  @ 
>
> This one is a very well-known false positive.
> http://sources.zabbadoz.net/freebsd/lor/261.html

Ahh. I see. Thanks for putting my mind at ease. :)
Maybe witness(4) needs to be better educated?

Thank you for taking the time to reply, Ben.

--Chris

> 
> -Ben
> ___
> 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: LOR on CURRENT

2014-11-05 Thread Benjamin Kaduk

On Wed, 5 Nov 2014, Chris H wrote:

> Greetings,
>  a fresh install off the 2014-10-26 bootonly iso, generates the
> following LOR:
>
> lock order reversal:
>  1st 0xfe00f7626b48 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3093
>  2nd 0xf8000404aa00 dirhash (dirhash) @

This one is a very well-known false positive.
http://sources.zabbadoz.net/freebsd/lor/261.html

-Ben
___
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 unstable: FreeBSD_HEAD-tests2 #192

2014-11-05 Thread 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: android bsd connectivity tools etc ?

2014-11-05 Thread Julian H. Stacey

Jamie Landeg-Jones wrote:
> "Julian H. Stacey"  wrote:
> > Any tips for Android / FreeBSD BSD tools for connectivity etc ?
> 
> I mainly use nfs / ssh (dropbear) / scp for connectivity over IPv6 to my
> local FreeBSD server. It works quite well - I even have automated cron
> rsync deduped backups!
> 
> NFS is used for mounting my media onto
> /sdcard/Videos
> /sdcard/Music
> /sdcard/Pictures
> 
> Not all androids come with nfs in the kernel though,

NFS [& AMD] [& SSH] would be ideal for me.

I had a look on my Samsung Galaxy Note 3, with Android 4.4.2 kernel
3.4.0, & skimmed index of the 182 page pdf, but I dont know how to
tell if mine has NFS ? Or how to get it.
I get no umass & /dev/da* I probably need to tweak my android somehow.

For Per who wrote "For tethering I have no idea, sorry." I have usb
tethering working :-) if you want it too, see below.
My android browser over USB does read from httpd on my FreeBSD :-)

Thank to all who have contributed info & URLS etc.  Collated at:
http://www.berklix.com/~jhs/android/#connect
Corrections, additions etc welcome.

Cheers,
Julian
-- 
Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com
 Indent previous with "> ".  Interleave reply paragraphs like a play script.
 Send plain text, not quoted-printable, HTML, base64, or multipart/alternative.
___
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: Build failed in Jenkins: FreeBSD_HEAD-tests2 #187

2014-11-05 Thread Garrett Cooper

On Nov 4, 2014, at 12:42, Garrett Cooper  wrote:

> On Nov 4, 2014, at 12:09, jenkins-ad...@freebsd.org wrote:
> 
>> See 
> 
> ...
> 
> Hi Craig/Jenkins admins,
>   I opened a pull request to increase the timeout from 1 to 2 hours when 
> running "kyua test”: https://github.com/freebsd/freebsd-ci/pull/1/files .
> Thank you!

Hi again,
I looked at the output from the latest failed run, and the real problem 
is that it’s assuming that “# “ is a sufficiently unique string to find a 
prompt. Long story short is it isn’t. Unique prompt handling is done better in 
pxssh with a bit more complex algorithms. I’ll provide better unique prompt 
handling and redo the pull request.
Thanks!

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: r273165. ZFS ARC: possible memory leak to Inact

2014-11-05 Thread James R. Van Artsdalen

On 11/5/2014 6:41 AM, Andriy Gapon wrote:
> If something hangs (appears to hang) and it's ZFS related, then
> https://wiki.freebsd.org/AvgZfsDeadlockDebug
>

I don't think the"zpool history" hang is in ZFS or storage layer code:
it seems be  stalled in kernel malloc().   See PID 12105 (zpool 
history) below.

SUPERTEX:/root# uname -a
FreeBSD SUPERTEX.housenet.jrv 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #3
r273476M: Wed Oct 22 15:05:29 CDT 2014
r...@supertex.housenet.jrv:/usr/obj/usr/src/sys/GENERIC  amd64
SUPERTEX:/root# procstat -kk -a > kk
SUPERTEX:/root# grep zio_wait kk
SUPERTEX:/root# grep zio_done kk
SUPERTEX:/root# grep zio_int kk
SUPERTEX:/root# grep zfs_ kk
0 100475 kernel   zfs_vn_rele_task mi_switch+0xe1
sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a
fork_trampoline+0xe
0 101018 kernel   zfs_vn_rele_task mi_switch+0xe1
sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a
fork_trampoline+0xe
0 101522 kernel   zfs_vn_rele_task mi_switch+0xe1
sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a
fork_trampoline+0xe
12105 101599 zpool-mi_switch+0xe1
sleepq_wait+0x3a _cv_wait+0x16d vmem_xalloc+0x568 vmem_alloc+0x3d
kmem_malloc+0x33 uma_large_malloc+0x49 malloc+0x43
zfs_ioc_pool_get_history+0xbd zfsdev_ioctl+0x5ca devfs_ioctl_f+0x139
kern_ioctl+0x255 sys_ioctl+0x13c amd64_syscall+0x351 Xfast_syscall+0xfb
SUPERTEX:/root# grep dmu_ kk
SUPERTEX:/root# grep arc_ kk
3 100125 zfskern  arc_reclaim_thre mi_switch+0xe1
sleepq_timedwait+0x3a _cv_timedwait_sbt+0x18b arc_reclaim_thread+0x288
fork_exit+0x9a fork_trampoline+0xe
3 100126 zfskern  l2arc_feed_threa mi_switch+0xe1
sleepq_timedwait+0x3a _cv_timedwait_sbt+0x18b l2arc_feed_thread+0x19f
fork_exit+0x9a fork_trampoline+0xe
SUPERTEX:/root# grep buf_ kk
   20 100139 bufdaemon-mi_switch+0xe1
sleepq_timedwait+0x3a _sleep+0x26e buf_daemon+0x78 fork_exit+0x9a
fork_trampoline+0xe
SUPERTEX:/root# ps lp 12105
UID   PID  PPID CPU PRI NIVSZ   RSS MWCHAN   STAT TT TIME COMMAND
  0 12105 12104   0  20  0 105692 35984 kmem are D -  0:03.76 zpool
history BI
SUPERTEX:/root#


___
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: r273165. ZFS ARC: possible memory leak to Inact

2014-11-05 Thread Andriy Gapon

On 05/11/2014 18:32, James R. Van Artsdalen wrote:
> On 11/5/2014 6:41 AM, Andriy Gapon wrote:
>> If something hangs (appears to hang) and it's ZFS related, then
>> https://wiki.freebsd.org/AvgZfsDeadlockDebug
>>
> 
> I don't think the"zpool history" hang is in ZFS or storage layer code:
> it seems be  stalled in kernel malloc().   See PID 12105 (zpool 
> history) below.

The wiki page has this underscored line :-)

when reporting a problem please always include full information about thread
stacks, don't cherry pick; the output can be large, upload it somewhere and post
a link

> SUPERTEX:/root# uname -a
> FreeBSD SUPERTEX.housenet.jrv 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #3
> r273476M: Wed Oct 22 15:05:29 CDT 2014
> r...@supertex.housenet.jrv:/usr/obj/usr/src/sys/GENERIC  amd64
> SUPERTEX:/root# procstat -kk -a > kk
> SUPERTEX:/root# grep zio_wait kk
> SUPERTEX:/root# grep zio_done kk
> SUPERTEX:/root# grep zio_int kk
> SUPERTEX:/root# grep zfs_ kk
> 0 100475 kernel   zfs_vn_rele_task mi_switch+0xe1
> sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a
> fork_trampoline+0xe
> 0 101018 kernel   zfs_vn_rele_task mi_switch+0xe1
> sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a
> fork_trampoline+0xe
> 0 101522 kernel   zfs_vn_rele_task mi_switch+0xe1
> sleepq_wait+0x3a _sleep+0x287 taskqueue_thread_loop+0xd5 fork_exit+0x9a
> fork_trampoline+0xe
> 12105 101599 zpool-mi_switch+0xe1
> sleepq_wait+0x3a _cv_wait+0x16d vmem_xalloc+0x568 vmem_alloc+0x3d
> kmem_malloc+0x33 uma_large_malloc+0x49 malloc+0x43
> zfs_ioc_pool_get_history+0xbd zfsdev_ioctl+0x5ca devfs_ioctl_f+0x139
> kern_ioctl+0x255 sys_ioctl+0x13c amd64_syscall+0x351 Xfast_syscall+0xfb
> SUPERTEX:/root# grep dmu_ kk
> SUPERTEX:/root# grep arc_ kk
> 3 100125 zfskern  arc_reclaim_thre mi_switch+0xe1
> sleepq_timedwait+0x3a _cv_timedwait_sbt+0x18b arc_reclaim_thread+0x288
> fork_exit+0x9a fork_trampoline+0xe
> 3 100126 zfskern  l2arc_feed_threa mi_switch+0xe1
> sleepq_timedwait+0x3a _cv_timedwait_sbt+0x18b l2arc_feed_thread+0x19f
> fork_exit+0x9a fork_trampoline+0xe
> SUPERTEX:/root# grep buf_ kk
>20 100139 bufdaemon-mi_switch+0xe1
> sleepq_timedwait+0x3a _sleep+0x26e buf_daemon+0x78 fork_exit+0x9a
> fork_trampoline+0xe
> SUPERTEX:/root# ps lp 12105
> UID   PID  PPID CPU PRI NIVSZ   RSS MWCHAN   STAT TT TIME COMMAND
>   0 12105 12104   0  20  0 105692 35984 kmem are D -  0:03.76 zpool
> history BI
> SUPERTEX:/root#
> 
> 


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

LOR on CURRENT

2014-11-05 Thread Chris H

Greetings,
 a fresh install off the 2014-10-26 bootonly iso, generates the
following LOR:

lock order reversal:
 1st 0xfe00f7626b48 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3093
 2nd 0xf8000404aa00 dirhash (dirhash) @
/usr/src/sys/ufs/ufs/ufs_dirhash.c:2
84
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0120cd9650
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0120cd9700
witness_checkorder() at witness_checkorder+0xdad/frame 0xfe0120cd9790
_sx_xlock() at _sx_xlock+0x75/frame 0xfe0120cd97d0
ufsdirhash_remove() at ufsdirhash_remove+0x37/frame 0xfe0120cd9800
ufs_dirremove() at ufs_dirremove+0x11b/frame 0xfe0120cd9860
ufs_remove() at ufs_remove+0x75/frame 0xfe0120cd98c0
VOP_REMOVE_APV() at VOP_REMOVE_APV+0xf7/frame 0xfe0120cd98f0
kern_unlinkat() at kern_unlinkat+0x209/frame 0xfe0120cd9ae0
amd64_syscall() at amd64_syscall+0x25a/frame 0xfe0120cd9bf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0120cd9bf0
--- syscall (10, FreeBSD ELF64, sys_unlink), rip = 0x800b5208a, rsp =
0x7fff
eb58, rbp = 0x7fffeb70 ---

it's not FATAL, but thought it worth mentioning.
I haven't built, or installed world|kernel (yet). I also have
dmesg(8) from that session, out of var/run/dmesg.boot, and would
be happy to provide it, on request.

Thank you for all your time, and consideration.

--Chris


___
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: HEADS UP: Enabling vt(4) by default

2014-11-05 Thread Chris H

On Wed, 5 Nov 2014 08:15:04 -0700 (MST) Warren Block  wrote

> On Wed, 5 Nov 2014, Chris H wrote:
> > On Wed, 5 Nov 2014 10:19:51 +0100 Gary Jennejohn 
> > wrote >>
> >> No, video mode won't work with the nVidia blob.  That requires
> >> a KMS (in-kernel) driver.
> >
> > Thank you for the reply, Gary.
> >
> > Ahh. I see. So unless I have ATI hardware, I'm pretty much out of luck?
> 
> Or Intel, or anything with KMS drivers.

Thanks. Everything I manage, is using nVidia. Looks like
the kms VESA might work. But I'm not sure if there would
be any appreciable gain going that route (assuming it's even
possible).

Thanks again, for the reply, Warren.

--Chris


___
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: HEADS UP: Enabling vt(4) by default

2014-11-05 Thread Warren Block


On Wed, 5 Nov 2014, Chris H wrote:

On Wed, 5 Nov 2014 10:19:51 +0100 Gary Jennejohn  wrote


No, video mode won't work with the nVidia blob.  That requires
a KMS (in-kernel) driver.


Thank you for the reply, Gary.

Ahh. I see. So unless I have ATI hardware, I'm pretty much out of luck?


Or Intel, or anything with KMS drivers.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: current panic: Lock (sx) random_adaptors not locked @

2014-11-05 Thread Julian H. Stacey

Xin Li wrote:
> On 11/04/14 06:01, Julian H. Stacey wrote:
> > Hi current@
> > Maybe this is a transient no one else will see ?: with no
> > /boot/loader.conf, my old custom kernel booted & my new one
> > paniced:
> > 
> > panic: Lock (sx) random_adaptors not locked @
> > dev/random/random_adaptors.c:278
> 
> This was fixed in r274006 FYI.

OK, Thanks Xin Li.

Cheers,
Julian
-- 
Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com
 Indent previous with "> ".  Interleave reply paragraphs like a play script.
 Send plain text, not quoted-printable, HTML, base64, or multipart/alternative.
___
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: buildkernel broken in HEAD

2014-11-05 Thread Gary Jennejohn

On Wed, 5 Nov 2014 06:02:39 -0800
David Wolfskill  wrote:

> On Wed, Nov 05, 2014 at 02:18:13PM +0100, Gary Jennejohn wrote:
> > HEAD updated just minutes ago:
> > 
> > --
> > >>> stage 3.1: making dependencies
> > --
> > @/amd64/amd64/genassym.c:79:16: error: no member named 'pm_save' in 'pmap'
> > ASSYM(PM_SAVE, offsetof(struct pmap, pm_save));
> > 
> > pm_save is not present in any pmap.h under /sys.
> > ...
> 
> I just built, booted, and smoke-checked:
> 
> FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1418  
> r274130M/274133:1100044: Wed Nov  5 05:47:27 PST 2014 
> r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  i386
> 

Thanks, but I'm at

Updating '.':
At revision 274134

-- 
Gary Jennejohn
___
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: HEADS UP: Enabling vt(4) by default

2014-11-05 Thread Andreas Nilsson

On Wed, Nov 5, 2014 at 3:36 PM, Chris H  wrote:

> On Wed, 5 Nov 2014 10:19:51 +0100 Gary Jennejohn 
> wrote
>
> > On Tue, 04 Nov 2014 18:01:41 -0800
> > "Chris H"  wrote:
> >
> > > On Tue, 04 Nov 2014 18:22:06 +0100 Jean-Sebastien Pedron
> > >  wrote
> > >
> > > > Hello!
> > > >
> > > > As announced a week ago, vt(4) is now the default console driver in
> > > > 11-CURRENT as of r274085.
> > > >
> > > > You may have to update your console settings in /etc/rc.conf. During
> > > > boot, /etc/rc.d/syscons will indicate what you need to do.
> > > >
> > > > The original HEADS UP mentioned several known issues. Among them, the
> > > > following were fixed:
> > > >
> > > > o  A video mode can be selected using the following tunable in
> > > >/boot/loader.conf:
> > > >kern.vt.fb.default_mode="1024x768"
> > > >
> > > >This only works when using a KMS video driver. It's not
> > > >supported by the VGA backend. See vt(4) man page for further
> > > >documentation.
> > > >
> > > > o  The keyboard was not working when kbdmux(4) was disabled. This
> > > >is fixed.
> > > >
> > > > o  After loading a KMS driver, the text cursor was in the middle
> of
> > > >the kernel messages. The problem was that the cursor position
> was
> > > >not updated after the change in window size. This is fixed.
> > > >
> > > > Up-to-date information can be found on the wiki page:
> > > > https://wiki.freebsd.org/Newcons
> > > >
> > > > If you want to keep using syscons(4), you can add the following line
> to
> > > > /boot/loader.conf:
> > > > kern.vty=sc
> > > >
> > > > Thank you to everyone who tested and reported problems! Please
> continue
> > > > to do so, especially if you find the need to go back to syscons.
> > >
> > > No. Thank _you_! :)
> > >
> > > I was unable to determine from the wiki. But do all these wonderful
> > > new features also work with the nVidia blob, under vt(4)?
> > > I'm currently building a new 11-CURRENT from the 10-26 iso, as I write
> > > this, and was wondering if the graphics mode at higher resolutions was
> > > now possible using the nVidia blob.
> > >
> >
> > No, video mode won't work with the nVidia blob.  That requires
> > a KMS (in-kernel) driver.
>
> Thank you for the reply, Gary.
>
> Ahh. I see. So unless I have ATI hardware, I'm pretty much out of luck?
>
> Thanks again.
>
> --Chris
>
> >
> > --
> > Gary Jennejohn
>
> Well,

ATI or Intel chip.

Best regards
Andreas
___
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: HEADS UP: Enabling vt(4) by default

2014-11-05 Thread Chris H

On Wed, 5 Nov 2014 10:19:51 +0100 Gary Jennejohn  wrote

> On Tue, 04 Nov 2014 18:01:41 -0800
> "Chris H"  wrote:
> 
> > On Tue, 04 Nov 2014 18:22:06 +0100 Jean-Sebastien Pedron
> >  wrote
> > 
> > > Hello!
> > > 
> > > As announced a week ago, vt(4) is now the default console driver in
> > > 11-CURRENT as of r274085.
> > > 
> > > You may have to update your console settings in /etc/rc.conf. During
> > > boot, /etc/rc.d/syscons will indicate what you need to do.
> > > 
> > > The original HEADS UP mentioned several known issues. Among them, the
> > > following were fixed:
> > > 
> > > o  A video mode can be selected using the following tunable in
> > >/boot/loader.conf:
> > >kern.vt.fb.default_mode="1024x768"
> > > 
> > >This only works when using a KMS video driver. It's not
> > >supported by the VGA backend. See vt(4) man page for further
> > >documentation.
> > > 
> > > o  The keyboard was not working when kbdmux(4) was disabled. This
> > >is fixed.
> > > 
> > > o  After loading a KMS driver, the text cursor was in the middle of
> > >the kernel messages. The problem was that the cursor position was
> > >not updated after the change in window size. This is fixed.
> > > 
> > > Up-to-date information can be found on the wiki page:
> > > https://wiki.freebsd.org/Newcons
> > > 
> > > If you want to keep using syscons(4), you can add the following line to
> > > /boot/loader.conf:
> > > kern.vty=sc
> > > 
> > > Thank you to everyone who tested and reported problems! Please continue
> > > to do so, especially if you find the need to go back to syscons.
> > 
> > No. Thank _you_! :)
> > 
> > I was unable to determine from the wiki. But do all these wonderful
> > new features also work with the nVidia blob, under vt(4)?
> > I'm currently building a new 11-CURRENT from the 10-26 iso, as I write
> > this, and was wondering if the graphics mode at higher resolutions was
> > now possible using the nVidia blob.
> > 
> 
> No, video mode won't work with the nVidia blob.  That requires
> a KMS (in-kernel) driver.

Thank you for the reply, Gary.

Ahh. I see. So unless I have ATI hardware, I'm pretty much out of luck?

Thanks again.

--Chris

> 
> -- 
> Gary Jennejohn


___
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: buildkernel broken in HEAD

2014-11-05 Thread David Wolfskill

On Wed, Nov 05, 2014 at 02:18:13PM +0100, Gary Jennejohn wrote:
> HEAD updated just minutes ago:
> 
> --
> >>> stage 3.1: making dependencies
> --
> @/amd64/amd64/genassym.c:79:16: error: no member named 'pm_save' in 'pmap'
> ASSYM(PM_SAVE, offsetof(struct pmap, pm_save));
> 
> pm_save is not present in any pmap.h under /sys.
> ...

I just built, booted, and smoke-checked:

FreeBSD g1-252.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1418  
r274130M/274133:1100044: Wed Nov  5 05:47:27 PST 2014 
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY  i386

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.


pgpLr9gjfSLMX.pgp
Description: PGP signature

buildkernel broken in HEAD

2014-11-05 Thread Gary Jennejohn

HEAD updated just minutes ago:

--
>>> stage 3.1: making dependencies
--
@/amd64/amd64/genassym.c:79:16: error: no member named 'pm_save' in 'pmap'
ASSYM(PM_SAVE, offsetof(struct pmap, pm_save));

pm_save is not present in any pmap.h under /sys.

-- 
Gary Jennejohn
___
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: r273165. ZFS ARC: possible memory leak to Inact

2014-11-05 Thread Andriy Gapon

On 05/11/2014 14:36, James R. Van Artsdalen wrote:
> I wonder if this is related to PR
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194513
> 
> This is against "zfs recv" and hanging in process state "kmem arena" &
> but also has a workaround of allocating lots of memory in userland.

If something hangs (appears to hang) and it's ZFS related, then
https://wiki.freebsd.org/AvgZfsDeadlockDebug

> But I do not see a lot of inactive with that PR.
> 
> "zpool history" also hangs sometimes in "kmem arena" but I do not have
> a  workaround for that.


-- 
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: r273165. ZFS ARC: possible memory leak to Inact

2014-11-05 Thread James R. Van Artsdalen

On 11/4/2014 5:47 AM, Dmitriy Makarov wrote:
> Funny thing is that when we manually allocate and release memory, using 
> simple python script:
...
>
> Current workaround is to periodically invoke this python script by cron.
>

I wonder if this is related to PR

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194513

This is against "zfs recv" and hanging in process state "kmem arena" &
but also has a workaround of allocating lots of memory in userland.

But I do not see a lot of inactive with that PR.

"zpool history" also hangs sometimes in "kmem arena" but I do not have
a  workaround for that.

This PR is filed against 10-STABLE but confirmed against CURRENT too.

SUPERTEX:/root# uname -a
FreeBSD SUPERTEX.housenet.jrv 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #3
r273476M: Wed Oct 22 15:05:29 CDT 2014
r...@supertex.housenet.jrv:/usr/obj/usr/src/sys/GENERIC  amd64
SUPERTEX:/root# top
last pid: 37286;  load averages:  0.03,  0.05,  0.05  up
11+11:24:34  06:25:46
39 processes:  1 running, 38 sleeping
CPU:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
Mem: 6444K Active, 57M Inact, 6475M Wired, 25G Free
ARC: 4753M Total, 862M MFU, 2765M MRU, 52K Anon, 139M Header, 986M Other
Swap: 31G Total, 21M Used, 31G Free

  PID USERNAMETHR PRI NICE   SIZERES STATE   C   TIMEWCPU
COMMAND
  676 root  1  200 25456K  1048K select  8   0:22   0.00% ntpd
  723 root  1  200 24112K  1472K select 13   0:09   0.00%
sendmail
12105 root  1  200   103M 35984K kmem a 11   0:04   0.00% zpool
  693 root  1  200 30676K  1684K nanslp 10   0:03   0.00% smartd
  519 root  1  200 14508K   684K select  5   0:02   0.00%
syslogd

___
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-tests2 #191

2014-11-05 Thread jenkins-admin

See 

--
[...truncated 2998 lines...]
libexec/atf/atf-check/atf-check_test:eflag_negated  ->  passed  [0.134s]
libexec/atf/atf-check/atf-check_test:stdin  ->  passed  [0.064s]
libexec/atf/atf-check/atf-check_test:invalid_umask  ->  passed  [0.060s]
libexec/atf/atf-sh/atf_check_test:info_ok  ->  passed  [0.158s]
libexec/atf/atf-sh/atf_check_test:expout_mismatch  ->  passed  [0.129s]
libexec/atf/atf-sh/atf_check_test:experr_mismatch  ->  passed  [0.129s]
libexec/atf/atf-sh/atf_check_test:null_stdout  ->  passed  [0.114s]
libexec/atf/atf-sh/atf_check_test:null_stderr  ->  passed  [0.115s]
libexec/atf/atf-sh/atf_check_test:equal  ->  passed  [0.236s]
libexec/atf/atf-sh/atf_check_test:flush_stdout_on_timeout  ->  passed  [1.079s]
libexec/atf/atf-sh/config_test:has  ->  passed  [0.204s]
libexec/atf/atf-sh/config_test:get  ->  passed  [0.161s]
libexec/atf/atf-sh/integration_test:no_args  ->  passed  [0.062s]
libexec/atf/atf-sh/integration_test:missing_script  ->  passed  [0.065s]
libexec/atf/atf-sh/integration_test:arguments  ->  passed  [0.116s]
libexec/atf/atf-sh/integration_test:custom_shell__command_line  ->  passed  
[0.093s]
libexec/atf/atf-sh/integration_test:custom_shell__shebang  ->  passed  [0.082s]
libexec/atf/atf-sh/integration_test:set_e  ->  passed  [0.085s]
libexec/atf/atf-sh/normalize_test:main  ->  passed  [0.096s]
libexec/atf/atf-sh/tc_test:default_status  ->  passed  [0.195s]
libexec/atf/atf-sh/tc_test:missing_body  ->  passed  [0.083s]
libexec/atf/atf-sh/tp_test:srcdir  ->  passed  [0.111s]
libexec/rtld-elf/ld_library_pathfds:missing_library  ->  passed  [0.028s]
libexec/rtld-elf/ld_library_pathfds:wrong_library_directories  ->  passed  
[0.026s]
libexec/rtld-elf/ld_library_pathfds:bad_library_directories  ->  passed  
[0.025s]
libexec/rtld-elf/ld_library_pathfds:single_library_directory  ->  passed  
[0.024s]
libexec/rtld-elf/ld_library_pathfds:first_library_directory  ->  passed  
[0.025s]
libexec/rtld-elf/ld_library_pathfds:middle_library_directory  ->  passed  
[0.025s]
libexec/rtld-elf/ld_library_pathfds:last_library_directory  ->  passed  [0.023s]
usr.bin/cut/cut_test:basic  ->  passed  [0.079s]
usr.bin/cut/cut_test:sflag  ->  passed  [0.074s]
usr.bin/cut/cut_test:dflag  ->  passed  [0.070s]
usr.bin/cut/cut_test:dsflag  ->  passed  [0.074s]
usr.bin/cut/cut_test:latin1  ->  passed  [0.086s]
usr.bin/cut/cut_test:utf8  ->  passed  [0.113s]
usr.bin/gzip/gzip_test:concatenated  ->  passed  [0.090s]
usr.bin/gzip/gzip_test:pipe  ->  passed  [1.705s]
usr.bin/gzip/gzip_test:truncated  ->  passed  [0.139s]
usr.bin/gzip/gzip_test:crcerror  ->  passed  [0.074s]
usr.bin/gzip/gzip_test:good  ->  passed  [0.068s]
usr.bin/calendar/legacy_test:main  ->  passed  [1.513s]
usr.bin/mkimg/mkimg:apm_1x1_512_qcow  ->  passed  [0.825s]
usr.bin/mkimg/mkimg:apm_1x1_512_qcow2  ->  passed  [0.717s]
usr.bin/mkimg/mkimg:apm_1x1_512_raw  ->  passed  [1.528s]
usr.bin/mkimg/mkimg:apm_1x1_512_vhd  ->  passed  [0.973s]
usr.bin/mkimg/mkimg:apm_1x1_512_vhdf  ->  passed  [1.395s]
usr.bin/mkimg/mkimg:apm_1x1_512_vmdk  ->  passed  [1.368s]
usr.bin/mkimg/mkimg:bsd_1x1_512_qcow  ->  passed  [1.084s]
usr.bin/mkimg/mkimg:bsd_1x1_512_qcow2  ->  passed  [0.677s]
usr.bin/mkimg/mkimg:bsd_1x1_512_raw  ->  passed  [0.788s]
usr.bin/mkimg/mkimg:bsd_1x1_512_vhd  ->  passed  [0.953s]
usr.bin/mkimg/mkimg:bsd_1x1_512_vhdf  ->  passed  [1.779s]
usr.bin/mkimg/mkimg:bsd_1x1_512_vmdk  ->  passed  [0.805s]
usr.bin/mkimg/mkimg:ebr_1x1_512_qcow  ->  passed  [1.227s]
usr.bin/mkimg/mkimg:ebr_1x1_512_qcow2  ->  passed  [2.401s]
usr.bin/mkimg/mkimg:ebr_1x1_512_raw  ->  passed  [1.012s]
usr.bin/mkimg/mkimg:ebr_1x1_512_vhd  ->  passed  [0.932s]
usr.bin/mkimg/mkimg:ebr_1x1_512_vhdf  ->  passed  [0.867s]
usr.bin/mkimg/mkimg:ebr_1x1_512_vmdk  ->  passed  [2.457s]
usr.bin/mkimg/mkimg:gpt_1x1_512_qcow  ->  passed  [0.697s]
usr.bin/mkimg/mkimg:gpt_1x1_512_qcow2  ->  passed  [1.752s]
usr.bin/mkimg/mkimg:gpt_1x1_512_raw  ->  passed  [0.753s]
usr.bin/mkimg/mkimg:gpt_1x1_512_vhd  ->  passed  [0.653s]
usr.bin/mkimg/mkimg:gpt_1x1_512_vhdf  ->  passed  [0.806s]
usr.bin/mkimg/mkimg:gpt_1x1_512_vmdk  ->  passed  [0.760s]
usr.bin/mkimg/mkimg:mbr_1x1_512_qcow  ->  passed  [2.012s]
usr.bin/mkimg/mkimg:mbr_1x1_512_qcow2  ->  passed  [1.963s]
usr.bin/mkimg/mkimg:mbr_1x1_512_raw  ->  passed  [2.774s]
usr.bin/mkimg/mkimg:mbr_1x1_512_vhd  ->  passed  [3.180s]
usr.bin/mkimg/mkimg:mbr_1x1_512_vhdf  ->  passed  [1.032s]
usr.bin/mkimg/mkimg:mbr_1x1_512_vmdk  ->  passed  [0.950s]
usr.bin/mkimg/mkimg:pc98_1x1_512_qcow  ->  passed  [1.807s]
usr.bin/mkimg/mkimg:pc98_1x1_512_qcow2  ->  passed  [0.922s]
usr.bin/mkimg/mkimg:pc98_1x1_512_raw  ->  passed  [2.933s]
usr.bin/mkimg/mkimg:pc98_1x1_512_vhd  ->  passed  [1.217s]
usr.bin/mkimg/mkimg:pc98_1x1_512_vhdf  ->  passed  [2.472s]
usr.bin/mkimg/mkimg:pc98_1x1_512_vmdk  ->  passed  [1.017s]
usr.bin/mkimg/mkimg:vtoc8_1x1_512_qcow  ->  pass

Re: r273165. ZFS ARC: possible memory leak to Inact

2014-11-05 Thread Dmitriy Makarov

Steven Hartland wrote
> On 05/11/2014 06:15, Marcus Reid wrote:
>> On Tue, Nov 04, 2014 at 06:13:44PM +, Steven Hartland wrote:
>>> On 04/11/2014 17:22, Allan Jude wrote:
 snip...
 Justin Gibbs and I were helping George from Voxer look at the same
 issue
 they are having. They had ~169GB in inact, and only ~60GB being used
 for
 ARC.

 Are there any further debugging steps we can recommend to him to help
 investigate this?
>>> The various scripts attached to the ZS ARC behavior problem and fix PR
>>> will help provide detail this.
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594
>>>
>>> I've seen it here where there's been bursts of ZFS I/O specifically
>>> write bursts.
>>>
>>> What happens is that ZFS will consume large amounts of space in various
>>> UMA zones to accommodate these bursts.
>> If you push the vmstat -z that he provided through the arc summary
>> script, you'll see that this is not what is happening.  His uma stats
>> match up with his arc, and do not account for his inactive memory.
>>
>> uma script summary:
>>
>>  Totals
>>  oused: 5.860GB, ofree: 1.547GB, ototal: 7.407GB
>>  zused: 56.166GB, zfree: 3.918GB, ztotal: 60.084GB
>>  used: 62.026GB, free: 5.465GB, total: 67.491GB
>>
>> His provided top stats:
>>
>>  Mem: 19G Active, 20G Inact, 81G Wired, 59M Cache, 3308M Buf, 4918M
>> Free
>>  ARC: 66G Total, 6926M MFU, 54G MRU, 8069K Anon, 899M Header, 5129M
>> Other
>>
>>
>> The big uma buckets (zio_buf_16384 and zio_data_buf_131072, 18.002GB and
>> 28.802GB respectively) are nearly 0% free.
>>
> Still potentially accounts for 5.4GB of your 20GB inact.
> 
> The rest could be malloc backed allocations?

No. 

There are few reasons for that. 
The first one is that Inact constantly grows, and 20GiB you see were 50GiBs
before we ran the script.
(We have to run it periodically or else our production server will grow
slower and slower)

The second argumens is that our codebase is the same, the only thing that
have changed is OS version.
In the previous version Inact was dramatically much smaller: ~hundrets of
megabytes. 



--
View this message in context: 
http://freebsd.1045724.n5.nabble.com/r273165-ZFS-ARC-possible-memory-leak-to-Inact-tp5962410p5962711.html
Sent from the freebsd-current mailing list archive at Nabble.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"

Re: r273165. ZFS ARC: possible memory leak to Inact

2014-11-05 Thread Steven Hartland



On 05/11/2014 09:52, Andriy Gapon wrote:

On 04/11/2014 14:55, Steven Hartland wrote:

This is likely spikes in uma zones used by ARC.

The VM doesn't ever clean uma zones unless it hits a low memory condition, which
explains why your little script helps.

Check the output of vmstat -z to confirm.

Steve,

this is nonsense :-)  You know perfectly well that UMA memory is Wired not 
Inactive.


I'll wake up in a bit honest, thanks for the slap ;-)
___
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: r273165. ZFS ARC: possible memory leak to Inact

2014-11-05 Thread Andriy Gapon

On 04/11/2014 14:55, Steven Hartland wrote:
> This is likely spikes in uma zones used by ARC.
> 
> The VM doesn't ever clean uma zones unless it hits a low memory condition, 
> which
> explains why your little script helps.
> 
> Check the output of vmstat -z to confirm.

Steve,

this is nonsense :-)  You know perfectly well that UMA memory is Wired not 
Inactive.

-- 
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: r273165. ZFS ARC: possible memory leak to Inact

2014-11-05 Thread Andriy Gapon

On 04/11/2014 14:55, Steven Hartland wrote:
> This is likely spikes in uma zones used by ARC.
> 
> The VM doesn't ever clean uma zones unless it hits a low memory condition, 
> which
> explains why your little script helps.
> 
> Check the output of vmstat -z to confirm.

Steve,

this is nonsense :-)  You know perfectly well that UMA memory is Wired not 
Inactive.

-- 
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: pkg 1.4 freeze please test test test!

2014-11-05 Thread Andriy Gapon

On 29/10/2014 15:53, Baptiste Daroussin wrote:
> yes remove the current pkg
> 
> pkg delete -f pkg
> 
> install ports-mgmt/pkg-devel (adding WITH_PKG=devel in make.conf)
> use it

So, I followed these instructions and got pkg replaced with 1.4.0.p.a16.
Then I ran pkg upgrade like this:
$ pkg upgrade -y
Updating FreeBSD repository catalogue...
pkg: Repository FreeBSD has a wrong packagesite, need to re-create database
Fetching meta.txz: 100%   944 B   0.9k/s00:01
Fetching digests.txz: 100%2 MB   2.1M/s00:01
Fetching packagesite.txz: 100%5 MB   5.3M/s00:01
Processing new repository entries: 100%
FreeBSD repository update completed. 23591 packages processed:
  0 updated, 0 removed and 23591 added.
Updating poudriere repository catalogue...
poudriere repository is up-to-date.
Updating database digests format: 100%
New version of pkg detected; it needs to be installed first.
Checking integrity... done (0 conflicting)
Your packages are up to date.
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
Updating poudriere repository catalogue...
poudriere repository is up-to-date.
All repositories are up-to-date.
Checking for upgrades (297 candidates):   0%
Checking for upgrades (297 candidates):  10%
Checking for upgrades (297 candidates): 100%
Processing candidates (297 candidates): 100%
Assertion failed: (curvar != NULL), function pkg_solve_add_request_rule, file
pkg_solve.c, line 463.
Child process pid=78582 terminated abnormally: Abort trap

$ pkg -vv
Version : 1.4.0.pre-alpha16
PKG_DBDIR = "/usr/local/var/db/pkg";
PKG_CACHEDIR = "/var/cache/pkg";
PORTSDIR = "/usr/ports";
INDEXDIR = "";
INDEXFILE = "INDEX-11";
HANDLE_RC_SCRIPTS = false;
ASSUME_ALWAYS_YES = false;
REPOS_DIR [
"/etc/pkg/",
"/usr/local/etc/pkg/repos/",
]
PLIST_KEYWORDS_DIR = "";
SYSLOG = false;
ABI = "FreeBSD:11:amd64";
ALTABI = "freebsd:11:x86:64";
DEVELOPER_MODE = false;
VULNXML_SITE = "http://www.vuxml.org/freebsd/vuln.xml.bz2";;
FETCH_RETRY = 3;
PKG_PLUGINS_DIR = "/usr/local/lib/pkg/";
PKG_ENABLE_PLUGINS = true;
PLUGINS [
]
DEBUG_SCRIPTS = false;
PLUGINS_CONF_DIR = "/usr/local/etc/pkg/";
PERMISSIVE = false;
REPO_AUTOUPDATE = true;
NAMESERVER = "";
EVENT_PIPE = "";
FETCH_TIMEOUT = 30;
UNSET_TIMESTAMP = false;
SSH_RESTRICT_DIR = "";
PKG_ENV {
}
PKG_SSH_ARGS = "";
DEBUG_LEVEL = 0;
ALIAS {
}
CUDF_SOLVER = "";
SAT_SOLVER = "";
RUN_SCRIPTS = true;
CASE_SENSITIVE_MATCH = false;
LOCK_WAIT = 1;
LOCK_RETRIES = 5;
SQLITE_PROFILE = false;
WORKERS_COUNT = 0;
READ_LOCK = false;
PLIST_ACCEPT_DIRECTORIES = false;
IP_VERSION = 0;

Repositories:
  FreeBSD: {
url : "pkg+http://pkg.FreeBSD.org/FreeBSD:11:amd64/latest";,
enabled : yes,
mirror_type : "SRV",
signature_type  : "FINGERPRINTS",
fingerprints: "/usr/share/keys/pkg"
  }
  poudriere: {
url : 
"file:///usr/local/poudriere/data/packages/basejail-default",
enabled : yes
  }

-- 
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: r273165. ZFS ARC: possible memory leak to Inact

2014-11-05 Thread Steven Hartland



On 05/11/2014 06:15, Marcus Reid wrote:

On Tue, Nov 04, 2014 at 06:13:44PM +, Steven Hartland wrote:

On 04/11/2014 17:22, Allan Jude wrote:

snip...
Justin Gibbs and I were helping George from Voxer look at the same issue
they are having. They had ~169GB in inact, and only ~60GB being used for
ARC.

Are there any further debugging steps we can recommend to him to help
investigate this?

The various scripts attached to the ZS ARC behavior problem and fix PR
will help provide detail this.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594

I've seen it here where there's been bursts of ZFS I/O specifically
write bursts.

What happens is that ZFS will consume large amounts of space in various
UMA zones to accommodate these bursts.

If you push the vmstat -z that he provided through the arc summary
script, you'll see that this is not what is happening.  His uma stats
match up with his arc, and do not account for his inactive memory.

uma script summary:

 Totals
 oused: 5.860GB, ofree: 1.547GB, ototal: 7.407GB
 zused: 56.166GB, zfree: 3.918GB, ztotal: 60.084GB
 used: 62.026GB, free: 5.465GB, total: 67.491GB

His provided top stats:

 Mem: 19G Active, 20G Inact, 81G Wired, 59M Cache, 3308M Buf, 4918M Free
 ARC: 66G Total, 6926M MFU, 54G MRU, 8069K Anon, 899M Header, 5129M Other


The big uma buckets (zio_buf_16384 and zio_data_buf_131072, 18.002GB and
28.802GB respectively) are nearly 0% free.


Still potentially accounts for 5.4GB of your 20GB inact.

The rest could be malloc backed allocations?

Regards
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: HEADS UP: Enabling vt(4) by default

2014-11-05 Thread Gary Jennejohn

On Tue, 04 Nov 2014 18:01:41 -0800
"Chris H"  wrote:

> On Tue, 04 Nov 2014 18:22:06 +0100 Jean-Sebastien Pedron
>  wrote
> 
> > Hello!
> > 
> > As announced a week ago, vt(4) is now the default console driver in
> > 11-CURRENT as of r274085.
> > 
> > You may have to update your console settings in /etc/rc.conf. During
> > boot, /etc/rc.d/syscons will indicate what you need to do.
> > 
> > The original HEADS UP mentioned several known issues. Among them, the
> > following were fixed:
> > 
> > o  A video mode can be selected using the following tunable in
> >/boot/loader.conf:
> >kern.vt.fb.default_mode="1024x768"
> > 
> >This only works when using a KMS video driver. It's not
> >supported by the VGA backend. See vt(4) man page for further
> >documentation.
> > 
> > o  The keyboard was not working when kbdmux(4) was disabled. This
> >is fixed.
> > 
> > o  After loading a KMS driver, the text cursor was in the middle of
> >the kernel messages. The problem was that the cursor position was
> >not updated after the change in window size. This is fixed.
> > 
> > Up-to-date information can be found on the wiki page:
> > https://wiki.freebsd.org/Newcons
> > 
> > If you want to keep using syscons(4), you can add the following line to
> > /boot/loader.conf:
> > kern.vty=sc
> > 
> > Thank you to everyone who tested and reported problems! Please continue
> > to do so, especially if you find the need to go back to syscons.
> 
> No. Thank _you_! :)
> 
> I was unable to determine from the wiki. But do all these wonderful
> new features also work with the nVidia blob, under vt(4)?
> I'm currently building a new 11-CURRENT from the 10-26 iso, as I write
> this, and was wondering if the graphics mode at higher resolutions was
> now possible using the nVidia blob.
> 

No, video mode won't work with the nVidia blob.  That requires
a KMS (in-kernel) driver.

-- 
Gary Jennejohn
___
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 still unstable: FreeBSD_HEAD-tests2 #190

2014-11-05 Thread 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"

44 matches

Mail list logo