WinXP Raw Disk Access CPU Load 100%

Discussions related to using VirtualBox on Linux hosts.
reloaded
Posts: 5
Joined: 13. Oct 2007, 13:08

WinXP Raw Disk Access CPU Load 100%

Post by reloaded »

I already searched the forum and found lots of threads concerning cpu-load issues. but since they are all slightly different, i thought its better to make a new thread.

I use Ubuntu 8.04 Hardy Heron with the latest Virtualbox 1.5.6.
Using a vdi-Image with WinXP runs without any problems.
But using Raw Disk Access vdmk-Image gives me an instant 100% CPU load on one of my cpucores. So even when im at the grub-bootloader-menu or when i only use the Windows-Partition at the Hardware-Profile-menu i instantly get a 100% load.
I dont think that it has todo with 2 cores, since the vdi-image runs ok.

any ideas what i could try to figure out the problem?
mongolito404
Posts: 3
Joined: 1. May 2008, 11:12

WinXP Raw Disk Access CPU Load 100%

Post by mongolito404 »

Same here. When I'm running Windows XP from a physical partition in VirtualBox (using a vdmk disk) I get 100% CPU load on one of my two cores (Intel Core Duo T7500).
Virtman
Posts: 5
Joined: 9. May 2008, 10:25

Post by Virtman »

same here on a vista business host with xp sp3 guest.
- new installation on a vid image: 1-10% cpu load
reloaded
Posts: 5
Joined: 13. Oct 2007, 13:08

Post by reloaded »

I now tested the same setting with a Linux Guest. I also accessed the Raw Disk through Vbox. The high Cpu Load at the Grub-menu is the same, but when im at the login-prompt it perfectly idles. So i guess its definitly a problem with windows.
kurtpete
Posts: 2
Joined: 16. May 2008, 21:33

Post by kurtpete »

I'm having the same issue with version 1.6 installed and an existing winxp install (this is on Ubuntu Hardy amd64). One core immediately goes to 100%, and stays there for the duration of the vm being run.
vkov_tinsky
Volunteer
Posts: 218
Joined: 5. Apr 2008, 20:18

Post by vkov_tinsky »

I also see high CPU usage (~70%) when accessing a raw NTFS partition under a WinXP guest (VBox 1.5.6 on Ubuntu 7.10, P4 3GHz HT), but this only happens when there is actual disk activity.
kurtpete
Posts: 2
Joined: 16. May 2008, 21:33

Post by kurtpete »

I have tried running the guest (xp) both with and without USB support (as turning this off was mentioned in another thread). Behaviour is the same both ways. One processor stays at 100% utilization for the duration of the guest being run.
wumpus42
Posts: 24
Joined: 7. Apr 2008, 22:48
Primary OS: Mac OS X Leopard
VBox Version: PUEL
Guest OSses: WinXPSP3, Win7-32, Win7-64
Location: St. Louis, MO, USA

Post by wumpus42 »

I too am seeing one of my CPUs consumed by a WinXP SP3 Pro guest running off a raw partition. If I start up a WinXP guest using a VDI, I do not see this issue. Seems like there's a lot of this going around. I've tried enabling SATA but I don't know which SATA driver to load under WinXP.

Anyone know how to stop the 100% CPU consumption?

Intel Core2 Duo T7500, 4GB RAM, NVidia Quadro NVS 140M
Fedora9, NVIDIA-Linux-x86-173.14.05
VBox 1.6.2, WinXP SP3 Pro w/Guest Additions
kyboren
Posts: 6
Joined: 25. Jun 2008, 04:08

Post by kyboren »

Bump.

I'm having the same issues. Anyone found a fix? Or even the cause?

VirtualBox 1.56
Ubuntu 8.04
Kernel 2.6.24-19
8600GT with 6/11 NVidia drivers (173.whatever)
C2D E6300
6GB RAM
Writethrough to physical NTFS partition

EDIT: Image at GRUB with top running, showing 100% CPU usage on one core.
Image


EDIT: Does it have anything to do with these messages?

Code: Select all

