Bug#658636: Acknowledgement (xserver-xorg-video-radeon: Multiple DRI regressions)

[Witold Baryluk]

Ok,

I managed to fix my computer.

It was not a problem in Xorg, DDX or udev at all.

It is kernel problem, and in my particular case a module loading done by initramfs.

It looks that initramfs-tools, was loading radeonfb module before
another ones, in early bootup process, and this messed with drm stuff
(drm and radeon module) for some reason. Initramfs was loading this
module early because I added 'radeonfb'  entry to the
/etc/initramfs-tools/modules long time ago, but it was not working or
was not an issue. Now it started to be issue. In fact I belive I hit
exactly same problem when I was compiling kernel with radeonfb and
radeon built-in directly into kernel. Modules was loading probably in
wrong order or something.

It was not udev fault. After booting, there was not even a proper
'card0' files in /sys/ tree. Removing 'radeonfb' from early boot loading
from initramfs, resolved problem for me.

So it looks that it is some problem beetween radeonfb and radeon modules.

In fact I do not have radeonfb module loaded right now, but I still have
a highresolution framebuffer on the console and /dev/fb0 exists, so I am
somehow confused how is this possible!

# dmesg | grep fb
[    5.157160] device: 'fbcon': device_add
[    5.157218] PM: Adding info for No Bus:fbcon
[  118.948689] [drm] fb mappable at 0xC00C0000
[  118.948848] [drm] fb depth is 24
[  118.949031] device: 'fb0': device_add
[  118.978424] PM: Adding info for No Bus:fb0
[  118.978936] fbcon: radeondrmfb (fb0) is primary device
[  119.549784] fb0: radeondrmfb frame buffer device


So why there are two incompatible drivers, especially when radeon looks
to be providing framebuffer anyway? Is radeonfb module supporting even
some older hardware so it is keeped in kernel?

Maybe maintainers of Xorg will have better knowledge about this
radeon/radeonfb mess, than Kernel maintainers before reassigning or
closing bug.


Regards,
Witek

-- 
Witold Baryluk