Gavin Mu | 22 Dec 16:51 2014

status of projects/numa?


Do you know what is the status of projects/numa? It seems it has been there for more than half a year without
any update. Is there any plan to merge to HEAD? or is it not ready yet?

The new Intel Haswell Xeon supports a feature called Cluster on Die, and there will be two NUMA domains in one
CPU socket. I am wondering if NUMA support is being more and more important.

Gavin Mu

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

Stephen Hocking | 21 Dec 21:40 2014

Fun with PF & redirection

Hi all,

I'm using PF on a 10.1 box, and am trying to redirect a range of ports to a
single port, with a rule like this:

rdr on $ext_if proto tcp from any to any port 65334:5044 -> $spoof_host
port $spoof_port

spoof_host has been set to

This does not seem to work. Any ideas?

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

françai s | 19 Dec 14:52 2014

[OFF-TOPIC] A real programmer would not stoop to wasting machine capacity to do the assembly as said Richard Hamming?

Reactions to SOAP and Fortran
Richard Hamming -- The Art of Doing Science and Engineering, p25 (pdf book)

In the beginning we programmed in absolute binary... Finally, a Symbolic
Assembly Program was devised -- after more years than you are apt to
believe during which most programmers continued their heroic absolute
binary programming. At the time [the assembler] first appeared I would
guess about 1% of the older programmers were interested in it -- using
[assembly] was "sissy stuff", and a real programmer would not stoop to
wasting machine capacity to do the assembly.

Yes! Programmers wanted no part of it, though when pressed they had to
admit their old methods used more machine time in locating and fixing up
errors than the [assembler] ever used. One of the main complaints was when
using a symbolic system you do not know where anything was in storage --
though in the early days we supplied a mapping of symbolic to actual
storage, and believe it or not they later lovingly pored over such sheets
rather than realize they did not need to know that information if they
stuck to operating within the system -- no! When correcting errors they
preferred to do it in absolute binary.

FORTRAN was proposed by Backus and friends, and again was opposed by almost
all programmers. First, it was said it could not be done. Second, if it
could be done, it would be too wasteful of machine time and capacity.
Third, even if it did work, no respectable programmer would use it -- it
was only for sissies!

John von Neumann's reaction to assembly language and Fortran
John A.N. Lee, Virginia Polytechnical Institute
(Continue reading)

Robert Bonomi | 17 Dec 21:06 2014

getting 'load average' info from inside a kernel module

originally sent to -questions, where it was suggested that -hackers was more
likely to produce some useful info.

> Subject: getting 'load averages' (or something similar) from inside a _kernel_
>   I'm trying to get the current 'runnable processes' count from inside a 
> kernel loadable module for BSD 8.4, so I can tweak it's behavior depending
> on the current activity level.  All I've found so far is what's in 'man 9 
> runqueue', and it is *badly* out-of-sync with the 8.4 kernel code. <snarl>
> <wry grin>   e.g., the external arrays at the beginning of the synopisis
> are shown as being of type 'struct rq' -- but there *ISN"T* any defined 
> struct 'rq'; it seems to be named 'runq', at least in /usr/include/sys/runq.h
> Then the cr*p gets deeper -- trying to make heads or tails out of how to
> get a count of runnable processes from the _arrays_ (of unknown size) 
> described on the 'man 9 runqueue' page info has me defeated. 
> Looking at '/usr/include/sys/runq.h', it appears that 'struct runq' is
> a single item with an array of queues (by 'nice' level), and a bitmap of
> which array elements have non-zero length queues.
> I'm perfectly willing to brute-force the data out of the queue lists, *IF*
> there's some reasonable, _current_, descriptive info of the format/usage
> of those kernel structures.

if 'man 9 runqueue' is 'mostly' correct -- reality just being 'runq' instead 
of 'rq' -- then 'how to find out' how mamy elements are in those 'unknown size'
arrays is the missing element.  *OR* if those four items are _not_ arrays,
but simple structs -- given the array of queueheads in the 'runq' struct,
I can probably decipher the rest.
(Continue reading)

Daniel Braniss | 13 Dec 12:11 2014

latest wireshark core dumps

hi all,
I just compiled from ports wireshark et.all on a virgin 10.1-stable,
and it’c coredumping on startup, any hints?


freebsd-hackers <at> mailing list
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at>"
Arnaud YSMAL | 10 Dec 10:01 2014

