Lars | 29 Mar 21:29 2015

Is a high witness refcount indicative of a missing unlock?

I am poking around for a cause for my repeating deadlock issues on my system based on r 279869. ddb show
witness show the “vnode interlock” and the “zfs” locks both with reference counts over 200K.
Obviously they are related, and there is a find running (all the filesystems on this machine are zfs ( minus
the specialty ones like devfs).

I don’t see any other withness entry with reference counts even in the ballpark of these two, so does this
indicate that we have a vnode/zfs path were we don’t unlock?

freebsd-current <at> mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at>"
jenkins-admin | 29 Mar 10:12 2015

Build failed in Jenkins: Build-UFS-image #1450

See <>

Started by upstream project "Build_Image_and_Run_Tests_in_Bhyve_HEAD" build number 949
originally caused by:
 Started by upstream project "FreeBSD_HEAD" build number 2606
 originally caused by:
  Started by an SCM change
Building remotely on (FreeBSD-10) in workspace <>
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url # timeout=10
Fetching upstream changes from
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from
	at hudson.plugins.git.GitSCM.fetchFrom(
	at hudson.plugins.git.GitSCM.retrieveChanges(
	at hudson.plugins.git.GitSCM.checkout(
	at hudson.scm.SCM.checkout(
	at hudson.model.AbstractProject.checkout(
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(
	at jenkins.scm.SCMCheckoutStrategy.checkout(
	at hudson.model.AbstractBuild$
	at hudson.model.Run.execute(
	at hudson.model.ResourceController.execute(
Caused by: hudson.plugins.git.GitException: Command "git -c core.askpass=true fetch --tags
(Continue reading)

bsdml | 29 Mar 01:34 2015

T40 bootloop on CAM status: Command timeout on both 10.1 and -CURRENT

Hello guys,

since I tried to install FreeBSD 10.1 on my recently purchased T40 I got 
stuck at this annoying bootloop that says
"ATAPY_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 etc etc.. CAM status: 
Command timeout". I have also tried latest 11-CURRENT snapshot and it 
did not make any difference at all, it is affected from the same exact 

I use to boot the kernel and installation image from PXE, however did 
try from usb and didn't make any difference, the bootloop goes on forever.

I did a bunch of researches on Google and somebody suggested to boot 
with hint.achci.0.msi="0" or with hw.achi.force="1" but again it did not 
make any difference.

It seems like there might be an issue with the CAM ATA stack that is 
clashing with the PATA controller on my T40.

Interestingly enough, I did try to remove the cdrom drive and boot the 
installation image with no cd drive installed. However in this case the 
kernel hangs and seat endlessly on the usb controller detection, it does 
not progress or give out any logs past the usb controller recognition.

Unfortunately at the time being it seems like I am stuck with 10 
release, hopefully someone will eventually address this issue so that my 
T40 can see the light again :) .

Here's the link to the picture that showcase the bootloop.

(Continue reading)

Manfred Antar | 28 Mar 23:59 2015

Re: Panic on current amd64

At 03:06 PM 3/28/2015, Davide Italiano wrote:
>On Sat, Mar 28, 2015 at 3:02 PM, Manfred Antar <null <at>> wrote:
>> I get the following panic on current svn ver  r280793:
>Revert to r280784. This should fix.

That works 

||      null <at>           ||
||                                      ||

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

Manfred Antar | 28 Mar 23:02 2015

Panic on current amd64

I get the following panic on current svn ver  r280793:

Sat Mar 28 14:41:28 PDT 2015

FreeBSD/amd64 ( (ttyu0)

login: panic: Invalid CPU in callout 16
cpuid = 2
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe023705f370
panic() at panic+0x1c1/frame 0xfffffe023705f430
callout_reset_sbt_on() at callout_reset_sbt_on+0x3cc/frame 0xfffffe023705f4b0
nv_start_rc_timer() at nv_start_rc_timer+0x5b/frame 0xfffffe023705f4e0
_nv000780rm() at _nv000780rm+0x52c/frame 0xfffffe0001e8af88
dmapbase() at 0xfffff800b78c7000/frame 0xfffffe0001f18000
uart_sab82532_class() at 0/frame 0xfffffe0001e7b000
dmapbase() at 0xfffff800703a6500/frame 0xfffffe0001f1c000
(null)() at 0xfffff801f8ed6000/frame 0xfffffe0001f26000
uart_sab82532_class() at 0/frame 0xfffff801f8dbd000
uart_sab82532_class() at 0/frame 0xfffff8000f758800
uart_sab82532_class() at 0/frame 0xfffff801f8cac000
dmapbase() at 0xfffff8000f838400/frame 0xfffff800700b8800
uart_sab82532_class() at 0/frame 0xfffff8000f838000
uart_sab82532_class() at 0/frame 0xfffffe0001f3a000
uart_sab82532_class() at 0/frame 0xfffffe0001f3e000
uart_sab82532_class() at 0/frame 0xfffffe0001d5b000
dmapbase() at 0xfffff800703aaa00/frame 0xfffffe0001f40000
uart_sab82532_class() at 0/frame 0xfffffe0001f42000
uart_sab82532_class() at 0/frame 0xfffff8000f760000
dmapbase() at 0xfffff8000f867000/frame 0xfffff801f8cb3000
(Continue reading)

jenkins-admin | 28 Mar 18:34 2015

Build failed in Jenkins: FreeBSD_HEAD-tests2 #904

See <>

[...truncated 2881 lines...]
local/atf/atf-c++/utils_test:copy_file__some_contents  ->  passed  [0.020s]
local/atf/atf-c++/utils_test:create_file  ->  passed  [0.018s]
local/atf/atf-c++/utils_test:file_exists  ->  passed  [0.019s]
local/atf/atf-c++/utils_test:fork  ->  passed  [0.023s]
local/atf/atf-c++/utils_test:grep_collection__set  ->  passed  [0.019s]
local/atf/atf-c++/utils_test:grep_collection__vector  ->  passed  [0.019s]
local/atf/atf-c++/utils_test:grep_file  ->  passed  [0.021s]
local/atf/atf-c++/utils_test:grep_string  ->  passed  [0.018s]
local/atf/atf-c++/utils_test:redirect__other  ->  passed  [0.018s]
local/atf/atf-c++/utils_test:redirect__stderr  ->  passed  [0.019s]
local/atf/atf-c++/utils_test:redirect__stdout  ->  passed  [0.020s]
local/atf/atf-c++/utils_test:wait__invalid_exitstatus  ->  passed  [0.025s]
local/atf/atf-c++/utils_test:wait__invalid_stderr  ->  passed  [0.025s]
local/atf/atf-c++/utils_test:wait__invalid_stdout  ->  passed  [0.025s]
local/atf/atf-c++/utils_test:wait__ok  ->  passed  [0.025s]
local/atf/atf-c++/utils_test:wait__ok_nested  ->  passed  [0.028s]
local/atf/atf-c++/utils_test:wait__save_stderr  ->  passed  [0.026s]
local/atf/atf-c++/utils_test:wait__save_stdout  ->  passed  [0.025s]
local/atf/atf-c++/detail/application_test:getopt  ->  passed  [0.019s]
local/atf/atf-c++/detail/auto_array_test:auto_array_access  ->  passed  [0.018s]
local/atf/atf-c++/detail/auto_array_test:auto_array_assign  ->  passed  [0.018s]
local/atf/atf-c++/detail/auto_array_test:auto_array_assign_ref  ->  passed  [0.021s]
local/atf/atf-c++/detail/auto_array_test:auto_array_copy  ->  passed  [0.017s]
local/atf/atf-c++/detail/auto_array_test:auto_array_copy_ref  ->  passed  [0.018s]
local/atf/atf-c++/detail/auto_array_test:auto_array_get  ->  passed  [0.019s]
local/atf/atf-c++/detail/auto_array_test:auto_array_release  ->  passed  [0.016s]
(Continue reading)

Damian Weber | 28 Mar 15:06 2015

umass, Verbatim STORE N GO drive, CAM status 0x50

Dear all,

on a 11-current system I tried a VERBATIM usb drive which does
not produce a /dev/da... entry. My question is whether this can
be fixed by adding an entry in some array within the kernel source
(header files?) or is this bad hardware for which a workaround 
implementation is needed.

system is 
FreeBSD 11.0-CURRENT (VENUS) #0 r280370: Mon Mar 23 22:14:14 CET 2015

relevant dmesg entries when inserting the drive:

umass0: <Verbatim STORE N GO, class 0/0, rev 2.10/1.00, addr 2> on usbus2
umass0:  SCSI over Bulk-Only; quirks = 0x8100
umass0:4:0: Attached to scbus4
(probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00 
(probe0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed
(probe0:umass-sim0:0:0:0): Error 5, Unretryable error
(da0:umass-sim0:0:0:0): got CAM status 0x50
(da0:umass-sim0:0:0:0): fatal error, failed to attach to device

the device gets recognized as ugen2.2 as seen by the timestamp below
# ls -ld ug*

lrwxr-xr-x  1 root  wheel  9 Mar 28 13:41 ugen0.1 <at>  -> usb/0.1.0
lrwxr-xr-x  1 root  wheel  9 Mar 28 13:41 ugen1.1 <at>  -> usb/1.1.0
lrwxr-xr-x  1 root  wheel  9 Mar 28 13:41 ugen2.1 <at>  -> usb/2.1.0
lrwxr-xr-x  1 root  wheel  9 Mar 28 13:44 ugen2.2 <at>  -> usb/2.2.0
(Continue reading)

Piotr Kubaj | 28 Mar 11:44 2015

Libreboot X200 and FreeBSD

I want to buy a Libreboot X200 notebook, however, I also want to use it
with FreeBSD. I'm not sure if that works, so I asked Gluglug directly
and got the following response:

>I'm given the impression that text-mode graphics initialization used
>to work on the X200, but was broken by a later commit. A bisect might
><phcoder-screen> fchmmr: if it uses vbt or bios calls, it won't
><phcoder-screen> fchmmr: first one should work, but FreeBSD works
>only in text mode
>Text-mode is currently broken on the X200. VBT or "fake VBT" is
>currently lacking in the coreboot port for X200 ("VBT calls"), and
>lacks INT 10H video services ("BIOS calls").
>I'm not sure if FreeBSD will work correctly or not. It should work
>if you use the Video BIOS extracted from the original firmware
>(libreboot won't use or recommend this, because it's proprietary;
>instead, it uses a free but incomplete implementation called
>"native graphics initialization").

Can some FreeBSD developers make a statement on this topic? If it
doesn't work, then I can test some patches, if someone writes them, but
I'm a sysadmin, not a programmer, so I'm not really able to write some code.
freebsd-current <at> mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscribe <at>"

(Continue reading)

Lars | 28 Mar 00:32 2015

locking issue between igmp and route code in current?

I realized that I hadn’t copied the other half of the locking issue mentioned earlier..


Mon Mar 23 12:42:15 CDT 2015
lock order reversal:
 1st 0xfffff80003d62190 if_addr_lock (if_addr_lock)  <at>  /u/lars/sandbox/builds/current_10032015/sys/netinet/igmp.c:1714
 2nd 0xffffffff80e387b0 ifnet_rw (ifnet_rw)  <at>  /u/lars/sandbox/builds/current_10032015/sys/net/if.c:243
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0043faf6f0
witness_checkorder() at witness_checkorder+0xbe7/frame 0xfffffe0043faf780
__rw_rlock() at __rw_rlock+0x5a/frame 0xfffffe0043faf820
ifnet_byindex() at ifnet_byindex+0x22/frame 0xfffffe0043faf840
igmp_intr() at igmp_intr+0x1d/frame 0xfffffe0043faf8c0
netisr_dispatch_src() at netisr_dispatch_src+0x61/frame 0xfffffe0043faf930
igmp_v1v2_queue_report() at igmp_v1v2_queue_report+0x14b/frame 0xfffffe0043faf980
igmp_fasttimo() at igmp_fasttimo+0x381/frame 0xfffffe0043fafa30
pffasttimo() at pffasttimo+0x54/frame 0xfffffe0043fafa60
softclock_call_cc() at softclock_call_cc+0x165/frame 0xfffffe0043fafb20
softclock() at softclock+0x3d/frame 0xfffffe0043fafb40
intr_event_execute_handlers() at intr_event_execute_handlers+0xb1/frame 0xfffffe0043fafb70
ithread_loop() at ithread_loop+0x9c/frame 0xfffffe0043fafbb0
fork_exit() at fork_exit+0x71/frame 0xfffffe0043fafbf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0043fafbf0
--- trap 0, rip = 0, rsp = 0xfffffe0043fafcb0, rbp = 0 ---
lock order reversal:
 1st 0xfffff80003d62190 if_addr_lock (if_addr_lock)  <at>  /u/lars/sandbox/builds/current_10032015/sys/netinet/igmp.c:1714
 2nd 0xfffff800090d7be0 radix node head (radix node head)  <at>  /u/lars/sandbox/builds/current_10032015/sys/net/route.c:415
KDB: stack backtrace:
(Continue reading)

Lars | 27 Mar 21:37 2015

locking issue between igmp and route code in current?

I noticed the following checkins to route.c in current, and was wondering if they have barring on the
deadlock documented below:

Revision 274589 <> - (view
(download <>)
(annotate <>) - [select
for diffs]
Modified Sun Nov 16 18:15:23 2014 UTC (4 months, 1 week ago) by melifaro 
File length: 46990 byte(s) 
Diff to previous 274585 <>
Revert r274585 <>: rte lock is
properly destroyed in uma dtor callback.

Pointed by:	glebius

 <>Revision 274585 <> - (view
(download <>)
(annotate <>) - [select
for diffs]
Modified Sun Nov 16 14:56:31 2014 UTC (4 months, 1 week ago) by melifaro 
File length: 47013 byte(s) 
Diff to previous 274187 <>
Make witness happy: destroy rte lock before free.

MFC after:	2 weeks
(Continue reading)

Eric van Gyzen | 27 Mar 20:26 2015

SSE in libthr

In a nutshell:

Clang emits SSE instructions on amd64 in the common path of
pthread_mutex_unlock.  This reduces performance by a non-trivial amount.  I'd
like to disable SSE in libthr.

In more detail:

In libthr/thread/thr_mutex.c, we find the following:

	#define MUTEX_INIT_LINK(m)              do {            \
	        (m)->m_qe.tqe_prev = NULL;                      \
	        (m)->m_qe.tqe_next = NULL;                      \
	} while (0)

In 9.1, clang 3.1 emits two ordinary mov instructions:

	movq   $0x0,0x8(%rax)
	movq   $0x0,(%rax)

Since 10.0 and clang 3.3, clang emits these SSE instructions:

	xorps  %xmm0,%xmm0
	movups %xmm0,(%rax)

Although these look harmless enough, using the FPU can reduce performance by
incurring extra overhead due to context-switching the FPU state.

As I mentioned, this code is used in the common path of pthread_mutex_unlock.  I
have a simple test program that creates four threads, all contending for a
(Continue reading)