NetBSD Problem Report #42737

From  Thu Feb  4 05:21:43 2010
Return-Path: <>
Received: from ( [])
	by (Postfix) with ESMTP id EBF6E63B886
	for <>; Thu,  4 Feb 2010 05:21:42 +0000 (UTC)
Message-Id: <>
Date: Thu,  4 Feb 2010 05:21:41 +0000 (UTC)
From: Taylor R Campbell <>
Reply-To: Taylor R Campbell <>
Subject: sbp temporary detachment feature causes deadlocks
X-Send-Pr-Version: 3.95

>Number:         42737
>Category:       kern
>Synopsis:       sbp temporary detachment feature causes deadlocks
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Feb 04 05:25:00 +0000 2010
>Last-Modified:  Thu Feb 04 05:40:03 +0000 2010
>Originator:     Taylor R Campbell <>
>Release:        NetBSD 5.0_STABLE
NetBSD ... 5.0_STABLE NetBSD 5.0_STABLE (APPLE_UFS_EI) #2: Fri Jul 31 20:44:51 UTC 2009  riastradh@... i386
Architecture: i386
Machine: i386

	Several days ago, I plugged a FireWire device (specifically, a
	MacBook with a hosed disk, booted into target disk mode) into
	a machine running NetBSD 5.0_STABLE.  I performed various
	diagnostics upon it, and mounted some some file systems from
	it using RUMP, which I fully unmounted before unplugging the
	device.  I did not run `fwctl -r' after unplugging the device,
	however, which apparently one is supposed to do.

	Today, I noticed that I hadn't gotten daily and security
	reports from that machine, which turns out to be because the
	processes generating them are waiting for `disklabel sd0',
	which is hung on a mutex.  I tried running `file -s /dev/sd0a'
	which hung too, unkillably.

	My kernel is configured just like GENERIC with the following
	two options added:

options 	FFS_EI		# FFS Endian Independent support
options 	APPLE_UFS	# Apple UFS support in FFS

	Whether or not I ought to have run `fwctl -r' after unplugging
	the device, NetBSD shouldn't wedge up like this.


	I have not yet attempted to reproduce this; I shall do so once
	I have built a kernel with LOCKDEBUG enabled in order to
	diagnose the problem better in case I can reproduce it.


	I do not yet have a fix, but shall endeavour to seek one once
	I can reproduce the problem and debug the kernel symbolically.

From: Taylor R Campbell <>
Subject: Re: kern/42737: sbp temporary detachment feature causes deadlocks
Date: Thu, 4 Feb 2010 00:35:55 -0500

 Forgot to add: I entered ddb and ran `t/t 0t87' to get a trace for
 process 87, one of the `disklabel sd0' processes, and copied the
 output by hand.  (No doubt I made some errors in transcription.)

 db{0}> t/t 0t87
 trace: pid 87 lid 1 at 0xcbfa19ac
 sleepq_block(0,0,c0a26161,c0a882fc,ca95f4d0,cbfd2458,0,cd4b0a7c,75,40) at n=
 0000020,cd4b0a64) at netbsd:turnstile_block+0x1a5
 f04,3) at netbsd:mutex_vector_enter+0x398
 sdopen(d03,1,2000,cbfd22a0,2000,1,6,d0818e64,cbb94268,0) at netbsd:sdopen+0=
 cdev_open(d03,1,2000,cbfd22a0,4,1a0,0,5,cbfd22a0,d03) at netbsd:cdev_open+0=
 spec_open(cbfa1b88,3,1,c048b237,6,c0826f60,d0818e64,1,d1f05840,0) at netbsd=
 VOP_OPEN(d0818e64,1,d1f05840,1,cc465ba4,0,0,d0818e64,cbfd22a0,d1f05840) at =
 00) at netbsd:vn_open+0x259
 sys_open(cbfd22a0,cbfa1d00,cbfa1d28,8052640,0,64,8052640,0,0,bbbf6983) at n=
 syscall(cbfa1d48,b3,ab,1f,1f,8052640,64,bfbfe948,bbbe68b8,bbbd5840) at netb=

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD:,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.