mxcfb framebuffer driver crashes the board hard on attempt to use a different resolution than the one specified on cmdline

[Oliver Grawert]

on imx51 hardware that uses mxcfb if you do the following it crashes the machine into a halt:

switch to tty1
run: usplash -c

this is caused by the fact that usplash if no resolution is specified either in usplash.conf or as commandline args will default to display the smallest theme possible and adjust itself to the size of this theme. the smallest theme possible it finds is usually 640x480, so the above tries to display a 640x480 screen on the 1024x768 (default setting for mxcfb in our images and setup). the mxcfb driver should not hardlock the device but either properly scale up the usplash screen like all other frambuffer drivers do or at least fail gracefully and properly switch back to its former console if 640x480 can not be displayed. it should definately not halt the system.

just to proof the concept, running the following on a tty in the current karmic live images for babbage will work fine:

usplash -c -x 1024 -y 768

ProblemType: Bug
Architecture: armel
Date: Fri Aug 28 14:01:25 2009
DistroRelease: Ubuntu 9.10
LiveMediaBuild: Ubuntu 9.10 "Karmic Koala" - Alpha armel+imx51 (20090828.2)
Package: linux-image-2.6.31-100-imx51 2.6.31-100.7
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-100.7-imx51
SourcePackage: linux-fsl-imx51
Uname: Linux 2.6.31-100-imx51 armv7l

[Loïc Minier (lool)]

I think it also hangs on shutdown (even with the workaround) if you have console=ttymxc0 last on your kernel cmdline.

[Loïc Minier (lool)]

Freescale commented over private email that:
"This seems like an artifact of x86 and expecting there to be a VGA BIOS. The app should deal with the resolution it gets. We should be able to switch to 640x480 with a monitor and it certainly shouldn't crash in our driver. There is no ability to scale the framebuffer though. So while we could change to 640x480 with a monitor, that would not work in the case of a discrete LCD."

[Loïc Minier (lool)]

Yes, we realize setting the resolution to 640x480 is not likely to work and not likely to be what we want in the end; usplash has some logic for picking the highest resolution supported by the video output backend and the configured theme. We didn't get as far as debugging why it's not trying to use the highest resolution, perhaps it's not reading the current resolution from the kernel properly, but when we started looking into the splash screen issue this system hang showed up.
  So in all cases usplash shouldn't be able to hand the whole system; this is what the bug is about.

We've put a workaround in place (we read the resolution set on the kernel cmdline and pass that to usplash) but that's less than ideal because:
- we'd like to not hardcode the resolution anywhere; it should be
  autodetected with EDID and reported to userspace
- we rely on fragile cmdlibe parsing
- usplash is still able to hang the system in some cases (might be
  another bug)

[Loïc Minier (lool)]

The workaround consist of creating a /etc/usplash.conf with proper values; since it's created in the initramfs it should be easy to reproduce the issue by just issuing "usplash -c" on a running system as suggested in the bug report, but you can rm /etc/usplash.conf if you have that file installed.

Works:
    rm -f /etc/usplash.conf
    virtual_size="`cat /sys/class/graphics/fb0/virtual_size`"
    usplash -p -c -x "${virtual_size%,*}" -y "${virtual_size#*,}"

Hangs system:
    rm -f /etc/usplash.conf
    usplash -p -c

[Loïc Minier (lool)]

Low prio since we have the usplash workaround in place

[Ann Thornton (ann-thornton)]

The crash only occurs on a live image. I installed the image and could no longer get it to crash. The monitor just complains that it can't display the requested resolution, but does not crash.

[Loïc Minier (lool)]

We have a good workaround in karmic already

[Rolf Leggewie (r0lf)]

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".