Boot splash screen messed up with ATI fglrx drivers

[Martin Eve]

Binary package hint: plymouth

Maverick beta 10.10.

Crypted boot per guided installation on Alternate CD.

Booting without the FGLRX graphics driver is slick and smooth.

Booting with it drops down to a far rougher version (for instance text to enter crypt password is massively off centre and looks more like a terminal)

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: plymouth 0.8.2-2ubuntu5
ProcVersionSignature: Ubuntu 2.6.35-19.28-generic 2.6.35.3
Uname: Linux 2.6.35-19-generic i686
NonfreeKernelModules: fglrx
Architecture: i386
Date: Sun Sep 26 10:57:28 2010
DefaultPlymouth: /lib/plymouth/themes/ubuntu-logo/ubuntu-logo.plymouth
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Alpha i386 (20100831.2)
MachineType: TOSHIBA Satellite C650D
ProcCmdLine: BOOT_IMAGE=/vmlinuz-2.6.35-19-generic root=/dev/mapper/hostname-root ro acpi=copy_dsdt quiet splash
ProcEnviron:
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
ProcFB:

SourcePackage: plymouth
TextPlymouth: /lib/plymouth/themes/ubuntu-text/ubuntu-text.plymouth
dmi.bios.date: 05/19/2010
dmi.bios.vendor: Insyde Corp.
dmi.bios.version: 1.40
dmi.board.asset.tag: No Asset Tag
dmi.board.name: Portable PC
dmi.board.vendor: TOSHIBA
dmi.board.version: Base Board Version
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: AMD
dmi.chassis.version: None
dmi.modalias: dmi:bvnInsydeCorp.:bvr1.40:bd05/19/2010:svnTOSHIBA:pnSatelliteC650D:pvrPSC16E-01Q007EN:rvnTOSHIBA:rnPortablePC:rvrBaseBoardVersion:cvnAMD:ct10:cvrNone:
dmi.product.name: Satellite C650D
dmi.product.version: PSC16E-01Q007EN
dmi.sys.vendor: TOSHIBA

[Fred van Zwieten (fvzwieten)]

I have this too on rc1

[iMac (imac-netstatz)]

I have the released 10.10 with and ATI card and plymouth falls back on the plymouth-text splash screen. I suspect this is the same problem I currently see on at least 3 other ATI GPU maverick system configurations here (all upgraded from Lucid), some laptops, others desktops. I'll do my best to get others to note this affects them.

On my particular laptop, when I remove the fglrx drivers and fall back on the open source radeon, the graphical boot only works after I additionally add a "sleep 2" to the end of "/usr/share/initramfs-tools/scripts/init-top/framebuffer" and rebuilding the initrd image. Without this flag I see my text-splash get resized after initially appearing, indicating a separate race that may be specific to my machine that I noted from Steve L's comments in another related bug. In any case without fglrx installed I see a graphical splash on shutdown. Perhaps a separate bug should be filed for this race condition issue, as it prevents people from correctly identifying the specific impact of the fglrx proprietary drivers.

Initrd image file listing output (below) verifies my plymouth packages installation, and I performed an uninstallation/re-installation of the plymouth packages early in my debugging process.

In my plymouth debug log (below), I can clearly see no supported renderers with the fglrx loading. I additionally verified using break=modules that the text-splash loaded to rule out any race conditions like the ones seen with the opensource drivers. In this case the "/sbin/plymouthd --mode=boot --pid-file=/dev/.initramfs/plymouth.pid resulted once again in plymouth-text splash. No /dev/fb0 (like with the opensource drivers) was present or noted in the dmesg.

Finally, with X loaded I can see the graphical splash (resized at a lower resolution than my native WSXGA+ 1680x1040) show by executing
  sudo plymouthd
  sudo plymouth --show-splash

-- plymouth debug --
[./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
[./plugin.c] open_device:could not open '/dev/fb0': No such file or directory
[ply-renderer.c] ply_renderer_open:could not open rendering device for plugin /lib/plymouth/renderers/frame-buffer.so
[./plugin.c] open_device:could not open '/dev/fb0': No such file or directory
[ply-renderer.c] ply_renderer_open:could not open rendering device for plugin /lib/plymouth/renderers/vga16fb.so
[ply-renderer.c] ply_renderer_open:could not find suitable rendering plugin
[main.c] add_default_displays_and_keyboard:could not open renderer /dev/fb

root@repo:/home/imac# zcat /boot/initrd.img-$(u...

[iMac (imac-netstatz)]

Additionally, the card used for my debug has 256MB onboard shown in lspci below, as I noted a comment in #554143 relating to ati cards with <=32Mb having the console dropped to 8bpp by a kernel patch.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=47381156a8f0d793bacfa346cc4cc515399525f7

01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3400 Series (prog-if 00 [VGA controller])
 Subsystem: Hewlett-Packard Company Device 30fc
 Flags: bus master, fast devsel, latency 0, IRQ 47
 Memory at c0000000 (32-bit, prefetchable) [size=256M]
 I/O ports at 7000 [size=256]
 Memory at d2300000 (32-bit, non-prefetchable) [size=64K]
 Expansion ROM at d2320000 [disabled] [size=128K]
 Capabilities: [50] Power Management version 3
 Capabilities: [58] Express Legacy Endpoint, MSI 00
 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
 Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
 Kernel driver in use: fglrx_pci
 Kernel modules: fglrx, radeon

My full plymouth debug log is attached here too

[iMac (imac-netstatz)]

I found a solution to this problem, possibly one that can be addressed through a configuration patch to grub2.

When my system boots to grub, I selected 'c' for command-line, and issued "vbeinfo" to figure out what vesa video modes my particular card supports. Interestingly 640x480 is not on the list :). 1400x1050 was the highest listed on my ATI adapter to use on my 1680x1050 panel.

