Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 17 Nov 2012 22:19:53 +0300
From:      Alex Chistyakov <alexclear@gmail.com>
To:        Marek Salwerowicz <marek_sal@wp.pl>
Cc:        freebsd-emulation@freebsd.org
Subject:   Re: VirtualBox 4.1.22 on FreeBSD 9.0-RELEASE problem: VBoxHeadless eats 100% CPU
Message-ID:  <CA%2Bkq2xsbOh8SQveP9HX1A%2BVdxxGpH=-MhVi%2BCwZZVCuJ4VPqRA@mail.gmail.com>
In-Reply-To: <50A787A6.8050402@wp.pl>
References:  <CA%2Bkq2xvYqbeodg6aL9QRuP%2BMi-b25CVdPUx4JEX9%2Be5Ri21qGg@mail.gmail.com> <50A67D9F.8040505@wp.pl> <CA%2Bkq2xsXjWtoa1nKd22hqQOkf8Tcnxtuf2af_pfDo3i1Bea6sQ@mail.gmail.com> <50A787A6.8050402@wp.pl>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Nov 17, 2012 at 4:48 PM, Marek Salwerowicz <marek_sal@wp.pl> wrote:
> W dniu 2012-11-16 20:28, Alex Chistyakov pisze:
>
>> On Fri, Nov 16, 2012 at 9:53 PM, Marek Salwerowicz <marek_sal@wp.pl>
>> wrote:
>>>
>>> W dniu 2012-11-16 16:22, Alex Chistyakov pisze:
>>>
>>>> Hello,
>>>>
>>>> My system is an amd64 box running FreeBSD 9.0-RELEASE on top of ZFS.
>>>> I try to setup a VirtualBox VM from an Ubuntu 12.04 Server
>>>> installation CD in a headless mode using VNC.
>>>> Top shows that VBoxHeadless process consumes 100% CPU almost all the
>>>> time and it takes forever to boot from the CD image:
>>>>
>>>>     PID USERNAME    THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU
>>>> COMMAND
>>>>    1652 vbox         19  22    0   358M   170M IPRT S  3   7:18 100.00%
>>>> VBoxHeadless
>>>>
>>>> I get lots of repeating "ioctl(7,0x200056c1 { IO 0x56('V'), 193, 0
>>>> },0x0) = 0 (0x0)" lines every time I try to run truss on the running
>>>> VBoxHeadless process, like this:
>>>>
>>>> ioctl(7,0x200056c1 { IO 0x56('V'), 193, 0 },0x0) = 0 (0x0)
>>>> ioctl(7,0x200056c1 { IO 0x56('V'), 193, 0 },0x0) = 0 (0x0)
>>>> ioctl(7,0x200056c1 { IO 0x56('V'), 193, 0 },0x0) = 0 (0x0)
>>>> ioctl(7,0x200056c1 { IO 0x56('V'), 193, 0 },0x0) = 0 (0x0)
>>>> ioctl(7,0x200056c1 { IO 0x56('V'), 193, 0 },0x0) = 0 (0x0)
>>>> ioctl(7,0x200056c1 { IO 0x56('V'), 193, 0 },0x0) = 0 (0x0)
>>>> ioctl(7,0x200056c1 { IO 0x56('V'), 193, 0 },0x0) = 0 (0x0)
>>>> ioctl(7,0x200056c1 { IO 0x56('V'), 193, 0 },0x0) = 0 (0x0)
>>>> ioctl(7,0x200056c1 { IO 0x56('V'), 193, 0 },0x0) = 0 (0x0)
>>>> ioctl(7,0x200056c1 { IO 0x56('V'), 193, 0 },0x0) = 0 (0x0)
>>>> ioctl(7,0x200056c1 { IO 0x56('V'), 193, 0 },0x0) = 0 (0x0)
>>>>
>>>> and it looks like this system call prevails in truss stats:
>>>>
>>>> [root@ci ~]# wc -l truss.vbox.log
>>>>    1174962 truss.vbox.log
>>>> [root@ci ~]# cat truss.vbox.log | grep 'ioctl(7,0x200056c1' | wc -l
>>>>    1013997
>>>> [root@ci ~]#
>>>>
>>>> FD 7 is /dev/vboxdrv0, does this indicate a problem in communicating
>>>> with a kernel VirtualBox driver?
>>>> What should I do to resolve this situation?
>
> I've noticed that in my FreeBSD there is /dev/vboxdrv (not vboxdrv0)
> driver..
> Probably different kernel module versions.?
>
>
>
>
>>> Could you write down the VBoxManage commands you use to create the VM ?
>>
>> Yeah sure:
>>
>> VBoxManage createhd --filename "st11.vdi" --size 30000
>> VBoxManage createvm --name Stage11 --ostype Ubuntu_64 --register
>> VBoxManage modifyvm Stage11 --memory 1024 --boot1 dvd --nic1 bridged
>> --bridgeadapter1 em0
>> VBoxManage storagectl Stage11 --name "SATA Controller" --add sata
>> --controller IntelAHCI --hostiocache on
>> VBoxManage storageattach Stage11 --storagectl "SATA Controller" --port
>> 0 --device 0 --type hdd --medium "st11.vdi"
>> VBoxManage storagectl Stage11 --name "IDE Controller" --add ide
>> --controller PIIX4
>> VBoxManage storageattach Stage11 --storagectl "IDE Controller" --port
>> 0 --device 0 --type dvddrive --medium ~/ubuntu-12.10-server-amd64.iso
>
> Why do you use 2 controllers? I'm almost sure you can plug the ISO file to
> SATA controller
> Have you tried booting the machine only with CD attached?
>
>
>
>>
>>> And post the VBoxManage showvminfo VM_NAME output.
>>
>> [vbox@ci /usr/home/vbox]$ VBoxManage showvminfo Stage11
>> [snip]
>>
>>
>>
>> BTW I've tried to disable nested pages, IOAPIC and ACPI but to no avail.
>
> I've created (without HDD) VM only with CD:
>
> s14% VBoxManage showvminfo Ubuntu
> Name:            Ubuntu
> Groups:          /
>
> Guest OS:        Ubuntu (64 bit)
> UUID:            a82f26cc-d223-4f51-8361-b1d3d06abd2c
> Config file:    ~/vm/Ubuntu/Ubuntu.vbox
> Snapshot folder: ~/vm/Ubuntu/Snapshots
> Log folder:      ~/vm/Ubuntu/Logs
> Hardware UUID:   a82f26cc-d223-4f51-8361-b1d3d06abd2c
>
> Memory size:     1024MB
> Page Fusion:     off
> VRAM size:       7MB
> CPU exec cap:    100%
> HPET:            on
>
> Chipset:         piix3
> Firmware:        BIOS
> Number of CPUs:  2
> Synthetic Cpu:   off
> CPUID overrides: None
> Boot menu mode:  message and menu
> Boot Device (1): DVD
> Boot Device (2): DVD
> Boot Device (3): HardDisk
> Boot Device (4): Not Assigned
> ACPI:            on
> IOAPIC:          on
> PAE:             on
> Time offset:     0ms
> RTC:             local time
> Hardw. virt.ext: on
> Hardw. virt.ext exclusive: on
> Nested Paging:   on
> Large Pages:     on
> VT-x VPID:       on
> State:           powered off (since 2012-11-17T12:34:40.000000000)
>
> Monitor count:   1
> 3D Acceleration: off
> 2D Video Acceleration: off
> Teleporter Enabled: off
> Teleporter Port: 0
> Teleporter Address:
> Teleporter Password:
> Tracing Enabled: off
> Allow Tracing to Access VM: off
> Tracing Configuration:
> Autostart Enabled: off
> Autostart Delay: 0
> Storage Controller Name (0):            IDE Controller
> Storage Controller Type (0):            PIIX4
>
> Storage Controller Instance Number (0): 0
> Storage Controller Max Port Count (0):  2
> Storage Controller Port Count (0):      2
>
> Storage Controller Bootable (0):        on
> IDE Controller (0, 1): /ftp/pub/Linux/Ubuntu/ubuntu-12.10-server-amd64.iso
> (UUID: 90e658c2-be30-4417-8a91-557b374fbaf5)
> NIC 1:           MAC: 080027CB7823, Attachment: Bridged Interface 'em0',
> Cable connected: on, Trace: off (file: none), Type: 82545EM, Reported speed:
> 0 Mbps, Boot priority: 0, Promisc Policy: deny, Bandwidth group: none
>
> NIC 2:           disabled
> NIC 3:           disabled
> NIC 4:           disabled
> NIC 5:           disabled
> NIC 6:           disabled
> NIC 7:           disabled
> NIC 8:           disabled
> Pointing Device: PS/2 Mouse
> Keyboard Device: PS/2 Keyboard
> UART 1:          disabled
> UART 2:          disabled
> LPT 1:           disabled
> LPT 2:           disabled
>
> Audio:           disabled
> Clipboard Mode:  disabled
> Drag'n'drop Mode:  disabled
> VRDE:            enabled (Address 0.0.0.0, Ports 5900, MultiConn: off,
> ReuseSingleConn: off, Authentication type: null)
> Video redirection: disabled
> VRDE property: TCP/Ports  = "5900"
> VRDE property: TCP/Address = <not set>
> USB:             disabled
> EHCI:            disabled
>
>
> USB Device Filters:
>
> <none>
>
> Available remote USB devices:
>
> <none>
>
> Currently Attached USB Devices:
>
> <none>
>
> Bandwidth groups:  <none>
>
>
> Shared folders:  <none>
>
> VRDE Connection:    not active
> Clients so far:     0
>
> Guest:
>
> Configured memory balloon size:      0 MB
>
>
> For me it works without any issues.
> The thing is that I am using VirtualBox 4.2.4 (it works well on my
> environment, under 9.1-PRERELEASE amd64).
> I'd recommend you to upgrade to 4.2.4
>
>
>>
>>> What is your hardware?
>>
>> Core i7-3930K on Intel DX79TO w/64 Gb RAM, ST33000651AS and ST3000DM001
>> HDDs
>
> Ok, that should be supporting virtualization well ;)
>
> Let me know about the results.

