Thor Lancelot Simon | 23 Jul 14:46 2014

Marvell 88SE9230 AHCI?

I just ordered a Supermicro low-power rackmount x86 machine which -- I
discovered after ordering it -- uses a Marvell 88SE9230 as a SATA controller.

From FreeBSD's ahci.c, I see this is approximately an AHCI compatible
controller but that it has some quirks.  Is anyone using NetBSD with this
controller or the similar 88SE9128, 9128, or 9130?


Alan Barrett | 23 Jul 11:31 2014

More detailed build infomation in kernels

I have some private patches that append arbitrary additional 
information to the kernel version string.  Essentially, I pass 
BUILDINFO="<multi-line message here>" in the environment (through and the make wrapper), and then a modified version of 
src/sys/conf/ appends it to the value of the "version" 
variable in the vers.c file that's compiled into the kernel.  I 
also add the information to /etc/release.

The additional information is exposed in sysctl kern.version, and 
in {struct utsname}.version as returned by uname(3), and in the 
output from uname(1) -v.

I use this feature to add infomation about the source tree
and build date, so I see information like this:

$ sysctl kern.version
kern.version = NetBSD 6.99.47 (APB)
fossil repository: apb-local-src.fossil
fossil tags: local
fossil commit: 449e51b700 (2014-07-19 15:41:14 UTC)
fossil comment: merge src from trunk as of 2014-07-19 00:00 UTC

I imagine that it would be useful for official builds to
include some sort of official statement here.

The multi-line BUILDINFO strings are truncated and folded to a 
single line by uname(3), which is unhelpful, so I am inclined to 
store them in a new kernel variable, exposed via a new sysctl 
node, instead of appending to the existing kernel version 
variable.  Then the new information would not be exposed by 
(Continue reading)

Taylor R Campbell | 23 Jul 02:42 2014

task queues

We don't have a nice easy lightweight way for a driver to ask that a
task be executed asynchronously in thread context.  The closest we
have is workqueue(9), but each user has to do bookkeeping for a
different workqueue and incurs a long-term kthread, or ncpu long-term
kthreads, that are mostly idle -- most users of workqueue(9) create a
single struct work for the workqueue and use it for a single purpose.

For USB drivers, we have usb_task, but the API is limited and, for
most users, broken: there's no way to wait for a task to complete,
e.g. before detaching a device and unloading its driver module.
There's also no reason this is peculiar to USB drivers.

The other month I threw together an facility for scheduling
lightweight tasks to be executed in thread context on the current CPU,
supporting cancellation, and without requiring a long-term kthread per

All you need to do to call my_task_action asynchronously is allocate a
struct task object, e.g. in your device softc, and do

	task_init(task, &my_task_action);

static void
my_task_action(struct task *task)

	printf("My task ran!\n");

(Continue reading)

Taylor R Campbell | 23 Jul 02:25 2014

pserialized reader/writer locks

While reading the fstrans(9) code a few months ago and trying to
understand what it does, I threw together a couple of simple
pserialize(9)-based reader/writer locks -- one recursive for nestable
transactions like fstrans(9), the other non-recursive.

Unlike rwlock(9), frequent readers do not require interprocessor
synchronization: they use pool_cache(9) to manage per-CPU caches of
in-use records which writers wait for.  Writers, in contrast, are very

The attached code is untested and just represents ideas that were
kicking around in my head.  Thoughts?  Worthwhile to experiment with?
/*	$NetBSD$	*/

 * This code does not run!  I have not even compile-tested it.

 * Copyright (c) 2014 The NetBSD Foundation, Inc.
 * All rights reserved.
 * This code is derived from software contributed to The NetBSD Foundation
 * by Taylor R. Campbell.
 * Redistribution and use in source and binary forms, with or without
(Continue reading)

Taylor R Campbell | 23 Jul 02:12 2014

removing mappings of uvm objects or device pages

How can I remove all virtual mappings of a range of a uvm object, or
all virtual mappings of a physical page that is a device page rather
than a physical RAM page?

- I can't uvm_unmap(vm_map, start, end) because I don't know every
  vm_map into which this uvm object has been mapped and where,
  although if I had a way to list weak references to vm_maps perhaps I
  could keep books about this.

