Bug 73291 - Kernel 3.13.7 boots with hybrid Intel/ATI but to blank graphical screen
Summary: Kernel 3.13.7 boots with hybrid Intel/ATI but to blank graphical screen
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: x86-64 Linux
: P1 high
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-31 14:34 UTC by Mike Cloaked
Modified: 2016-06-05 03:25 UTC (History)
4 users (show)

See Also:
Kernel Version: 3.13.7
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
systemd journal for current boot with kernel 3.13.6 (125.58 KB, text/x-log)
2014-03-31 14:34 UTC, Mike Cloaked
Details
xorg log for kernel 3.13.6 (24.30 KB, text/plain)
2014-03-31 14:34 UTC, Mike Cloaked
Details
systemd journal for current boot with kernel 3.13.7 (116.61 KB, text/plain)
2014-03-31 14:35 UTC, Mike Cloaked
Details
xorg log for kernel 3.13.7 (26.40 KB, text/plain)
2014-03-31 14:35 UTC, Mike Cloaked
Details
systemd journal with 3.13.7 booted with radeon module blacklisted (122.38 KB, text/plain)
2014-03-31 16:00 UTC, Mike Cloaked
Details

Description Mike Cloaked 2014-03-31 14:34:14 UTC
Created attachment 131071 [details]
systemd journal for current boot with kernel 3.13.6

Running arch linux stock kernel. Previous Kernel 3.13.6 boots to graphical screen giving a usable laptop but problems with radeon apparent from systemd journal log. Updating the kernel to 3.13.7 boots the laptop, but the graphical screen is blank apart from static cursor at top left of the screen. The kernel is still running and able to ssh in to get at the log files (attached). No graphics is usable.

Hybrid graphics in this Lenovo Thinkpad S540 is:

$ lspci | egrep '(Graphics|Display)'
00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09)
06:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Sun XT [Radeon HD 8670A]

i915 and radeon modules are built into the initial ramdisk.

xrandr only sees one provider:

$ xrandr --listproviders
Providers: number : 1
Provider 0: id: 0x48 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 5 associated providers: 0 name:Intel

I have tried adding intel.modeset=0, and separately  radeon.runpm=0 to the kernel line but this does not remedy the situation.
Comment 1 Mike Cloaked 2014-03-31 14:34:59 UTC
Created attachment 131081 [details]
xorg log for kernel 3.13.6
Comment 2 Mike Cloaked 2014-03-31 14:35:31 UTC
Created attachment 131091 [details]
systemd journal for current boot with kernel 3.13.7
Comment 3 Mike Cloaked 2014-03-31 14:35:54 UTC
Created attachment 131101 [details]
xorg log for kernel 3.13.7
Comment 4 Mike Cloaked 2014-03-31 14:42:22 UTC
The system is dual boot arch linux and Windows 8.1, boot is UEFI using the rEFInd boot manager, but that should not be relevant to the fail mode reported in this bugzilla.
Comment 5 Alex Deucher 2014-03-31 14:57:33 UTC
The radeon driver appears to be loading fine.  Additionally, there are no displays connected to the radeon so it will only be used when you set it up as an offload sink.  The warning in your kernel logs appear to be from the intel driver:

