Monitor goes black ("no signal") after Grub, comes back to life when X starts

[Baokai Lei]

After selecting an entry from the Grub menu and booting starts, the screen goes blank, and the monitor displays "no signal". When booting ends and X starts up, the screen comes back to life, and the LightDM login screen appears.
I'm using a Radeon HD 6850 with the opensource driver.

Kernel version: 3.5.0-15.23-generic 3.5.4

This is a regression, as the issue wasn't present with an earlier 3.5 kernel.
When I updated recently, I updated to kernel version 15.22, which exposed the issue. Updating to a newer version (.23) did nothing to fix the issue.

Update: Installing the kernels did not fix the issue either:
3.5.0-16.24, 3.5.0-16.25

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: linux-image-3.5.0-13-generic 3.5.0-13.14
                                      3.5.0-14.15, 16, 17, 18, 19
                                      3.5.0-15.20, 21, 22, 23, 24
                                      3.5.0-16.25
ProcVersionSignature: Ubuntu 3.5.0-15.23-generic 3.5.4
Uname: Linux 3.5.0-15-generic x86_64
ApportVersion: 2.5.2-0ubuntu4
Architecture: amd64
Date: Thu Sep 27 15:25:08 2012
InstallationMedia: Kubuntu 12.10 "Quantal Quetzal" - Beta amd64 (20120913)
ProcFB: 0 radeondrmfb
SourcePackage: linux

Update: Apparently the Ubuntu kernels can't handle the "vt.handoff=7" option properly, which causes the black screen.
See my comment below for how to fix it:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1057532/comments/38

[Lucazade (lucazade)]

same here with a Radeon HD3000 and with a Mobility Radeon 7500

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.6 kernel[0] (Not a kernel in the daily directory) and install both the linux-image and linux-image-extra .deb packages.

Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. Please only remove that one tag and leave the other tags. 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.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-rc7-quantal/

[Baokai Lei (leibaokai)]

Using the kernel 3.6 rc7 from the mainline now.
The bootscreen works fine, so the bug is fixed here :D

I've installed the kernel manually now. Is there a way to add a Launchpad repository for the kernel, so you always have the latest kernel installed, without having to do it manually?

[Lucazade (lucazade)]

those kernel are vanilla.. without any ubuntu patches. I would not use them if not for testing.
I hope the issue is going to be fixed in stock 3.5 with a backport.

[Joseph Salisbury (jsalisbury)]

I'd like to perform a reverse bisect to figure out which commit upstream fixes this regression. It would be very helpful to know the last kernel that had this issue and the first kernel that did not.

Can you test the following kernels and report back? We are looking for the first kernel version that doesn't have this bug:

v3.6-rc1: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-rc1-quantal/
v3.6-rc3: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-rc3-quantal/
v3.6-rc5: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-rc5-quantal/

You don't have to test every kernel, just up until the kernel that first does not have this bug.

Thanks in advance!

[Baokai Lei (leibaokai)]

I've downloaded all three rcs you listed, installed rc1, rebooted... and lookit there, already rc1 works fine and has the bug fixed :D
Now that was quick. No need anymore for the other two.

[Joseph Salisbury (jsalisbury)]

Can you test two additional kernels? Can you test upstream v3.5.3[0] and v3.5.4[1]? I'd like to confirm the regression was introduced in v3.5.4.

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.5.3-quantal/
[1] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.5.4-quantal/

[Baokai Lei (leibaokai)]

I've installed and tested now both mainline kernels, 3.5.3 and 3.5.4.
Both kernels work fine and display the bootscreen as they should.

To check back, I've booted into 3.5.0-15.23 again, and yes, the black screen during boot is still the very same there.

[Baokai Lei (leibaokai)]

I've taken a look at the mainline kernel index to get the next 3.5 kernel after 3.5.4 for testing - however, there is no next 3.5 kernel.
The kernel following 3.5.4 is 3.6-rc1.

As none of the mainline kernels exhibits the bug, apparently one of the modifications that Ubuntu did to the mainline kernel is the cause for the black screen during boot.

