Bug 1100503 - Can't run X after upgrading Mesa
Can't run X after upgrading Mesa
Status: RESOLVED WONTFIX
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: X.Org
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: E-mail List
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-07-07 18:41 UTC by John Ford
Modified: 2018-08-16 21:23 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Journal content (155.79 KB, text/plain)
2018-07-07 18:41 UTC, John Ford
Details
Xorg.0.log (6.45 KB, text/plain)
2018-08-15 18:29 UTC, John Ford
Details

Note You need to log in before you can comment on or make changes to this bug.
Description John Ford 2018-07-07 18:41:33 UTC
Created attachment 776424 [details]
Journal content

Upgrading Mesa using zypper results in the following package changes:

  Mesa                18.0.0-190.1 -> 18.1.2-200.1
  Mesa-32bit          18.0.0-190.1 -> 18.1.2-200.1
  Mesa-dri            18.0.0-190.1 -> 18.1.2-200.1
  Mesa-dri-32bit      18.0.0-190.1 -> 18.1.2-200.1
  Mesa-dri-nouveau    18.0.0-190.1 -> 18.1.2-200.1
  Mesa-gallium        18.0.0-190.1 -> 18.1.2-200.1
  Mesa-gallium-32bit  18.0.0-190.1 -> 18.1.2-200.1
  Mesa-libEGL-devel   18.0.0-190.1 -> 18.1.2-200.1
  Mesa-libEGL1        18.0.0-190.1 -> 18.1.2-200.1
  Mesa-libGL-devel    18.0.0-190.1 -> 18.1.2-200.1
  Mesa-libGL1         18.0.0-190.1 -> 18.1.2-200.1
  Mesa-libGL1-32bit   18.0.0-190.1 -> 18.1.2-200.1


After this, if I log out, I just get a black screen, and my journal fills up with stuff like in the attached file. If I reboot I also just get the black screen.

The computer is a Dell XPS 15 9560.

Output of lspci:

00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (rev 05)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x16) (rev 05)
00:02.0 VGA compatible controller: Intel Corporation Device 591b (rev 04)
00:04.0 Signal processing controller: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem (rev 05)
00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller (rev 31)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-H Thermal subsystem (rev 31)
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-H Serial IO I2C Controller #0 (rev 31)
00:15.1 Signal processing controller: Intel Corporation Sunrise Point-H Serial IO I2C Controller #1 (rev 31)
00:16.0 Communication controller: Intel Corporation Sunrise Point-H CSME HECI #1 (rev 31)
00:17.0 SATA controller: Intel Corporation Sunrise Point-H SATA Controller [AHCI mode] (rev 31)
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #1 (rev f1)
00:1c.1 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #2 (rev f1)
00:1d.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #9 (rev f1)
00:1d.4 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #13 (rev f1)
00:1d.6 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #15 (rev f1)
00:1f.0 ISA bridge: Intel Corporation Sunrise Point-H LPC Controller (rev 31)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-H PMC (rev 31)
00:1f.3 Audio device: Intel Corporation CM238 HD Audio Controller (rev 31)
00:1f.4 SMBus: Intel Corporation Sunrise Point-H SMBus (rev 31)
01:00.0 3D controller: NVIDIA Corporation GP107M [GeForce GTX 1050 Mobile] (rev a1)
02:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)
03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS525A PCI Express Card Reader (rev 01)
04:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961
Comment 1 Stefan Dirsch 2018-07-07 20:25:57 UTC
Appears to be sddm related.

Jul 07 20:09:39 linux-x9tf display-manager[1984]: /usr/bin/xauth: (stdin):1:  bad "remove" command line
Jul 07 20:09:39 linux-x9tf display-manager[1984]: /usr/bin/xauth: (stdin):2:  bad "add" command line

You may want to switch to xdm temporarily via

  update-alternatives --config default-displaymanager

If it works with xdm, let's reassign to KDE component ...
Comment 2 John Ford 2018-07-08 13:12:36 UTC
Still does not work with xdm. I now get the following:

