Mar 2003 - Sep 2003 FreeBSD Status Report

Scott Long scottl at
Fri Oct 10 05:42:29 PDT 2003

   Navigation Bar

March-September 2003 Status Report


   The FreeBSD Bi-monthly status reports are back! In this edition, we
   catch up on seven highly productive months and look forward to the end
   of 2003.

   As always, the FreeBSD development crew has been hard at work. Support
   for the AMD64 platform quickly sprang up and is nearly complete. KSE
   has improved greatly since the 5.1 release and will soon become the
   default threading package in FreeBSD. Many other projects are in the
   works to improve performance, enhance the user experience, and expand
   FreeBSD into new areas. Take a look below at the impressive summary of

   Scott Long, Robert Watson
     * Bluetooth stack for FreeBSD (Netgraph implementation) 
     * ACPI Status Report
     * AMD64 Porting
     * ATAPI/CAM Status Report
     * Binary security updates for FreeBSD
     * version 2.0
     * Compile FreeBSD with Intels C compiler (icc)
     * Cryptographic Support
     * Device_t locking
     * Disk I/O
     * Dynamically Linked Root Support
     * FreeBSD Java Project
     * FreeBSD ports monitoring system
     * FreeBSD/ia64
     * jpman project
     * KDE FreeBSD Project
     * kgi4BSD Status Report
     * KSE
     * Network Subsystem Locking and Performance
     * Porting OpenBSD's pf
     * PowerPC Port
     * Release Engineering Status
     * Rescue build infrastructure
     * uart(4)
     * VideoBSD
     * WifiBSD Status Report
     * Wireless Networking Support

Bluetooth stack for FreeBSD (Netgraph implementation)


   Contact: Maksim Yevmenkin <m_evmenkin at>

   I'm very pleased to announce that another release is available for
   download at I have
   also prepared patch for the FreeBSD source tree. The patch was
   submitted for review to the committers.

   Fixed few bugs in kernel modules. The ng_hci(4) and ng_l2cap(4)
   modules were changed to fix issue with Netgraph timeouts. The
   ng_ubt(4) module was changed to fix compilation issue on -current.

   Improved user-space utilities. Implemented new libsdp(3). Added new
   sdpcontrol(8) utility. The rfcomm_sppd(1), rfcomm_pppd(8) and
   obexapp(1) were changed and now can obtain RFCOMM channel via SDP from
   the server. The hccontorol(8) utility now has four new commands. The
   hcsecd(8) daemon now saves link keys on the disk.

   I've been recently contacted by few individuals who whould like to
   port current FreeBSD Bluetooth code to other BSD systems (OpenBSD and
   NetBSD). The work is slowly progressing towards un-Netgraph'ing
   current code. In the mean time Netgraph version will be the primary
   supported version of the code.