Issue with the number of jumbo frames after tweaking


Using sysctl to set a new value to kern.ipc.nmbjumbo9 or kern.ipc.nmbjumbo16 leads to a wrong value.
This appears in FreeBSD 9.3 with the revision 254515
( which MFC the revision 243631.

The values are respectively 3 and 4 times bigger than expected.

Example on a FreeBSD 9.3 (amd64):
# sysctl kern.ipc.nmbjumbo9=224000
kern.ipc.nmbjumbo9: 223263 -> 672000

The sysctls functions in sys/kern/kern_mbuf.c got the new value from the uma_zone_set_max
(sys/vm/uma_core.c) function.
It looks like the formula used in uma_core.c to compute the number of items based on the number of pages is not
always the same (uk_ppera is sometimes missing).
In the enclosed patch I assumed that the correct formula to compute the number of items is: (pages /
uk_ppera) * uk_ipers

Is it normal that in these sysctls the comparison between nmbufs and the sum of jumbos + clusters (added in
the same revision) does not use the new value requested by the user?

Attachment (uma_core.patch): text/x-patch, 2382 bytes
freebsd-hackers <at> mailing list
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at>"
Andre Albsmeier | 9 Dec 13:50 2014

[Patch] Bring back ALT_BREAK_TO_DEBUGGER functionality to vt(4)

This is what I use to bring back ALT_BREAK_TO_DEBUGGER
functionality to vt(4). The patch is against STABLE-9.3.

--- ./vt_core.c.ORI	2014-07-22 17:29:27.000000000 +0200
+++ ./vt_core.c	2014-12-08 20:51:24.000000000 +0100
 <at>  <at>  -517,6 +517,9  <at>  <at> 

+#if defined(KDB)
+			kdb_alt_break( c, &vd->vd_altbrk );
 			terminal_input_char(vw->vw_terminal, KEYCHAR(c));
 		} else
 			terminal_input_raw(vw->vw_terminal, c);
--- ./vt.h.ORI	2014-04-07 19:06:41.000000000 +0200
+++ ./vt.h	2014-12-08 20:46:55.000000000 +0100
 <at>  <at>  -139,6 +139,7  <at>  <at> 
 	int			 vd_keyboard;	/* (G) Keyboard index. */
 	unsigned int		 vd_kbstate;	/* (?) Device unit. */
 	unsigned int		 vd_unit;	/* (c) Device unit. */
+	int			 vd_altbrk;	/* (?) State for alt break sequence. */


Any comments? Something missing in order to get it committed?

(Continue reading)

se | 8 Dec 14:39 2014


>From se <at>  Mon Dec  8 14:34:01 2014
Return-Path: <se <at>>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
X-Spam-Status: No, score=-3.4 required=7.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	autolearn_force=no version=3.4.0
X-Original-To: se <at> localhost
Received: from (localhost [IPv6:::1])
	by (Postfix) with ESMTP id 814C66FF
	for <se <at> localhost>; Mon,  8 Dec 2014 14:34:01 +0100 (CET)
Received: from []
	by with POP3 (fetchmail-6.3.26)
	for <se <at> localhost> (single-drop); Mon, 08 Dec 2014 14:34:01 +0100 (CET)
Received: from ([])
	by (Dovecot) with LMTP id DS1GDYOmhVQ+LAAAPh7MgA;
	Mon, 08 Dec 2014 14:24:19 +0100
Received: from ([]) by
	with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted)
	esmtp id 1XxyIT-2JxvX60; Mon, 8 Dec 2014 14:24:17 +0100
Received: from ( [])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by (Postfix) with ESMTPS id 37D5B373A
	for <st_esser <at>>; Mon,  8 Dec 2014 13:24:15 +0000 (UTC)
Received: by (Postfix)
	id 35023C52; Mon,  8 Dec 2014 13:24:15 +0000 (UTC)
Received: from ( [IPv6:2001:1900:2254:206a::19:1])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(Continue reading)

Garrett Cooper | 8 Dec 11:22 2014

Reason for reordering /usr/share/misc/termcap.src for /usr/share/misc/termcap ?

Hi all,
	I’m trying to resolve an issue where usr.bin/vi is needed to preprocess share/termcap every time make