Jul 08 15:03:49 linux-x9tf systemd[1]: Stopped User Manager for UID 1000.
Jul 08 15:03:49 linux-x9tf systemd[1]: Removed slice User Slice of johnfo
Jul 08 15:03:49 linux-x9tf systemd[1]: Created slice system-systemd\x2dcoredump.slice.
Jul 08 15:03:49 linux-x9tf systemd[1]: Started Process Core Dump (PID 9158/UID 0).
Jul 08 15:03:49 linux-x9tf systemd-coredump[9159]: Process 9156 (X) of user 0 dumped core.
Jul 08 15:04:04 linux-x9tf display-manager[9166]: /usr/lib/X11/display-manager: line 144: type: console_vars: not found
Jul 08 15:04:04 linux-x9tf display-manager[9166]: /usr/lib/X11/display-manager: line 144: type: default-displaymanager_vars: not found
Jul 08 15:04:04 linux-x9tf display-manager[9166]: ..done
Comment 3 Stefan Dirsch 2018-07-09 13:54:36 UTC
> Jul 08 15:04:04 linux-x9tf display-manager[9166]: /usr/lib/X11/display-manager: line 144: type: console_vars: not found
> Jul 08 15:04:04 linux-x9tf display-manager[9166]: /usr/lib/X11/display-manager: line 144: type: default-displaymanager_vars: not found

Probably a red herring ...

Please check first if you can start an Xserver manually. As root please run

  X -retro -verbose 7 -logverbose 7

You should see a black and white patter with a X cursor on it, which you can move.

Then kill it again with Ctrl-Alt-BS (Backspace two times in  a row shortly after each other).   And attach /var/log/Xorg.0.log.
Comment 4 Stefan Dirsch 2018-07-19 14:46:38 UTC
Any news on that one?
Comment 5 John Ford 2018-08-15 11:17:16 UTC
Sorry, I'm not sure how to do that. I guess I need to boot without starting X? Or somehow manage till kill X so that it does not automatically restart again?
Comment 6 Stefan Dirsch 2018-08-15 13:04:48 UTC
Yes, you can start without X into runlevel 3.
Comment 7 John Ford 2018-08-15 18:29:29 UTC
Created attachment 779834 [details]
Xorg.0.log

Log generated when running

X -retro -verbose 7 -logverbose 7
Comment 8 John Ford 2018-08-15 18:33:09 UTC
(In reply to Stefan Dirsch from comment #6)
> Yes, you can start without X into runlevel 3.

Starting X just results in a black screen with a little white line in the top left corner (a text cursor?). I can't kill X using Ctrl+Backspace, neither can I change to another VT. This is the same as previously when I have tried to reboot after updating Mesa.

When I press the power button I briefly see the terminal from where I started X, and see that it has segfaulted ("segmentation fault (core dumped)"), but I'm not sure at what point this has happened (right after running the command, or after pressing the power button?)
Comment 9 Stefan Dirsch 2018-08-16 13:49:07 UTC
Hmm. No errors in logfile, but very short.  Nothing about input drivers though. Very strange.  Maybe you can update who TW once more ...
Comment 10 Stefan Dirsch 2018-08-16 13:53:25 UTC
(In reply to Stefan Dirsch from comment #9)
> Hmm. No errors in logfile, but very short.  Nothing about input drivers
> though. Very strange.  Maybe you can update who TW once more ...

Maybe you can update TW once more ...
Comment 11 John Ford 2018-08-16 20:34:28 UTC
(In reply to Stefan Dirsch from comment #10) 
> Maybe you can update TW once more ...

Did not help. Thanks for trying to help, but at this point I'm just going to give up and install some other distro instead, so I won't be able to give any additional info anymore.
Comment 12 Stefan Dirsch 2018-08-16 21:23:19 UTC
Sigh. :-( Anyway, we'll try to make sure Intel Kabylake machines are working on openSUSE Leap and TW.