Failed to load VMMR0.r0 (VERR_SYMBOL_NOT_FOUND) when starting a VM on Linux 2.6.29-rc6

[Marc O'Connor]

When starting any VM (new or old) on vbox 2.1.2/2.1.4 I get a dialog box that says the following

Failed to load VMMR0.r0 (VERR_SYMBOL_NOT_FOUND).
Unknown error creating VM (VERR_SYMBOL_NOT_FOUND).


Result Code:
NS_ERROR_FAILURE (0x80004005)
Component:
Console
Interface:
IConsole {e3c6d4a1-a935-47ca-b16d-f9e9c496e53e} 

This is followed by a log in my /home

Log created: 2009-02-20T15:17:05.822351000Z
Executable: /opt/VirtualBox/VirtualBox
Arg[0]: /opt/VirtualBox/VirtualBox
Arg[1]: -comment
Arg[2]: WinXP
Arg[3]: -startvm
Arg[4]: 6d5f33b5-8fd1-4685-92e7-70f21442f0f4
1: SUPR0AbsIs64bit
2: SUPR0Abs64bitKernelCS
3: SUPR0Abs64bitKernelSS
4: SUPR0Abs64bitKernelDS
5: SUPR0AbsKernelCS
6: SUPR0AbsKernelSS
7: SUPR0AbsKernelDS
8: SUPR0AbsKernelES
9: SUPR0AbsKernelFS
10: SUPR0AbsKernelGS
11: SUPR0ComponentRegisterFactory
12: SUPR0ComponentDeregisterFactory
13: SUPR0ComponentQueryFactory
14: SUPR0ObjRegister
15: SUPR0ObjAddRef
16: SUPR0ObjAddRefEx
17: SUPR0ObjRelease
18: SUPR0ObjVerifyAccess
19: SUPR0LockMem
20: SUPR0UnlockMem
21: SUPR0ContAlloc
22: SUPR0ContFree
23: SUPR0LowAlloc
24: SUPR0LowFree
25: SUPR0MemAlloc
26: SUPR0MemGetPhys
27: SUPR0MemFree
28: SUPR0PageAlloc
29: SUPR0PageFree
30: SUPR0Printf
31: SUPR0GetPagingMode
32: SUPR0EnableVTx
33: RTMemAlloc
34: RTMemAllocZ
35: RTMemFree
36: RTMemRealloc
37: RTR0MemObjAllocLow
38: RTR0MemObjAllocPage
39: RTR0MemObjAllocPhys
40: RTR0MemObjAllocPhysNC
41: RTR0MemObjAllocCont
42: RTR0MemObjEnterPhys
43: RTR0MemObjLockUser
44: RTR0MemObjMapKernel
45: RTR0MemObjMapKernelEx
46: RTR0MemObjMapUser
47: RTR0MemObjAddress
48: RTR0MemObjAddressR3
49: RTR0MemObjSize
50: RTR0MemObjIsMapping
51: RTR0MemObjGetPagePhysAddr
52: RTR0MemObjFree
53: RTProcSelf
54: RTR0ProcHandleSelf
55: RTSemFastMutexCreate
56: RTSemFastMutexDestroy
57: RTSemFastMutexRequest
58: RTSemFastMutexRelease
59: RTSemEventCreate
60: RTSemEventSignal
61: RTSemEventWait
62: RTSemEventWaitNoResume
63: RTSemEventDestroy
64: RTSemEventMultiCreate
65: RTSemEventMultiSignal
66: RTSemEventMultiReset
67: RTSemEventMultiWait
68: RTSemEventMultiWaitNoResume
69: RTSemEventMultiDestroy
70: RTSpinlockCreate
71: RTSpinlockDestroy
72: RTSpinlockAcquire
73: RTSpinlockRelease
74: RTSpinlockAcquireNoInts
75: RTSpinlockReleaseNoInts
76: RTTimeNanoTS
77: RTTimeMillieTS
78: RTTimeSystemNanoTS
79: RTTimeSystemMillieTS
80: RTThreadNativeSelf
81: RTThreadSleep
82: RTThreadYield
83: RTLogDefaultInstance
84: RTMpCpuId
85: RTMpCpuIdFromSetIndex
86: RTMpCpuIdToSetIndex
87: RTMpIsCpuPossible
88: RTMpGetCount
89: RTMpGetMaxCpuId
90: RTMpGetOnlineCount
91: RTMpGetOnlineSet
92: RTMpGetSet
93: RTMpIsCpuOnline
94: RTMpIsCpuWorkPending
95: RTMpOnAll
96: RTMpOnOthers
97: RTMpOnSpecific
98: RTPowerNotificationRegister
99: RTPowerNotificationDeregister
100: RTLogRelDefaultInstance
101: RTLogSetDefaultInstanceThread
102: RTLogLogger
103: RTLogLoggerEx
104: RTLogLoggerExV
105: RTLogPrintf
106: RTLogPrintfV
107: AssertMsg1
108: AssertMsg2
VMMR0.r0 is importing g_SUPGlobalInfoPage which we couldn't find

I am using virtualbox binaries install on Gentoo w/ kernel 2.6.29-rc5 xorg-server 1.5.3-r2, libsdl 1.2.13-r1

Not sure what the resolution is.

[Frank Mehnert]

Which binaries are that exactly, that is, where do they come from? Please attach the VBox.log file for such a session. It is possible that you mix two different versions of VirtualBox?

[Marc O'Connor]

I am using VirtualBox-2.1.4-42893-Linux_amd64.run. Just to be sure there wasnt and mixing I uninstalled vbox completely and reinstall 2.1.4. I cleaned /opt and /lib/modules/2.6.29-rc5

[Marc O'Connor]

vbox log

[Frank Mehnert]

Your log file is showing something different. First, this seems to be a debug log file which shouldn't be created in that case. Normal log files are created in ~/.VirtualBox/VM_NAME/Log/VBox.log. Second, the installation path seems to be /opt/VirtualBox/ which is wrong for a 2.1.4 package. It would be named /opt/VirtualBox-2.1.4.

[Marc O'Connor]

The installation path is set by the downstream 'devs'. But I just noticed that it is wrong.

I just uninstalled vbox/vbox-modules and rm -rf .~/Virtualbox then reinstalled and created a new VM. Same result. I have attached the log from ~/.VirtualboxMachines/winxp/ .

Is there anywhere that vbox may leave some cruft that could be causing this and I missed it when removing the rest of vbox? Also, this was working fne 2 days ago, is there any kernel related changes that could effect vbox?

[Marc O'Connor]

.Virtualbox/Machines/winxp/VBox.log

[leigh123linux]

I have the same problem :(

[root@localhost qBT_dir]# rpm -qa |grep Box
VirtualBox-2.1.4_42893_fedora9-1.x86_64
[root@localhost qBT_dir]# uname -r
2.6.29-0.137.rc5.git4.fc10.x86_64
[root@localhost qBT_dir]# lsmod |grep vbox
vboxnetflt             88348  0 
vboxdrv              1683692  2 vboxnetflt
[root@localhost qBT_dir]# cat '/home/leigh/.VirtualBox/Machines/Windows 7/Logs/VBox.log.3' 
00:00:01.097 VirtualBox 2.1.4 r42893 linux.amd64 (Feb 16 2009 20:57:32) release log
00:00:01.097 Log opened 2009-02-20T22:37:02.785039000Z
00:00:01.097 OS Product: Linux
00:00:01.097 OS Release: 2.6.29-0.137.rc5.git4.fc10.x86_64
00:00:01.097 OS Version: #1 SMP Fri Feb 20 14:31:43 EST 2009
00:00:01.097 Package type: LINUX_64BITS_GENERIC
00:00:01.143 1: SUPR0AbsIs64bit
00:00:01.147 2: SUPR0Abs64bitKernelCS
00:00:01.147 3: SUPR0Abs64bitKernelSS
00:00:01.147 4: SUPR0Abs64bitKernelDS
00:00:01.147 5: SUPR0AbsKernelCS
00:00:01.147 6: SUPR0AbsKernelSS
00:00:01.147 7: SUPR0AbsKernelDS
00:00:01.147 8: SUPR0AbsKernelES
00:00:01.147 9: SUPR0AbsKernelFS
00:00:01.147 10: SUPR0AbsKernelGS
00:00:01.147 11: SUPR0ComponentRegisterFactory
00:00:01.147 12: SUPR0ComponentDeregisterFactory
00:00:01.147 13: SUPR0ComponentQueryFactory
00:00:01.147 14: SUPR0ObjRegister
00:00:01.148 15: SUPR0ObjAddRef
00:00:01.148 16: SUPR0ObjAddRefEx
00:00:01.148 17: SUPR0ObjRelease
00:00:01.148 18: SUPR0ObjVerifyAccess
00:00:01.148 19: SUPR0LockMem
00:00:01.148 20: SUPR0UnlockMem
00:00:01.148 21: SUPR0ContAlloc
00:00:01.148 22: SUPR0ContFree
00:00:01.148 23: SUPR0LowAlloc
00:00:01.148 24: SUPR0LowFree
00:00:01.148 25: SUPR0MemAlloc
00:00:01.148 26: SUPR0MemGetPhys
00:00:01.148 27: SUPR0MemFree
00:00:01.148 28: SUPR0PageAlloc
00:00:01.148 29: SUPR0PageFree
00:00:01.148 30: SUPR0Printf
00:00:01.149 31: SUPR0GetPagingMode
00:00:01.149 32: SUPR0EnableVTx
00:00:01.149 33: RTMemAlloc
00:00:01.149 34: RTMemAllocZ
00:00:01.149 35: RTMemFree
00:00:01.149 36: RTMemRealloc
00:00:01.149 37: RTR0MemObjAllocLow
00:00:01.149 38: RTR0MemObjAllocPage
00:00:01.149 39: RTR0MemObjAllocPhys
00:00:01.149 40: RTR0MemObjAllocPhysNC
00:00:01.149 41: RTR0MemObjAllocCont
00:00:01.149 42: RTR0MemObjEnterPhys
00:00:01.149 43: RTR0MemObjLockUser
00:00:01.149 44: RTR0MemObjMapKernel
00:00:01.149 45: RTR0MemObjMapKernelEx
00:00:01.149 46: RTR0MemObjMapUser
00:00:01.149 47: RTR0MemObjAddress
00:00:01.149 48: RTR0MemObjAddressR3
00:00:01.149 49: RTR0MemObjSize
00:00:01.149 50: RTR0MemObjIsMapping
00:00:01.149 51: RTR0MemObjGetPagePhysAddr
00:00:01.149 52: RTR0MemObjFree
00:00:01.150 53: RTProcSelf
00:00:01.150 54: RTR0ProcHandleSelf
00:00:01.150 55: RTSemFastMutexCreate
00:00:01.150 56: RTSemFastMutexDestroy
00:00:01.150 57: RTSemFastMutexRequest
00:00:01.150 58: RTSemFastMutexRelease
00:00:01.150 59: RTSemEventCreate
00:00:01.150 60: RTSemEventSignal
00:00:01.150 61: RTSemEventWait
00:00:01.150 62: RTSemEventWaitNoResume
00:00:01.150 63: RTSemEventDestroy
00:00:01.150 64: RTSemEventMultiCreate
00:00:01.150 65: RTSemEventMultiSignal
00:00:01.150 66: RTSemEventMultiReset
00:00:01.150 67: RTSemEventMultiWait
00:00:01.150 68: RTSemEventMultiWaitNoResume
00:00:01.150 69: RTSemEventMultiDestroy
00:00:01.150 70: RTSpinlockCreate
00:00:01.150 71: RTSpinlockDestroy
00:00:01.150 72: RTSpinlockAcquire
00:00:01.150 73: RTSpinlockRelease
00:00:01.150 74: RTSpinlockAcquireNoInts
00:00:01.150 75: RTSpinlockReleaseNoInts
00:00:01.151 76: RTTimeNanoTS
00:00:01.151 77: RTTimeMillieTS
00:00:01.151 78: RTTimeSystemNanoTS
00:00:01.151 79: RTTimeSystemMillieTS
00:00:01.151 80: RTThreadNativeSelf
00:00:01.151 81: RTThreadSleep
00:00:01.151 82: RTThreadYield
00:00:01.151 83: RTLogDefaultInstance
00:00:01.151 84: RTMpCpuId
00:00:01.151 85: RTMpCpuIdFromSetIndex
00:00:01.151 86: RTMpCpuIdToSetIndex
00:00:01.151 87: RTMpIsCpuPossible
00:00:01.151 88: RTMpGetCount
00:00:01.151 89: RTMpGetMaxCpuId
00:00:01.151 90: RTMpGetOnlineCount
00:00:01.151 91: RTMpGetOnlineSet
00:00:01.151 92: RTMpGetSet
00:00:01.151 93: RTMpIsCpuOnline
00:00:01.151 94: RTMpIsCpuWorkPending
00:00:01.151 95: RTMpOnAll
00:00:01.151 96: RTMpOnOthers
00:00:01.151 97: RTMpOnSpecific
00:00:01.152 98: RTPowerNotificationRegister
00:00:01.152 99: RTPowerNotificationDeregister
00:00:01.152 100: RTLogRelDefaultInstance
00:00:01.152 101: RTLogSetDefaultInstanceThread
00:00:01.152 102: RTLogLogger
00:00:01.152 103: RTLogLoggerEx
00:00:01.152 104: RTLogLoggerExV
00:00:01.152 105: RTLogPrintf
00:00:01.152 106: RTLogPrintfV
00:00:01.152 107: AssertMsg1
00:00:01.152 108: AssertMsg2
00:00:01.152 VMMR0.r0 is importing g_SUPGlobalInfoPage which we couldn't find
00:00:01.152 pdmR3LoadR0U: pszName="VMMR0.r0" rc=VERR_SYMBOL_NOT_FOUND
00:00:01.153 ERROR [COM]: aRC=NS_ERROR_FAILURE (0x80004005) aIID={e3c6d4a1-a935-47ca-b16d-f9e9c496e53e} aComponent={Console} aText={Failed to load VMMR0.r0 (VERR_SYMBOL_NOT_FOUND).
00:00:01.153 Unknown error creating VM (VERR_SYMBOL_NOT_FOUND)} aWarning=false, preserve=false
00:00:01.162 Power up failed (vrc=VERR_SYMBOL_NOT_FOUND, rc=NS_ERROR_FAILURE (0X80004005))
00:00:11.918 ERROR [COM]: aRC=VBOX_E_INVALID_VM_STATE (0x80bb0002) aIID={e3c6d4a1-a935-47ca-b16d-f9e9c496e53e} aComponent={Console} aText={Invalid machine state: 1)} aWarning=false, preserve=false
[root@localhost qBT_dir]#

[Frank Mehnert]

Seems that this problem is related to 2.6.29-rc?

[Marc O'Connor]

Agreed. Any ideas as to what VMMR0.r0 is looking for so I can bisect the the git repo and see what might have regressed?

[sig_wall]

I've noticed, that vbox works fine with 2.6.29-rc4, but failed to start vm with 2.6.29-rc5.

[Marc O'Connor]

I'll test that later today as well.

[Marc O'Connor]

I'll test that later as well.

[Niki Waibel]

same issue here. using 2.6.29-rc5-git6

[Niki Waibel]

just compiled 2.6.29-rc4-git1: virtualbox works as expected!

[David Watzke]

same here - gentoo/amd64, linux 2.6.29-rc6 (vanilla), vbox 2.1.4, trying to start win xp

[Frank Mehnert]

After all, this seems to be a problem with 2.6.29-rc6 if CONFIG_X86_PAT is enabled as they made some kernel checks more strict.

You might want to check if uncommenting the following line

# VBOX_USE_INSERT_PAGE = 1

in /usr/src/vboxdrv*/Makefile and recompiling the modules (/etc/init.d/vboxdrv setup) solves the problem for you and how stable VBox then is.

[David Watzke]

frank, it works OK after uncommenting mentioned line, so thank you :-)

[Marc O'Connor]

This is a bit of a Gentoo specific question but how can I comment that out of the Makefile? There is no /usr/src/vboxdrv*/Makefile created. Gentoo extracts it to a /tmp dir and compiles it from there. I guess i can edit the Makefile in the tarball and go from there. Any Gentoo'ers can confirm this?

[David Watzke]

Replying to mroconnor:

This is a bit of a Gentoo specific question but how can I comment that out of the Makefile? There is no /usr/src/vboxdrv*/Makefile created. Gentoo extracts it to a /tmp dir and compiles it from there. I guess i can edit the Makefile in the tarball and go from there. Any Gentoo'ers can confirm this?

Of course... I used the 2.1.4 ebuild from jokey's overlay, ran "paludis -i virtualbox-modules" and after it was unpacked I stopped it with ctrl+z, edited the makefile and resumed the compilation with "fg" command.

[Marc O'Connor]

@dwatzke: I am not familiar with the 'fg' command. I also use paludis. Thanks.

[Niki Waibel]

i can confirm that Failed to load VMMR0.r0 is fixed by uncommenting

# VBOX_USE_INSERT_PAGE = 1

in src/vboxdrv*/Makefile and executing /etc/init.d/vboxdrv setup (using 2.6.29-rc5-git6).

[Alessio Cassibba]

@mroconnor, dwatzke

this issue was just reported on gentoo's bugzilla[1],
now the suggested patch is included in both
virtualbox-modules-2.1.2 and 2.1.4 ebuilds
( ebuilds on jokeys'overlay[2] )

[1] ​https://bugs.gentoo.org/show_bug.cgi?id=259688
[2] ​https://overlays.gentoo.org/dev/jokey

[Sid Boyce]

Uncommenting "VBOX_USE_INSERT_PAGE = 1" also solved the problem for me.

[zygfryd homonto]

this is not only Gentoo specific - exactly the same problem on Arch and kernel 2.6.29-rc7 and workaround solved the problem as well (Uncommenting "VBOX_USE_INSERT_PAGE = 1")

[Dave Plater]

I have the same with 2.6.29-rc5 and 2.6.29-rc6-git1 x86_64 on opensuse factory (11.2 Alpha 0) using binary VirtualBox-2.1.4_42893_openSUSE111-1.x86_64.rpm and the workaround in ticket #3090 start up with nopat enables vbox to start.

[Frank Mehnert]

nopat is not required if the vboxdrv module is compiled with VBOX_USE_INSERT_PAGE = 1

[Frans Pop]

I have tested current upstream kernel source (2.6.29-rc7) with ​this patch applied on top.

I can confirm that with that the issue is fixed. The "Failed to load VMMR0.r0" error is gone (without any change in the VBOX_USE_INSERT_PAGE setting). I expect that patch to be included in mainline shortly, so I expect no changes will be needed in VBox for it to work correctly with the next RC release of the kernel.

The kernel "WARNING: at arch/x86/mm/pat.c:620 reserve_pfn_range+0x5b/0x26d()" in dmesg that I reported in ​#3090 is also gone.

Tested with 2.1.4_OSE Debian package with self-compiled kernel and VBox modules.

Cheers, FJP

[Frans Pop]

Oops. Looks like I spoke too soon. VirtualBox crashed on me and hung up the whole system.

However, that was the first time I tried 2.1.4_OSE. I've now gone back to 2.1.2_OSE and cannot reproduce the same problem with a quick test, so it may be unrelated.

If I find out more I'll report it separately. I suggest getting independent info about the pat fix though.

Sorry, FJP

[Frans Pop]

Looks like the kernel patch itself is the problem. I also had X/KDE hang on me completely unrelated to VBox.

I've informed the kernel developers: ​http://lkml.org/lkml/2009/3/11/419

[Frank Mehnert]

fjp, thanks for tracking this issue!

[Dave Plater]

Confirm that the uncommenting of "VBOX_USE_INSERT_PAGE = 1" works with VirtualBox-2.1.4_42893_openSUSE111-1.x86_64 and recompiling vboxdrv works.

[Frans Pop]

The problems I reported yesterday look to be solved with ​this new version of the kernel patch for 2.6.29-rc7.

I've also upgraded to 2.1.4_OSE again and did not see any problems during a short test running Debian Installer, so all looks well.

[Lott Caskey]

I can confirm that the latest 2.6.29 builds in Fedora/Redhat are also affected by this problem.

I initially enabled VBOX_USE_INSERT_PAGE, but I was getting horrible disk-IO with the guest. Less than 9 MB/s on average.

I have removed VBOX_USE_INSERT_PAGE, applied the above patch against 2.6.29-0.237.rc7.git4.fc10.x86_64 and I no longer get the error, and disk-IO is significantly better.

I am however having a new problem since applying the patch. Bridged network connectivity is significantly dimished. When transferring a file from host to guest, using scp, my throughput is 35 KB/s. Is anyone else experiencing this?

[Lott Caskey]

I should also note that transferring from guest to host I am getting about 9.3 MB/s.

[Frank Mehnert]

lottc, please could you retry with VBOX_USE_INSERT_PAGE with the above patch applied? I doubt that your bad disk performance was due to enabling that #define.

[Frank Mehnert]

Hrmpf, in2.6.29-rc8 reserve_pfn_range() still returns -EINVAL for RAM :-(

[Frans Pop]

Correct. The patch is not yet included in rc8. It will probably be allowed to stew in a development tree for about a week before getting included in mainline. Reason is probably that it's pretty late in the release cycle and AIUI the patch is relatively invasive.

I do hope it will get included before the 2.6.29 release, but that's not 100% certain as Linus mentioned that rc8 may be the last candidate... If not it'll have to go in the first stable update for .29.

[Lott Caskey]

Still very poor (worse) host2guest network PERFORMANCE with VBOX_USE_INSERT_PAGE defined and above patch applied. I want to reiterate that my performance issues have only occurred since switching to 2.6.29 and thus have to use this patch and/or define.

---

scp transfer host2guest with kernel patch + define: [root@dev tmp]# scp centos_user.tar.bz2 root@10.13.5.20:/tmp centos_user.tar.bz2 100% 4622KB 16.5KB/s 04:40

scp transfer guest2host with kernel patch + define: [root@dev tmp]# scp root@10.13.5.20:/tmp/centos_user.tar.bz2 . centos_user.tar.bz2 100% 4622KB 4.5MB/s 00:00

---

scp transfer host2guest with kernel patch: [root@dev tmp]# scp centos_user.tar.bz2 root@10.13.5.20:/tmp centos_user.tar.bz2 100% 4622KB 17.6KB/s 04:23

scp transfer guest2host with kernel patch: [root@dev tmp]# scp root@10.13.5.20:/tmp/centos_user.tar.bz2 . centos_user.tar.bz2 100% 4622KB 4.5MB/s 00:00

---

(I say host2guest/guest2host, but it is really localnet2guest/guest2localnet)

So there was a very slight difference in the host2guest, probably not related to the define, but this kernel version (though I ran several transfers and with the define, the transfer rate was around 16 KB/s, and without the define it was around 17 KB/s). I use the guest in question for RPM and ISO builds, which grabs its 1GB or so worth of dependencies from another server on the local network... So I was shocked to find that an ISO build that normally takes 20 minutes was looking more like 15 hours to complete.

Does this belong in another ticket? This seems to be related to this kernel version/patch/define.

[Frank Mehnert]

First, 2.6.29 was not released so it is likely that there might some performance-related bugs. And apart from this, you could even check with 2.6.28.xyz if VBOX_USE_INSERT_PAGE changes anything related performace. In general I don't trust -rc kernels, and especially I don't trust -rc kernels which require some patches to work properly.

[Lott Caskey]

I agree, -rc kernels can be dubious. However, I switched to ext4, and this kernel has addressed some issues regarding the zeroing of files on a hard-lock in 2.6.28. Ie, when a hard-lock occurred, a commit against opened files would cause them not to be written back to disk. This is not a fault of the kernel, but bad programming in which O_TRUNC is being used to open files, zeroing them and holding the contents in memory before the commit.

​https://bugs.launchpad.net/ubuntu/jaunty/+source/linux/+bug/317781

Plus with comments from Linus were he believes there wont be another -rc before release after -rc8, using 2.6.29 and finding the problems before this does get released can only help the community...

Now, I don't believe VBOX_USE_INSERT_PAGE is causing a notable performance difference, but 2.6.29 + patch OR 2.6.29 + VBOX_USE_INSERT_PAGE from above is...at least for me.

Can anyone else verify that my problems are happening to them?

[Jim Gribbin]

I also have this happening on Fedora.

It was working OK w/ kernel-2.6.27.19-170.2.35_1.cubbi_tuxonice.fc10.i686

When upgraded to kernel-2.6.29-0.61.rc8_1.cubbi_tuxonice.fc10.i686, I have the same VMMR0.r0 error.

The latest Fedora Kernel is the same issue wo/ the cubbi_tuxonice stuff.

I also seemed to be able to cure it be uncommenting VBOX_USE_INSERT_PAGE, but I can't comment on the change in disk access times. This is my first vbox setup, so I have no frame of reference.

[Frans Pop]

JFYI

The 2.6.29 Linux kernel was just released but unfortunately still *without* the patch needed to fix this issue. Apparently it was judged too invasive for so late in the release cycle.

I expect the patch will be included in the first stable update (2.6.29.1), and will try to make sure it does.

[Frank Mehnert]

Thanks again!

[Frank Mehnert]

That patch is indeed included in 2.6.29.1. Please everyone with Linux 2.6.29, could you upgrade you 2.6.29.1 and compare if it makes any difference in performance when executing VBox with VBOX_USE_INSERT_PAGE enabled or disabled?

[Dave Plater]

VBOX_USE_INSERT_PAGE doesn't exist in VirtualBox-2.2.0_45846_openSUSE111-1 anymore and I can confirm that I have no more problems, running kernel-default-2.6.29-6.2