I decided to build a new kernel.

I downloaded the latest sources, configured it (remembering to add in support for the MTD devices, for that flash card I bought), and built and installed it.

I checked to see if I needed an update to the wireless drivers again, but they looked ok. (There was a problem with compiling the ipw2200 drivers against the 2.6.12 kernel, and I had to hack the source to get it to compile).

I rebooted, booted the new kernel. I built the wireless drivers (the ieee80211 bit first, and then the ipw2200), it worked, the interface/device appeared again.

It associated with the access point, but pump wouldn't configure the device for some reason. Everytime I attempted to use pump, with any interface, it just immediately came back saying "Operation Failed".

I set the interface up manually, with ifconfig and route (setting the ip, and the default route), and got browsing.

I found this page.

It looks like something has got stuffed in this kernel version, and pump is broken, because it writes to a socket, and reads it back, and it gets changed in the process.

I used strace for myself, and saw the same thing.

No biggie, I can handle setting up the interfaces manually, it's just a pain though, and I don't know when it will get fixed, and if it's the kernel or pump that will get fixed.

Ok, time to get the graphics driver working properly again.

I reread my old notes, and followed through them again.

Basically, I had to build the drm source, and then plonk i915.ko and drm.ko in the /lib/modules/[version]/kernel/drivers/char/drm directory, "depmod -a", then modprobe the modules.

This got me:

[drm] Initialized drm 1.0.0 20040925
ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
[drm] Initialized i915 1.2.0 20041217 on minor 0: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller

sweet, but I'm not celebrating yet.. I checked for /dev/dri/card0, and saw it, so now I'm happy, that's halfway there, this was a big problem last time.

It means the kernel has proper support for direct rendering, I just have to build the matching Mesa code, for the X module that interacts with the kernel module.

Based on the process in http://dri.freedesktop.org/wiki/Building it looked like I was doing things ass about, ie drm, then Mesa, instead of doing X, then Mesa, then drm, but I think it did that way before, and had it all working, so I tried it that way again.

Before I could build Mesa, I needed libdrm, so in the drm directory, I did an ./autogen, and a make install.

This worked, so then I went about building Mesa, with "make linux-dri-x86", this took ages, and eventually finished.

I backed up the /usr/X11R6/lib/modules/dri directory, and then copied all the .so files from the lib dir under Mesa in there.

However, from looking at the file timestamps, they'd already been updated, oh well.

I restarted gdm, but discovered that I still didn't have direct rendering. Bugger, it should have worked.

I looked in the logs, and I saw:

(II) Loading sub module "dri"
(II) LoadModule: "dri"
(II) Reloading /usr/X11R6/lib/modules/extensions/libdri.so
(II) UnloadModule: "dri"
(II) I810: Failed to load module "dri" (already loaded, 0)

Strange. I tried unloading the kernel modules, in case it was trying to load them, when they were already loaded, but this didn't make any difference, still no good.

I didn't think that was the problem anyway.

