Bug 251114 - x11/xorg: /usr/local/bin/Xorg Segmentation Fault When Switch Virtual TTY
Summary: x11/xorg: /usr/local/bin/Xorg Segmentation Fault When Switch Virtual TTY
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-x11 (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-11-13 20:49 UTC by John
Modified: 2022-03-11 22:10 UTC (History)
4 users (show)

See Also:
bugzilla: maintainer-feedback? (x11)


Attachments
/var/log/Xorg.0.log of First Occurrence of Bug 20201113-1704+0000-UTC (60.57 KB, text/plain)
2020-11-13 20:53 UTC, John
no flags Details
/var/log/Xorg.0.log of Second Occurrance of Bug 20201113-1901+0000-UTC (21.48 KB, text/plain)
2020-11-13 21:00 UTC, John
no flags Details
Current System Information as of 13 November 2020 (530.61 KB, text/plain)
2020-11-13 21:03 UTC, John
no flags Details
Xorg.0.log file with intel_drv.so renamed to lkg.intel_drv.so (3.56 KB, text/plain)
2020-11-14 18:58 UTC, John
no flags Details
Xorg crash log during mode switch with NVIDIA driver 510.54 (5.97 KB, text/plain)
2022-03-11 19:41 UTC, Ruslan Zalata
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description John 2020-11-13 20:49:32 UTC
This /usr/local/bin/Xorg segmentation fault has occurred twice today within 90 minutes of each occurrance.  In the second occurrence only a file manager, two consoles, sylpheed, and XFCE DTE were running since boot of system.  This issue occurred about week ago, but I did not make attempts to save or document as at time I thought it was just a very rare set of conditions.  Prior to about two weeks ago this issue had never occurred since I first installed FreeBSD July 2019.

I will attach the related /var/log/Xorg.0.log files and console output of system information.  I have never has this a bug with X before in all my years of using X.  I do not know what other information I should provide if there is other information needed that I have provided.

The problem the three times that has occurred has always occurred when switching virtual terminals via Ctrl-Alt-Fx where the return to X/XFCE DTE via ctrl-alt-F9 causes the bug.

Data loss occurs as result of this bug.

In each of the three instances of the bug the system is rebooted.  Ergo the 90 minutes between first and second occurrence of the bug today.

The last occurrence via /var/log/Xorg.0.log was:

[  8568.469] (EE) Backtrace:
[  8568.835] (EE) 0: /usr/local/bin/Xorg (OsInit+0x38a) [0x5b898a]
[  8568.910] (EE) unw_get_proc_name failed: no unwind info found [-10]
[  8568.910] (EE) 1: /lib/libthr.so.3 (?+0x0) [0x802800bb0]
[  8568.917] (EE) unw_get_proc_name failed: no unwind info found [-10]
[  8568.917] (EE) 2: /lib/libthr.so.3 (?+0x0) [0x802800110]
[  8568.923] (EE) 3: ? (?+0x0) [0x7ffffffff003]
[  8568.968] (EE) 4: /usr/local/lib/xorg/modules/drivers/intel_drv.so (ignore+0x2373) [0x806659333]
[  8568.975] (EE) 5: /usr/local/lib/libdrm.so.2 (drmHandleEvent+0x159) [0x8016a1ff9]
[  8568.981] (EE) 6: /usr/local/bin/Xorg (OsCleanup+0x4c5) [0x5b8f75]
[  8568.988] (EE) 7: /usr/local/bin/Xorg (WaitForSomething+0x18e) [0x5b0d9e]
[  8568.994] (EE) 8: /usr/local/bin/Xorg (UpdateCurrentTimeIf+0x22c) [0x431e9c]
[  8569.035] (EE) 9: /usr/local/bin/Xorg (InitFonts+0xa4c) [0x43cdac]
[  8569.041] (EE) 10: /usr/local/bin/Xorg (_start+0x9b) [0x425436]
[  8569.048] (EE) 11: ? (?+0x0) [0x800853000]
[  8569.048] (EE) 
[  8569.048] (EE) Segmentation fault at address 0x7040175b0
[  8569.048] (EE) 
Fatal server error:
[  8569.048] (EE) Caught signal 11 (Segmentation fault). Server aborting
Comment 1 John 2020-11-13 20:53:55 UTC
Created attachment 219650 [details]
/var/log/Xorg.0.log of First Occurrence of Bug 20201113-1704+0000-UTC

/var/log/Xorg.0.log of First Occurrance of Segmentation Bug via VT switch to X/XFCE DTE 20201113 17:04+0000-UTC
Comment 2 John 2020-11-13 21:00:02 UTC
Created attachment 219651 [details]
/var/log/Xorg.0.log of Second Occurrance of Bug 20201113-1901+0000-UTC

/var/log/Xorg.0.log of Second Occurrence of Bug 20201113-1901+0000-UTC
Comment 3 John 2020-11-13 21:03:46 UTC
Created attachment 219652 [details]
Current System Information as of 13 November 2020

Current System information as of 13 November 2020
Comment 4 Jan Beich freebsd_committer freebsd_triage 2020-11-13 21:39:50 UTC
> drm-fbsd11.2-kmod-4.11g20200420 DRM modules for the linuxkpi-based KMS components
[...]
> 24    1 0xffffffff824e1000 79c70    i915kms.ko (/boot/kernel/i915kms.ko)

It seems your're not actually using drm-*-kmod. /boot/kernel/i915kms.ko is part of ancient in-base drm2 which is based on Linux 3.8 drivers.

According to pkg-message you need to add kld_list="/boot/modules/i915kms.ko" to rc.conf(5). It'd unlock VAAPI via libva-intel-driver as well. ;)

> (--) PCI:*(0@0:2:0) 8086:0116:17aa:21ed rev 9, Mem @ 0xd0000000/4194304, 0xc0000000/268435456, I/O @ 0x00005000/64, BIOS @ 0x????????/65536

0116 is SandyBridge (Gen6). drm-kmod should work fine but upgarding to FreeBSD 12.* may bring more stability.

In general, userland drivers (e.g., mesa-dri, xf86-video-{intel,amdgpu,ati}, modesetting) in ports/ have to support everything but the level of support degrades the farther away one strays from what contributors dogfood (i.e., -CURRENT):
- in-base drm2 aka drm-legacy-kmod are a complete abandonware
- drm-fbsd11.2-kmod is abandonware that still receive minor QA/fixes
- drm-fbsd12.0-kmod is abandonware that still receive minor QA/fixes
- drm-current-kmod is stable and receives LTS upstream fixes
- drm-devel-kmod is best maintained but can be unstable shortly after major updates

> (II) UXA(0): Driver registered support for the following operations:
> (II)         solid
> (II)         copy
> (II)         composite (RENDER acceleration)
> (II)         put_image
> (II)         get_image

Set "AccelMethod" to "SNA" (aka Sandybridge New Acceleration) in xorg.conf(5) for more performance. SNA is default upstream, so maybe more stable.

> (EE) 4: /usr/local/lib/xorg/modules/drivers/intel_drv.so (ignore+0x2373) [0x806659333]

Try modesetting (part of xorg-server package). Either remove xf86-video-intel or set "Driver" to "modesetting" in xorg.conf(5).
Comment 5 John 2020-11-14 00:58:24 UTC
Current System information as of 13 November 2020(In reply to Jan Beich from comment #4)

Jan,

Thanks for your  points and technical comments.

I want to be sure before I make any changes that X/XFCE will start again or I will have challenges following up to this bug.

Based on <https://www.freebsd.org/doc/en/books/handbook/x-config.html>"

1) I have no xorg.conf.  That is good as far as I can tell.

2) The user is part of wheel group, but not the video group.  Is this fine?  the above suggests yes.

