Eitan Adler | 25 Apr 07:42 2014

request for help: netcat kernel module for FreeBSD

Hi all,

In an effort to teach myself how to write a kernel module I decided to
port the netcat kernel module to FreeBSD.

For those that havn't heard of it, the original is here:
You will need the original to compile this as well (for the data files)

N.B. This is not intended to commit.

When I load this module the system just freezes.   If I put a return
(0); right before make_dev_p it works.

Can anyone help me figure out what else I did wrong.  (read() code is
untested atm)

#include <sys/param.h>
#include <sys/module.h>
#include <sys/kernel.h>
#include <sys/systm.h>
#include <sys/conf.h>   /* cdevsw struct */
#include <sys/types.h>
#include <sys/uio.h>

#include "tracks/trk1.h"
#include "tracks/trk2.h"
#include "tracks/trk3.h"
#include "tracks/trk4.h"
#include "tracks/trk5.h"
(Continue reading)

Mikolaj Golub | 23 Apr 22:01 2014

valgrind on amd64 crashes when delivering signal for threaded application

I am observing an issue with valgrind on amd64 CURRENT or 10, when it
crashes the application delivering an asynchronous signal, if the
application is linked with libthr.

This simple test illustrate the issue.

  #include <sys/param.h>

  #include <signal.h>
  #include <unistd.h>

  static void
  dummy_sighandler(int sig)
  	/* EMPTY */

  	int c = 10;

  	if (signal(SIGINT, dummy_sighandler) == SIG_ERR)
  		return (1);
  	return (0);

Building with -lpthread, running under valgrind and pressing Ctr-C
makes it crash:
(Continue reading)

Nick Rogers | 23 Apr 02:03 2014

Re: arp(8) performance - use if_nameindex() instead of if_indextoname()

On Sat, Apr 5, 2014 at 1:44 PM, George Neville-Neil
<gnn <at> neville-neil.com> wrote:
> On Mar 27, 2014, at 16:59 , Vladislav Prodan <universite <at> ukr.net> wrote:
>>> I propose that instead of calling if_indextoname() for every entry,
>>> we leverage if_nameindex() to obtain a cache of if_index to if_name
>>> mappings, before printing all the entries. This results in a
>>> considerable performance improvement for my situation, and also
>>> handles the case that was "fixed" in the commit I just mentioned.
>>> I took a shot at this and came up with the following diff against
>>> HEAD. I used routed's route6d.c as a reference, which is the only
>>> thing I could find utilizing if_nameindex(). I am currently using this
>>> in production environments with great success.
>>> The following illustrates the performance improvement:
>>> [root <at> vm ~/arp]# ifconfig -a | grep vlan | grep interface | wc -l
>>> 1500
>>> [root <at> vm ~/arp]# arp -na | wc -l
>>> 1503
>>> [root <at> vm ~/arp]# time /usr/sbin/arp.old -na > /dev/null
>>> real 0m5.529s
>>> user 0m0.813s
(Continue reading)

Sushanth Rai | 22 Apr 23:05 2014

Priotizing pages to be swapped-out


Is there any mechanism for a privileged user application to provide a hint to kernel to prioritize some user
pages to be swapped-out later (after all the "lower" priority pages have been swapped-out)

freebsd-hackers <at> freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

Julio Merino | 22 Apr 22:20 2014

Can fmake be deleted?


