Guest Fedora 12 can not boot any more (pPage->enmKind != PGMPOOLKIND_FREE) => Fixed in SVN

[rumen]

After an upgrade from 3.2.12 the fedora VMs stopped booting sometimes generating an error (see the attached log) but not always. I created new VM and tried to install Fedora 12 but after the installation when I try to boot the VM I get "NO BOOT DEVICE FOUND".

I have the same problem on Ubuntu 10.04 and MacOS X 10.6.5 hosts.

[rumen]

UPDATE: after a downgrade to 3.2.12 the all the machines started booting again. Even the one installed under 4.0.0.

[Raffaello D. Di Napoli]

Boot failure with Linux 2.6.36 with Gentoo patchset 5

[Raffaello D. Di Napoli]

Same issue here, with a Gentoo guest with minimal custom-configured kernel version 2.6.36 with Gentoo patchset 5, which worked perfectly until I upgraded from VirtualBox 3.2.12 to 4.0.0.

Host is Gentoo as well, with the same kernel, very up-to-date.

I have a number of other guests, and I don’t seem to have any problems with Arch Linux, Fedora 14, Ubuntu 10.10, and OpenSolaris 2009.06. I’m also investigating a lock-up crash in Windows XP SP3 that appeared with 4.0.0, but I’ll probably file a separate bug for that.

[Raffaello D. Di Napoli]

I believe I found what, in my case at least, leads to the failure of the assertion in the subject (pPage->enmKind != PGMPOOLKIND_FREE).

I reconfigured the faulty guest kernel using the .config from another (working) guest, Ubuntu 10.10, and I started disabling/altering configuration options until the error showed up again (very lengthy process - hours of recompilations). And it did, when I disabled highmem support (CONFIG_NOHIGHMEM=y) while still enabling PAE support (CONFIG_X86_PAE=y).

I tried re-enabling highmem (CONFIG_HIGHMEM4G=y) or disabling PAE (#CONFIG_X86_PAE), and it resumed working; I then reverted them again, one by one, and I got still the same guru meditation. So, I think that the combination no-highmem + PAE is the culprit. It also makes sense that it’s a memory-related problem, since the assertion that fails is in

VBox/VMM/VMMAll/PGMAllPool.cpp(5117) PGMPOOLPAGE* pgmPoolGetPage(PGMPOOL*, RTHCPHYS)

I don’t know if this is the same problem that’s afflicting the OP, but the workaround I found (either enable highmem or disable PAE) works for me.

I hope you’ll be able to reproduce, and maybe fix, this issue.

[sigwx]

Seems to be hardware specific for me as I use 4.0.2 on a newer system with VT-x support and it works fine. Move the VMs to a older P4 system without VT-x and I see the same issues.... or is this the same as #7938?

[Raffaello D. Di Napoli]

Replying to sigwx:

Seems to be hardware specific for me as I use 4.0.2 on a newer system with VT-x support and it works fine. Move the VMs to a older P4 system without VT-x and I see the same issues.... or is this the same as #7938?

It can’t be the same: this bug only happens with no hwvirt, while the nested paging (related to #7938) is only available with hwvirt.

[Frank Mehnert]

I closed a couple of duplicates. Let's summarize the findings (raffaellod, thank you for your investigation):

• this seems to be a VBox 4.0 regression (VBox 3.2.12 works)
• all reports have in common that no hardware virtualization is used
• the guest is always 32-bit and uses PAE
• the hosts of all reporters are 32-bit but I believe the same would happen with Vt-x disabled on a 64-bit host

[Frank Mehnert]

The fix will be available with the next maintenance release.