i915: black screen on boot

After a followup boot where fsck wasn't running any more, I just get a 10 second phase of screen power-off.

I had exactly the same symptom some time ago when I debugged a new i915 driver and booted without initramfs. Back then the problem was that the fbcon driver did not get loaded. It looks like we have the same problem now, and fbcon should be loaded much earlier in the boot process?

Confirming the issue there it's quite confusing

I'd like to understand how fbcon is getting loaded at the moment, since I can't find any logic that actually does this - but it's clearly loaded by the time X starts.

Then I'd like to figure out how we can make fbcon automatically loaded when we need it *properly*, rather than putting a hack in.

Alberto,

Can you take a look and see if you can help Scott see what is going on?

Cheers, Rick

For information, after installation and reboot, when we have black screen, in fact we are in prompt because of file system check problem.
If you enter commands in blind like :
fsck -y /dev/sda3
after a moment , when dd led stop to check, you can do a ctrl+alt+del and the system works.

So the problems are :
1/systematic problem with filesystem after the installation (with new upstart system)
2/prompt for fsck is not shown (black screen)
3/recovery mode don't works too because of black screen

I have the same problem but the i915.modeset=0 fix doesn't work for me.

@Scott
fbcon is loaded by the -intel driver by i830_kernel_mode_enabled() in src/i830_driver.c:

    ret = drmCheckModesettingSupported(busIdString);
    if (ret) {
 if (xf86LoadKernelModule("i915"))
     ret = drmCheckModesettingSupported(busIdString);
    }
    /* Be nice to the user and load fbcon too */
    if (!ret)
 (void) xf86LoadKernelModule("fbcon");

So basically i915 and fbcon are loaded when checking for KMS.

I encountered the same issue on my notebook.

How do I give the i915.modeset=0 statement correctly? I tried in GRUB to modify the command with button C and E, typed the i915.modeset=0 in different places, but this doesn‘t seem to change the situation. After booting I have a root shell, but I cannot see it.

I would appreciate a hint. Thanks in advance!

Tilo Körner [2009-09-18 14:10 -0000]:
> How do I give the i915.modeset=0 statement correctly? I tried in GRUB to
> modify the command with button C and E, typed the i915.modeset=0 in
> different places, but this doesn‘t seem to change the situation. After
> booting I have a root shell, but I cannot see it.

You have to append it at the line starting with "linux", and don't
change other lines. Don't start the rescue mode, just the normal
system.

It looks like I don't get KMS unless fbcon is in in /etc/initramfs-tools/modules .

In order to test it:
put fbcon in /etc/initramfs-tools/modules

and type:
sudo update-initramfs -k all -c

and reboot.

Would it make sense to make fbcon a dependency of i915 (and similar KMS modules for other hw)?

Excuse me, I tried the solution proposed meaning to add the i915.modeset=0 fix to the linux line at the boot but the boot immediately tells me that the option is invalid (or something similar). What am I doing wrong?

Giwex [2009-09-19 1:21 -0000]:
> Excuse me, I tried the solution proposed meaning to add the
> i915.modeset=0 fix to the linux line at the boot but the boot
> immediately tells me that the option is invalid (or something similar).

Yes, it does that, but it works anyway. The reason is that at the time
this check runs and the error message appears, the i915 module isn't
loaded yet.

Hello,

I've this bug with my Asus laptop, I wan't to try the tip of "i915.modeset=0" but how to do this ?
It seems easy for you, but I can't. I've a message "GRUB LOADING", I try to press "esc", "space bar" and another touch, but nothing. The system starts to boot and hangs with the black screen.
Thank for your help.

Stéphane: hold down shift at boot to get the grub menu.

Thanks Martin. Unfortunatelly it appears not working for me as I still have the display powered off. I really don't know what to do.

Thank Colin, this shortcut is not easy to find !

With the i915.modeset=0 option, I've the message telling this option is invalid but the laptop starts well. The good news is very short, because with this the keyboard and the touchpad didn't work ! I can't loging, can't do anything.

I feeling the testing of Alpha6 will stop here for me, wait for Beta1.

After reading all of this, maybe this summary might help:
1) the boot process is trying to do an file system check
2) because of an issue with the start process you can't see the prompt