- I can't pmap_page_protect(vm_page, VM_PROT_NONE) because there is no
  struct vm_page for the pages in question -- they're device pages,
  not system RAM pages.

Background (with apologies for the length; this is a little tricky):

Graphics drivers involve buffers, represented by UVM objects, that can
be mapped into the GPU virtual address space or into one or more of
the various CPU address spaces.  Sometimes the driver needs to free up
some GPU virtual address space, so it will choose an inactive buffer
to evict, say at V_gpu, and unmap the GPU page table entry for V_gpu.

If the buffer is not mapped into any CPU virtual address space, all is
well and good.  But if it is mapped into a CPU virtual address space,
say at the virtual address V_cpu, it's a little tricky.

While shared between GPU and CPU virtual address spaces, graphics
buffers are backed by physical pages of system RAM, say at the
physical address P_ram.  The GPU page table's entry for V_gpu points
at P_ram.  But the buffer's fault handler for V_cpu doesn't map it to
P_ram -- it maps V_cpu to a special physical address P_aper in a
(Continue reading)

Taylor R Campbell | 23 Jul 01:01 2014

uvm objects and bus_dma

Several graphics drivers use swap-backed buffers that sometimes need
to be wired into physical memory and made available for DMA by the
device.  For buffers that are always wired and always mapped into KVA,
we can use bus_dmamem.  But these buffers are numerous and large, so
they should not be wired or mapped into KVA all the time.

I propose to add the following MI APIs to bus_dma(9):

int	bus_dmamem_pgfl(bus_dma_tag_t dmat);

   Return a page freelist number fit for use with uao_set_pgfl or
   uvm_pagealloc_strat(UVM_PGA_STRAT_ONLY).  Pages allocated from this
   freelist are guaranteed to have physical addresses fit for DMA with

int	bus_dmamap_load_pglist(bus_dma_tag_t dmat, bus_dmamap_t map,
	    struct pglist *pglist, bus_size_t size, int flags)

   Load map for DMA to the pages in pglist.  The pages must have been
   allocated from the freelist returned by bus_dmamem_pgfl(dmat), and
   are typically obtained by uvm_obj_wirepages.

