Bug 38402 - Black locked screen after inserting only i915 or radeon+starting X with radeon/ati/intel driver
Summary: Black locked screen after inserting only i915 or radeon+starting X with radeo...
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL: https://forums.gentoo.org/viewtopic-t...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-17 06:10 UTC by tokiclover
Modified: 2019-11-19 07:32 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments
dmesg|grep drm (3.81 KB, text/plain)
2011-06-17 06:10 UTC, tokiclover 		no flags Details
dmesg|grep i915 (1.18 KB, text/plain)
2011-06-17 06:14 UTC, tokiclover 		no flags Details
dmesg|grep radeon (842 bytes, text/plain)
2011-06-17 06:14 UTC, tokiclover 		no flags Details
kernel .config part/VGA (3.48 KB, text/plain)
2011-06-17 06:15 UTC, tokiclover 		no flags Details
Xorg.radeon_kernel-module.log (16.88 KB, text/plain)
2011-06-17 06:19 UTC, tokiclover 		no flags Details
Xorg.radeon_xorg-drivers.log (16.88 KB, text/plain)
2011-06-17 06:24 UTC, tokiclover 		no flags Details
Xorg.fglrx.log (8.61 KB, text/plain)
2011-06-17 06:25 UTC, tokiclover 		no flags Details
lspci (2.03 KB, text/plain)
2011-06-17 06:55 UTC, tokiclover 		no flags Details
lspci -vv (33.21 KB, text/plain)
2011-06-17 06:59 UTC, tokiclover 		no flags Details
full dmesg (43.96 KB, text/plain)
2011-06-17 06:59 UTC, tokiclover 		no flags Details
full dmesg with drm.debug=0xe (60.55 KB, text/plain)
2011-06-18 08:16 UTC, tokiclover 		no flags Details
'it just works' Xorg.log [with radeon/i915 loaded and without xorg.conf] (6.43 KB, text/plain)
2011-06-18 08:34 UTC, tokiclover 		no flags Details
Xorg.0.log with radeon/i915 loaded and vgaswitcheroo DIS mode (20.86 KB, text/x-log)
2011-06-30 08:55 UTC, tokiclover 		no flags Details
full dmesg with `drm.debug=0xe fbcon=map:0[|1]' cmdline args (26.18 KB, application/x-bzip2)
2011-08-12 08:04 UTC, tokiclover 		no flags Details
drm summery errors with `debug=0xe fbcon=map:0[|1]' (11.82 KB, text/plain)
2011-08-12 08:06 UTC, tokiclover 		no flags Details
Show Obsolete (2) View All

Description tokiclover 2011-06-17 06:10:46 UTC 
Created attachment 48085 [details]
dmesg|grep drm

I had this issue since a while, since kernel .36, with different kernel forks.
Depending on the kernel, it was either inserting i915 first or radeon first
that caused the black locked screen. So, identifying the culprit module was
straightforward and the other module was loaded before the culpirit one via
blacklisting. This way, everything was fine and vgaswitcheroo was also
available. 

Now a change in my set up going from an unencrypted root to a LUKS encrypted
root--which give me the a chance to make a clean install--screw away that work
around without any clue about what is happening because dmesg is alright when
inserting i915 or radeon for that matter. I even tried going back to an old
stage4 with pf-sources-2.6.38_p6 and gentoo-sources-2.6.38-r2 which worked well
before only to have the same issue. So when inserting radeon or i915 everything
seems alright--but when i915 is loaded before/after or with/without radeon,
whenever i915 is loaded, a black locked screen just come up from nowhere; and
blacklisting i915 and only inserting radeon module, once again dmesg looks
perfectly fine from a module load standpoint, trying to run X with
intel/radeon/ati driver trigger the said locked black screen.

