# YET ANOTHER i915 BLACK LOCKED SCREEN[NEW WORKAROUND]

## tclover

Hi, well I'm having too much trouble to get a GMA X4500 (GM45) working which is not really new since the `i915 black screen' is ubiquitous, even for me, I had thought that I could never get stuck with this issue because I had found a workaround before which doesn't work anymore. Now I have a `firmware bug' which prevent to even run a discrete graphic--well, actually I can only use a discret graphic (a Rdaeon HD3500) in console mode, whenever I try to run X, my screen got locked!

Let's begin by describing the issue and the previous workaround which permitted me before to get the X4500 working. 

First of, I had the `i915 balck screen' issue with kernel .3{6,7,8,9} and with {gentoo,pf,tuxonice}-sources. Each kernel gave me a different flavor of this issue, however, the same thing kept coming--a black screen resulted from inserting i915 or radeon driver first depending on the kernel;--for exemple with {pf,gentoo}-sources it used to be inserting i915 first, before radeon, resulted to a black locked screen; with tuxonice-source, it was radeon first, before i915, which resulted to the same issue. Now the order of the module became clear to me when I tried to blacklist the driver that caused the black locked screen. So I've just tried to load another module to get a working screen, and after that I tried loading the other one and it worked for a few months. The workaround was to just blacklist the culpirit and load another module [radeon|i915] to have a working screen. I could even run vgaswitcheroo, I writed a script [/etc/hoprofile/profiles/vga/ptest] to take care of it, which looked if vgaswitcheroo was available and load the missing module wich triggered the availability of vgaswitcheroo.

Now the issue is that, that workaround doesn't work anymore and I had a new issue --a firmware bug, see what will follow,--which prevent to even run X with the module that doesn't cause a black screen. 

KMS is enabled by default in my .config which doesn't make any difference because I tried to disable KMS when loading the modules and it doesn't make any difference. I also experimented removing KMS altogether with different kernel and nothing came up with it. Sometimes not setting CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY made a difference, but I've just noticed that I forget to remove it from my new kernel config and removed it and built again my kernel, which did not take much time, and nothing came up. 

My main functionnal kernel is pf-sources-2.6.38_p6, I have gentoo-sources-2.6.38-r5 but I do no use it for the moment because of different issues, the same could be said with _p8 but I cannot unload OSS4 modules with it so I do not use it, I keep it as a fallback.

Here, i'm going to post some infos:

I keep the same configuration for vga related stuff for the different kernels, here the related part of my .config file:

 *Quote:*   

> # Graphics support
> 
> CONFIG_AGP=y
> 
> CONFIG_AGP_INTEL=y
> ...

 

This what is bothering me in dmesg, now I have an ACPI related bug wich I did not have before with my laptop. Actually I use the config/stage4 image for a lpatop and a desktop to avoid compiling twice some stuff.

 *output of dmesg-ACPI bug?! wrote:*   

> [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
> 
> ACPI: SSDT 00000000bbb76c18 00265 (v01  PmRef  Cpu0Ist 00003000 INTL 20051117)
> 
> ACPI: Dynamic OEM Table Load:
> ...

 

However, in the same dmesg, everything seem fine when loading radeon driver, which make me wonder what's going on when trying to run X server.

 *dmesg|grep -i radeon wrote:*   

> [drm] radeon defaulting to kernel modesetting.
> 
> [drm] radeon kernel modesetting enabled.
> 
> radeon 0000:01:00.0: enabling device (0006 -> 0007)
> ...

 

And here what I've got when inserting i915, there's nothing particulary weirg about the output.

 *Quote:*   

> Jun 10 19:54:55 * kernel: i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> 
> Jun 10 19:54:55 * kernel: i915 0000:00:02.0: setting latency timer to 64
> 
> Jun 10 19:54:55 * kernel: i915 0000:00:02.0: irq 48 for MSI/MSI-X
> ...

 

Or the contains of radeon/dr is not particulary weid, it looks fine.

 *Quote:*   

> Jun 10 19:54:01 * kernel: [drm] radeon defaulting to kernel modesetting.
> 
> Jun 10 19:54:01 * kernel: [drm] radeon kernel modesetting enabled.
> 
> Jun 10 19:54:01 * kernel: VGA switcheroo: detected switching method \_SB_.PCI0.OVGA.ATPX handle
> ...

 

And here the most weird thing, the end of Xorg.0.log is not reassuring at all after the previous dmesg log, evrything looks fine from a radeon load module stand point, but...

 *Xorg.0.log wrote:*   

> [   265.100] X Protocol Version 11, Revision 0
> 
> [   265.100] Build Operating System: Linux 2.6.38-pf8 x86_64 Gentoo
> 
> [   265.100] Current Operating System: Linux lufik 2.6.38-pf6 #6 SMP PREEMPT Fri Jun 3 15:59:00 Local time zone must be set--s x86_64
> ...

 

now there's a failure to read the BIOS or the ROM info about the VGA!

I smashed my head over some walls in an attempt to find a workaround/solution but nothing came up. gentoo-2.6.38-r{1,5} or pf-sources-2.6.38_p8 did not change a thing. I don't know what to do anymore. Maybe I could re-emerge pf-sources-2.6.38_p2 or pf-sources-2.6.37_p6 which because those kernel worked well with my settings... going back to previous rm-ed kernels?! Is that the only solution, I don't know if it 's a solution because I could end up having the same issue because many configuration changes happened since those kernels. Now I have an old stage4 with pf-sources-2.6.37_p6, maybe this the only thing I could do... 

Any input is welcomed.

EDIT: Of course seing the BIOS/ROM "issue" made me wonder if my BIOS got corrupted, so I ended up trying to log into my w7 partion, which gave me too much trouble because I did not remember my password anymore in a attempt to restore my laptop BIOS. The thing is all my partion are encrypted with LUKS/Truecrypt... so it wasn't that easy to come up with a solution. Curiously I remembered Truecrypt password for my w7 partition wich is much longer and complicated than my M$ w7 password. That shit, M$ w7 passwod, gave me to much troube to hack. Despite reading some threads in the forum about updating BIOSs with a CD/USB stick... all those solution relied on a bootable media which wasn't really a go for different reasons. Finaly I found this tool. Sources files are also available, so I tried to build it with no luck... hopefully there're static built binaries wich helped me in no time to hack my w7 password. I restored my laptop BIOS in no time after that only to... get the same issue after all the trouble to hack w7 password. Darn, no luck on this side niether.

EDIT2: The thing is I had the black locked screen with the exactly same setup and kernel and it worked with the said workaround. The thing is I decided to migrate my root to LVM/LUKS and that's where I did the mistake to--, delete kernel-2.6.3{7_p2,8_p6} which worked with the said workaround,--and do a clean install to my new root which involved to build only the kernel as I keep pkgs on a separate LV. This was a mistake... because I built all this on my desktop and everything worked there. I could have tested my new clean install on my laptop by plugging my desktop boot device on my laptop which I did not. This was a serious mistake. The exactly same setup worked before migrating to LVM/LUKS which make me wonder what's possibly gone wrong with my clean install or what trigger the new BIOS/ROM read failure. This is quiet weird because I cannot come up with an explanation on the why I cannot run X with radeon module and why inserting i915 after radeon the screen got locked.

UPDATE[2011-06-13]:

Now, I've just tried an old stage4 (pf-sources-2.6.38_p2 and gentoo-sources-2.6.38-r2) which worked with the said work around however I ended up with the same issue which made me wonder if it's a hardware related issue. I've fired up w7 to check if switching IGP/RADEON worked and it did seamlessly. I happen to had to have to hard rebout my laptop after a few kernel panics when testing an init script (for an initrd), so I suspected to have damaged something, as switching still works on w7 it's likely not.

A second attempt was to try running X with fglrx. And then the black locked screen came up with a different flavor: now intel module is automaticly loaded when X is started which might be the source of the black screen. Furthermore, I have a segment fault at the end of Xorg.0.log. That's pretty funny(?). Now, I've re-built mesa early when facing this issue and various drivers/components of X to make sure that everything was built with the right kernel headers. I've just re-built xf86-video-{intel,ati} ati-drivers and libdrm to make sure that th issue wasn't there. The funnier thing is there's a glibc library in the segement fault... I did not really want to re-build glibc, furthermore I have I functional package and It worked and still work with my setup. I've just runned `revdep-rebuild -ip' to make sure that the linking was still good and it was.

