From deb80e622591c03c21eaa09ef17ef6f923edd0ab Mon Sep 17 00:00:00 2001 From: Daniel Gerzo Date: Tue, 12 Jan 2010 21:27:23 +0000 Subject: [PATCH] - start wrapping up the FreeBSD status report for 4Q/2009 - this is to allow other members of monthly@ to work further on my version - keep this disconnected from the build until after we add all the entries we will receive until deadline. I suppose there will be a few more. --- en/news/status/report-2009-10-2009-12.xml | 1030 +++++++++++++++++++++ 1 file changed, 1030 insertions(+) create mode 100644 en/news/status/report-2009-10-2009-12.xml diff --git a/en/news/status/report-2009-10-2009-12.xml b/en/news/status/report-2009-10-2009-12.xml new file mode 100644 index 0000000000..e29d36ebf6 --- /dev/null +++ b/en/news/status/report-2009-10-2009-12.xml @@ -0,0 +1,1030 @@ + + + + + + October-December + + 2009 + + +
+ Introduction + +

This report covers &os; related projects between October and + December 2009. Obviously, this is the last report in the year 2009, + which has shown to be very important for the &os; Project. Besides + other remarkable things, a new major version of &os;, 8.0, has been + released, while the release process for 7.3 is soon to begin.

+ +

Thanks to all the reporters for the excellent work! We hope you + enjoy the reading. Let us also use this opportunity to wish you all + happy and successfull new year 2010.

+ +

Please note that the next deadline for submissions covering the + period between January and March 2010 is April 15th, 2010.

+
+ + + soc + + Google Summer of Code + + + + proj + + Projects + + + + team + + &os; Team Reports + + + + net + + Network Infrastructure + + + + kern + + Kernel + + + + docs + + Documentation + + + + arch + + Architectures + + + + ports + + Ports + + + + vendor + + Vendor / 3rd Party Software + + + + misc + + Miscellaneous + + + + DAHDI (Zaptel) support for &os; + + + + + Max + + Khon + + + fjoe@FreeBSD.org + + + + + SVN + repository + + + Official Announcement + + + +

A module for DAHDI support for &os; has been created in the + official Asterisk SVN repository.

+ +

The following drivers are currently ported:

+ +
    +
  • main DAHDI driver
    • + +
  • all software echo cancellation drivers
    • + +
  • dahdi_dynamic
    • + +
  • dahdi_dynamic_loc
    • +
+ +

The following HW drivers are currently ported and tested:

+ +
    +
  • wct4xxp, including HW echo cancellation support + (Octasic)
    • + +
      +
    • Digium TE205P/TE207P/TE210P/TE212P: PCI dual-port + T1/E1/J1
      • + +
    • Digium TE405P/TE407P/TE410P/TE412P: PCI quad-port + T1/E1/J1
      • + +
    • Digium TE220: PCI-Express dual-port T1/E1/J1
      • + +
    • Digium TE420: PCI-Express quad-port T1/E1/J1
      • +
    + +
  • wcb4xxp
    • + +
      +
    • Digium B410: PCI quad-port BRI
      • + +
    • Junghanns.NET HFC-2S/4S/8S duo/quad/octoBRI
      • + +
    • OpenVox B200P/B400P/B800P
      • + +
    • BeroNet BN2S0/BN4S0/BN8S0
      • +
    +
+ + + + +

The port for dahdi_dynamic_eth and dahdi_dynamic_ethmf is + under way.

+ + + +

More HW drivers need to be ported.

+ +

Please let me know if you can provide remote access with + serial console to the box with ISDN/T1/E1 HW not currently + supported by DAHDI for &os; but supported by DAHDI for Linux. I + am also interested in porting drivers for FXO/FXS cards: please + let me know if you can provide a remote access or donate a + card.

+ + + + + + CAM-based ATA implementation + + + + + Alexander + + Motin + + + mav@FreeBSD.org + + + + + Scott + + Long + + + scottl@FreeBSD.org + + + + +

Existing ata(4) infrastructure which has been around many years + has number of problems and limitations, in respect to modern + controllers/devices support. A CAM subsystem (used for SCSI), which + is around for almost the same time, implements many of required + algorithms solving many problems in a better way. To reduce code + duplication and better support border cases such as ATAPI and SAS, + new CAM based ATA implementation has been started in order to use + its benefits.

+ +