Okay the situation has changed radically after upgrade to 4.2.4,
VBoxHeadless does not consume 100% CPU anymore but now I have another
problem:

--- 192.168.221.11 ping statistics ---
677 packets transmitted, 677 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.233/4997.489/52552.511/10627.598 ms

This is results of ping between host and guest systems.

A common pattern is like this:

64 bytes from 192.168.221.11: icmp_seq=63 ttl=64 time=21.168 ms
64 bytes from 192.168.221.11: icmp_seq=64 ttl=64 time=1.914 ms
64 bytes from 192.168.221.11: icmp_seq=65 ttl=64 time=49.005 ms
64 bytes from 192.168.221.11: icmp_seq=66 ttl=64 time=7.190 ms
64 bytes from 192.168.221.11: icmp_seq=67 ttl=64 time=56.000 ms
64 bytes from 192.168.221.11: icmp_seq=68 ttl=64 time=0.276 ms
64 bytes from 192.168.221.11: icmp_seq=69 ttl=64 time=0.817 ms
64 bytes from 192.168.221.11: icmp_seq=70 ttl=64 time=12.177 ms
64 bytes from 192.168.221.11: icmp_seq=71 ttl=64 time=11.181 ms
64 bytes from 192.168.221.11: icmp_seq=72 ttl=64 time=19790.362 ms
64 bytes from 192.168.221.11: icmp_seq=73 ttl=64 time=18789.374 ms
64 bytes from 192.168.221.11: icmp_seq=74 ttl=64 time=17788.379 ms
64 bytes from 192.168.221.11: icmp_seq=75 ttl=64 time=16787.386 ms
64 bytes from 192.168.221.11: icmp_seq=76 ttl=64 time=15786.393 ms
64 bytes from 192.168.221.11: icmp_seq=77 ttl=64 time=14785.398 ms
64 bytes from 192.168.221.11: icmp_seq=78 ttl=64 time=13784.407 ms
64 bytes from 192.168.221.11: icmp_seq=79 ttl=64 time=12783.412 ms
64 bytes from 192.168.221.11: icmp_seq=80 ttl=64 time=11782.419 ms
64 bytes from 192.168.221.11: icmp_seq=81 ttl=64 time=10781.423 ms
64 bytes from 192.168.221.11: icmp_seq=82 ttl=64 time=9780.431 ms
64 bytes from 192.168.221.11: icmp_seq=83 ttl=64 time=8779.437 ms
64 bytes from 192.168.221.11: icmp_seq=84 ttl=64 time=7778.445 ms
64 bytes from 192.168.221.11: icmp_seq=85 ttl=64 time=6777.452 ms
64 bytes from 192.168.221.11: icmp_seq=86 ttl=64 time=5776.456 ms
64 bytes from 192.168.221.11: icmp_seq=87 ttl=64 time=4775.463 ms
64 bytes from 192.168.221.11: icmp_seq=88 ttl=64 time=3774.470 ms
64 bytes from 192.168.221.11: icmp_seq=89 ttl=64 time=2773.473 ms
64 bytes from 192.168.221.11: icmp_seq=90 ttl=64 time=1772.482 ms
64 bytes from 192.168.221.11: icmp_seq=91 ttl=64 time=771.488 ms
64 bytes from 192.168.221.11: icmp_seq=92 ttl=64 time=50.004 ms
64 bytes from 192.168.221.11: icmp_seq=93 ttl=64 time=0.252 ms
64 bytes from 192.168.221.11: icmp_seq=94 ttl=64 time=67.006 ms

I also have got a lot of "soft lockup - CPU#0 stuck for 22s!" Linux
kernel messages on the guest.
Since this is a periodic problem I guess the best way to track it down
is to get thread stack dump samples using gdb when the lock occures
but unfortunately I am not familiar with FreeBSD flavour of gdb, it
seems to be quite different. But I will try anyway.

Thanks,

--
SY,
Alex



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2Bkq2xsbOh8SQveP9HX1A%2BVdxxGpH=-MhVi%2BCwZZVCuJ4VPqRA>