Here the fglrx's Xorg.0.log:

 *Quote:*   

> [   442.959] 
> 
> X.Org X Server 1.9.5
> 
> Release Date: 2011-03-17
> ...

 

SECOND UPDATE[2011-06-15:

I went into experimenting a thing or two and noticed that the only way to run X is to disable the IGP and run X with VESA driver. This way X start without an issue and even without a xorg.conf.

I've tried to make use of fglrx driver by blacklisting radeon and i915 driver, however this does not work as showed in previous Xorg.0.log, when doing so the IGP is detected and some X modules are loaded, I'm not sure if it's those modules that cause the black locked screen or not, but I do have a black locked screen. The issue is even worse when the IGP is disabled which cause not only a black locked screen but the machine is locked as well in the process requiring a hard reboot. fglrx did not live to anything, I merged it to be able to run X without radeon/i915 and it does not serve for anything. As the machine is completly locked I don't know what is hapening and there's not Xorg log for that matter either.

Here is the Xorg log for that only usable case anyway to give enough material. Anyway, this only usable case is not that usable because I end up having a heater than a laptop.

I've deleted the 'font' and 'chips/cards' section of Xorg.log to limit the length of the logs.

 *Xorg.log-VESA wrote:*   

> [    98.361] 
> 
> X.Org X Server 1.9.5
> 
> Release Date: 2011-03-17
> ...

 

The post is becoming hard to manage with hundreds of [ and ]. So to finish with something tat disappeared in the post, I can use xf86-video-ati to run X with a custom xorg.conf which limit power consumption. It's far better than trying to run X with VESA. As a side note, hibernate/suspend do not work anymore or rather resuming became impossible. There's nothing in hibernate.log particulary weird,--in fact everything looks fine,--and there's nothing logged when trying to resume.

As I reached the max length of this post, all in all, this issue is quiet close to this bug 18160, a failure to read the ROM/BIOS of a seconf card. It's an old bug which should have been fixed on xorg-1.6 onwards, but it's the only bug close enough to my issue--everything looks fine when inserting radeon/i915 modules but it end up with black locked screen with{,/out} failure to read RM/BIOS. And I deleted some redundant section of Xorg.log... to limit the length.Last edited by tclover on Fri Aug 12, 2011 3:14 pm; edited 9 times in total

----------

## fturco

Don't know if this could help you. I have an Intel integrated graphics card and I had to renounce to build kernel modules for it. So you may try building the following options directly into the kernel image:

```
AGP=y

AGP_INTEL=y

DRM=y

DRM_I915=y

DRM_I915_KMS=y
```

----------

## tclover

Those are already built in as you could see in the .config file part above. If ever I built in i915... I could never make it even to the console.

----------

## cach0rr0

for me, i periodically have issues that stem from backlight wonkiness with my GM45

I have i915 as a built-in, as well as KMS

whenever I have such issues at boot, I:

-boot with i915.modeset=0 on the kernel command-line, which gives me an ugly but mostly functional environment; at least a console

- echo 5 > /sys/class/backlight/acpi_video0/brightness

-reboot, specifying acpi_osi=Linux on the kernel command line

and everything is fine, at least for a while. I have no idea what triggers it in my case, but it's always when I've been using it on battery for a while. 

no other great answer, sorry to say, but that's what's worked for me.

----------

## tclover

And I've tried acpi_osi=Linux to see whatever difference it'd do, and the issue was exactly the same. At first, I suspected for a possible hardware/BIOS damage, but now I begin to only suspect a common failure to read the BIOS/ROM of a second card (bug18160)... which is a little strange because my set up used to work with exactly the same settings. I've now safely upgraded my kernel from pf-sources-2.6.38_p6 to p8, however everything worked with p6, as the issue did not change a bit after upgrading, I don't think it's made a difference.Last edited by tclover on Mon Jun 20, 2011 3:25 am; edited 1 time in total

----------

## tclover

I've submited a bug on bugs.freedesktop.org --38402--and bugzilla.kernel.org --37722. And still no clue/work around found yet on what is happening.

----------

## cach0rr0

for me i think acpi_osi=Linux was just a placebo

what seems to be the key behind it is going into /sys and adjusting the screen brightness value, then rebooting - everything seems ok after that 

there are tons of documented and apparently unresolved issues with i915 relating to this, i got the two above workarounds (functional or otherwise) from trawling existing kernel bug reports.

----------

## tclover

I've found another work around which is amost fully functional for kernel 3.0.1 and half functional for 2.6.38.8 with appending `fbcon=map:0[|1]' to the kernel cmdline after failed to make X sevrer start with a `echo DIS > /sys/kernel/debug/vgaswitcheroo/switch' (runned by a hprofile script and with 2.6.38.8 kernel) to get back a usable screen on the discret graphic but X server just does not want to find a screen.

EDIT: details are posted on the bugs.freedesktop

----------

