http://bugzilla.opensuse.org/show_bug.cgi?id=899879 Freek de Kruijf changed: What |Removed |Added ---------------------------------------------------------------------------- Version|13.2 Beta 1 |201410* --- Comment #2 from Freek de Kruijf --- Found an article on an updated driver from Intel on https://01.org/linuxgraphics/downloads/2014/2014q2-intel-graphics-stack-rele... for this processor and graphics. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 --- Comment #3 from Stefan Dirsch --- Could well be a driver issue. I suggest to verify with a simpler desktop like xfce or even twm. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 --- Comment #5 from Freek de Kruijf --- I wrote the above while using lokalize in Xfce. However after closing down the system and later booting the system, the system hangs. Even pressing the power button shortly does not halt the system. I have to press it long to get at that point. However I can boot the system in rescue mode and I do get a log in screen to enter Xfce. It is not the normal Xfce log in screen. While in the Xfce desktop I started lokalize again and it appears normal. A normal reboot behaves the same as above, but using the rescue mode gives access to the Xfce desktop. In rescue mode I used the following command to get some info on the system. # lspci -nnk | grep -A3 VGA 00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display [8086:0f31] (rev 0e) Subsystem: Acer Incorporated [ALI] Device [1025:0905] Kernel modules: i915 00:13.0 SATA controller [0106]: Intel Corporation Device [8086:0f23] (rev 0e) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 Freek de Kruijf changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Freek de Kruijf --- Now I am using kernel-desktop-3.16.4-9.1.g7a8842b and all is well. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 Stefan Dirsch changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium Status|REOPENED |CONFIRMED Component|Installation |X.Org Assignee|kde-maintainers@suse.de |xorg-maintainer-bugs@forge. | |provo.novell.com QA Contact|jsrain@suse.com |xorg-maintainer-bugs@forge. | |provo.novell.com -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 --- Comment #10 from Freek de Kruijf --- I received an answer on the upstream bug report, see Comment 9. There is a request to test the mentioned fixes. However I do not have the knowledge to test this. Can you guide me or indicate that these fixes are implemented in 13.2 GM and/or Tumbleweed? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 --- Comment #12 from Stefan Dirsch --- Sorry, building a commplete kernel and provide it as packages (as you would like it) isn't a trivial task. But testing with current kernel-of-the-day RPMs might already help. If required fixes landed upstream already. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 http://bugzilla.opensuse.org/show_bug.cgi?id=899879#c23 Freek de Kruijf changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX |--- --- Comment #23 from Freek de Kruijf --- (In reply to Egbert Eich from comment #22)

