Bug 60643

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

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)

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

...and commenting out lines 550+551 lead to a GREY screen at boot.

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

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

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

any tests with vanilla kernels required?

what now?

What if you try to boot with either acpi_osi="!Windows 2012" or acpi_backlight=vendor kernel parameter?

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

(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

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.

Created attachment 107172 [details]
kernel 3.9.11-gentoo-r1, KMS=y, acpi_osi="!Windows 2012", acpi_backlight=vendor

consoles unusable (GREY)

Created attachment 107173 [details]
kernel 3.9.11-gentoo-r1, KMS=y, acpi_osi="!Windows 2012"

consoles unusable (GREY)

Created attachment 107174 [details]
kernel 3.9.11-gentoo-r1, KMS=y, acpi_backlight=vendor

consoles unusable (GREY)

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

Created attachment 107175 [details]
kernel 3.10.5-gentoo-r1, KMS=y, acpi_osi

did HANG on "shutdown -r now"

Created attachment 107176 [details]
kernel 3.10.5-gentoo-r1, KMS=y, acpi_backlight

rebooted normally

Created attachment 107177 [details]
kernel 3.10.5-gentoo-r1, KMS=y, no acpi cmdline options

rebooted normally

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

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?

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

(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?

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.

(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

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

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 ~ #>>

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 ~ #>>

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 ~ #>>

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 ~ #>>

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 ~ #>>

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.

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.

3.11-rc7 with KMS=n has invisible VTs.

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?

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

Created attachment 107348 [details]
diff of kernel .configs 3.10.6(vanilla) vs. 3.10.6-gentoo

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.

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.

(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?

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.