00:12:58.390 NAT: DHCP offered IP address 10.0.2.15
00:12:58.398 NAT: DHCP offered IP address 10.0.2.15
00:12:59.000 PCNet#0: Init: ss32=1 GCRDRA=0x0319e420[64] GCTDRA=0x0319e020[64]
00:13:33.008 Guest Additions capability report: (0x1) VMMDEV_GUEST_SUPPORTS_SEAMLESS: yes VMMDEV_GUEST_SUPPORTS_GUEST_HOST_WINDOW_MAPPING: no
00:13:40.771 PCNet#0: Init: ss32=1 GCRDRA=0x0319e420[64] GCTDRA=0x0319e020[64]
00:15:15.947 PCNet#0: Init: ss32=1 GCRDRA=0x0319e420[64] GCTDRA=0x0319e020[64]
00:15:51.878 TM: Giving up catch-up attempt at a 60001579430 ns lag; new total: 60001579430 ns
00:17:18.511 TM: Giving up catch-up attempt at a 60008165214 ns lag; new total: 120009744644 ns
00:18:38.141 TM: Giving up catch-up attempt at a 60003040491 ns lag; new total: 180012785135 ns
00:19:54.878 TM: Giving up catch-up attempt at a 60003655862 ns lag; new total: 240016440997 ns
00:21:18.621 TM: Giving up catch-up attempt at a 60006617970 ns lag; new total: 300023058967 ns
00:22:29.191 TM: Giving up catch-up attempt at a 60004524471 ns lag; new total: 360027583438 ns
00:23:40.580 TM: Giving up catch-up attempt at a 60008925854 ns lag; new total: 420036509292 ns
00:24:50.760 TM: Giving up catch-up attempt at a 60007142796 ns lag; new total: 480043652088 ns
00:26:01.210 TM: Giving up catch-up attempt at a 60005664741 ns lag; new total: 540049316829 ns
00:27:11.150 TM: Giving up catch-up attempt at a 60003479277 ns lag; new total: 600052796106 ns
00:28:22.525 TM: Giving up catch-up attempt at a 60001911707 ns lag; new total: 660054707813 ns
00:29:35.541 TM: Giving up catch-up attempt at a 60000660924 ns lag; new total: 720055368737 ns
00:30:45.561 TM: Giving up catch-up attempt at a 60007304931 ns lag; new total: 780062673668 ns
00:31:55.930 TM: Giving up catch-up attempt at a 60004497736 ns lag; new total: 840067171404 ns
00:33:06.760 TM: Giving up catch-up attempt at a 60006754603 ns lag; new total: 900073926007 ns
00:34:17.187 TM: Giving up catch-up attempt at a 60004207844 ns lag; new total: 960078133851 ns
00:35:28.210 TM: Giving up catch-up attempt at a 60001456783 ns lag; new total: 1020079590634 ns
00:36:40.671 TM: Giving up catch-up attempt at a 60004215682 ns lag; new total: 1080083806316 ns
00:38:50.049 TM: Giving up catch-up attempt at a 60001120693 ns lag; new total: 1140084927009 ns
00:40:16.081 TM: Giving up catch-up attempt at a 60004593779 ns lag; new total: 1200089520788 ns
00:41:38.671 TM: Giving up catch-up attempt at a 60001118010 ns lag; new total: 1260090638798 ns
00:43:01.648 TM: Giving up catch-up attempt at a 60001189413 ns lag; new total: 1320091828211 ns
00:44:27.937 TM: Giving up catch-up attempt at a 60002712788 ns lag; new total: 1380094540999 ns
00:45:45.471 TM: Giving up catch-up attempt at a 60002152905 ns lag; new total: 1440096693904 ns
00:47:02.377 TM: Giving up catch-up attempt at a 60004252196 ns lag; new total: 1500100946100 ns
00:48:30.107 TM: Giving up catch-up attempt at a 60002490814 ns lag; new total: 1560103436914 ns
00:50:06.690 TM: Giving up catch-up attempt at a 60004983102 ns lag; new total: 1620108420016 ns
00:51:33.166 TM: Giving up catch-up attempt at a 60002779517 ns lag; new total: 1680111199533 ns
00:52:55.580 TM: Giving up catch-up attempt at a 60002351044 ns lag; new total: 1740113550577 ns
00:54:12.851 TM: Giving up catch-up attempt at a 60004741925 ns lag; new total: 1800118292502 ns
00:55:32.130 TM: Giving up catch-up attempt at a 60000438650 ns lag; new total: 1860118731152 ns
00:56:55.501 TM: Giving up catch-up attempt at a 60001129916 ns lag; new total: 1920119861068 ns
00:58:11.891 TM: Giving up catch-up attempt at a 60002303275 ns lag; new total: 1980122164343 ns
00:59:30.519 TM: Giving up catch-up attempt at a 60005509401 ns lag; new total: 2040127673744 ns
01:00:51.567 TM: Giving up catch-up attempt at a 60004209037 ns lag; new total: 2100131882781 ns
01:02:20.084 TM: Giving up catch-up attempt at a 60000101226 ns lag; new total: 2160131984007 ns
01:03:40.040 TM: Giving up catch-up attempt at a 60006127450 ns lag; new total: 2220138111457 ns
01:04:57.460 TM: Giving up catch-up attempt at a 60000077931 ns lag; new total: 2280138189388 ns
01:06:17.674 TM: Giving up catch-up attempt at a 60000134304 ns lag; new total: 2340138323692 ns
01:07:36.410 TM: Giving up catch-up attempt at a 60007477251 ns lag; new total: 2400145800943 ns
01:09:00.110 TM: Giving up catch-up attempt at a 60006643954 ns lag; new total: 2460152444897 ns
01:10:26.448 TM: Giving up catch-up attempt at a 60004485575 ns lag; new total: 2520156930472 ns
01:11:57.457 TM: Giving up catch-up attempt at a 60004355843 ns lag; new total: 2580161286315 ns
01:13:29.300 TM: Giving up catch-up attempt at a 60002451626 ns lag; new total: 2640163737941 ns
01:15:00.470 TM: Giving up catch-up attempt at a 60000070898 ns lag; new total: 2700163808839 ns
01:16:32.720 TM: Giving up catch-up attempt at a 60002946892 ns lag; new total: 2760166755731 ns
01:18:05.345 TM: Giving up catch-up attempt at a 60000349614 ns lag; new total: 2820167105345 ns
01:19:32.277 TM: Giving up catch-up attempt at a 60001649645 ns lag; new total: 2880168754990 ns
01:20:54.991 TM: Giving up catch-up attempt at a 60003606955 ns lag; new total: 2940172361945 ns
01:22:16.110 TM: Giving up catch-up attempt at a 60000604154 ns lag; new total: 3000172966099 ns
01:23:49.366 TM: Giving up catch-up attempt at a 60002759880 ns lag; new total: 3060175725979 ns
01:25:35.135 TM: Giving up catch-up attempt at a 60005304953 ns lag; new total: 3120181030932 ns
01:27:36.678 TM: Giving up catch-up attempt at a 60001375714 ns lag; new total: 3180182406646 ns
01:29:22.277 TM: Giving up catch-up attempt at a 60003751512 ns lag; new total: 3240186158158 ns
01:31:03.027 TM: Giving up catch-up attempt at a 60003324331 ns lag; new total: 3300189482489 ns
01:32:45.120 TM: Giving up catch-up attempt at a 60000302762 ns lag; new total: 3360189785251 ns
01:34:34.331 TM: Giving up catch-up attempt at a 60002264835 ns lag; new total: 3420192050086 ns
01:36:17.984 TM: Giving up catch-up attempt at a 60001421150 ns lag; new total: 3480193471236 ns
01:37:59.020 TM: Giving up catch-up attempt at a 60004715565 ns lag; new total: 3540198186801 ns
01:39:32.058 TM: Giving up catch-up attempt at a 60004164627 ns lag; new total: 3600202351428 ns
01:40:59.677 TM: Giving up catch-up attempt at a 60001046006 ns lag; new total: 3660203397434 ns
01:42:32.424 TM: Giving up catch-up attempt at a 60000250620 ns lag; new total: 3720203648054 ns
01:44:02.921 TM: Giving up catch-up attempt at a 60001256208 ns lag; new total: 3780204904262 ns
01:45:23.397 TM: Giving up catch-up attempt at a 60003047335 ns lag; new total: 3840207951597 ns
01:46:49.757 TM: Giving up catch-up attempt at a 60004402820 ns lag; new total: 3900212354417 ns
01:48:22.010 TM: Giving up catch-up attempt at a 60001220479 ns lag; new total: 3960213574896 ns
01:49:48.827 TM: Giving up catch-up attempt at a 60005361284 ns lag; new total: 4020218936180 ns
01:51:15.327 TM: Giving up catch-up attempt at a 60004873755 ns lag; new total: 4080223809935 ns
01:52:40.510 TM: Giving up catch-up attempt at a 60000914881 ns lag; new total: 4140224724816 ns
01:54:07.058 TM: Giving up catch-up attempt at a 60002260514 ns lag; new total: 4200226985330 ns
01:55:33.450 TM: Giving up catch-up attempt at a 60000808117 ns lag; new total: 4260227793447 ns
01:56:59.988 TM: Giving up catch-up attempt at a 60000201459 ns lag; new total: 4320227994906 ns
01:58:27.012 TM: Giving up catch-up attempt at a 60000589841 ns lag; new total: 4380228584747 ns
01:59:49.641 TM: Giving up catch-up attempt at a 60004906642 ns lag; new total: 4440233491389 ns
02:01:13.790 TM: Giving up catch-up attempt at a 60004245998 ns lag; new total: 4500237737387 ns
02:02:44.490 TM: Giving up catch-up attempt at a 60002731065 ns lag; new total: 4560240468452 ns
02:04:19.558 TM: Giving up catch-up attempt at a 60004571496 ns lag; new total: 4620245039948 ns
02:05:53.948 TM: Giving up catch-up attempt at a 60000459474 ns lag; new total: 4680245499422 ns
02:07:26.117 TM: Giving up catch-up attempt at a 60002527914 ns lag; new total: 4740248027336 ns
02:08:57.208 TM: Giving up catch-up attempt at a 60000946122 ns lag; new total: 4800248973458 ns
02:10:25.271 TM: Giving up catch-up attempt at a 60000274511 ns lag; new total: 4860249247969 ns
02:12:01.239 TM: Giving up catch-up attempt at a 60001280654 ns lag; new total: 4920250528623 ns
02:13:39.021 TM: Giving up catch-up attempt at a 60000434867 ns lag; new total: 4980250963490 ns
02:15:11.920 TM: Giving up catch-up attempt at a 60000541217 ns lag; new total: 5040251504707 ns
02:16:39.861 TM: Giving up catch-up attempt at a 60002757727 ns lag; new total: 5100254262434 ns
02:18:04.121 TM: Giving up catch-up attempt at a 60004157572 ns lag; new total: 5160258420006 ns
02:19:44.121 TM: Giving up catch-up attempt at a 60000600335 ns lag; new total: 5220259020341 ns
02:21:23.050 TM: Giving up catch-up attempt at a 60003346491 ns lag; new total: 5280262366832 ns
02:22:56.171 TM: Giving up catch-up attempt at a 60000678015 ns lag; new total: 5340263044847 ns
02:24:31.367 TM: Giving up catch-up attempt at a 60004763512 ns lag; new total: 5400267808359 ns
02:26:08.691 TM: Giving up catch-up attempt at a 60002027466 ns lag; new total: 5460269835825 ns
02:27:43.225 TM: Giving up catch-up attempt at a 60001277432 ns lag; new total: 5520271113257 ns
02:29:19.871 TM: Giving up catch-up attempt at a 60001052529 ns lag; new total: 5580272165786 ns
02:30:52.507 TM: Giving up catch-up attempt at a 60001590621 ns lag; new total: 5640273756407 ns
02:32:28.041 TM: Giving up catch-up attempt at a 60003526102 ns lag; new total: 5700277282509 ns
02:34:10.438 TM: Giving up catch-up attempt at a 60001114997 ns lag; new total: 5760278397506 ns
02:35:40.689 TM: Giving up catch-up attempt at a 60006683224 ns lag; new total: 5820285080730 ns
02:37:20.301 TM: Giving up catch-up attempt at a 60006075664 ns lag; new total: 5880291156394 ns
02:38:59.281 TM: Giving up catch-up attempt at a 60000428033 ns lag; new total: 5940291584427 ns
02:40:34.098 TM: Giving up catch-up attempt at a 60003417119 ns lag; new total: 6000295001546 ns
02:42:01.251 TM: Giving up catch-up attempt at a 60001616177 ns lag; new total: 6060296617723 ns
02:43:29.731 TM: Giving up catch-up attempt at a 60001487849 ns lag; new total: 6120298105572 ns
I can't help but notice they're each 1 (virtualized) min apart... is there some thread constantly trying to gain a resource, then timing out after a minute?
AlGaN
Posts: 22
Joined: 18. Jun 2008, 11:11
Primary OS: Ubuntu other
VBox Version: PUEL
Guest OSses: Windows XP SP3
Location: Germany

