Andrey Fesenko | 22 Apr 18:18 2014

ZFS bug or feature

After detach ada0 and attach him (reboot between that)

boot only one disk
Apr 17 13:33:52 x220 kernel: ada0 at ahcich2 bus 0 scbus0 target 0 lun 0
Apr 17 13:33:52 x220 kernel: ada0: <OCZ-NOCTI 2.15> ATA-8 SATA 2.x device
Apr 17 13:33:52 x220 kernel: ada0: Serial Number OCZ-J8928HU1G10KR9XM
Apr 17 13:33:52 x220 kernel: ada0: 300.000MB/s transfers (SATA 2.x,
UDMA6, PIO 8192bytes)
Apr 17 13:33:52 x220 kernel: ada0: Command Queueing enabled
Apr 17 13:33:52 x220 kernel: ada0: 114473MB (234441648 512 byte
sectors: 1H 63S/T 65535C)
Apr 17 13:33:52 x220 kernel: ada0: Previously was known as ad4

After attach ada0 im see this

# camcontrol devlist
<Corsair Neutron SSD M206>         at scbus0 target 0 lun 0 (ada0,pass0)
<OCZ-NOCTI 2.15>                   at scbus1 target 0 lun 0 (ada1,pass1)

# zpool status
  pool: x220pool
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
        still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
        the pool may no longer be accessible by software that does not support
        the features. See zpool-features(7) for details.
  scan: resilvered 42.4M in 0h0m with 0 errors on Thu Apr 17 13:48:42 2014

(Continue reading)

