[Intrepid] screen goes black after upgrading to kernel 2.6.27-13-generic

Bug #337019 reported by Luca Aluffi on 2009-03-03
This bug affects 6 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Stefan Bader

Bug Description

Binary package hint: linux-image


My pc is a DELL 830.

As the subject states, screen goes black after dist-upgrading to proposed kernel 2.6.27-13. Restart is possible using RSEIUB. Booting with 2.6.27-12 works fine.

I'll start attaching both "messages" and "xorg.log" for 2.6.27-12 and 13. Suffix of the file designate the kernel that was used.

I remain at you disposal for any needed further information.

Best regards.


SRU justification:

Impact: One of the stable release updates for Intrepid changed the size of an acpi integer from 32 to 64bit on 32bit builds. This had a bad side effect when using closed source graphics drivers on machines that exposed video adapters via acpi tables. On those systems the start of X locked up with a solid black screen without any chance to type normal commands (or change to the terminal).
More recent NVidia drivers (180) work with that change but the default in intrepid is 177.

Fix: Revert the change to acpi integer size (and one follow-up patch to this).

Testcase: Tested by affected users.

Luca Aluffi (aluffilu) wrote :
Luca Aluffi (aluffilu) wrote :

Always me.

Just tried with another pc and, again, screen goes black.

This time is again a dell but with an ati video card so, I guess, it does not depends upon video card. Pc is a DELL OPTIPLEX 740.

I'll attach messages e xorg.log from this boot too.

Ask me whatever you want, I remain at your disposal for further information.
Best regards.

Same problem here, I'm writing this with:

uname -a
Linux *** 2.6.27-12-generic #1 SMP Thu Feb 5 09:26:35 UTC 2009 i686 GNU/Linux

Because when trying the new update 2.6.27-13 screen goes black once it has booted everything.

My computer is an Acer 5610 with nvidia 7300 Go graphic card and Driver "nvidia" on xorg.conf:
Section "Device"

Section "Monitor"
  Identifier "Configured Monitor"

Section "Screen"
  Identifier "Default Screen"
  Monitor "Configured Monitor"
  Device "Configured Video Device"
######### Option "RandRRotation"
  DefaultDepth 24

Section "Module"
  Load "glx"
  Disable "dri2"

  Identifier "Configured Video Device"
  Driver "nvidia"
  Option "NoLogo" "True"
  Option "Rotate" "CCW"

Stefan Bader (smb) wrote :

At least in the nvidia case there seems to be a way to solve this. As discussed here:


There seem to be a change in the number/names of video devices. Apparently a later NVidia driver can work with this, while the older cannot.

bdoe (bdoe-att) wrote :

This is a showstopper, since the nVidia 180 drivers are never suggested for update with the .12 kernel, and it's nearly impossible to do so with the .13 kernel, without booting into safe mode and running xfix first. Even then, the nVidia 180 drivers need to be updated through Synaptic or APT before Jockey will pick it up and make it available.

There's no known workaround for ATI users as of yet.

Pak (paolo-tezza) wrote :

same here, but

sudo apt-get install nvidia-glx-180

on kubuntu 8.10 works for me :)

Andy Whitcroft (apw) wrote :

This is a kernel bug, therefore the package should be linux.

Stefan Bader (smb) on 2009-03-04
Changed in linux:
assignee: nobody → stefan-bader-canonical
importance: Undecided → Critical
status: New → In Progress
Stefan Bader (smb) wrote :

If you can look at the failing log and the working, is there a common pattern that acpi video changes its number of entries?

ACPI: Video Device [VID] (multi-head: yes rom: no post: no)
ACPI: Video Device [VID1] (multi-head: yes rom: no post: no)
ACPI: Video Device [VID2] (multi-head: yes rom: no post: no)

ACPI: Video Device [VID] (multi-head: yes rom: no post: no)

Stefan Bader (smb) wrote :

