Bug 38402

Created attachment 48086 [details]
dmesg|grep i915

Created attachment 48087 [details]
dmesg|grep radeon

Created attachment 48088 [details]
kernel .config part/VGA

Created attachment 48089 [details]
Xorg.radeon_kernel-module.log

Created attachment 48090 [details]
Xorg.radeon_xorg-drivers.log

Created attachment 48092 [details]
Xorg.fglrx.log

Created attachment 48098 [details]
lspci

Created attachment 48100 [details]
lspci -vv

Created attachment 48102 [details]
full dmesg

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?

Created attachment 48133 [details]
full dmesg with drm.debug=0xe

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!

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.

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.

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}.

Created attachment 50163 [details]
drm summery errors with `debug=0xe fbcon=map:0[|1]'

summery of the drm errors/bugs.

I imagine this has been fixed in the meantime. I should have transferred it much earlier.

-- 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.