Blank screen when using usplash and kernel >= 2.6.25

[jdm64]

Binary package hint: linux-image-2.6.26-5-generic

The kernel that is going into Ubuntu 8.10 has a bug that (as far as I know hasn't been fixed in upstream 2.6.26). The problem is that when using a 2.6.25 or 2.6.26 kernel the screen blanks out when entering graphical mode after the boot splash (screen never comes back on). Also sometimes the computer will completely lock up in the middle of the boot splash. This problem is known to occur when using a Intel graphics card, the problem could effect other cards too (I haven't tested).

I've reported the bug (https://bugs.freedesktop.org/show_bug.cgi?id=15602) and have even found both the commit that introduced the bug (around 2.6.25-rc0) and the commit that fixes the bug (around 2.6.27-rc0). I would suggest that the commit that fixed the bug which is in 2.6.27 be backported to the 2.6.26 kernel that will go into 8.10.

I've tested the 2.6.26 Ubuntu kernel and can verify that it does still has the bug.

-----------------------------------------
This commit introduced the bug
-----------------------------------------
commit 8f4d37ec073c17e2d4aa8851df5837d798606d6f
Author: Peter Zijlstra <email address hidden>
Date: Fri Jan 25 21:08:29 2008 +0100

sched: high-res preemption tick

Use HR-timers (when available) to deliver an accurate preemption tick.

The regular scheduler tick that runs at 1/HZ can be too coarse when nice level
are used. The fairness system will still keep the cpu utilisation 'fair' by
then delaying the task that got an excessive amount of CPU time but try to
minimize this by delivering preemption points spot-on.

The average frequency of this extra interrupt is sched_latency / nr_latency.
Which need not be higher than 1/HZ, its just that the distribution within the
sched_latency period is important.

Signed-off-by: Peter Zijlstra <email address hidden>
Signed-off-by: Ingo Molnar <email address hidden>

:040000 040000 ab225228500f7a19d5ad20ca12ca3fc8ff5f5ad1
f1742e1d225a72aecea9d6961ed989b5943d31d8 M arch
:040000 040000 25d85e4ef7a71b0cc76801a2526ebeb4dce180fe
ae61510186b4fad708ef0211ac169decba16d4e5 M include
:040000 040000 9247cec7dd506c648ac027c17e5a07145aa41b26
950832cc1dc4d30923f593ecec883a06b45d62e9 M kernel

---------------------------------
This commit fixed the bug
---------------------------------
commit 31656519e132f6612584815f128c83976a9aaaef
Author: Peter Zijlstra <email address hidden>
Date: Fri Jul 18 18:01:23 2008 +0200

    sched, x86: clean up hrtick implementation

    random uvesafb failures were reported against Gentoo:

      http://bugs.gentoo.org/show_bug.cgi?id=222799

    and Mihai Moldovan bisected it back to:

    > 8f4d37ec073c17e2d4aa8851df5837d798606d6f is first bad commit
    > commit 8f4d37ec073c17e2d4aa8851df5837d798606d6f
    > Author: Peter Zijlstra <email address hidden>
    > Date: Fri Jan 25 21:08:29 2008 +0100
    >
    > sched: high-res preemption tick

    Linus suspected it to be hrtick + vm86 interaction and observed:

    > Btw, Peter, Ingo: I think that commit is doing bad things. They aren't
    > _incorrect_ per se, but they are definitely bad.
    >
    > Why?
    >
    > Using random _TIF_WORK_MASK flags is really impolite for doing
    > "scheduling" work. There's a reason that arch/x86/kernel/entry_32.S
    > special-cases the _TIF_NEED_RESCHED flag: we don't want to exit out of
    > vm86 mode unnecessarily.
    >
    > See the "work_notifysig_v86" label, and how it does that
    > "save_v86_state()" thing etc etc.

    Right, I never liked having to fiddle with those TIF flags. Initially I
    needed it because the hrtimer base lock could not nest in the rq lock.
    That however is fixed these days.

    Currently the only reason left to fiddle with the TIF flags is remote
    wakeups. We cannot program a remote cpu's hrtimer. I've been thinking
    about using the new and improved IPI function call stuff to implement
    hrtimer_start_on().

    However that does require that smp_call_function_single(.wait=0) works
    from interrupt context - /me looks at the latest series from Jens - Yes
    that does seem to be supported, good.

    Here's a stab at cleaning this stuff up ...

    Mihai reported test success as well.

    Signed-off-by: Peter Zijlstra <email address hidden>
    Tested-by: Mihai Moldovan <email address hidden>
    Cc: Michal Januszewski <email address hidden>
    Cc: Antonino Daplas <email address hidden>
    Signed-off-by: Ingo Molnar <email address hidden>

:040000 040000 5ae152350652713c58bd1700ba2c776a556b6985
40d22771987dc5814a1e18aa3cee82ae9e4faea5 M arch
:040000 040000 4dfe3c6abd244d2da57b7801e47f073899124376
3863e3311a21dc049d5ad98f45c272e4a5269a2b M include
:040000 040000 236b2824be1c7cf3c899a090498e4151543bba31
9f9779c89b781d8fa8950468deee42f419339bd7 M kernel

[jdm64 (jdm64)]

It seems that the commit that went into 2.6.27 can't be backported to .26. But, hrtick, what is causing the problem, can be disabled.

The patch to disable hrtick that applies on a vanila 2.6.26.2 kernel and should also apply to Ubuntu's kernel is below. That patch (or similar) should go into 2.6.26.3 or 2.6.26.4. See discussion here:

    http://lkml.org/lkml/2008/8/19/311

