kern/153511: kernel panic when xen disk is detached

Colin Percival cperciva at
Wed Dec 29 05:40:11 UTC 2010

>Number:         153511
>Category:       kern
>Synopsis:       kernel panic when xen disk is detached
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Dec 29 05:40:10 UTC 2010
>Originator:     Colin Percival
>Release:        FreeBSD 9.0-CURRENT i386/XEN

FreeBSD 9.0-CURRENT @ 2010-12-28 i386/XEN running in EC2.


Attaching a new disk to a running FreeBSD instance works fine:

xbd2: 1024MB <Virtual Block Device> at device/vbd/2128 on xenbusb_front0
xbd2: attaching as da5
GEOM: new disk da5

but detaching it causes a panic:

Kernel page fault with the following non-sleepable locks held:
exclusive sleep mutex intr sources (intr sources) r = 0 (0xc0576b00) locked @ /usr/src/sys/i386/i386/intr_machdep.c:190

KDB: stack backtrace:
X_db_sym_numargs(c037e9b5,c0117cd0,c273aa0c,a,c273aa48,...) at X_db_sym_numargs+0x146
kdb_backtrace(be,1,ffffffff,c0536fc4,c273aa9c,...) at kdb_backtrace+0x2a
witness_display_spinlock(c038106f,c273aab0,4,1,0,...) at witness_display_spinlock+0x75
witness_warn(5,0,c03aaea4,c0893888,c03f2de0,...) at witness_warn+0x1fe
trap(c273ab34) at trap+0x16a
alltraps(c2adf000,c2d028b8,c273abcc,c031e15d,88,...) at alltraps+0x1b
unbind_from_irqhandler(88,c03e0780,c03a421c,4e1,c2ae3ef4,...) at unbind_from_irqhandler+0x21
balloon_update_driver_allowance(c2d53100,c296d060,c03bc02c,a6e,c2d53100,...) at balloon_update_driver_allowance+0x94d
device_detach(c2d53100,c2adfa80,c2adfa80,c2d53100,c273ac24,...) at device_detach+0x8c
device_delete_child(c2960400,c2d53100,c2d53100,c2960400,c,...) at device_delete_child+0x35
xenbusb_identify(0,c2990530,c038477a,c273ac60,8,...) at xenbusb_identify+0xa7
xenbusb_add_device(c03f49b0,0,c03a3a97,1c0,c273acc4,...) at xenbusb_add_device+0x604
xenbusb_attach(c2960400,1,c03802df,f1,c2987858,...) at xenbusb_attach+0x192
taskqueue_thread_enqueue(c2987840,c2987858,0,c0370aea,0,...) at taskqueue_thread_enqueue+0x12b
taskqueue_thread_loop(c0408708,c273ad28,c0376a5f,35b,c03f2de0,...) at taskqueue_thread_loop+0x67
fork_exit(c01211e0,c0408708,c273ad28) at fork_exit+0xb8
fork_trampoline() at fork_trampoline+0x8
--- trap 0, eip = 0, esp = 0xc273ad60, ebp = 0 ---

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address	= 0x0
fault code		= supervisor read, page not present
instruction pointer	= 0x21:0x0
stack pointer	        = 0x29:0xc273ab74
frame pointer	        = 0x29:0xc273ab94
code segment		= base 0x0, limit 0xf9800, type 0x1b
			= DPL 1, pres 1, def32 1, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= 0 (thread taskq)
trap number		= 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
X_db_sym_numargs(c037e9b5,c298c000,c273aa18,c01177cb,c037b930,...) at X_db_sym_numargs+0x146
kdb_backtrace(c037b930,0,c036d3a5,c273aa64,0,...) at kdb_backtrace+0x2a
panic(c036d3a5,c03aaeab,c298c1ac,1,1,...) at panic+0x117
dblfault_handler() at dblfault_handler+0x3c3
--- trap 0x17, eip = 0, esp = 0, ebp = 0 ---
Uptime: 1h43m31
Physical memory: 607 MB
Dumping 53 MB: 38 22 6
Dump complete

Launch a FreeBSD instance in EC2.  Create a new EBS volume.  Attach it
to the instance.  Detach it from the instance.

The presence of unbind_from_irqhandler and the EIP=0 panic makes me
suspect that we're doing something silly like invoking a hanlder
after it has been (re)set to NULL.

More information about the freebsd-bugs mailing list