plymouth in quantal on arm does only boot with black screen

Bug #1018907 reported by Oliver Grawert
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
plymouth (Ubuntu)
Fix Released
High
Ricardo Salveti
Quantal
Fix Released
High
Ricardo Salveti

Bug Description

during the debugging of bug 1010009 it was found that plymouth only shows a black screen on boot in precise instead of showing the splash screen on boot . shutting down results in proper shutdown splash behavior though.

Tags: iso-testing

Related branches

Revision history for this message
Oliver Grawert (ogra) wrote :

whoops, ignore teh first logfile, that was actually a boot without splash... new log attached

Revision history for this message
Oliver Grawert (ogra) wrote :
Revision history for this message
Oliver Grawert (ogra) wrote :

downgrading the following packages to their 12.04 versions seems to fix everything ...

libplymouth2
plymouth
plymouth-label
plymouth-theme-ubuntu-logo
plymouth-theme-ubuntu-text

summary: - plymouth in quantal on arm does only boot with black sccreen
+ plymouth in quantal on arm does only boot with black screen
Revision history for this message
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1018907

tags: added: iso-testing
Revision history for this message
Steve Langasek (vorlon) wrote :

The log shows:

[ply-renderer.c] ply_renderer_open_plugin:trying to open renderer plugin /lib/plymouth/renderers/drm.so
[...]
[./plugin.c] load_driver:Attempting to load driver 'omapdrm'
[...]
[ply-renderer.c] ply_renderer_open_plugin:opened renderer plugin /lib/plymouth/renderers/drm.so
[...]
[./plugin.c] ply_renderer_head_map:Creating buffer for 1920x1200 renderer head
[./ply-renderer-libkms-driver.c] create_buffer:Could not allocate GEM object for frame buffer: 22

So the kernel is exposing a DRM interface which is not usable by plymouth (or, according to what Oliver tells me on IRC, by anything else either). Either the kernel needs fixed, or we need to blacklist omapdrm so that we fall back to the framebuffer renderer instead, which is what was used in precise and earlier.

Revision history for this message
Oliver Grawert (ogra) wrote :

confirming that an:
rm /lib/plymouth/renderers/drm.so

fixes the issue on the pandaboard, i will research the issue on tegra ac100 tomorrow so we can see if thats similar.

Revision history for this message
Brian Murray (brian-murray) wrote :

I deleted the first log file that was incorrect. You can do this by clicking the pencil icon by the attachment name.

Changed in plymouth (Ubuntu):
importance: Undecided → High
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in plymouth (Ubuntu):
status: New → Confirmed
tags: added: rls-q-incoming
Revision history for this message
Brian Murray (brian-murray) wrote :

Removing the rls-q-incoming task as this is already targetted for fixing in Q.

tags: removed: rls-q-incoming
Changed in plymouth (Ubuntu Quantal):
status: Confirmed → Triaged
Revision history for this message
Oliver Grawert (ogra) wrote :

digging deeper into this, there is now a libdrm-omap1in the archive, i suspect that will need someone to write a proper omap drm handler for plymouth (and also link plymouth agaist the omap stuff of libdrm)

additionally libdrm-omap1 as well as the new drm capable xserver-xorg-video-omap need to go onto the panda images

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 1018907] Re: plymouth in quantal on arm does only boot with black screen

On Wed, Aug 15, 2012 at 02:28:14PM -0000, Oliver Grawert wrote:
> digging deeper into this, there is now a libdrm-omap1in the archive, i
> suspect that will need someone to write a proper omap drm handler for
> plymouth (and also link plymouth agaist the omap stuff of libdrm)

Why do we need a separate drm handler for plymouth? Why doesn't this work
with the generic drm backend?

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Revision history for this message
Rob Clark (rob-ti) wrote :

if plymouth will fall back to the "dumb scanout buffer" ioctl, it should work.. I'd have to look at plymouth src code to see if this is actually how it does work. If plymouth uses libkms then this should be automatic.

