(In reply to comment #10)
The segfault shows up when using
xserver-5532687a929426c4b1c4667f4591ed362f097c9b.tar.bz2 (Keith Packard)
and following versions of xserver. (I first made distclean!)
The patch works well when using the previous versions of xserver.

(In reply to comment #13)
> I too applied the patch. startx gets further, but in the logs I see
>
> /usr/bin/X: symbol lookup error: /usr/lib/xorg/modules/drivers/radeon_drv.so:
> undefined symbol: udev_monitor_filter_add_match_subsystem_devtype
> giving up.
> xinit: Connection refused (errno 111): unable to connect to X server
> xinit: No such process (errno 3): Server error.
Hmm, maybe I lucked into a working setup because I don't use evdev on this old LFS setup, so have an xorg.conf with -
Section "ServerFlags"
Option "AutoAddDevices" "off"
EndSection
As for mesa (maybe you know this anyway) you can workaround by adding to autogen options
--with-state-trackers=dri

I added the autoadddevice option as suggested. There is no change (no surprise really, since the load of the radeon driver is what's probably failing).
I was able to rebuild mesa with the --with-state-trackers=dri flag. Can't test it though.

OK, I've just rebuilt/reinstalled xserver and xf86-video-ati. Things now work provided:
1. I turn off KMS in the kernel.
2. I apply the patch to deal with pixmapPrivate
3. Apply the patch (attached below) to deal with udev_monitor_filter_add_match_subsystem_devtype
I'm on a slackware box, and I suspect that udev is too old. Unfortunately so is libc and hence I've been unable to build my own udev. I'd appreciate someone checking if I've broken something by simply dropping the call.

It looks that commit
commit 5c6a2f93ebc16a78093782b442306de23ae94e78
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Sep 27 19:39:23 2010 +0100
xfree86: Kill pixmapPrivate with a vengeance (v2)
ScrnInfo->pixmapPrivate only existed in order to catch invalid access to
the framebuffer by making the backing data NULL across the VT switch.
This was causing more confusion in the higher layers during mode setting
without any real benefit, so remove it.
v2: Kill ShadowModifyPixmapHeader() as well.
...
removed pixmapPrivate from struct _ScrnInfoRec in xserver/hw/xfree86/common/xf86str.h
Author of the line in mesa which references (indicatted by git blame mesa/src/gallium/state_trackers/xorg/xorg_driver.c ) is
commit 6749310d...
Jakob Bornecrantz 2010-01-25 20:07:43 +0100
There is also a comment, which reads
/* This a hack to work around EnableDisableFBAccess setting the pointer
* the real fix would be to replace pScrn->EnableDisableFBAccess hook
* and set the rootPixmap->devPrivate.ptr to something valid before that.
*
* But in its infinit visdome something uses either this some times before
* that, so our hook doesn't get called before the crash happens.
*/
pScrn->pixmapPrivate.ptr = ptr;
Apperently removing pScrn->pixmapPrivate.ptr = ptr, do not hurt...

There is a bit more to it.
The commit is a major ABI breakage, which means drivers compiled against previous X servers won't work anymore. Hence the major ABI number should have been updated. Likewise, any new driver releases simply removing this reference won't work against older X servers without compatibility code.