3) Do I need to add kern.vty=vt to /boot/loader.conf?

4) Opps despite (1) above I have a xorg.conf in /usr/local/etc/X11/xorg.conf.d/ that the find I did for (1) did not find:

4 -rw-r--r--  1 root  wheel    90 Jul 18 12:55:23 2019 driver-intel.conf
4 -rw-r--r--  1 root  wheel  1936 Jul 18 12:58:53 2019 xorg.conf
4 -rw-r--r--  1 root  wheel  1936 Jul 18 12:58:53 2019 xorg.conf.new

These were install when I initially installed FreeBSD for first time 18 July 2019.  Do you want me to attach the /usr/local/etc/X11/xorg.conf.d/xorg.conf before I try the ""AccelMethod" to "SNA""

Do I need to attach the /usr/local/etc/X11/xorg.conf.d/driver-intel.conf, change it or delete it to implement the "Try modesetting (part of xorg-server package). Either remove xf86-video-intel or set "Driver" to "modesetting" in xorg.conf(5)."

4) xrandr says:

Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192
LVDS-1 connected primary 1366x768+0+0 (normal left inverted right x axis y axis) 256mm x 144mm
   1366x768      59.97*+
   1280x720      59.86    59.74  
   1024x768      60.00  
   1024x576      59.90    59.82  
   960x540       59.63    59.82  
   800x600       60.32    56.25  
   864x486       59.92    59.57  
   640x480       59.94  
   720x405       59.51    58.99  
   640x360       59.84    59.32  
