re: FYI: new X server in -current, among other X things

[matthew green <mrg%eterna.com.au@localhost>]

> TL;DR: after upgrading via the sets available from releng builds from
> July 16th (http://releng.netbsd.org/builds/HEAD/202207160630Z) I'm not
> able to start X on amd64 with i915 graphics. Separately, there may be
> issues with libX11 1.8.1 where clients will hang due to recursive locks
> occurring.

the libX11 thing is pretty terrible.  upstream says that
_not_ enabling it means other things are broken.  i don't
know anything better than fixing the clients i guess,
which is pretty terrible for backwards compat code/binaries.

> [   378.033] (EE) 0: /usr/X11R7/bin/X (xorg_backtrace+0x44) [0x1467d46d5]
> [   378.033] (EE) 1: /usr/X11R7/bin/X (os_move_fd+0x79) [0x1467d0465]
> [   378.033] (EE) 2: /usr/lib/libc.so.12 (__sigtramp_siginfo_2+0x0) [0x75b46379c930]
> [   378.034] (EE) 
> [   378.034] (EE) Segmentation fault at address 0x0
> 
> This happens with ctwm as part of the base installation, as well as with
> other pre-existing window managers and such from pkgsrc built against
> 9.99.97.

can you configure X to generate a core dump or run it
under GDB and get the real stack trace?  i thought we'd
fixed this problem in libexecinfo, but it's still not
tracing through the SEGV above, so finding what is
crashing where is what we need next.

does it happen when X starts up?  maybe it crashes with
plain running "X" without any arguments (ie, not using
some frontend that will also fire up clients etc.)

can you post the whole Xorg.0.log somewhere?  most of
my i915 systems have become non-functional the last few
years, but i have one system to test.


.mrg.