Re: Xorg segfaulting and other problems

[Jukka Salmi <j+nbsd%2009.salmi.ch@localhost>]

Jukka Salmi --> tech-x11 (2009-01-19 22:00:14 +0100):
> Hello,
> 
> after successfully running XFree86 on a NetBSD/i386 current system for
> years I recently decided to give the in-tree Xorg a try.  Using binaries
> built from sources as of 2009-01-02 I noticed several problems:

Finally all those problems seem to be fixed or at least not reproducable
anymore.  At least on a 5.0_STABLE system; I didn't try with -current,
but since the problems are identical I'm quite sure the fixes also make
a -current Xorg system work.  Since none of those fixes have been
committed yet I'll summarise them here:


> - When using another window manager where moving windows is done
>   "opaque" (i.e. not just their borders are shown as with twm),
>   moving windows was extremely slow (CPU intensive!).  Furthermore,
>   xterm generally was slow, e.g. a visual bell was more like a black
>   waterfall than a dark flash...  But rxvt-unicode was fast as usual.
>   Hmm...

This is fixed by building mga(4) with USE_XAA defined.  See [1]here for
details.


> - With XFree86 I'm using a Matrox G450 card with a dual head setup.
>   This works fine.  Of course I want to do the same with Xorg.  Thus
>   the first thing I did was running xorgconfig(1) and manually porting
>   various parts like the dual screen configuration from XF86Config(5) to
>   xorg.conf(5).  But running startx(1) afterwards resulted in Xorg dumping
>   core; a gdb bt shows:
> 
>     [...]
>     #13 0x0809769d in ddxGiveUp ()
>     #14 0x0809769d in ddxGiveUp ()
>     #15 0x08179f07 in AbortServer ()
>     #16 0x0817a345 in FatalError ()
>     #17 0x080a46f9 in xf86SigHandler ()
>     #18 0xbba49d20 in setusershell () from /usr/lib/libc.so.12
>     #19 0xbb68fc49 in ?? ()
>     #20 0xbb72a800 in ?? ()
>     #21 0x00000000 in ?? ()
> 
>   After removing xorg.conf startx was successful.  Xorg also started
>   successfully after just removing the second screen configuration part
>   from xorg.conf.  However, more problems followed (see below).

This is magically "fixed" by the USE_XAA fix referenced above. Ok, it's
probably not fixed, but I can't reproduce the crash with an XAA enabled
mga(4), and my original dual head setup works fine again.


> - Starting xterm(1) resulted in
> 
>     Failed to open input method
> 
>   being printed, and then it took several seconds until xterm eventually
>   appeared.  This was probably due to `LC_CTYPE' being set to `en_US.UTF-8';
>   at least the message was not printed and the delay went away after I
>   set LC_CTYPE=en_US.ISO8859-1.
> 
> - Starting twm(1) failed with
> 
>     unable to open fontset "-adobe-helvetica-bold-r-normal--*-120-*-*-*-*-*-*"
> 
>   while `LC_CTYPE' was `en_US.UTF-8'; xlsfonts(1) showed fonts matching
>   the above pattern.  However, setting it to `en_US.ISO8859-1' worked
>   around this problem, i.e. it made twm start.

Those two problems are fixed by a change to
/usr/X11R7/lib/X11/locale/en_US.UTF-8/XI18N_OBJS.  See [2]here for
details.


HTH, Jukka

[1] http://mail-index.netbsd.org/tech-x11/2009/07/03/msg000588.html
[2] http://mail-index.netbsd.org/tech-x11/2009/06/07/msg000511.html

-- 
This email fills a much-needed gap in the archives.