Bug 60643

Summary: [i915] black screen at boot
Product: Drivers Reporter: MDBürkle (dominik.buerkle)
Component: Video(DRI - Intel)Assignee: intel-gfx-bugs (intel-gfx-bugs)
Status: RESOLVED INVALID    
Severity: normal CC: daniel, intel-gfx-bugs, kernel
Priority: P1    
Hardware: x86-64   
OS: Linux   
URL: https://bugs.gentoo.org/show_bug.cgi?id=463838
Kernel Version: 3.8.4(and earlier) - 3.10.2 Subsystem:
Regression: No Bisected commit-id:
Attachments: lspci -vmmnn
dmesg.gz from a boot of a kernel with CONFIG_DRM_I915=m and CONFIG_DRM_I915_KMS=y and /etc/modprobe.d/test.conf:options i915 modeset=1
dmesg.gz from a boot of a kernel with CONFIG_DRM_I915=m and "CONFIG_DRM_I915_KMS not set" and /etc/modprobe.d/test.conf:options i915 modeset=1
DRM_I915_KMS=y, fglrx loaded, two lines commented out -- GREY screens at boot
DRM_I915_KMS not set, fglrx loaded, two lines commented out -- consoles visible and usable
DRM_I915_KMS not set, fglrx loaded, -- consoles visible and usable
kernel 3.9.11-gentoo-r1, KMS=y, acpi_osi="!Windows 2012", acpi_backlight=vendor
kernel 3.9.11-gentoo-r1, KMS=y, acpi_osi="!Windows 2012"
kernel 3.9.11-gentoo-r1, KMS=y, acpi_backlight=vendor
kernel 3.10.5-gentoo-r1, KMS=y, acpi_osi
kernel 3.10.5-gentoo-r1, KMS=y, acpi_backlight
kernel 3.10.5-gentoo-r1, KMS=y, no acpi cmdline options
kernel 3.10.5-gentoo-r1, KMS=y, acpi_osi, acpi_backlight
dmesg.gz from a boot of a kernel with CONFIG_DRM_I915=m and CONFIG_DRM_I915_KMS=y and /etc/modprobe.d/test.conf:options i915 modeset=1
dmesg from a boot of kernel 3.10.9 with CONFIG_DRM_I915=m and CONFIG_DRM_I915_KMS=y and /etc/modprobe.d/test.conf:options i915 modeset=1
dmesg from a boot of kernel 3.10.9 with CONFIG_DRM_I915=m and CONFIG_DRM_I915_KMS=n and /etc/modprobe.d/test.conf:options i915 modeset=1
dmesg from a boot of kernel 3.10.9 with CONFIG_DRM_I915=m and CONFIG_DRM_I915_KMS=y and /etc/modprobe.d/test.conf:options i915 modeset=1, acpi_osi
dmesg from a boot of kernel 3.10.9 with CONFIG_DRM_I915=m and CONFIG_DRM_I915_KMS=y and /etc/modprobe.d/test.conf:options i915 modeset=1, acpi_backlight
dmesg from a boot of kernel 3.10.6 with CONFIG_DRM_I915=m and CONFIG_DRM_I915_KMS=n and /etc/modprobe.d/test.conf:options i915 modeset=1
kernel .config for 3.10.8 with KMS=n
dmesg from a boot of kernel 3.11.0-rc7 with CONFIG_DRM_I915=m and CONFIG_DRM_I915_KMS=y and /etc/modprobe.d/test.conf:options i915 modeset=1
diff of kernel .configs 3.10.6(vanilla) vs. 3.10.6-gentoo

Description MDBürkle 2013-07-28 20:45:20 UTC
Created attachment 107029 [details]
lspci -vmmnn

Hi,
when I have /etc/modprobe.d/test.conf with
  options i915 modeset=1
and I try to run a kernel compiled with
  CONFIG_DRM_I915=m
  CONFIG_DRM_I915_KMS=y
then loading of the i915 module results in loss of terminal output, a black screen.
Typing in blindly (ie. logging in and typing commands) works.
After start of X11 (with ati-drivers ie. fglrx which requires KMS), the screen can be turned on by using the laptop's Brigthness-Up and -Down buttons. Switching to tty1-6 (with ctrl-alt-F1-6) results in some colored, blurred pixels and blindly logging in etc. is possible.

When I have the same test.conf with kernel compiled with
  CONFIG_DRM_I915=m
  # CONFIG_DRM_I915_KMS is not set