buildworld is invoked on FreeBSD. The termcap file reordering seems to have been done since the BSD 4.4
Lite sources were imported into FreeBSD:
, . I don’t have history behind why
this should be done (it’s unfortunate because it appears to mangle the comment <-> entry mappings, and
ultimately this gets put into termcap.db), and I was hoping that someone with additional history could
fill in why this is being done.
Thank you!
Wojciech Puchar | 7 Dec 21:21 2014

freebsd crash under I/O - got error messages

after enabling debug, WITNESS, INVARIANTS, DIAGNOSTICS etc.

just after virtualbox starting VM with windows XP, i've got

what to do next to trace down a problem?

Dec  7 21:15:26 laptop kernel: vboxdrv: fAsync=0 offMin=0x356 offMax=0xe62
Dec  7 21:15:41 laptop kernel: lock order reversal:
Dec  7 21:15:41 laptop kernel: 1st 0xfffff800603305f0 ufs (ufs)  <at>  kern/vfs_syscalls.c:3459
Dec  7 21:15:41 laptop kernel: 2nd 0xfffffe0060df5ad0 bufwait (bufwait)  <at>  ufs/ffs/ffs_vnops.c:262
Dec  7 21:15:41 laptop kernel: 3rd 0xfffff8006037dd50 ufs (ufs)  <at>  kern/vfs_subr.c:2137
Dec  7 21:15:41 laptop kernel: KDB: stack backtrace:
Dec  7 21:15:41 laptop kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00787923e0
Dec  7 21:15:41 laptop kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0078792490
Dec  7 21:15:41 laptop kernel: witness_checkorder() at witness_checkorder+0xdc2/frame 0xfffffe0078792520
Dec  7 21:15:41 laptop kernel: __lockmgr_args() at __lockmgr_args+0x9ea/frame 0xfffffe0078792660
Dec  7 21:15:41 laptop kernel: ffs_lock() at ffs_lock+0x84/frame 0xfffffe00787926b0
Dec  7 21:15:41 laptop kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xd9/frame 0xfffffe00787926e0
Dec  7 21:15:41 laptop kernel: _vn_lock() at _vn_lock+0xaa/frame 0xfffffe0078792750
Dec  7 21:15:41 laptop kernel: vget() at vget+0x67/frame 0xfffffe0078792790
Dec  7 21:15:41 laptop kernel: vfs_hash_get() at vfs_hash_get+0xe1/frame 0xfffffe00787927e0
Dec  7 21:15:41 laptop kernel: ffs_vgetf() at ffs_vgetf+0x40/frame 0xfffffe0078792870
Dec  7 21:15:41 laptop kernel: softdep_sync_buf() at softdep_sync_buf+0xac0/frame 0xfffffe0078792950
Dec  7 21:15:41 laptop kernel: ffs_syncvnode() at ffs_syncvnode+0x286/frame 0xfffffe00787929d0
Dec  7 21:15:41 laptop kernel: ffs_fsync() at ffs_fsync+0x20/frame 0xfffffe0078792a00
Dec  7 21:15:41 laptop kernel: VOP_FSYNC_APV() at VOP_FSYNC_APV+0xd1/frame 0xfffffe0078792a30
Dec  7 21:15:41 laptop kernel: sys_fsync() at sys_fsync+0x144/frame 0xfffffe0078792aa0
Dec  7 21:15:41 laptop kernel: amd64_syscall() at amd64_syscall+0x216/frame 0xfffffe0078792bb0
Dec  7 21:15:41 laptop kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0078792bb0
Dec  7 21:15:41 laptop kernel: --- syscall (95, FreeBSD ELF64, sys_fsync), rip = 0x80128e66a, rsp =
(Continue reading)

Wojciech Puchar | 7 Dec 10:40 2014

10.1-STABLE one week old from svn - random hangs

i have a problem with FreeBSD-10.

To make it more probable one have to

1) reduce maxbcache. eg

in loader.conf

but NOT doing this doesn't make problem disappear. it is just more rare.

2) use swap. But you don't need system that swaps heavily. Probably - it 
may not swap at all.

3) do lots of I/O

4) it is more often if you use virtualbox, but still - it is not required, 
just make problem more common.

The problem. At random moment system I/O stops. If you are running top at 
this moment, there are lots of prosesses stalled in vnread or biord. 
network keeps running, processes that doesn't need I/O still runs.

top often reports at least 10MB free memory.

seems like a deadlock. Anyone know that problem. How to trace it down?
freebsd-hackers <at> mailing list
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at>"
(Continue reading)