Return to BSD News archive
Xref: sserve comp.os.386bsd.bugs:1024 comp.windows.x.i386unix:2266
Newsgroups: comp.os.386bsd.bugs,comp.windows.x.i386unix
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!ux1.cso.uiuc.edu!howland.reston.ans.net!xlink.net!gmd.de!mururoa!veit
From: veit@mururoa.gmd.de (Holger Veit)
Subject: Re: XFree86 1.3 crashes under 386BSD
Message-ID: <1993Jul1.190603.4559@gmd.de>
Sender: veit@mururoa (Holger Veit)
Nntp-Posting-Host: mururoa
Organization: GMD - German National Research Center for Computer Science
References: <20ea6n$5v5@email.tuwien.ac.at>
Date: Thu, 1 Jul 1993 19:06:03 GMT
Lines: 67
In article <20ea6n$5v5@email.tuwien.ac.at>, mbirgmei@email.tuwien.ac.at (Martin BIRGMEIER) writes:
|> Hello all,
|>
[... XFree86-1.2/1.3 crashing after some minutes, codrv?, pk-0.2.4? ...]
|> their boxes, doesn't it? Some of the many changes between 1.1 and 1.2
|> must have exposed a bug - somewhere, and I'd so much *like to know*!
|>
|> Here is some relevant information from SuperProbe:
|>
|> First video: Super-VGA
|> Chipset: Tseng ET4000
|> RAMDAC: AT&T 20C491/492 15/16/24-bit DAC
Is the latter one a hicolor version? I dunno, but this could probably cause
trouble. David, more comment on this? Otherwise, the ET4000 is known pretty
well, so I believe the problem is not the hardware.
I haven't asked SuperProbe about my RAMDAC, but plain ET4000 worked quite
well for nearly all codrv or pccons kernels (of different patchlevels or
versions) with xservers from 1.1 to 1.3 on my system.
|> VGA256: SpeedUp mode selected (Flags=0x3f)
|> Text save failed
|> Text restore failed
|>
|> where the last two lines obviously come from the new version of codrv
|> I installed with patchkit-0.2.4.
This is true. There is an unaligned data structure in ioctl_pc.h which
compiles differently on gcc1 and gcc2 (the server binary available is
compiled with gcc2, the kernel with gcc1). If you compile the 1.1 server
from scratch with the new ioctl_pc.h, this effect should go away. But this
is not a problem: you obviously have a new server which crashes in an
improved way :-)
|>
|> One more hint for those who might know the solution: I can trigger a
|> crash most easily if I run xlock with one of the modes which draw lines,
|> e.g. swarm or qix. Since the precompiled XFree86-1.3 binary has no
|> symbols, I can't get a full stack traceback; only the fact that abort()
|> was called can be deduced from the core. So most likely some signal
|> like bus error et al must have occured.
This might be a dangling pointer left in the server (and you suspected
the drawline part), but since this happened for almost every server,
I doubt that it hasn't shown up before. Since drawline is a facility
of the device independent part, *except for the speedup-code* for ET4000,
you could try to disable speedup mode (some option in Xconfig) and check
if this changes something.
But the effect might as well be yet another bug in the kernel (yes there are
still some :-)), e.g. in the VM system.
|> Solutions to this problem would be most appreciated!
|>
|> - Martin
|>
|> P.S. Other setup: 486DX50, 16M mem, 1542B + 300M SCSI, MSoft mouse,
|> etherlink II
Doesn't look too unusual.
--
Dr. Holger Veit | INTERNET: Holger.Veit@gmd.de
| | / GMD-SET German National Research | Phone: (+49) 2241 14 2448
|__| / Center for Computer Science | Fax: (+49) 2241 14 2342
| | / P.O. Box 13 16 | Had a nightmare yesterday:
| |/ Schloss Birlinghoven | My system started up with
DW-5205 St. Augustin, Germany | ... Booting vmunix.el ...