Opened 11 years ago
Closed 8 years ago
#12375 closed defect (obsolete)
Host crashed after a processor offline
Reported by: | mzprx | Owned by: | |
---|---|---|---|
Component: | other | Version: | VirtualBox 4.3.2 |
Keywords: | Cc: | ||
Guest type: | other | Host type: | Solaris |
Description (last modified by )
I'm running VirtualBox 4.3.2 on this host:
- OS: OpenIndiana 151a8
- CPU: Intel Xeon E3-1240 V2
I had one virtual machine guest running.
Once I ran psradm -f 1
on the host to offline one CPU the machine panicked with this info:
> ::status debugging crash dump vmcore.0 (64-bit) from raven operating system: 5.11 oi_151a8 (i86pc) image uuid: bce29343-bd66-4abc-9670-96f69cb1d15c panic message: BAD TRAP: type=6 (#ud Invalid opcode) rp=ffffff001f36aab0 addr=1 dump content: kernel pages only > ::stack 0xfffffffff822afa4() 0xfffffffff822aae6() 0xfffffffff823d6bb() supdrvIOCtlFast+0x8c() VBoxDrvSolarisIOCtl+0x109() cdev_ioctl+0x45(10e00000002, 200056c1, 1, 202003, ffffff04e462a468, ffffff001f36ae24) spec_ioctl+0x5a(ffffff04e65e5700, 200056c1, 1, 202003, ffffff04e462a468, ffffff001f36ae24) fop_ioctl+0x7b(ffffff04e65e5700, 200056c1, 1, 202003, ffffff04e462a468, ffffff001f36ae24) ioctl+0x18e(12, 200056c1, 1) sys_syscall+0x17a() > ::cpuinfo ID ADDR FLG NRUN BSPL PRI RNRN KRNRN SWITCH THREAD PROC 0 fffffffffbc30640 1f 0 0 -1 no no t-0 ffffff001e005c40 (idle) 1 ffffff04d865e080 2f 0 0 -1 no no t-10 ffffff001e364c40 (idle) 2 ffffff04d8642a80 1f 0 0 59 no no t-0 ffffff04db148ae0 VBoxHeadless 3 ffffff04d8ac8540 1f 0 0 -1 no no t-0 ffffff001e4a2c40 (idle) 4 ffffff04d8ac7040 1f 0 0 -1 no no t-0 ffffff001e852c40 (idle) 5 ffffff04d8ac5080 1f 0 0 -1 no no t-4 ffffff001e454c40 (idle) 6 fffffffffbc3ae50 1b 0 0 59 no no t-0 ffffff04da579bc0 VBoxHeadless 7 ffffff04d8aba540 1f 1 0 -1 no no t-9 ffffff001e97bc40 (idle) >
I'll provide the crash dump file on request.
Attachments (4)
Change History (9)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
Description: | modified (diff) |
---|
comment:3 by , 11 years ago
Last night I had two similar panices:
# ls -al vmdump.* -rw-r--r-- 1 root root 392953856 2013-11-24 03:21 vmdump.1 -rw-r--r-- 1 root root 320471040 2013-11-24 04:04 vmdump.2 #
Now it was not caused by processor offline on the host, so it is possible that guest somehow caused it (there are some weekly cron jobs running on guest approximately during the time when the host panicked).
Here is the panic stack from vmdump.1 (vmdump.2 have the exactly same panic stack):
> ::status debugging crash dump vmcore.1 (64-bit) from raven operating system: 5.11 oi_151a8 (i86pc) image uuid: a7b255ac-d818-e7f7-9d8c-88b0e1f5ab4a panic message: BAD TRAP: type=e (#pf Page fault) rp=ffffff0024979930 addr=28 occurred in module "<unknown>" due to a NULL pointer dereferenc e dump content: kernel pages only > ::stack vpanic() die+0xdd(e, ffffff0024979930, 28, 0) trap+0x17db(ffffff0024979930, 28, 0) 0xfffffffffb8001d6() 0xfffffffff82938db() 0xfffffffff82c1e14() 0xfffffffff82c18a8() 0xfffffffff8240d53() 0xfffffffff82317aa() 0xfffffffff823124b() 0xfffffffff82c3667() 0xfffffffff823c6f5() supdrvIOCtlFast+0x8c() VBoxDrvSolarisIOCtl+0x109() cdev_ioctl+0x45(10e00000002, 200056c1, 1, 202003, ffffff04e52ba190, ffffff0024979e24) spec_ioctl+0x5a(ffffff04e78c8140, 200056c1, 1, 202003, ffffff04e52ba190, ffffff0024979e24) fop_ioctl+0x7b(ffffff04e78c8140, 200056c1, 1, 202003, ffffff04e52ba190, ffffff0024979e24) ioctl+0x18e(12, 200056c1, 1) sys_syscall+0x17a() >
Please find attached all four VBox.log files I found in the Logs directory for the guest machine.
by , 11 years ago
by , 11 years ago
Attachment: | VBox.log.1 added |
---|
by , 11 years ago
Attachment: | VBox.log.2 added |
---|
by , 11 years ago
Attachment: | VBox.log.3 added |
---|
comment:4 by , 11 years ago
I just found that I'm not running 4.3.2, but 4.3.0. Sorry for confusion. I'll upgrade to 4.3.2 to see whether it helps.
comment:5 by , 8 years ago
Resolution: | → obsolete |
---|---|
Status: | new → closed |
Please reopen if still relevant with a recent VirtualBox release.
Could you please attach VBox.log for the VM when the crash happened.