Mar 31 15:01:10 lenovo1 kernel: ------------[ cut here ]------------
Mar 31 15:01:10 lenovo1 kernel: WARNING: CPU: 1 PID: 57 at drivers/gpu/drm/i915/intel_opregion.c:266 swsci+0x2ec/0x300 [i915]()
Mar 31 15:01:10 lenovo1 kernel: excessive driver sleep timeout (DSPL) 1280
Mar 31 15:01:10 lenovo1 kernel: Modules linked in: i915(+) video button intel_agp intel_gtt radeon i2c_algo_bit drm_kms_helper ttm drm i2c_core
Mar 31 15:01:10 lenovo1 kernel: CPU: 1 PID: 57 Comm: modprobe Not tainted 3.13.6-1-ARCH #1
Mar 31 15:01:10 lenovo1 kernel: Hardware name: LENOVO 20B3CTO1WW/20B3CTO1WW, BIOS GPET54WW (1.54 ) 02/19/2014
Mar 31 15:01:10 lenovo1 kernel:  0000000000000009 ffff880221de7810 ffffffff81513274 ffff880221de7858
Mar 31 15:01:10 lenovo1 kernel:  ffff880221de7848 ffffffff81061a3d ffffc90000c68218 ffff880221d60000
Mar 31 15:01:10 lenovo1 kernel:  00000000000001f4 0000000000000008 ffff880221de7920 ffff880221de78a8
Comment 6 Mike Cloaked 2014-03-31 15:30:01 UTC
Perhaps this warning will not occur when kernel 3.14.x is used when it is released to arch in the near future. I presume that new patches in kernel 3.13.7 makes the difference between a successful boot to graphical screen in 3.13.6 and fail in 3.13.7 but it would be nice to know if there is a workaround until this is resolved in kernel > 3.13.7?
Comment 7 Alex Deucher 2014-03-31 15:40:11 UTC
(In reply to Mike Cloaked from comment #6)
> Perhaps this warning will not occur when kernel 3.14.x is used when it is
> released to arch in the near future. I presume that new patches in kernel
> 3.13.7 makes the difference between a successful boot to graphical screen in
> 3.13.6 and fail in 3.13.7 but it would be nice to know if there is a
> workaround until this is resolved in kernel > 3.13.7?

Can you bisect?  If the warning is related to the problem, it's an intel driver issue rather than a radeon driver issue.  Does the system work ok if you blacklist the radeon driver?  E.g., add modprobe.blacklist=radeon to the kernel command line in grub.
Comment 8 Mike Cloaked 2014-03-31 15:44:01 UTC
What I am seeing seems to be the same as in the Fedora bug at:

https://bugzilla.redhat.com/show_bug.cgi?id=1070219

I don't have the system set up for bisecting. However I will boot with the radeon driver blacklisted and report back.
Comment 9 Mike Cloaked 2014-03-31 15:50:25 UTC
Booting with modprobe.blacklist=radeon added to the kernel line in the rEFInd boot manager gives a successful boot to a graphical screen.  So thank you, this is a workaround for the present.

I can upload the systemd journal for this boot if it is useful?
Comment 10 Mike Cloaked 2014-03-31 16:00:50 UTC
Created attachment 131111 [details]
systemd journal with 3.13.7 booted with radeon module blacklisted
Comment 11 Mike Cloaked 2014-03-31 16:22:50 UTC
For completeness I removed the radeon module from the initial ramdisk, and added:

install radeon /bin/false 

to the file /etc/modprobe.d/blacklist.conf

Now the system boots to a working graphical screen for kernel 3.13.7 with only the Intel i915 running.
Comment 12 Mike Cloaked 2014-04-01 17:17:31 UTC
Is this bug related to https://bugzilla.kernel.org/show_bug.cgi?id=65761
Comment 13 Alex Deucher 2014-04-01 17:22:17 UTC
(In reply to Mike Cloaked from comment #12)
> Is this bug related to https://bugzilla.kernel.org/show_bug.cgi?id=65761

I don't think so.  In your case you seem to lose the display before the radeon card is even used.  Are you sure radeon.runpm=0 doesn't help?
Comment 14 Mike Cloaked 2014-04-01 17:29:57 UTC
Yes prior to blacklisting the radeon module I tried booting with radeon.runpm=0 and I still got the blank screen for graphical boot.
Comment 15 abandoned account 2015-04-25 16:22:18 UTC
Mar 31 15:01:10 lenovo1 kernel: x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106

It might be a long shot but, maybe try with PAT disabled ? and if you do, you might get this warning:
[    0.868163] [drm] Please enable CONFIG_MTRR and CONFIG_X86_PAT for better per
formance thanks to write-combining                                              

I wrote this to another user:
"
 You could try with kernel option CONFIG_X86_PAT turned off. (I'm assuming here, that you had it turned on; it's a child option to MTRR which is in 'Processor features' main menu in eg. 'make nconfig')
 I get random black screens right when luks password is about to be entered(and system seems locked up) because that's when radeon switches from text mode into frame buffer(graphics) mode, and that's when it happens(for me anyway). But sometimes I just keep getting this black screen on startup, in which case, I just pass radeon.modeset=0 to kernel cmdline(through grub) and this way I get past it(because it doesn't change into graphics mode) so that I can recompile kernel with that PAT option off; during this time you don't have KMS so X (eg. startx) won't work.

Cheers,
EmanueL
"

Note You need to log in before you can comment on or make changes to this bug.