As a work around for those wanting to use their system
1) when the screen goes blank and hard drive light stops - type your password eg:
   password123 [Enter]
2) run a file system check, eg:
  fsck -y /dev/sda [enter]
3) reboot your system, eg:
  reboot [enter]

NOTE:
* This does not solve the underlying issue
* but it does allow the system to continue to boot.

My hardware is an ASUS EeePC 4G, which uses the Intel Driver mentioned above.

Since this also kills recovery and text-only mode, could we put back the previous method of loading it in the initramfs, or would that be inappropriate now?

I don't know if this anything do with this, but the same thing happened to me while trying generic 2.6.31 and on some previous rc's I tried. 2.6.30 worked just fine. I used the kernel-team-ppa. I tried them out on Ubuntu 9.04 and I have a basic Eeepc 900 with a Celeron.

See bug #392039, since both bugs have the same set of fixes

Did this get fixed already, or worked around? I updated this morning, saw some sysv etc. updates and kernel 10.35, and have booted twice without nomodeset now without incident.

By the way, when I did have the problem, it was particularly troublesome on my Eee PC 1000HEB, because it apparently left the LCD brightness in an "off" state, even across cold reboots. Hard brightness keys brought it back up though.

It appears to be fixed also on my system.

On my system the screen blanks, the loading proceeds (but without usplash) and then appears gdm....

I got the sysv, kernel updates too, but my system is still broken. It does not boot (screen is turned off) without 'nomodeset'.

Hardware brightness buttons, ALT+SysRq+REISUB, nothing works.

This bug was fixed in the package initramfs-tools - 0.92bubuntu50

---------------
initramfs-tools (0.92bubuntu50) karmic; urgency=low

  LP: #392039, #431812.
  * hooks/framebuffer:
    - rename from hooks/kernelextras, this is much more descriptive and
      actually matches the associated script
    - copy kernel-mode-setting drivers (drivers/gpu) into the initramfs
    - include the vesafb driver, which we previously relied on being in
      the special initrd directory
    - don't force load fbcon
    - don't force load things from the initrd directory
  * scripts/init-top/framebuffer:
    - add udev as a pre-requisite
    - remove mknods since udev will make those now
    - remove intel_agp and i915 code
    - don't unset MODPROBE_OPTIONS, just override for the modprobe call
      (since we want video= to override the blacklist)
    - if we didn't pick up a framebuffer from vga= or video=, and don't
      have one from udev, wait for udev to finish then if we still don't
      have one, load vesafb
    - settle after loading drivers to ensure the device is ready
  * debian/control:
    - increase dependency on udev to that which loads fbcon
    - add breaks on older usplash to force upgrade

 -- Scott James Remnant <email address hidden> Wed, 23 Sep 2009 14:25:00 -0700

This bug was fixed in the package udev - 147~-5

---------------
udev (147~-5) karmic; urgency=low

  * debian/udev.initramfs-top:
    - Rename from udev.initramfs-bottom and move from local-premount to
      init-top
    - Add a pre-requisite on all_generic_ide so that gets a chance before
      we load IDE devices.
  * rules/rules.d/80-drivers.rules:
    - load the fbcon driver when a framebuffer is created.
      LP: #392039, #431812.

 -- Scott James Remnant <email address hidden> Wed, 23 Sep 2009 14:22:52 -0700

This bug was fixed in the package usplash - 0.5.38

---------------
usplash (0.5.38) karmic; urgency=low

  LP: #392039, #431812.
  * debian/control:
    - increase dependency on initramfs-tools for new framebuffer handling
  * initramfs/hooks/usplash:
    - change pre-requisite to framebuffer
  * initramfs/scripts/init-top/usplash:
    - remove mknod and modprobe calls now udev takes care of that

 -- Scott James Remnant <email address hidden> Wed, 23 Sep 2009 14:27:10 -0700

Unless using the daily live cd as of 2009-09-24 is not the right way of testing this patch, it is not working for me. However, i915.modeset=0 still does the job. I don't know if this is of any interest but I am also not able to establish a network connection (neither through LAN nor WLAN).

@Fabus: I imagine not. The new packages weren't yet in my update last night.

