The following reply was made to PR kern/150186; it has been noted by GNATS.
From: David Evans <dave.evan...@googlemail.com>
To: bug-follo...@freebsd.org, dave.evan...@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
_______________________________________________
freebsd-emulation@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-emulation
To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
