Opened 4 years ago
Last modified 3 years ago
#19988 awaitsfeedback defect
VM crashes or restarts during package upgrade on FreeBSD guest
Reported by: | Georgi | Owned by: | |
---|---|---|---|
Component: | other | Version: | VirtualBox 6.1.16 |
Keywords: | FreeBSD | Cc: | |
Guest type: | BSD | Host type: | Linux |
Description
Hi,
my host machine is Debian GNU/Linux 10.6 latest and up to date (21 Oct 2020). VirtualBox version is 6.1.16.
I have a FreeBSD guest - FreeBSD 12.1-RELEASE-p10 GENERIC.
When I try to upgrade packages on guest (FreeBSD) the virtual machine restarts or vanishes.
I could not reproduce the issue with previous versions of VirtualBox (6.1.x) or with Linux guest including VirtualBox 6.1.16.
There is a video.
https://www.youtube.com/watch?v=dqjWNC7nPX0
Kind regards Georgi
Attachments (2)
Change History (9)
comment:1 by , 4 years ago
Status: | new → awaitsfeedback |
---|
comment:4 by , 4 years ago
Yes. I'm attaching another log file from today. The VM's window vanished.
by , 4 years ago
Attachment: | VBox-vanished.log added |
---|
comment:5 by , 4 years ago
The VBox-vanished.log does show the following errors indicating that the VM has crashed after triggering an assert():
00:01:23.180640 PIIX3 ATA: Ctl#0: ABORT DMA 00:01:23.180993 PIIX3 ATA: Ctl#0: ABORT DMA 00:01:23.181123 PIIX3 ATA: Ctl#0: ABORT DMA 00:01:23.181258 PIIX3 ATA: Ctl#0: ABORT DMA 00:01:23.181665 PIIX3 IDE: guest issued command 0xca while controller busy 00:01:23.182216 PIIX3 IDE: guest issued command 0xca while controller busy 00:01:23.185993 00:01:23.185994 !!Assertion Failed!! 00:01:23.185994 Expression: ReqType == ATA_AIO_RESET_ASSERTED || ReqType == ATA_AIO_RESET_CLEARED || ReqType == ATA_AIO_ABORT || pCtl->uAsyncIOState == ReqType 00:01:23.185995 Location : /home/vbox/vbox-6.1.16/src/VBox/Devices/Storage/DevATA.cpp(5842) int ataR3AsyncIOThread(RTTHREAD, void*) 00:01:23.186011 Stack : 00:01:23.186011 00007f0745018e4c VBoxRT.so!RTAssertMsg2V+0x1f4 (rva:0x16fe4c) 00:01:23.186011 00:01:23.186028 I/O state inconsistent: state=0 request=1
This same issue seems to have been encountered in ticket #17089 'crash with host on Windows 7 and iSCSI to FreeBSD 11.1' and the submitter there reported the following workaround:
The issue really seems to stem from setting the number of emulated CPUs to 8, where the host CPU is a Core i7 6820HQ.
Setting the number of emulated CPUs to only 4 resolves the issue.
That ticket was closed due to lack of details from the submitter. However, this issue appears to be the same as the one described in open ticket #17721 'VBox crashes under heavy disk IO' which links to a VirtualBox forum discussion where enabling the 'Host I/O cache' for the controller helped them. One of the VirtualBox developers had this comment about enabling the 'Host I/O cache' in the forums from 2011:
https://forums.virtualbox.org/viewtopic.php?t=45245
Re: Why isn't "use host I/O cache" option on by default? Postby aeichner » 4. Nov 2011, 12:20
The host I/O cache is not used by default because it can cause I/O timeouts in the guest if the host faces a high I/O load and the host cache can't cope with it. We encountered this when running I/O benchmarks in several VMs on different host operating systems. The guest will become unusable most of the time. The other reason is that the I/O cache on the host will be trashed with data from the disk image which is unnecessary because the guest uses free RAM for its own cache. Having the host I/O cache enabled can speed up certain I/O operations. Compiling software is one of these operations because it reads a lot of small files.
Some other comments on enabling the 'host I/O cache' can be found here:
https://www.electricmonk.nl/log/2016/03/14/terrible-virtualbox-disk-performance/
The VirtualBox documentation regarding the 'host I/O cache' is here:
https://www.virtualbox.org/manual/ch05.html#iocaching
and it contains some helpful information as well.
In short, perhaps using fewer CPUs is a workaround and experimenting with the 'host I/O cache' setting for the controller may help here.
comment:6 by , 4 years ago
Hi paulson,
thanks for the explanation but I had no such problem with Linux host and prior versions of VirtualBox.
One of the key steps in filing a new bug is including a VBox.log file (as mentioned on the 'Create New Ticket' page: https://www.virtualbox.org/newticket). Without that it's not really possible to start root causing this issue. So can you attach a VBox.log from when this problem occurs?