Stephan | 30 Mar 14:00 2015

syscall related developer documentation


I´m reffering to this documentation:

I do think that some points have changed with current versions of
NetBSD (7, current). For example the format of syscalls.master and the
argument handling.

Could someone familiar check this?


Maxime Villard | 27 Mar 18:49 2015

bread()'s cred


     bread(struct vnode *vp, daddr_t blkno, int size, struct kauth_cred *cred,
         int flags, buf_t **bpp);

Actually here the 'cred' argument is useless.

Ok if I remove it?

Taylor R Campbell | 26 Mar 13:13 2015

tracking P->V for unmanaged device pages

Various DRM graphics drivers, including Intel, Radeon, and Nouveau,
sometimes need to unmap all virtual mappings of certain physical
pages for which there is no struct vm_page.  The issue is explained in
detail here:

It's not desirable to simply add struct vm_pages on a freelist that
uvm_pagealloc ignores, because struct vm_page is large (120 bytes on
amd64, for example), most of it is unnecessary for P->V tracking, and
the physical regions that need P->V tracking are large (hundreds of
megabytes, or gigabytes).

The attached patch implements the following extension to pmap(9) on
x86 and uses it in DRM[*].  The implementation uses a linear list of
pv-tracked ranges, since it is expected to be short (one to three
elements).  The list is managed with pserialize(9) so it adds no
locking overhead to existing pmap operations that need to look up
entries in it.

core <at>  discussed the problem and asked that this approach be marked as
an interim solution, because not everyone was happy about it but
nobody had an obviously better idea.


void	pmap_pv_init(void);

  Initialize the pmap_pv(9) subsystem.  Called by uvm_init.

(Continue reading)

Robert Sprowson | 24 Mar 14:30 2015

Re: patch: 3.0 hub support for xhci


> This patch tries to support USB 3.0 for xhci.
> xhci is still at best experimental.
> Don't use it on production servers even though it looks work well.
> Fixes: [...]
> Known bugs: [...]
> Misc bugs: [...]

I've spent a few hours looking at this patch, and there's plenty of meat in
there to chew on. However I think in its current form it's undigestable as
in fact it comprises
a) some good fixes that should go straight into CVS
b) some experimental USB 3 work that might break it for some people, this
   should probably be on a private branch
c) some port specific tweaks for Intel chipsets, which should probably be
   compile time bracketed or taken out with quirks on other ports
d) new helper functions in the main USB stack 

I guess that's why it's lingering, because at ~2000 lines it's probably too
big to see which falls into which category.

Taking a step back though, I'd tend to agree that XHCI is currently
experimental grade. 

Looking at other open source stacks I see that for each TRB type there's a
call out from the common USB stack code to the equivalent hardware
operation, whereas in the current NetBSD implementation almost all of
(Continue reading)

Emmanuel Dreyfus | 23 Mar 12:00 2015

keyboard on recent macs


Neither netbsd-6, nor netbsd-current as of 2015-03-17, seems able to work
on recent macs. The system boots, but without keyboard support. 

In the boot prompt, both a USB and a bluetooth keyboard do work. Booting
with option -c (userconf) let me see a message that may be there on normal 
boot (I cannot tell, it pases too fast):
pckbc: cmd word write error

In userconf, the cursor blinks very fast and keyboard inputs do not show up.

Ayone have a hint on how to handle that one?


Emmanuel Dreyfus
manu <at>

Maxime Villard | 21 Mar 08:02 2015

Double-Free in bwi(4)

I was peacefully testing a new feature in my code scanner when it brought me
in sys/dev/ic/bwi.c for what turned out to be an internal bug in the parser.

But, actually, I found a double-free bug in bwi.c.

Can someone review/test it?


