[powerpc] built-in radeonfb driver prevents KMS from running

Please boot with the option 'plymouth:debug=file:/var/log/plymouth-debug.log' and attach the resulting log.

Please find attached the log.
When I boot with the option you specified although the machine boot up, GDM never came up. Is that expected?

Ok, here's the critical section of the log:

[./plugin.c] create_backend:creating renderer backend for device /dev/dri/card0
[./plugin.c] load_driver:Attempting to load driver '(null)'
[./plugin.c] load_driver:drmOpen failed
[ply-renderer.c] ply_renderer_open:could not open rendering device for plugin /lib/plymouth/renderers/drm.so
[./plugin.c] create_backend:creating renderer backend for device /dev/fb0
[ply-terminal.c] ply_terminal_open:trying to open terminal '/dev/tty7'
[ply-terminal.c] ply_terminal_look_up_geometry:looking up terminal text geometry
[ply-terminal.c] ply_terminal_look_up_geometry:terminal is now 128x48 text cells
[./plugin.c] query_device:Visual was FB_VISUAL_PSEUDOCOLOR, trying to find usable mode.
[./plugin.c] query_device:Visual is FB_VISUAL_DIRECTCOLOR; not using graphics
[ply-renderer.c] ply_renderer_open:could not query rendering device for plugin /lib/plymouth/renderers/frame-buffer.so

So the DRM driver is failing to load; and the fallback to the framebuffer driver also fails (as expected - bug #564471) because there's no truecolor fb available.

The question is, why does the drm driver fail to load?

Please show the output of:

$ readlink /sys/dev/char/$((0x$(stat -c '%t' /dev/dri/card0))):$(stat -c '%T' /dev/dri/card0)/device/driver
$ ls -l /sys/dev/char/$((0x$(stat -c '%t' /dev/dri/card0))):$(stat -c '%T' /dev/dri/card0)/device/driver/

This may indeed be an arch-specific bug with the driver not being correctly exposed under sysfs.

> When I boot with the option you specified although the machine boot up, GDM
> never came up. Is that expected?

No, it's not.

Both commands fail.

onkar@iBook:~$ readlink /sys/dev/char/$((0x$(stat -c '%t' /dev/dri/card0))):$(stat -c '%T' /dev/dri/card0)/device/driver
stat: cannot stat `/dev/dri/card0': No such file or directory
stat: cannot stat `/dev/dri/card0': No such file or directory
onkar@iBook:~$ ls -l /sys/dev/char/$((0x$(stat -c '%t' /dev/dri/card0))):$(stat -c '%T' /dev/dri/card0)/device/driver/
stat: cannot stat `/dev/dri/card0': No such file or directory
stat: cannot stat `/dev/dri/card0': No such file or directory
ls: cannot access /sys/dev/char/0:/device/driver/: No such file or directory

Is udev running on this system? Does /dev/dri show anything at all? I see from your /proc/modules that the drm driver is loaded and referenced, but OTOH, /proc/fb appears to list a non-drm framebuffer.

udev is running. This is standard Ubuntu installation upgraded from karmic.
onkar@iBook:~$ ps -ef |grep udev
root 240 1 0 10:46 ? 00:00:00 upstart-udev-bridge --daemon
root 244 1 0 10:46 ? 00:00:00 udevd --daemon
root 661 244 0 10:46 ? 00:00:00 udevd --daemon
root 667 244 0 10:46 ? 00:00:00 udevd --daemon
onkar 28737 4904 0 12:39 pts/1 00:00:00 grep udev

There is no device /dev/dri*.
onkar@iBook:~$ ls /dev/dri*
ls: cannot access /dev/dri*: No such file or directory

I am also hit by bug 570228. Apparently this bug is the cause of /dev/dri* not being present. When I turn off KMS the device node is present - /dev/dri/card0.

I found a relevant thread here - http://us.generation-nt.com/answer/how-activate-kms-radeon-video-card-powerpc-help-196523701.html
According to comments in the thread 'radeonfb' prevents KMS from taking ownership of the GPU. radeonfb is built into kernel. So I tried passing 'video=radeonfb:off' argument to kernel. But then the display fails to come up. So I guess radeonfb is needed at some point of time in boot process.
Is it possible to built radeonfb as module instead of in kernel, so that it is loaded/unloaded on need basis?

Possible, yes - reassigning this bug to the kernel package for follow-up.

Hi Onkar,

If you could also please test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

I am ready to test latest upstream kernels if powerpc build is made available. As of now they are available only for i386 and amd64.