Larry Baird | 1 Oct 05:15 2014

Kernel/Compiler bug

I have run into a compiler optimization bug with clang version 3.4.1 and
"-O0" when compiling a 10.1 i386 kernel. When debugging kernels using kgbd I
like to disable compiler optimization.  I have been fighting a kernel double
fault bug for a while.  I thought is was a modification I had made.  Today I
finally stumbled upon the fact that it is a compiler lack of optimization
bug. (-:

It is easy to duplicate the issue with a GENERIC kernel and 10.1-BETA3.
Edit /sys/conf/ changing first _MINUS_O to '-O0'.

--- /sys/conf/       2014-09-26 06:33:38.000000000 -0400
+++ 2014-09-30 22:59:51.000000000 -0400
 <at>  <at>  -26,7 +26,7  <at>  <at> 
 SIZE?=         size

 .if defined(DEBUG)
-_MINUS_O=      -O
+_MINUS_O=      -O0
 CTFFLAGS+=     -g
 .if ${MACHINE_CPUARCH} == "powerpc"

Build GENERIC as usual and you will get a double faulting kernel. 
Should this be reported as a FreeBSD kernel bug or as a clang optimization bug?

To get a backtrace I created a kernel conf file called GDB containing:

include GENERIC
options KDB
options KDB_TRACE
(Continue reading)

Pokala, Ravi | 1 Oct 00:53 2014

dumpsys/savecore on AF-4Kn drives?

Hi folks,

Does anyone out there have AF-4Kn drives (both logical and physical sector
size is 4KB)? Have you been able to drop a core to one, and successfully
save the core on the way back up?

I'm working on adding AF-4Kn support to an older version of FreeBSD (based
on 7 - yeah, I know... :-P), using -CURRENT as a reference. Things look
good at the GEOM level and higher; the GEOM utils report correct sizes,
UFS runs fine, etc. If I manually break into the debugger and 'call
doadump', it appears to work; at least, it does not report any errors. But
when I reboot, `savecore' complains:

    error reading dump header at offset 0 in /dev/mirror/gm1: Invalid

(Yes, it's dumping to a mirror; no, that's not the problem: the mirror is
configured using the 'prefer' balancing algorithm, as described in
gmirror(8), and we've been doing this without issue for years.)

I'm trying to figure out if the problem is on the dumpsys side, the
savecore side, or if they're both broken for AF-4Kn. In particular,
'struct kerneldumpheader' is 512 bytes, and it looks like most calls to
dump_write() in the full-dump context (not minidumps) pass either the size
of the structure, or an explicit 512, for the 'length' argument. That's
the case in both the 7-ish version I'm porting to, and in -CURRENT.

There's no AF-4Kn-aware bootstrap in the version we're using (emaste <at>  -
does the new UEFI bootstrap in 10-STABLE work w/ AF-4Kn drives?), so one
of the drives is 512n, and I could probably find some space on there to
(Continue reading)

Andriy Gapon | 30 Sep 13:18 2014

uk_slabsize, uk_ppera, uk_ipers, uk_pages

I have a hard time understanding how to use uk_slabsize, uk_ppera, uk_ipers,
uk_pages to derive other useful characteristics of UMA kegs.  This is despite
the good descriptions of the fields and multiple examples of their usage in the
code.  Unfortunately, I find those examples to be at least inconsistent and
possibly contradictory.

First problem is quite obvious.  uk_slabsize has a too narrow type.  For
example, ZFS creates many zones with item sizes larger than 64KB.  So,
obviously, uk_slabsize overflows.  Not sure how that affects further
calculation, if any, but probably not in a good way.
On the other hand, there is probably no harm at all, because as far as I can see
uk_slabsize is actually used only within keg_small_init().  It is set but not
used in keg_large_init() and keg_cachespread_init().  It does not seem to be
used after initialization.  So, maybe this field could be just converted to a
local variable in keg_small_init() ?

Now a second problem.  Even the names uk_ppera (pages per allocation) and
uk_ipers (items per slab) leave some room for ambiguity.  What is a relation
between the allocation and the slab?  It seems that some code assumes that the
slab takes the whole allocation (that is, one slab per allocation), other code
places multiple slabs into a single allocation, while other code looks
inconsistent in this respect.

For instance:
static void
keg_drain(uma_keg_t keg)
                LIST_REMOVE(slab, us_link);
(Continue reading)

Anton Shterenlikht | 30 Sep 10:45 2014

cluster FS?


Not sure if this is the right list...
I wanted to ask about a cluster file system.
Is there something like this on FreeBSD?

It seems to me (just from reading the handbook)
that none of NFS, HAST or iSCSI provide this.

My specific needs are as follows.
I have multiple nodes and a disk array.
Each node is connected by fibre to the disk array.
I want to have each node read/write access
to all disks on disk array.
So that if any node fails, the
data is still accessible
via the remaining nodes.

I want to have all nodes equal, i.e. no master/slave
or server/client model. Also, the disk array
provides adequate RAID already, so that is not
needed either.

In the archives I see that the demands for
a cluster FS support on FreeBSD have been expressed
periodically over a very long time, but seems
there's never been any resolution.
Some people mention GFS, but I've no idea
if this what I'm trying to describe.

(Continue reading)

Shrikanth Kamath | 30 Sep 10:44 2014

Textdump capture not generating "ddb.txt" when scripted via ddb utility

I am trying to experiment with text dumps, and using the ddb utility
to script the necessary capture information when a panic is triggered.
The problem I am seeing is that ddb.txt is not getting generated as
the ddb capture is not set on when invoked via ddb utility.

I am doing the following

% /sbin/ddb script kdb.enter.panic="textdump set; capture on; show
pcpu; bt; ps; alltrace; capture off; reset"
% sysctl debug.ddb.textdump.pending=1
debug.ddb.textdump.pending: 0 -> 1

I drop to the debugger and trigger a panic, which promptly generates
the text dump but is creating only the following text files

%tar -xvf textdump.tar.1
x msgbuf.txt
x panic.txt
x version.txt

The ddb.txt is not generated. But if I drop to the debugger and do the
following after doing the above scripting,

db> capture on
db>show allpcpu
db>capture off

I am able to see the ddb.txt after triggering panic.

Question is why is /sbin/ddb script not effecting "capture on" when
(Continue reading)

Bryan Venteicher | 28 Sep 02:59 2014

Change uma_mtx to rwlock


I'd appreciate some comments attached patch that changes the uma_mtx to a

At $JOB, we have machines with ~400GB RAM, with much of that being
allocated through UMA zones. We've observed that timeouts were sometimes
unexpectedly delayed by a half second or more. We tracked one of the
reasons for this down to when the page daemon was running, calling
uma_reclaim() -> zone_foreach(). zone_foreach() holds the uma_mtx while
zone_drain()'ing each zone. If uma_timeout() fires, it will block on the
uma_mtx when it tries to zone_timeout() each zone.
freebsd-hackers <at> mailing list
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at>"
Jin Guojun | 27 Sep 22:53 2014

Inproper ada# assignment in 10-BETA2

Installed 10-BETA2 on SATA port 4 (ad8) and then added another SATA port 3 (ad6), the system has not
correctly enumerate the ada # for the boot device.
As original boot (without the second SATA drive), the ad8 is enumerated as ada0 -- the boot drive:

Sep 24 22:51:30 R10-B2 kernel: ada0 at ahcich2 bus 0 scbus2 target 0 lun 0
Sep 24 22:51:30 R10-B2 kernel: ada0: <Hitachi HDP725050GLA360 GM4OA50E> ATA-8 SATA 2.x device
Sep 24 22:51:30 R10-B2 kernel: ada0: Previously was known as ad8

However, after added another SATA drive (ad6), this new drive is assigned to ada0, but ad8 has changed to
ada1. This is incorrect dynamic device assignment. FreeBSD has kept using fixed disk ID assignment due to
the same problem introduced in around 4-R (or may be slightly later), and after a simple debate, a decision
was made to use fixed drive ID to avoid such hassle.

If now we want to use dynamic enumeration for drive ID# assignment, this has to be done correctly -- boot
drive MUST assigned to 0 or whatever the # as installation assigned to; otherwise, adding a new drive will
cause system not bootable, or make other existing drive not mountable due to enumeration # changes.

Has this been reported as a known problem for 10-R, or shall I open a bug to track?

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

btw | 26 Sep 16:51 2014

Questions with the in_cksumdata() function in sys/amd64/amd64/in_cksum.c

Hi All,

I'm reading the in_cksumdata() function in sys/amd64/amd64/in_cksum.c, and
I have some questions with the following comment and code:

static u_int64_t
in_cksumdata(const void *buf, int len)

         * access prefilling to start load of next cache line.
         * then add current cache line
         * save result of prefilling for loop iteration.
        prefilled = lw[0];
        while ((len -= 32) >= 4) {
                u_int64_t prefilling = lw[8];
                sum += prefilled + lw[1] + lw[2] + lw[3]
                        + lw[4] + lw[5] + lw[6] + lw[7];
                lw += 8;
                prefilled = prefilling;


It said that it adds the current cache line, and it adds 32 bytes actually,
while on amd64 platform, the size of each cache line is 64 bytes. So I think
the correct code should be something like this:
(Continue reading)

Joe Nosay | 25 Sep 06:31 2014

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

suresh gumpula | 21 Sep 21:28 2014

stack size rlimit

    I am experimenting the RLIMIT_INFINITY for RLIMIT_STACK and I observed
that we set to maximize(512M) .
Looking at kern_setrlimit()  , it seems we are checking this condition and
reseting to maxssize

While reading through the "design and implementation of freebsd" book , I
came across a point that we map the shared libraries just below the stack
limit.  But looking at sample map of curproc, I don't see shared libraries
just below the stack limit.

in linux , we have two different address map layouts , one is  traditional
layout which maps shared libraries somewhere in the middle and the other
one which maps just below the stack limit.
And it seems by default, it  prefers the flexible layout.

Can somebody please confirm freebsd layout convention. ?
This is what I see on freebsd, does not look like its starting below the

% cat /proc/curproc/map
0x400000 0x403000 3 0 0xffffff0003711d80 r-x 1 0 0x1000 COW NC vnode
/bin/cat NCH -1
0x602000 0x800000 1 0 0xffffff014816aa20 rw- 1 0 0x3000 NCOW NNC default -
CH 1002
0x800602000 0x800638000 34 0 0xffffff0003661ca8 r-x 81 40 0x1004 COW NC
vnode /libexec/ NCH -1
0x800638000 0x800640000 7 0 0xffffff0147f2ee58 rw- 1 0 0x3000 NCOW NNC
default - CH 1002
0x800837000 0x80083b000 4 0 0xffffff0156ec0000 rw- 1 0 0x3000 COW NNC vnode
(Continue reading)

btw | 20 Sep 09:07 2014

What's the difference between kmem_arena and kernel_arena?

Hi All,

There are two similar variables declared in vm/vm_kern.h, they are kernel_arena
and kmem_arena. Both of them are used in kmem_malloc():

        rv = kmem_back((vmem == kmem_arena) ? kmem_object : kernel_object,

I'm wondering what's the difference between them. Why both of them are needed?
I have done a lot of searching, but I still can not find an answer.

Thanks in advance!

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