trouble with xorg-server-1.18.3-i586-3 update on Slackware-14.2

[Sylvain Robitaille]

Has anyone else had trouble with the latest update to Xorg on
Slackware-14.2, or have I done something wrong (or not done something
right)??? This system has been running since September 2016, and
getting regular updates, on an at least monthly basis (typically I
keep up better than that).

My system was last updated on August 17, when the following packages
were updated:

-rw-r--r-- 1 root system 7672 Aug 17 16:12 xorg-server-1.18.3-i586-3_slack14.2
-rw-r--r-- 1 root system 92817 Aug 17 16:15 mozilla-thunderbird-52.3.0-i586-1_slack14.2
-rw-r--r-- 1 root system 45518 Aug 17 16:15 mercurial-4.3.1-i586-1_slack14.2
-rw-r--r-- 1 root system 963 Aug 17 16:15 xorg-server-xnest-1.18.3-i586-3_slack14.2
-rw-r--r-- 1 root system 61438 Aug 17 16:16 git-2.14.1-i586-1_slack14.2
-rw-r--r-- 1 root system 14028 Aug 17 16:17 subversion-1.9.7-i586-1_slack14.2
-rw-r--r-- 1 root system 742 Aug 17 16:18 xorg-server-xephyr-1.18.3-i586-3_slack14.2
-rw-r--r-- 1 root system 13865 Aug 17 16:18 libsoup-2.52.2-i586-3_slack14.2
-rw-r--r-- 1 root system 1057 Aug 17 16:19 xorg-server-xvfb-1.18.3-i586-3_slack14.2

However, the X server was *not* restarted until this morning, due
simply to my requiring that I maintain context on this system for as
long as possible. The system's default runlevel is "4", so it boots
into X, and that works fine, except now I can't login: I enter username
and password, and after blinking a couple of times, the system returns
to the login prompt (the KDM login dialog box, to be precise).

Syslog tells me simply:

Aug 28 10:12:01 charlotte kdm[1219]: X server for display :0 terminated unexpectedly

So I told KDM to log me into a text console, from which I attempt to
start X manually. It segfaulted:

: charlotte[syl] ~; startx