Typical usage:

	/* Limit to 36-bit paddrs for DMA.  */
	if (bus_dmatag_subregion(pa->pa_dmat64, 0, __BITS(0,35), &dmat,
		goto fail0;

	/* Create an object.  */
(Continue reading)

Christoph Badura | 20 Jul 17:15 2014

how to properly enable modules for pci devices?

I want to enable the build of ubsec(4) as a module in sys/modules/Makefile
for all arches that have PCI bus and a reference to ubsec in some kernel
config file.

Reading sys/modules/Makefile I found little guidance.  I get the
impression that this hasn't been tried before.

I've come up with the following changes and ran release builds for:
  alpha evbarm i386 hppa arc evbmips evbppc sparc sparc64 amd64

Of those evbppc failed because PPC_PCI_MACHDEP_IMPL isn't defined when
the module is compiled.  How is that supposed to work?

The other release builds were all successful.

I'd like to get this into -7 in some form or other.  Comments?


Index: sys/modules/Makefile
RCS file: /cvsroot/src/sys/modules/Makefile,v
retrieving revision 1.136
diff -u -r1.136 Makefile
--- sys/modules/Makefile	18 May 2014 11:46:23 -0000	1.136
+++ sys/modules/Makefile	20 Jul 2014 14:43:15 -0000
 <at>  <at>  -105,7 +105,6  <at>  <at> 
 SUBDIR+=	tprof
 .if (defined(NOTYET))
 SUBDIR+=	hifn		# Builds on architectures with PCI bus
(Continue reading)

Ms. Zou | 19 Jul 15:45 2014

Spam Good-day


My name is Ms. Zou from Taiwan, i will like to make an inquiry on your product please inform me on (minimum and
maximum order quantity and latest product catalog) Send it asap so that we can place a trial order.

Ms. Zou
Sales manager.

Alexander Nasonov | 19 Jul 11:02 2014

icache sync private rump component


I'd like to commit a private rump component that adds a hypercall for
synching icache. This will help us to test bpfjit and npf on arm and
mips platforms.

I already sent a couple of emails to Antti but because he hasn't
replied yet and the branching date is fast approaching, I thought
I'd give a heads up to the community. I'll commit my changes if I
don't hear any objections in the next few days.

Basically, this component resides in librumpkern_sljit and it
exposes one function:

int rumpcomp_sync_icache(void *, uint64_t);

This declaration doesn't go to any public header file because it's
only being used inside librumpkern_sljit.

On arm, rumpcomp_sync_icache() makes ARM_SYNC_ICACHE sysarch syscall
while on mips it calls _cacheflush() which is defined in libc.

On the kernel side, both arm and mips use a global object with a bunch
of function pointers to various cpu-related routines. Those objects
are defined in cpufunc.c and cache.c, respectively.

For the rump kernel, I add barebone versions of those objects with
only one non-NULL function pointer for icache_rync_range routine.

To compile <mips/cache.h> in rump kernel, I needed to add -DMIPS3=1
(Continue reading)

Maxime Villard | 18 Jul 11:46 2014


I intend to enable KMEM_REDZONE on DIAGNOSTIC. It adds a 2-byte-sized pattern at
the end of each allocated buffer when allocating, and checks this pattern when
freeing to ensure the caller hasn't written outside the requested area. It can
catch off-by-one's, and has almost no performance impact now.

I think it's a nice feature, and our (me and lars <at> ) recent improvements make it
more efficient and lighter. As a comparison, one month ago I enabled KMEM_SIZE
and shortly afterwards it caught a memory corruption bug:


Index: subr_kmem.c
RCS file: /cvsroot/src/sys/kern/subr_kmem.c,v
retrieving revision 1.59
diff -u -r1.59 subr_kmem.c
--- subr_kmem.c	3 Jul 2014 08:43:49 -0000	1.59
+++ subr_kmem.c	3 Jul 2014 12:56:41 -0000
 <at>  <at>  -65,13 +65,23  <at>  <at> 
  *	Prefix each allocations with a fixed-sized, aligned header and record
  *	the exact user-requested allocation size in it. When freeing, compare
  *	it with kmem_free's "size" argument.
- */
+ *
  * KMEM_REDZONE: detect overrun bugs.
(Continue reading)

Manuel Bouyer | 16 Jul 23:18 2014

troubles with an USB touch screen

I have a USB touch screen, which I have trouble getting working
properly (under -current). It reports itself as:
uhidev0 at uhub0 port 1 configuration 1 interface 0
uhidev0: N-trig DuoSense, rev 2.00/21.00, addr 2, iclass 3/0
uhidev0: 10 report ids
uhid at uhidev0 reportid 1 not configured
uhid at uhidev0 reportid 2 not configured
uhid at uhidev0 reportid 3 not configured
uhid at uhidev0 reportid 4 not configured
uhid at uhidev0 reportid 5 not configured
uhid at uhidev0 reportid 6 not configured
uhid at uhidev0 reportid 7 not configured
uhid at uhidev0 reportid 8 not configured
uhid at uhidev0 reportid 9 not configured
uhid at uhidev0 reportid 10 not configured
uhidev1 at uhub0 port 1 configuration 1 interface 1
uhidev1: N-trig DuoSense, rev 2.00/21.00, addr 2, iclass 3/0
uhidev1: 24 report ids
ums0 at uhidev1 reportid 1: 3 buttons digitizer, tip, barrel, eraser
wsmouse0 at ums0 mux 0
uts0 at uhidev1 reportid 2wsmouse1 at uts0 mux 0
uts1 at uhidev1 reportid 3wsmouse2 at uts1 mux 0
uhid at uhidev1 reportid 4 not configured
uhid at uhidev1 reportid 10 not configured
uhid at uhidev1 reportid 11 not configured
uhid at uhidev1 reportid 12 not configured
uhid at uhidev1 reportid 13 not configured
uhid at uhidev1 reportid 14 not configured
uhid at uhidev1 reportid 15 not configured
(Continue reading)