VGA-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)

Does xrand provide any additional insight?

5) /usr/local/etc/X11/xorg.conf.d/screen-resolution.conf does not exist.

6) Do I need to do a "Xorg -configure" and "Xorg -retro -config /root/xorg.conf.new"?
Comment 6 John 2020-11-14 01:06:11 UTC
(In reply to John from comment #5)
Opps I forgot to note I did not have this issue until I upgraded from 11.3 to 11.4 Kernel.
Comment 7 Jan Beich freebsd_committer freebsd_triage 2020-11-14 02:40:29 UTC
(In reply to John from comment #5)
> 1) I have no xorg.conf.  That is good as far as I can tell.

Good. If necessary just configure desired sections. Since the adoption of KMS by various vendors DDX drivers like xf86-video-intel are deprecated.

> 2) The user is part of wheel group, but not the video group.
> Is this fine?  the above suggests yes.

No. "video" group is required for DRI3, VAAPI, OpenCL, etc.

See also https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#render-nodes

> 3) Do I need to add kern.vty=vt to /boot/loader.conf?

Default since FreeBSD 11.0, see base r268158.

> Do you want me to attach the /usr/local/etc/X11/xorg.conf.d/xorg.conf before I try the ""AccelMethod" to "SNA""

Find which one specifies "Driver" "intel" and adjust "AccelMethod" there e.g.,

  Section "Device"
          Identifier "integrated_card"
          Driver     "intel"
          Option     "AccelMethod" "SNA"
  #       Option     "TearFree" "true" # uncomment if *not* using compositor (e.g., picom)
          Option     "DRI" "3"
  #       BusID      "pci:0:2:0" # uncomment if multi-GPU
  EndSection

> Do I need to attach the /usr/local/etc/X11/xorg.conf.d/driver-intel.conf,
> change it or delete it to implement the "Try modesetting...

Find which one specifies Section "Device" then "Driver" "modesetting". Alternatively, remove all configs and xf86-video-intel.

> 6) Do I need to do a "Xorg -configure" and
> "Xorg -retro -config /root/xorg.conf.new"?