Check

dpkg --status initramfs-tools | grep ^Version

as well as for udev and usplash and confirm your versions.

When will it be in daily live?

I have no idea about the timing of daily builds, but I'd think it'd be available by now, since the package has been out nearly three days.

Still not working with the latest updates. Using the option i915.modeset=0 on grub does solve the problem. HP Pavilion DV2000.

Best,

Igor Gomes

Just to confirm the previous post:
With
initramfs-tools 0.92bubuntu50
usplash 0.5.38
udev 147~-5
it does not work without setting i915.modeset on my Mac Mini 2nd generation. I was using live 2009-09-27, network now working.

I do confirm networking working too. But the graphics still a serious regression. I'll stay with this laptop only today, let me know if I can be any help. (HP DV2000)

Best,

Igor Gomes

Got new results: Workaround.

1) Add nomodeset to the grub options in /etc/default/grub
2) Run update-grub
3) Restart
4) Somehow, it will be fallback to the console. But just hitting CTRL+ALT+F7 the normal Ubuntu initialization starts (with that white line in the middle)

Best,

Igor Gomes

I can also confirm that, having set i915.modeset=0, the system will fall back to console, Ctrl+Alt+F7 will magically start the window manager.

unresolved in beta; pushing the milestone back.

Steve, in my opinion this is a quite serious regression that touch on a very important deliverable for Karmic: KMS. It should not be postponed. If so, we'll be repeating the Intel issue we had with Jaunty.

I already got a workaround (comment #37). Tomorrow I'll get the problematic laptop again and do new tests with daily images.

We have two options:

1) Solve the problem tomorrow.
2) Add it to the known issues yet on Beta. And giving it a milestone to RC.

Best,

Igor Gomes

I agree with Igor, in terms of testing, this is a very severe issue. If I wasn't able to put that boot option into place (like 99% of the users), I wouldn't have been able to do any testing at all. In terms of marketing, I think it is not a good idea to release beta software without the Intel graphics working. There were so many arguments and reviews on that issue. And we cannot make sure that it really works if there is no feedback from beta users.

If you'd ask me, I'd propose delivering it with beta, delaying beta or releasing a beta-2 the week after.

Best
Fabian

Igor Gomes [2009-09-29 23:23 -0000]:
>
> Steve, in my opinion this is a quite serious regression that touch
> on a very important deliverable for Karmic: KMS. It should not be
> postponed. If so, we'll be repeating the Intel issue we had with
> Jaunty.

It was just postponed for the beta release, which is tomorrow already
(and we need to test/publish the images before). It's not such a
serious bug any more, since it should now work for most people with
the original fix.

It's still on the list for Karmic final.

I hope the following info is useful: With daily-live 2009-09-29 the issue remains unsolved -- still no screen without the kernel option. If that is what you've called original fix then I'd suggest rating its not working as serious indeed.

I think the problem is extremely serious and postponing the solution to the release candidate is dangerous.
It seems to me there is no intention of fixing it, like the mtrr bug in jaunty..

I've installed karmic beta yesterday, and now I can boot to the desktop. With alpha 6 the only thing I could see was a black screen where nothing could be done, even the caps locks key failed to work.

However it seems that the new xsplash doesn't work, as I'm getting no splash at all, only the boot messages till the brown flashy splash appears. It's odd because with the live CD, it shows the ubuntu logo on a black background and then the brown flashy splash.

With 2.6.31-10-generic kernel everything is working fine on Alpha6. Today I upgraded to Beta with the same 2.6.31-10-generic kernel and it works.

With 2.6.31-11 I had the same problem stated in this bug report.

Wondering if my problem is related to this: I get a black screen (monitor goes to standby) when booting the livecd/installer.

The hardware is last year's Mac Mini with Intel GMA 950.

@Olli Helenius: You're absolutely right here, I've got the same hardware and same problem. It does not work with any daily or official live CD since Alpha 6 (the versions before show other graphics bugs).

Just wanted to add a "me too". After choosing the kernel from the Grub menu, there's a good 10 second delay or so, then the textual boot process appears. I see usplash at what seems to be GDM loading.

% lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)

2.6.31-11-generic #38-Ubuntu SMP