X.Org X Server 1.18.3
Release Date: 2016-04-04
X Protocol Version 11, Revision 0
Build Operating System: Slackware 14.2 Slackware Linux Project
Current Operating System: Linux charlotte 4.4.75-smp #1 SMP Fri Jun 30 04:10:30 CDT 2017 i686
Kernel command line: BOOT_IMAGE=generic ro root=801 vt.default_utf8=0
Build Date: 15 August 2017 04:58:43PM

Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Mon Aug 28 11:11:11 2017
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
Aug 28 11:11:11 charlotte acpid: client connected from 2838[0:100]
(EE)
(EE) Backtrace:
(EE) 0: /usr/libexec/Xorg (xorg_backtrace+0x88) [0x8223f42]
(EE) 1: /usr/libexec/Xorg (0x8048000+0x1e161f) [0x822961f]
(EE) 2: linux-gate.so.1 (__kernel_rt_sigreturn+0x0) [0xb7798ba0]
(EE) 3: /usr/lib/xorg/modules/libglamoregl.so (0xb6d7f000+0x2973a) [0xb6da873a]
(EE) 4: /usr/lib/xorg/modules/libglamoregl.so (0xb6d7f000+0x2a05f) [0xb6da905f]
(EE) 5: /usr/lib/xorg/modules/libglamoregl.so (glamor_create_pixmap+0x1c6) [0xb6d8603d]
(EE) 6: /usr/libexec/Xorg (0x8048000+0x2aa5f) [0x8072a5f]
(EE) 7: /usr/libexec/Xorg (0x8048000+0x2854d) [0x807054d]
(EE) 8: /usr/libexec/Xorg (0x8048000+0x35328) [0x807d328]
(EE) 9: /usr/libexec/Xorg (0x8048000+0x1ad08) [0x8062d08]
(EE) 10: /lib/libc.so.6 (__libc_start_main+0x107) [0xb715a697]
(EE) 11: /usr/libexec/Xorg (0x8048000+0x1abc1) [0x8062bc1]
(EE)
(EE) Segmentation fault at address 0x9b204200
(EE)
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE)
(EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
(EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
(EE)
(II) AIGLX: Suspending AIGLX clients for VT switch
(EE) Server terminated with error (1). Closing log file.
xinit: connection to X server lost

waiting for X server to shut down

==============================================================

This is Linux 4.4.75-smp (tty1),
A computer system at Concordia University in Montreal, Canada.
Unauthorized use is strictly prohibited.

All access to this system is closely monitored and is subject
to the Concordia Computing Facilities Acceptable Use Policy.

==============================================================

(hrmmm... there's obviously an error in my issue file, but I won't
worry about that right now ...)

The /var/log/Xorg.0.log mostly is unenlightening in this case (I could
post its contents, but it's 570 lines, so I'll do so only if it turns
out to be truly interesting), except it does have the following ...

[ 3640.674] (II) LoadModule: "fbdev"
[ 3640.674] (WW) Warning, couldn't open module fbdev
[ 3640.674] (II) UnloadModule: "fbdev"
[ 3640.674] (II) Unloading fbdev
[ 3640.674] (EE) Failed to load module "fbdev" (module does not exist, 0)

... and repeated occurances of this:

[ 3640.676] (II) [drm] nouveau interface version: 1.3.1
[ 3640.676] (EE) Unknown chipset: NV117

The graphics device in question is:

: charlotte[root] /home/syl; lspci -v -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation GM107GL [Quadro K620] (rev a2) (prog-if 00 [VGA controller])
Subsystem: NVIDIA Corporation GM107GL [Quadro K620]
Flags: bus master, fast devsel, latency 0, IRQ 30, NUMA node 0
Memory at f6000000 (32-bit, non-prefetchable) [size=16M]
Memory at e0000000 (64-bit, prefetchable) [size=256M]
Memory at f0000000 (64-bit, prefetchable) [size=32M]
I/O ports at e000 [size=128]
Expansion ROM at f7000000 [disabled] [size=512K]
Capabilities: [60] Power Management version 3
Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [78] Express Legacy Endpoint, MSI 00
Capabilities: [100] Virtual Channel
Capabilities: [250] Latency Tolerance Reporting
Capabilities: [258] L1 PM Substates
Capabilities: [128] Power Budgeting <?>
Capabilities: [420] Advanced Error Reporting
Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
Capabilities: [900] #19
Kernel driver in use: nouveau
Kernel modules: nvidiafb, nouveau

Is there something I missed in the update? Do I need to somehow tell
the system to use the nvidiafb driver, or would that be for text mode?
Have others seen this problem? I'm not averse to downgrading X if
necessary, but I'd really like to figure out what's going on here ...

--
----------------------------------------------------------------------
Sylvain Robitaille s...@encs.concordia.ca

Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------

[Sylvain Robitaille]

On 2017-08-28, Sylvain Robitaille wrote:

> Has anyone else had trouble with the latest update to Xorg on
> Slackware-14.2, or have I done something wrong (or not done something

> right)??? ...

Well, I'm reasonably certain that the problem isn't something I did or
didn't do ... I've downgraded back to xorg-server-1.18.3-i586-2 (which
is what was in place before this latest update) and that's working.
What gets me, though, is that I have examined the two patches that
are new for xorg-server-1.18.3-i586-3, and neither appear to me to
be even remotely related to the failure mode I'm seeing.

> ... and repeated occurances of this:
>
> [ 3640.676] (II) [drm] nouveau interface version: 1.3.1
> [ 3640.676] (EE) Unknown chipset: NV117

I'm honestly not sure what to make of it, but I would be
interested in knowing if others run into similar problems
with xorg-server-1.18.3-i586-3. I would try applying each patch
individually to xorg-server-1.18.3-i586-2, to try to narrow this down,
but building X is rather non-trivial, I think, even with Slackware's
SlackBuild script (it occurs to me that I likely really only need
to download all of slackware-14.2/patches/source/xorg-server and
run the SlackBuild script there, but I really should be getting some
work done at some point today ...) I might look at this more closely
another day.

[Henrik Carlqvist]

On Mon, 28 Aug 2017 19:09:16 +0000, Sylvain Robitaille wrote:
> [ 3640.676] (II) [drm] nouveau interface version: 1.3.1
> [ 3640.676] (EE) Unknown chipset: NV117

Could it be that you have installed the evil binary nVidia drivers on
your working installation? If so, upgrading xorg might break things as
the opensource xorg (mesa) OpenGL libraries overwrite your nVidia binary
OpenGL libraries.

The solution might be to reinstall the evil binary nVidia drivers after
upgrading xorg or upgrading the kernel.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc351(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

[Sylvain Robitaille]

On 2017-08-28, Henrik Carlqvist wrote:

> Could it be that you have installed the evil binary nVidia drivers on
> your working installation?

Not on this incarnation of the system in question, no. I have used the
vendor's driver in the past (apparently as recently as 2012), but this
is a newer system and the open-source driver included in Slackware-14.2
was quite sufficient. Besides, if that was the culprit, downgrading
xorg back to xorg-server-1.18.3-i586-2 wouldn't have helped.

[Henrik Carlqvist]

On Tue, 29 Aug 2017 12:56:40 +0000, Sylvain Robitaille wrote:
> Besides, if that was the culprit, downgrading
> xorg back to xorg-server-1.18.3-i586-2 wouldn't have helped.

So what does Xorg.0.log look like on a working system?

Compared to:

> [ 3640.676] (II) [drm] nouveau interface version: 1.3.1
> [ 3640.676] (EE) Unknown chipset: NV117

Is the working system using some other version of nouveau or maybe it is
using the nv driver instead? If the working system is using nv you might
get nv working also with the upgraded packages.

[Sylvain Robitaille]

On 2017-08-29, Henrik Carlqvist wrote:

> So what does Xorg.0.log look like on a working system?

Ironically, same ...

> Compared to:
>> [ 3640.676] (II) [drm] nouveau interface version: 1.3.1
>> [ 3640.676] (EE) Unknown chipset: NV117

The following is from the same system *after* having downgraded back to
xorg-server-1.18.3-i586-2 (with me happily working in an X environment
since having restarted it afterwards):

[ 634.675] (II) LoadModule: "fbdev"
[ 634.677] (WW) Warning, couldn't open module fbdev
[ 634.677] (II) UnloadModule: "fbdev"
[ 634.677] (II) Unloading fbdev
[ 634.677] (EE) Failed to load module "fbdev" (module does not exist, 0)
...
[ 634.678] (II) NOUVEAU driver
[ 634.678] (II) NOUVEAU driver for NVIDIA chipset families :
...
[ 634.680] (II) [drm] nouveau interface version: 1.3.1
[ 634.681] (EE) Unknown chipset: NV117
(repeated 9 more times)

Maybe this was a red herring after all ...

> Is the working system using some other version of nouveau or maybe
> it is using the nv driver instead? If the working system is using
> nv you might get nv working also with the upgraded packages.

Well, I still think it's using nouveau:

: charlotte[syl] ~; glxinfo | grep -iw vendor
server glx vendor string: SGI
client glx vendor string: Mesa Project and SGI
Vendor: nouveau (0x10de)
OpenGL vendor string: nouveau

[Henrik Carlqvist]

On Wed, 30 Aug 2017 20:20:10 +0000, Sylvain Robitaille wrote:
> The following is from the same system *after* having downgraded back to
> xorg-server-1.18.3-i586-2 (with me happily working in an X environment
> since having restarted it afterwards):

> (EE) Unknown chipset: NV117 (repeated 9 more times)
>
> Maybe this was a red herring after all ...

If so, you will need to compare those log files more closely to find
where the new version of xorg fails and the old version succeds.

[Sylvain Robitaille]

On 2017-09-01, Henrik Carlqvist wrote:

>> Maybe this was a red herring after all ...
>
> If so, you will need to compare those log files more closely to
> find where the new version of xorg fails and the old version succeds.

Yes, but unfortunately that isn't worth my time. This is a workstation
on which I'm the only authenticated user, so the Xorg fix simply isn't
urgent for this system ... well hang on ... I *have* both the current
and previous Xorg.0.log files on the system. It isn't *that* hard to
diff them and examine the output. Ok, ignoring the timestamps, which
are not relevant to troubleshooting this, the files are essentially
identical up to where the X server starts (or doesn't):

--- /tmp/Xorg.0.log.old 2017-09-01 10:52:19.619731178 -0400
+++ /tmp/Xorg.0.log 2017-09-01 10:52:13.245669043 -0400
@@ -13,7 +13,7 @@

Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.

-(==) Log file: "/var/log/Xorg.0.log", Time: Mon Aug 28 14:33:54 2017
+(==) Log file: "/var/log/Xorg.0.log", Time: Mon Aug 28 14:34:45 2017

(==) Using system config directory "/usr/share/X11/xorg.conf.d"

(==) No Layout section. Using the first Screen section.
(==) No screen section available. Using defaults.
@@ -540,12 +540,126 @@
(II) config/udev: Adding input device PC Speaker (/dev/input/event10)
(II) No input driver specified, ignoring this device.
(II) This device may have been added with another device file.
-(II) evdev: USB Optical Mouse: Close
-(II) UnloadModule: "evdev"
-(II) evdev: CHICONY HP Basic USB Keyboard: Close
-(II) UnloadModule: "evdev"
-(II) evdev: Power Button: Close
-(II) UnloadModule: "evdev"
-(II) evdev: Power Button: Close
-(II) UnloadModule: "evdev"
-(II) Server terminated successfully (0). Closing log file.
+(II) modeset(0): Allocate new frame buffer 3520x1200 stride
+(II) modeset(0): EDID vendor "DEL", prod id 61506
+(II) modeset(0): Using EDID range info for horizontal sync
+(II) modeset(0): Using EDID range info for vertical refresh
+(II) modeset(0): Printing DDC gathered Modelines:
+(II) modeset(0): Modeline "1680x1050"x0.0 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync (65.3 kHz eP)
+(II) modeset(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e)
+(II) modeset(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz e)
...

[Henrik Carlqvist]

On Fri, 01 Sep 2017 15:07:32 +0000, Sylvain Robitaille wrote:
> @@ -540,12 +540,126 @@
> (II) config/udev: Adding input device PC Speaker
> (/dev/input/event10) (II) No input driver specified, ignoring this
> device. (II) This device may have been added with another device
> file.
> -(II) evdev: USB Optical Mouse: Close -(II) UnloadModule: "evdev"
> -(II) evdev: CHICONY HP Basic USB Keyboard: Close -(II) UnloadModule:
> "evdev"
> -(II) evdev: Power Button: Close
> -(II) UnloadModule: "evdev"
> -(II) evdev: Power Button: Close
> -(II) UnloadModule: "evdev"
> -(II) Server terminated successfully (0). Closing log file.

The above looks like a very normal shutdown of X, about as what whould
happen if the user logs out. Looking more closely to your first post in
this thread that also seems to be what is happening.

At boot, you are using runlevel 4 and kdm is able to start X
successfully. Once you try to login X is aborted just as if you
immediately whould logout again. Then kdm is able to successfully restart
X again.

My guess is that your user has something in the login or X startup
scripts that does not like the new X server. Maybe you would be able to
find some clue in ~/.xsession-errors by loggin in to a text console right
after have being thrown out by X. But that would require that you again
upgrade to the X server that breaks your system for your user.

[Sylvain Robitaille]

On 2017-09-02, Henrik Carlqvist wrote:

> My guess is that your user has something in the login or X startup
> scripts that does not like the new X server.

I hadn't considered that possibility. Though note that the X server is
the same *version* (ie, no new features), just with a couple of patches
applied. I agree it shouldn't be ruled out, but I don't consider it
very likely (my X startup from KDM is really quite straight-forward
and generic; it fails *also* with startup from command-line, as in
"startx", but that setup is years old and doesn't normally get used at
all any more). Also, the same is known to work on a different system,
admittedly with different hardware, after the upgrade of the X server.

> Maybe you would be able to find some clue in ~/.xsession-errors by
> loggin in to a text console right after have being thrown out by
> X. But that would require that you again upgrade to the X server
> that breaks your system for your user.

Yeah ... it's a workstation at work. I'm just not able to spend that
much time troubleshooting when I can simply work around the problem
with the downgrade.

[Ars Ivci]

On Mon, 28 Aug 2017 15:53:30 GMT
Sylvain Robitaille <s...@alcor.concordia.ca> wrote:


> (EE) Backtrace:
> (EE) 0: /usr/libexec/Xorg (xorg_backtrace+0x88) [0x8223f42]
> (EE) 1: /usr/libexec/Xorg (0x8048000+0x1e161f) [0x822961f]
> (EE) 2: linux-gate.so.1 (__kernel_rt_sigreturn+0x0) [0xb7798ba0]
> (EE) 3: /usr/lib/xorg/modules/libglamoregl.so (0xb6d7f000+0x2973a)
> [0xb6da873a] (EE) 4: /usr/lib/xorg/modules/libglamoregl.so
> (0xb6d7f000+0x2a05f) [0xb6da905f] (EE)
> 5: /usr/lib/xorg/modules/libglamoregl.so (glamor_create_pixmap+0x1c6)
> [0xb6d8603d] (EE) 6: /usr/libexec/Xorg (0x8048000+0x2aa5f)

Libglamoregl could be the culprit, it's been reported to misbehave with
some nvidia cards.
t.
--
Those who can make you believe absurdities, can make you commit
atrocities.

[Sylvain Robitaille]

On 2017-09-09, Ars Ivci wrote:

> Libglamoregl could be the culprit, it's been reported to misbehave
> with some nvidia cards.

Definitely worth some consideration, as that does seem to ship within
the xorg-server package:

: charlotte[syl] ~; grep -rlsw libglamoregl /var/log/packages/
/var/log/packages/xorg-server-1.18.3-i586-2