You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

After all the package upgrading, removing obsolete packages, running lilo etc, I rebooted and I was really taken by surprise. Apparently, this certain intel graphics card doesn't work right with KMS. The boot process starts, I get to see the two tux twins and a few lines of boot messages, but as soon as KMS kicks in, everything goes completely blank. It doesn't crash or freeze or anything, the boot process continues, but it's all blank.

What's completely weird is that I have another laptop, which reports exactly the same graphics card, but KMS works fine there with current!

Anyway, I did some google search and I found that it's a common problem. There was a suggestion to remove any vga=... lines from lilo.conf, but that didn't help at all. Adding nomodeset to my boot options, disabled KMS, and I was able to boot to init 3, just like in 13.0. The problem was that then, it wasn't possible to launch X, because the intel driver that is included in current requires KMS to work!

So, after trying out a few different versions of the intel driver, I found that anything from 2.8.x and down wouldn't compile and that anything after and including 2.10.x require KMS. The only versions that would work are 2.9.0 and 2.9.1, which seem to have an identical effect here. They both work, but I have artifacts using my favorite mouse cursor theme, I get a black box instead of the mouse cursor. Not a big deal and choosing another theme fixed that too.

What I'm thinking is that probably more people will have the same problem and nothing is more frustrating than a completely blank screen. Maybe it would be a good idea to keep the 2.9.x versions of the driver in /extra. That and perhaps also add a note in the UPGRADE docs about adding nomodeset if you have an intel graphics card and you get a blank screen.

On Slackware the latest intel driver may not work since
newer releases require KMS enabled in the kernel. The
default slackware kernel does not have KMS enabled. The
xorg.conf-vesa configuration file seem to work fine. If
you want to use the intel driver then rebuild the kernel
with KMS enabled or use the xf86-video-intel-2.9 driver.

Again, if this is not obvious from my first post, I have fixed the blank screen problem which comes from KMS not working with my intel card. The fix is to add "nomodeset" to the boot options and use xf86-video-intel-2.9.1. I posted here so that other people having the same problem can find the solution and also hoping that something to make the entire procedure a little less painful for slackware 13.1 can be done.

I have a netbook with the same graphics chip and have not had any problems.
Just curious, have you tried booting both laptops with 'vga=-3' (to prompt for available graphics mode to use) in lilo.conf to see whether there are any differences?
Perhaps KMS is trying to use a graphics mode that is not supported on the problematic machine.

I feel pretty sure there are a number of Intel graphics chipsets that experience this with the latest Intel drivers. I had exactly the same issue with an old 8245G graphics chipset in a six year old laptop. The kernel for every distro I tried installed the i915 driver by default each time, and it booted to a black screen, or occassionally it would boot to a desktop but crash within minutes of use. I tried "nomodeset" to no avail. The ONLY solution I have found is creating an xorg file in Slackware with the vesa driver. Not optimal but it works and it is stable with 1024X768 res. I do hope a solution is going to be forthcoming at some point.

Just curious, have you tried booting both laptops with 'vga=-3' (to prompt for available graphics mode to use) in lilo.conf to see whether there are any differences?

No, it doesn't help at all. No matter what I choose in the vga= line, or if I leave it out completely doesn't change a thing.

The only thing that I can think that is different in the two laptops, is that the one with the problem runs a 32bit slackware and the one that works runs a 64bit one. Maybe I'll try to also install a 32bit system in the one that works, see if I break it there too.

Quote:

Originally Posted by vorbote

Add the following to the boot line in grub: nohz=off That'll give you screen back.

I don't see how this could have anything to do with it.

Quote:

Originally Posted by BobNutfield

I feel pretty sure there are a number of Intel graphics chipsets that experience this with the latest Intel drivers. I had exactly the same issue with an old 8245G graphics chipset in a six year old laptop. The kernel for every distro I tried installed the i915 driver by default each time, and it booted to a black screen, or occassionally it would boot to a desktop but crash within minutes of use. I tried "nomodeset" to no avail. The ONLY solution I have found is creating an xorg file in Slackware with the vesa driver. Not optimal but it works and it is stable with 1024X768 res. I do hope a solution is going to be forthcoming at some point.

Did you try to compile the 2.9.1 version of the driver and use it together with nomodeset as I did? It would certainly be a lot better than running vesa.

I too am hoping that a solution will come up eventually. I have found a solution for myself for 13.1, but what happens if the 2.9.1 version of the intel driver can't be compiled anymore in the future? I would hate not to be able to upgrade that laptop anymore.

I'm also having problems with KMS on my Intel 945, but they're a little different. My screen isn't blank on boot, but will randomly flicker and go black (sometimes pink or blue) after about an hour of use.

The solution for me is to boot with 'i915.powersave=0' then create the file '/etc/modprobe.d/i915.conf' with:

If you read my first post, I wrote that the only way to have it working is to downgrade the driver.

I know what you've said - but you fixed it so I apologise.

... hmmm, the patch is interesting, it seems it does not exactly patch any part of the driver ... it looks like it reverses a commit which used the lid status as a way of detecting LVDS (the signalling method for your laptop screen). However, old laptops often "lie" about their lid status .

Not always, which is why some people have the problem and others, with exactly the same chipset and stuff don't. I put "lie" in scare quotes since it may just be that some laptops use normally open and others normally closed micro-switches for lid status and make up the difference in the (windows) software. That's a guess but it sounds like the sort of thing that happens: sometimes a nod means no.

What the patch does is pretend that the dri connection status was "connected" no matter what and hope it all comes out in the wash. Which it won't - some systems will still need to be manually configured but at least it won't lock the screen.

May be interesting to play with - by default, in a lot of distros, the power management is set so the screen is black and locked if the lid is closed - if the lid says it is closed when it is open you get an unresponsive black screen. So the workaround this suggests is to hack into the screensaver so it doesn't switch the screen off when the lid closes.

But other lid events work fine you say? Well yes - except these are detected by the event handler, which does not run at HW detection time.

Actually, the unpatched code sets the dri connector status to "disconnected" when the lid is closed - thus the dri errors. So it probably won't work that way - the event handler cannot handle resources (dri) that it does not have - but fun to try if anyone has yet to patch this.

Another thing to try would be to plug in an external monitor for post install configuration.

I installed Slackware 13.1 without problem. But on booting it first show standard text console (80x25), then switches to framebuffer (or loads driver for graphics controller) and since then the screen is blank, even after soft restart. I am able to ssh into the machine without problem. I added "nomodeset" to kernel parameters and now it is possible to work with console.

I tried to install new kernel 2.6.34 but it changed nothing, the screen blanks at the same time. So nothing changes with 2.6.34.

Then I tried also to compile xf86-video-intel-2.9.1 driver. It compiles with no problem. But when I tried to use it the notebook freezes. I tried it this way: