My old patched ACPI DSDT didn't work well after adding 2 GB of RAM and caused a lot of “interesting” problems, so I built a kernel without a custom DSDT to be able to work safely without hitting a “bad page.”

Last night I fetched the system's DSDT again, patched and recompiled it, removing the rules that disallow non-Vista systems to get certain info from the thermal zone. So now I have a working 2.6.33.5 kernel that can access the ACPI thermal zone again.

shadowm@bluecore:~$ taintedness.pl 
Tainted: G        A  

    A (ACPI) - ACPI DSDT overridden.
shadowm@bluecore:~$

With the usual side-effect of tainting the kernel.

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:6febe
page:ffffea000187b990 flags:4000000000800000 count:0 mapcount:0 mapping:(null) index:0
Pid: 4323, comm: VirtualBox Tainted: G       A   2.6.33.4-bluecore263-preempt-suspend2 #1
Call 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 0x10
ioremap reserve_memtype failed -16
ACPI 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_MEMORY
ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0._CRS] (Node ffff88013f860430), AE_NO_MEMORY
ACPI 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.

May 17th 2010, 9:15 PM local time, Santiago de Chile.

This has been a day plenty of good news in the software side of things. For one, the KDE 4.4 migration in Debian Squeeze seems to be mostly complete and SC version 4.4.3 is in testing now, despite having been released by the upstream providers only about a little more than a week ago. I downloaded and installed the packages earlier this morning (blessed be aptitude) and I've seen only satisfying results so far — not to mention that the improvements to the Oxygen widget set and windeco are...uh...OHHHH SHIIIIINYYYYY!!!

*Ahem*, in any case, I've decided to set up (again) a little experiment with kernel modesetting support for my ATI RS780 (r6xx-based) and this HP laptop. Linux 2.6.34 was, according to my sources, released yesterday with lots of performance improvements in that area. I have, as usual, the latest DDX (radeon), DRM and Mesa sources from the git repositories. Right now I'm copying my 2.6.33-tuxonice (2.6.33.4) tree, cleaning it and patching it to prepare a 2.6.33.4 build. The weather is pretty cold and I've got an annoying stomachache which I'm fighting with the Power of Tea. I hope to have luck...with the kernel, I mean, not the stomachache, although I guess that's also important for a complete and comfortable user experience.

For what is worth, I'm not using a Tux-On-Ice patch for 2.6.34 since there's no such officially released yet — I only want to try KMS and go back to 2.6.33.4 for production until I hear news from TOI, unless things go really wrong and I simply decide 2.6.34 is not for me, like I once did with 2.6.29 and 2.6.30.

*end of record*

10:16 PM.

27 minutes after starting make-kpkg, I have obtained a fresh 2.6.34 kernel with a delicious vanilla smell. I'll now put it in the oven — er, I mean, install it with dpkg, recompile the radeon DDX with KMS support and reboot.

*end of record*

10:50 PM.

While things didn't go as well as I expected, I can assure that KMS' performance with this ATI RS780 improved a lot since Linux 2.6.33, especially when dragging windows around with a compositing window manager. Something that really amazes me is the shorter delay (less than 1 second now, used to be between 2 and 3 seconds) in resuming from suspend-to-RAM.

The problem here is that OpenGL clients still suffer a lot of performance loss under a compositing manager such as KDE 4.4.3's Kwin — which they generally don't with UMS, which only causes flickering — making Frogatto's camera motion jerky and annoying. This is not a Good Thing™ (particularly because of a greater reason I'll eventually explain in detail) and this means that if I wanted to use Frogatto with KMS I'd have to disable compositing with the handy keyboard shortcut...in other words, not different to how I use it with UMS. No gain for some substantial loss.

There's still some performance loss with KMS and no compositing. It isn't very noticeable in Frogatto most of the time, but I've been using an old eduke32 build with an old version of the High Resolution Pack as a test case for Mesa for quite a while now. Framerate drops from between 70 and 90 FPS (UMS) to between 30 and 50. It's still acceptable, but not optimal and this is not even a worst-case scenario.

