Bug 85823 - [byt] Black screen during init phase of KDE desktop after installation and after that early in boot process
Summary: [byt] Black screen during init phase of KDE desktop after installation and af...
Status: CLOSED INVALID
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium major
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-03 21:54 UTC by Freek de Kruijf
Modified: 2017-07-24 22:50 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Attachments
dmesg (114.70 KB, text/plain)
2014-11-04 14:28 UTC, Freek de Kruijf 		no flags Details
Xorg.0.log (28.58 KB, text/plain)
2014-11-04 14:29 UTC, Freek de Kruijf 		no flags Details
dmesg with drm.debug=6 (94.12 KB, text/plain)
2014-11-04 14:52 UTC, Freek de Kruijf 		no flags Details
Xorg.0.log with drm.debug=6 (27.15 KB, text/plain)
2014-11-04 14:54 UTC, Freek de Kruijf 		no flags Details
View All

Description Freek de Kruijf 2014-11-03 21:54:28 UTC 
I have a new laptop with a N3530 Intel processor with Intel HD Graphics.
After installation of openSUSE Factory using kernel 3.17.1 the system reaches the log in screen of KDE after the first boot. Entering the username and password gets the splash screen of KDE. But right after the appearance of the picture of the hard disc, the screen turns black. Rebooting the system in the normal mode gives early in the boot process also a black screen and the system never reaches the log in screen anymore.
Booting the system in rescue mode makes the system work and I can do whatever needs to be done.
Comment 1 Chris Wilson 2014-11-04 07:53:28 UTC 
Please attach the dmesg (with drm.debug=6 kernel command line option preferrably) and the Xorg.0.log from the failed bootup.
Comment 2 Freek de Kruijf 2014-11-04 13:01:18 UTC 
Just started the laptop again and by chance without the power plugged in. The system works normaly and I could log in into KDE getting the expected desktop. However right after plugging in the power the screen turned black and nothing seems to work. Unplugging the power however brings back the desktop and I can work on it. So it does not seem te be related to Xorg, but to something related to the power.
Do you still need the output of dmesg?
Comment 3 Chris Wilson 2014-11-04 13:06:38 UTC 
Yes, I still need the dmesg and Xorg.0.log to see if that is expected behaviour for the requests being sent by userspace.
Comment 4 Freek de Kruijf 2014-11-04 14:27:53 UTC 
Just found out that clicking on the battery icon in the system panel gives me the opportunity to disable power control. After that I can plug in the power with no ill effects.
Send you the current versions of dmesg and Xorg.0.log. The one with the kernel option will be send asap.
Comment 5 Freek de Kruijf 2014-11-04 14:28:33 UTC 
Created attachment 108892 [details]
dmesg
Comment 6 Freek de Kruijf 2014-11-04 14:29:08 UTC 
Created attachment 108893 [details]
Xorg.0.log
Comment 7 Freek de Kruijf 2014-11-04 14:52:17 UTC 
Created attachment 108895 [details]
dmesg with drm.debug=6

I updated the system between the two versions of the files to the official openSUSE 13.2 release with some additonal repositories.
I booted not on battery and now I have a black screen and unplugging the power does not help.
Comment 8 Freek de Kruijf 2014-11-04 14:54:19 UTC 
Created attachment 108899 [details]
Xorg.0.log with drm.debug=6

Same comment as with dmesg with drm.debug=6
Comment 9 Freek de Kruijf 2014-11-04 22:48:11 UTC 
Still new surprises. Now I can't start up the system and get a log in screen of KDE anymore when running on battery. Experimenting with the kernel parameters that are used when booting in Rescue mode, I found that I only need "nomodeset" on the boot command line to get a log in screen for KDE. When using that the system is behaving predictable, no surprises anymore.
Comment 10 Chris Wilson 2014-11-05 07:45:16 UTC 
Nothing appears wrong in the logs.
Comment 11 Daniel Vetter 2014-11-25 10:01:20 UTC 
Hm, might be pps fallout. Can you please retest with latest drm-intel-nightly branch from http://cgit.freedesktop.org/drm-intel

That branch has a _lot_ of byt fixes.
Comment 12 Jani Nikula 2015-01-29 15:00:21 UTC 
(In reply to Daniel Vetter from comment #11)
> Hm, might be pps fallout. Can you please retest with latest
> drm-intel-nightly branch from http://cgit.freedesktop.org/drm-intel
> 
> That branch has a _lot_ of byt fixes.

Ping for retesting.
Comment 13 Freek de Kruijf 2015-01-29 23:04:17 UTC 
I asked openSUSE for assistance. See https://bugzilla.opensuse.org/show_bug.cgi?id=899879
Comment 14 Jesse Barnes 2015-04-02 16:39:28 UTC 
Hoping this is fixed, but it looks like there hasn't been much activity on the opensuse bug either...  Best bet would be to re-test with a drm-intel-nightly kernel (hopefully someone in opensuse is building those to make it easy), if the issue still occurs, please re-open.

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.