From owner-freebsd-emulation@FreeBSD.ORG Fri Sep 10 10:50:04 2010 Return-Path: Delivered-To: freebsd-emulation@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69B371065674 for ; Fri, 10 Sep 2010 10:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 57A9A8FC19 for ; Fri, 10 Sep 2010 10:50:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o8AAo4Kp099802 for ; Fri, 10 Sep 2010 10:50:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o8AAo4Xm099801; Fri, 10 Sep 2010 10:50:04 GMT (envelope-from gnats) Date: Fri, 10 Sep 2010 10:50:04 GMT Message-Id: <201009101050.o8AAo4Xm099801@freefall.freebsd.org> To: freebsd-emulation@FreeBSD.org From: David Evans Cc: Subject: Re: kern/150186: [parallels] [panic] Parallels Desktop: CDROM disconnected leads to panic, eventually X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Evans List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 10:50:04 -0000 The following reply was made to PR kern/150186; it has been noted by GNATS. From: David Evans To: bug-followup@FreeBSD.org, dave.evans55@googlemail.com Cc: Subject: Re: kern/150186: [parallels] [panic] Parallels Desktop: CDROM disconnected leads to panic, eventually Date: Fri, 10 Sep 2010 11:49:17 +0100 Summary: -------- In a Desktop VM with the CDrom installed, but not connected, and with the hald and dbus daemons running, and running buildworld or background fsck or both, there is a high probability of a panic within a few minutes. After disabling hald and dbus in /etc/rc.conf, I successfully ran make buildworld in a loop 7 times without any problems. This amounts to about 11 hours of runtime. Environment: ------------ Parallels Desktop 5 for Mac build 5.0.9376. A slightly older version was also used. Mac OS X Snow Leopard 10.6.4, 4G of ram, 1G allocated to VM CVS tag RELENG_8 src cvsup'ed at 2010-09-02 22:27 UTC Ports cvsup'ed at 2010-08-31 15:05 UTC Events so far: -------------- My main development VM, known as eight.pearl, has been running for the last five days without the CDROM installed. It has successfully built world, ran a major portupgrade and done a few dump(8)s without any panics. It is far too precious to risk any data corruption, so I made a clone. The cloned VM is known imaginatively as clone8.pearl In clone8.pearl, I installed the CDROM and disconnected it. I then started make buildworld. Within a few minutes there was a panic. I rebooted and tried another buildworld. Again, there was soon another panic. Each panic appeared to be preceeded by a message from /dev/acd0. Fortunately I had enabled dumps (see below). In clone8.pearl I then disabled hald and dbus in /etc/rc.conf. I then ran make buildworld in a loop 7 times overnight. This morning I found the VM was still running. Additional VMs created ---------------------- I created two more VMs: cdpanic.pearl and cam.pearl. Both were the minimum installation from the FreeBSD cdrom 1 of November 2009. I updated the world and kernel from my local sources. No ports were installed. cdpanic.pearl had a standard GENERIC kernel with DDB. cam.pearl also was a standard debugging kernel with option ATA_CAM, as suggested by jh earlier in this bug report. I installed and disconnected the CDrom on both VMs and started a buildworld. Both completed successfully with no panics. hald and dbus ------------- These two ports run as daemons checking the status of devices. hald comes from sysutils/hal. dbus is from devel/dbus. They are the only two daemons I can see that access the CDrom device. I am now convinced they are tickling a bug in the acd device which causes a panic. To trigger the bug you need to run something disk-intensive. make buildworld is good. So is background fsck. The acd0 device needs to report NOT READY status when it is not connected. This is probably a Desktop problem. To Do ----- I must create another clone of eight.pearl and install a CAM kernel on it. Dumps ----- I managed to obtain two dumps. here is the output of dmesg. I realise they are not much use, but I need to hone my kernel debugging skills to get more useful information. Both stopped at the same instruction pointer. ------- ata1: WARNING - READ_TOC read data overrun 18>12 acd0: WARNING - READ_TOC taskqueue timeout - completing request directly Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x1a4 fault code = supervisor read, page not present instruction pointer = 0x20:0xc08a119f stack pointer = 0x28:0xe4521b44 frame pointer = 0x28:0xe4521b5c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi6: task queue) panic: from debugger cpuid = 0 Uptime: 6m0s Physical memory: 1011 MB Dumping 148 MB: 133 117 101 85 69 53 37 21 5 ------------------------- acd0: WARNING - READ_TOC taskqueue timeout - completing request directly Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x1a4 fault code = supervisor read, page not present instruction pointer = 0x20:0xc08a119f stack pointer = 0x28:0xe4521b44 frame pointer = 0x28:0xe4521b5c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi6: task queue) panic: from debugger cpuid = 0 Uptime: 21m2s Physical memory: 1011 MB Dumping 138 MB: 123 107 91 75 59 43 27 11