Hello Sean, this is a known bug since 3 weeks. Please see more information below.
Solution: Either wait for VirtualBox 2.2.4 or for now take this fix: http://www.virtualbox.org/attachment/ticket/3981/vboxkern_20090513.zip Here comes the original posting where it had been reported on caiman-discuss 3 weeks ago: ---------- Forwarded message ---------- From: Joe Bonasera <[email protected]> To: Thomas Tornblom <[email protected]> Date: Thu, 07 May 2009 11:59:17 -0700 Subject: Re: snv_114 + VirtualBox = toxic Yup.. In nevada 114, the putback of 6565817 sigwait can't wait for SIGTSTP exposed a place in VirtualBox where it didn't use a DDI function, but should have. The fix is in the next maintenance release, 2.2.4, probably about 4 weeks out from now. Until then if you're running virtualbox, stay on build 113. Joe Thomas Tornblom wrote: It appears that snv_114 and VirtualBox, 2.1.4 or 2.2.2, is not a good combination, whether snv_114 is a host or a guest. I've live-upgraded my snv_113/x64 to snv_114, and when I try to start any of the VirtualBox clients, the system panics with this stack: --- SolarisCAT(vmcore.1/11X)> panic panic on cpu 0 panic string: BAD TRAP: type=e (#pf Page fault) rp=ffffff00090d3870 addr=0 occurred in module "unix" due to a NULL pointer dereference ==== panic kernel thread: 0xffffff01d9274760 PID: 0 on CPU: 0 ==== cmd: t_procp: 0xffffff01eae0d790 p_as: 0x0t_stk: 0xffffff00090d3f10 sp: 0xffffff00090d35d0 t_stkbase: 0x0 t_pri: 59(IA) pctcpu: 0.000000 t_lwp: 0x0 address translation failed for cpupart: 320 bytes @ 0xfffffd7ffed74000 bound psrset: -70932208 last CPU: 0 idle: 73680379 ticks (8 days 12 hours 40 minutes 3.79 seconds) start: Sun Apr 26 06:04:08 .*0* age: 1092344788625 seconds (12642879 days 11 hours 57 minutes 5 seconds) tstate: TS_ONPROC - thread is being run on a processor tflg: T_PANIC - thread initiated a system panic T_DFLTSTK - stack is default size tpflg: TP_TWAIT - wait to be freed by lwp_wait TP_MSACCT - collect micro-state accounting information tsched: TS_LOAD - thread is in memory TS_DONT_SWAP - thread/LWP should not be swapped pflag: none set pc: unix:vpanic_common+0x13b: addq $0xf0,%rsp unix:vpanic_common+0x13b() unix:panic+0x94() unix:die+0xdd() unix:trap+0x175f() unix:cmntrap_pushed+0x3d() unix:mutex_enter+0xb() vbi:vbi_user_map+0x56() vboxdrv:rtR0MemObjNativeMapUser+0x105() vboxdrv:RTR0MemObjMapUser+0x188() vboxdrv:SUPR0GipMap+0x157() vboxdrv:supdrvIOCtl+0xee0() vboxdrv:VBoxDrvSolarisIOCtl+0x359() genunix:cdev_ioctl+0x45() specfs:spec_ioctl+0x83() genunix:fop_ioctl+0x7b() genunix:ioctl+0x18e() unix:_syscall_invoke+0x30() -- end of kernel thread's stack -- --- On my fresh MacBook Pro, running VIrtualBox 2.2.2, I successfully installed snv_113, with the vbox guest additions. Today I lu:ed the snv_113 guest to snv_114, and when I boot that, it panics with this stack: --- r...@mbsol[22]> mdb -k 0 mdb: warning: dump is from SunOS 5.11 snv_114; dcmds and macros may not match kernel implementation Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc pcplusmp scsi_vhci zfs sd sockfs ip hook neti sctp arp usba uhci s1394 stmf qlc fctl nca lofs idm md cpc random crypto smbsrv nfs fcip fcp logindmux ptm ufs nsctl sdbc sv ii sppp nsmb rdc ] > $C ffffff00031ef9e0 RTProcSelf+0x17() ffffff00031efa20 VBoxGuestCreateUserSession+0x65() ffffff00031efa80 VBoxGuestSolarisOpen+0xa0() ffffff00031efab0 dev_open+0x3c(ffffff00031efb08, 2003, 2, ffffff0107056308) ffffff00031efb60 spec_open+0x59c(ffffff00031efc40, 2003, ffffff0107056308, 0) ffffff00031efbd0 fop_open+0xbf(ffffff00031efc40, 2003, ffffff0107056308, 0) ffffff00031efd70 vn_openat+0x65d(45c710, 0, 2003, 180, ffffff00031efdb8, 0, 12, 0, 3) ffffff00031efed0 copen+0x418(ffd19553, 45c710, 2003, 180) ffffff00031eff00 open+0x34(45c710, 2002, 180) ffffff00031eff10 sys_syscall+0x17b() --- I'm now back at snv_113 on both systems. Thomas -- %martin On Thu, May 21, 2009 at 5:51 PM, Sean Sprague <[email protected]> wrote: > Hello, > > This panic has occurred on two completely configurations (laptop in > VirtualBox and PC native disk). Basically after the installation of b114 (ZFS > root) has completed, the system will not boot, and panics in vfs_mountroot(). > The image is fine; verified by checksum. > > On the PC installation, what I get is the following (the relevant bits): > > NOTICE: zfs_parse_bootfs: error 2 > > Cannot mount root on rpool/ROOT/53 fstyp zfs > > panic[cpu0]/thread=fffffffffbc2d120: vfs_mountroot cannot mount root > > Then: > > fffffffffbcfeec0: genunix: vfs_mountroot + 350 () > > Sadly thereafter, the keyboard is inactive (KB is directly connected). > > Failsafe boot is fine. Then, I basically booted single-user from the DVD, and > successfully imported rpool. I received the EROFS errors that you would > expect when doing zpool import from booted DVD; and ignored them for the > current purpose. > > Now, on the fail on the laptop with VirtualBox, the problem went away on a > reboot after the boot archive had been updated, so to avoid this, on the PC, > I hit the reset button. Thereafter the system booted fine, and proceeded with > the usual post-installation configuration stuff. > > So basically it looks to me like rpool had been left in a state at the end of > the installation where it was not mountable (exported), and a simple import > of it (whether through a failsafe boot or a single-user boot from DVD) > cleared this state and made it mountable once more. Actually just confirmed > this... booted single-user from DVD again, imported rpool successfully > (ignoring errors), then exported rpool and hit the reset. On next hard disk > boot, received the same vfs_mountroot panic. > > This looks like a bug. Also, any thoughts why there should be no keyboard > input possible to KMDB? > > Thanks and regards... Sean. > -- > This message posted from opensolaris.org > _______________________________________________ > opensolaris-discuss mailing list > [email protected] > _______________________________________________ opensolaris-discuss mailing list [email protected]