[Joseph Salisbury (jsalisbury)]

Can you test the latest Quantal image in the -proposed repository?

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed.

Thank you in advance!

[Baokai Lei (leibaokai)]

I'm already using proposed, so I just reloaded the software list and installed the new kernel 3.5.0-16.24 which it offered.
On reboot though, it sadly exhibited the same black screen bug as before with .23, no change there.

[Lucazade (lucazade)]

Could it be a bug in Grub 2.0? Maybe not correctly patched against vt.handoff=7?
Because if I temporary remove the grub_gfx_payload option from grub everything work ok.

[Baokai Lei (leibaokai)]

No, it's not a Grub bug. I initially wasn't using any grub_gfx_payload option, but the bug was the same, in Grub 1.99 as well as in Grub 2.00. Then I added it, and while the resolution of the Grub menu changed properly, it nothing about the black screen bug.

It's a kernel regression. I've now installed and booted into the new kernel 3.5.0-16.25 that was offered today. Also here though, no change, still a black screen during boot - all the same.

I've updated the desription above, listing all kernels with which I had the black screen bug appearing.

[Joseph Salisbury (jsalisbury)]

@Baokai Lei,

I would like to perform a kernel bisect to identify the commit that caused this regression. Can you confirm the 3.5.0-15.21[0] does not have the bug? If that is the case, there are very few changes to bisect between 3.5.0-15.21 and 3.5.0-15.22.

[0] https://launchpad.net/ubuntu/+source/linux/3.5.0-15.21/+build/3799058

[Baokai Lei (leibaokai)]

Tried out the .21 kernel, but it already has the black screen bug.

[Baokai Lei (leibaokai)]

Tested the .20 kernel now, and it's already there as well.
Will continue further down.

[Baokai Lei (leibaokai)]

Testing 3.5.0-14.19, already there, too.
How far back does this reach?

[Baokai Lei (leibaokai)]

Running 3.5.0-14.18... Guess who's there? Our friend, the bug.

[Baokai Lei (leibaokai)]

Yes, it's in .17 as well. Only one more to go now.

[Baokai Lei (leibaokai)]

Already there in .16 as well.
Looks like a commit between .15 and .16 caused the bug.

[Joseph Salisbury (jsalisbury)]

So does the bug not exist in v3.5.0-14.15 ?

https://launchpad.net/ubuntu/+source/linux/3.5.0-14.15/+build/3768740

[Baokai Lei (leibaokai)]

I just downloaded and installed the 14.15 kernel and tried it out. Good thing I did, because it also has the bug.
I *thought* I had installed 14.15 before the upgrade, where the boot screen had still worked fine, but it seems I'm mistaken there.
I went further back to kernel 13.14, but it has the bug, too. Seems the kernel I had before was still older.

Is there any install log or anything, where I can see which kernels I have had installed, so I can see which kernel I had installed before the update to 15.22?
Going back kernels one by one is starting to grate on my nerves.

[Baokai Lei (leibaokai)]

Perhaps I should also mention that I've now tried out the just released mainline kernel 3.6.0 final.
Like all other mainline kernels I've tried, it *doesn't* have the bug.

[Joseph Salisbury (jsalisbury)]

It does appear this bug is due to an Ubuntu specific change, since none of the upstream kernels have this bug. The key is to identify the last kernel that did not have this bug, and the first kernel that did. That will allow us to bisect down to the commit that introduced the regression.

Instead of trying each kernel going back in time, can you test the following kernels:

v3.5.0-1.1: https://launchpad.net/ubuntu/+source/linux/3.5.0-1.1
v3.5.0-5.5: https://launchpad.net/ubuntu/+source/linux/3.5.0-5.5
3.5.0-10.10 https://launchpad.net/ubuntu/+source/linux/3.5.0-10.10

Based on these results, we should know if we need to test in-between versions, or test older/newer kernels.

[Baokai Lei (leibaokai)]

