I was hoping to not have any more problems with Linux and my HP Pavilion dv5-1132la laptop since the last installment of this series of posts. However, with the release of Linux 2.6.33 and the improvements on KMS and general direct rendering support for the ATI R6xx and R7xx chipsets, I wanted to give KMS a try — this kernel version also improves support for some HDMI thing that I don't understand exactly what it is about, apparently related to digital audio devices or something.
(In other words, I shouldn't be complaining. Most of what comes in this post is the result of a voluntary experiment, and not some unfortunate incompatibility...probably.)
Configuring the kernel
Getting the kernel configured correctly was unusually hard this time, although my foolishness didn't exactly help matters.
At first, I tried to build the drm and radeon modules as part of the kernel image and that didn't work really well, because firmware blobs are required to be loaded by userspace to enable the most interesting features of these drivers — and since I don't make initrds anymore, the kernel would hang in middle of initializing the graphics driver long before getting to mount the root file system on which the blobs are installed. So what did I do? Play around with the “External firmware blobs to build into the kernel binary” option in the build configuration, to ultimately give up after two extra kernel builds and revert those components to their original external module status and just make sure radeon is manually inserted from /etc/rc.local before KDM/X.org starts.
Trying KMS out
It's sweet to see my usual 80x25 text console grow to a complete 1280x800 KMS-managed framebuffer console. With the radeon DDX, there's no more annoying usleep() wait when switching from text to X terminals and viceversa.
However, I could not get 3D acceleration to work — Mesa reverted to the software renderer for some reason. I had recompiled libdrm, Mesa and the DDX but this didn't help, so I'm probably missing something else. XRender acceleration appears to be missing as well.
This doesn't matter much at this point anyway, since I've got another reason for not using KMS yet.
Suspending to RAM (S3)
Power saving features such as suspend-to-RAM tend to unveil “interesting” problems in all kinds of hardware drivers, although sometimes it's just userspace misbehaving. In this case, I stumbled upon two different issues, the most relevant one being a huge delay when resuming from ACPI S3 with the screen and keyboard disabled. Once userspace fully comes back after this delay of approximately 1 minute, all graphic operations both on X and framebuffer consoles lag horribly to the point of making X barely usable.
The other issue is one that I found for the first time with the kernel 2.6.32.5 and which seems to strike at random here. The hard disk driver appears to have a small probability of giving up when suspending to RAM, issue which results in a huge delay before and after suspending, most likely because the userspace scripts (from pm-utils) in charge of helping the kernel with problematic drivers and hardware need read access to the root filesystem, which becomes inaccessible in middle of suspending until the machine gets rebooted. With 2.6.32.5 the kernel just gave up and unmounted the filesystems altogether, but 2.6.33 simply got the (in RAM) logs flooded with disk I/O errors — and a wreck in userspace.
I tried S3 only twice with 2.6.32.5, first stumbling upon the aforementioned dead disk controller issue, and then encountering the actual problem with KMS.
Missing firmware?
I suspect I'm required to install some firmware that cannot be distributed with the vanilla kernel from kernel.org after noticing some warnings in the logs:
[drm] Loading RS780 Microcode
platform radeon_cp.0: firmware: requesting radeon/RS780_pfp.bin
platform radeon_cp.0: firmware: requesting radeon/RS780_me.bin
platform radeon_cp.0: firmware: requesting radeon/R600_rlc.bin
r600_cp: Failed to load firmware "radeon/R600_rlc.bin"
[drm:r600_startup] *ERROR* Failed to load firmware!
radeon 0000:01:05.0: disabling GPU acceleration
The radeon/R600_rlc.bin blob is effectively not in the distribution.
Trying to make Mesa work with KMS-enabled libdrm would probably be worthless if I'm understanding things correctly here — I'm missing something which I must search somewhere in the net. Still doesn't explain the lag when resuming from S3 — or does it? Maybe I'll try this thing again the next time I feel like giving ccache a workout and a Tux-on-Ice patch for .33 is available to try KMS interaction with suspend-to-disk as well.
For now, I stick to UMS and Linux 2.6.32.9.
