Ticket #19988 (awaitsfeedback defect)

Opened 22 months ago

Last modified 17 months ago

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



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.

Kind regards Georgi


VBox.log Download (189.6 KB) - added by Georgi 22 months ago.
The log file
VBox-vanished.log Download (82.9 KB) - added by Georgi 22 months ago.

Change History

comment:1 Changed 22 months ago by paulson

  • Status changed from new to awaitsfeedback

One of the key steps in filing a new bug is including a VBox.log file (as mentioned on the 'Create New Ticket' page: 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?

Changed 22 months ago by Georgi

The log file

comment:2 Changed 22 months ago by Georgi

The log file is attached.

comment:3 Changed 22 months ago by janitor

Is that a log file collected at the time of the malfunction?

comment:4 Changed 22 months ago by Georgi

Yes. I'm attaching another log file from today. The VM's window vanished.

Changed 22 months ago by Georgi

comment:5 Changed 22 months ago by paulson

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.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!RTAssertMsg2V+0x1f4 (rva:0x16fe4c)
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:

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:

The VirtualBox documentation regarding the 'host I/O cache' is here:

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 Changed 22 months ago by Georgi

Hi paulson,

thanks for the explanation but I had no such problem with Linux host and prior versions of VirtualBox.

comment:7 Changed 17 months ago by grahamperrin

Cc: grahamperrin

Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use