Not very long ago I mentioned that Frogatto’s iris transition effect didn’t work with the ATI R600 KMS drivers, and I assumed that this was caused by some lacking in the Mesa code. I even filed a bug report to its developers about it.

I was wrong. As MostAwesomeDude explained to me on IRC, and later posted in the bug tracker:

In UMS mode, r600c provides 8 bits of stencil on all configs, but in KMS mode, the normal wider variety of configs are available. The app used to have a call to SDL_GL_SetAttribute(SDL_GL_STENCIL_SIZE, 1), but it was commented out for some reason. Uncommenting that line caused a stencilled config to be properly selected.

The moral: Always check your GL configs.

Effectively, we discovered that restoring that line would solve the issue. It was apparently commented out by Dave at some point by accident. This won’t matter for long anyway, since Frogatto is already using a different mechanism to render the transitions on SVN trunk, solving the missing effect on who knows how many PC configurations. The iPhone port also lacked these transitions because of a platform limitation, so maybe the new technique will solve that minor shortcoming as well.

So now I’m basically just waiting for a new official release of the Tux-On-Ice patch for Linux 2.6.35 before switching to a complete KMS-based configuration. Until that happens, I’ll continue using 2.6.34.4 in UMS mode.

Again, thanks to MostAwesomeDude for the help with finding the cause of the bug!

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.

I have just rebooted from a 2.6.35 kernel to 2.6.34.2 in order to have the ability to hibernate bluecore with Tux-on-Ice again. However, the laptop acted up after the warm reboot as a consequence of running Linux in KMS operation mode, apparently. The greatest sign of doom: the Giant Blinking Cursor of Doom.

It’s normal for these HP laptops to display the text-mode blinking cursor for a bit after the BIOS splash screen, right before transferring execution to the first available boot medium. The cursor’s size is similar to Linux’s or MS-DOS under a default configuration with any generic VGA-compatible video adapter. In this transition state, the bold-white cursor blinks a few times at the top-left corner of the empty black screen, before changing its color to the normal text terminal white when GNU GRUB takes over.

However, whenever the AMD ATI Catalyst drivers lock up the laptop and I perform a warm reboot using one of the Magic SysRq sequences, the laptop doesn’t get past the system initialization code and after the BIOS splash screen disappears, instead of the usual bright blinking cursor, an abnormally large and wide white blinking cursor appears as the computer gets stuck forever.

I had not seen this occur after running with the open-source KMS drivers before, but I guess it might indicate I own a faulty GPU or motherboard.

EDIT: now I have pictures — taken with my three years old cell phone — showing the GBCoD and the normal blinking cursor:

Today, while having breakfast at a subway station before going to university, I stumbled upon a weird case of the laptop’s battery going crazy again.

As you know, Bluecore’s battery basically dropped dead after an unfortunate accident with charging cycles, but now the outlook has slightly improved after its capacity increased as a consequence of booting the laptop on battery power this morning.

$ acpitool -B
  Battery #1     : present
    Remaining capacity : 1504 mAh, 66.20%
    Design capacity    : 9000 mAh
    Last full capacity : 2272 mAh, 25.24% of design capacity
    Capacity loss      : 74.76%
    Present rate       : unknown
    Charging state     : charging
    Battery type       : rechargeable 
    Model number       : 25 mAh
    Serial number      : Primary

(The last two information fields and the design capacity are bogus as usual.)

The BIOS didn’t warn me about charge capacity this time either, nor after plugging the AC adapter in at the university’s central library, so there’s something clearly odd about this. I didn’t wait for the battery to discharge at the subway and left it at 66% before proceeding to charge it again now, so let’s see how this goes in the future. I might be able to squeeze some life out of this deteriorated power source before sending off Bluecore for maintenance and repair.

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.

The Linux kernel 2.6.35 was released today, and I compiled and installed it before all the download links appeared on kernel.org’s front-page thanks to Akregator.

There hasn’t been an official release of Tux-On-Ice for this kernel version yet, but I still went and booted 2.6.35 with Radeon KMS support enabled by default. I should say that I don’t notice any performance improvements since the last time I tried this thing, and in particular, stencil buffers seem to be still unsupported by my Mesa/kernel drivers combination, which makes Frogatto fall back to using fading for level transitions, as opposed to the cool iris effect used otherwise.

(I might even bug the Mesa developers about the stencil buffer thing if I like KMS enough now...)

Nonetheless, the VSync support in the Radeon KMS driver, just like in 2.6.34, is much better than the crap AMD ATI's proprietary suite has to offer. Watching videos in VLC with no tearing at all is just wonderful.

It’s one of those moments where I can’t decide whether I want features, or quality. Right now KMS appears to offer more quality than UMSm if only because it has VSync at all, but as far as I can see, the UMS driver is more mature in terms of OpenGL features. Granted, I may give the AMD ATI Catalyst 10.7 drivers a try later now that the SuperTuxKart issue I mentioned before appears to be fixed according to their changelogs.

EDIT: only a few hours after, I decided to file a bug report for Mesa, now #29350. Let’s hope for the best!

