I've notice this last night after fighting with this a bit, since I couldn't get anything on the monitor.

There seems to be a race between the loading of the radeon drm module, and the check for KMS support in the radeon driver in the X process. The radeon driver looks for the /sys/bus/pci/devices/$path/drm/controlD* directory (controlD64 on my system) to make sure that KMS mode report is supported; unfortunately it seems like this check happens before the directory is actually created. Loading the module _before_ starting X, or building the radeon drm inside the kernel itself solves the problem since the controlD directory is created before X is started.

There is another related problem: when the controlD directory is not found, KMS is not detected and dri1 is initialized (which will also fail because the kernel is running dri2); somehow this leaves the card in an inconsistent state, and when X is started again afterwards (and KMS is detected), X blocks into calling ioctl (which repeatedly returns -EBUSY). This happens with xorg-server 1.6.3.901, 1.6.4 and 1.7.0.

HTH,
Diego

P.S.: sorry but I'm afraid I don't have a failure dmesg and Xorg.0.log :( I was debugging this last night around 4am so I didn't have the idea of saving them for later reporting… if I need to I can look into providing them.

P.P.S.: while I had radeon drm built as a module rather than bult-in it kernel paniced on rmmod… of that, too, I forgot to save the log :/ but I'll try to reproduce that next week as well, and save the log (serial console ftw!).