Post by AlGaN »

Same with me here on a non-raw vdi image with WinXP SP2 installed (generated with VB 1.5.6). I detected this behaviour (100% CPU all the time the VM runs) from beginning of version 1.6.0 & 1.6.2.

Cf my other post in the Using VB forum: http://forums.virtualbox.org/viewtopic.php?t=7353.
As it seems nobody has a fix or workaround for this major issue so I have to stay at version 1.5.6 for now.

AlGaN
kyboren
Posts: 6
Joined: 25. Jun 2008, 04:08

Post by kyboren »

I just tried disabling ACPI and IO ACPI (knowing it probably wouldn't work as they warn), and I got CPU usage to go to idle! Of course, with ACPI disabled it won't even load the profile, and with ACPI enabled and IO ACPI disabled, it loads the entire profile (then apparently hangs, but no messages are given this time!).

Is this a bug related to VirtualBox's ACPI handling?


EDIT: AHA! I fixed it!
When we were all running Windows on-the-metal, our newer processors were determined by Windows to be suitable to use the 'ACPI Multiprocessor PC' kernel. From what I've read here, Windows' ACPI sucks, and the way it does it incurs an enormous virtualization penalty.

So, I believe I've found the cause. What's the workaround? Tell Windows to not use ACPI! The instructions are in the linked page, but they are basically thus:
  • Right-click 'My Computer'
  • Go to the hardware tab, click 'Device Manager'
  • Expand the 'Computer' item
  • Select 'ACPI Multiprocessor PC'
  • Right-click it and select 'Update Driver'
  • Choose "Install from a list or specific location (Advanced)'
  • Choose 'Don't search. I will choose the driver to install.'
  • Choose 'Standard PC' from the list.
  • Reboot
  • Enjoy your new PC!
Immediately upon reboot, the machine booted up nearly instantly, instead of nearly hanging at the logo screen and barely crawling along. Looking at top, VirtualBox is no longer eating up all my CPU! In the guest, everything's just as speedy as it was on-the-metal!

FIXED
wumpus42
Posts: 24
Joined: 7. Apr 2008, 22:48
Primary OS: Mac OS X Leopard
VBox Version: PUEL
Guest OSses: WinXPSP3, Win7-32, Win7-64
Location: St. Louis, MO, USA

DRAT! Changing to Standard PC causes BSOD

Post by wumpus42 »

And I was so hopeful too. Got a BSOD after rebooting the VM after changing to Standard PC... something about the intelppm.sys driver. I even went back to my restore point just before the move to Standard PC and tried Advanced Configuration and Power Interface (ACPI) PC... same BSOD in the same driver.

Thank goodness for restore points.

Guess its just not meant to be for me.
kyboren
Posts: 6
Joined: 25. Jun 2008, 04:08

Post by kyboren »

You should have taken the time to read that link!

The intelppm.sys driver is smart enough to not BSOD again. If you get the intelppm.sys BSOD, just restart without changing the configuration back or restoring and your system will work.
wumpus42
Posts: 24
Joined: 7. Apr 2008, 22:48
Primary OS: Mac OS X Leopard
VBox Version: PUEL
Guest OSses: WinXPSP3, Win7-32, Win7-64
Location: St. Louis, MO, USA

Post by wumpus42 »

I did let it reboot... several times in a row. Each time I got the BSOD and each time upon rebooting I was informed that the boot process did not complete and did I want to boot into Safe Mode or ... Normal. I let it "Normal" those several times but it always BSOD'd. I finally chose "Safe Mode" after those several BSODs. During Safe Mode many drivers were automatically installed and it suggested I reboot, so I restarted the VM... BSOD.

I realize this is not very scientific documentation. When I get a chance I'll try the process again documenting the messages.
Virtman
Posts: 5
Joined: 9. May 2008, 10:25

Post by Virtman »

You have to edit the registry key BEFORE you restart the virtual machine.

Change the value of the key Start to 4 for one of the following registry keys:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Processor
or
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Intelppm
Post Reply