I tried out all three kernels listed above: 10.10, 5.5 and 1.1. Surprisingly enough, all three have the black screen bug.
What to do next?

[Joseph Salisbury (jsalisbury)]

Can you test the first 3.4 based kernel:
https://launchpad.net/ubuntu/+source/linux/3.4.0-1.1

[Baokai Lei (leibaokai)]

Do you have a downloadable version of that kernel?
Further down on the page, under "Builds", it says "Failed to build" for amd64 (and for all other platforms, too).

[Baokai Lei (leibaokai)]

Just looked, and kernel 3.4.0-1.2 has builds avaiable. Should I take that one instead?
https://launchpad.net/ubuntu/+source/linux/3.4.0-1.2

[Baokai Lei (leibaokai)]

I've tried out kernel 3.4.0-1.2 now, and the bug is even there.
Now this is getting uncanny.

[Baokai Lei (leibaokai)]

Anything else for me to try out?

I've been thinking... It could be that the bug appeared because of an update to the video drivers in the xorg-edgers repository I'm using.
Some Ubuntu-specific modification to the kernel, which isn't present in the mainline kernel, doesn't go well with the current xorg-edgers video drivers (or at least the video drivers at the time at which I did the kernel update).
That would explain why I didn't see the bug with an earlier version of the 3.5 kernel, because it wouldn't show itself before the video driver update.

Current version of "xserver-xorg-video-radeon" (part of the "xserver-xorg-video-ati" set) in xorg-edgers is:
1:6.99.99+git20120928.e8cb0b72-0ubuntu0sarvatt

The driver version in the main Quantal repositories is:
1:6.99.99~git20120913.8637f772-0ubuntu1

[Joseph Salisbury (jsalisbury)]

One last thing to check would be to see if this bug exists in the v3.2 kernel[0]. If it does, we can investigate further into X.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-precise/

[Baokai Lei (leibaokai)]

Shouldn't I rather try the Ubuntu-specific version of the kernel, rather than the mainline version?
As we've seen before, no version of the mainline kernel I've tried has the bug.

The latest version of the Ubuntu-specific 3.2 kernel is 3.2.0-32.51:
https://launchpad.net/ubuntu/+source/linux/3.2.0-32.51

Besides that - I've now tried the just released kernel 3.5.0-17.26, still no change there.

[Joseph Salisbury (jsalisbury)]

Yes, sorry. Please test the Ubuntu 3.2 kernel

[Baokai Lei (leibaokai)]

Just tried the 3.2.0-32.51 Ubuntu kernel. Even there it's the same black screen during boot.

[Lucazade (lucazade)]

I don't think it is X or kernel related... the black screen appears after grub so when the framebuffer is opened.
I bet on grub v2.0 that doesn't handle vt.handoff=7 in a proper way.

[Lucazade (lucazade)]

In fact with this I can see plymouth and VTs:
sed -i 's/set vt_handoff=vt.handoff=7/set vt_handoff=/g' /etc/grub.d/10_linux
update-grub

[Joseph Salisbury (jsalisbury)]

Can you follow the "Boot options" instructions on the following wiki to enable additional output on boot:

https://wiki.ubuntu.com/DebuggingKernelBoot

As mentioned on the wiki, it would be great if you can attach a log file which may have captured any messages you see. If you are unable to capture a log file, a digital photo will work just as well. As a last resort you can even copy messages down by hand.

[Baokai Lei (leibaokai)]

@Lucazade

I've tried out what you suggested, so I launched a root Kwrite by entering in the "Run" dialog:

kdesu kwrite

I opened /etc/grub.d/10_linux and replaced the line:

    set vt_handoff=vt.handoff=7

with:

    set vt_handoff=

I also opened /etc/default/grub and changed the gfxpayload to "keep", as I saw that mentioned in the 10_linux file above, so my resolution commands there are now:

GRUB_GFXMODE=1600x1200x32
GRUB_GFXPAYLOAD=keep