Hiroo Ono (小野寛生 | 22 Apr 16:38 2014

Three LOR in r264695

I encountered three LOR in head r264695.

The 1st and 2nd are the same and it does not seem to be in ,
though similar LORs exist.
The 3rd seems to be LOR #276
did not look into further detail.

lock order reversal:
 1st 0xc6d3b7f8 ufs (ufs)  <at> 
 2nd 0xc5829838 bufwait (bufwait)  <at> 
 3rd 0xc6bd3150 ufs (ufs)  <at> 
KDB: stack backtrace:
kdb_backtrace(c11684b4,c6082800,c119df21,c5d9acf8,c119db45,...) at
0xc0b1a620 = kdb_backtrace+0x30/frame 0xe8f6e7d4
witness_checkorder(c6082800,9,c119db45,11c,0,...) at 0xc0b36cf4 =
witness_checkorder+0xd04/frame 0xe8f6e820
_sx_xlock(c6082800,0,c119db45,11c,c667a000,...) at 0xc0ae84a5 =
_sx_xlock+0x75/frame 0xe8f6e850
ufsdirhash_add(c6a97c3c,e8f6e948,80c,e8f6e8d0,e8f6e8d4,...) at
0xc0d7f237 = ufsdirhash_add+0x37/frame 0xe8f6e880
ufs_direnter(c6aab8e0,c6c55b18,e8f6e948,e8f6eb64,c58cf5c0,...) at
0xc0d82144 = ufs_direnter+0x604/frame 0xe8f6e900
ufs_mkdir(e8f6ec00,c1410ba8,c6aab8e0,e8f6ebfc,12b,...) at 0xc0d8b0c2 =
ufs_mkdir+0x8c2/frame 0xe8f6ea9c
VOP_MKDIR_APV(c13fb850,e8f6ec00,e8f6eb64,e8f6eb90,28cd86b0,...) at
0xc101778e = VOP_MKDIR_APV+0xfe/frame 0xe8f6eac8
(Continue reading)

Russo Colleen | 22 Apr 10:05 2014

A Tiny Float Alert For You Subpenny Lovers

He may have also owned a ropewalk in Baltimore. It is a fluvial parade done in the afternoon of the 2nd day of the fiesta. The Law Book Company, 1982. Made more than 150 roles, and in 1936 became a First Class Actor of the National Theatre. Hank Aaron receiving honors from Tom Bradley, Ernest Debs and John Ferraro before Braves vs Dodgers game, Calif.
English playwright, screenwriter, director and actor. The excitement of printmaking for Alps was in the creative process. Some Irish mobsters, in a plot to recover their drugs, take Adam and the two cops hostage. Sengoku Featherweight Grand Prix Opening Round. The production is reminiscent of that of a movie replete with soundesign and FX.
Wade, and when Cassie and Adam visit, they find out that Heather has not moved in the sixteen years since the fire. Seeds are subject to change as more players commit to the event. Dr Bogle and Mrs Chandler left the party soon after 4 a. Wilson added various buildings including the Crichton Memorial Church. Isaac's circumcision, Regensburg c1300.
This is then followed by the species accounts themselves, from pages 87 to 764. Hall's opportunities in the first team in both 1963 and 1964 were much reduced. By 1761, the Islington Turnpike Trust built City Road, to meet this road from the City. He then finds Dane who is about to depart in a chopper hovering over the train. One of the biggest employers is Christchurch City Council with 800 FTE at the civic offices.
In a restaurant, Jessie sees dolls nearly identical to the ones that Carlos showed her. Later, in 1953, two years before he died, he met the newly crowned Queen Elizabeth II. Hazy air hindered the attempts despite good weather conditions. Borel as Minister of War. In short time, Narayanan Kutty fells in love with Mala, whom he mistakes to be Sujatha.
Miriam Novitch, Lucy Dawidowicz, Tom L. Jack Partington, in August 1926. Mixed Hype Sessions Vol. Kramon did not decide the songs to be featured, but composed and created the whole score. Especially aromatic compounds are not differentiated from normal ring containing components.
takehara.mikihito | 22 Apr 09:21 2014

uninitialized journal data written in SU+J ?


I'm testing UFS with SU+J. But it seems sometimes broken journal data has written.

In softdep_process_journal (ffs_softdep.c), there is a while code to build jsegrec and each entry.
But by my test, sometimes there is no entry then break this while code without building jsegrec.
If this happens, bp->b_data is not initialized but this bp is written, I think.

I checked this behavior by following patch.
diff --git a/sys/ufs/ffs/ffs_softdep.c b/sys/ufs/ffs/ffs_softdep.c
index 585af50..2d4939c 100644
--- a/sys/ufs/ffs/ffs_softdep.c
+++ b/sys/ufs/ffs/ffs_softdep.c
 <at>  <at>  -3421,6 +3421,15  <at>  <at>  softdep_process_journal(mp, needwk, flags)
                        data = bp->b_data + off;
+#if 1
+               if (off == 0) {
+                       struct jsegrec *tmp = (struct jsegrec*)bp->b_data;
+                       if (tmp->jsr_seq != jseg->js_seq) {
+                               panic("test test");
+                       }
+               }
                 * Write this one buffer and continue.

If uninitialized data is "valid" by fsck suj, this may result filesystem corruption, I think.
I think it's better to clear b_data before using it.

freebsd-current <at> mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at>"

Glen Barber | 22 Apr 04:54 2014

Build failures with high parallel make(1) jobs with GCC

I have been pounding my head against the desk for longer than I care to
admit with this failure.

I see this with powerpc, powerpc64, and now ia64.  I initially thought
it was specific to powerpc{,64}, but now realize ia64 is also affected.

This build was running with -j48 on a 48-core machine, when the
following caused build failure:


/usr/obj/ia64.ia64/usr/src/tmp/usr/bin/ld: cannot find -lm
--- ---
*** [] Error code 1

make[4]: stopped in /usr/src/gnu/lib/libstdc++
A failure has been detected in another branch of the parallel make


It is unclear to me when exactly this started happening, but it seems at
least two weeks is a reasonable estimate.

I realize this is not an entirely large chunk of useful information
regarding the build failure, but I have determined it is entirely
reproducible.  I have determined that the failure case seems to
disappear with make(1) jobs <= 10, at least for powerpc.

The last successful build for powerpc on head/ was April 8.  But I am
having trouble tracking down what commits may (or may not) have
contributed to recent high-parallel build failures.


O. Hartmann | 21 Apr 09:03 2014

r264702: kldxref: /boot/modules/kldxref.core: too many sections

On FreeBSD 11.0-CURRENT #0 r264702: Sun Apr 20 23:56:04 CEST 2014 amd64

I receive this mysterious message several times when compiling a new kernel an
automatically build virtualbox-ose-kmod-4.3.10. What is this supposed to mean?

===>  Deinstalling for emulators/virtualbox-ose-kmod
===>   Deinstalling 
pkg-static: You are trying to delete package(s) which has dependencies that are still
required: emulators/virtualbox-ose-kmod: emulators/virtualbox-ose
... delete these packages anyway in forced mode
Deinstallation has been requested for the following 1 packages:


The deinstallation will free 394 KB
[1/1] Deleting virtualbox-ose-kmod-4.3.10...
virtualbox-ose-kmod-4.3.10 is required by: virtualbox-ose-4.3.10, deleting anyway
kldxref: /boot/modules/kldxref.core: too many sections
kldxref: /boot/modules/kldxref.core: too many sections
kldxref: /boot/modules/kldxref.core: too many sections
kldxref: /boot/modules/kldxref.core: too many sections
kldxref: /boot/modules/kldxref.core: too many sections
kldxref: /boot/modules/kldxref.core: too many sections
kldxref: Skipping /boot/modules/kldxref.core: not dynamically-linked
===>  Installing for virtualbox-ose-kmod-4.3.10
===>   Registering installation for virtualbox-ose-kmod-4.3.10
kldxref: /boot/modules/kldxref.core: too many sections
kldxref: /boot/modules/kldxref.core: too many sections
kldxref: /boot/modules/kldxref.core: too many sections
kldxref: /boot/modules/kldxref.core: too many sections
kldxref: /boot/modules/kldxref.core: too many sections
kldxref: /boot/modules/kldxref.core: too many sections
kldxref: Skipping /boot/modules/kldxref.core: not dynamically-linked
Installing virtualbox-ose-kmod-4.3.10... done
R. Tyler Croy | 20 Apr 03:36 2014

UFS lock order reversal stack trace with r264677 on i386

I've noticed this as of late on my i386 -CURRENT Thinkpad T43 when I 
perform some file operations, but an exact reproduction case I've not 
yet stumbled upon:

Apr 20 01:29:32 lemon kernel: lock order reversal:
Apr 20 01:29:32 lemon kernel: 1st 0xc5832358 bufwait (bufwait)  <at>  
Apr 20 01:29:32 lemon kernel: 2nd 0xc6f1d600 dirhash (dirhash)  <at>  
Apr 20 01:29:32 lemon kernel: KDB: stack backtrace:
Apr 20 01:29:32 lemon kernel: 
at db_trace_self_wrapper+0x2d/frame 0xe93ba918
Apr 20 01:29:32 lemon kernel: 
kdb_backtrace(c115e882,c6f1d600,c1192fe7,c5dae950,c1192c15,...) at 
kdb_backtrace+0x30/frame 0xe93ba980
Apr 20 01:29:32 lemon kernel: 
witness_checkorder(c6f1d600,9,c1192c15,11c,0,...) at 
witness_checkorder+0xd04/frame 0xe93ba9cc
Apr 20 01:29:32 lemon kernel: 
_sx_xlock(c6f1d600,0,c1192c15,11c,c5832300,...) at _sx_xlock+0x75/frame 
Apr 20 01:29:32 lemon kernel: 
ufsdirhash_remove(c6c26bc8,db6e02fc,2fc,e93baa58,e93baa54,...) at 
ufsdirhash_remove+0x37/frame 0xe93baa24
Apr 20 01:29:32 lemon kernel: 
ufs_dirremove(c6c1f238,c73c0d98,400800c,0,c6c1f238,...) at 
ufs_dirremove+0x12c/frame 0xe93baa68
Apr 20 01:29:32 lemon kernel: 
ufs_remove(e93bac00,c11683ae,a8b,e93babfc,0,...) at 
ufs_remove+0x76/frame 0xe93baaac
Apr 20 01:29:32 lemon kernel: 
VOP_REMOVE_APV(c13e8d1c,e93bac00,c73c2e6c,e93babd4,81a5b18,...) at 
VOP_REMOVE_APV+0xfe/frame 0xe93baad8
Apr 20 01:29:32 lemon kernel: 
kern_unlinkat(c6958000,ffffff9c,81a5b18,0,0) at 
kern_unlinkat+0x27a/frame 0xe93bac24
Apr 20 01:29:32 lemon kernel: 
sys_unlink(c6958000,e93bacc8,c0feeaef,c1c25c90,0,...) at 
sys_unlink+0x32/frame 0xe93bac40
Apr 20 01:29:32 lemon kernel: syscall(e93bad08) at syscall+0x30c/frame 
Apr 20 01:29:32 lemon kernel: Xint0x80_syscall() at 
Xint0x80_syscall+0x21/frame 0xe93bacfc
Apr 20 01:29:32 lemon kernel: --- syscall (10, FreeBSD ELF32, 
sys_unlink), eip = 0x2848bd37, esp = 0xbfbfd1bc, ebp = 0xbfbfd248 ---
Apr 20 01:29:54 lemon kernel: lock order reversal:
Apr 20 01:29:54 lemon kernel: 1st 0xc699e388 ufs (ufs)  <at>  
Apr 20 01:29:54 lemon kernel: 2nd 0xc5859e98 bufwait (bufwait)  <at>  
Apr 20 01:29:54 lemon kernel: 3rd 0xc7d27c68 ufs (ufs)  <at>  
Apr 20 01:29:54 lemon kernel: KDB: stack backtrace:
Apr 20 01:29:54 lemon kernel: 
at db_trace_self_wrapper+0x2d/frame 0xe93ba260
Apr 20 01:29:54 lemon kernel: 
kdb_backtrace(c115e89b,c7d27c68,c1144d4e,c5dae8e8,c11683ae,...) at 
kdb_backtrace+0x30/frame 0xe93ba2c4
Apr 20 01:29:54 lemon kernel: 
witness_checkorder(c7d27c68,9,c11683ae,835,c7d27c88,...) at 
witness_checkorder+0xd04/frame 0xe93ba310
Apr 20 01:29:54 lemon kernel: 
__lockmgr_args(c7d27c68,80100,c7d27c88,0,0,...) at 
__lockmgr_args+0x8f3/frame 0xe93ba3f0
Apr 20 01:29:54 lemon kernel: 
ffs_lock(e93ba470,c116537f,c5d8d110,c5d93840,c5d8d110,...) at 
ffs_lock+0x87/frame 0xe93ba42c
Apr 20 01:29:54 lemon kernel: 
VOP_LOCK1_APV(c13e8d1c,e93ba470,c116537f,227,c13fe1f0,...) at 
VOP_LOCK1_APV+0x10a/frame 0xe93ba458
Apr 20 01:29:54 lemon kernel: 
_vn_lock(c7d27c34,80100,c11683ae,835,c11675a0,...) at
Apr 20 01:29:54 lemon kernel: _vn_lock+0xa6/frame 0xe93ba498
Apr 20 01:29:54 lemon kernel: vget(c7d27c34,80100,c6958000,57,0,...) at 
vget+0x74/frame 0xe93ba4d0
Apr 20 01:29:54 lemon kernel: 
vfs_hash_get(c63fad20,70aa44,80000,c6958000,e93ba5d0,...) at 
vfs_hash_get+0xfc/frame 0xe93ba4fc
Apr 20 01:29:54 lemon kernel: 
ffs_vgetf(c63fad20,70aa44,80000,e93ba5d0,1,...) at ffs_vgetf+0x44/frame 
Apr 20 01:29:54 lemon kernel: 
softdep_sync_buf(c699e354,c5859e40,1,0,0,...) at 
softdep_sync_buf+0xbdf/frame 0xe93ba5e8
Apr 20 01:29:54 lemon kernel: ffs_syncvnode(c699e354,1,0,c13c3cdc,0,...) 
at ffs_syncvnode+0x2dd/frame 0xe93ba640
Apr 20 01:29:54 lemon kernel: 
ffs_truncate(c699e354,200,0,880,c5ed0300,...) at 
ffs_truncate+0x6eb/frame 0xe93ba
Apr 20 01:29:54 lemon kernel: 7f0
Apr 20 01:29:54 lemon kernel: 
ufs_direnter(c699e354,c7d27c34,e93ba8b8,e93babcc,0,...) at 
Apr 20 01:29:54 lemon kernel: me 0xe93ba870
Apr 20 01:29:54 lemon kernel: ufs_makeinode(e93babb8,e93babcc) at
Apr 20 01:29:54 lemon kernel: ufs_makeinode+0x534/frame 0xe93ba9f0
Apr 20 01:29:54 lemon kernel: 
ufs_create(e93baad8,614,c63fad30,2,c63fad74,...) at
Apr 20 01:29:54 lemon kernel: ufs_create+0x2f/frame 0xe93baa04
Apr 20 01:29:54 lemon kernel: 
VOP_CREATE_APV(c13e8d1c,e93baad8,e93babcc,e93baa68,c0acc930,...) at 
VOP_CREATE_APV+0xfe/frame 0xe93baa30
Apr 20 01:29:55 lemon kernel: 
vn_open_cred(e93bab70,e93babfc,180,0,c5ed0300,c6960118) at 
vn_open_cred+0x2f0/frame 0xe93bab00
Apr 20 01:29:55 lemon kernel: 
vn_open(e93bab70,e93babfc,180,c6960118,bfbfe843,...) at 
vn_open+0x3d/frame 0xe93bab28
Apr 20 01:29:55 lemon kernel: 
kern_openat(c6958000,ffffff9c,bfbfe843,0,a01,180) at 
kern_openat+0x310/frame 0xe93bac1c
Apr 20 01:29:55 lemon kernel: 
sys_open(c6958000,e93bacc8,c131d50a,d5,0,...) at sys_open+0x39/frame 
Apr 20 01:29:55 lemon kernel: syscall(e93bad08) at syscall+0x30c/frame 
Apr 20 01:29:55 lemon kernel: Xint0x80_syscall() at 
Xint0x80_syscall+0x21/frame 0xe93bacfc
Apr 20 01:29:55 lemon kernel: --- syscall (5, FreeBSD ELF32, sys_open), 
eip = 0x282b7dc3, esp = 0xbfbfe3c4, ebp = 0xbfbfe
Apr 20 01:29:55 lemon kernel: c58 ---

freebsd-current <at> mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at>"

Thomas Hoffmann | 19 Apr 05:46 2014

make delete-old/delete-old-libs issue after r264673 build

After building at -CURRENT amd64 r264673, I got the following errors
running 'make delete-old' and 'make delete-old-libs':

 # make delete-old
make[2]: "/usr/share/mk/" line 239: Could not find
make[2]: "/usr/share/mk/" line 262: Malformed conditional
(${MK_LIBPTHREAD} == "no")
make[2]: "/usr/share/mk/" line 266: Malformed conditional
(${MK_LDNS} == "no")
make[2]: "/usr/share/mk/" line 271: Malformed conditional
(${MK_SOURCELESS} == "no")
make[2]: "/usr/share/mk/" line 276: Malformed conditional
(${MK_CDDL} == "no")
make[2]: "/usr/share/mk/" line 281: Malformed conditional
(${MK_CRYPT} == "no")
make[2]: "/usr/share/mk/" line 287: Malformed conditional
(${MK_CXX} == "no")
make[2]: "/usr/share/mk/" line 292: Malformed conditional
(${MK_MAIL} == "no")
make[2]: "/usr/share/mk/" line 298: Malformed conditional
(${MK_NETGRAPH} == "no")
make[2]: "/usr/share/mk/" line 303: Malformed conditional
(${MK_OPENSSL} == "no")
make[2]: "/usr/share/mk/" line 308: Malformed conditional
(${MK_PF} == "no")
make[2]: "/usr/share/mk/" line 312: Malformed conditional
(${MK_TEXTPROC} == "no")
make[2]: "/usr/share/mk/" line 316: Malformed conditional
(${MK_CROSS_COMPILER} == "no")
make[2]: "/usr/share/mk/" line 322: Malformed conditional
(${MK_TOOLCHAIN} == "no")
make[2]: "/usr/share/mk/" line 329: Malformed conditional
(${MK_CLANG} == "no")
make[2]: "/usr/share/mk/" line 352: Malformed conditional
(defined(WITHOUT_${:UBZIP2}_SUPPORT) || ${MK_${:UBZIP2}} == "no")
make[2]: "/usr/share/mk/" line 352: Malformed conditional
(defined(WITHOUT_${:UGNU}_SUPPORT) || ${MK_${:UGNU}} == "no")
make[2]: "/usr/share/mk/" line 352: Malformed conditional
(defined(WITHOUT_${:UINET}_SUPPORT) || ${MK_${:UINET}} == "no")
make[2]: "/usr/share/mk/" line 352: Malformed conditional
(defined(WITHOUT_${:UINET6}_SUPPORT) || ${MK_${:UINET6}} == "no")
make[2]: "/usr/share/mk/" line 352: Malformed conditional
(defined(WITHOUT_${:UKERBEROS}_SUPPORT) || ${MK_${:UKERBEROS}} == "no")
make[2]: "/usr/share/mk/" line 352: Malformed conditional
(defined(WITHOUT_${:UKVM}_SUPPORT) || ${MK_${:UKVM}} == "no")
make[2]: "/usr/share/mk/" line 352: Malformed conditional
(defined(WITHOUT_${:UNETGRAPH}_SUPPORT) || ${MK_${:UNETGRAPH}} == "no")
make[2]: "/usr/share/mk/" line 352: Malformed conditional
(defined(WITHOUT_${:UPAM}_SUPPORT) || ${MK_${:UPAM}} == "no")
make[2]: "/usr/share/mk/" line 352: Malformed conditional
(defined(WITHOUT_${:UWIRELESS}_SUPPORT) || ${MK_${:UWIRELESS}} == "no")
make[2]: "/usr/share/mk/" line 129: Malformed conditional
(${MK_CTF} != "no")
make[2]: "/usr/share/mk/" line 137: Malformed conditional
(${MK_INSTALL_AS_USER} != "no")
make[2]: Fatal errors encountered -- cannot continuemake[1]:
"/usr/src/Makefile.inc1" line 135: warning: "make -C /usr/src/release -V
REVISION" returned non-zero status
make[2]: "/usr/share/mk/" line 239: Could not find

Maybe r26466{1|2|3|4} could be the source?

freebsd-current <at> mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at>"

yan cui | 18 Apr 04:30 2014

GSOC proposal

Dear all,

    My GSOC 2014 proposal (cpu online offline project) has been updated,
please feel free to give comments. Hope that I can catch the last train.

Thanks, Yan


Think big; Dream impossible; Make it happen.
freebsd-current <at> mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at>"

Gabor Pali | 17 Apr 20:32 2014

FreeBSD Quarterly Status Report, January-March 2014

FreeBSD Quarterly Status Report, January-March 2014

   This report covers FreeBSD-related projects between January and March
   2014. This is the first of four reports planned for 2014.

   Note that there is an HTML version available at


   The first quarter of 2014 was, again, a hectic and productive time for
   FreeBSD. The Ports team released their landmark first quarterly
   "stable" branch. FreeBSD continues to grow on the ARM architecture, now
   running on an ARM-based ChromeBook. SMP is now possible on multi-core
   ARM systems. bhyve, the native FreeBSD hypervisor, continues to
   improve. An integral test suite is taking shape, and the Jenkins
   Continuous Integration system has been implemented. FreeBSD patches to
   GCC are being "forward-ported", and LLDB, the Clang/LLVM debugger is
   being ported. Desktop use has also seen improvements, with work on
   Gnome, KDE, Xfce, KMS video drivers,, and vt, the new console
   driver which supports KMS and Unicode. Linux and Wine binary
   compatibility layers have been improved. UEFI booting support has been
   merged to head. The FreeBSD Foundation continues to assist in moving
   FreeBSD forward, sponsoring conferences and meetings and numerous
   development projects. And these are only some of the things that
   happened! Read on for even more.

   Thanks to all the reporters for the excellent work! This report
   contains 41 entries and we hope you enjoy reading it.

   The deadline for submissions covering between April and June 2014 is
   July 7th, 2014.

FreeBSD Team Reports

     * FreeBSD Cluster Administration Team
     * FreeBSD Core Team
     * FreeBSD Documentation Engineering Team
     * FreeBSD Port Management Team
     * FreeBSD Postmaster Team
     * FreeBSD Release Engineering Team


     * Jenkins Continuous Integration for FreeBSD
     * ZFSguru


     * ASLR and PIE
     * Intel GPU Driver Update
     * Native iSCSI Stack
     * New Automounter
     * PCI SR-IOV Infrastructure
     * SDIO Driver
     * UEFI Boot
     * Updated vt(4) System Console


     * bhyve
     * FreeBSD Host Support for OpenStack and OpenContrail
     * FreeBSD on Chromebook
     * FreeBSD/arm64
     * FreeBSD/armv6hf
     * SMP on Multi-Core ARM Systems

Userland Programs

     * auditdistd(8)
     * External Toolchain Improvements
     * Forward Port FreeBSD GCC
     * FreeBSD Test Suite
     * LLDB Debugger Port


     * Chromium
     * FreeBSD Ada Ports
     * GCC in the Ports Collection
     * GNOME/FreeBSD
     * KDE/FreeBSD
     * libvirt/bhyve Support
     * OpenAFS on FreeBSD
     * The Graphics Stack on FreeBSD
     * Using CentOS 6.5 as Linux Base
     * Wine/FreeBSD
     * Xfce/FreeBSD


     * ZFS Chapter of the Handbook


     * FreeBSD Participating in Summer of Code 2014
     * The FreeBSD Foundation

FreeBSD Cluster Administration Team

   Contact: FreeBSD Cluster Administration Team <admins <at> >

   The FreeBSD Cluster Administration Team consists of the people
   responsible for administering the machines that the project relies on
   for its distributed work and communications to be synchronised. In this
   quarter, the team has worked on the following:

     * Assimilated master email configurations into a single source
       control repository.
     * Moved the FreeBSD web server CGI services to a new location
     * Further enhanced upon our internal monitoring utilities.
     * Added a Russian pkg(8) mirror, hosted by Yandex.
     * Moved the FreeBSD Foundation web services to a new server

   This project is sponsored by The FreeBSD Foundation.

FreeBSD Core Team

   Contact: FreeBSD Core Team <core <at>>

   The FreeBSD Core Team constitutes the project's "Board of Directors",
   responsible for deciding the project's overall goals and direction as
   well as managing specific areas of the FreeBSD project landscape.

   The first quarter of 2014 was very active for the Core Team. John
   Baldwin and David Chisnall kept coordinating the work required for
   providing a newer version of X.Org for 9.x and 10.x systems. Now that
   vt(4), a successor to syscons(4) that offers a KMS-enabled console, has
   been merged to both stable/9 and stable/10, an alternative pkg(8)
   repository is in preparation for wider testing of vt(4) and the new
   X.Org version. In addition to that, John Baldwin published the policy
   on licenses for new files and files with non-standard licenses. Thanks
   to the efforts of Gavin Atkinson, FreeBSD has again made it into the
   Google Summer of Code program, for the tenth time. David Chisnall
   reported that both libc++ and libstdc++ can now be built, as all of the
   standards-compliant implementations of the required numerical functions
   have been added.

   The Core Team conducted an annual review among the Project teams and
   hats, where team members had to declare whether they wished to continue
   their service. As a result, Florian Smeets replaced David Wolfskill in
   the lead role of the Postmaster Team, and Glen Barber assumed the head
   Release Engineer position from Ken Smith. The Core Team congratulates
   Florian and Glen, and thanks David and Ken for their long-standing

   The Core Team approved chartering the Ports Security Team, which is
   established to maintain security updates for the ported applications.
   In coordination with the Port Management Team, pkg_tools was eventually
   deprecated and tagged with an End-of-Life date, in order to clear the
   way for pkg(8). The Port Management Team also requested a way to make
   it possible to track userland ABI and KBI changes reliably for the
   Ports Collection. Ideally this can be achieved by increasing the value
   of __FreeBSD_version on each fix, therefore the corresponding
   discussion concluded in freezing the ABI note tag for releases in order
   to keep the size of binary patches for freebsd-update(8) low. A related
   Errata Notice is about to be published soon.

   Only a single commit bit was taken for safekeeping. We did not have new
   committers to the src/ repository in this quarter.

FreeBSD Documentation Engineering Team


   Contact: FreeBSD Documentation Engineering Team <doceng <at>>

   The FreeBSD Documentation Engineering Team is responsible for defining
   and following up on the documentation goals for the committers in the
   Documentation project. The team is pleased to announce a new member --
   Warren Block. In early March, the FreeBSD Documentation Engineering
   Team members assumed responsibility for the FreeBSD Webmaster Team.

FreeBSD Port Management Team


   Contact: Thomas Abthorpe <portmgr-secretary <at>>
   Contact: Frederic Culot <culot <at>>
   Contact: FreeBSD Port Management Team <portmgr <at>>

   The role of the FreeBSD Port Management Team is to ensure that the
   FreeBSD Ports Developer community provides a ports collection that is
   functional, stable, up-to-date and full-featured. It is also to
   coordinate among the committers and developers who work on it.

   The ports tree slowly approaches the 25,000 ports threshold, while the
   PR count exceeds 1,800. In the first quarter, we added four new
   committers, took in three commit bits for safe keeping, and reinstated
   one commit bit.

   In January, the longest serving port manager, Joe Marcus Clarke,
   stepped down from his active duties on the team. At a similar time
   Ion-Mihai Tetcu also stepped down from his duties. Fortunately, as a
   result of the first portmgr-lurkers intake, we were able to replace
   them with Mathieu Arnold and Antoine Brodin.

   Commencing March 1, the second intake of portmgr-lurkers started active
   duty on portmgr for a four month duration. The next two candidates are
   Alexey Dokuchaev and Frederic Culot.

   This quarter also saw the release of the first quarterly branch, namely
   2014Q1. This branch is intended to provide a stable and high-quality
   ports tree, with patches related to security fixes as well as packaging
   and runtime fixes being backported from head.

   Ongoing maintenance goes into, including QAT runs and
   ports and security updates.

Open tasks:

    1. As previously noted, many PRs continue to languish. We would like
       to see committers dedicate themselves to closing as many as

FreeBSD Postmaster Team

   Contact: FreeBSD Postmaster Team <postmaster <at>>

   The FreeBSD Postmaster Team is responsible for mail being correctly
   delivered to the committers' email addresses, ensuring that the mailing
   lists work, and should take measures against possible disruptions of
   project mail services, such as having troll-, spam- and virus-filters.

   In the first quarter of 2014, the team has implemented these items that
   may be interest of the general public:

     * Continued a discussion on current and possible future mail and spam
     * Discovered more of what needs to be done for a new year (with
       respect to email archives), did what we could, and recorded the
       steps for next time.
     * Added Kubilay Kocak to donations, requested by Pietro Cerutti.
     * Added Warren Block to doceng.
     * Made sure portmgr receives bounces for pkg-fallout messages.
     * Created a jenkins-admin mail alias.
     * Enabled Mailman password reminder emails again.
     * Discovered that all Mailman cron jobs were disabled in November
       during upgrades. Enabled those again. This caused problems like
       digests not being sent.

FreeBSD Release Engineering Team


   Contact: FreeBSD Release Engineering Team <re <at>>

   The FreeBSD Release Engineering Team is responsible for setting and
   publishing release schedules for official project releases of FreeBSD,
   announcing code freezes and maintaining the respective branches, among
   other things.

   In early January, the team became aware of several last-minute
   showstopper issues in FreeBSD 10.0, which led to an extension in the
   final release builds. FreeBSD 10.0-RELEASE was announced on January 20,
   two months behind the original schedule.

   The schedule for the FreeBSD 9.3-RELEASE cycle has been written and
   posted to the website, and the release cycle will begin early May.

   There is ongoing work to integrate support for embedded architectures
   as part of the release build process. At this time, support exists for
   a number of ARM kernels, in particular the Raspberry Pi, BeagleBone,
   and WandBoard.

   This project is sponsored by The FreeBSD Foundation.

Jenkins Continuous Integration for FreeBSD


   Contact: Craig Rodrigues <rodrigc <at>>
   Contact: Jenkins Administrators <jenkins-admin <at>>
   Contact: FreeBSD Testing <freebsd-testing <at>>

   Jenkins is a framework used by many companies and open source projects
   for Continuous Integration (CI). CI allows developers to commit code to
   a Source Code Management (SCM) system such as Subversion, and then have
   automated programs check out, build, and test the code. Jenkins is
   implemented in the Java language.

   Ed Maste reviewed some CI work that Craig Rodrigues had done for the
   FreeNAS project with Jenkins, and encouraged him to set up something
   similar for the FreeBSD Project. With the help of the FreeBSD Cluster
   Administration Team, he set up a FreeBSD machine running two bhyve
   virtual machines, and He
   set up software builds of head and several stable branches on these
   machines. The status of these builds is visible on a web interface
   accessible at When any of the builds fail, emails
   are sent to freebsd-current or freebsd-stable. Emails are also sent
   directly to the list of people who recently committed code to
   Subversion since the last successful build.

   As part of the Jenkins setup, Craig Rodrigues encountered problems with
   running Java on FreeBSD 9.2 and FreeBSD 10.0. Both problems stemmed
   from changes to the FreeBSD Virtual Memory (VM) subsystem. On FreeBSD
   9.2-RELEASE, running Jenkins under Java would cause the kernel to
   panic. This was a known problem, and fixed in 9.2.-RELEASE-p3. On
   FreeBSD 10.0-RELEASE, Java processes would randomly crash. Disabling
   the vm.pmap.pcid_enabled sysctl(3) variable seemed to fix the problem.
   In kern/187238, Henrik Gulbrandsen submitted fixes to the FreeBSD VM to
   address this problem. Konstantin Belousov committed the fixes to head,
   where they are being tested now.

   During the setup of the bhyve VMs which run Jenkins processes, Craig
   Rodrigues wrote scripts to start bhyve VMs from the rc.d bootup
   scripts, which were then published at GitHub.

   On February 19, 2014, Craig Rodrigues notified the FreeBSD developers
   that Jenkins was running in the FreeBSD cluster, and that they could
   look at the web interface to see the status of builds.

   On March 13, 2014, Craig Rodrigues gave a presentation of the Jenkins
   work at the Bay Area FreeBSD User Group (BAFUG) in Mountain View,
   California, USA. Video of the presentation was recorded and put online
   by iXsystems.

   Craig Rodrigues assembled a team of volunteers, jenkins-admin, to help
   maintain and expand the use of Jenkins CI used in
   the FreeBSD cluster. jenkins-admin consists of the following people
   working in the following areas:

     * R. Tyler Croy is both a FreeBSD developer and a Jenkins developer.
       He will be working on fixing bugs in Jenkins specific to FreeBSD.
       He is first looking at fixing the libpam4j library which is used by
       Jenkins to interface with the PAM system for user authentication.
       The released version of libpam4j does not currently work on
     * Li-Wen Hsu maintains the devel/jenkins port. He set up a Jenkins
       build which runs the scan-build static analyzer which is part of
     * Steven Kreuzer has experience administering Jenkins systems. He set
       up several builds on, including a Jenkins build
       of the FreeBSD documentation. He is looking into using Ansible for
       automatic provisioning of VMs running Jenkins in the FreeBSD
     * Craig Rodrigues will be running a Continuous Testing working group
       at the FreeBSD Devsummit in Ottawa on May 15, 2014. He will also
       give a Jenkins presentation on May 17, 2014. He is interested in
       working with Julio Merino to integrate Jenkins and Kyua. They have
       exchanged some emails about this on the freebsd-testing list.
     * Steve Wills maintains the devel/jenkins-lts port. He has
       implemented several builds at which detect
       commits to the FreeBSD ports repository, and then build the ports
       tree using Poudrière.

   At the end of March, Roman Bogorodskiy reported to jenkins-admin that
   he has successfully run the Jenkins libvirt plugin with his libvirt
   modifications to integrate with bhyve. He provided a link to a blog
   posting where he described his experience.

   This project is sponsored by iXsystems, Inc.

Open tasks:

    1. Obtain certificates for LDAP and web servers, to replace
       self-signed certificates.
    2. Set up more Jenkins builds of the FreeBSD base repository on
       different branches and with different configurations.
    3. Set up more Jenkins builds of the FreeBSD ports repository on
       different FreeBSD versions.
    4. Integrate with Kyua, so that Jenkins can run Kyua tests and report
       the results directly in the native Jenkins web UI where test
       results are reported.
    5. Write scripts which can take a Jenkins build of FreeBSD, and boot
       the results in a bhyve VM or on real hardware.
    6. Fix libpam4j on FreeBSD.
    7. Continuous Testing working group at Devsummit on May 15, 2014
    8. Jenkins presentation at BSDCan on May 17, 2014



   Contact: Jason Edwards <sub.mesa <at>>

   ZFSguru is a multifunctional server appliance with a strong emphasis on
   storage. It wants to deliver all the great BSD and ZFS technology to a
   wider audience, while at the same time pleasing more advanced users as
   well with unique features and customization.

   A "vanilla" ZFSguru installation comes with only Samba and a
   web-interface setup, but can be extended easily by installing addons
   called "services" to add functionality as desired. This prevents users
   from running programs they do not need and do not want. Advanced users
   can still use ZFSguru as they would a normal FreeBSD installation with
   a 100% ZFS setup ("Root-on-ZFS"). ZFSguru does not strip away anything,
   and uses a GENERIC-like kernel with only some additional settings added
   like InfiniBand networking, Device Polling and AltQ. This means you can
   use a ZFSguru installation as you would use a FreeBSD installation.

   In the first month of 2014, ZFSguru has released beta9 version of the
   web interface. This release brings vastly improved support for Samba
   and NFS configuration. In particular, it adds a convenient
   drag-and-drop interface for Samba permissions. This allows novice users
   to configure access to shares in various configurations. It allows both
   control and usability, with no manual being necessary in order to
   operate it. This is the ZFSguru style.

   New system versions have been released, based on FreeBSD 9.2, 10.0, and
   head. The experimental head version has vt(4) and 7.12.4 and the
   Intel/Radeon KMS graphics drivers. That is, the latest and greatest of
   FreeBSD graphics development. The ZFSguru project plans to release
   stable/10 builds in the near future which also have the MFCed patches
   for vt(4), the KMS-enabled system console with Unicode support. Please
   see the vt(4) entry for more information.

   Support for ZFS version 5000 is now universal across 9.2, 10.0 and head
   builds. LZ4 compression is the key feature for ZFS version 5000.
   Otherwise users are advised to keep their pool versions as is, to be as
   compatible as you can with as many ZFS platforms as possible. Only
   upgrade the pool as you desire its functionality, forfeiting the
   compatibility with older storage platforms.

Open tasks:

    1. ZFSguru beta10 will increase the compatibility of newly added Samba
       functionality with non-Gecko browsers. It will also fix some minor
       bugs as well as speed up some pages by having a redesigned remote
       database system called GuruDB.
    2. ZFSguru beta11 will add the one major feature still missing in
       ZFSguru: the Migration Manager. This allows users to maintain a
       file with all the configuration of their ZFSguru installation. It
       can be used like a firmware -- restoring the machine to the exact
       state and configuration of the snapshot configuration. It allows
       users to maintain a backup of their ZFSguru configuration and
       allows upgrading to a newer ZFSguru system version without any
    3. Automated system builds should bring more system image releases.
    4. New website with new forum and new login system.
    5. Developer website with GitLab setup, allowing bug reports, code
       contributions, wiki, and wall messages. Note that GitLab has also
       been provided as a ZFSguru service, for those interested in trying



   Contact: Shawn Webb <lattera <at>>
   Contact: Olivér Pintér <oliver.pntr <at>>

   Address space layout randomization (ASLR) is a computer security
   technique involved in protection from buffer overflow attacks. In order
   to prevent an attacker from reliably jumping to a particular exploited
   function in memory, ASLR involves randomly arranging the positions of
   key data areas of a program, including the base of the executable and
   the positions of the stack, heap, and libraries, in a process' address

   We have added ASLR support to all architectures. As the primary
   developers behind this feature have the most access to amd64, the focus
   of development is on the amd64 architecture. Other architectures, such
   as ARM, have known bugs with our current ASLR implementation and we are
   working hard to fix them. We added support for Position-Independent
   Executables (PIEs) in a number of applications in base.

Open tasks:

    1. Shawn has access to a Raspberry Pi (RPI). PIE is 90% broken. Debug
       and fix major issues on the RPI. The existing NX stack protections
       are not obeyed on RPI. Properly implemented ASLR requires a NX
    2. Shawn will be receiving a sparc64 box on April 6, 2014. He will
       test ASLR on sparc64, identifying and fixing any bugs that pop up.
    3. Olivér has identified one or more bugs with the Linuxulator. He
       will be looking into that and fixing those.
    4. Shawn will be cleaning up code and adding support for PIE to more
       applications in base. He will also add PIE support to the ports
       framework for general consumption.
    5. Shawn will be giving a presentation regarding ASLR at BSDCan 2014.

Intel GPU Driver Update

   Contact: Konstantin Belousov <kib <at>>

   The project to update the Intel graphics chipset driver (i915kms) to a
   recent snapshot of the Linux upstream code continues. Progress was
   delayed by external circumstances, but it is hoped to reach a useful
   milestone in the near future.

   This project is sponsored by The FreeBSD Foundation.

Native iSCSI Stack


   Contact: Edward Tomasz Napieral/a <trasz <at>>

   The new FreeBSD in-kernel iSCSI stack was functionally complete in
   FreeBSD 10.0-RELEASE, but ongoing enhancements and bug fixes are being
   committed to FreeBSD head, with a plan to merge them back to stable/10
   in time for FreeBSD 10.1-RELEASE.

   Many issues have been resolved, including very slow operation with data
   digests enabled, bugs in persistent reservations which impacted Hyper-V
   Failover Cluster, and a negotiation problem affecting Dell Equallogic

   There have also been numerous enhancements, such as support for
   redirections, which are necessary for some High Availability setups,
   and the ability to modify session parameters in the iscsictl utility.
   Previously it was necessary to remove the session and add it again.

   This project is sponsored by The FreeBSD Foundation.

New Automounter

   Contact: Edward Tomasz Napieral/a <trasz <at>>

   The automount project is nearing the functional prototype stage, and a
   call for testing is expected in the next month. The userspace portion
   consists of the automountd(8) daemon, which is designed to be fully
   compatible with its counterparts in OS X, Solaris, and Linux, and which
   is nearly complete. Work on the kernel component continues.

   This project is sponsored by The FreeBSD Foundation.

PCI SR-IOV Infrastructure


   Contact: Ryan Stone <rstone <at>>

   PCI Single Root I/O Virtualization (SR-IOV) is an optional part of the
   PCIe standard that provides hardware acceleration for the
   virtualization of PCIe devices. When SR-IOV is in use, a function in a
   PCI device (known as a Physical Function, or PF) will present multiple
   Virtual PCI Functions (VF) on the PCI bus. These VFs are fully
   independent PCI devices that have access to the resources of the PF.
   For example, on a network interface card, VFs could transmit and
   receive packets independent of the PF.

   The most obvious use case for SR-IOV is virtualization. A hypervisor
   like bhyve could instantiate a VF for every VM and use PCI passthrough
   to assign the VFs to the VMs. This would allow multiple VMs to share
   access to the PCI device without having to do any expensive
   communication with the hypervisor, greatly increasing performance of
   performing I/O from a VM.

   There are two parts to this project. The first is implementing an API
   in the PCI subsystem for creating VFs and configuring standard PCI
   features like BARs. The second part is updating individual drivers for
   PCI devices that support SR-IOV to configure their VFs. For example, a
   network interface driver will typically have to assign a MAC address to
   a VF and configure the interface to route packets destined for that MAC
   address to the VF.

   At this point only SR-IOV support for the ixgbe(4) driver is planned.
   The PCI subsystem API is designed to be generic and should support
   SR-IOV on any device, but fairly extensive driver work is necessary to
   support SR-IOV, which is currently not planned due to lack of time and

   At present, ixgbe(4) is able to create VFs and the ixgbevf driver is
   able to pass traffic. There is still a fair amount of work to support
   VLAN tags, multicast addresses, and other features on the VFs. Also,
   the VF configuration needs to be better integrated with the PF
   initialization path to ensure that resets of the PF do not interrupt
   operation of the VFs.

   This project is sponsored by Sandvine, Inc.

SDIO Driver


   Contact: Ilya Bakulin <ilya <at>>

   SDIO is an interface designed as an extension of the existing SD card
   standard, allowing connection of different peripherals to the host with
   the standard SD controller. Peripherals currently sold on the general
   market include WLAN/BT modules, cameras, fingerprint readers, and
   barcode scanners. The FreeBSD driver is implemented as an extension to
   the existing MMC bus, adding a lot of new SDIO-specific bus methods. A
   prototype of the driver for the Marvell SDIO WLAN/BT (Avastar 88W8787)
   module is also being developed, using the existing Linux driver as a

   SDIO card detection and initialization already work; most needed bus
   methods are implemented and tested.

   The WiFi driver is able to load firmware onto the card and initialize
   it. Migration of the MMC stack to the new locking model is necessary in
   order to work with SDIO cards effectively. The FreeBSD CAM
   implementation is believed to be a good choice. There is ongoing work
   to implement an MMC transport for CAM.

Open tasks:

    1. SDIO stack: finish CAM migration. The XPT layer is almost ready.
       What is missing is a SIM module, for which a modified version of
       the SDHCI controller driver will be used, and a peripheral module,
       where porting the mmcsd(4) driver is required.
    2. Marvell SDIO WiFi: connect it to the FreeBSD network stack, write
       the code to implement required functions, such as sending and
       receiving data, network scanning and so on.



   Contact: Ed Maste <emaste <at>>

   The Unified Extensible Firmware Interface (UEFI) provides boot- and
   run-time services for x86 computers, and is a replacement for the
   legacy BIOS. This project will adapt the FreeBSD loader and kernel boot
   process for compatibility with UEFI firmware, found on contemporary
   servers, desktops, and laptops.

   Starting with Rui Paulo's i386 EFI loader, Benno Rice developed a
   working proof-of-concept amd64 loader in 2013 under sponsorship from
   the FreeBSD Foundation. After refinement, that work has now been merged
   from the projects/uefi Subversion branch into FreeBSD head. The project
   includes the infrastructure to build a UEFI-enabled loader, and the
   kernel-side changes to parse metadata provided by the loader.

   A number of integration tasks remain, with a plan to have UEFI
   installation and boot support merged to stable/10 in time for FreeBSD

   This project is sponsored by The FreeBSD Foundation.

Open tasks:

    1. Document manual installation, including dual-boot configurations.
    2. Implement chain-loading from UFS/ZFS file systems.
    3. Integrate UEFI configuration with the FreeBSD installer.
    4. Support secure boot.

Updated vt(4) System Console


   Contact: Aleksandr Rybalko <ray <at>>
   Contact: Ed Maste <emaste <at>>
   Contact: Ed Schouten <ed <at>>

   vt(4) is a modern replacement for the existing, quite old, virtual
   terminal emulator called syscons(4). Initially motivated by the lack of
   Unicode support and infrastructural issues in syscons(4), the project
   was later expanded to cover the new requirement to support Kernel Mode
   Setting (KMS).

   The project is now in head, stable/10 and stable/9 branches. Hence,
   vt(4) can be tested by using the VT kernel configuration (i386 and
   amd64) or by replacing two lines in the GENERIC kernel configuration

device sc
device vga

   with the following ones:

device vt
device vt_vga

   Or, to use for UEFI testing, add the following lines instead:

device vt
device vt_efifb

   Major highlights:

     * Unicode support.
     * Double-width character support for CJK characters.
     * xterm(1)-like terminal emulation.
     * Support for Kernel Mode Setting (KMS) drivers (i915kms, radeonkms).
     * Support for different fonts per terminal window.
     * Simplified drivers.

   Brief status of supported architectures and hardware:

     * amd64 (VGA/i915kms/radeonkms) -- works.
     * ARM framebuffer -- works.
     * i386 (VGA/i915kms/radeonkms) -- works.
     * IA64 -- untested.
     * MIPS -- untested.
     * PPC and PPC64 -- work, but without X.Org yet.
     * SPARC -- works on certain hardware (e.g., Ultra 5).
     * vesa(4) -- in progress.
     * i386/amd64 nVidia driver -- not supported. VGA should be used (VESA
     * Xbox framebuffer driver -- will be deleted as unused.

   This project is sponsored by The FreeBSD Foundation.

Open tasks:

    1. Create sub-directories for vt(4) under /usr/share/ to store key
       maps and fonts.
    2. Implement the remaining features supported by vidcontrol(1).
    3. Write the vt(4) manual page. (This is in progress.)
    4. Support direct handling of keyboard by the kbd device (without
    5. CJK fonts. (This is in progress).
    6. Address performance issues on some architectures.
    7. Switch to vt(4) by default.



   Contact: Peter Grehan <grehan <at>>
   Contact: Neel Natu <neel <at>>
   Contact: John Baldwin <jhb <at>>
   Contact: Tycho Nightingale <tychon <at>>
   Contact: Allan Jude <freebsd <at>>

   bhyve is a Type-1 hypervisor that runs on the FreeBSD platform. It
   currently only runs FreeBSD (9.x or later) and Linux guests; current
   development efforts aim at widening support for other x86 64-bit
   operating systems. After a great deal of work by all involved, bhyve
   was shipped as part of FreeBSD 10.0-RELEASE. Increased interest in
   bhyve and the first usable versions have provided great feedback and
   many bug reports.

   A number of important improvements have been made to bhyve this

     * Optionally ignore accesses to unimplemented MSRs
     * Support soft power-off via the ACPI S5 state for bhyve guests
     * Graceful shutdown via ACPI on SIGTERM
     * Fix an issue with virtio-blk devices on Linux guests with more than
       4GB of RAM
     * Increase the block-layer backend maximum requests to match AHCI
       command queue depth
     * Add SMBIOS support
     * Improve support for nmdm, opening the tty non-blocking
     * Add HPET device emulation
     * Implement the "Virtual Interrupt Delivery" and "Posted Interrupt
       Processing" VT-x features on newer Intel CPUs
     * Add support for booting FreeBSD/i386 guests
     * Add virtualized XSAVE support for features like AVX
     * Add Support for booting from ZFS with bhyveload

Open tasks:

    1. Improve documentation.
    2. Write Handbook chapter for bhyve.
    3. Merge fixes and features back to stable/10.
    4. Support for booting with UEFI instead of userspace loaders.
    5. CSM BIOS boot support for FreeBSD (which has no UEFI support
    6. Add support for virtio-scsi.
    7. Improve virtio-net, add offload features, support multiple queues.
    8. Implement Intel 82580 and e1000 NIC emulation.
    9. Netmap support.
   10. Flexible networking backend: wanproxy, vhost-net.
   11. Improve resource accounting.
   12. Move to a single process model, instead of bhyveload and bhyve.
   13. Support running bhyve as non-root.
   14. Add filters for popular VM file formats (VMDK, VHD, QCOW2).
   15. Implement an abstraction layer for video (no X11 or SDL in base
   16. Support for VNC as a video output.
   17. Implement USB and Sound.
   18. Suspend/resume support.
   19. Live Migration.
   20. Nested VT-x support (bhyve in bhyve).
   21. Support for other architectures (ARM, MIPS, PPC).

FreeBSD Host Support for OpenStack and OpenContrail


   Contact: Grzegorz Bernacki <gjb <at>>
   Contact: Michał Dubiel <md <at>>
   Contact: Dominik Ermel <der <at>>
   Contact: Rafał Jaworowski <raj <at>>

   OpenStack is a cloud operating system that controls large pools of
   compute, storage, and networking resources in a data center.
   OpenContrail is a network virtualization (SDN) solution comprising a
   network controller, virtual router, and analytics engine, which can be
   integrated with cloud orchestration systems like OpenStack or

   The goal of this work is to make FreeBSD a fully supported compute host
   for OpenStack using OpenContrail virtualized networking. The main areas
   of development are:

     * Libvirt hypervisor driver for bhyve.
     * Support for bhyve (via the libvirt compute driver) and the FreeBSD
       platform in overall in nova-compute.
     * Port OpenContrail vRouter (forwarding plane kernel module) to
     * Port OpenContrail Agent (network controller node) to FreeBSD.
     * Integration, performance optimization.

   The current state of development allows for a working demo of OpenStack
   with compute node component running on a FreeBSD host:

     * The native bhyve hypervisor is driven by a nova-compute component
       for spawning guest instances using libvirt and a nova-network
       component for providing simple networking using bridges between
       guest VMs.
     * QEMU might also be used instead of bhyve this way.
     * The main goal on the networking side is to use the OpenContrail
       solution, compliant with the modern OpenStack networking API

   Also, an initial port of the OpenContrail vRouter kernel module has
   been completed. It successfully handles all networking on the host.

   This project is sponsored by Juniper Networks.

FreeBSD on Chromebook


   Contact: Ruslan Bukin <br <at>>

   One model of Chromebook is an ARMv7 Cortex-A15 personal computer
   powered by a Samsung Exynos 5 Dual System-on-Chip. As of the current
   status of this project, such laptops can be booted with FreeBSD from
   USB flash -- it works stably (including SMP) and it can build
   third-party applications. The display and keyboard work.

   Thanks to Peter Grehan for providing hardware.

Open tasks:

    1. Implement keyboard polling mode.
    2. Add support for the upcoming second generation of Chromebook.
    3. Write SD, SATA drivers.



   Contact: Andrew Turner <andrew <at>>

   Arm64 is the name of the in-progress port of FreeBSD to the ARMv8 CPU
   when it is in AArch64 mode. Until recently, all ARM CPU designs were
   32-bit only. With the introduction of the ARMv8 architecture, ARM has
   added a new 64-bit mode. This new mode has been named AArch64.

   Progress has been good on getting FreeBSD to build and run on the ARM
   Foundation model. FreeBSD is able to be built for this architecture,
   however, it requires a number of external tools including objdump(1)
   and ld(1). These tools are provided by an external copy of binutils
   until replacements can be written.

   FreeBSD will run the early boot on the Foundation model. The loader has
   been ported to the AArch64 UEFI environment and can load and run the
   kernel. The kernel is able to create the initial page tables to be able
   to run from virtual memory. It can then execute C code to parse the
   memory map provided by the loader. This is as far as the kernel
   currently boots.

   This work is now happening in the FreeBSD Subversion repository in a
   project branch, see the links.

Open tasks:

    1. Implement an initial pmap(9) layer.
    2. Write the missing machine-dependent code.
    3. Test on real hardware.


   Contact: Andrew Turner <andrew <at>>

   FreeBSD has been updated to allow it to use the VFP variant of the ARM
   EABI ABI. The VFP unit is the ARM hardware to perform floating-point
   operations. This changes the ABI to improve the performance of code
   that uses floating-point operations. By default, FreeBSD already uses
   the ARM EABI on all releases from 10.0.

   This is important for FreeBSD/arm users running code with
   floating-point operations on ARMv6 or ARMv7 SoC systems. It removes the
   need for the slow software floating-point support in libc. This is
   mostly compatible with the existing ABI, with the exception of how
   floating-point values are passed into functions. Because no
   floating-point values are passed to the kernel, the armv6 and armv6hf
   kernels will work with either userland.

   As part of this change, some support functions have been updated to use
   the VFP unit when available. The existing armv6 target architecture
   will be kept for cases where the SoC lacks a VFP unit, or existing
   binaries that are incompatible with the new ABI.

Open tasks:

    1. Testing.
    2. More testing.

SMP on Multi-Core ARM Systems


   Contact: Ian Lepore <ian <at>>
   Contact: Olivier Houchard <cognet <at>>
   Contact: Wojciech Macek <wma <at>>

   FreeBSD now supports Symmetrical MultiProcessing (SMP) on a variety of
   ARM multi-core systems. The effort to bring SMP to ARM has been
   underway for quite some time, but a major push by the FreeBSD ARM
   developer community over the past two months has resulted in robust
   production-ready SMP support.

   An ever-growing number of ARM-based development boards and small
   low-power computer systems are available with multi-core processors.
   FreeBSD is now able to make good use of all that computing power,
   making such systems more attractive to both end users and vendors
   looking to create products based on similar designs.

   As of r264138 in FreeBSD head, SMP is now enabled by default in the
   configuration files for all currently-supported systems that have
   multi-core processors. This includes systems based on the following
   processor families:

     * Allwinner A20
     * Freescale i.MX6
     * Marvell Armada XP
     * Samsung Exynos 5
     * Texas Instruments OMAP4

   We plan to merge this work to stable/10 in time for 10.1-RELEASE.

   This project is sponsored by Microsemi, Inc., and Semihalf sp.j.


   Contact: Pawel Jakub Dawidek <pjd <at>>

   The auditdistd(8) daemon is responsible for distributing audit trail
   files over TCP/IP networks securely and reliably.

   The daemon now supports client-side certificates, which can be used to
   automatically configure the receiver side -- the directory name for
   received trail files is determined based on the commonName field in
   client's certificate. There is no need any more to add every sender to
   the receiver's configuration file.

   The sender's functionality was extended to allow sending audit trail
   files to multiple receivers.

   Complete Public Key Infrastructure (PKI) support is now implemented,
   including full certificate chain verification, Certificate Revocation
   Lists (CRL) verification at every level and support for multiple
   Certificate Authority (CA) certificates.

   This project is sponsored by The FreeBSD Foundation.

External Toolchain Improvements


   Contact: Warner Losh <imp <at>>

   Building on the work that Brooks Davis did to enable external Clang
   toolchains, this project hopes to generalize that to GCC, as well as
   support different versions of these compilers simultaneously for the
   FreeBSD base system and the kernel. We also hope get to the point that
   a port can be cross-compiled entirely from scratch with no initial
   binary artifacts.

Open tasks:

    1. Setup Subversion project repository.
    2. Fix issues with differences of interpretation of the -B argument
       between GCC and Clang.
    3. Support building the entire tree based only on xdev-built
    4. Support building the entire tree based only on ports-built GCC
    5. Support full bootstrapping of FreeBSD to new platforms.

Forward Port FreeBSD GCC

   Contact: Warner Losh <imp <at>>

   Not all of the FreeBSD changes to GCC have been reflected upstream. A
   large amount of the platform support as well as a couple of minor
   improvements like the kernel formatting checker need to be forward
   ported (and if possible, moved upstream into GCC).

   We will be targeting the FreeBSD ports tree lang/gcc* ports for these
   efforts to (optionally) include them in these builds. Some variation
   from normal builds may be required due to bootstrapping issues when
   combined with the external toolchain enhancements project.

FreeBSD Test Suite


   Contact: Julio Merino <jmmv <at>>

   The FreeBSD Test Suite project aims to equip FreeBSD with a
   comprehensive collection of tests that are easy to run out of the box
   and during the development of the system. The test suite is installed
   into /usr/tests/ and the kyua(1) command-line tool (devel/kyua in the
   Ports Collection) is used to run them. See the project page for more

   Since the last status report, we have been hard at work polishing the
   framework in many different areas. The highlights are:

     * A roadmap for the project has been prepared and published, see
     * Many tests have been added to the test suite thanks to the work of
       various developers and, in particular, a good bunch of old tests
       from src/tools/regression/ have been incorporated into the new test
       suite. As of this writing, there are 509 test cases continuously
     * The testing infrastructure in the stable/10 branch has been synced
       to head. It should now be possible to seamlessly MFC changes to the
       stable branch along with their tests, if any.
     * The testing cluster, which only issued amd64 builds, has been
       extended to perform i386 builds as well. Additionally, a canary
       machine has been put in place so that changes to the cluster
       configuration can be properly validated before deployment.
     * A tutorial on Kyua and the FreeBSD Test Suite was given at
       AsiaBSDCon 2014. The tutorial materials are available for public
       consumption, please consult the links.
     * Both Kyua's and ATF's upstream sites have been moved to GitHub,
       mostly due to the discontinuation of file downloads in Google Code.

Open tasks:

    1. Enable the build of the test suite by default.
    2. Add alerting for failed or missing test runs from the testing
    3. Add bhyve support to the testing cluster for faster turnaround
    4. Simplify and improve Kyua HTML reports. In particular, reports will
       be coalesced into single HTML files for easier management and will
       include more useful details for debugging. Such details are the
       revision at which the system was built, the date and duration of
       the whole run, or the list of installed packages, to mention a few
    5. Add JUnit XML output to Kyua for better integration with Jenkins.
       This work is actively ongoing and should be ready for prime time at
       BSDCan 2014.

LLDB Debugger Port


   Contact: Ed Maste <emaste <at>>

   LLDB is the debugger project associated with Clang/LLVM. It supports
   the Mac OS X, Linux, and FreeBSD platforms, with ongoing work on
   Windows. It builds on existing components in the larger LLVM project,
   for example using Clang's expression parser and LLVM's disassembler.

   The majority of work since the last status update has been on bugfixes
   and implementation of the remaining functionality missing on FreeBSD.
   Most of these improvements are now in the LLDB snapshot in the base
   system, which has been updated to upstream Subversion revision r202189.
   Some highlights of the new update include:

     * Improvements to the remote GDB protocol client.
     * Bug fixes for big-endian targets.
     * Initial support for libdispatch (GCD) queues in the debuggee.
     * Add "step-avoid-libraries" setting.
     * IO subsystem improvements (including initial work on a curses GUI).
     * Support hardware watchpoints.
     * Improved unwinding through hand-written assembly functions.
     * Handle DW_TAG_unspecified_parameters for variadic functions.
     * Fix Ctrl+C interrupting a running inferior process.
     * Various bug fixes for memory leaks, LLDB segfaults, the C++
       demangler, ELF core files, DWARF debug info, and others.

   LLDB is currently not yet built by default and may be enabled by adding
   WITH_LLDB= to src.conf(5). A port will be made available for those who
   wish to track ongoing development more closely.

   This project is sponsored by DARP/AFRL, SRI International, and
   University of Cambridge.

Open tasks:

    1. Add support for remote debugging (gdbserver-compatible
    2. Add support for local and core file kernel debugging.
    3. Implement, fix or test support on all non-amd64 architectures.
    4. Verify cross-debugging.
    5. Investigate and fix test suite failures.
    6. Package LLDB as a port.
    7. Enable by default in the base system for working architectures.



   Contact: Chromium on FreeBSD Team <freebsd-chromium <at>>

   Chromium is the open source web browser project from which Google
   Chrome draws its source code. The browsers share the majority of code
   and features, though there are some minor differences in features and
   they have different licensing. Over the last four years, the Chromium
   team has been busy with porting Chromium to FreeBSD. This involves
   patching the browser so that it runs on FreeBSD, tracking and
   documenting security updates, and merging patches back upstream.

   While there are already several browsers available for FreeBSD,
   advantages of Chromium are:

     * Quick response from upstream to security issues, resulting in
       approximately bi-weekly updates.
     * A testbed for security features of FreeBSD, like Capsicum. While
       support for this capability and sandbox framework is currently not
       included in the browser, a proof-of-concept implementation for an
       early version of Chromium was realized within a single weekend.

   George Liaskos and René Ladan are currently busy with submitting the
   remaining patches specific to FreeBSD back upstream. Apart from making
   future updates easier, it sometimes also improves the overall code

   Jonathan Anderson recently updated the Capsicum patches for Chromium
   and is talking to upstream about them.

Open tasks:

    1. Advocate FreeBSD. While patches are getting accepted by both humans
       and bots, it is not an official platform so attitude varies from
       developer to developer. While René Ladan thinks it is a bit early,
       it might be fruitful to investigate what is required to make
       FreeBSD (and possibly OpenBSD) an official platform in terms of
       both hardware and procedures.
    2. If you feel comfortable with large source trees, you can try to
       build the Git version of Chromium on FreeBSD. If you are also
       comfortable with signing Google's Contributor License Agreement,
       you can join in testing and submitting patches upstream.

FreeBSD Ada Ports


   Contact: John Marino <marino <at>>

   Ada is a structured, statically typed, imperative, wide-spectrum, and
   object-oriented high-level computer programming language, extended from
   Pascal and other languages, originally targeted at embedded and
   real-time systems. The number of Ada ports in the collection has grown
   significantly since the last report six months ago. There are almost 50
   Ada-related ports now, with new ones getting added all the time.

   The previous plan was to move from the GCC 4.7-based GNAT compiler to a
   GCC 4.8-based one, but finally GCC 4.8 was skipped and now a GCC
   4.9-based GNAT is the standard Ada compiler, which fully supports the
   new ISO standard, Ada 2012. Moving to a newer compiler allowed several
   important ports like PolyOrb and GPRBuild to be upgraded to the latest
   available versions. In fact, almost every Ada port is currently at its
   most recent upstream version.

   For non-Windows-based Ada development, FreeBSD and DragonFly are now
   undisputed as the go-to platforms. The other candidates are Debian and
   Fedora, but there are few Ada softwares on those platforms that are not
   also in the FreeBSD ports tree, and the FreeBSD versions are much
   newer. The Ports Collection also features software not found anywhere
   else such as the USAFA's Ironsides DNS server, libsparkcrypto,
   matreshka, GNATDroid (Android cross-compiler) and several developer

   A desired addition to the Ada ports will be SPARK 2014 (see links),
   which should cement FreeBSD as an option for professional,
   safety-critical application development. This package should have its
   first release by early summer.

GCC in the Ports Collection


   Contact: Gerald Pfeifer <gerald <at>>

   While the age old version of the GNU Compiler Collection (GCC) in the
   base system is on its way out with FreeBSD 10 and later, there are many
   users who want--and some platforms which need--to use GCC.

   For that purpose there are various versions of GCC in the ports tree,
   including lang/gcc46, lang/gcc47, lang/gcc48 and lang/gcc49 which track
   upstream snapshots of the respective release branches, and more
   importantly lang/gcc which serves as the canonical version of GCC and
   is the default when a port requests USE_GCC=yes as well as for some
   cases of USES=compiler.

   With a lot of help from Christoph Moench-Tegeder who fixed many ports
   and made a fair number respect CXXFLAGS, LDFLAGS and friends, we
   managed to update the canonical version from GCC 4.6.4 to GCC 4.7.3.
   Many of Christoph's fixes also benefit Clang and other modern

   For users of lang/gcc, this upgrade proved very smooth, and we
   generally recommend using this port over version specific ones.

   After ten years of service lang/gcc34 retired, as did lang/gcc44 after
   half that timespan.

   On a related note, with the help of John Marino, the license of the GCC
   ports now properly reflects the combination of GPLv3 for the compiler
   itself and GPLv3 with GCC Runtime Library Exception for the runtime.
   The latter is the key in making it possible to use GCC for building and
   distributing non-free software.

Open tasks:

    1. Move lang/gcc from GCC 4.7 to GCC 4.8.



   Contact: FreeBSD GNOME Team <gnome <at>>

   GNOME is a desktop environment and graphical user interface that runs
   on top of a computer operating system. GNOME is part of the GNU Project
   and can be used with various Unix-like operating systems, including

   Preparations for merging GNOME 3 are moving forward. The work on the
   documentation is falling behind a bit, but we got some solid feedback
   on the rough work to keep this moving forward as well. In the meantime,
   deprecation of ports that need the old GNOME 2 desktop ports has begun.
   These ports will break when the GNOME desktop components are updated to
   the GNOME 3 version.

   Thanks to a combined effort by Ryan Lortie (GNOME developer), Ting-Wei
   Lan (upstream contributor), and Koop Mast, we now have a
   FreeBSD-powered JHbuild tinderbox. JHbuild is a build system that
   allows building GNOME upstream code. Twice a day, it will attempt to
   build Gnome components from a specific branch, usually the git master
   branch, to catch compile issues. A positive side effect is that it lets
   upstream know GNOME still lives on non-Linux systems. It also exposes
   the GNOME code base to the Clang compiler and libc++. Since the start
   of this project over a hundred issues have been fixed.

   Gustau Perez has stepped up and put together a port set in the
   "ports-experimental" tree of our development repository with GNOME
   3.12. It was decided to polish GNOME 3.12. It will be merged when the
   preparation work has (mostly) finished, and we are happy with the
   stability of GNOME 3.12.

   Gustau Perez also ported Cinnamon 2.0 to FreeBSD. It will appear in the
   Ports Collection after GNOME 3 has been merged.

   MATE 1.8 was released at the beginning of April, Eric Turgeon of
   GhostBSD had volunteered to do that update for FreeBSD. Note that this
   update is still based on GTK+, version 2. The GTK+ 3-based MATE is on
   the roadmap for 1.10.

Open tasks:

    1. Finish the work needed to be done before GNOME 3 can be merged at
       all. Documentation work, port deprecation, and so on.
    2. Finish porting of MATE 1.8.
    3. Update Cairo to 1.12 in coordination with the Graphics Team.


   URL: <at>

   Contact: KDE/FreeBSD Team <kde <at>>

   KDE is an international free software community producing an integrated
   set of cross-platform applications designed to run on Linux, FreeBSD,
   Solaris, Microsoft Windows, and OS X systems. The KDE/FreeBSD Team have
   continued to improve the experience of KDE software and Qt under

   During this quarter, the team has kept most of the KDE and Qt ports
   up-to-date, working on the following releases:

     * KDE SC: 4.12.2, 4.12.3, and 4.12.4; Workspace: 4.11.6, 4.11.7, and
     * Qt: 5.2.1
     * KDevelop: 4.6.0
     * Digikam (and KIPI-plugins): 3.5.0

   As a result -- according to PortScout -- kde <at>  has 526 ports (up from
   464), of which 98.86% are up-to-date (up from 88.15%). iXsystems
   continues to provide a machine for the team to build packages and to
   test updates. They have been providing the KDE/FreeBSD team with
   support for quite a long time and we are very grateful for that.

   A major change has been the deprecation of the KDE3 ports and the move
   of the KDE4_PREFIX to LOCALBASE. Also, work on Qt5 continues to
   maturity. Raphael Kubo da Costa has been working with upstream to
   ensure Baloo (Nepomuk successor in KDE SC 4.13) compiles and runs on
   non-Linux systems. His work not only benefits FreeBSD but other BSDs
   and OS X.

   As usual, the team is always looking for more testers and porters, so
   please contact us and visit our home page (see links). It would be
   especially useful to have more helping hands on tasks such as getting
   rid of the dependency on the defunct HAL project and providing
   integration with KDE's Bluedevil Bluetooth interface.

   This project is sponsored by iXsystems, Inc.

Open tasks:

    1. Update out-of-date ports, see PortScout for a list.
    2. Work on Qt 5.
    3. Make sure the whole KDE stack (including Qt) builds and works
       correctly with Clang and libc++.
    4. Remove the dependency on HAL.

libvirt/bhyve Support


   Contact: Roman Bogorodskiy <novel <at>>

   Libvirt is a virtualization library providing a common API for various
   hypervisors (Qemu/KVM, Xen, LXC, and others), and also a popular
   library used by a number of projects. Libvirt 1.2.2, released on March,
   2014, was the first release to include bhyve support. Enabling bhyve
   support allows consumers to use bhyve in libvirt-ready applications
   without major efforts.

   Currently, libvirt supports almost all essential features of bhyve,
   such as Virtual Machine lifecycle (start, stop), bridged networking,
   and virtio/SATA driver support. The work continues to implement more
   API calls and to cover more of features offered by bhyve.

Open tasks:

    1. FreeBSD port of netcf is needed for adding interface driver support
       to libvirt.

OpenAFS on FreeBSD


   Contact: Benjamin Kaduk <bjk <at>>

   AFS is a distributed network filesystem that originated from the Andrew
   Project at Carnegie-Mellon University. OpenAFS is an open-source
   implementation of the AFS protocol derived from IBM AFS, which was
   released under the IBM Public License. OpenAFS on FreeBSD (the
   net/openafs port) is suitable for light use, but is not yet production

   We got a chance to pick up this porting project after some hiatus.
   Recent work focused on investigating the bugs preventing the use of a
   disk cache for caching file data. An internal "lookupname" abstraction
   was intended to return an unlocked, referenced vnode, but instead
   returned a locked, referenced vnode, leading to various failure modes
   depending on the number of kernel debugging options enabled.

Open tasks:

    1. Track down an issue involving incorrect reference counts on the AFS
       root vnode that cause warnings on shutdown.
    2. Audit the locking in all the vnode operations code -- it is
       expected that there remain some incorrectly locked areas, though
       none that present visible issues under light load.

The Graphics Stack on FreeBSD


   Contact: FreeBSD Graphics Team <graphics-team <at>>

   On the kernel side, the Radeon KMS driver was merged in stable/9 and
   will be available in FreeBSD 9.3-RELEASE. Now both the 9.x and 10.x
   branches share the same support for Intel and AMD GPUs.

   The next big tasks are the updates of the DRM generic code and the i915
   driver. Both are making good progress and the DRM update should
   hopefully be ready for wider testing during April. An update of the
   Radeon driver is on the to-do list, but nothing is scheduled yet.

   On the ports tree and packages side, the update to Cairo 1.12 mentioned
   in the last quarterly report is ready to be committed, as people who
   tested it either reported improvements or no regressions. As a
   reminder, the switch from Cairo 1.10 to 1.12 causes display artifacts
   with xf86-video-intel 2.7.1, but fixes similar problems with other
   hardware/driver combinations. Furthermore, Cairo 1.12 is required by
   Pango 1.36.0, GTK+ 3.10 and Firefox 27.0. A "Heads up" mail will be
   posted to the freebsd-x11 mailing-list when this update goes live.

   In the graphics stack's ports development tree, new Mesa ports are
   being worked on. Those ports are required to support GLAMOR (the
   GL-based 2D acceleration library used by Radeon HD 7000+ cards for
   instance) and OpenCL (using the GPU to perform non-graphical
   calculations). We were able to execute some "Hello World" OpenCL
   programs and play with OpenCL in darktable, but there are some
   compatibility issues between Clover (Mesa's libOpenCL implementation)
   and Clang/libc++.

   We are preparing an alternate pkg(8) repository with packages built
   with WITH_NEW_XORG. The goal is to ease the usage of the KMS drivers
   and move forward with the graphics stack updates. The main pkg(8)
   repository will still use the default setting (WITH_NEW_XORG set on
   head, but not on the stable branches).

   This will pave the way to the deprecation ofWITH_NEW_XORG and the
   removal of the older stack. The current plan is to do this after
   10.0-RELEASE End-of-Life, scheduled on January 31st, 2015. By that
   time, the only supported releases will be 8.4-RELEASE, 9.3-RELEASE and
   10.1-RELEASE. FreeBSD 9.3 and 10.1 will be fully equipped to work with
   the newer stack. Unfortunately, FreeBSD 8.x misses the required kernel
   DRM infrastructure: supporting X.Org here cripples progress on the
   graphics stack and, once WITH_NEW_XORG is gone, we will not support 8.x
   as a desktop any more. Therefore, please upgrade to 9.3 or 10.1 when
   they are available.

Open tasks:

    1. See the "Graphics" and "WITH_NEW_XORG" wiki pages for up-to-date

Using CentOS 6.5 as Linux Base


   Contact: Johannes Meixner <xmj <at>>

   The Linux emulation layer relies on a Linux base distribution along
   with Linux ports of relevant non-base software. Fedora 10 was imported
   in 2006, and it shows -- current Linux software like Skype 4, Sublime
   Text 2, or even modern games fail to run with the provided libraries.

   CentOS 6.5 was released in December 2013 and will be supported until
   2017, making it an ideal basis for an update to the ports
   infrastructure. Built upon the work of Carlos Jacobo Puga Medina, all
   ports using Linux have been updated to work with either Fedora 10 or
   CentOS 6.5.

   The goal of this project is to make CentOS 6.5 the default Linux
   distribution, so that FreeBSD users can enjoy running modern Linux
   binaries without having to resort to virtualization à la VirtualBox, or
   even dual-booting.

   This project is sponsored by Goldener Grund OÜ.

Open tasks:

    1. Clean up Mk/bsd.linux-*.mk and fix errors detected in ports/187786.
    2. Revert making c6 the default (in the git repository).
    3. Testing.
    4. Review patches and import into the ports tree (any help
    5. Make c6 the default (after sufficient testing) within the ports



   Contact: Gerald Pfeifer <gerald <at>>
   Contact: David Naylor <dbn <at>>

   Wine is a free and open source software application that aims to allow
   applications designed for Microsoft Windows to run on Unix-like
   operating systems, such as FreeBSD. The Wine project has been in
   maintenance mode this quarter and has updated the ports for the
   following versions:

     * Stable releases: 1.6.2
     * Development releases: 1.7.9 through 1.7.15

   The ports have packages built for amd64, available through the ports
   emulators/i386-wine and emulators/i386-wine-devel.

Open tasks:

    1. See the "Open Tasks" and "Known Problems" sections on the Wine wiki
    2. FreeBSD/amd64 integration, consult the i386-Wine wiki page for the
    3. Port WoW64 (supporting Windows 32-bit and 64-bit from the same
       port) and Wine64.



   Contact: FreeBSD Xfce Team <xfce <at>>

   Xfce is a free software desktop environment for Unix and Unix-like
   platforms, such as FreeBSD. It aims to be fast and lightweight, while
   still being visually appealing and easy to use. The Xfce team continues
   to keep each piece of the Xfce Desktop up to date.

   The latest commits concerned:

     * Applications:

       - Midori (0.5.7)
       - xfburn (0.5.0)
       - xfce4-parole (0.5.4)
       - xfce4-taskmanager (1.0.1)
       - xfce4-tumbler (0.1.30)

     * Panel plugins:

       - xfce4-clipman-plugin (1.2.5)
       - xfce4-equake-plugin (1.3.4)
       - xfce4-wavelan-plugin (0.5.11)
       - xfce4-whiskermenu-plugin (1.3.2)

   We also follow development of core components (available in your
   repository). See the links for documentation on how to upgrade those

     * garcon (0.3.0)
     * libxfce4menu (4.11.1)
     * libxfce4util (4.11.0)
     * xfce4-appfinder (4.11.0)
     * xfce4-desktop (4.11.4)
     * xfce4-dev-tools (4.11.0)
     * xfce4-panel (4.11.0)
     * xfce4-parole (0.6.0)
     * xfce4-settings (4.11.2)
     * xfce4-session (4.11.0)
     * xfce4-wm (4.11.1)
     * xfce4-xkb-plugin (0.7.0)

Open tasks:

    1. Add support of DragonFly for xfce4-taskmanger.
    2. Finish replacing Tango icon theme with GNOME, in order to close
       ports/183690 (see links, Midori remains to be fixed).

ZFS Chapter of the Handbook


   Contact: Allan Jude <freebsd <at>>
   Contact: Benedict Reuschling <bcr <at>>
   Contact: Warren Block <wblock <at>>

   ZFS is one of the premier features of FreeBSD. The current
   documentation in the Handbook and elsewhere online is severely lacking.
   Much of the original documentation from Sun and Oracle has disappeared,
   moved, or is about the proprietary version of ZFS.

   New users have many questions about ZFS and yet there exists a great
   deal more bad advice about ZFS than proper documentation. The current
   ZFS chapter of the FreeBSD Handbook starts off with the required steps
   to configure an i386 machine to run ZFS. This is more likely to scare
   off a new user than to educate them about how to properly use ZFS.

   At BSDCan 2013, the process of writing an entirely new chapter of the
   Handbook on ZFS was started. Currently this chapter consists of
   approximately 16,000 words covering all subcommands of the zpool(8) and
   zfs(8) utilities, delegation, tuning and a section devoted to
   definitions and explanations of the terms and features of ZFS.

   The remaining section is the FAQ, to help users address the most common
   problems they might run into with ZFS. It would be useful to hear
   experiences, questions, misconceptions, gotchas, stumbling blocks, and
   suggestions for the FAQ section from other users. Also, it would be
   good to have a use cases section that highlights some of the cases
   where ZFS provides advantages over traditional file systems.

   Please send suggestions to the freebsd-doc mailing list.

   This project is sponsored by ScaleEngine, Inc.

Open tasks:

    1. Technical review by Matt Ahrens (co-creator of ZFS).
    2. Improve delegation section.
    3. Improve tuning section, add new sysctls added in head.
    4. Add section on jails and the jailed property.
    5. Add FAQ section.
    6. Add "Use Cases" section.
    7. General editing and review.

FreeBSD Participating in Summer of Code 2014


   Contact: Gavin Atkinson <gavin <at>>
   Contact: Glen Barber <gjb <at>>
   Contact: Wojciech Koszek <wkoszek <at>>

   FreeBSD is pleased to have been accepted as a participating
   organization in Google's Summer of Code 2014. This will be the tenth
   time we have participated in the program, having been selected to
   participate every year since its introduction.

   This year, the administrators made a special attempt to spread the word
   about Summer of Code around universities, including making contact with
   around 350 mainly Polish, British, African and American universities to
   advertise the Summer of Code program, with a particular focus on
   FreeBSD's participation. We made contact with both technical
   departments and student societies. Posters were produced in several
   languages, and FreeBSD committers and users were encouraged to
   distribute these posters around their local universities.

   FreeBSD received a total of 39 proposals from students, and were
   subsequently granted 15 slots from Google. We are now facing the
   unpleasant challenge of trying to decide which of the 39 proposals to
   select, taking into account the quality, desirability and feasibility
   of each proposal, as well as ensuring we will be able to provide an
   excellent mentoring experience to each selected student. All mentors
   have volunteered to mentor, and we pair students with mentors primarily
   based on the prospective mentor's areas of expertise, interest in the
   project, also taking into account the desire to pair students up with
   mentors in similar time zones in order to improve the student
   experience. The final list of accepted students is expected to be
   announced on the 21st April.

The FreeBSD Foundation


   Contact: Deb Goodkin <deb <at>>

   The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated
   to supporting and promoting the FreeBSD Project and community
   worldwide. Most of the funding is used to support FreeBSD development
   projects, conferences and developer summits, purchase equipment to grow
   and improve the FreeBSD infrastructure, and provide legal support for
   the Project.

   We published the first issue of the FreeBSD Journal, our new on-line
   FreeBSD magazine. The positive feedback from both the FreeBSD and
   outside communities has been incredible. This quarter we began work on
   articles and promotion for the second issue. We also started working on
   a dynamic version of the magazine that can be read in many web browsers
   including those that run on FreeBSD.

   This year we are earmarking more funding towards FreeBSD advocacy and
   education. You will see more literature, white papers, articles, and so
   on to help promote FreeBSD.

   The Foundation held a board meeting in Berkeley, California, in
   January. We discussed longer term strategy and planning for the year.
   We put together our 2014 budget with a plan of raising at least
   $1,000,000 and spending $900,000.

   Two Foundation funded projects were completed. The first, co-sponsored
   by Google, integrated the Casper daemon into FreeBSD. The second was
   auditdistd(8) improvements for the FreeBSD cluster.

   Work continued on these Foundation-sponsored projects: Intel graphics
   driver update by Konstantin Belousov, UEFI boot support for amd64 by Ed
   Maste, autofs automounter and in-kernel iSCSI stack enhancements and
   bug fixes by Edward Tomasz Napierala, and updated vt(4) system console
   by Aleksandr Rybalko. A more detailed project update for each of the
   above projects can be found within this quarterly status report.

   We were a Gold Sponsor for NYCBSDCon 2014 in New York, February 8,
   which was attended by several board members. We were represented at
   SCALE in Los Angeles, February 22-23, and ICANN in Singapore, March

   We were a sponsor for AsiaBSDCon in Tokyo, March 15-16. Board member
   Hiroki Sato was the conference organizer. Board members Kirk McKusick
   and George V. Neville-Neil taught tutorials and Kirk gave a keynote.
   Board member Dru Lavigne manned the foundation table and spoke at one
   of the sessions.

   We became a Gold+ sponsor for BSDCan 2014, May 16-17 and have started
   reaching out to vendors to attend the developer summit that runs in the
   two days before BSDCan.

   Board members George, Kirk, and Robert Watson pushed to finish the
   final draft of the next edition of their book "The Design and
   Implementation of the FreeBSD Operating System".

   ITWire editor Sam Varghese published an interview with Kirk and
   Foundation technical manager Ed Maste about the status of secure boot
   on FreeBSD.

   The FreeBSD Logo is now officially a registered trademark to represent
   the FreeBSD operating system. We are working to expand the registration
   beyond just the FreeBSD operating system, but currently still have to
   use the "TM" symbol when using it on apparel and other
   non-operating-system items. We continued reviewing requests and
   granting permission to use FreeBSD trademarks.

   After finishing the 10.0-RELEASE, Foundation system administrator and
   release engineer Glen Barber began work on adding support for
   FreeBSD/arm image builds as part of the release build process. As a
   result of this work, FreeBSD/arm images are produced as part of the
   weekly development snapshot builds, and are available from any of the
   FreeBSD FTP mirrors. Supported kernel configurations currently include

   George visited six large FreeBSD users in the Bay Area in February.
   These meetings are conducted to help facilitate collaboration between
   FreeBSD customers and the FreeBSD Project. It is an opportunity to
   exchange information on what the customers are doing and what is being
   worked on in the Project. It is also an opportunity to try to connect
   customers with the appropriate FreeBSD developers who may be working on
   areas of FreeBSD that interest these customers.

Love FreeBSD?  Support the development with a donation to the FreeBSD
freebsd-current <at> mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at>"
Andrey Fesenko | 17 Apr 12:10 2014

SATA2 mode on SATA3 SSD (marvell controller) after boot


ada2: <PLEXTOR PX-128M5S 1.05> ATA-8 SATA 3.x device
ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)

need tuning? or change SSD?

motherboard gigabyte z87mx-d3h all ports SATA-3, port change does not
change the situation

hdd SATA-3 recognized correctly
ada3: <WDC WD30EZRX-00D8PB0 80.00A80> ATA-9 SATA 3.x device
ada3: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)

another ssd
ada2: <Corsair Neutron SSD M206> ATA-8 SATA 3.x device
ada2: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)

if disconnect ssd
pr 17 14:07:08 desktop kernel: ahcich3: DISCONNECT requested
Apr 17 14:07:08 desktop kernel: ahcich3: AHCI reset...
Apr 17 14:07:08 desktop kernel: ahcich3: SATA connect timeout
time=10000us status=00000000
Apr 17 14:07:08 desktop kernel: ahcich3: AHCI reset: device not found
Apr 17 14:07:08 desktop kernel: pass3 at ahcich3 bus 0 scbus3 target 0 lun 0
Apr 17 14:07:08 desktop kernel: pass3: <PLEXTOR PX-128M5S 1.05> s/n
P02411112921 detached
Apr 17 14:07:08 desktop kernel: ada3 at ahcich3 bus 0 scbus3 target 0 lun 0
Apr 17 14:07:08 desktop kernel: ada3: <PLEXTOR PX-128M5S 1.05> s/n
P02411112921 detached
Apr 17 14:07:08 desktop kernel: (pass3:ahcich3:0:0:0): Periph destroyed
Apr 17 14:07:08 desktop kernel: (ada3:ahcich3:0:0:0): Periph destroyed
Apr 17 14:07:18 desktop kernel: ahcich3: CONNECT requested
Apr 17 14:07:18 desktop kernel: ahcich3: AHCI reset...
Apr 17 14:07:18 desktop kernel: ahcich3: SATA connect time=8000us
Apr 17 14:07:18 desktop kernel: ahcich3: AHCI reset: device found
Apr 17 14:07:18 desktop kernel: ahcich3: AHCI reset: device ready after 0ms
Apr 17 14:07:18 desktop kernel: ada3 at ahcich3 bus 0 scbus3 target 0 lun 0
Apr 17 14:07:18 desktop kernel: GEOM: new disk ada3
Apr 17 14:07:18 desktop kernel: ada3: <PLEXTOR PX-128M5S 1.05> ATA-8
SATA 3.x device
Apr 17 14:07:18 desktop kernel: ada3: Serial Number P02411112921
Apr 17 14:07:18 desktop kernel: ada3: 600.000MB/s transfers (SATA 3.x,
UDMA6, PIO 8192bytes)
Apr 17 14:07:18 desktop kernel: ada3: Command Queueing enabled
Apr 17 14:07:18 desktop kernel: ada3: 122104MB (250069680 512 byte
sectors: 16H 63S/T 16383C)
Apr 17 14:07:18 desktop kernel: ada3: Previously was known as ad10
Apr 17 14:07:18 desktop kernel: pass3 at ahcich3 bus 0 scbus3 target 0 lun 0
Apr 17 14:07:18 desktop kernel: pass3: <PLEXTOR PX-128M5S 1.05> ATA-8
SATA 3.x device
Apr 17 14:07:18 desktop kernel: pass3: Serial Number P02411112921
Apr 17 14:07:18 desktop kernel: pass3: 600.000MB/s transfers (SATA
3.x, UDMA6, PIO 8192bytes)
Apr 17 14:07:18 desktop kernel: pass3: Command Queueing enabled

# uname -a
FreeBSD desktop.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r263932:
Sun Mar 30 15:43:01 MSK 2014
root <at> desktop.local:/usr/obj/usr/src/sys/MY_DES  amd64
freebsd-current <at> mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at>"