Hopefully THIS is the issue I'm experiencing anyway ;)

All - I have the same problem on my ibm x61s thinkpad.
I've just upgraded from jaunty to karmic beta and now I can't get into my system.
I tried adding the 'i915.modeset=0' option to the line that begins with kernel, but no success.
No matter what I do, I always land on a blank screen with a blinking cursor.
Typing 'fsck -y /dev/sda1' followed by enter doesn't do anything and hdd light does not blink.
Once I do a ctrl-alt-del the root prompt shows up and runs any commands I'd typed on the blank screen.
The machine then reboots and I'm back to the same blinking cursor screen after reboot.

Can someone point how I get back into the system and remove the forcefsck.
Hope there is a way to get back in.

I have tried multiple times changing the kernel line to end with i915.modeset=0 and nomodeset, however nothing works.I just get a blinking cursor on a black screen as mentioned in my post above.
I am logged in via my jaunty live-cd. Are there any changes I can do to make the system bootable again from my hdd.
Should I edit any entries in fstab to prevent the fsck? Or is there any other boot options which I can add at the end of the kernel line to get things going.
Any advice would be great.
Thanks.

ok i tried a few things
when i get the blinking cursor on black screen (after grub screen), I can do a ctrl-alt-del and get to the prompt and quickly do a init 3 and prevent system reboot. After this I can do ctrl-atl-f2 and login.
I can also do a sudo dhclient eth0 and get an ip addy and get internet access.
However it seems the file system is mounted as ro.
This also explains the message on tty1 (after I press ctrl-alt-del) which says "cannot remove /forcefsck read-only file-system"
Should I boot from jaunty livecd and add /fastboot to my partition. Will that work?

I finally got into my system.
After grub, I get a blinking cursor on a black screen. I need to do a ctrl-alt-del to get to a prompt, then quickly type init 3 to prevent reboot. After this I need to remount the file system as rw and then do a sudo service dbus start, followed by sudo service hal start, sudo service gdm start. This gets me into the gui. This is where I have lots of serious issues reported by apport. Not sure anymore if they are related to this issue or to dbus errors.
I also have a thread going here http://ubuntuforums.org/showthread.php?t=1281504
Thanks for any help.

The original bug that caused the black screen has been fixed.

HOWEVER there is a *different* bug that has the same symptom - if you are still experiencing black screen problems, you may be suffering from bug 430694 instead - subscribe to that for updates

I am not quite sure if I am suffering from this bug or #430694 . All I can say is that it does not work out of the box (screen blanking just after the isolinux splash of the LiveCD 2009-10-05) and that it does work when adding i915.modeset=0 to the boot args.
How can I tell what bug is the one that affects me?

I'm having a problem with an i865 and a CRT monitor connected via DVI->VGA - There's some problems getting EDID data (see dmesg logs attached)

The only solution I've found so far is to turn the monitor off after grub, wait about 10 seconds and turn the monitor back on (this only works 10% of the time). If this doesn't work I have to press the power button, press alt-s and try the boot again.

Fortunately, when the display is up (albeit only 800x600, have to set up 1600x1200 with xrandr each boot) it is solid (the current beta liveCD locks up after ~10 seconds - but the current daily (as of 7/10) is fine) and compiz runs very well.

2.6.32rc4 generic still black screen, boot up process takes much more than 2.6.31,
splash appears for few seconds, the final boot to X takes about minute more tha 2.31

But luckilly I have X, what's goin' on before - don't know, removed dhcp server and all the delayin stuff
but still too slowly to boot up..

PS: No problem with recognizing screens, PC is notebook DELL D620 so maybe Xorg switch to extrnal NO screen and after
framebuffer switch back to LCD with login.. ??

After updates on the 15 the blank screen on boot problem persists on an Acer Aspire One 110L (ZG5) BUT under specific circumstances ONLY: when booting on battery power with ethernet cable connected. If either of those two conditions is not met - no problem booting.

I had this problem earlier in the karmic release cycle, and now, after using Update Manager to update to what I assume is the Release Candidate, the problem returned. I suppose that the update overwrote my grub settings, which had the i915.modeset=0 parameter added. So... is this parameter still supposed to be required? It apparently still is on my hardware at least (Dell GX60, Intel 82845G/GL). Maybe the installer/updater should set it automatically for unfortunate hardware like mine, if there is no actual fix for the problem.

