Date: 29 Dec 2010 05:30:32 -0000 From: Colin Percival <cperciva@FreeBSD.org> To: FreeBSD-gnats-submit@FreeBSD.org Subject: kern/153511: kernel panic when xen disk is detached Message-ID: <20101229053032.8676.qmail@xps.daemonology.net> Resent-Message-ID: <201012290540.oBT5eAkl086479@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 153511 >Category: kern >Synopsis: kernel panic when xen disk is detached >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Dec 29 05:40:10 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Colin Percival >Release: FreeBSD 9.0-CURRENT i386/XEN >Organization: >Environment: FreeBSD 9.0-CURRENT @ 2010-12-28 i386/XEN running in EC2. >Description: 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 >How-To-Repeat: Launch a FreeBSD instance in EC2. Create a new EBS volume. Attach it to the instance. Detach it from the instance. >Fix: 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. >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101229053032.8676.qmail>