The WITHOUT_BMAKE=yes build has been broken for over a month and, as
far as I can tell, only tinderbox noticed... (Should be fixed with a
commit I made yesterday but tinderbox hasn't caught up yet.)

Question: is there any reason to keep the old fmake around or could it
be deleted along all the MK_BMAKE logic?

freebsd-hackers <at> freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

Larry Baird | 22 Apr 04:01 2014

apu1c led driver

There exists a nice simple linux driver for the leds on a pc engines apu1c
board at http://daduke.org/linux/apu/.  Converting driver to use led(4)
and run on FreeBSD seemed straight forward.  Or that is until I realized
I don't know how to alloc and write to a fixed set of I/O ports. I believe
the magic happens by using bus_alloc_resource(). Code below attempts to allow
control of the second of three leds on the apu1c board.  Once I get that
working, it should be easy to extend driver to support all three leds.
What is the correct way to allocate and write to a a set of I/O ports at
address 0xFED801BD?

#include <sys/param.h>
#include <sys/bus.h>
#include <sys/kernel.h>
#include <sys/module.h>
#include <sys/rman.h>
#include <x86/bus.h>
#include <dev/led/led.h>

#define BASEADDR        (0xFED801BD)
#define LEDON           (0x8)
#define LEDOFF          (0xC8)

#define GPIO_187      187       // MODESW
#define GPIO_189      189       // LED1#
#define GPIO_190      190       // LED2#
#define GPIO_191      191       // LED3#

struct apuled_softc {
	device_t	sc_dev;
        int             sc_rid;
(Continue reading)

Chris Torek | 22 Apr 00:15 2014

MAXPHYS in md(4)

In svn commit: r264504 - head/sys/geom/uzip we have:

  Make sure not to do I/O for more than MAXPHYS bytes. Doing so can cause
  problems in our providers, such as a KASSERT in md(4). ...

That would be this one:

	KASSERT(bp->bio_length <= MAXPHYS, ("bio_length %jd",
	if ((bp->bio_flags & BIO_UNMAPPED) == 0) {
		pb = NULL;
		aiov.iov_base = bp->bio_data;
	} else {
		pb = getpbuf(&md_vnode_pbuf_freecnt);

As it happens, the KASSERT is really only required for the
pb != NULL case, which uses one of the reserved getpbuf() buffers
that only map MAXPHYS bytes at a time.  If bp->bio_flags says that
the bio is mapped, we just use the existing KVA, and VOP_READ() and
VOP_WRITE() must already break up arbitrarily large transfers.

So, it seems like the md(4) KASSERT can be moved into the "else".
Is this a good idea?  (It might not help r264504 much since it
looks like r264504 wants to handle short-read results anyway, but
it seems overly restrictive to require <= MAXPHYS for the mapped

(Continue reading)

David Wolfskill | 21 Apr 21:15 2014

Pointer to info on migrating from UFS2 -> ZFS?

At work, we have several machines presently running FreeBSD/amd64
stable/9  <at> r257221 that are used for building software within a jail.
They currently use UFS2 + soft updates (no journaling).

I am interested in finding out how the behavior of one of these systems
changes if I replace the UFS2 FS where the builds are actually done with

I would prefer to avoid the need to touch the machine(s) for this
exercise, so I'm interested in trying the exercise using the same
hardware -- though possibly configured somewhat differently.

What would be a good place to start my research?  [Caveat: While I've
used UFS longer than ... some readers of this message have been alive,
I've not administered ZFS before.]



David H. Wolfskill				david <at> catwhisker.org
Taliban: Evil cowards with guns afraid of truth from a 14-year old girl.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
Kevin Bowling | 21 Apr 03:56 2014

Getting VNET/VIMAGE across the finish line


I'd like to see VNET/VIMAGE get added to GENERIC in -CURRENT and help 
stamp out any remaining issues.

I'm aware of two broad problems at the moment:
* http://www.freebsd.org/cgi/query-pr.cgi?pr=164763&cat=
* pf related things which seem to be getting addressed

Is anyone tracking other issues?


freebsd-hackers <at> freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

Sergey Matveychuk | 18 Apr 18:12 2014



Tell me please, why f_bfree is unsigned and f_bavail is signed?

struct statfs {
  uint64_t f_bfree;             /* free blocks in filesystem */
  int64_t  f_bavail;            /* free blocks avail to non-superuser */
freebsd-hackers <at> freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

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, X.org, 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.
(Continue reading)