Auto-configuration is known to be broken. Try with empty xorg.conf(5) then fill in whatever you miss. modesetting(4x) usually works fine without any configurion.
Comment 8 John 2020-11-14 13:30:20 UTC
(In reply to Jan Beich from comment #7)
I was thinking I do the changes in increments to be safe that I can start the X/XFCE DTE.  First was going to be add my user to video group.

I used the "pw groupmod video -m [userid]" command, that returns with no error message and return code 0.  Yest "id" still shows the [userid] is not part of video group, but is prior to "pw groupmod video -m [userid]" and after still part of wheel group.

Is it possible that because the [userid] is already part of the wheel group that in some manner adding the [userid] to the video group is muted in some manner such that no error message and return code of 0 to add [userid] to video group is somehow superseded because the [userid] is part of the wheel group?

Adding the [userid] to the video group was to be my first incremental step.
Comment 9 Jan Beich freebsd_committer freebsd_triage 2020-11-14 15:28:53 UTC
(In reply to John from comment #8)
> Yest "id" still shows the [userid] is not part of video group

Re-login. Existing sessions(s) are not affected by changes to group(5).

In the past, nscd(8) could throw off pw(8), see bug 119695 and bug 207804.
Comment 10 John 2020-11-14 17:22:02 UTC
Opps first of despite the years using Unix I seem to keep forgetting when add/remove a user from a group one has to log out the user and log back into the user to see the changes to groups made.  Sorry I forgot this yet again.

Before I forget I made a configuration change to xfce4-screensaver after your first entry to this issue in hopes I would avoid my need to do VT switching the several times a day I have to due to long standing bug with xfce4screensaver.  Long standing means well back into FreeBSD 11.3 and many Px releases of 11.3.  The issue is not due to FreeBSD core, just so you have a sense of hoe long and often I have been doing VT switching as very crude workaround to the xfce4-screensaver bug I have had open for some time. 

Sequence so far of incremental changes:

1) Reboot system after adding [userid] to video group.  Successful and X/XFCE DTE still functions. Did not save a copy of the /var/log/Xorg.0.log.

2) Renamed /usr/local/etc/X11/xorg.conf.d/
4 -rw-r--r--  1 root  wheel  1936 Jul 18  2019 lkg.xorg.conf
4 -rw-r--r--  1 root  wheel  1936 Jul 18  2019 lkg.xorg.conf.new

Rebooted system.   Successful and X/XFCE DTE still functions. Saved a copy of the /var/log/Xorg.0.log.

3) Renamed /usr/local/etc/X11/xorg.conf.d/
4 -rw-r--r--  1 root  wheel    90 Jul 18 12:55:23 2019 lkg.driver-intel.conf
Rebooted system.   Successful and X/XFCE DTE still functions. Saved a copy of the /var/log/Xorg.0.log.

4) Renamed /usr/local/lib/xorg/modules/drivers/
1664 -rwxr-xr-x  1 root  wheel  1665080 Aug 31 13:50:47 2020 lkg.intel_drv.so

and left unchanged /usr/local/lib/xorg/modules/drivers/
 100 -rwxr-xr-x  1 root  wheel   102008 Oct  3 11:22:11 2020 modesetting_drv.so
  20 -rwxr-xr-x  1 root  wheel    20176 Feb 27 01:18:06 2020 scfb_drv.so
  28 -rwxr-xr-x  1 root  wheel    28608 Oct  3 14:32:59 2020 vesa_drv.so

Rebooted system.  Unsuccessful startx:

[    56.287] (II) LoadModule: "intel"
[    56.301] (WW) Warning, couldn't open module intel
[    56.301] (EE) Failed to load module "intel" (module does not exist, 0)
[    56.301] (EE) No drivers available.
[    56.301] (EE) 
Fatal server error:
[    56.301] (EE) no screens found(EE) 
[    56.301] (EE) 
Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
[    56.301] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[    56.302] (EE) 
[    56.302] (EE) Server terminated with error (1). Closing log file.

Saved a copy of the /var/log/Xorg.0.log.

Reverted (4) above to /usr/local/lib/xorg/modules/drivers/
1664 -rwxr-xr-x  1 root  wheel  1665080 Aug 31 13:50:47 2020 intel_drv.so
1664 -rwxr-xr-x  1 root  wheel  1665080 Aug 31 13:50:47 2020 lkg.intel_drv.so
 100 -rwxr-xr-x  1 root  wheel   102008 Oct  3 11:22:11 2020 modesetting_drv.so
  20 -rwxr-xr-x  1 root  wheel    20176 Feb 27 01:18:06 2020 scfb_drv.so
  28 -rwxr-xr-x  1 root  wheel    28608 Oct  3 14:32:59 2020 vesa_drv.so

