Plum blossoms, the false hope of life
Rain, the reflection of infinite sadness
The sky, the unique embodiment of loneliness
A dog in the shadows, the instrument of Death.

People’s curiosity has no limits, particularly when it comes to Wesnoth add-ons.

In order to reproduce a bug, I had uploaded and removed a test add-on from the add-on servers for 1.8 and trunk several times, yet it seems I forgot to remove it the last time. This hasn’t stopped people from downloading it out of morbid curiosity, although nobody has dared to ask me about it on IRC or the forums. Certainly not news to me, since this is exactly what happened with it the last time prior to its removal.

As of this writing, the 1.8 version has had 949 downloads, as it can be seen in the screenshot above. You’d think an add-on with a description of “FOO” and a misspelled title would not attract anyone to try it, but this principle doesn’t work in practice. Had the add-on contained code to break all other add-ons, people would still not get the idea, I guess. Then again, I’m talking about users who often mistakenly download the source code tarballs and then ask how to install Wesnoth on Windows or Mac OS X.

This is what I get for forgetting to remove this kind of stuff. Thanks Gambit for pointing it out to me this night.

Finally, now that I have a 2 TiB external hard disk drive, I can start making regular, complete backups of my dear laptop. With rsnapshot fully setup after experimenting for a while using Bluecore’s own internal hard disk as target, a full copy of all major filesystems, and a partial copy of my /home — filtering useless crap for now, to avoid including caches and such — as of this writing the system is being backed up. Considering that it resides within a 250 GiB hard disk, of which 28 GiB are allocated for the preinstalled copy of Windows Vista, this couldn’t have been a better investment.

The next logical step is backing up Greycore and Blackcore’s hard disk contents, in particular the latter since its hard disk is already dying, and many blocks near the end of the drive are unusable.

After finishing Bluecore’s backup, I intend to send it to technical support if possible, to solve the issues with the noisy fan, partially stuck touchpad buttons, excess of dirt and lint inside the case and beneath the keyboard, loose screen panel articulation, … so yeah. And I also need a new, better battery (although the current one got better!). I’d probably consider just replacing the whole damn thing, if it weren’t that I already feel comfortable using it, and that we recently invested money on a laptop for my father — which happens to be completely useless, but whatever.

Besides, I didn’t buy an extra 2 GiB RAM module to throw it away with the laptop.

(Granted, I could just use Bluecore as a backup laptop by itself, but really, it’s hard to get rid of it since I’ve had better experiences with it than Greycore, despite all the problems derived from using AMD/ATI hardware.)

I’m also considering relocating and resizing partitions since my current configuration isn’t really optimal anymore, now that I have an use for those 250 GiB.

Not very long ago, I had a rather frightening experience that made me reconsider my testing practices of the increasingly popular Kernel Modesetting (KMS) support for various ATI Radeon chipsets on Linux. While I couldn’t determine exactly what happened back then, I’ve now got another similar story of KMS-related bugs that can cause permanent damage to your hardware.

My Wesnoth-UMC-Dev collaborator and personal friend of mine, Espreon, owns a Dell Inspiron e1705 laptop which ships with an ATI Mobility Radeon x1400 graphics controller. This is in contrast to my HP Pavilion dv5-1132la notebook (bluecore) which has an ATI Radeon HD 3200 (RS780-based) controller.

Espreon’s laptop is now damaged and unusable after some minor testing of KMS + Gallium3D drivers. The screen simply doesn’t work anymore.

I feel the need to carefully and meticulously analyze our stories since the KMS-enabled Radeon drivers are slowly becoming a standard amongst X.org-based Unix distributions including Debian GNU/Linux — Squeeze (6.0) is going to ship with a configuration apt for running on Radeon controllers in KMS operation without any user intervention. This is not to be unexpected since the KMS stack is clearly superior in terms of security and stability to the Xfree86/X.org based device drivers since it doesn’t require such things like making the X server’s executable setuid root, and allowing direct access to the host’s memory, video BIOS, etc. from a userland application.