Hi, I have just upgrade my Jaunty to Karmic Koala, and get a completely black screen after boot.

I have tried adding "i915.modeset=0" (without the quotes) to the end of the line in grub that starts with "kernel", and ending with "splash", and then pressing enter, followed by "b". The computer starts booting, but I end up with a black screen again.

Is there any way to fix this? I've read that I can't revert to Jaunty either, but I would really like to use my system again!

Thanks very much for you help!

I also did the i915.modeset=0 workaround. It worked, but the graphic is slow. Compiz is not working. I have a Lenovo G550 with Intel Core 2 Duo (Centrino 2) P8700, Mobile Intel GM45 Express 4500MHD
I am thinking of downgrade to 9.04 that worked perfectly.

Hi, I have the same problem as sarion. post #62

I also tried "nomodeset" and tried launching in recovery mode.

My machine is a notebook Dell inspiron 6000.

Thank you for helping.

After removing the ATI HD3450 video card from my system, and using the on-board ATI Radeon 2100, combined with the i915.modeset=0 at startup, I now get command line interface. It flickers for about 20 seconds, after which the flickering stops. It asks for my login & password, after which I am logged in. However, I am still in the command line interface.

I guess this is some progress. However, can anybody help me to get the graphical user interface working?

Addition: I have used startx, but I get a "no screens found" error. Tried updating xserver-xorg-video-ati, but I already had the most recent version.

I just want to confirm that this bug persists, even now that the final 9.10 release is out. The workaround adding i915.modeset=0 to the boot arguments in grub works for me on my hp Pavilion dv2000. But this is a serious problem to be persisting in a final release! Given that my machine (and other experiencing the same problem) is pretty common hardware, this seems to me to be a massive barrier for people that might try to adopt Ubuntu with this release. We cannot expect users to mess with their grub arguments. In any case, as of today (Nov. 3rd) the most recent updates have not solved the issue.

It seems like three questions need to be answered:
 * What is the root cause?
 * When will it be fixed?
 * What are the workarounds in the meantime?

For workarounds: this bug is specific to certain Intel graphics chipsets, right? If the list of bad chipsets can be determined, then the installer/updater could "blacklist" those and automatically add the i915.modeset=0 to the grub configuration if necessary -- correct? That's probably not as great of a solution as actually fixing the problem, but at least it would make these offending computers usable without "user hacking".

My machine seems to have an Intel GMA 950 chipset. Why don't others experiencing the problem post their specific graphics adapter info here and we can build a list, as joeclarkia suggests.

One other question. Is there some way I can configure my machine to boot with the i915.modset=0 automatically, without adding it manually on each boot?

hi
search in /boot/grub/menu.lst for the line # kopt= ...

append "i915.modeset=0 " to the line

looks like
# kopt=root=/dev/... ro i915.modeset=0

update-grub

and it will be added in the parameterlist on all kernels into all
version if you make a kernel update

greatings
jochen

ps it is the 9.10 is the alpha release oft the next LTS, so you will
have many critical bugs in it

Ian W Scott schrieb:

> My machine seems to have an Intel GMA 950 chipset. Why don't others
> experiencing the problem post their specific graphics adapter info here
> and we can build a list, as joeclarkia suggests.
>
> One other question. Is there some way I can configure my machine to boot
> with the i915.modset=0 automatically, without adding it manually on each
> boot?
>
>

Vielen Dank jochen. Just a point of clarification. You say that 9.10 is an alpha release for the next LTS, so we should expect critical bugs. If that's the case, this is something that is not being communicated to users. When you go to the Canonical site there is no indication that 9.10 would be less stable or functional. It isn't labeled "dev" or "alpha" or even "beta." It's provided as the primary version to download for ordinary production environments. The LTS release is explained as one which will receive support for a longer period of time, not one which is more "finished." Granted, an LTS release will have more time to get all of the bugs fixed. But if the "regular" releases like 9.10 are supposed to be prone to "many critical bugs," this isn't being communicated properly to the people we want to adopt the os. To be clear, I'm not just trying to be critical here. I'm concerned that if this had been my first attempt with Ubuntu it would have driven me back to Windows.