As such, CAM infrastructure was extended to support different + transports. New transport was implemented to support PATA/SATA + buses. To support ATA disks, new CAM driver ada was written. ATAPI + devices are supported by existing SCSI drivers cd, da, sa, etc. To + support SATA port-multipliers new CAM driver pmp was written. To + support most featured and widespread SATA controllers, new drivers + ahci(4) and siis(4) were developed.

+ +

To support legacy ATA controllers, kernel option ATA_CAM was + added. When used, it makes all ata(4) controllers directly + available to CAM, deprecating ata(4) periperal drivers and external + APIs. To make it possible, ata(4) code was heavily refactored, + making controller driver API more strict.

+ +

Command queuing support gives new ATA implementation up to + double performance benefit on some workloads, whereas 20-30% is + quite usual.

+ +

SATA Port Multipliers support makes it easy to build fast and + cheap storages with huge capacities, by using dozens of SATA drives + in one system or external enclosures,

+ +

Some of that code was presented in &os; 8.0-RELEASE, but + 8-STABLE includes much improved version now.

+ + + + +

Improve timeouts and transport errors recovery.

+ + + +

Improve hot-plug support.

+ + + +

Search and fix any show stoppers for legacy ata(4) + deprecation.

+ + + +

Write new, more featured driver for Marvell SATA controllers + (specs wanted).

+ + + +

Write SAS-specific transport and drivers for SAS HBAs (specs + wanted). SAS controllers can support SATA devices and + multipliers, so it should fit nicely into the new + infrastructure.

+ + + + + + Chromium web browser + + + + + Ben + + Laurie + + + ben@links.org + + + + + test builds and port + progress + + first build + information + + + +

Chromium is a Webkit-based web browser that is largely BSD + licensed. We ported it from linux to &os; in October and have been + posting patches and test builds periodically ever since. Chromium + works well on &os; — it is very fast and stable, but there + are a handful of rough edges that need to be polished up. Two + remaining bugs should probably be fixed before releasing a + chromium-devel port. We are looking for volunteers to test and + maintain this port, to make this BSD browser a viable option on the + &os; desktop.

+ + + + Fix sporadic rendering freezes + + Fix javascript interpreter, v8, on i386 architecture + + + + + SUJ: Journaled Softupdates + + + + + Jeff + + Roberson + + + jeff@freebsd.org + + + + + + + + +

I have been adding a small intent log to softupdates to + eliminate the requirement for fsck after an unclean shutdown. This + work has been funded by Yahoo!, iXsystems, and Juniper. Kirk + McKusick has been aiding me with design critiques and helping me + better understand softupdates.

+ +

Extensive testing by myself and Peter Holm has yielded a stable + patch. Current users are encouraged to follow the instructions + posted to current@ to verify stability in your own workloads. + Updates are forthcoming and it is expected to be merged with + current before the end of January. Ports to older versions of &os; + will be available in SVN under alternate branches. Official + backports will be decided by re@ when current is stable.

+ +

The changes are fully backwards and forwards compatible as there + are very few metadata changes to the filesystem. The journal may be + enabled or disabled on existing ffs filesystems using tunefs(8). + The log consumes 64 megabytes of space at maximum and fsck time is + bounded by the size of the log rather than the size of the + filesystem. Other details are available in my technical + journal.

+ + + + + Ports Collection + + + + + Mark + + Linimon + + + linimon@FreeBSD.org + + + + + The &os; Ports + Collection + + + Contributing to the &os; Ports Collection + + &os; ports + monitoring system + + The &os; + Ports Management Team + + marcuscom + Tinderbox + + + +

Most of the recent activity was dealing with the 8.0 release + process. As an experiment, we tried to decouple the ports QA + timeline as much as possible from the src QA timeline. Although + this meant that the impact on people actively maintaining and using + ports was much less than in previous releases, it still has not + solved the problem of the release going out with an stale set of + packages. We are still trying to come up with a better solution for + the problem.

+ +

The ports count is over 21,000. The PR count jumped to over + 1000, but is now back to around 950.

+ +

We are currently building packages for amd64-6, amd64-7, + amd64-8, i386-6, i386-7, i386-8, i386-9, ia64-8, sparc64-7, and + sparc64-8. This represents the addition of i386-9 and ia64-8 since + the last report.

+ +

There has been some discussion of when to drop regular package + builds for 6.x, but no decision has been made yet. The cluster, and + the portmgrs, are struggling to keep up with so many branches being + active all at the same time.

+ +

Mark Linimon continues to make progress on the cluster nodes. + Almost every node that does not have a hard disk failure is now + online. In addition, he continues to make progress debugging + problems that occasionally take nodes offline.

