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.
Created attachment 101024 [details] configuration of the 3.15.0 kernel
Created attachment 101026 [details] dmesg output with drm debug for vanilla 3.15 (screen black)
Created attachment 101027 [details] dmesg output with drm debug for modfied 3.15 (working)
I also tried to not set CONFIG_DRM_I915_FBDEV. But this also results in a black screen.
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
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.
> 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?
After X should be fine, but really as early as possible in the boot sequence after KMS loads would be ideal.
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.
Created attachment 101252 [details] xlog0.txt
Created attachment 101253 [details] xlog1.txt
I can confirm this issue. This happened to me after updating to 3.15 as well.
Ok trying stock 3.15 on my T61 now. Things worked with drm-intel-nightly though so it may just be a missing fix.
Yep, I see this with stock 3.15 here too. Debugging now.
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;
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.
I tested with 3.16, and it works.
Original reporter indicates this is fixed. Yay!
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.