Nope, regular releases, i.e. 9.10 aren't development releases so aren't supposed to be prone to critical bugs. It's inevitable that people will find these 'bad' bugs with day to day use but that's the way it goes!

Dave.

The only person entitled to reopen this bug is the original reporter.

If you are experiencing continued problems, you have a different bug to the original reporter.

How can I try out this fix?

I solved the problem by adding nomodeset --xdriver=intel to the boot parameters. I hope that can help some of you guys. No black screen and Compiz is also working then. I hope there will be an update so we don't need to add boot with these parameters.

"
@Scott
fbcon is loaded by the -intel driver by i830_kernel_mode_enabled() in src/i830_driver.c:

    ret = drmCheckModesettingSupported(busIdString);
    if (ret) {
 if (xf86LoadKernelModule("i915"))
     ret = drmCheckModesettingSupported(busIdString);
    }
    /* Be nice to the user and load fbcon too */
    if (!ret)
 (void) xf86LoadKernelModule("fbcon");

So basically i915 and fbcon are loaded when checking for KMS.
"

What I'd like to know is why something for "be nice to the user" is being hard-coded as policy in the driver?

Personally, I really like the 80x25 text console. It's snappy and fast, and is just the right size for me.

I don't like it being forced on me, and as a workaround on my system I've renamed the fbcon.ko to fbcon.ko.disabled.

May I suggest that whether or not fbcon is loaded be left up to the system admin? I hate fbcon and having it hard-force-loaded is most unkind.

This is a violation of "provide mechanism not policy".

I'm suffering from this problem, too. I've upgraded to Kubuntu 9.10 today. I'm running Kubuntu on a Fujitsu Stylistic ST5021 tablet pc (Intel 855GM).
My problem looks like the following: The kernel loads, it looks like the system would reach the initramfs, then the screen goes black, the harddisk shows some activity for maybe 5 to 10 seconds, then the system freezes completely (still black screen). The freeze seems to happen at kernel level as the systems responds to maybe 1 or 2 ping packets from the outside, then silence forever. Num lock or caps lock leds are dead at this moment.
Im running 2.6.31-16-generic - with old 2.6.28-17-generic the system is able to boot up.
The system is also able to boot up if I append one of the following kernel parameters:
- nomodeset
- i915.modeset=0

Am I right here or should I open a new bug for the linux-image-... package?

hello
yes you are right and rught here
you have to do this, because this big bug is not fixed before release,
and not till now.
you have to edit with admin right your grub config (kernel init
parameters) that you can use an intel graphic card with ubuntu 9.10

jochen

Markus Schuster schrieb:
> I'm suffering from this problem, too. I've upgraded to Kubuntu 9.10 today. I'm running Kubuntu on a Fujitsu Stylistic ST5021 tablet pc (Intel 855GM).
> My problem looks like the following: The kernel loads, it looks like the system would reach the initramfs, then the screen goes black, the harddisk shows some activity for maybe 5 to 10 seconds, then the system freezes completely (still black screen). The freeze seems to happen at kernel level as the systems responds to maybe 1 or 2 ping packets from the outside, then silence forever. Num lock or caps lock leds are dead at this moment.
> Im running 2.6.31-16-generic - with old 2.6.28-17-generic the system is able to boot up.
> The system is also able to boot up if I append one of the following kernel parameters:
> - nomodeset
> - i915.modeset=0
>
> Am I right here or should I open a new bug for the linux-image-...
> package?
>
>

Well, it wasn't a big thing to modify my grub config, but Ubuntu had big problems with Intel in 9.04, I thought they would know it better this time - seems not...
Could someone with knowledge about what's going on please have a look on this problem - I would consider this a major showstopper.

Yes - various symptoms.

I found a entry in the /boot/grub/grub.cfg file which may be the cause for the problems
Seems that a call for "splash" halts the system

"linux /boot/vmlinuz-2.6.31-14-generic root=UUID=44118bfa-d582-45e2-964f-66886a1d4d03 ro quiet splash"