then loading of the i915 module results in a normal working console and after start of X11, switching to tty1-6 behaves normal.

If I don't have test.conf with "options i915 modeset=1", then the first scenario fails in the same manner (and the second scenario fails to run X11).

In addition to that, resuming (from suspend-to-ram) does not work any more since 3.10.x kernels; 3.8 and 3.9 up to 3.9.11-gentoo-r1, but that is another bug.

What commands should I run in which scenario (and also note if You require a vanilla kernel as I'm usually running the Gentoo lightly patched series) to give You more informations?

Kind regards,
mdb
Comment 1 Daniel Vetter 2013-08-04 22:53:30 UTC
Please boot with drm.debug=0xe added to your kernel cmdline and kms enabled, and then attach the complete dmesg (doing that via ssh is probably easiest).

Also please remove the ati blob driver completely from your system in case it interferes badly somehow (they do some ugly stuff ...).
Comment 2 MDBürkle 2013-08-06 22:22:14 UTC
Created attachment 107127 [details]
dmesg.gz from a boot of a kernel with CONFIG_DRM_I915=m and CONFIG_DRM_I915_KMS=y and /etc/modprobe.d/test.conf:options i915 modeset=1

Additionally, please NOTE:

 - it's a gentoo-kernel (3.10.2-gentoo) (though these are close to vanilla)

 - two lines were commented out in these runs (not to turn the backlight off)
   in drivers/gpu/drm/i915/i915_drv.c, lines 550+551,
                //list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
                //      dev_priv->display.crtc_disable(crtc);

 - fglrx.ko was renamed to fglrx.ko_off to prevent auto-loading of the module
   and xdm-service was turned off, too

 - loading of fglrx.ko made no difference (with or without fglrx, 
   the results were the same: only dependent on .config value DRM_I915_KMS)
Comment 3 MDBürkle 2013-08-06 22:31:38 UTC
Created attachment 107129 [details]
dmesg.gz from a boot of a kernel with CONFIG_DRM_I915=m and "CONFIG_DRM_I915_KMS not set" and /etc/modprobe.d/test.conf:options i915 modeset=1

dmesg from kernel with .config DRM_I915_KMS "not set" as the only difference opposed to attachment#107127 [details].

Notes: consoles visible (and fully usable),
 additionally: NOT screwed up after closing/opening the LID switch/laptop but normal resume / continuation of work.

attachment#107127 [details] (the second attachment in this bug) in addition to not showing anything, was producing HEAT after CLOSING/OPENING the laptop, did not react on ctrl-alt-del, "shutdown -r now".
Comment 4 MDBürkle 2013-08-06 22:55:05 UTC
...and commenting out lines 550+551 lead to a GREY screen at boot.
Comment 5 MDBürkle 2013-08-06 23:20:58 UTC
Created attachment 107130 [details]
DRM_I915_KMS=y, fglrx loaded, two lines commented out -- GREY screens at boot

dmesg with fglrx loaded and KMS=y
Comment 6 MDBürkle 2013-08-06 23:22:27 UTC
Created attachment 107131 [details]
DRM_I915_KMS not set, fglrx loaded, two lines commented out -- consoles visible and usable

another dmesg with fglrx loaded and DRM_I915_KMS not set
Comment 7 MDBürkle 2013-08-06 23:32:47 UTC
with the last one (attachment#107131 [details]) and X running, the system behaves differently on lid-close-acpi-event: it's suspending to RAM, but upon resuming, the (graphical) cursor (arrow) is shown (can't be moved) and the system is frozen...
Comment 8 MDBürkle 2013-08-06 23:33:48 UTC
any tests with vanilla kernels required?

what now?
Comment 9 Jani Nikula 2013-08-08 12:37:46 UTC
What if you try to boot with either acpi_osi="!Windows 2012" or acpi_backlight=vendor kernel parameter?
Comment 10 MDBürkle 2013-08-10 19:27:34 UTC
Created attachment 107171 [details]
DRM_I915_KMS not set, fglrx loaded, -- consoles visible and usable

(In reply to Jani Nikula from comment #9)
> What if you try to boot with either acpi_osi="!Windows 2012" or
> acpi_backlight=vendor kernel parameter?

Just booted ok with "I915_KMS not set" and both parameters on the cmdline.

Attached dmesg (script .log / typescript) from the last boot.

Hung with
Comment 11 MDBürkle 2013-08-10 19:30:33 UTC
(In reply to MDBürkle from comment #10)
> Created attachment 107171 [details]
> DRM_I915_KMS not set, fglrx loaded, -- consoles visible and usable
> ...
> Hung with

(accidentally hit return on creating the attachment, sry)

...with kernel 3.10.5-gentoo-r1 and cmdline

 root=/dev/sda8 vga=0x0f04 drm.debug=0xe acpi_osi="!Windows 2012" acpi_backlight=vendor
Comment 12 Jani Nikula 2013-08-11 09:00:50 UTC
From the log:
[    0.000000] Command line: root=/dev/sda8 vga=0x0f04 drm.debug=0xe
i.e. you don't have acpi_osi or acpi_backlight set.

Let's focus on *one* thing at a time. Please try:

1) I915_KMS=y. Do not attach logs for KMS=n.

2) Do *not* load fglrx. Do not attach logs with fglrx loaded.

3a) What happens with acpi_osi="!Windows 2012"

3b) What happens with acpi_backlight=vendor

