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*

In my case, I was trying out the KMS support provided by Linux 2.6.34 and the current Mesa (classic DRI r600) and Radeon DDX from their respective Git repositories back then, and the target application was the Eduke32 port of Duke Nukem 3D, using an old version of the High Resolution Pack — which means, detailed large textures, many models with motion, uncapped framerate. Espreon’s situation was different — he was just trying the final boss level of Frogatto, which is a game with simpler 2D rendering and capped framerate around 50 frames per second, albeit still a mildly exigent OpenGL client. Also, he was trying the newer Mesa Gallium3D drivers for ATI R3xx-based chipsets (r300g) since they are getting new (existing) features at a steady rate, faster than r600g which would apply to my GPU.

Both cases had as immediate symptom X.org seemingly locking up. In my case, the kernel also locked up and I could not switch to a text terminal, nor use any magic SysRq sequences to reboot the machine. However, Espreon’s case differs in that his kernel continued running normally and he could switch to a text terminal, in which he noticed vertical lines and screwed up colors.

Now, as soon as I figured that there was something really wrong happening to my laptop’s GPU or screen, I closed its lid, unplugged the AC adapter and removed the battery as quickly as I could. Espreon used sudo reboot instead, thus keeping the laptop running despite this inconsistent state.

After cutting off all power to my laptop, I waited some seconds and plugged the adapter and inserted the battery again, and turned it on, to watch the BIOS splash and GNU GRUB text-mode menu blinking like hell. Fearing that I might have killed the GPU/screen, and feeling the metaphorical bucket of water on my head, I decided to let bluecore cool down for a few minutes. Then I turned it on and everything was working normally again. In Espreon’s case, after completing the warm reboot from Linux, he could see an abnormally grainy BIOS splash screen which led him to turn off the laptop. Ever since then, whenever he turns it on, although the boot process appears to carry on as usual, neither the screen’s backlight or the LCD panel itself would work again.

I don’t know much about how the graphics controller and the related software work, or how they interact with a laptop’s display panel, but I suspect that a rare bug in the KMS code — most likely at the kernel side — could be forcing execution to jump to a bad location in such way it doesn’t immediately crash, and overriding the GPU state in some dangerous way that sets the display parameters off the output device’s limits.

***

Now Espreon needs to either get his laptop repaired or buy a new computer. As for me, bluecore seems to be doing fine after that little accident. Naturally, now that I know these catastrophic bugs can be triggered by more than just stress-testing like I did, I’m not considering giving KMS much more testing again, at least not until the kernel version 2.6.40 or so. This does not mean I’ll stop tracking mainline kernels, because there’s always improvements and additions in other areas outside of the graphics stack — this in particular is pretty motivating even for RC kernel testing.

So, this is an inconspicuous issue that might be worth considering, especially for system distributors that are transitioning to KMS drivers for their newer releases. It’s a pity that we don’t have methods for determining a failsafe way to reproduce these bugs, at least not without investing enormous amounts of money. Maybe HP and AMD could team up and donate AMD ATI-powered laptops to the kernel DRM developers?