using this information, I simply added

 GRUB_GFXPAYLOAD_LINUX=1400x1050

to /etc/default/grub and issued an update-grub.

This gave me the standard/unchanged low resolution grub menu that "paints" quickly and is easy to read, but allowed the graphical splash to work at the highest resolution possible, which is also used for my tty's .. which is great too for console real-estate outside of X.

Note, this is NOT the option that appears commented out in /etc/default/grub by default. Changing this more obvious option to a valid resolution (indicated by vbeinfo) and uncommenting it affects the resolution of the grub menu itself. This new option I added, shown above, additionally 'passes' on a mode to the linux kernel whereby plymouth picks it up. (if I'm not mistaken)

This works without any messing with initramfs config files, uvesafb modules or kernel command line parameters directly which likely makes it more future-compatible with a permanent fix as this change can be more managed by dpkg upgrades. I suspect a few other non-ATI graphical splash issues may be workable using this grub option also.

Attached is my new plymouth-debug output, which includes the following line that shows the rendering device being selected.

[./plugin.c] create_backend:creating renderer backend for device /dev/fb0

[Martin Eve (martineve)]

Just for the record, on the Toshiba Satellite system from which I submitted the original bug, the problem is note resolved by adding:

 GRUB_GFXPAYLOAD_LINUX=1400x1050

to the grub config and in fact resulted in serious system slowdown. Perhaps the resolution was too high?

[iMac (imac-netstatz)]

If the console output is too slow (which I assume is what you mean in serious system slowdown), decrease the resolution. I have a couple of lesser powered ATI cards (HD3200) where I notice super-slow consoles on the higher, unaccelerated, vesa modes they support. I just take these down to lower resolutions for this workaround.

Things just appear slow .. but its actually just your display, which has a buffer. Without "quiet" and in the higher resolution it will take longer to boot if your console is slow and you have to wait for the output to complete. Just decrease your resolution, maybe down to plain VGA and use *quiet* and your speed issues should go away until this is fixed in an elegant way.

[Martin Eve (martineve)]

Hi,

No, what I meant was that GNOME was *incredibly* slow with this option enabled. I will, however, try a lower res.

Martin

[iMac (imac-netstatz)]

This issue has not gone away with 11.04 ... It would be nice to get back to the graphics quality and speedy consoles of the pre-maverick releases. I consider this a big unresolved regression for ATI users and seemed to make no headway since 10.10.

[iMac (imac-netstatz)]

Attached is my boot screen with the default package configuration defined in /etc/default/grub

imac@repo:~$ cat /etc/default/grub | grep -v "#" | grep -v ^$
GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="splash"
GRUB_CMDLINE_LINUX=""

Sorry for the fantastic phone quality photo with glare

[iMac (imac-netstatz)]

Here is my shutdown screen too. note in this case I get the graphical dots painted over the text.

[Martin Eve (martineve)]

Interesting; my boot screen is, at least, centered but nevertheless looks like that.

If I uninstall FGLRX, I end up with the boot screen moved to the top left, as per your example, but then GDM won't start (!)

[iMac (imac-netstatz)]

This is on my HD3400 with 256MB onboard (see below). On a similar dv5 with HD3200, same output but centered (scaled to 80 columns).

01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3400 Series (prog-if 00 [VGA controller])
 Subsystem: Hewlett-Packard Company Device 30fc
 Flags: bus master, fast devsel, latency 0, IRQ 47
 Memory at c0000000 (32-bit, prefetchable) [size=256M]
 I/O ports at 7000 [size=256]
 Memory at d2300000 (32-bit, non-prefetchable) [size=64K]
 Expansion ROM at d2320000 [disabled] [size=128K]
 Capabilities: [50] Power Management version 3
 Capabilities: [58] Express Legacy Endpoint, MSI 00
 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
 Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
 Kernel driver in use: fglrx_pci
 Kernel modules: fglrx, radeon

Part of the problem is that the video card does store video mode information across boots. For instance, I do see some changes in the video mode used if I boot into Ubuntu+FGLRX after using the Debian+radeon during the previous boot. I attached a screenshot here showing this different console mode after using radeon, with no changes to my ubuntu configuration or grub.

Sometimes I also see one instance of the proper shutdown screen (with graphical logo) after previously booting into radeon as well. Attached is what my console looks like after previous boot into radeon. I note that Ubuntu does not have a "setting console mode" process on boot like debian does which creates nice consistent good looking fonts and sizes for its console no matter the video driver being used, or the previous mode used.

My point in sharing these observations is to make it clear to others that this bug, as Martin noted, is not the video mode used on the console, but the use of a non-graphical console mode on boot and shutdown instead of the Ubuntu logo and "progress dots" we are used to seeing when using FGLRX.

[iMac (imac-netstatz)]

I have found a way to make the graphical screen appear on boot. In my case I removed one of my RAID 1 disks that is used for my home directory mount point. This gave me the attached screen shot to drop to a recovery console. After exiting the recovery console after starting the degraded array, the graphical boot screen appeared as it should followed by the login screen.

[iMac (imac-netstatz)]

I have also found a way to make the graphical screen appear on shutdown. In my case I drop to console at the login screen (ATL-CTRL-F1) and login as root. When I type reboot, I instantly see the proper graphical screen as attached.

[Paul van Genderen (paulvg)]

Configuring GRUB_GFXPAYLOAD_LINUX is detrimental, any fsck or mount prompt will not appear. Instead, the screen remains blank.

[Alexandrosg (alexandrosg)]

Still exists on precise

[Max Tamer-Mahoney (max-tamermahoney)]

Still exists on quantal