Rebooted system.   Successful and X/XFCE DTE still functions. Saved a copy of the /var/log/Xorg.0.log.

I know renaming intel_drv.so may not be the best alternative to removing package xf86-video-intel.  Some thoughts I have are:

a) When FreeBSD 11.3 was installed from scratch 18 July 2019 FreeBSD installed the xf86-video-intel and the files in /usr/local/etc/X11/xorg.conf.d/ that has never changed to date.

b) The /usr/local/lib/xorg/modules/drivers/intel_drv.so clearly has had updates as result of "pkg upgrade".  That seems to suggest package xf86-video-intel is still being updated and maybe still required for (my) FreeBSD 11 at least?

c) If xf86-video-intel is not needed why is it being installed by FreeBSD?

d) If /usr/local/etc/X11/xorg.conf.d/xorg.conf is not needed why is /usr/local/etc/X11/xorg.conf.d/xorg.conf being installed?

e) Do I need to still implement the option "AccelMethod" "SNA" with no /usr/local/etc/X11/xorg.conf.d/xorg.conf?
Comment 11 Jan Beich freebsd_committer freebsd_triage 2020-11-14 17:56:39 UTC
(In reply to John from comment #10)
> [    56.287] (II) LoadModule: "intel"

Check Xorg.log for (**) lines. Maybe you still have a config that forces "intel".

> c) If xf86-video-intel is not needed why is it being installed by FreeBSD?

"pkg info -r xf86-video-intel" and "pkg check -d" may help.

> d) If /usr/local/etc/X11/xorg.conf.d/xorg.conf is not needed
> why is /usr/local/etc/X11/xorg.conf.d/xorg.conf being installed?

"pkg which /usr/local/etc/X11/xorg.conf.d/xorg.conf". Some xf86-* ports do install files under xorg.conf.d/, so Xserver(1) picks it up by default.

Also, xorg.conf.d/xorg.conf doesn't make sense. Either use xorg.conf and/or xorg.conf.d/<whatever>.conf.

> e) Do I need to still implement the option "AccelMethod" "SNA"
> with no /usr/local/etc/X11/xorg.conf.d/xorg.conf?

xf86-video-intel and modesetting are interchangeable. Only the former supports AccelMethod. If modesetting(4x) works fine remove xf86-video-intel.

