Subject: port-i386/8256: kernel related X-server crashes
To: None <gnats-bugs@gnats.netbsd.org>
From: None <Thilo.Manske@HEH.Uni-Oldenburg.DE>
List: netbsd-bugs
Date: 08/23/1999 19:15:48
>Number:         8256
>Category:       port-i386
>Synopsis:       X server crashes due to kernel bugs introduced recently
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    port-i386-maintainer (NetBSD/i386 Portmaster)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Aug 23 18:05:01 1999
>Last-Modified:
>Originator:     Thilo Manske
>Organization:
Dies ist Thilos Unix Signature! Viel Spass damit.
>Release:        current since mid July
>Environment:
	
System: NetBSD WintelKiller 1.4K NetBSD 1.4K (WintelKiller) #157: Sun Aug 22 18:35:28 MEST 1999 thilo@WintelKiller:/usr/src/sys/arch/i386/compile/WintelKiller i386
(no rnd device)

>Description:
Since maybe two weeks I'm experiencing X-server crashes:
Fatal server error:
Caught signal 11.  Server aborting

I think they're related to kernel changes made recently, because:

1. I know for sure that they did not occure with the same X-server
   (XF86_SVGA from XFree3.3.4) around 14th July since I have played around
   with a lot of gqmpeg skins that day (see "How-To-Repeat").
2. They happen with every kernel compiled since then and even with old
   X-Servers I've downloaded from the NetBSD ftp server (the a.out sets for
   1.4 and the XFree3.3.4 snapshot in arch/i386).

Though I doubt that it matters, here are the configurations of two
i386 machines, I was able to reproduce this bug (haven't tried a third).
AMD K6-2 @ 350MHz			AMD K6-III @400MHz
2 64MB SDRAM-100 SIMMS			1 128MB SDRAM-100 SIMM
Soyo E5MA+ Motherboard (VIA chipset)	Asus P5A (Ali chipset)
Miro Highscore Pro (AGP, 3Dfx Banshee)	Diamond Viper V330 (AGP, Riva 128)

It does not crash on NetBSD/arm32 with Xvidc (both quite current), displaying
gqmpeg remotely.

Here's a backtrace I got from a cordump of the Xserver:
#0  0x4837bb39 in kill ()
#1  0x4837b315 in abort ()
#2  0x815c64e in ddxGiveUp ()
#3  0x815c6e4 in AbortDDX ()
#4  0x8196551 in AbortServer ()
#5  0x8197317 in FatalError ()
#6  0x816535c in xf86VTSwitch ()
#7  <signal handler called>
#8  0x82570e3 in miRegionDestroy ()
#9  0x826928b in miSetShape ()
#10 0x8269948 in RegionOperate ()
#11 0x8269e56 in ProcShapeCombine ()
#12 0x826a81e in ProcShapeDispatch ()
#13 0x8174f1b in Dispatch ()
#14 0x8182f98 in main ()
#15 0x807d499 in __start ()
If there's more information I can squeeze out of a coredump,
please let me know.

>How-To-Repeat:
This is the most succesfull way to reproduce the crash:
run gqmpeg, repeat changing skins until X-server crashes
(more complex skins like Gqofol seem to crash X "better")

It doesn't matter, if gqmpeg runs on the same machine as the X-server
or on a remote one
>Fix:
>Audit-Trail:
>Unformatted: