Since I bought my new Radeon X550 PCIe I've been using the vesafb driver for the console framebuffer (1024x768 24 bit). Today I decided to test the radeonfb driver hoping to get a better refresh rate but the console was stuck to the default VGA 80x25. Looking through the kernel sources I noticed that the pci id of my card (5B63) was missing so I added the definition to drivers/video/aty/radeon_base.c, I recompiled the kernel (radeonfb builtin without other fb drivers) and rebooted. The console worked in a framebuffer mode with the desired refresh rate, resolution and depth color, but when X started and the system switched to vt7 there was a lockup; the screen became blank and the system became unresponsive to the keyboard, so I couldn't switch back to a console. I could however login with ssh from another machine and I could see that the X process was using 100% CPU and was unkillable. I saved the logs but apparently there isn't anything of interest; a diff with a old Xorg.0.log shows just a new IRQ for the dma control and some slightly different memory addresses. Before rebooting, I modified xorg.conf and commented out the 'Load "dri"' line: with this change X started again. I'm using xorg 7.2, mesa 6.5.2, libdrm 2.3.0, xf86-video-ati 6.6.3 and xorg-server 1.2.99.901.
Created attachment 9095 [details] Xorg.0.log Xorg log.
Created attachment 9096 [details] Relevant messages in the syslog archive. PS. I'm using a 2.6.20 kernel.
I can confirm this, I have the same behaviour with a Radeon X300SE PCIE card. Comes up fine with vesafb or VGA without any fb at all, but X server hangs with 100% CPU if radeonfb is compiled into the kernel.
Does the problem also occur when not enabling direct rendering?
No, if I compile a kernel with drm completely disabled, and only radeonfb compiled in, the xorg doesn't hang. So this "hanging @ 100% CPU" seems to be drm related. There are other issues, though. With radeonfb compiled in, X rendering is corrupted and slow (not usable). Everything works fine if I throw out radeonfb and use vesafb instead. With drm compiled in (without radeonfb), I have yet another problem: The second monitor of my dual head setup shows only a black picture...
radeonfb messes up the memory map setup for cards that require benh's new memory map setup, I think Ben has some fixes but hasn't had time to integrate/test them for the kernel..
This will probably never be fixed without KMS, which should provide more or less the same features as radeonfb anyway.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.