(In reply to Freek de Kruijf from comment #21)

...

kernel-default-4.3.0-1.1

I did an update today to kernel-default-4.5.0-1.1

All fixes should be in there.

...

You mentioned two things, I only see one thing to test. More details::

1. remove any 'quiet' and 'splash=silent' from the kernel command line to get rid of plymouth - *don't* include 'nomodeset'! - does this freeze?

I did this. It is not so much freeze. I get a black screen and whatever button I press, also <Ctrl><Alt><Backspace><Backspace> , the screen stays black. I am able to log into the system via ssh and everything seems to work, except apparently the X server. Also tried "systemctl restart display-manager.service". Result nothing happens.

2. when you boot with 'nomodeset', (all other options in place), log into the system as root - either remotely or on a text console - and run 'modprobe i915 modeset=1'. Does this freeze up?

Nothing happens.

Does any of the two give you a usable system?

No. Leap 42.1 still does not need the nomodeset. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 Egbert Eich changed: What |Removed |Added ---------------------------------------------------------------------------- Version|201410* |Current -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 http://bugzilla.opensuse.org/show_bug.cgi?id=899879#c26 --- Comment #26 from Freek de Kruijf --- After my previous start of the system with nomodeset removed and also quiet and splash=silent removed. I started the system without changing the boot line. Now I got in this file at the end: [ 40.243] (II) LoadModule: "intel" [ 40.243] (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so [ 40.243] (II) Module intel: vendor="X.Org Foundation" [ 40.243] compiled for 1.18.1, module version = 2.99.917 [ 40.243] Module class: X.Org Video Driver [ 40.243] ABI class: X.Org Video Driver, version 20.0 [ 40.243] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45, 4 Series, G45/G43, Q45/Q43, G41, B43 [ 40.244] (II) intel: Driver for Intel(R) HD Graphics: 2000-6000 [ 40.244] (II) intel: Driver for Intel(R) Iris(TM) Graphics: 5100, 6100 [ 40.244] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics: 5200, 6200, P6300 [ 40.256] (EE) No devices detected. [ 40.256] (EE) Fatal server error: [ 40.256] (EE) no screens found(EE) [ 40.256] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 40.256] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 40.256] (EE) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 http://bugzilla.opensuse.org/show_bug.cgi?id=899879#c28 Egbert Eich changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(freek@opensuse.or | |g) --- Comment #28 from Egbert Eich --- (In reply to Freek de Kruijf from comment #25)

(In reply to Egbert Eich from comment #24)

...

Please try the driver from:

http://download.opensuse.org/repositories/home:/eeich:/Test:/Intel/ openSUSE_Tumbleweed/

I got a huge file /var/log/Xorg.0.log which is still growing fast. AFAIK there are no lines with [EE] in it. Do you need this file?

Do you still get a black screen with KDE? Yes, I've enabled full debugging output for this test driver. It is just for testing. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 http://bugzilla.opensuse.org/show_bug.cgi?id=899879#c30 --- Comment #30 from Egbert Eich --- (In reply to Freek de Kruijf from comment #29)

(In reply to Egbert Eich from comment #28)

...

Do you still get a black screen with KDE?

Yes. But it is not so much with KDE. During the boot process - the messages are too fast to see after what message - the screen turns black and nothing appears on the screen any more. I tried all kinds of keys and key combinations, but the screen stays black.

I can inspect the log files only by accessing via ssh.

I also tried "systemctl restart display-manager.service", but that did not help either.

Ok, please disable the boot splash. Add plymouth.enable=0 to the kernel command line and get rid of the 'splash=silent quiet' options. Also boot init the multi-user mode instead of X by adding a '3' to the command line. See if this gives you a black screen again. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 http://bugzilla.opensuse.org/show_bug.cgi?id=899879#c31 Freek de Kruijf changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(freek@opensuse.or | |g) | --- Comment #31 from Freek de Kruijf --- I reverted to xf86-video-intel from the main repository, but now by using nomodeset does not give me the login screen of KDE anymore. (EE) in Xorg.0.log file. From the discussion about i915 I tried the situation to uncomment certain lines in 50-device.conf, 50-screen.conf and 50-monitor.conf. But that did not prevent the (EE) about a missing device and a missing screen. I found out that although the screen is black, I still have ssdm running, so I tried to enter the password that normally needs to be entered. Via ssh I saw I have a running KDE desktop; only the screen is black. When pressing <Ctrl>+<Alt>+<Backspace>, releasing <Backspace> and pressing it again, the KDE session is ended. Again entering the password starts again a session. So the current situation is, old xf86-video-intel and changed files as above: booting without nomodeset: gives a blackscreen, but I can start an unusable KDE session by entering blind the password. booting with nomodeset: gives me a screen with a line mode login prompt. The process ssdm dumped core. How can I get a working Tumbleweed again. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 http://bugzilla.opensuse.org/show_bug.cgi?id=899879#c33 Freek de Kruijf changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(freek@opensuse.or | |g) | --- Comment #33 from Freek de Kruijf --- (In reply to Egbert Eich from comment #30)

Ok, please disable the boot splash. Add plymouth.enable=0 to the kernel command line and get rid of the 'splash=silent quiet' options. Also boot init the multi-user mode instead of X by adding a '3' to the command line. See if this gives you a black screen again.

Both with the old and the new xf86-video-intel, doing the above ends in a black screen. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 http://bugzilla.opensuse.org/show_bug.cgi?id=899879#c35 --- Comment #35 from Freek de Kruijf --- (In reply to Egbert Eich from comment #34)

This means that you cannot get a text console either. Since you can access the system from remote, can you set the 'nomodeset' boot option boot, log in remotey and simply run: 'modprobe i915 modeset=1'? Does this give you a black screen as well?

I have to add, I've got several machines with the same Baytrail GPU here and haven't seen this issue on any of them.

When I start with nomodeset on the boot line I now end with a text console, previously I got the sddm log in screen, so I can log in and give the above command, also via ssh. In both cases nothing visual happens. I still have a text console. This is the output of journalctl -b -u display-manager: -- Logs begin at do 2015-01-22 18:05:59 CET, end at wo 2016-03-23 16:39:42 CET. -- mrt 23 16:34:05 ltfctum.beelaertsict.nl systemd[1]: Starting X Display Manager... mrt 23 16:34:05 ltfctum.beelaertsict.nl display-manager[1227]: /etc/vconsole.conf available mrt 23 16:34:05 ltfctum.beelaertsict.nl display-manager[1227]: KEYMAP: us-acentos mrt 23 16:34:05 ltfctum.beelaertsict.nl display-manager[1227]: Command: localectl set-keymap us-acentos mrt 23 16:34:05 ltfctum.beelaertsict.nl display-manager[1227]: I: Using systemd /usr/share/systemd/kbd-model-map mapping mrt 23 16:34:07 ltfctum.beelaertsict.nl display-manager[1227]: error: unexpectedly disconnected from boot status daemon mrt 23 16:34:08 ltfctum.beelaertsict.nl systemd[1]: Started X Display Manager. mrt 23 16:34:10 ltfctum.beelaertsict.nl systemd[1]: display-manager.service: Main process exited, code=dumped, status=11/SEGV mrt 23 16:34:10 ltfctum.beelaertsict.nl systemd[1]: display-manager.service: Unit entered failed state. mrt 23 16:34:10 ltfctum.beelaertsict.nl systemd[1]: display-manager.service: Failed with result 'core-dump'. mrt 23 16:34:10 ltfctum.beelaertsict.nl sddm-helper[1598]: [PAM] Starting... mrt 23 16:34:10 ltfctum.beelaertsict.nl sddm-helper[1598]: [PAM] Authenticating... mrt 23 16:34:10 ltfctum.beelaertsict.nl sddm-helper[1598]: [PAM] returning. mrt 23 16:34:10 ltfctum.beelaertsict.nl sddm-helper[1598]: Received a wrong opcode instead of AUTHENTICATED: 0 mrt 23 16:34:11 ltfctum.beelaertsict.nl systemd-coredump[1600]: Process 1470 (sddm) of user 0 dumped core. mrt 23 16:34:12 ltfctum.beelaertsict.nl display-manager[1227]: Starting service sddm..done mrt 23 16:34:12 ltfctum.beelaertsict.nl display-manager[1227]: /usr/bin/xauth: (stdin):1: bad "remove" command line mrt 23 16:34:12 ltfctum.beelaertsict.nl display-manager[1227]: /usr/bin/xauth: (stdin):2: bad "add" command line mrt 23 16:34:12 ltfctum.beelaertsict.nl display-manager[1227]: /usr/bin/xauth: (stdin):1: bad "remove" command line mrt 23 16:34:12 ltfctum.beelaertsict.nl display-manager[1227]: /usr/bin/xauth: (stdin):2: bad "add" command line mrt 23 16:34:12 ltfctum.beelaertsict.nl display-manager[1227]: /usr/bin/xauth: (stdin):1: bad "remove" command line mrt 23 16:34:12 ltfctum.beelaertsict.nl display-manager[1227]: /usr/bin/xauth: (stdin):2: bad "add" command line mrt 23 16:34:12 ltfctum.beelaertsict.nl display-manager[1601]: ..done -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 http://bugzilla.opensuse.org/show_bug.cgi?id=899879#c37 --- Comment #37 from Freek de Kruijf --- (In reply to Egbert Eich from comment #36)

...

When I start with nomodeset on the boot line I now end with a text console, previously I got the sddm log in screen, so I can log in and give the above command, also via ssh. In both cases nothing visual happens. I still have a text console.

Again, you didn't answer my question - but for the nomodeset case, could you please provide the output of: 'cat /dev/fb'?

When I wrote I give the above command. this is the command "modprobe i915 modeset=1", so I did answer your question, which is nothing appears to happen after giving that command. So I do not get a black screen. The output of "cat /dev/fb" is: cat: /dev/fb: No such file or directory There is a /dev/fb0, but the output gives question marks on an oval black background. cat /dev/fb0 | wc -c gives: 4227072 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 http://bugzilla.opensuse.org/show_bug.cgi?id=899879#c39 Freek de Kruijf changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(freek@opensuse.or | |g) | --- Comment #39 from Freek de Kruijf --- (In reply to Egbert Eich from comment #38)

Sorry, I meant to say 'cat /proc/fb'. What does this say? Also, please provide the full Xserver log file: /var/log/Xorg.0.log

ltfctum:~ # cat /proc/fb 0 inteldrmfb When using nomodeset it is: 0 EFI VGA The gziped file is attached. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 http://bugzilla.opensuse.org/show_bug.cgi?id=899879#c41 Egbert Eich changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(freek@opensuse.or | |g) --- Comment #41 from Egbert Eich --- (In reply to Freek de Kruijf from comment #40)

Created attachment 670370 [details] /var/log/Xorg.0.log gziped

This was generated for KMS not for the case with 'nomodeset'. Can you get a log file for nomodeset as well, please? This is so we can get the minimal system back to work: nomodeset with fbdev driver. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 http://bugzilla.opensuse.org/show_bug.cgi?id=899879#c43 --- Comment #43 from Egbert Eich --- It looks like you have configured Intel in /etc/X11/xorg.conf.d/50-device.conf or similar. This way, the auto-detection with fallbacks is not being used. The Intel driver itself requires KMS and thus does not work with 'nomodeset'. As for the KMS with Intel: it seems like you are not even able to run the system in console mode (without X). To really make sure that this is the case, can you move the Xserver binary away (mv /usr/bin/Xorg /usr/bin/Xorg.orig) and reboot *without* nomodeset? If you still get a black screen and can't get to the text console (although you can log in from remote) there is some serious trouble. This should be reported to Intel on bugs.freedesktop.org. If you want, I can help you with this. There isn't much I can do as I don't have access to your system - all Baytrail systems available to me work flawlessly. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 http://bugzilla.opensuse.org/show_bug.cgi?id=899879#c45 Freek de Kruijf changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(freek@opensuse.or | |g) | --- Comment #45 from Freek de Kruijf --- (In reply to Egbert Eich from comment #44) In comment #31 I mentioned to have changed 3 files in /etc/X11/xorg.conf.d/ reverting these changes has given me back the previous behaviour of Tumbleweed. Many thanks for the suggestion in comment #43, which put me on the right track.

In addition to what I've suggested in comment #43, you may want to get the openSUSE KOTD: http://download.opensuse.org/repositories/Kernel:/HEAD/standard and install the 'vanilla' version. If this also gives you a black screen, we need to open a ticket on freedesktop.org.

I tried this, however this is on an EFI system and the vanilla kernel apparently has not been properly signed, so I can't start the system with that kernel. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 http://bugzilla.opensuse.org/show_bug.cgi?id=899879#c47 Egbert Eich changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(freek@opensuse.or | |g) --- Comment #47 from Egbert Eich --- Is there a way to disable secure boot in your BIOS? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 http://bugzilla.opensuse.org/show_bug.cgi?id=899879#c49 Freek de Kruijf changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(freek@opensuse.or | |g) | --- Comment #49 from Freek de Kruijf --- (In reply to Egbert Eich from comment #48)

Further question: Originally you reported that the screen turns black only when you log into KDE. XFCE worked for you - even without 'nomodeset'. If I understand your recent reports correctly this has changed and now you get a black screen even in text mode as soon as you omit 'nomodeset'. Is this correct?

Right after installation from the USB with the distribution image I could get a little further, see comment #1. After a few reboots the screen turns black during the boot process. Never got a log in screen again without nomodeset. If you think this is important, I can repeat the installation from scratch, but I will ruin my Tumbleweed system, although I will keep the /home partition. Tumbleweed is not the main system on my laptop. 13.2 still is, and I have Leap 42.1 also. Leap 42.1 does not need the nomodeset on that system, 13.2 still does. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 http://bugzilla.opensuse.org/show_bug.cgi?id=899879#c51 Egbert Eich changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(freek@opensuse.or | |g) --- Comment #51 from Egbert Eich --- (In reply to Freek de Kruijf from comment #49)

(In reply to Egbert Eich from comment #48)

...

Further question: Originally you reported that the screen turns black only when you log into KDE. XFCE worked for you - even without 'nomodeset'. If I understand your recent reports correctly this has changed and now you get a black screen even in text mode as soon as you omit 'nomodeset'. Is this correct?

Right after installation from the USB with the distribution image I could get a little further, see comment #1. After a few reboots the screen turns

This is why I've asked. Initially (with a different kernel of course) you were at least able to log in and everything seemed to be fine. Since then things turned worse.

black during the boot process. Never got a log in screen again without nomodeset. If you think this is important, I can repeat the installation from scratch, but I will ruin my Tumbleweed system, although I will keep the /home partition. Tumbleweed is not the main system on my laptop. 13.2 still is, and I have Leap 42.1 also. Leap 42.1 does not need the nomodeset on that system, 13.2 still does.

This reminds me of another ticket that's still open - that one however is not about Intel but about NVIDIA graphics. The patterns are similar, though. I'm starting to wonder if systemd is not playing some tricks on us - systemd is rather intrusive and tries to manage about every aspect of the system. I was thinking about backlight control for instance: Could you add try and add 'systemd.restore_state=0' to the kernel command line? Alternatively, try to move away '/usr/lib/systemd/systemd-backlight'. Another thing you could try is to connect an external display and see if this behaves in the same way. If none of this gets you any further, could you please get me the output of: 'ls /sys/class/drm'. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 http://bugzilla.opensuse.org/show_bug.cgi?id=899879#c53 Egbert Eich changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(freek@opensuse.or | |g) --- Comment #53 from Egbert Eich --- (In reply to Freek de Kruijf from comment #52)

I removed nomodeset from the command line and added systemd.restore_state=0 . This gives me the the desired log in screen, however on VT8 not VT7. After entering username and pasword the screen becomes black again. I hear the sound played to indicate the KDE session has started. Also <Ctrl>+<Alt>+<F1> does not give me visible VT1. Blindly logging in and shutdown -P now powers down the laptop.

Ok, what was the difference to not having 'systemd.restore_state=0'? IMHO, you were not able to see the login screen, is this correct? What happens if you pick Xfce as desktop, now? Can you still log in there and see something?

This may take another day.

What you could try quickly - create a test user and see if you can log into this newly created test account using KDE.

...

If none of this gets you any further, could you please get me the output of: 'ls /sys/class/drm'.

# ls -l /sys/class/drm totaal 0 lrwxrwxrwx 1 root root 0 29 mrt 16:24 card0 -> ../../devices/pci0000:00/0000:00:02.0/drm/card0 lrwxrwxrwx 1 root root 0 29 mrt 16:24 card0-DP-1 -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-1 lrwxrwxrwx 1 root root 0 29 mrt 16:24 card0-eDP-1 -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1 [..] Thanks!

-- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 http://bugzilla.opensuse.org/show_bug.cgi?id=899879#c55 Egbert Eich changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(freek@opensuse.or | |g) --- Comment #55 from Egbert Eich --- (In reply to Freek de Kruijf from comment #54)

Did that and I can start a Plasma5 session, end that session and start the session again. I still have file backlight moved away. However when I start a session with my username the screen turns black and also going to VT1 shows a black screen. So something in my user configuration causes the black screen?

Yes, Plasma5 sessions store the last known settings and restore them on the next login - even if they were bogus. I'm not sure which settings are wrong: it could be backlight, but Baytrail also has issues with enabling planes. It could be, that the latter is an issue as well. I'd like to know whether the Plasma5 session uses a different mode than the login screen. Please do the following (this assumes you use sddm as login manager): - log in as root from remote. - when the login manager is active (sddm) do from remote: $ xauth=$(p=$(ps -C sddm-greeter -o pid=) && p=${p# } && cat /proc/$p/environ | tr '\0' '\n' | grep XAUTHORITY) $ export $xauth # this is no mistake! leave the '$' in place! $ export DISPLAY=:0 $ xrandr -q > log.file - Now log into the Plasma5 session (with the black screen) - From remote run: $ xrandr -q >> log.file - Get me log.file In log.file you should see 2 outputs of xrandr. Check if the currently active modes listed in each one differ (marked by '*').

Do you still need the test with an extra monitor attached?

We may get by without it. Let's see. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 http://bugzilla.opensuse.org/show_bug.cgi?id=899879#c57 Freek de Kruijf changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(freek@opensuse.or | |g) | --- Comment #57 from Freek de Kruijf --- (In reply to Egbert Eich from comment #56)

What would also work - and it would be easier to obtain - is an Xserver log file recovered *after* Plasma5 went black. You'd have to make sure, it hasn't been overwritten by the next Xserver, yet, ie. you should recover it while the server that went 'black' is still running (*). I'm looking for any lines containing 'switch to mode'.

(*) If you have rebooted and a new server has started, you should be able to find the previous log in /var/log/Xorg.0.log.old (please make sure that it is the right one by checking the time stamp of the file).

Regarding backlight:

I will attach the requested file. Got it by still having backlight moved away, starting without nomodeset, but with systemd.restore_status=0, as can be seen from the boot line at the beginning of the Xorg.0.log file. After that I started the Plasma5 session and got a black screen. I went to VT1 and entered blind root and the password and a shutdown command. The system started again, but I booted another system and got the file from the Tumbleweed partition. Please let me know what I should do next. Currently I do not have remote access to this system, only tonight. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 http://bugzilla.opensuse.org/show_bug.cgi?id=899879#c59 Egbert Eich changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(freek@opensuse.or | |g) --- Comment #59 from Egbert Eich --- Ok, in the above log file I only find a singe entry with 'switch to mode'. This is where the native mode of the display (1366x768) is set initially. So I don't think this is the problem. However, what I see in the log file is an issue with dbus. Dbus could br the culprit screwing up your session. Now we should focus on the backlight when you have to opportunity to log in from remote. See cpmment #56. Also you may want to check DPMS: . When you have a chance for a remote login, could you check the status of /sys/class/drm/card0-eDP-1/dpms when the Plasma5 session is blank, as well? Ie. do 'cat /sys/class/drm/card0-eDP-1/dpms' and check what is read. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 http://bugzilla.opensuse.org/show_bug.cgi?id=899879#c61 --- Comment #61 from Egbert Eich --- (In reply to Freek de Kruijf from comment #60)

Before starting the system I restored systemd-backlight.

That's fine.

# ls -l

[..]

...

The structure of these subdirectories is pretty identical. For you the files brightness and max_brightness are relevant. - Get 'max_brighness':

is 7812

Can you get the value from 'brighness' right after a boot?

...

$ cat max_brightness - Set the brightness value: (try 0, the value of max_brightness and values between) $ echo <value> > brightness See if this changes your settings and makes the screen light up again.

echo 0 -n > brightness

This is wrong: if you want to specify the '-n' option it needs to be at the beginning of the command line.

did not change anything nor did entering 3000 and 7812.

This looks to be not off, so on.

For the above I only removed nomodeset from the command line. Should I add systemd.restore_state=0 and repeat?

This just prevents the previously saved value to be restored. Can you try the following? If you reboot after your Plasma5 session went black, and don't specify this option on the next reboot, your will get a black login screen after the reboot. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 http://bugzilla.opensuse.org/show_bug.cgi?id=899879#c63 --- Comment #63 from Freek de Kruijf --- (In reply to Egbert Eich from comment #61)

Can you get the value from 'brighness' right after a boot?

It is 4687, max_brightness is 7812.

This is wrong: if you want to specify the '-n' option it needs to be at the beginning of the command line.

Did not seem to be of any harm.

...

For the above I only removed nomodeset from the command line. Should I add systemd.restore_state=0 and repeat?

This just prevents the previously saved value to be restored.

Can you try the following? If you reboot after your Plasma5 session went black, and don't specify this option on the next reboot, your will get a black login screen after the reboot.

Yesterday with your newest xf86-video-intel module, version 2.99.917.590_g094924f-168.1, and nomodeset removed from the boot command, I did not get a black screen any more. However it causes a lot of output to /var/log/Xorg.0.log. This file does not contain a failing dbus message any more. At this moment, same as above, I again hear the sound of an active Plasma5 session, but the screen is black; brightness is at its maximum. I tried different values for brightness and found that 0 gives black, maximum gives black, close to maximum 7500 gives a dim screen, 4687 gives a bright screen. Seems we have found culprit. I will try the xf86-video-intel from the main repository. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 http://bugzilla.opensuse.org/show_bug.cgi?id=899879#c65 --- Comment #65 from Egbert Eich --- If you want to try a newer user space driver without getting all the annoying messages (which make things really slow), you can use a different repo I've created: http://download.opensuse.org/repositories/home:/eeich:/Test:/Intel-NoDebug/o... But at least we got somewhere and did make some progress: we did find that the backlight is the culprit. Fist thing I need from you is 1. What you get when you do: systemctl list-units | grep backlight 2. What you get by doing: ls /var/lib/systemd/backlight/ 3. Determine if you get a somewhat linear behaviour between 0 and 4687. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 http://bugzilla.opensuse.org/show_bug.cgi?id=899879#c67 Freek de Kruijf changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(freek@opensuse.or | |g) | --- Comment #67 from Freek de Kruijf --- (In reply to Egbert Eich from comment #65)

If you want to try a newer user space driver without getting all the annoying messages (which make things really slow), you can use a different repo I've created: http://download.opensuse.org/repositories/home:/eeich:/Test:/Intel-NoDebug/ openSUSE_Tumbleweed/

But at least we got somewhere and did make some progress: we did find that the backlight is the culprit. Fist thing I need from you is 1. What you get when you do: systemctl list-units | grep backlight

# systemctl list-units | grep backlight sys-devices-pci0000:00-0000:00:02.0-drm-card0-card0\x2deDP\x2d1-intel_backlight.device loaded active plugged /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight systemd-backlight@backlight:intel_backlight.service loaded active exited Load/Save Screen Backlight Brightness of backlight:intel_backlight system-systemd\x2dbacklight.slice loaded active active system-systemd\x2dbacklight.slice

2. What you get by doing: ls /var/lib/systemd/backlight/

# ls /var/lib/systemd/backlight/ pci-0000:00:02.0:backlight:intel_backlight

3. Determine if you get a somewhat linear behaviour between 0 and 4687.

No. 0 is black and even 1 is bright. It looks like values above 4687 make a difference in brightness. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 http://bugzilla.opensuse.org/show_bug.cgi?id=899879#c69 --- Comment #69 from Freek de Kruijf --- (In reply to Egbert Eich from comment #66)

(In reply to Freek de Kruijf from comment #64) [..] I can make a root cron job at boot to set

...

brightness as a workaround, although keeping nomodeset is also workable for me.

I order get all the efforts spent to pay off and to let others for benefit from what we have learned so far, I would like to find a fix for this issue. For this I need more stuff: 1. add drm.debug=0x4 to the kernel command line, reboot and run as root: # dmesg > dmesg.out Please get me the content of 'dmesg.out'.

See attached file dmesg.out.gz

2. run as root: # intel_bios_dumper intel_bios.data get me the output file 'intel_bios.data'

# intel_bios_dumper intel_bios.data Couldn't read graphics card ROM: Input/output error -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 Egbert Eich changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(freek@opensuse.or | |g) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 http://bugzilla.opensuse.org/show_bug.cgi?id=899879#c72 Freek de Kruijf changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(freek@opensuse.or | |g) | --- Comment #72 from Freek de Kruijf --- Created attachment 671432 --> http://bugzilla.opensuse.org/attachment.cgi?id=671432&action=edit dmesg.out.gz -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=899879 Egbert Eich changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|[Intel, BYT] Black screen |[Intel, BYT, backlight] |during init phase of KDE |Black screen during init |desktop after installation |phase of KDE desktop after | |installation -- You are receiving this mail because: You are on the CC list for the bug.