Bug 80010 - [965gm bisected regression] screen black when starting X
Summary: [965gm bisected regression] screen black when starting X
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: x86 (IA32) Linux (All)
: highest normal
Assignee: Jesse Barnes
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-14 00:43 UTC by Thomas Rohwer
Modified: 2016-10-19 11:09 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
log of bisection process (2.65 KB, text/plain)
2014-06-14 00:43 UTC, Thomas Rohwer
no flags Details
configuration of the 3.15.0 kernel (72.55 KB, text/plain)
2014-06-14 00:45 UTC, Thomas Rohwer
no flags Details
dmesg output with drm debug for vanilla 3.15 (screen black) (103.09 KB, text/plain)
2014-06-14 00:48 UTC, Thomas Rohwer
no flags Details
dmesg output with drm debug for modfied 3.15 (working) (63.96 KB, text/plain)
2014-06-14 00:49 UTC, Thomas Rohwer
no flags Details
xlog0.txt (13.73 KB, text/plain)
2014-06-17 16:58 UTC, Thomas Rohwer
no flags Details
xlog1.txt (13.74 KB, text/plain)
2014-06-17 16:58 UTC, Thomas Rohwer
no flags Details

Description Thomas Rohwer 2014-06-14 00:43:37 UTC
Created attachment 101023 [details]
log of bisection process

I have the problem with newer Linux kernels, that after starting X the screen is black. Suspend/resume fixes the problem.
I bisected the problem (log attached). I then reproduced the problem with Linux kernel version 3.15.0:
In the vanilla version the problem exists (dmesg output attached in comment).
Removing the line

.initial_config = intel_fb_initial_config,

in drivers/gpu/drm/i915/intel_fbdev.c

fixes the problem (dmesg output attached in comment).

The machine is a Thinkpad T61. I also attached the kernel .config in a comment.
Comment 1 Thomas Rohwer 2014-06-14 00:45:20 UTC
Created attachment 101024 [details]
configuration of the 3.15.0 kernel
Comment 2 Thomas Rohwer 2014-06-14 00:48:22 UTC
Created attachment 101026 [details]
dmesg output with drm debug for vanilla 3.15 (screen black)
Comment 3 Thomas Rohwer 2014-06-14 00:49:09 UTC
Created attachment 101027 [details]
dmesg output with drm debug for modfied 3.15 (working)
Comment 4 Thomas Rohwer 2014-06-14 00:56:06 UTC
I also tried to not set CONFIG_DRM_I915_FBDEV.
But this also results in a black screen.
Comment 5 Jani Nikula 2014-06-16 12:58:20 UTC
commit eb1bfe807cb7b62a326fa20df5e3118a32c6f923
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Wed Feb 12 12:26:25 2014 -0800

    drm/i915: allow re-use BIOS connector config for initial fbdev config v3
Comment 6 Chris Wilson 2014-06-16 15:48:48 UTC
So as far as I can tell, this should have worked. In the working configuration we setup LVDS on pipe A, but in the broken configuration we try to keep the bios pipe B.  About the only difference is that in the non-working configuration we skip disabling pipe A as we believe it is dead (in the working configuration we zap the other pipe as well).

What would be useful would be an intel_reg_dumper of working and broken kernels.
Comment 7 Thomas Rohwer 2014-06-17 12:21:31 UTC
> What would be useful would be an intel_reg_dumper of working and broken kernels.

Ok, I can try to get that information. Should I use that tool after starting X?
And in case of the non-working kernel before I suspend/resume?
Comment 8 Chris Wilson 2014-06-17 12:24:01 UTC
After X should be fine, but really as early as possible in the boot sequence after KMS loads would be ideal.
Comment 9 Thomas Rohwer 2014-06-17 16:57:33 UTC
Ok,

I tried this:

intel_reg_dumper > ~/xlog0.txt
modprobe i915
intel_reg_dumper > ~/xlog1.txt
/bin/su -l -c "exec startx" tr

instead of just starting X with both kernels.

When I load i915 before starting X with startx, the screen goes black and
X and suspend/resume does not recover from this situation with
BOTH kernels. The content of xlog0.txt and xlog1.txt is
the same for both kernels (attached).

I verified that the original behaviour still exists: With vanilla 3.15 I get a black screen after starting X and with the patched one (i.e.
.initial_config = intel_fb_initial_config removed) it works.
Comment 10 Thomas Rohwer 2014-06-17 16:58:24 UTC
Created attachment 101252 [details]
xlog0.txt
Comment 11 Thomas Rohwer 2014-06-17 16:58:54 UTC
Created attachment 101253 [details]
xlog1.txt
Comment 12 David Kolossa 2014-06-19 16:11:34 UTC
I can confirm this issue. This happened to me after updating to 3.15 as well.
Comment 13 Jesse Barnes 2014-06-26 18:55:53 UTC
Ok trying stock 3.15 on my T61 now.  Things worked with drm-intel-nightly though so it may just be a missing fix.
Comment 14 Jesse Barnes 2014-06-26 20:58:33 UTC
Yep, I see this with stock 3.15 here too.  Debugging now.
Comment 15 Chris Wilson 2014-06-27 17:50:11 UTC
Jesse, try

commit e72faea9b3296faad92f0a1fa0bced6a522ff4d6
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed May 21 09:31:37 2014 +0100

    vt-bug

diff --git a/drivers/tty/vt/vt_ioctl.c b/drivers/tty/vt/vt_ioctl.c
index 2bd78e2..a7bdc4b 100644
--- a/drivers/tty/vt/vt_ioctl.c
+++ b/drivers/tty/vt/vt_ioctl.c
@@ -684,7 +684,8 @@ int vt_ioctl(struct tty_struct *tty,
                        console_unlock();
                        if (ret)
                                break;
-                       set_console(arg);
+                       if (set_console(arg))
+                               ret = -EIO;
                }
                break;
Comment 16 Denis Dupeyron 2014-08-04 01:11:10 UTC
I also have a T61 and my machine has the exact same symptoms. The last kernel I tried it with is 3.15.8.

Removing the line in drivers/gpu/drm/i915/intel_fbdev.c as in comment #1 works around the issue. However, the patch in comment #15 does not seem to help.

Do not hesitate to ask if you need me to try other patches.
Comment 17 Thomas Rohwer 2014-08-11 22:40:42 UTC
I tested with 3.16, and it works.
Comment 18 Jesse Barnes 2014-08-19 19:50:03 UTC
Original reporter indicates this is fixed.  Yay!
Comment 19 Jari Tahvanainen 2016-10-19 11:09:33 UTC
Closing resolved+fixed. Verified by Reporter.


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.