But, is it really worth the risk? Is KMS really well-tested and safe enough to feature in stable mainline Linux kernels and in major general-purpose system distributions such as Debian? Let’s take a look at our personal experiences with the new graphics subsystem and drivers which are due to become mainstream around the end of this year.

Often on IRC I refer to my computers by their unique hostnames, which I also use to differentiate their Linux kernel configuration sets, optimized for every individual machine.

Many get confused with this because the names aren’t very descriptive of these machines, so here’s some technical background and history for every one of my technological pets.

It seems that one of the big guys of the Internet can’t keep the spambots at bay.

Espreon and I have been receiving this kind of garbage in our Gmail inboxes for quite a while already. They aren’t classified as spam for obvious reasons, but they are really annoying nonetheless. How come a company with that much money doesn’t set-up some kind of smart protection for their service forms? I’ve never seen this kind of crap from Google, and I hope to never do. This people, is why I use Google.

(Notably, I’ve received 4 of these so far, one every month until now.)

I just found out that Chromium (browser) has been in Debian experimental and Sid for a while.

I'm currently tracking Squeeze and pulling some packages from Experimental, in particular Iceweasel 3.6, which feels much more stable to me than its counterpart in Testing, version 3.5 — which will probably have to remain in the upcoming Stable release as explained by one of the package maintainers.

(Granted, I'm a fool who doesn't care about security because I don't visit unknown odd sites at all. If it weren't for this, you'd say I should not be pulling packages from Experimental, but I am, fully understanding the risks!)

Despite I can see other packages from Experimental in my package manager, including a localization package for Chromium, I can't see Chromium itself, which is really odd. I have Google Chrome installed and I pull it from Google's repository because…because it added itself to apt's sources after I installed it for trying it out last year — which unfortunately reeks of Internet Explorer's old “integration” thing that started with IE 4, frankly. I mean, why didn't it even ask me about adding the source? Is it modifying other parts of my system's configuration without my consent? What the hell, Google?

Rant aside, this is a strange coincidence, which could be related to a mirroring issue in any case, but I don't rule out the possibility that Chrome is somehow banning Chromium from my package manager. Alternatively my laptop might be possessed by some evil spirit that wants me to leave Debian's free-as-in-freedom packages for evil “Big Brother” software suites. Uncanny?

(For the Google lovers and haters in the audience: I'm perfectly fine with using Google stuff, mind you. My main email account is from Gmail, my preferred only search engine is Google's, I also use Google Maps, Google Earth, and this memory/method call profiling suite of sorts that Sirp recommended to me. I also use Google Translate and reCAPTCHA. So, no, I'm not really bothered by Google Chrome's additions, but I'm really mildly pissed off at their decision to change my package manager's sources without asking me through debconf or something.)

Sometimes people (especially Windows users) ask me what I use for some common task in Linux. These are my software preferences when working on various environments; your mileage will definitively vary.

Finally, the trap that is social networking has caught me.

I have joined Twitter as ShikadiLord (since “shadowm” and “shadowmaster” were already taken ) mainly because of Frogatto, which also has presence in Twitter now.

Let's see if I make use of this thing. To make things easier for me I'm using Choqok, a micro-blogging client for KDE SC 4.

Yays.

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

After almost two days of wandering around the streets of the city, my emissaries located a place to buy a new AC adapter for my much beloved HP Pavilion “ATI hellspawn” dv5-1132la, and I have thusly regained access to my development environment for Wesnoth and related projects.

48 hours of using a laptop with a broken display, short-lived (8 minutes) battery, unusable touchpad buttons, different keyboard layout and outdated user config can be very frustrating, but it was a good exercise nevertheless. It's better to have a broken spare laptop running Linux (Debian Lenny before Stable) than no spare laptop or no Linux laptop at all.