Besides, until you switch to drm-*-kmod (/boot/modules/i915kms.ko) all of this maybe pointless.
Comment 12 John 2020-11-14 18:35:13 UTC
(In reply to Jan Beich from comment #11)

"pkg info -r xf86-video-intel":

xf86-video-intel-2.99.917.909,1:

"sudo pkg check -d":

Shows issues I have seen in less verbose manner with "pkg upgrade" for well over a year I will open a bug for after I have rached where this issue needs to be.

When I looked at the Xorg.0.log file for the "**" I discovered there are two directories being referenced got X startup in the following search order:

"/usr/local/etc/X11/xorg.conf.d"
"/usr/local/share/X11/xorg.conf.d"

ls -lsT /usr/local/share/X11/xorg.conf.d
4 -rw-r--r--  1 root  wheel   152 Oct  3 11:22:11 2020 20-evdev-kbd.conf
4 -rw-r--r--  1 root  wheel  1429 Oct  3 11:22:47 2020 40-libinput.conf
4 -rw-r--r--  1 root  wheel  1753 Oct  3 11:54:43 2020 70-synaptics.conf

I will attach the Xorg.0.log for the stage point of renanimg the /usr/local/lib/xorg/modules/drivers/intel_drv.so.  I did not attach any of the /vat/log/Xorg.0.log files not knowing which one or more may be of interest. 

Based on dates of the /usr/local/share/X11/xorg.conf.d installed when a "pkg upgrade" was done 18 October 2020 right after a FreeBSD 11.3 to 11.4 upgrade was done.  I looked at each of the files in /usr/local/share/X11/xorg.conf.d and find no reference to "intel" or video driver.  With no xorg.conf why and where would Xorg be trying to find an intel driver?

Would it make sense short term to create a xorg.conf with just with BusID that matches my system and see if VT switching issues are resolved?:

"Driver" "intel" and adjust "AccelMethod" there e.g.,

  Section "Device"
          Identifier "integrated_card"
          Driver     "intel"
          Option     "AccelMethod" "SNA"
  #       Option     "TearFree" "true" # uncomment if *not* using compositor (e.g., picom)
          Option     "DRI" "3"
  #       BusID      "pci:0:2:0" # uncomment if multi-GPU
  EndSection
Comment 13 John 2020-11-14 18:58:36 UTC
Created attachment 219688 [details]
Xorg.0.log file with intel_drv.so renamed to lkg.intel_drv.so

This is the Xorg.0.log file when /usr/local/lib/xorg/modules/drivers/intel_drv.so was renamed to /usr/local/lib/xorg/modules/drivers/lkg.intel_drv.so such that Xorg would not start wit no xorg.conf file
Comment 14 John 2020-11-15 00:20:52 UTC
Opps big time.

Tried kld_list="/boot/modules/i915kms.ko" in /etc/rc.conf.  no other kld was in rc.conf.

FreeBSD boot with data in screen for bit, then screen goes blank for about 30+ seconds, FreeBSD reboots on own, and repeats.

I had to use single user mode to restore prior /etc/rc.conf I had kept.

System rebooted and then created /var/crash files.

Not good. No clue why occurred or what FreeBSD was not happy about related to  kld_list="/boot/modules/i915kms.ko" in /etc/rc.conf.
Comment 15 Emmanuel Vadot freebsd_committer freebsd_triage 2021-11-19 14:35:47 UTC
Closing this one, please open again if that still happens with up to date packages.
Comment 16 Ruslan Zalata 2022-03-11 19:41:14 UTC
Created attachment 232391 [details]
Xorg crash log during mode switch with NVIDIA driver 510.54
Comment 17 Ruslan Zalata 2022-03-11 19:44:20 UTC
X.Org X Server 1.20.13 crashes on my laptop with latest NVIDIA driver (510.54 Tue Feb  8 04:29:15 UTC 2022). Installation of the driver was made according to these instructions:

https://gist.github.com/Mostly-BSD/4d3cacc0ee2f045ed8505005fd664c6e

Complete log in attachment. Brief output from Xorg as follows. 

root@butterfly:/home/rz# X

X.Org X Server 1.20.13
X Protocol Version 11, Revision 0
Build Operating System: FreeBSD 13.0-RELEASE-p7 amd64 
Current Operating System: FreeBSD butterfly 13.0-RELEASE-p7 FreeBSD 13.0-RELEASE-p7 #0: Mon Jan 31 18:24:03 UTC 2022     root@amd64-builder.daemonology.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
Build Date: 01 March 2022  02:11:36AM
 
Current version of pixman: 0.40.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: Sat Mar 12 00:15:14 2022
(==) Using config file: "/etc/X11/xorg.conf"
(==) Using system config directory "/usr/local/share/X11/xorg.conf.d"
(EE) 
(EE) Backtrace:
(EE) 0: /usr/local/bin/Xorg (?+0x0) [0x41e27a]
(EE) unw_get_proc_name failed: no unwind info found [-10]
(EE) 1: /lib/libthr.so.3 (?+0x0) [0x80092ce0e]
(EE) unw_get_proc_name failed: no unwind info found [-10]
(EE) 2: /lib/libthr.so.3 (?+0x0) [0x80092c3cf]
(EE) 3: ? (?+0x0) [0x7ffffffff003]
(EE) 
(EE) Segmentation fault at address 0x0
(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) 
(EE) Server terminated with error (1). Closing log file.
Abort (core dumped)
Comment 18 Alex S 2022-03-11 22:10:02 UTC
(In reply to Ruslan Zalata from comment #17)

Already discussed in bug 261666.