My resolution is 1920x1200, but since Grub can only handle Vbe resolutions and not 16:9 resolutions, I had to use the 4:3 resolution 1600x1200.

Then I've rebuilt the grub configuration, entering at the terminal:

sudo update-grub

After that I've rebooted, picked the 3.5.0-17.26 kernel, and... was baffled to see that it actually worked! :D
The bootscreen is just fine now, no black screen anymore.
Apparently the Ubuntu kernels can't handle the "vt.handoff=7" option properly, while the mainline kernels have no problems with it. I would strongly reccommend to remove the "vt.handoff=7" option from the default /etc/grub.d/10_linux file.

@all:
If this black screen issue affects you too, just follow my instructions above. For grub_gfxmode, you can pick the resolution you want, but note that you can only pick 4:3 resolutions.

[Baokai Lei (leibaokai)]

Anything left to do here?
Or should I mark this as "fixed"?

[Lucazade (lucazade)]

not fixed.. the previous one is just a quick workaround.
the vt.handoff is a cool feature so it would be better to keep it, also not disabled because it always worked in the past.
It allows a smooth transition from grub to plymouth splashscreen without any screen flickering :)

[Baokai Lei (leibaokai)]

Okay. Although I can't see any difference between booting with vt.handoff=7 and the 3.6 mainline kernel, which I did before, and booting now with a current 3.5 Ubuntu kernel and vt.handoff turned off - no screen flickering or anything with the latter.
Thus I don't quite see the point of this vt.handoff.

[Lucazade (lucazade)]

http://askubuntu.com/questions/32999/what-is-vt-handoff-7-parameter-in-grub-cfg

[Baokai Lei (leibaokai)]

I've read that already. However, as I already said, there is *no* difference, if vt.handoff is enabled or not.
I've disabled vt.handoff now, as per above, and booting is very smooth:

- Grub boot menu appears (with customised background image)
- after making a selection (or waiting until the boot countdown is up), background stays for 2-3 seconds
- Plymouth boot screen appears seamlessly
- once booting is completed, the LightDM login screen appears seamlessly

All very smooth. At no point, there's a black screen for a few seconds, or screen flickering.
Thus, as I see it, vt.handoff not only does *nothing*, but is even harmful, in that it prevents the boot screen from appearing, and you end up with a black screen during boot.

[Baokai Lei (leibaokai)]

I've now installed the proprietary fglrx driver, reinstated the "vt.handoff=7" in /etc/grub.d/10_linux and then did a "Sudo update-grub".

Upon booting with the current Ubuntu 3.5.0-17-28 kernel, I didn't have a black screen anymore. Other than that, there's next to none difference between booting with "vt.handoff=7" disabled and enabled. With it disabled, there's a 2-3 second black screen between thwe boot screen and the LightDM login screen. With it enabled, the pause is 1-2 seconds. So neither gives me a smooth transition between boot screen and login screen, as I had with the opensource driver.

[matthieu vidal (mvidal0001)]

same problem with radeon HD4800 on 12.10 (without fglrx that can't be used )

[Igor Tarasov (tarasov-igor)]

The same problem on Radeon HD6310 (E-300 APU) on Lenovo Thinkpad X121e. Using Ubuntu 12.10. Display is off since the point after grub.

vt_handoff workaround did help. However, display still turns off, but then returns in less than a second, so that I can see plymouth.

BTW, I have the same problem on another old box, with Nvidia Geforce4. It also turns monitor off, and turns it on only when lightdm starts. And vt_handoff workaround does help, the same way as with Thinkpad. CRT display flickers, goes off for about a second, and then turns on and plymouth comes up.

Just as a side note: switching to other tty (e.g. pressing ctrl+alt+1) turns display on (without workaround).

[Matthew Mott (orbweaver)]

Confirmed on a Radeon 4850 after upgrading to Ubuntu 12.10 with kernel 3.5.0-25-generic. The vt_handoff workaround fixed the problem.

[penalvch (penalvch)]

Baokai Lei, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available (not the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.13-rc3

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]