i.e. *either* of the parameters, *not* both.
Comment 13 MDBürkle 2013-08-11 16:55:31 UTC
Created attachment 107172 [details]
kernel 3.9.11-gentoo-r1, KMS=y, acpi_osi="!Windows 2012", acpi_backlight=vendor

consoles unusable (GREY)
Comment 14 MDBürkle 2013-08-11 16:56:11 UTC
Created attachment 107173 [details]
kernel 3.9.11-gentoo-r1, KMS=y, acpi_osi="!Windows 2012"

consoles unusable (GREY)
Comment 15 MDBürkle 2013-08-11 16:56:52 UTC
Created attachment 107174 [details]
kernel 3.9.11-gentoo-r1, KMS=y, acpi_backlight=vendor

consoles unusable (GREY)
Comment 16 MDBürkle 2013-08-11 17:52:20 UTC
(In reply to Jani Nikula from comment #12)

> Please try:
> 
> 1) I915_KMS=y. Do not attach logs for KMS=n.
> 2) Do *not* load fglrx. Do not attach logs with fglrx loaded.

The problem with these is, that the consoles are not visible.
My X configuration is using fglrx, so if I do not load fglrx then X cannot start, either - i.e. the system is unusable, only blind typing is possible. (And I don't have a secondary computer to run a ssh client on, either.)

> 3a) What happens with acpi_osi="!Windows 2012"
> 
> 3b) What happens with acpi_backlight=vendor
> 
> i.e. *either* of the parameters, *not* both.

ok, that's one test less, sigh.
3a) is in comment#14 (attachment#107173 [details])
3b) is in comment#15 (attachment#107174 [details])

will go for 3.10.5-gentoo, again, most likely this evening.
Comment 17 MDBürkle 2013-08-11 18:08:45 UTC
Created attachment 107175 [details]
kernel 3.10.5-gentoo-r1, KMS=y, acpi_osi

did HANG on "shutdown -r now"
Comment 18 MDBürkle 2013-08-11 18:09:46 UTC
Created attachment 107176 [details]
kernel 3.10.5-gentoo-r1, KMS=y, acpi_backlight

rebooted normally
Comment 19 MDBürkle 2013-08-11 18:28:09 UTC
Created attachment 107177 [details]
kernel 3.10.5-gentoo-r1, KMS=y, no acpi cmdline options

rebooted normally
Comment 20 MDBürkle 2013-08-11 18:30:17 UTC
Created attachment 107178 [details]
kernel 3.10.5-gentoo-r1, KMS=y, acpi_osi, acpi_backlight

rebooted normally -- both acpi_ parameters here just to try if that will prevent a normal reboot.
Comment 21 MDBürkle 2013-08-11 18:45:23 UTC
comment#17 attachment#107175 [details] acpi_osi
comment#18 attachment#107176 [details] acpi_backlight
comment#19 attachment#107177 [details] no acpi options
comment#20 attachment#107178 [details] acpi_osi and acpi_backlight

all with GREY consoles (backlight on, but "black" or better a "GREY" display)

as for comment#17: the HANG was not reproducible, just did a quick boot with the same options (without logging in and with ctrl-alt-del instead of "shutdown -r now") which succeeded.


BTW: making a diff of attachment#107127 [details] and attachment#107129 [details] (the first two) via

diff <( awk -F '[][]+' 'NF>2{$2=""};{print}' typescript-20130806-233231 | sort )
     <( awk -F '[][]+' 'NF>2{$2=""};{print}' typescript-20130806-232628 | sort )
| less +Gg