Two days ago, my HP laptop’s battery was working perfectly fine. Then I had to unplug the AC adapter and do stuff with the laptop elsewhere, so the battery was completely discharged afterwards. Then, I charged it again, but when going to bed I unplugged the adapter again when the battery was around 50% charged.

Fast-forward to the next afternoon, when I’m going with my family to celebrate stuff, and I turn on the laptop while in the car. Linux resumes from hibernation fine, and I see my KDE desktop again, with the battery meter at 50%. I check the Wesnoth.org forums for spambots as usual, fire up my IRC client…

And then the battery meter drops to 0%, KDE warns about suspending to disk in 5 seconds, and the laptop’s front panel battery status LED starts flashing.

I assumed that the laptop had just gone bonkers like it’s done before and ignored the warnings of imminent failure. Just as I was mentioning the ongoing problem on IRC, the laptop shut down completely, as it ran out of power.

It seems that this battery has finally collapsed, since the maximum charge dropped dramatically afterwards, and even the BIOS software warned me about it on the next boot. Here’s what acpitool has to say about the poor thing:

$ acpitool -B
  Battery #1     : present
    Remaining capacity : 704 mAh, 100.0%
    Design capacity    : 9000 mAh
    Last full capacity : 704 mAh, 7.822% of design capacity
    Capacity loss      : 92.18%
    Present rate       : 0      
    Charging state     : charged
    Battery type       : rechargeable 
    Model number       : 25 mAh
    Serial number      : Primary

(Note: Linux has always reported 9,000 mAh as the battery’s design capacity since day zero. This information is incorrect, and the correct value should be 4,000 mAh. Also note the bogus model/serial information.)

Since this is a rather critical situation, I’m probably going to buy a new battery for the laptop soon — besides sending it away for maintenance, which is in my list as soon as I buy that external hard disk drive on which I’ll be able to fit a complete raw disk image of my laptop’s HDD.

After successfully trying the AMD Catalyst driver (a.k.a. fglrx), I decided to go back to the open-source drivers for several reasons.

• A certain memory allocation failure from X.org scared me a bit.
• The proprietary drivers don't play well with SuperTuxKart (e.g. Debian bug #586797) causing texture corruption both with 0.6.2a and SVN trunk.
• Tearing. Lots of tearing with 2D. Forcing use of VSync in the configuration causes increased CPU usage for some reason.
• XVideo acceleration consumes some more CPU time than the free drivers' code for some reason (uh...).
• I discovered that the screen or GPU buzz when running on batteries after all.

There isn't anything in fglrx that I really needed to have, so I'm sticking to the free (open-source) drivers again, most likely for the rest of the laptop's lifetime.

After unsuccessfully trying the ATI Radeon Kernel-Modesetting driver with Linux 2.6.34, and reading about some performance comparisons with AMD/ATI's proprietary Catalyst drivers and the free Mesa DRI drivers, I decided to give AMD/ATI Catalyst (a.k.a. fglrx) another try.

When I decided to do that, fglrx 10.5 was in Debian's Testing, so I waited until the next day for fglrx 10.6 to enter Testing.

I've been using fglrx for the last 2:30 hours and haven't experienced any difficulties so far with OpenGL or Xv. Switching consoles works, suspend-to-RAM works, suspend-to-disk works, and I don't hear any buzzing from the screen, although I can't be very sure since the fan has been making very loud noises since around December last year. I have suddenly regained my faith in AMD.

There is one minor issue with Tux-On-Ice since it seems to run out of memory for drivers for the atomic copy step, probably due to fglrx. This causes TOI to try the same step twice or thrice before hibernating successfully ­— but solving this is most likely a matter of increasing CONFIG_TOI_DEFAULT_EXTRA_PAGES_ALLOWANCE (currently 2000) in the kernel config.

TuxOnIce debugging info:
- TuxOnIce core  : 3.1.1.1
- Kernel Version : 2.6.34-bluecore280-suspend2
- Compiler vers. : 4.4
- Attempt number : 2
- Parameters     : 0 667656 0 1 -2 5
- Overall expected compression percentage: 0.
- Compressor is 'lzf'.
  Compressed 1638621184 bytes into 554865401 (66 percent compression).
- Block I/O active.
  Used 78251 pages from swap on /dev/sda10.
- Max outstanding reads 851. Max writes 3700.
  Memory_needed: 1024 x (4096 + 320 + 104) = 4628480 bytes.
  Free mem throttle point reached 0.
- Swap Allocator enabled.
  Swap available for image: 1496831 pages.
- I/O speed: Write 91 MB/s, Read 105 MB/s.
- Extra pages    : 4118 used/4503.
- Result         : Succeeded.

The Extra pages line is what matters here.

While performance overall is much better than with the open-source drivers from Mesa, and Frogatto is usable with Kwin's compositing at last — even if still slightly slower than in non-compositing mode — there are some occasional odd messages in the kernel's log.

[fglrx:firegl_acpi_video_event] *ERROR* Could not find private acpi context by video busid: LCD

Nothing to worry about, I hope.

UPDATE: Effectively, increasing CONFIG_TOI_DEFAULT_EXTRA_PAGES_ALLOWANCE seems to have solved the hibernation issues.

- Extra pages    : 4041 used/5200.

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.