Revision history for this message
Oliver Grawert (ogra) wrote :
Revision history for this message
Ricardo Salveti (rsalveti) wrote :

Testing with http://cdimage.ubuntu.com/daily-live/20120815/quantal-desktop-armhf+omap4.img, still at the first boot (installer), I got a different behavior:

[ply-renderer.c] ply_renderer_open_plugin:trying to open renderer plugin /lib/plymouth/renderers/drm.so^M
[./plugin.c] create_backend:creating renderer backend for device /dev/dri/card0^M
[./plugin.c] load_driver:Attempting to load driver 'omapdrm'^M
[ply-terminal.c] ply_terminal_open:trying to open terminal '/dev/tty7'^M
[ply-terminal.c] ply_terminal_look_up_geometry:looking up terminal text geometry^M
[ply-terminal.c] ply_terminal_look_up_geometry:terminal is now 240x67 text cells^M
[ply-terminal.c] get_active_vt:Remembering that initial vt is 1^M
[./plugin.c] query_device:Could not initialize heads^M
[ply-renderer.c] ply_renderer_open_plugin:could not query rendering device for plugin /lib/plymouth/renderers/drm.so^M
[./plugin.c] close_device:closing device^M
[./plugin.c] unload_driver:unloading driver^M
[./ply-renderer-libkms-driver.c] destroy_driver:uninitializing kms buffer driver^M
[ply-renderer.c] ply_renderer_open_plugin:trying to open renderer plugin /lib/plymouth/renderers/frame-buffer.so^M
[./plugin.c] create_backend:creating renderer backend for device /dev/fb0^M
[ply-terminal.c] ply_terminal_open:terminal /dev/tty7 is already open^M
[./plugin.c] query_device:32 bpp (8, 8, 8, 8) with rowstride 8192^M
[./plugin.c] initialize_head:initializing 1920x1080 head^M

The splash worked, but because for some reason it failed to query the device for omapdrm. I'm waiting the installer to finish and will test it again with proper debug after it's done.

Revision history for this message
Ricardo Salveti (rsalveti) wrote :

At the attached patch I included a patch already available at upstream, that adds a new generic driver for the drm renderer plugin.

This generic driver is supposed to work on radeon, nouveau and omap, and any other generic use case using the drm driver. As the plymouth package implies at a bunch of ubuntu specific changes, I decided to just backport this patch instead of rebasing it on top of 0.8.5.1.

I also had to include another fix related with the new libdrm package (2.4.38), which changes the old nouveau library to libdrm_nouveau1, otherwise the nouveau plugin would be linked with the wrong libdrm nouveau implementation.

And, as a side effect, I had to update the autoreconf.patch, making the debdiff quite large, but due differences on using a newer autoconf/automake than the one previously used when the patch was previously updated.

Tested on Pandaboard and I can now see the splash screen during boot. Will attach plymouth.log as well.

Revision history for this message
Ricardo Salveti (rsalveti) wrote :
Changed in plymouth (Ubuntu Quantal):
assignee: nobody → Ricardo Salveti (rsalveti)
status: Triaged → In Progress
Revision history for this message
Ricardo Salveti (rsalveti) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package plymouth - 0.8.4-0ubuntu2

---------------
plymouth (0.8.4-0ubuntu2) quantal; urgency=low

  * debian/patches/upstream-add-generic-driver-to-drm-renderer-plugin.patch:
    - Add the generic driver to the drm render plugin, which is the only one
      supported on latest upstream, working also for omap. Not yet disabling
      the others, as they can still be used in case the generic one fails,
      which keeps plymouth safe for x86 (LP: #1018907)
  * debian/patches/update-libdrm-nouveau-library-dependency.patch:
    - Old nouveau driver is now called libdrm_nouveau1 at the latest libdrm
      package (>= 2.4.38)
  * Refresh autoreconf.patch.
 -- Ricardo Salveti de Araujo <email address hidden> Thu, 16 Aug 2012 01:53:54 -0300

Changed in plymouth (Ubuntu Quantal):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.