-----------------

The hrtick implementation in 2.6.25 and .26 has been known to cause boot
problems with at least Intel GMA cards. see:

 https://bugs.freedesktop.org/show_bug.cgi?id=15602
 http://bugzilla.kernel.org/show_bug.cgi?id=10892

A full fix to hrtick went into 2.6.27
(31656519e132f6612584815f128c83976a9aaaef),
but that fix is too intrusive to backport. Henceforth, we default to
disable hrtick.

Signed-off-by: Justin Madru <email address hidden>
Tested-by: Justin Madru <email address hidden>
Cc: Peter Zijlstra <email address hidden>
Cc: Ingo Molnar <email address hidden>

--- a/kernel/sched_features.h
+++ b/kernel/sched_features.h
@@ -4,7 +4,7 @@
 SCHED_FEAT(AFFINE_WAKEUPS, 1)
 SCHED_FEAT(CACHE_HOT_BUDDY, 1)
 SCHED_FEAT(SYNC_WAKEUPS, 1)
-SCHED_FEAT(HRTICK, 1)
+SCHED_FEAT(HRTICK, 0)
 SCHED_FEAT(DOUBLE_TICK, 0)
 SCHED_FEAT(NORMALIZED_SLEEPER, 1)
 SCHED_FEAT(DEADLINE, 1)

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[Khairul Aizat Kamarudzzaman (fenris)]

i got bump :(

linux-image-2.6.26-5-generic = blank screen after boot splash
linux-image-2.6.27-1-generic = conflict with firmware

[jdm64 (jdm64)]

Well, if the Ubuntu kernel hasn't diverged that far from the mainline .27-rc kernel then the problem should be fixed. The blank screen bug is only the result of a broken implementation of HR-Tick that is only in 2.6.{25,26} (at least as far as I know). HR-Tick was fixed when the merge window opened for the .27 kernel. I do weekly rebuilds for every -rc kernel off of Linus' git tree (and now -next), and can confirm the problem is fixed there. So, if the Ubuntu kernel has only done back-porting of drivers and bug fixes (and not touched hrtick), then the blank screen bug should have been fixed.

I'll do an "official" test of the Ubuntu kernel when Alpha-5 comes out.

[Khairul Aizat Kamarudzzaman (fenris)]

thanks jdm64

now im using linux-image-2.6.27-2-generic, blank screen appear after bootsplash , before the login window. hope it will be fix in Alpha 5 which is in a few days more .. ill update back after Alpha 5 out ..

[jdm64 (jdm64)]

I tested the linux-image-2.6.27-2-generic kernel, but on _hardy_. No blank screen problems or garbled splash screen.
I'm not ready to do an upgrade to ibex for a full test until at least the first beta (can't loose data or time as I use my computer daily).

[kirth_gersen25 (kirth-gersen)]

Excuse me for my english but i'm not very well enough. When I start on the pc, the screen on the my two
monitors is black with the blinking cursor, but after reboot, if i try recovery mode and then:

- try "xfix" --> menù recovery mode

- try "resume" --> menù recovery mode

- the login apperars but only in one monitor and then i press "alt+f1" and then restore my xorg backup with

- sudo cp /etc/xorg.conf_backup xorg.conf

and then ctrl+alt+backspace or sudo /etc/init.d/gdm restart

magically the login will appears and the two monitor is functioning very well. But i do this every time, if i
try without recovery mode, the screen is always black.

My kernel is 2.6.27-3 on ubuntu 8.10 alpha 5. I have the intel quad core q6600, nvidia geforce 8800 gts 512 mb,
a raid with 2 western digital 250 gb, 1 sata 250 gb western digital, 1 quantum fireball 200 gb, 4 gb ddr3 xtreem.

P.S. This problem will appears even if the monitor is only one.

[Nemes Ioan Sorin (nemes-sorin)]

hmm - just upgraded from Hardy to Ibex - upgrade OK - after reboot - just a blank screen after bootloader.
attached my .xsession log.

dpkg tell me all ok, `xfix` can not do anything, xorg.conf is 'dpkg-reconfigure'it, `resume` send me back to the blank screen, sudo /etc/init.d/gdm restart -> put me back to the black screen figure..

I have 2.6.27-6 generic kernel

some directions from here ??

thanks in advance.

[Nemes Ioan Sorin (nemes-sorin)]

UPDATE - Problem Solved ( at least for me )...

I put radeonhd video driver instead of Update-Manager chosen driver.
It works.

But the problem is still HOT because the Update-Manager ( during upgrade process ) don't recognize my RadeonHD so he chose for me a wrong driver >>> then the blank screen and the rest ....

If this will be not solved ...a lot of Ubuntu Hardy machines (with RadeonHD) ..upgrading to Ibex will have the same problem.

[Andy Whitcroft (apw)]

Unfortunately it seems this bug is still an issue. Can you confirm this issue exists with the most recent Jaunty Jackalope 9.04 release - http://www.ubuntu.com/news/ubuntu-9.04-desktop . If the issue remains in Jaunty, Please run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux-image-2.6.28-11-generic <bug #>

If you could also test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine this 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!

[Jeremy Foshee (jeremyfoshee)]

This bug report was marked as Incomplete and has not had any updated comments for quite some time. As a result this bug is being closed. Please reopen if this is still an issue in the current Ubuntu release http://www.ubuntu.com/getubuntu/download . Also, please be sure to provide any requested information that may have been missing. To reopen the bug, click on the current status under the Status column and change the status back to "New". Thanks.

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