To corner this issue, there were two changes that could relate to that issue. I placed two kernel versions at http://people.ubuntu.com/~smb/bug337019/ Could those which still have the old nvidia driver test both and report back whether one of them (v1 or v2) helps? Thanks

Doug Holton (edtechdev) wrote :

I see the same problem on a Dell D820. Screen totally black after installing updates.

I tried the nvidia-glx-180. No luck, instead of a black screen I got the ubuntu splash screen right, but when I log in I got background color screen with horizontal lines(see screenshots, I have my screen rotated). Same problem with kernel and 13.

So I installed nvidia-glx-177, with the black screen problem in kernel 13.

So I tried the 177 with the 12, and it works(here I'm).

What you see here has a lot of specular reflection. What appears is background color, and white lines(in the image they are blurred, in reality they have some square white dots into the line )

Orzech (piotr.orzechowski) wrote :

I've tried with Stefan Bader's i386 images and nvidia drivers 177.82. None of them worked. Using image v1 resulted with the same problem, as with ubuntu's .13 kernel and using image v2 made nvidia driver to claim, that there were screens detected, but none of them with usable configuration.

Stefan Bader (smb) wrote :

@Orzech, could you gather the dmesg and xorg.log from your working case and running the v2 kernel. Also could you do an "acpidump -oacpidump.hex" and post that resulting file as well?

Beni (benjamin-lutz) wrote :

here are the log files for the two different kernel versions 2.6.27-12 and 2.6.27-13. Nvidia driver version is 173.14.12. For kernel -12 everything works fine, for -13 the screen stays black and keyboard input is not possible. But the power button is recognized and the system shuts down.

I also tested version 180 of the nvidia driver and it works for me with kernel 2.6.27-13.

Beni (benjamin-lutz) wrote :
Beni (benjamin-lutz) wrote :
Beni (benjamin-lutz) wrote :
Beni (benjamin-lutz) wrote :
Stefan Bader (smb) wrote :

Thanks a bunch Beni. So the pattern seems to be confirmed. You had an "ACPI: Video" entry for NVID and GFX0 with -12 and -13 only shows the NVID one. Also for some reason VT 9 is user in the non-working case, while VT7 is used when it works. Could you do me a favor and check whether the working 180 / 13 combination has VT9 or VT7 in xorg.log? Also, it would be great if you could try to install the v2 debug kernel from http://people.ubuntu.com/~smb/bug337019/ and post me the dmesg when that boots? Thanks again.

Beni (benjamin-lutz) wrote :

VT 7 for 180.11 and -13

Beni (benjamin-lutz) wrote :

I tried the installation of the test-kernel v2 and nvidia 173. The screen does not get black, but the X-server does not come up properly either. It starts in low resolution mode and goes to the debug menu.
I tried to install nvidia 180 then, but the problem is the same.
Unfortunately, I cycled out the Xorg.log of nvidia 173 by reinstalling the original kernel. Therefore, I can provide only the dmesg for this configuration. I will not have time to redo the test before end of next week.

For completeness the logs from v2 and nvidia 180 are attached, too.

Beni (benjamin-lutz) wrote :
Beni (benjamin-lutz) wrote :
Stefan Bader (smb) wrote :

Doh, that was enlightening! So actually the revert for that change did the trick, but unfortunately (in order for a quick testing) I cheated a bit about the version. That patch changes internal interfaces and normally requires the ABI to change and all the depending packages to be rebuild.
To put it simple, with that kernel you get your 2 ACPI video entries back but the nvidia module fails to load because of the changes. If the nvidia module was rebuild it would work.
You helped a lot. Thanks again.

Jussi (jussi-lahtinen-gmail) wrote :

I have same problem, but with different symptoms.
From bug report I made ( https://bugs.launchpad.net/ubuntu/+source/linux/+bug/337355 ) ;

After proposed kernel update (2.6.27-12 --> 2.6.27-13), I noticed unusual delay at "Starting up...".
Usually that delay isn't very long (about 10 - 20s), but sometimes it seems to be freezed (although cursor is blinking) and so I press reset.
I haven't try yet to just wait long time...

Syslog seems to have many warnings (probably not related?):

1. Cannot find map file.
2. ACPI Warning (tbutils-0217): Incorrect checksum in table [OEMB] - CE, should be CD [20080609]
3. Warning! ehci_hcd should always be loaded before uhci_hcd and ohci_hcd, not after
4. WARNING: Unable to find provider 'gnome-wm' of required component 'windowmanager'
5. hub 6-0:1.0: unable to enumerate USB device on port 2 <--- there is Logitech Deluxe 250 keyboard

Ubuntu 8.10 64bit
P5Q-E with bios version 1703.
Nvidia 8600 GT
4GB memory

Jussi (jussi-lahtinen-gmail) wrote :
Jussi (jussi-lahtinen-gmail) wrote :

Forgot to mention, that is with kernel 2.6.27-13.

gersoid (gerson-riddy) wrote :

I had the "dark screen" issue with on a Dell Inspiron 1520 + Nvidia 8600M GT card.
The system would only run with .12
The install of nvidia-glx-180 has solved the problem.

Luca Aluffi (aluffilu) wrote :

Ok guys. Upgrading to nvidia-glx-180 worked for me too.
Tryed with both ubuntu and kubuntu.

Stefan Bader (smb) wrote :

If there is still anybody left with the 177 nvidia driver, it would be good if those (or even those willing to get back to the older version) could try to enable my PPA https://launchpad.net/~stefan-bader-canonical/+archive/ppa to verify this series of kernel packages. I'd rather get with that and avoid to cause grieve with such a kernel-driver dependency in updates.

Luca Aluffi (aluffilu) wrote :

Tomorrow I will manage to save an image of my actual (nvidia 180) partition and restore a "no driver at all" image, if I still have it. Hope to let you know something.


Orzech (piotr.orzechowski) wrote :

@Stefan Bader
I run Ubuntu's 12 kernel, yours 13v2 kernel and yours 14 kernel, all of them with nvidia 177.82 driver. Xorg logs, acpidumps and dmesgs are in attached archive. I was able to see gdm on 14 kernel again.

Michele Nasti (artlover) wrote :

stefan, I'm actually in the condition to try your packages since I haven't already installed the nvidia-180 . My only doubt is that it could break my system, and since It's my (only) personal machine, I'm a bit scared about it. What do you suggest?
shall I try?
Let me know.

Stefan Bader (smb) wrote :

@Michele, as Orzech has confirmed above it seems to work for him (but more confirmations are better). The difference between the -13 kernel and the one on my PPA is just the one change which seem to have caused breakage. Another thing to note, as it is another ABI version (thats why it requires new versions of those other packages as well (but without any content change)) it will install in parallel to your current kernel. So it is possible to boot back to the previous version. So if you were affected by the -13 kernel. this can only improve it.

Michele Nasti (artlover) wrote :

Well, I can confirm that the kernel 2.6.27-14-generic is working.

Now I only need that network manager manages my wpa connections... :D

bdoe (bdoe-att) wrote :

Michele: Try wicd.

On topic: I'm not at all sure why the nVidia 180 driver worked where the older ones failed, but this brings up another concern: Since I have already been bitten by the -13 bug and worked around it by installing the 180 driver, will any future kernel updates work with this driver, or am I in for another wild ride?

Dan The Man (onemanbanddan) wrote :

Marked 337735 as duplicate.
'sudo apt-get install nvidia-glx-180' -fixed it for me too. however 180 doesn't show in the GUI System->Administration->Hardware Drivers.

> the 180 driver, will any future kernel updates work with this driver, or
> am I in for another wild ride?
It is hard to guarantee anything, but since updates to Intrepid rather bring in
code from newer kernels and the nvidia driver got updated to work with recent
kernels, it should be ok (beside of the potential that the new driver has some
new bugs). I suspect the change they did was to cope with a larger size of
integer from acpi. This should be ok when the size is reduced again. You could
install the -14 kernel from my ppa (link must be somewhere in this bug report)
which has that acpi change reverted. This likely gets into proposed soon, since
it seems not worth the trouble to have that in Intrepid and breaking for more
people when it gets into updates.

@Stefan: Hello, I don't understand a word of what you said :-) , let me show you what I do:

1- I install an update of something that (in theory) is stable.
2- It doesn't work.
3- I can't work or do anything in the machine that (in theory) is stable. I have to spend time trying hacks(maybe that's what unstable is for, that I will install when I have time for tinkering).
4- Please don't include changes that break things in stable.

I don' t want to sound too rough, just don't want you to loose the perspective that there is people out there that needs to use their computer and have work done in time.

Dan The Man (onemanbanddan) wrote :

I agree with Jose. I've gone back to -12 now because despite the fact that -13 boots with nv 180, it consistently fails to recover from suspend. Only way out is hard power-off.
Bad form.
I used to think it was a bit daft that grub kept all the boot options for old kernel images, now I'm glad.

Michele Nasti (artlover) wrote :

@jose hevia & dan the man:

well, I must say that this update was in intrepid-proposed and not in intrepid-main. It means that this kind of update was received only if you decided to turn on the "proposed" repository, wich is a repository of new software that should be ok but is still on testing. If you turn on this repository, you agree to test software for ubuntu.

Be coscient of what you do when you turn on a repository! It may break down your computer. Be aware also of other unknown repository: if you don't trust him you can never know what is going to install on your pc!

Dan The Man (onemanbanddan) wrote :

Fair enough! feeling suitably humbled.

Stefan Bader (smb) wrote :

To add that this is two sided. It is bad that this caused problems for people
having -proposed turned on. On the other hand it is good, since that gives the
opportunity to identify and remove that change before this kernel goes to
updates. The fewer around which have -proposed turned on, the less chance to
catch something like this. I tested on machines I got, but I have limited
hardware (compared to all of the community) and none of my machines (even those
with NVidia cards and the 177 driver) showed any problems.

@Michele: Thanks for pointing this. I didn't knew proposed updates could break the system, I expected in intrepid only no critical bugs. Good to know.

Stefan Bader (smb) on 2009-03-11
description: updated
Changed in linux:
status: In Progress → Fix Committed
Martin Pitt (pitti) wrote :

Accepted intrepid into linux-proposed; please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in linux:
assignee: stefan-bader-canonical → nobody
status: Fix Committed → Invalid
assignee: nobody → stefan-bader-canonical
importance: Undecided → Critical
status: New → Triaged
Martin Pitt (pitti) wrote :

This regression only affected intrepid-proposed, thus the bug can be closed now.

Changed in linux:
status: Triaged → Fix Released
_dan_ (dan-void) wrote :

still blackscreen for me

_dan_ (dan-void) wrote :

edit: grub did not automatically update menu.lst to include latest -14 kernel, doing that manually fixes the problem. Still i think that grub update hickup should be looked at.

marcel (marcelrf) wrote :

I have the same problem. Screen goes black after loggin-in but, if I go into f1 console the screen is OK, then i go back to graphical and everything is OK.

I am running 2.6.27-11-generic and noticed this problem after updating to the 180 nvidia drivers. Is there another bug report for that, couldn't find it

marcel wrote:
> I have the same problem. Screen goes black after loggin-in but, if I go
> into f1 console the screen is OK, then i go back to graphical and
> everything is OK.
> I am running 2.6.27-11-generic and noticed this problem after updating
> to the 180 nvidia drivers. Is there another bug report for that,
> couldn't find it
Rather a different bug (though I cannot say whether there is one open) since
you where able to switch screens, while people affected by this bug were hard
locked and could not recover. Also this happened when upgrading to a newer
kernel while you upgraded the nvidia driver.

To post a comment you must log in.