where the "splash" word needs to be edited away (for some creepy reason)

HOWTO

Go into recovery mode
Drop to root

>nano /etc/default/grub

Edit the line
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
to
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
and save

>update-grub
(which will update the /boot/grub/grub.cfg file)

>shutdown -r now

and now go into the normal boot and the splash screen and GUI should be there.

Good luck
Morten

i have a q1 ultra and i couldn't even install 9.10 without using the modeset trick, as it just kept flashing that 22 error. correct me if im wrong, but does using i915.modeset=0 disable whatever form of acceleration the graphics card had? i ask this because i noticed that anything that would normally appear to use acceleration seems to run incredibly sluggish almost to the point of complete lockup.

I am having the same problem on Acer Extensa EX5235-901G16MN with chipset Intel GL40, graphics card Intel GMA 4500M.

With the i915.modeset=0 the system boots but I am unable to play any DVD or video via Totem, VLC or other media player as GUI crashes back to login page. Note Flash videos (YouTube) are ok.

I'm seeing same/similar problem with an i915 chipset on an Asrock G41MH-GE motherboard. This is latest kernel, 2.6.31-19.

I also got this problem it was solved in recent kernels, but the black screen came back in the 2.6.31-19

Same problem here.
Kernel 2.6.31-19
Intel i915 onboard video card.

I can only boot with setting
GRUB_CMDLINE_LINUX_DEFAULT="nomodeset"
and
GRUB_TERMINAL=console
in /etc/default/grub
then
sudo update-grub
and reboot

If I set GRUB_GFXMODE=640x480 and GRUB_GFXPAYLOAD=keep, I can see BRUB and my monitro tells that it is 640x480, but after the GRUB - nothing. And this "nothing" differs depending on grub settings. It may leave GRUB menu on screen, while boot normally (I can connect to the station via SSH) or it may start booting normally in 640x480, but then, right after "Loading keymap and console fonts" the screen goes off.

I took me 3 days to determine that nomodeset solves (partially) my problem. Since this is just a silent file serever, I'm OK with the text console. But I would be happy to have full functionality on it.

Hi

Sorry if I post on the wrong thread, but my problem is somehow similar and I cannot find a more appropriate place.

It is related to Intel graphic board and screen resolution (i915 driver).
I'm using a console mode Server installation (no X graphics) with 2.6.31-19 kernel.

The problem lays in drm - EDID - framebuffer chain settings.
If EDID data cannot be read or is not available (as under a KVM switch), the drm sets a "random" mode for DAC and only registers THAT mode in /dev...
This leads to some strange behavior when some app's expect or request a different video mode (screen resolution).
Now, how could anyone force a video mode if automatic detection is not possible or fails? Usually, monitor rates and video card capabilities are known, so in many cases, a fixed setting would be more comfortable.

I am happy enough with the 640 x 480 console, but I have a large monitor that I do not use as I could (and like). More than this: if I boot with the KVM switched to the Ubuntu box (EDID data read from monitor), resolution is set to the maximum supported (1280 x 1024) which is also extreme.
Using GRUB2, I have tested many settings for various GRUB variables but without success.
It would be nice to have a parameter or something in the kernel module (drm, i915 or whatever) to be able to manually override automatic settings. Maybe this could help avoiding problems like mine or other ones posted on this thread.

All the best

This bug has been marked as fixed. Anyone experiencing similar problems should open a new bug report. The developers are very busy and don't have time to keep checking back on comments for bugs that have already been marked as fixed.

Just did an upgrade to Lucid and I run into this bug. With Karmic I haven't that problem.

Running a very new system with Intel i915 integrated graphics, the only option for me to get around the blank screen after boot was to add "i915.modeset=0" to the boot options.

But that leaves me trapped in vesa mode, which means 1024x768 and 800x600 mode only, which are both not the native resolution of my display and distort the whole GUI.

This bug report here seems to be the more general problem, while the specific detailed bug for my system is described in bug https://bugs.launchpad.net/ubuntu/+bug/608907

That this bug had been marked as "fixed" is correct. Refer to bug https://bugs.launchpad.net/linux/+bug/608907 to see how the black screen on boot can be solved until the fix has propagated to main. Thanks everyone.