ACPI Status Report


   Contact: Nate Lawson <njl at>

   Work is continuing on updating ACPI with new features as well as
   bugfixing. A new embedded controller driver was written in July with
   support for the ACPI 2.0 ECDT as well as more robust polling support.
   Also, a buffer overflow in the ACPICA resource list handling that
   caused panics for some users was fixed. Marcel helped get acpidump(8)
   tested and basically working on ia64.

   Upcoming work includes integrating ACPI notifies with devd(8),
   committing user-submitted drivers for ASUS and Toshiba hotkeys, Cx
   processor sleep states (so my laptop doesn't burn my lap), and power
   resource support for intelligently powering down unused or idle

   Users who have problems with ACPI are encouraged to submit a PR and
   email its number to acpi-jp at Bug reports of panics or
   crashes have first priority and non-working features or missing
   devices (except suspend/resume problems) second. Reports of failed
   suspend/resume should NOT be submitted as PRs at this time due to most
   of them being a result of incomplete device support that is being
   addressed. However, feel free to mail them to the list as any
   information is helpful.

AMD64 Porting

   Contact: Peter Wemm <peter at>

   The last known bug that prevented AMD64 machines completing a full
   release has been fixed - one single character error that caused
   ghostscript to crash during rendering diagrams. SMP work is nearing
   completion and should be committed within the next few days. The SMP
   code uses the ACPI MADT table based on John Baldwin's work-in-progress
   there for i386. We need to spend some time on low level optimization
   because there are several suboptimal places that have been ignored for
   simplicity, context switching in particular. MTRR support has been
   committed and XFree86 can use it. cvsup now works but the ezm3 port
   has not been updated yet. The default data segment size limit is 8GB
   instead of 512M, and the (primitive) i386 binary emulation support
   knows how to lower the rlimits for executing 32 bit binaries.

   Notable things missing still: Hardware debug register support needs to
   be written; gdb is still being done as an external set of patches
   relative to the not-yet-released FSF gdb tree; DDB does not
   disassemble properly; DDB cannot do stack traces without
   -fno-omit-frame-pointer - a stack unwinder is needed; i386 and amd64
   linux binary emulation is needed, and the i386 FreeBSD binary
   emulation still needs work - removing the stackgap code in particular.

   The platform in general is very reliable although a couple of problems
   have been reported over the last week. One appears to be a stuck
   interrupt, but all that code has been redone for SMP support.

ATAPI/CAM Status Report

   Contact: Thomas Quinot <thomas at>

   With the introduction of ATAng, some users of ATAPI/CAM have
   experienced various problems. These have been mostly tracked down to
   issues in the new ATA code, as well as two long-standing problems in
   portions of the CAM layer that are rarely exercised with "real" SCSI
   SIMs. This has also been an occasion to cleanup ATAPI/CAM to make it
   more robust, and to enable DMA for devices accessed through it,
   resulting in improved performances.

Binary security updates for FreeBSD


   Contact: Colin Percival <cperciva at>

   FreeBSD Update is a system for tracking the FreeBSD release (security)
   branches. In addition to being faster and more convenient than source
   updates, FreeBSD Update also requires less bandwidth and is more
   secure than source updates via CVSup. However, FreeBSD Update is
   limited; it can only update files which were installed from an
   official RELEASE image and not recompiled locally. Right now I'm
   publishing binary updates for 4.7-RELEASE and 4.8-RELEASE; since my
   only available box takes 3.5 hours to buildworld, I don't have enough
   resources to do any more than that.

   In the near future, I'd like to: Find someone who is willing to donate
   a faster buildbox; start building updates for other releases (at a
   minimum, for all "supported" FreeBSD releases); add warnings if a file
   would have been updated but can't be updated because it was recompiled
   locally; add code to compare the local system against a list of
   "valid" MD5 hashes for intrusion detection purposes; and add support
   for cross-signing, whereby several machines could build updates
   independently to protect against buildbox compromise.
     _________________________________________________________________ version 2.0


   Contact: Ernst De Haan <znerd at>
   Contact: Herve Quiroz <herve.quiroz at>

   The FreeBSD Java community has started an effort to improve the
   current framework for Java-based ports. The main objective is the
   automation of JDK/JRE build and run dependency checking.

   The original version was aimed to ease the life of porters. Although
   it has proved to be useful and reliable to a great extend, we are
   currently working on a new version. We intend to reach a high degree
   of flexibility to cope with the recent increase of available JDK/JRE
   flavors. Furthermore, the new version will be easier to maintain,
   which means improved reliability, and hopefully more frequent updates.

Compile FreeBSD with Intels C compiler (icc)


   Contact: Alexander Leidinger <netchild at>

   Since I ported icc to FreeBSD I wanted to build FreeBSD with icc. Now
   with icc 7.1 (and some patches) it is possible. There are still some
   bugs, e.g. NFS doesn't work with an icc compiled kernel, IP seems to
   be fragile, and some advanced optimizations trigger an ICE (Intel is
   working on it). At the moment I'm waiting for our admins to install
   icc on the FreeBSD cluster (we got a commercial license from Intel, so
   we are allowed to distribute binaries which are compiled with icc),
   after that I will try to convince some people with more knowledge of
   the IP and NFS parts of the kernel to debug the remaining problems.
   When the icc compiled kernel seems to work mostly bugfree the userland
   will get the porting focus. Interested people may try to do a build of
   the ports tree with icc independently from the status of the porting
   of the userland... if this happens at the FreeBSD cluster, we would
   also be allowed to distribute the binaries.

   Benefits include: another set of compiler errors (debugging help),
   more portable source, and code which is better optimized for a P4 (gcc
   has some drawbacks in this area)

Cryptographic Support

   Contact: Sam Leffler <sam at>

   Support for several new crypto devices was added. The SafeNet 1141 is
   a medium performance part that is not yet available on retail
   products. The Hifn 7955 and 7956 parts are starting to appear on
   retail products that should be available by the end of the year. Both
   devices support AES encryption. Support for public key operations for
   the SafeNet devices was recently done for OpenBSD and will be
   backported. Public key support for the Hifn parts is planned.

   A paper about the performance work done on the cryptographic subsystem
   was presented at the Usenix BSDCon 2003 conference and received the
   best paper award.

   NetBSD recently imported the cryptographic subsystem.

Device_t locking

   Contact: Warner Losh <imp at>

   A number of races have been identified in locking device_t. Most of
   the races have been identified in making device_t have to do with how
   drivers are written. Efforts are underway to identify all the races,
   and to contact the authors of subsystems that can help the drivers. Of
   special concern is the need for the driver to ensure that all threads
   are completely out of the driver code before detach() finishes. Of
   additional concern is making sure that all sleepers are woken up
   before certain routines are called so that other subsystems can ensure
   the last condition and leave no dangling references. Locking device_t
   is relatively straight forward apart from these issues. Towards the
   end of proper locking, sample strawmen drivers are being used to work
   out what, exactly proper is. Once these issues are all known and
   documented in the code, efforts will be made to update relevant
   documentation in the tree. There are many problems with driver locking
   that has been done to date, but until we nail down how to write a
   driver in current, it will be premature to contact specific driver
   writers with specific concerns.

Disk I/O

   Contact: Poul-Henning Kamp <phk at>

   The following items are in progress in the Disk I/O area: Turn
   scsi_cd.c into a GEOM driver. (Patch out for review). Turn atapi-cd.c
   into a GEOM driver. Turn fd.c into a GEOM driver. Move softupdates and
   snapshot processing from SPECFS to UFS/FFS. Move userland access to
   device drivers out of vnodes.

   Once these preliminaries are dealt with, scatter/gather and
   mapped/unmapped support will be added to struct bio/GEOM.

Dynamically Linked Root Support

   Contact: Gordon Tetlow <gordon at>

   Support for a dynamically linked /bin and /sbin has been committed,
   although it is not turned on by default. Adventurous users can try it
   out by building /bin and /sbin using the WITH_DYNAMICROOT make flag.
   More testing is needed to determine if this is going to be default for
   5.2-RELEASE. If anyone would like to benchmark worldstones with and
   without dynamically linked /bin and /sbin, please feel free to do so
   and submit the results.

FreeBSD Java Project


   Contact: Greg Lewis <glewis at>

   The BSD Java Porting Team has recently reached an exciting milestone
   with the release of the first "Diablo" JDK and JRE courtesy of the
   FreeBSD Foundation. The release of Diablo Caffe and Diablo Latte 1.3.1
   was the first binary release of a native FreeBSD JDK since 1.1.8 and
   marks an important step forward in FreeBSD Java support.

   The team is continuing development work, with a focus on achieving a
   compliant JDK 1.4 release in the near future.

FreeBSD ports monitoring system


   Contact: Mark Linimon <linimon_at_lonesome_dot_com>

   Several months ago, I took it upon myself to to try present the
   information contained on the bento build cluster to be presented in a
   more user-friendly fashion; that is, to be browsed by error type, by
   maintainer, and so forth. An early addition was code to attempt to
   classify ports PRs by either "existing port" (after assiging the most
   likely category and portname); "new port"; "framework" (e.g. changes); and "unknown". Various columns about the ports
   PRs were added to the reports.

   The initial intent of this was to make life easier for ports
   maintainers; however, the "general" reports are also useful to anyone
   who just wants to, e.g., find out if a particular port is working on
   their particular architecture and OS combination before downloading
   it. Those with that general interest should start with the overview of
   one port.



   Contact: Marcel Moolenaar <marcel at>

   Much has happened since the last bi-monthly report, which was more
   than half a year ago. FreeBSD 5.0 and FreeBSD 5.1 have been released
   for example. With FreeBSD 5.2 approaching quickly, we're not going to
   look back too far when it comes to our achievements. There's too much
   ahead of us...

   Two milestones have been reached after FreeBSD 5.1. The first is the
   ability to support both Intel and HP machines with sources in CVS.
   This due to a whole new driver for serial ports, or UARTs.
   Unfortunately this still implies that syscons is not configured.
   That's another task for another time, but keep an eye on
   KGI/FreeBSD... The second milestone is the completion of KSE support.
   Both M:N and 1:1 threading is functional on ia64 and the old libc_r
   library has been obsoleted. Testing has shown that KSE (i.e. M:N) may
   well become the default threading model. It's looking good.

   The ABI hasn't changed after 5.1 and the expectation is that it won't
   change much. This means that we can think about becoming a tier 1
   platform. This also means we need gdb(1) support. Work on it has been
   started but the road is bumpy and long. Kernel stability also has
   improved significantly and we typically have one kernel panic
   remaining: VM fault on no fault entry. This will be addressed with the
   long awaited PMAP overhaul (see below).

   Most work for FreeBSD 5.2 will be "sharpening the saw". Get those
   loose ends tied. This is a slight change of plan made possible by a
   slip in the release schedule. The 5.2 release is not going to be the
   start of the -stable branch; it has been moved to 5.3. So, we use the
   extra time to prepare the ground for 5.3.

   The planned PMAP overhaul will probably be finished after 5.2. This
   should address all known issues with SMP and fix those last panics. As
   a side-effect, major performance improvements can be expected. More
   news about this in the next status reports.

jpman project


   Contact: Kazuo Horikawa <horikawa at>

   We have released Japanese translation of 5.1-RELEASE online manual
   pages on June 10.

KDE FreeBSD Project


   Contact: KDE-FreeBSD Mailinglist <kde at>

   The FreeBSD ports were updated to KDE 3.1.4, another bug- and
   security-fixes release. With this update, the QT port was updated to
   version 3.2. Both will be included in FreeBSD 4.9. Significant work
   was spent to fix KDE on FreeBSD-CURRENT after the removal of the gcc
   -pthread Option. Automatic package builds from KDE CVS continued to
   ensure and improve the quality of the upcoming KDE 3.2 release.

   Future: Work is in progress to setup a new server for hosting the
   KDE-FreeBSD Website, Repository and another KDE CVS mirror. With help
   from Marcel Moolenaar the project will try to make KDE compile and
   working on the Intel IA64. And last but not least efforts are being
   made to fix the currently broken kdesu program.

kgi4BSD Status Report


   Contact: Nicholas Souchu <nsouch at>

   A lot of work done since last report: site reworked completly (see new
   URL), console design with console message in text or graphic modes
   implemented, implementation of a compatibility layer to compile Linux
   fbdev drivers with more or less changes in the original driver

   Except some memory allocation bugs, X (XGGI based on XFree 3.3.6) is
   now working with the same driver as the console. A basic terminal has
   now to be implemented.

   Volonteers are welcome to the project...



   Contact: Dan Eischen <deischen at>
   Contact: David Xu <davidxu at>

   KSE seems to be working well on x86, amd64, and ia64. The alpha
   userland bits are done, but a couple of functions are unimplemented in
   the kernel. For sparc64, the necessary functions are implemented in
   the kernel, but the userland context switching functions need more

   Since 5.1, efficient scope system threads (no upcalls when they block)
   have been implemented, and KSE based pthread library can have both
   POSIX scope process threads and scope system threads. It is also
   possible that KSE based pthread library can implement pthread both in
   1:1 and M:N mode, I know Dan has such Makefile file patch for libkse
   not yet committed.

   KSE program now can work under ULE scheduler, its efficient should be
   improved under the new scheduler in future. BSD scheduler is still the
   best scheduler for current KSE implement.

Network Subsystem Locking and Performance

   Contact: Sam Leffler <sam at>

   The purpose of this project is to improve performance of the network
   subsystem. A major part of this work is to complete the locking of the
   networking subsystem so that it no longer depends on the "Giant lock"
   for proper operation. Removing the use of Giant will improve
   performance and permit multiple instances of the network stack to
   operate concurrently on multiprocessor systems.

   This project started in August. The emphasis has been on locking the
   "lower half" of the networking code so that packet forwarding through
   the IPv4 path can operate without the Giant lock as part of the 5.2
   release. To this end locking was added to several network interface
   drivers and much of the "middleware" code in the network was locked
   (e.g. ipfw, dummynet, then routing table, multicast routing support,
   etc). Work towards this goal is still ongoing but should be ready for
   5.2. A variety of test systems have been running for several months
   without the Giant lock in the network drivers and IP layer.

   Past the 5.2 release Giant will be removed from the "upper half" of
   the network subsystem and the socket layer. Once this is done the plan
   is to measure and improve performance (though some work of this sort
   is always happening). The ultimate goal is a system that performs at
   least as well as 4.x for normal use on uniprocessor systems. On
   multiprocessor systems we expect to see significantly better
   performance than 4.x due to greater concurrency and reduced latency.

Porting OpenBSD's pf


   Contact: Max Laier <max at>
   Contact: Pyun YongHyeon <yongari at>

   The project started this spring and released version 1.0 with a port
   installation (security/pf) in may 2003. Version 2.0 is on the doorstep
   as OpenBSD 3.4 will be released. Due to the porting efforts we were
   able to reveal some bugs in the OpenBSD code and provided locking for
   the PFIL_HOOKS, which we utilize. Tarball installation of a loadable
   kernel module for testing can be found on the project homepage, a
   patchset is in the making.

   PF was started at OpenBSD as a substitute for ipfilter and provides
   the same function set. However, in the two years it exists now, it has
   gained many superior features that no other packet filter has. For a
   impression take a look at the pf FAQ.

   We hope to be eventually integrated into the base system. Before that
   we have to resolve some issues with tcpdump and kame.

PowerPC Port

   Contact: Peter Grehan <grehan at>

   Work has restarted after a hiatus. Current focus is on getting
   loadable modules working, NEWBUSing the NetBSD dbdma code, and
   completing the BMAC ethernet driver.

   There is a huge amount of work to do. Volunteers more than welcome!

Release Engineering Status

   Contact: Scott Long <re at>

   The release of 4.9 is just around the corner and offers Physical
   Address Extensions (PAE) for x86 along with the same world-class
   stability and performance that is expected from the 4-STABLE series.
   As always, don't forget to purchase a copy of the CD set from your
   favorite FreeBSD vendor.

   FreeBSD 5.1 was released in June and offered vastly improved stability
   over 5.0 along with a working implementation of Kernel Scheduled
   Entities, allowing for true multithreading of applications across
   multiple CPUs. FreeBSD 5.2 will be released by the end of 2003 and
   will focus on improved network and overall performance.

Rescue build infrastructure

   Contact: Gordon Tetlow <gordon at>
   Contact: Tim Kientzle <kientzle at>

   The rescue build infrastructure has been committed. There is one known
   issue with make using both the '-s' and '-j' flags that appears to be
   a bug in make. Anyone interested in tracking down should contact us.


   Contact: Marcel Moolenaar <marcel at>

   The uart(4) project was born out of the need to have a working serial
   interface (i.e. an RS-232-C interface) in a legacy-free configuration
   and after an unsuccessful attempt to convert sio(4). The biggest
   problem with sio(4) is that it has been intertwined in many ugly ways
   into the kernel's core. Conversion could not happen without breaking
   something that invariably affects some group of people negatively.
   With sio(4) as a good bad example and a strong desire to solve
   multiple problems at once, the idea of an UART (Universal
   Asynchronuous Receiver/Transmitter) device that, given its generic
   name, could handle different flavors of UART hardware started to
   settle firmly in the authors mind.

   The biggest challenge was of course solving the problem of the
   low-level console access prior to the initialization of the bus
   infrastructure and still have a driver that uses the bus access
   exclusively. Along the way the problem of having an UART function as
   the keyboard on sparc64 was solved with the introduction of system
   devices, which also encapsulated the console as a system device.

   The uart(4) driver can be enhanced to support the various UART
   hardware on pc98 and this is currently being worked on. Keyboard
   support on sparc64 is underway as well. Plans exist for a rewrite of
   the remote gdb support that uses a generic interface to allow various
   drivers, including uart(4), to register itself as a communications
   channel. And since uart(4) does not support multi- port cards by
   itself, we likely need to either enhance puc(4) or otherwise introduce
   other umbrella drivers



   Contact: John-Mark Gurney <jmg at>

   Still in the planning stage. Working on creating an extensible
   interface that is usable for both userland and kernel implementations
   for device drivers. Deciding on how to interface userland implemented
   device drivers with applications.

WifiBSD Status Report


   Contact: Jon Disnard <masta at>

   WifiBSD is a miniture version of FreeBSD for wireless applications.
   Originally for the Soekris Net45xx line of main-boards, but is now
   capable of being targeted to any hardware/architecture FreeBSD itself
   supports. Although not feature complete, WifiBSD is expected to be
   ready for 5.2-RELEASE. The design goal is to meet, or exceed, the
   functionality of commercial/consumer 802.11 wireless gear. Features
   that need attention (to name just a few) are: http interface, consol
   menu interface, and installation. Volunters are welcome.

Wireless Networking Support

   Contact: Sam Leffler <sam at>

   Numerous bugs have been fixed since the last status report (and of
   course a few new ones added). Progress on improved security has been
   slowed by other work. But new features and fixes are coming in from
   other groups that are now sharing the code. In particular NetBSD
   recently imported the revised 802.11 layer and the Linux-based MADWIFI
   project is using it too (albeit in an older form). The MADWIFI users
   have already contributed features such as fragmentation reassembly of
   802.11 frames and improved signal monitoring. Power save polling and
   an improved rate control algorothm are expected to come in from the
   NetBSD folks. WPA support is still in the plans; the best estimate is
   that work on that will start in January.

   News Home | Status Reports Home

    freebsd-questions at
    Copyright © 1995-2003 the FreeBSD Project. All rights reserved.
freebsd-current at mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscribe at"

More information about the freebsd-stable mailing list