To finish up, when i915 AND radeon are blacklisted and the IGP (GM45) is
active,--and is then the default VGA is the IGP,--the black locked come up
again. When the IGP is disabled and radeon (kernel module) is inserted result
to a completely unusable screen even for the console. fglrx driver doesn't work
for any configuration--IGP on/off--and end up by segment fault to many
libraries and even glibc when everything run perfectly fine--without segement
fault--without fglrx. Where the segment faults come from? I don't know.

So the only usable alternative is IGP disabled and either use VESA driver for
the console,--radeon kernel module is only usable on the console without a
running X server,--either ati/radeon Xorg drivers--without radeon kernel module
then. At least power management features on radeon are quiet good otherwise
with VESA driver my laptop become too hot to be usable.

To conclude, first I thought it was a hardware/BIOS issues with a few suspect
lines in dmeg--ACPI bug--or Xorg.log--failure to read the BIOS--but now I think
it might be a failure to read the BIOS/ROM of the IGP/HD3450M card as seen in
this Bug 18160 because I've even restored the BIOS and nothing, really nothing,
changed.
And I don't really know if it's a kernel issue. However the black locked screen
which came from inserting i915 lead to this way. For the rest, it looks like a
failure to read VGA BIO/ROM when X server is started which is close enough of
the siad bug. However, that bug is old which should/have been fixed. And yes my
set up worked with X server 1.{9.x,8.x,7x} before so I don't know.
Comment 1 tokiclover 2011-06-17 06:14:06 UTC 
Created attachment 48086 [details]
dmesg|grep i915
Comment 2 tokiclover 2011-06-17 06:14:59 UTC 
Created attachment 48087 [details]
dmesg|grep radeon
Comment 3 tokiclover 2011-06-17 06:15:51 UTC 
Created attachment 48088 [details]
kernel .config part/VGA
Comment 4 tokiclover 2011-06-17 06:19:04 UTC 
Created attachment 48089 [details]
Xorg.radeon_kernel-module.log
Comment 5 tokiclover 2011-06-17 06:24:33 UTC 
Created attachment 48090 [details]
Xorg.radeon_xorg-drivers.log
Comment 6 tokiclover 2011-06-17 06:25:10 UTC 
Created attachment 48092 [details]
Xorg.fglrx.log
Comment 7 tokiclover 2011-06-17 06:55:10 UTC 
Created attachment 48098 [details]
lspci
Comment 8 tokiclover 2011-06-17 06:59:09 UTC 
Created attachment 48100 [details]
lspci -vv
Comment 9 tokiclover 2011-06-17 06:59:37 UTC 
Created attachment 48102 [details]
full dmesg
Comment 10 Chris Wilson 2011-06-18 02:12:32 UTC 
I'm not sure what you expect me to do with this in Driver/Intel without at least some Intel logs ;-)

Let's work through the "it just works" scenario, where you neither blacklist i915/radeon and load X without an Xorg.conf. Can you please attach the full drm.debug=0xe dmesg and Xorg.log for that session?
Comment 11 tokiclover 2011-06-18 08:16:02 UTC 
Created attachment 48133 [details]
full dmesg with drm.debug=0xe
Comment 12 tokiclover 2011-06-18 08:34:00 UTC 
Created attachment 48134 [details]
'it just works' Xorg.log [with radeon/i915 loaded and without xorg.conf]

Now, I have the feeling that X doesn't finish to start with a somewhat incomplete log. However, I shut down the system when I have the feeling--,when the intensive I/O of the disk stop signaling the end of the boot up process,--everything is done.

I've just tried to fire up a xorg.{intel/radeon}.conf to see if something changed only to find out that now the machine is not completely shut down, I mean even the shutdown log shows that everything went fine but the last thing to be done,--effectively shutdown the machine when the fs were unmounted and LVM/cryptsetup were removed,--nothing happen,I have to hard shut it down. 

