While VirtualBox 4.1.22 has not been assigned to qa yet,
I have been trying it out.
Host is Mageia 2 x86-64 running 3.3.8-desktop-2.mga2, with
the extension pack installed, and the matching guest additions
in all guests.
First guest was Mageia 2 x86-64, running the 3.3.8-server kernel,
During execution of urpmi, to install a package, the guest system
became unresponsive, with one of the virtualbox threads stuck in
a device wait. The only way to kill the guest was to reboot the
After that, restarting the guest, and then running urpmi recreated
the problem. In the guest, reformatting the virtual drive and
reinstalling the guest os, recreated the problem. The only way
to clear the problem, was to delete/rcreate the .vdi file, and
then reinstall the guest os.
I'm using a dynamically sized vdi file. The host file system where
the vdi file is stored is an ext4 filesystem, on a luks encrypted
partition. The host drive is a ssd drive, with the following mount
options ext4 (rw,noatime,user_xattr,barrier=1,data=ordered,discard).
In the guest setting, the vdi is setup as a sata drive, with the
ssd option checked.
I've now run into the same problem on a Mageia 1 x86-64 guest.
dmesg shows ...
[ 203.645807] EXT4-fs (dm-0): Unaligned AIO/DIO on inode 1708686 by VirtualBox; performance will be poor.
[ 481.367093] INFO: task VirtualBox:17482 blocked for more than 120 seconds.
[ 481.367100] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 481.367107] VirtualBox D 0000000000000000 0 17482 8755 0x00000000
[ 481.367117] ffff88037e825d78 0000000000000082 0000000000000001 ffff880308b02840
[ 481.367128] ffff8803add5da40 ffff88037e825fd8 ffff88037e825fd8 ffff88037e825fd8
[ 481.367137] ffff8804294bda40 ffff8803add5da40 ffff88037e825d88 ffff8803abb9c570
[ 481.367148] Call Trace:
[ 481.367161] [<ffffffff8144fe9f>] schedule+0x3f/0x60
[ 481.367171] [<ffffffff81194d59>] inode_dio_wait+0xb9/0xe0
[ 481.367182] [<ffffffff81071130>] ? autoremove_wake_function+0x40/0x40
[ 481.367251] [<ffffffffa012b128>] ext4_setattr+0x338/0x550 [ext4]
[ 481.367260] [<ffffffff81053756>] ? current_fs_time+0x16/0x60
[ 481.367270] [<ffffffff811785fa>] notify_change+0x1aa/0x340
[ 481.367281] [<ffffffff8115bd4e>] do_truncate+0x5e/0xa0
[ 481.367291] [<ffffffff8115c015>] sys_ftruncate+0xd5/0x120
[ 481.367299] [<ffffffff81458e79>] system_call_fastpath+0x16/0x1b
htop on the host shows ...
85 root 20 0 0 0 0 R 112. 0.0 23:23.31 kworker/u:9
82 root 20 0 0 0 0 S 84.0 0.0 17:40.15 kworker/u:8
17459 dave 20 0 3779M 2210M 2099M S 11.0 13.8 2:50.15 /usr/lib64/virtualbox/VirtualBox --com
I'm not sure if this is a VirtualBox bug, a host kernel bug,
I'll be searching through https://www.virtualbox.org/search?q=ext4&noquickjump=1&ticket=on later, after I reboot again, so
I can check the guest's logs, to see if there is anything useful
Bug reported upstream.
Just fyi. Encountered again during installation of Mageia 3 alpha 2 x86-64.
So far, it only seems to affect 64 bit guest systems.
As the upstream bug has been closed, and I've been avoiding the
possibility of recreating the bug by having moved all of my
virtual hard drives from the sata controller to the ide controller,
I'll close this bug, and open a new one, if I do encounter it