+ +

The next task is to characterize the overall performance of the + build cluster. The question has been asked of us, "what would it + take to speed up package builds?" There is no one simple answer. It + is not merely a matter of having a larger number of package + building machines -- before asking for funding we first need to + identify the current bottlenecks. While we are starting to + understand the problems on the nodes, the problems on the dispatch + machine itself are much harder. Complicating the matter is that + there are several periodic processes (ZFS backup, ZFS expiration, + and errorlog compression, among others) that can combine to slow + that machine significantly. The interaction of all these + simultaneously is proving difficult to quantify.

+ +

Between pav and miwi, many more experimental ports runs have + been completed and committed.

+ +

We have added 3 new committers since the last report, and 1 + older one has rejoined.

+ + + + We are still trying to set up ports tinderboxes that can be + made available to committers for pre-testing. + + Most of the remaining ports PRs are "existing port/PR + assigned to committer". Although the maintainer-timeout policy is + helping to keep the backlog down, we are going to need to do more + to get the ports in the shape they really need to be in. + + Although we have added many maintainers, we still have more + than 4,700 unmaintained ports (see, for instance, the list on + portsmon). (The percentage remains steady at just over 22%.) We are + always looking for dedicated volunteers to adopt at least a few + unmaintained ports. As well, the packages on amd64 and especially + sparc64 lag behind i386, and we need more testers for those. + + + + + &os;/sparc64 + + + + + Marius + + Strobl + + + marius@FreeBSD.org + + + + +

The main thing that has taken place since the last Status Report + is that I have gotten to the bottom of the remaining PCI problems + with Sun Fire V215/V245 and support for these has been completed + and since r202023 now is part of HEAD. With some luck it will also + be part of the upcoming 7.3-RELEASE.

+ +

In other news:

+ +
    +
  • Two bugs in the NFS server causing unaligned accesses and + thus panics on sparc64 and all other architectures with strict + alignment requirements (basically all Tier 2 ones) have been + fixed. There likely will be a 8.0-RELEASE Erratum Notice released + for these.
    • + +
  • &os; has been adopted to the changed firmware of newer Sun + Fire V480 (those equipped with version 7 Schizo bridges) and was + reported to now run fine on these. The necessary change will be + part of 7.3-RELEASE. Unfortunately, using the on-board NICs in + older models of Sun Fire V480 (at least those equipped with + version 4 Schizo bridges) under &os; still leads to the firmware + issuing a FATAL RESET due to what appears to be a CPU bug which + needs to be worked around.
    • + +
  • Work on supporting Sun Fire V1280 has been started but still + is in very early stages. Unfortunately, these are rather quirky + machines. After solving two firmware specialties the loader now + is able to boot the kernel but the latter currently still fails + in early cycles as trying to take the trap table over from the + firmware results in a solid hang.
    • +
+ + + + + 3G USB support + + + + + Andrew + + Thompson + + + thompsa@FreeBSD.org + + + + +

Recently a bunch of new device IDs have been added for the + u3g(4) cellular wireless driver, the list should be comparable with + other operating systems around. A lot of these devices have a + feature where the unit first attaches as a disk or cdrom that + contains the Win/Mac drivers, this state should be detected by the + u3g driver and the usb device is sent a command to switch to modem + mode. This has been working for quite some time but as its + implemented differently for each vendor I am looking for feedback + on any units where the auto switchover is not working (or the init + is not recognized at all). Please ensure you are running an up to + date kernel from head r201681 or later, or stable/8 if r201681 has + been merged by the time of publication.

+ + + + + The &os; German Documentation Project + + + + + Johann + + Kois + + + jkois@FreeBSD.org + + + + + Benedict + + Reuschling + + + bcr@FreeBSD.org + + + + + Martin + + Wilke + + + miwi@FreeBSD.org + + + + + German Documentation Project + Homepage + + + +

We are happy to announce that Benedict Reuschling is now free + from mentorship and can commit to the doc-tree on his own.

+ +

Since the last status report, the German Documentation Team has + chased updates to various sections of the &os; handbook, FAQ and + the german website. Many handbook pages were updated to the latest + version, including chapters about configuration, disks, kernel + configuration, printing, multimedia and virtualization.

+ +

We require help from volunteers who are willing to contribute + bug fixes or translations. The following documents need active + maintainership and are a good training-ground for those willing to + join the translation team:

