Latest working kernel version: 2.6.25
Earliest failing kernel version: After 2.6.25, exatcly don't know, probably 2.6.26-rc3
Distribution:Ubuntu 8.04 Hardy
Hardware Environment: toshiba U305 intel-based laptop, see http://bugzilla.kernel.org/attachment.cgi?id=16067&action=view
Software Environment:xserver-xorg-video-intel 2:2.2.1-1ubuntu12, see also http://bugzilla.kernel.org/attachment.cgi?id=16066&action=view
Sometime, on cold boot (after the laptop has been shut off), when the screen switch from the Ubuntu startup to gdm, the screen goes blank. Forever. Rebooting (warm) with the same kernel cures it, sometime. If I reboot 2.6.25 it cures it everytime.
Otherwise, the system seems to be working.
It was difficult to see because I almost never do a cold boot, the laptop is either sleeping (s2ram) or on, or (warm) rebooted when I test a new kernel.
Helps / tricks to gather more data when it happens are welcome.
This entry is being used for tracking a regression from 2.6.25. Please don't
close it until the problem is fixed in the mainline.
References : http://lkml.org/lkml/2008/6/10/137
On Sunday, 15 of June 2008, you wrote:
> On Sat, 2008-06-14 at 22:12 +0200, Rafael J. Wysocki wrote:
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10892
> > Subject : Sometime (often) X come out blank (black screen) on
> cold boot - Intel chipset
> > Submitter : Romano Giannetti <firstname.lastname@example.org>
> > Date : 2008-06-10 05:33 (5 days old)
> > References : http://lkml.org/lkml/2008/6/10/137
> It happened, again, with the new Ubuntu x-intel driver. Rebooting with
> nousplash solved the problem, but alas, sometime simply rebooting solves
> the problem. It seems a race...
Bad luck. Happened again.
OTOH, it happened with 126.96.36.199 too.
rebooting with nosplash cured the problem.
Again, with -rc8. It seems it happens when switching from the bootsplash (I think it is X in VGA mode, I do not have any fb compiled in) to X intel in full resolution.
I think I will add nosplash as default, although if anyone has something for me to check, I will.
(In reply to comment #3)
> Bad luck. Happened again.
> OTOH, it happened with 188.8.131.52 too.
Is 2.6.25 good and 184.108.40.206 bad or was it simply luck that 2.6.25 worked?
On Wed, 2008-06-25 at 08:22 -0700, email@example.com
> Is 2.6.25 good and 220.127.116.11 bad or was it simply luck that 2.6.25
At this point, I really do not know. It seems to happen quite randomly.
I am testing for it now; after noticing, I think I did a cold boot once
in month, so I cannot say anything for sure.
Ok, last phrase did not parse. What I tried to say, is that *before* noticing the bug, I hardly did a cold boot (I reboot for a new kernel, and then s2ram everytime), so for what I know, that bug could be here since ever...
Thanks for this update.
Until shown otherwise this bug should therefore not be tracked as a regression.
I do reboot quite regularly under 2.6.24 and recently 2.6.25, and I get this issue VERY regularly under 2.6.25, and have never seen it under 2.6.24.
Romano, is nosplash confirmed to help for sure?
Wait, there is no nosplash option that could have any effect for you.
Adrian: I do not understand your last phrase. Until now, booting with nosplash (to be exact: editing the grub entry and changing splash to nosplash) did the trick.
If you were referring to not having fb compiled, I can say that even without fb, I have the splash screen. Not sure how. I suppose Ubuntu starts an X server in VGA 640x480 mode (which by the way has a lot of problems, lost pixels, etc, since ever).
It certainly seems to me that this is a regression from 2.6.24.
In case it's not clear, the video seems to be knocked for a loop by this. Once the X server starts, even switching back to tty1 or closing the X server doesn't seem to help (although the system is responsive. You can log in and do things blind from the console)
Sorry Romano, I thought you were talking about a kernel commandline but you are talking about the grub splashscreen support.
Well, I was talking about kernel commandline. What I think it happens is that
Ubuntu's initrd read the splash/nosplash and acts... it does
for x in $(cat /proc/cmdline); do
case $x in
and then uses usplash, which I really do not know how to work. It seems that it shouldn't work without framebuffers... hmm... let me dig a bit my .config.
There is a strange thing that happens to me. VESA/VGA framebuffer option appears ONLY if I choose framebuffer compiled in, not module; my previous configuration was with framebuffer compiled as module, uvesa and intelfb compiled but not used:
# lsmod | grep fb
I am compiling with VESA/VGA framebuffer compiled in, now.
VESA compiled in. Booting with video=vesa vga=ask init=/bin/bash and choosing any of the VESA mode results in black display. No console.
Choosing a normal VGA mode (80x60) gives the splash screen. Trying to switching consoles while the splash screen is in creates a flashing show of rubbish, no usable X starts.
Starting normally (splah, no video option) gives the splash screen, and then a black screen.
Starting with nosplash will give a correct (although ugly) 80x50 console and a working X.
1) in early boot, usplash digs the bowels out of the intel graphic card.
2) VESA modes are busted with the intel graphic card.
2.6.26-rc9: booted two times in a row (no vga nor video options) options, with splash screen, all seems ok.
Will continue to test, because it seemed fixed another time, but well, something changed.
Nope. Happened again. Rebooted and then it was fine, but...
Please re-open if this is incorrect