I checked the config file I was using again, and found that it had 2 display device definitions (since it's a dual head card in the laptop) in it, and wondered if that was causing a problem.

Both had dri enabled on them, and maybe it's trying to load the drivers for the second definition, and that's why it was complaining that it's already loaded.

I swapped out the config file, for one with only a single definition in it, but that didn't work either.

The last time this happened, it took me a couple of reboots before it started working, so I rebooted, and tried again, but it still didn't work. There goes the windows way of fixing things.

I checked the log file from X again, and noticed that xinerama was enabled, hmm, I seem to recall that you can't have both dri and xinerama.

I don't need xinerama, since I don't use dual head anymore.

I edited the config file, and I took out the second card definition, and crt details, and changed the xinerama setting to off.

I started up X, and it flashed a bit differently, so I thought it had worked, but I still didn't have direct rendering enabled.

I think the initial flash of video was in direct rendering mode, and then it flashed off, and back on again, in vesa mode, or whatever it falls back to using.

When I checked the log, I found:

drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenByBusid: Searching for BusID pci:0000:00:02.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 8, (OK)
drmOpenByBusid: drmOpenMinor returns 8
drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
(II) I810(0): [drm] DRM interface version 1.2
(II) I810(0): [drm] created "i915" driver at busid "pci:0000:00:02.0"
(II) I810(0): [drm] added 8192 byte SAREA at 0xe0214000
(II) I810(0): [drm] mapped SAREA 0xe0214000 to 0xb7ac3000
(II) I810(0): [drm] framebuffer handle = 0xc0020000
(II) I810(0): [drm] added 1 reserved context for kernel
(II) I810(0): Allocated 3072 kB for the back buffer at 0xf800000.
(II) I810(0): Allocated 3072 kB for the depth buffer at 0xf400000.
(II) I810(0): Allocated 32 kB for the logical context at 0xf3f8000.
(II) I810(0): Allocated 54016 kB for textures at 0x520000
(II) I810(0): Updated framebuffer allocation size from 5120 to 5128 kByte
(II) I810(0): Updated pixmap cache from 512 scanlines to 514 scanlines

Ok, good start, but then..

(II) I810(0): Activating tiled memory for the back buffer.
(II) I810(0): Activating tiled memory for the depth buffer.
(II) I810(0): [drm] Registers = 0xdff00000
(EE) I810(0): [drm] drmAddMap(backbuffer) failed. Disabling DRI
(II) I810(0): [drm] removed 1 reserved context for kernel
(II) I810(0): [drm] unmapping 8192 bytes of SAREA 0xe0214000 at 0xb7ac3000
(==) I810(0): Write-combining range (0xc0000000,0x10000000)
(II) I810(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000
(WW) I810(0): Extended BIOS function 0x5f05 failed.

Crap. what does "drmAddMap(backbuffer) failed" mean??

A bit of googling turns up this page, and this page.

I think it's a mailing list related to netbsd, though the linux related "answer" seemed to be:

"I just updated the kernel from 2.6.13-rc2-mm1 to 2.6.13-rc5
and the problem went away."

But this looks like it's more related to a different issue, that I had later..

So now what? is 2.6.13 really having issues? pump's busted, and now it looks like the dri stuff could be too.

I wondered if maybe I should just pull the latest drm/Mesa out of CVS and try again, but I didn't think it would make any difference, because the i915 driver looks like it's from last year anyway.

Hmm, one thing that seemed weird, is that I didn't have to do anything with agpgart (and it wasn't loaded), and I seem to recall having to muck around with it the last time I was doing this.

I rolled back to the old kernel, 2.6.12.4, that I've been using for a few weeks.

Pump starting working again, bonus. I decided I should have been able to get the dri stuff working with the old kernel.

When I went to build the dri kernel modules ("make", in the linux-core dir), it kept complaining about not being able to find the kernel configuration file.

I realised it was probably because /usr/src/linux now pointed to the wrong kernel version. I fixed up that symlink, but it still said the same thing.

I found that I had to specify the kernel source directory, by using "sudo make LINUXDIR=/usr/src/linux", this worked.

I copied i915.ko and drm.ko into /lib/modules again, did a depmod, and modprobed both, but got:

mtrr: base(0xc0020000) is not aligned on a size(0x300000) boundary
[drm:drm_unlock] *ERROR* Process 4971 using kernel context 0

(this is where the "I updated the kernel and it went away" fix applied, for the other guy).

Hmm. 4971 is the PID of the X process that's currently running.

I killed off X, and did some work on the console. I unloaded the dri and i915 modules that were loaded when I booted, or when X started before.

I tried to load the new ones I'd just built and copied in, but it complained that the magicversion was wrong. It's the same kernel version I compiled it against, but the append-to stuff was missing, so it looked like it was different.

I forced the modules in anyway, and they loaded, as they should, since they were right.

I then rebuilt the libdrm stuff again, and installed it.

Then I built the Mesa/Xmodules again. I had to copy them in manually this time, they hadn't updated by themselves, like I think happened before.

I started up X, and found that I still didn't have direct rendering. Hmm.

I looked in the log again, and found the same thing as before, about the backbuffer.

Now I don't know what the problem is. Is 2.6.12.4 a problem as much as 2.6.13? or is there something wrong with the Mesa stuff that I pulled out of CVS?

I tried updating the drm code from CVS, and rebuilding the kernel modules and Mesa all over again, with the new code.

This resulted in exactly the same error, about the backbuffer again.

I did a bit more googling, and turned up this page, where the code is all hyperlinked.

I wish I knew C code, I might be able to try modifying it, or debugging it or something.

I don't understand what's going on here, and I don't know what to do. I suppose I could roll back to 2.6.11.11, which I think I had direct rendering working with before, but that's really a pain.

The other possibility, is that the code in CVS is broken, or changed from the previous code I've used, so regardless of what kernel I try using, it might make no difference.

Here we go.. for the regular signoff.. "I give up". (That was good use of about 4 hours).

Update..

OK, I got X running in direct rendering mode again. I downloaded a snapshot of the dri stuff for the i915, and I built and installed it. Direct rendering worked when I started X.

I downloaded kernel 2.6.12.6 (first from mirror.pacific.net.au, which was corrupt, same thing as when I downloaded 2.6.12.5 from there), and built it.

I rebuilt the wireless drivers again, and pump still worked. I built the dripkg snapshot, and installed the drivers, and X runs in direct rendering mode.

I'm only seeing about 750 fps though, and I had previously seen 1250 fps from this chip.

Oh well, it works, I can run games like gltron, and ultimatestunts, and I can run videos in mplayer at fullscreen, without it complaining that my computer is too slow.

I'm pretty happy, and I guess this confirms that the DRM code in CVS is broken.