I thought for a moment that this loss could be caused by a couple of options I left set in my xorg.conf from UMS, namely ClockGating and DynamicPM, so I disabled them and restarted X. Again, no differences, except for a little warning that appeared in the kernel logs with no further explanation.

You have old & broken userspace please consider updating mesa

Okay, wait, how can the userspace support be “old & broken” and yet it works at acceptable performance? Then again, it's partially right in complaining because I haven't recompiled mesa (not that I really should, probably) in a couple of days. So let's try again with a newer mesa.

*end of record*

11:15 PM.

Here we go, with a current version of mesa's source code from the git repository. Everything looking the same again. No performance improvements or extra losses. Again, I use eduke32 as a stress testing suite for lack of something better.

So...wait...WHOAH...THE COLORS MAN, THE COLORS!! IT'S SO BEAUTIFUL...IT'S...IT'S...

vsmlbhmnermernqvatmguvfmguramlbhmunirmabmyvsr*

*unexpected end of record*

11:32 PM.

I have no fucking idea of what happened. I don't know if the GPU (or the display?) got hyperstimulated or it was just my eyes, or my brain, but after rebooting from the aforementioned...crashed...system (which didn't react to any magic sysrq sequence for a change), the GRUB menu background (blue) was blinking so quickly it was making me dizzy.

My theory is that yes, the GPU got hyperstimulated and needed to cool down for a few seconds, just like my eyes. In any case, the KMS kernel in question has been destroyed and I'm back on 2.6.33.4 with Tux On Ice and using drivers in UMS mode. Oh...the colors...there are no words, screenshots or photos which could demonstrate my point. IT WAS SO FREAKIN' COOL THAT I'm currently wondering if it permanently damaged my hardware or it's just one of those "as long as it doesn't happen again we're okay" things. O_o The effect was pretty hypnotic despite looking like a still screen going brighter and brighter...

There's naturally nothing in the kernel logs hinting to what happened. I'd say it was a hardware failure, maybe caused by a corrupted firmware image making it past the defenses. </wildguessing> In any case I don't think I want to try KMS for a while...at least not until I have a whole laptop (or eyes) to spare.

*end of record*

GAAAAAAAAAAAAAAAAAAAAAAAAAA! o_O

No, not the movie, although I admit it's one of my favorites.

Some time ago I got an upgrade from Qt 4.5 to 4.6 as part of the deal of following Debian Squeeze's progress in the testing repository. This had a couple of interesting side effects, one of them being a minor change in behavior related to the radeon drive and my DPI settings (long history), and the other being performance degradation in one of my most frequently used applications: Konsole.

This performance degradation results in it lagging everything down whenever a top view updates, for example — not even window managers can stand the increased CPU load produced by the refreshing console. A more common symptom I see is a huge delay when switching tabs. I'm not sure if all this is just a direct consequence of upgrading Qt or there's something wrong with my setup.

I didn't really feel like giving up Konsole for the plain and bland xterm application. Then I remembered a software package that I installed (as many other packages) following a suggestion from some person on IRC.

Terminator is a program that embeds Gtk terminal emulator widgets (which are also used by the popular GNOME terminal) and allows the user to arrange them in various ways in the same window. The following screenshot attempts to illustrate the flexibility I'm talking about.

While I initially feared I'd be forced to go back to Konsole for some features, Terminator has proven to be a very good replacement which plays well with most console-based programs I use, including Irssi. The version I'm using, 0.93, has a very nice GUI for editing its configuration. I had used previous versions which required me to write a configuration file by hand with my non-standard preferences. Now I can easily edit keybindings to imitate Konsole and get used to Terminator more quickly.

It's implemented in Python and can consume a fair amount of memory — it's the process using 44 MB of RAM as seen in the top view above — but it's well worth the price in my opinion.