Assertion fail in MMHyper.cpp when trying to start VM => Fixed in SVN/3.0.6

[dbolte]

I'm running CentOS 4 (kernel 2.6.9) on a 8core Xeon system. I installed VirtualBox 1.6.2, compiled the kernel module using /etc/init.d/vboxdrv setup.

The VM disk was copied from another host (where it worked fine) and cloned afterwards using VBoxManage clonevdi.

After about 2 or 3 successful VM starts, I'm now constantly running into an assertion in MMHyper.cpp, line 617.

[dbolte]

log file of VirtualBox

[John La Rooy]

I have this same problem except that it has not worked even once for me. In fact it has hung the machine a couple of times :(

Also on centos4 kernel is Linux 2.6.9-78.0.5.ELsmp #1 SMP Wed Oct 8 07:12:03 EDT 2008 i686 i686 i386 GNU/Linux

CPU is a single Xeon E5320

[John La Rooy]

I am trying 1.6.6, but 2.0.2 has the same error too

[dbolte]

Tried VirtualBox 2.0.4 - problem still exists

[Frank Mehnert]

I removed your previous comment. Please never cut'n'paste the VBox.log file, there is an attach function.

[John La Rooy]

2.0.6 has the same problem

[rordinas]

version 2.1.2 still have the same problem

[Frank Mehnert]

Please could you append a more recent VBox.log file (preferable from version 2.1.2)?

[kylix tan]

Error Log

[kylix tan]

os:rhel 4.7 kernel:2.6.7-70-ELsmp

[Frank Mehnert]

kylix.tan, thank you for this additional log. Can you reproduce this bug? Would you be willing to do some more tests? If so, please contact me via private E-mail (frank _dot_ mehnert _at_ sun _dot_ com).

[ikcc]

Hello,

problem appears here with vbox 2.2.2 rel 46594 on a 4x Xeon host running RHEL 4 AS update 4. I've attached a RHEL 32bits boot cd on my "4mkcdrec" vm, and two virtual disks. Each time I try to start the vm, a black window appears briefly, and close. The virtual machine state is shown "aborted".

this problem prevents using vitualbox at all in my case. Ready to give more feedback if needed.

[Frank Mehnert]

Could anyone who is experiencing this assertion do the following to help us finding the problem: Please edit the file /usr/src/vboxdrv-*/r0drv/linux/memobj-r0drv-linux.c and apply the following patch:

--- memobj-r0drv-linux.c        (revision 48451)
+++ memobj-r0drv-linux.c        (working copy)
@@ -538,6 +538,14 @@
         rc = rtR0MemObjLinuxVMap(pMemLnx, fExecutable);
         if (RT_SUCCESS(rc))
         {
+
+            size_t iPage = pMemLnx->cPages;
+            while (iPage-- > 0)
+            {
+                if (page_to_phys(pMemLnx->apPages[iPage]) == 0)
+                    printk("Page %d is backed by frame 0!\n", iPage);
+            }
+
             *ppMem = &pMemLnx->Core;
             return rc;
         }

After this, please do

/etc/init.d/vboxdrv setup

Note that both actions require root permissions. After doing this please try to start a VM. When the assertion was triggered, please do

dmesg

and look for the occurrence of the printk() message from the above patch. Our current assumption is that this function returns a page which is backed by a physical memory at address 0 which should not happen.

[Nathaniel Ingersoll]

I applied the patch. Nothing was noted by dmesg (cleared before starting the VM, very little output). Do note that it's not the linux kernel crashing - my system stays up just fine - it's just the VM that fails.

[Frank Mehnert]

I know.

[Bill V]

I applied the patch as well, did the setup and tried starting a VM with the same results and no output from dmesg or messages log. I have tried several version of Vbox, 2.12. 2.14, 2.24 all with the same result:

00:00:01.060 MM: cbHyperHeap=0x140000 (1310720)
00:00:01.064
00:00:01.064 !!Assertion Failed![[BR]] 00:00:01.064 Expression: paPages[i].Phys != 0 && paPages[i].Phys != NIL_RTHCPHYS && !(paPages[i].Phys & PAGE_OFFSET_MASK)
00:00:01.064 Location : /home/vbox/tinderbox/2.2-lnx32-rel/src/VBox/VMM/MMHyper.cpp(570) int MMR3HyperMapPages(VM*, void*, RTR0PTR, size_t, const SUPPAGE*, const char*, RTGCPTR64*)
00:00:01.064 i=0x0 Phys=0000000000000000 VM

I am using a Dell 2850 power edge single Xeon 3.4Ghz CPU 8GB ram, only using about 4gb, with RHEL4 updated with all the latest patches. I have tried the RHEL4 versions of VBOX as well as building the generic version, all result are the same.

There have been several occasions where starting up the VBOX client crashed the Kernel (Panic), after an install of a new version of VBOX. In 4 years this is the only application I have ever had cause a Kernel Panic on RHEL4. I have never been able to successfully run a Virtual Machine, even plain dos with no boot disk. I have VBOX running on windows XP just fine. Thanks for any help you can provide.

[qzhang8]

I encountered the same problem using VirtualBox3.0. It is really frustrating to me.

[Wilson]

Hi All,

I also encounter same issues on my Oracle Enterprise Linux 4 update 5. It is brand new install for both OS and VBox (2.2 and 3.0).

However, I discovered that I'm able to start VM with VBoxHeadless if I perform export appliance for a VM at the same time.

Then, I reboot the host and use UniProcessor (UP) kernel. My existing VM can start without error. (Both with VBoxHeadLess or from the GUI) That remind me that my EL4U5 guest also need to use UP kernel after installation.

Hope it may help for trouble-shooting or serve as a work-around.

Wilson

[Chris]

I am also receiving the same error with VirtualBox Version 3.0.4 r50677. Any VM that I try and start immediately exits and the VBox.log shows the error below :

00:00:00.551 !!Assertion Failed!! 00:00:00.551 Expression: paPages[i].Phys != 0 && paPages[i].Phys != NIL_RTHCPHYS && !(paPages[i].Phys & PAGE_OFFSET_MASK) 00:00:00.551 Location : /home/vbox/vbox-3.0.4/src/VBox/VMM/MMHyper.cpp(610) int MMR3HyperMapPages(VM*, void*, RTR0PTR, size_t, const SUPPAGE*, const char*, RTGCPTR64*) 00:00:00.551 i=0x0 Phys=0000000000000000 VM

I also applied the patch mentioned above, recompiled the vboxdrv module and did not see any additional output in dmesg : vboxdrv: Found 2 processor cores. vboxdrv: fAsync=0 offMin=0x369 offMax=0x97e vboxdrv: TSC mode is 'synchronous', kernel timer mode is 'normal'. vboxdrv: Successfully loaded version 3.0.4 (interface 0x000e0000). divert: allocating divert_blk for vboxnet0

I am running RHEL4 : $ cat redhat-release Red Hat Enterprise Linux WS release 4 (Nahant Update 4)

$ uname -a Linux deschutes 2.6.9-55.0.2.ELsmp #1 SMP Tue Jun 12 17:59:08 EDT 2007 i686 i686 i386 GNU/Linux

The workstation is a Dell Optiplex 745 with an Intel Core 2 Duo CPU and 4GB of RAM. If there is any other info I can provide that would be of assistance please let me know. This bug is preventing me from running any virtual machines on this workstation.

[Chris]

vm log

[Frank Mehnert]

Problem reproduced in RHEL4. Investigating.

[Frank Mehnert]

Most probably this problem occurs only on systems

• with physical frames beyond the 4GB limit (usually systems with more than ~3.5GB RAM)
• only on 32-bit hosts
• only on Linux hosts with Linux < 2.6.10

If one of this conditions is not met, the bug should not occur. Anyway, searching for a proper workaround.

[Chris]

Thanks for the quick response Frank. I'm looking forward to a patch or update to get VirtualBox running again :)

The problem also only occurs for me when running the SMP kernel. As sikson mentioned above, I also am not able to reproduce the problem running the kernel 'Red Hat Enterprise Linux WS (2.6.9-55.0.2.EL)'.

[Frank Mehnert]

Good news and bad news: The bad news is that there will be no guest SMP with VirtualBox on Linux kernels < 2.6.13. The reason is that Linux unconditionally rewrites the content of the CR4 register when flushing the TLBs, in particular the VMXE flag will be cleared causing a Linux kernel OOPs. Therefore we cannot enable VT-x on such kernels (therefore no SMP and no AMD-V). The good news is that the assertion was fixed and at least guest with software virtualization will work with the next maintenance release of VirtualBox.