+ +
    +
  • arch-handbook/jail/
    • + +
  • developers-handbook/I10n/
    • + +
  • developers-handbook/policies/
    • + +
  • developers-handbook/sockets/ (translation from scratch)
    • + +
  • handbook/firewalls/ (translation from scratch)
    • + +
  • handbook/security/
    • + +
  • porters-handbook/
    • +
+ + + + Read the translations and report bugs to + de-bsd-translators@de.FreeBSD.org. + + Translate articles or missing sections listed above. + + + + + The &os; Forums + + + + + &os; Forums + + Admins + + + forum-admins@FreeBSD.org + + + + + &os; Forums + + Moderators + + + forum-moderators@FreeBSD.org + + + + + + + + +

Since the last report we have seen a growth of 2000 users on our + Forums resulting in ca. 10.000 registered users at this time. The + posts count is about to reach 60.000 soon, which are contained in + almost 9000 threads.

+ +

The sign-up rate still hovers between 50-100 each week. The + total number of visitors (including 'guests') is currently hard to + gauge, but is likely to be a substantial multiple of the registered + userbase.

+ +

New topics and posts are actively 'pushed out' to search + engines. This in turn makes the Forums show up in search results + more and more often, making it a valuable and very accessible + source of information for the &os; community.

+ +

One of the contributing factors to the Forums' success is their + 'BSD-style' approach when it comes to administration and + moderation. The Forums have a strong and unified identity and are + very actively moderated, spam-free, and with a core group of very + active and helpful members, dispensing many combined decades' worth + of knowledge to starting, intermediate and professional users of + &os;.

+ + + + + V4L support in Linux emulator + + + + + J.R. + + Oldroyd + + + fbsd@opal.com + + + + + + + + +

V4L video support in the Linux emulator is now available.

+ +

This work allows Linux applications using V4L video calls to + work with existing &os; video drivers that provide V4L interfaces. + It is tested and working with the net/skype port and also with + browser-based Flash apps that access webcams. It is tested on + &os;-8.0/amd64 and &os;-7.2/i386. An early version has been + committed to head and work is in progress to commit the latest + version and then MFC.

+ +

Note: to be clear, this does not add V4L support to all webcams. + The &os; camera driver must already offer V4L support itself in + order for a Linux app to be able to use that camera. The + multimedia/pwcbsd port provides the pwc(4) driver that already has + V4L support. If your camera is supported by a different driver, you + will need to enhance that driver to add V4L support.

+ + + + + webcamd + + + + + Hans Petter + + Selasky + + + hselasky@FreeBSD.org + + + + + + + + +

The webcamd daemon enables hundreds of different USB based + webcam devices to be used under the &os;-8/9 operating system. The + webcam daemon is basically an application which is a port of + Video4Linux USB webcam drivers into userspace on &os;. The daemon + currently depends on libc, pthreads, libusb and the VIDEO4BSD + kernel module.

+ + + + Add support for the remaining Video4Linux USB devices. + + Make patches for increased buffer sizes, due to higher + latency in userspace. Especially for High Speed USB. + + + + + Syncing pf(4) with OpenBSD 4.5 + + + + + Ermal + + Luçi + + + eri@FreeBSD.org + + + + + + Viewing the changes. + + The + actual repo to build from. + + + +

This import is based on OpenBSD 4.5 state of pf(4). It includes + many improvements over the code currently present in &os;. The + actual new feature present in pf45 repository is support for + divert(4) which should allow tools like snort_inline to work with + pf(4) too.

+ +

Currently the pf(4) import is considered stable with normal + kernel, as well as VIMAGE enabled kernels.

+ + + + pflow(4)/pflog(4)/pfsync(4) need to be made VIMAGE + aware. + + More regression testing is needed. + + + + + NFSv4 ACL support + + + + + Edward Tomasz + + Napierala + + + trasz@FreeBSD.org + + + + + + + + +

Native NFSv4 ACL support in ZFS and UFS was merged into HEAD. It + is expected to be MFCed in order to make it into FreeBSD 8.1.

+ + + + Support for NFSv4 ACLs in tar(1). + + MFC. + + + + + Ralink wireless RT2700U/2800U/3000U run(4) USB driver + + + + + Akinori + + Furukoshi + + + moonlightakkiy@yahoo.ca + + + + + + Announcement on the &os; Forums + + + +

The run(4) driver brings support for Ralink RT2700U/2800U/3000U + USB wireless devices. For detailed information and list of all the + supported devices, please see the above mentioned URL. The source + code has been imported to the USB P4 repository on January 10, 2010 + (172906).

