More RAM at last! (or, the side-effects of patching the ACPI DSDT)
Today I bought and installed another 2 GB of RAM from my HP Pavilion dv5-1132la laptop while on an errand to buy a new laptop for someone else — it ended up being a HP Pavilion dv4-something in case you are wondering.
This means that I can not only run Windows 2000, Windows XP, Windows 98, OpenSolaris 2009.06 and Debian Lenny on VirtualBox all at the same time now, but I'll also be able to compile Wesnoth faster now that I can take advantage of the dual-core AMD processor without running out of RAM and getting excess swapping to disk during the build!
It didn't work quite well at first, though. Problems occurred when I started enough processes to consume over 2 GB of RAM:
BUG: Bad page state in process VirtualBox pfn:6febepage:ffffea000187b990 flags:4000000000800000 count:0 mapcount:0 mapping:(null) index:0Pid: 4323, comm: VirtualBox Tainted: G A 2.6.33.4-bluecore263-preempt-suspend2 #1Call Trace:[<ffffffff81086a48>] ? bad_page+0x102/0x115[<ffffffff810882a2>] ? get_page_from_freelist+0x3b0/0x517[<ffffffff810884f6>] ? __alloc_pages_nodemask+0xed/0x588[<ffffffff810884f6>] ? __alloc_pages_nodemask+0xed/0x588[<ffffffff810a0b2a>] ? __vmalloc_area_node+0xea/0x10a[<ffffffffa021d514>] ? rtR0MemObjLinuxAllocPages+0xd8/0x1cc [vboxdrv][<ffffffffa021d630>] ? rtR0MemObjLinuxAllocPhysSub2+0x28/0xde [vboxdrv][<ffffffffa022a7dd>] ? g_abExecMemory+0x1ddd/0x180000 [vboxdrv][<ffffffffa022ad78>] ? g_abExecMemory+0x2378/0x180000 [vboxdrv][<ffffffffa022d2b0>] ? g_abExecMemory+0x48b0/0x180000 [vboxdrv][<ffffffff8102cc1c>] ? cpuacct_charge+0x54/0x76[<ffffffffa023b2f4>] ? g_abExecMemory+0x128f4/0x180000 [vboxdrv][<ffffffffa023d28f>] ? g_abExecMemory+0x1488f/0x180000 [vboxdrv][<ffffffffa023d7bb>] ? g_abExecMemory+0x14dbb/0x180000 [vboxdrv][<ffffffffa02316da>] ? g_abExecMemory+0x8cda/0x180000 [vboxdrv][<ffffffffa0218ded>] ? supdrvIOCtl+0x1241/0x20f8 [vboxdrv][<ffffffffa021ce22>] ? rtR0MemAlloc+0x90/0xb4 [vboxdrv][<ffffffffa02152a7>] ? VBoxDrvLinuxIOCtl+0x114/0x18e [vboxdrv][<ffffffff81028440>] ? pick_next_task_fair+0xac/0x112[<ffffffff810ba422>] ? vfs_ioctl+0x23/0x93[<ffffffff810ba92d>] ? do_vfs_ioctl+0x429/0x46d[<ffffffff810aeff3>] ? fget_light+0xc3/0xe8[<ffffffff810ba9ad>] ? sys_ioctl+0x3c/0x5c[<ffffffff81001f2b>] ? system_call_fastpath+0x16/0x1b
While at first I thought it was a problem with the new RAM module itself (either that or damage on the old module, which is occupying the formerly free slot) I quickly suspected of the Linux kernel configuration instead because of several ACPI-related errors in the boot log.
reserve_ram_pages_type failed 0x6febe000-0x6febf000, track 0x10, req 0x10ioremap reserve_memtype failed -16ACPI Error: Could not map memory at 000000006FEBEE70, size 7 (20091214/exregion-180)ACPI Exception: AE_NO_MEMORY, Returned by Handler for [SystemMemory] (20091214/evregion-475)ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.TOM_] (Node ffff88013f8605d0), AE_NO_MEMORYACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0._CRS] (Node ffff88013f860430), AE_NO_MEMORYACPI Error (uteval-0250): Method execution failed [\_SB_.PCI0._CRS] (Node ffff88013f860430), AE_NO_MEMORY
After running some memory test utilities and getting no problem reports I recompiled another kernel (blessed be ccache, by the way!) without my patched DSDT which I needed for getting thermal zone readings with Linux. I might have mentioned before that this laptop has a special rule in the ACPI DSDT to not allow any operating system other than Windows Vista (even the particular version) to read the temperature status.
As I suspected, all the boot errors went away after rebooting to an unpatched/untainted kernel, and right now I'm using 3678 MB of 3707 MB (damned graphics controller) without hitting a “bad page.”
I'm not sure why the patched DSDT caused this little mess, but I'll check what happens if I repatch it now, using the current “original” DSDT.