shows some differences in assigned IRQs, input device numbers, BogoMIPS and timer values.
Comment 22 MDBürkle 2013-08-26 19:48:37 UTC
This bug is still in status NEEDINFO.

Please keep in mind that the consoles are visible and fully usable if KMS is turned off via .config option "# CONFIG_DRM_I915_KMS not set" at compile time, but at runtime turned on via a modprobe parameter (options i915 modeset=1).

I upgraded my X configuration to run with and without fglrx, meanwhile.

Should I try black screens with the latest kernel (3.10.9), anyone interested in drm.debug=0xe dmesg output?

What else can I do to provide needed informations?
Comment 23 MDBürkle 2013-08-26 20:08:13 UTC
(In reply to Jani Nikula from comment #12)
> From the log:
> [    0.000000] Command line: root=/dev/sda8 vga=0x0f04 drm.debug=0xe
> i.e. you don't have acpi_osi or acpi_backlight set.

Jani, this quote is /not/ from attachment#107171 [details] which followed Your request and which contains:

[    0.000000] Linux version 3.10.5-gentoo-r1 (root@lapmdb-hpl) (gcc version 4.6.3 (Gentoo 4.6.3 p1.13, pie-0.5.2) ) #1 SMP PREEMPT Thu Aug 8 19:43:35 CEST 2013
[    0.000000] Command line: root=/dev/sda8 vga=0x0f04 drm.debug=0xe acpi_osi="!Windows 2012" acpi_backlight=vendor

AFAIK there is no way to see the .config defines other than doing a "modprobe configs; zgrep I915 /proc/config.gz", which I missed to include until now...
Comment 24 Jani Nikula 2013-08-27 07:01:43 UTC
(In reply to MDBürkle from comment #3)
> Created attachment 107129 [details]
> dmesg.gz from a boot of a kernel with CONFIG_DRM_I915=m and
> "CONFIG_DRM_I915_KMS not set" and /etc/modprobe.d/test.conf:options i915
> modeset=1

(In reply to MDBürkle from comment #22)
> Please keep in mind that the consoles are visible and fully usable if KMS is
> turned off via .config option "# CONFIG_DRM_I915_KMS not set" at compile
> time, but at runtime turned on via a modprobe parameter (options i915
> modeset=1).

Is this in reference to comment #3 quoted above? From the dmesg, i915 does not get loaded at all. (CONFIG_DRM_I915_KMS=n leaves out MODULE_DEVICE_TABLE in the driver.) So this does not bring us any new information.

> I upgraded my X configuration to run with and without fglrx, meanwhile.

Does your X work without fglrx, with CONFIG_DRM_I915_KMS=y? If it's CONFIG_DRM_I915_KMS=n, it's also not interesting.

> What else can I do to provide needed informations?

Have you ever had working output with i915 KMS only? Have you looked at your BIOS GPU settings?
Comment 25 Jani Nikula 2013-08-27 07:08:37 UTC
PS. For future reference, it is slightly more convenient to read plain text attachments directly in the browser instead of having to download and unzip. Thanks.
Comment 26 MDBürkle 2013-08-27 17:57:31 UTC
(In reply to Jani Nikula from comment #25)
> more convenient to read plain text attachments directly in the browser

I'll keep that in mind.
Just bothered about the space required for two dozen dmesg files and "script.log" files being recognized as binary files anyway...


(In reply to Jani Nikula from comment #24)
> (In reply to MDBürkle from comment #3)
> > Created attachment 107129 [details]
> 
> (In reply to MDBürkle from comment #22)
> > consoles are visible and fully usable if .config option
> > "# CONFIG_DRM_I915_KMS not set" turned on via (options i915 modeset=1).
> 
> Is this in reference to comment #3 quoted above? From the dmesg, i915 does
> not get loaded at all.

Huh? or oops! Usually, i915 gets loaded automatically within the Gentoo boot process with a msg like "letting udev process events", which denotes the time when the console gets invisible or not... don't know what happened there. There might be more dmesg files without i915 lines, at least locally there are more.


> (CONFIG_DRM_I915_KMS=n leaves out MODULE_DEVICE_TABLE
> in the driver.) So this does not bring us any new information.

MODULE_DEVICE_TABLE sounds like info about which devices are supported by the module. Bad naming then, if this is solely a table for KMS, I wonder.


> > I upgraded my X configuration to run with and without fglrx, meanwhile.
> 
> Does your X work without fglrx, with CONFIG_DRM_I915_KMS=y? If it's
> CONFIG_DRM_I915_KMS=n, it's also not interesting.

I run modules with CONFIG_DRM_I915_KMS=y only for testing as I want to see what happens during fsck, just in case...
My X configuration should work with either type of i915 modules.
I just built the module with ...KMS=y and am preparing for reboot. I expect having to press Fn+BrightnessUp to make the gdm login screen visible. :-/


> > What else can I do to provide needed informations?
> 
> Have you ever had working output with i915 KMS only? Have you looked at your
> BIOS GPU settings?

There are no GPU settings in the BIOS (never in any version I had installed). However, I'll do a BIOS update (have to boot Windoof for that) these days, too - provided availability.

I'm unsure about "working output" with i915 KMS=y - I don't remember having a working console with KMS=y, must have been long ago.
I'll check which versions of Linux kernels I ran in [most of] the lifetime of this computer, then I can think about testing (some) old kernels (again).

Kind regards
Comment 27 MDBürkle 2013-08-27 19:16:14 UTC
Created attachment 107335 [details]
dmesg.gz from a boot of a kernel with CONFIG_DRM_I915=m and CONFIG_DRM_I915_KMS=y and /etc/modprobe.d/test.conf:options i915 modeset=1
Comment 28 MDBürkle 2013-08-27 19:26:17 UTC
Created attachment 107336 [details]
dmesg from a boot of kernel 3.10.9 with CONFIG_DRM_I915=m and CONFIG_DRM_I915_KMS=y and /etc/modprobe.d/test.conf:options i915 modeset=1

black/grey console after "processing uevents" boot message.

lapmdb-hpl ~ #>> zgrep I915 /proc/config.gz 
CONFIG_DRM_I915=m
CONFIG_DRM_I915_KMS=y
lapmdb-hpl ~ #>>
Comment 29 MDBürkle 2013-08-28 05:34:47 UTC
Created attachment 107337 [details]
dmesg from a boot of kernel 3.10.9 with CONFIG_DRM_I915=m and CONFIG_DRM_I915_KMS=n and /etc/modprobe.d/test.conf:options i915 modeset=1

Module i915 was loaded very late, most likely by X startup.

Consoles were black/grey/unusable after switch to X. :-(

lapmdb-hpl ~ #>> modprobe configs
lapmdb-hpl ~ #>> zgrep I915 /proc/config.gz 
CONFIG_DRM_I915=m
# CONFIG_DRM_I915_KMS is not set
lapmdb-hpl ~ #>>
Comment 30 MDBürkle 2013-08-28 05:45:52 UTC
Created attachment 107338 [details]
dmesg from a boot of kernel 3.10.9 with CONFIG_DRM_I915=m and CONFIG_DRM_I915_KMS=y and /etc/modprobe.d/test.conf:options i915 modeset=1, acpi_osi

with cmdline addition: acpi_osi="!Windows 2012"

same result as without acpi_osi.

lapmdb-hpl ~ #>> modprobe configs
lapmdb-hpl ~ #>> zgrep I915 /proc/config.gz
CONFIG_DRM_I915=m
CONFIG_DRM_I915_KMS=y
lapmdb-hpl ~ #>>
Comment 31 MDBürkle 2013-08-28 05:57:07 UTC
Created attachment 107339 [details]
dmesg from a boot of kernel 3.10.9 with CONFIG_DRM_I915=m and CONFIG_DRM_I915_KMS=y and /etc/modprobe.d/test.conf:options i915 modeset=1, acpi_backlight

same result (consoles invisible) with cmdline: acpi_backlight=vendor

lapmdb-hpl ~ #>> modprobe configs
lapmdb-hpl ~ #>> zgrep I915 /proc/config.gz 
CONFIG_DRM_I915=m
CONFIG_DRM_I915_KMS=y
lapmdb-hpl ~ #>>
Comment 32 MDBürkle 2013-08-28 06:25:42 UTC
Created attachment 107340 [details]
dmesg from a boot of kernel 3.10.6 with CONFIG_DRM_I915=m and CONFIG_DRM_I915_KMS=n and /etc/modprobe.d/test.conf:options i915 modeset=1

consoles visible/usable; module loaded by X startup.

lapmdb-hpl ~ #>> modprobe configs
lapmdb-hpl ~ #>> zgrep I915 /proc/config.gz 
CONFIG_DRM_I915=m
# CONFIG_DRM_I915_KMS is not set
lapmdb-hpl ~ #>>
Comment 33 MDBürkle 2013-08-28 16:58:35 UTC
Created attachment 107343 [details]
kernel .config for 3.10.8 with KMS=n

Kernel 3.10.8 is running into some stack trace at boot, the [time=0.87] is about hd detection.
Comment 34 MDBürkle 2013-08-28 19:59:40 UTC
Booted some other linux kernels (3.10.6-gentoo, 3.10.7-gentoo, 3.9.11-gentoo-r1, 3.10.6(vanilla), 3.10.0(vanilla)) with KMS=n, because 3.10.9-gentoo does not have visible/usable VTs with KMS=n.

Result: VTs are invisible/unusable in all 3.10.x versions, no matter if KMS=n.

Will try 3.11-rc7, next.
Comment 35 MDBürkle 2013-08-28 20:28:36 UTC
3.11-rc7 with KMS=n has invisible VTs.
Comment 36 MDBürkle 2013-08-28 21:55:43 UTC
Created attachment 107345 [details]
dmesg from a boot of kernel 3.11.0-rc7 with CONFIG_DRM_I915=m and CONFIG_DRM_I915_KMS=y and /etc/modprobe.d/test.conf:options i915 modeset=1

VTs invisible.

Jani, do You want output from acpi_osi and acpi_backlight cmdline additions with that kernel?
Comment 37 MDBürkle 2013-08-28 22:26:52 UTC
(In reply to MDBürkle from comment #32)
> dmesg from a boot of kernel 3.10.6 with CONFIG_DRM_I915_KMS=n
> 
> consoles visible/usable; module loaded by X startup.

That was with 3.10.6-gentoo and reproduced.


(In reply to MDBürkle from comment #34)
> Booted some other linux kernels with KMS=n, because
> 3.10.9-gentoo does not have visible/usable VTs with KMS=n.
> 
> Result: VTs are invisible/unusable in all 3.10.x versions

incorrect, see above. Configs differ slightly, config-diff follows.

Will try some other combinations, ie. 3.11-rc7 and 3.10.6(vanilla) with 
 modprobe.blacklist= fglrx,radeon.
Comment 38 MDBürkle 2013-08-28 22:28:38 UTC
Created attachment 107348 [details]
diff of kernel .configs 3.10.6(vanilla) vs. 3.10.6-gentoo
Comment 39 MDBürkle 2013-08-28 23:03:05 UTC
Kernel 3.10.6(vanilla, KMS=n) with cmdline modprobe.blacklist=fglrx,radeon leads to visible VTs.

=> is this effect due to radeon or vga_switcheroo (which gets activated when both i915 and radeon are loaded AFAIK)

=> will try the same with 3.11.0-rc7.
Comment 40 MDBürkle 2013-08-29 00:48:17 UTC
Kernel 3.11.0-rc7(vanilla, KMS=n) with cmdline modprobe.blacklist=fglrx,radeon leads to visible VTs.

(In reply to MDBürkle from comment #34)
> Result: VTs are invisible/unusable in all 3.10.x versions, no matter if
> KMS=n.

wrong - but if radeon is loaded and vga_switcheroo is in the kernel, then the VTs are unusable as soon as i915 is loaded.
Comment 41 MDBürkle 2013-08-29 01:09:45 UTC
(In reply to MDBürkle from comment #40)
> Kernel 3.11.0-rc7(vanilla, KMS=n) with cmdline
> modprobe.blacklist=fglrx,radeon leads to visible VTs.
> 
> if radeon is loaded and vga_switcheroo is in the kernel, then
> the VTs are unusable as soon as i915 is loaded.

Without vga_switcheroo, the results remain the same (depending on radeon being loaded before i915).

Even when radeon is loaded later by manually forcing it to load (modprobe radeon), the VTs remain visible.

Couldn't unload i915 as it's still in use (1), even when X is stopped.

Any comments?
Comment 42 Jani Nikula 2013-10-10 13:01:38 UTC
Looking back at this bug now, in the abundance of dmesgs and configs and options and everything, I am slightly lost on what it is that is the crux of the problem here.

It seems that it is related to the coexistence of i915 and fglrx, that you expect VTs and backlight to be handled by i915 but X by fglrx, and that you're unable to reproduce the problem with pure i915 and KMS. Is that right?

The fact is that we can't debug problems related to proprietary binary only drivers. We also don't support your hardware without KMS (i915 won't get loaded without KMS). 

I am closing this as invalid. Please reopen if you can reproduce with i915 KMS, without binary drivers. Thanks.