Otherwise everything is similar to the previous Xorg.log but now, one more thing, when X is started with a radeon xorg.conf profile, and after the black locked screen which come up whenever i915 is loaded, and X fails to start for a supposedly failure to read the BIOS, well, the BIOS boot up message `M82M A11 lenovo/Wistron Olympus GDDR3 700m/500e' is displayed on the screen with different screen resolution! That's the funniest thing!
Comment 13 tokiclover 2011-06-30 08:55:35 UTC 
Created attachment 48599 [details]
Xorg.0.log with radeon/i915 loaded and vgaswitcheroo DIS mode

Hello, I've just went to remove {radeon,intel}fb drivers from my kernel .config file and tried, again, to see if this was an issue and nothing changed. However, as running X server with only radeon (xorg) driver and without radeon kernel module end up displaying awful colors, I decided to try to enable the IGP and try to run `modprobe -a radeon i915; echo DIS >/sys/kernel/debug/vgaswitcheroo/switch` to see if I could get back a usable screen. And it worked! The console screen was back after a few seconds of black locked screen and the IGP is put to OFF state. 

Now the issue is that X server doesn't find a screen which is ridiculous as the screen is defined in the xorg.conf,--which work without the kernel radeon module!,--furtermore, now there's a `Bad V_BIOS checksum' error at the end of Xorg.0.log. I don't get it... what could be wrong with this?
Help! I don't get what could be wrong with everything running fine and after another workaround trick to escape the black locked screen.
Comment 14 tokiclover 2011-08-12 07:11:57 UTC 
Hi,
I've found another workaround to get rid of the "BOSD(TM)" (black [locked] screen of death) thing but a few things remain a complet mystery... as before I may say.

Now the key to get something functional is appending "fbcon=map:0[|1]" to the kernel cmdline. With the latest 3.0.1 stable vanilla (with a few patches not related to drm/i915/radeon) I have the "BOSD(TM)" if no fbcon arg is appended in the kernel cmdline; a few seconds (~3s) of "BOSD(TM)" if "fbcon=map:0" is appended and a usable screen come back after that; no "BOSD(TM)" with "fbcon=map:1" but the "video=*" arg is just ignored so an awful resolution is used to print to fb1. In the the two last cases X server can be started on either IGP/RADEON card switching with a little script which does run `echo IGD[|DIS] > /sys/kernel/debug/vgaswitcheroo/switch' and switch a xorg.conf.{intel,radeon} config file to make it smooth. I've tried switching IGP/RADEON in the first case, without "fbcon=mape:*" arg, with no avail.

The weird stuff is, as I have a 2.6.38.8-{pf,zen} stable kernels, I tried that trick on both because I use one of them for running 7/24h and... only the last scenario work but the discrete chip run very hot so it's not usable. When I use the third scenario to switch to the IGP and run X on top of it, it results into a "BOSD(TM)" for tty7 and the other tty are locked after getting back a usable screen. I did not try to disbale my script and remove the init service which run X server on start up to see if it's the switching or starting X which cause the locked screens but I do have a "no screen found" at the end of Xorg.0.log as seen previously when I could get back usable terminals running `echo DIS > ...' with a script after getting the "BOSD(TM)" (caused by the insertion of i915 module).

I have a very few drm errors in dmesg--three lines or so for each kernel and a bug for 2.6.38.8 when using the second scenario or the third with switching to the IGP--so I don't know if it'll help debugging it.
Comment 15 tokiclover 2011-08-12 08:04:17 UTC 
Created attachment 50162 [details]
full dmesg with `drm.debug=0xe fbcon=map:0[|1]' cmdline args

full dmesg for kernel 3.0.1 and 2.6.38.8-{zen,pf}.
Comment 16 tokiclover 2011-08-12 08:06:17 UTC 
Created attachment 50163 [details]
drm summery errors with `debug=0xe fbcon=map:0[|1]'

summery of the drm errors/bugs.
Comment 17 Chris Wilson 2012-04-22 14:22:47 UTC 
I imagine this has been fixed in the meantime. I should have transferred it much earlier.
Comment 18 Martin Peres 2019-11-19 07:32:18 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/21.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.