Index: bwi.c
RCS file: /cvsroot/src/sys/dev/ic/bwi.c,v
retrieving revision 1.25
diff -u -r1.25 bwi.c
--- bwi.c	7 Jan 2015 07:05:48 -0000	1.25
+++ bwi.c	21 Mar 2015 06:50:09 -0000
 <at>  <at>  -9140,7 +9140,6  <at>  <at> 

 		if (m_new == NULL) {
-			m_freem(m);
 			error = ENOBUFS;
 			    "can't defrag TX buffer (1)\n");
 <at>  <at>  -9151,7 +9150,6  <at>  <at> 
 		if (m->m_pkthdr.len > MHLEN) {
 			MCLGET(m_new, M_DONTWAIT);
 			if (!(m_new->m_flags & M_EXT)) {
-				m_freem(m);
(Continue reading)

Taylor R Campbell | 20 Mar 14:37 2015

nanosecond debiting cv_timedwait

cv_timedwait can't handle sub-tick waits, which we can't do now but
when we go tickless will be handy.

It's also a pain to use in a loop with a maximum timeout -- it doesn't
tell you how many ticks passed, so you have to maintain that yourself:

	unsigned timeout = mstohz(1000);
	unsigned now, end;

	now = hardclock_ticks;
	end = now + timeout;
	while (!condition) {
		error = cv_timedwait_sig(&sc->sc_cv, &sc->sc_lock,
		if (error)
			goto fail;
		now = hardclock_ticks;
		if (end < now) {
			error = EWOULDBLOCK;
			goto fail;
		timeout = end - now;

I propose to add the following routines to address these shortcomings:

int	cv_timedwaitns(kcondvar_t *, kmutex_t *, struct timespec *);
int	cv_timedwaitns_sig(kcondvar_t *, kmutex_t *, struct timespec *);

cv_timedwaitns(cv, lock, timeout) waits a duration at most timeout for
(Continue reading)

J. Hannken-Illjes | 9 Mar 11:05 2015

Re: Vnode API change: add global vnode cache

On 22 May 2014, at 00:48, David Holland <dholland-tech <at>> wrote:


> As I discovered while prodding lfs last weekend, this is too
> optimistic, as there's another family of cases: allocating a new inode
> and constructing a vnode for it.
> It is *possible* to do this by allocating an inode number and then
> using vcache_get to procure the vnode, such that when the vnode cache
> calls VFS_LOADVNODE it will load a blank inode. This is what ffs does,
> and it works fine there since unallocated inodes have fixed known
> locations that are in a known on-disk state.
> It doesn't work for lfs, and it won't work for any other filesystem
> where inode locations aren't fixed, at least not without some ugly
> hackery: you can update the fs state with a location for the new
> inode, and write a buffer with the intended inode contents, and then
> have VFS_LOADVNODE find and use this buffer, but this is inefficient
> and gross. (This isn't itself adequate for lfs because lfs has some
> additional self-inflicted issues.)
> After sleeping on this a few times, ISTM that the best way to handle
> this is as follows:
>   - add an additional call vcache_new to the API;
>   - have vcache_new take a type argument;
>   - have vcache_new assert that no vnode with the same key already
>     exists (FS-level locking should guarantee this);
>   - have vcache_new call a new op VFS_NEWVNODE instead of
(Continue reading)

Lourival Vieira Neto | 5 Mar 02:09 2015

[GSoC 2015] NetBSD kernel Lua project in LabLua

Hi Folks,

LabLua [1] has been accepted as a mentoring organization this year by
Google Summer of Code and I've added a NetBSD kernel Lua project in
the ideas list [2].

If you are an eligible student and have interest in kernel Lua
development (perhaps your own use case or feature idea), please
consider to contact us at LabLua GSoC mailing list [3].



Lourival Vieira Neto

matthew green | 28 Feb 10:44 2015

i386 vs radeondrmkms problem - isa attachments suck

hi folks.

i've been trying to find a least-ugly solution to the radeondrmkms
on i386 problem.  quick summary of what's wrong:

	radeondrmkms doesn't complete attachments (and most
	importantly create a wsdisplay) until mountroot completes.
	this means it happens quite late in boot.  in i386 GENERIC,
	vga <at> isa and pcdisplay <at> isa are still enabled and they will
	attach to the legacy vga device, and present a wsdisplay0
	to the system.  later, radeon0 attaches, and we get a
	wsdisplay1 that has taken over the console output.

this leaves us with a non-working console output, and the inability
to run X11 even if accessed remotely.

my first attempt (that is currently commited), made the radeondrmkms
driver attempt to map the isa vga registers to reserve them from the
vga <at> isa, and while that worked on my serial console machine, it does
not work on a normal system due to x86 consinit() attaching the
basic vga console driver (so we get early console output.)  in this
case, it has already mapped these registers (ie, radeon is unable
to map them) and the later real attachment knows not to attempt it
again.  so that method doesn't work.

we could have the vga driver detach itself at the right point, but
that leaves the console detached for quite a while, during the time
that drm is getting setup (ie, we'd miss several of its early
messages.)  that seems less than desireable.
(Continue reading)

Stephan | 27 Feb 12:55 2015

Adding a .c-file to the kernel


I want to add a new .c-file to the kernel source under sys/kern.
What´s the right way to make the build system aware so it we be
compiled into a new kernel image?

I´m also unsure about the name. The code implements an IPC mechanism.
I guess uipc_ is a good prefix, though I don´t know what 'u' means in
this case.