+ + + + Solve USB_TIMEOUT problem when sending beacons, and/or + confirm which chipsets supports AP mode if all of them don't + support it. + + Read TX stats for AMRR on AP mode, and/or confirm which + chipsets supports AP mode if all of them don't support it. + + Maintain the code. + + + + + &os;/mips + + + + + The &os;/mips mailing list + + + mips@FreeBSD.org + + + + + Warner + + Losh + + + imp@FreeBSD.org + + + + + + + + + + +

The base/projects/mips branch has been merged into base/head. + The merge is complete and the sanity tests have passed. The code + has booted on both a Ubiquiti RouterStation (big endian) as well as + in gxemul (little endian).

+ +

The branch lived for one year, minus a day, and accumulated much + work:

+ +
    +
  • A new port to the Atheros AR71xx series of processors. This + port supports the RouterStation and RouterStation PRO boards from + Ubiquiti. Other boards should work with minimal tweaking. This + port should be considered as nearing production quality, and has + been used extensively by the developers. The primary author of + this port is Oleksandr Tymoshenko (gonzo@FreeBSD.org).
    • + +
  • A new port to the sibyte BCM1250 SoC on the BCM91250 + evaluation board (aka SWARM). This port is reported to be stable, + but this hardware is a little old and not widely available. The + primary author of this port is Neel Natu (neel@FreeBSD.org). Only + one core is presently supported.
    • + +
  • A port, donated by Cavium, to their Octeon and Octeon plus + series of SoC (CN3xxx and CN5xxx). This code is preliminary, + supporting only a single core right now. It has been lightly + tested on the CN3860 evaluation board only in 32-bit mode. Warner + Losh (imp@FreeBSD.org) has been driving the efforts to get this + code into the tree.
    • + +
  • A port, donated by RMI, to their XLR series of SoCs. This + port is single core only as well. The code reaches multi-user but + should be considered beta quality for the moment. Randal Stewart + (rrs@FreeBSD.org) has been driving the efforts to integrate this + into the tree.
    • + +
  • Preliminary support for building a mips64 kernel from this + source base. More work is needed here, but at least two kernels + successfully build in 64-bit mode (OCTEON1 and MALTA64).
    • + +
  • Very early support for N32 and N64 ABIs
    • + +
  • Support for booting compressed kernels has been added + (gonzo@).
    • + +
  • Improved support for debugging
    • + +
  • Improved busdma and bus_space support
    • + +
  • Many bug fixes
    • + +
  • More types of MIPS cores are recognized
    • + +
  • Expanded cache handling for newer processors
    • + +
  • Beginning of a port to the alchemy au1XXX cpus is present, + but experimental.
    • + +
  • Work on SMP is underway to support multicore processors like + the sibyte, Octeon and XLR processors.
    • +
+ +

I am sure there are minor items I have forgotten. If so, please + forgive any omission on my part...

+ +

he branch had been updated incorrectly several times over the + past year, and the damage was too much to repair. We've retired the + branch and will do further mips development in "head" for the time + being. If you have a checked out tree, the suggested way to update + the projects/mips tree you have is to do a "svn switch + svn://svn.freebsd.org/base/head" in that tree.

+ +

I would like to thank everybody that has contributed time, code + or hardware to make FreeBSD/mips better.

+ +

As development proceeds, I will keep posting updates. In + addition, I hope to have some mini "how-to" wiki pages done for + people that want to try it out.

+ + + + We are still investigating how feasible merging all this work + into stable/8 will be, as it represents a huge leap forward in code + stability and quality. + + + + + HAST - Highly Available Storage + + + + + Pawel Jakub + + Dawidek + + + pjd@FreeBSD.org + + + + + + Announcement + + + +

HAST software will provide synchronous replication of any GEOM + provider (eg. disk, partition, mirror, etc.) or file from one &os; + machine (primary node) to another one (secondary node). +
+ + Because data is replicated on block level neither application, no + file systems have to be modified to take advantage of this + functionality. +
+ + The functionality that HAST software will provide is very similar + to the functionality provided by the DRBD project for Linux. +
+ + The HAST project is sponsored by the &os; Foundation. +
+ + Work is progressing well, first milestone was reached in December + 2009 and the project completion date is January 31st 2010. +
+ + Check out &os; mailing lists for patches to test in February and + wish me good luck! +
+ + And BTW, don't forget to donate to the &os; Foundation, as your + donations make projects like this possible. +
+ + Thank you!

+ + + +