Hardware: API UP2000, Voodoo3-3000 card, BTTV card in machine,
Sony CPD-G500 monitor.
Software: Redhat 7 Alpha Linux Deluxe, default XFree4.
Previously, this combination ran Redhat 6.1, default XFree 3.something,
at 1600x1200, ~75-76Hz, 24bpp truecolor fine, using the SVGA X
With Redhat 7, default XFree4, it runs 1600x1200, 85Hz, 8bpp fine,
using the "tdfx" driver.
With both Xconfigurator and X -configure, any attempt to use 24bpp
(at any resolution) has caused fatal X server crashes, signal 4, or
a garbled screen.
I'm not attempting to do Glide or any 2D or 3D animation, just plain
X window system stuff at 1600x1200, >=75Hz, 24bpp. I'd also like to
use the TV card.
Is "tdfx" the right driver? Or, is there a closer equivalent to the old
SVGA X server?
I'm told Redhat 7 can use XFree 3.6 drivers, but I have not found
documentation on how to do that. Would that be worth trying? If
I'd be glad to send configuration files, log files, core files :-), if
AGP or PCI card? Query bugzilla for "voodoo" bugs, and see if any other bugs
match your symptoms.
To try xfree 3.3.6, make sure it is installed (XFree86-Servers) and run
Xconfigurator with: Xconfigurator --preferxf3
Yes, please also attach your config files and log files to this bugzilla entry.
Created attachment 8391 [details]
XF86Config for XFree 4 server
Created attachment 8392 [details]
XF86Config-4 for XFree 4 server
Created attachment 8393 [details]
log with XFree 4 server
Created attachment 8394 [details]
XF86Config for XFree 3.3.6 server
Created attachment 8395 [details]
XF86Config-4 for the XFree 3.3.6 server
Created attachment 8396 [details]
log from XFree 3.3.6 server
Created attachment 8397 [details]
(oops) This is the _real_ XF86Config-4 for the XFree 3.3.6 server
The UP2000 only has PCI slots (and one ISA), so this is a PCI card I'm
using. I checked the other 'voodoo' reports, and nothing seemed to
match my symptoms. I installed the XFree86-Servers RPM (source was
all I could find on the CD). The screen corruption at 24bpp was less
than with the XFree 4 server, but it was still nowhere near usable.
I attached config and log files (some of the configs are probably
superfluous, but I didn't know that for certain) from both the XFree 4
server and the XFree 3.3.6 (--preferxf3) server. However, I made one
oops: id=8395, time='20:04:23' is not correctly identified. The real file
of that description is id=8397, time='20:08:18'. (Sorry.)
Thanks for working on this issue.
I just realized you're using an alpha... Duh... Sorry about that.
Please try our latest release in my ftp space:
Get XFree86-4.0.2a-2 and Mesa-3.4-13. There are a few Alpha X bugs fixed
from the one you're using.
FYI, the XF86Config file is the config for XFree86 3.3.6 and the XF86Config-4
is the config file from XFree86 4.x
I notice that you have alpha RPMs for 4.0.3-1. Will those work, as well?
Should I upgrade to that, and if so, which versions of the XF86Config s will I use?
Thanks for the updated info and the chance to download a fix.
When I went to the indicated ftp space (people.redhat.com/mharris),
I found XFree86/4.0.2a-1, but not ...a-2. Hoping the a-2 was just
a typo, I downloaded and attempted to install the 4.0.2a-1 (and Mesa)
set. I get a dependency failure that I need libfreetype.so.6 in order to
install these. Please excuse my newbieness, but I was unable to find
where this library should come from. At present, my system is RH7
plus anything from up2date as of about a week ago, except for the
most recent kernel update.
Should I be using 4.0.2a-1, or maybe 4.0.3-1?
Where should I be getting libfreetype.so.6?
A little more checking showed me some about freetype, so now I can maybe
ask a slightly more intelligent question. My system is RH7 plus updates through
about a week ago. I have freetype (and -devel and -utils) 1.3.1-7. I see a
libfreetype.a but no libfreetype.so.
Where should I be getting the .so version of libfreetype?
I finally got 4.0.2a-1 and 4.0.3-1 to install from the binary RPMs. However,
the X server dies immediately upon startup, in the pcidata module. In one case,
it reports segmentation fault, and the other just dies. There was a bug
on email@example.com that the code that reads /proc/bus/pci/devices uses a
static buffer that is not long enough for 64-bit addresses. Could this be the
I tried building XFree 4.0.2a-1 from the source RPM, but it died during linking
with: "can't find -lglide3".
I made a few more attempts, but everything still fails. I found that the source
compile _after_ I install the corresponding binary RPMs. (I would guess there
a problem in the makefiles or something similar.) With the canned 4.0.2a-1
the canned 4.0.3-1 binary RPMs, and the home-compiled 4.0.2a-1, I get the same
a segmentation fault during or immediately after the pcidata module.
On the advice of Michal from Harddata, I downloaded 4.0.3-3 and tried it.
It has the same symptoms--X server segment faults during or after module
pcidata. It does the same thing with a TNT2 card and a Permedia2 Oxygen
There are some pagesize assumptions in all of the DRI drivers which
I've added fixes for, this may or may not solve the problem for you.
These fixes are going to be in the 4.0.3-4 release soon. I will look
into this and see what I can come up with but I do not have any 3dfx
hardware, nor an alpha... ;o(
On the bright side of things - if someone gives me an alpha, and a Voodoo
card, I'll spend all my spare time working on a fix for this, as well as
other Alpha bugs. ;o) All seriousness aside.. back into the code cave.. ;o)
Thanks for the news that 4.0.3-4 is coming soon.
I ran into something interesting this morning. Yesterday, I had installed
to try it. Although it didn't work for me any better than 4.0.2a-1, I kept it
the machine, using the 3.3.6 X server with the Permedia2 Oxygen card.
This morning, both Netscape and Acroread refused to come up, bombing with
a long X-protocol error message. Downgrading to 4.0.2a-1 made Netscape
and Acroread work again. I'm sorry, but I didn't have the presence of mind to
save the error message.
On the 4.0* server segment fault issue, I'm going to try to get a core dump
and stack trace from it.
On the subject of wanting an Alpha for testing, have you talked with the
fine follks at Harddata? Perhaps, it just might be mutually beneficial enough
that they might be able to put together a workable deal that would make that
happen. (I heard rumor that they or maybe API gave the ALSA folks use of
an Alpha machine for testing some time last year.)
Despite my best efforts at "limit core 256m" (/bin/csh) and such,
I could not get a core file from the segment faulting X server.
However, I was able to run "strace /etc/X11/X -probeonly", which
appears to be the core of the wrapper/server chain. I will add this
as an attachment in case it will help isolate the segment fault.
I'll take the risk of being called an idiot, but would kernel version
be an issue with this segment fault? I am running kernel 2.2.17-4,
while the XFree 4.0.2a-1 binaries appear to be compiled for a 2.4
kernel. However, I got the same symptoms when I did a "rpm
--rebuild" on the 4.0.2a-1 source RPM followed by a "rpm
--upgrade --oldpackage" to install the binaries I had compiled
with the 2.2.17-4 kernel, etc.
Created attachment 14043 [details]
strace output from segment faulting X server
Sorry for the numerous additional comments today, but I just got mail back
from Michal Jaegermann at Harddata. He says the strace shows the PCI
probing is "riding roughshod through ... PCI address space." He said you'd
know who to yell at. :-)
Michal suggested kernel 2.2.19 _might_ fix this if it was a kernel bug rather
than X. Or, is there a user-option to disable or tone down the PCI probing?
The segment fault problem has been solved by upgrading to kernel
2.2.19aa1 from Harddata and using XFree86 4.0.2a-1. (I did not
try XFree86 4.0.3* with the new kernel.) I'm running at least
16-bit color on a TNT2 card at 1600x1200 resolution. With some
configuration tweaking, I'm hoping to get back to 24-bit color.
Ok, sorry for the delay in responding.. So many bug reports, so little time..
To answer some of your questions - which you probably figured out already
on your own anyway.. ;o)
To run XFree86 4.0.3 on Guinness, you need to upgrade freetype, flex, Mesa,
and possibly other packages I'm forgetting. You should get these all from the
Seawolf release (7.1). Also, you should use my latest RPMS from:
Currently this is XFree86-4.0.3-14 and Mesa-3.4.1-1
Numerous alpha fixes and 3dfx are in this release including PCI resource
fixups for Alpha that should solve your problem. There are also massive
updates for Permedia, especially on Alpha.
WRT the kernel: I don't know the state of the kernels on Alpha very well
in any of our releases so it is hard for me to give alpha-kernel advice.
Best to ask that on our mailing lists, or ask one of our kernel guys
directly. (Alan/Arjan/Michael/Al/etc.) As for kernel/XFree86 interaction
however - if you use a 2.2.x kernel you'll be without DRI at a minimum
because the DRM is for kernel 2.4.x. I have no idea how difficult it
would be to backport. It could be as easy as just replacing the DRI dir
in the kernel with the one from XFree86, but I have no idea as I do not
work directly with any kernel code even WRT X - at least not yet.
Our 2.4.x kernel is of course the best match for XFree86 4.0.3 out of the
box, however I have no idea how easy or worthwhile it is to upgrade RHL7.0
to a 2.4.x kernel. It is likely just as much trouble to upgrade directly
to 7.1. Of course 7.1 has not been released for Alpha yet though so...
Either way, if you're running 4.0.2 or later, you _should_ be better off
with my latest release. Unless I get any useful patches or fixes real
soon, 4.0.3-14 will be the official final XFree86 release in our Alpha
distro release. Compaq's patches seem to have fixed tonnes of stuff very
Update the bug report when you get a chance and let me know how you make out.
In the comments for all the logs above you say "XF86Config-4 for 3.3.6 server",
etc. That is incorrect however - There are two XFree86 configuration files,
one is "XF86Config" and is read by the 3.3.6 X server, while the other file
is "XF86Config-4" and is for the 4.x server. There is no such thing as a
"XF86Config-4" for the 3.3.6 server. After exmining your problem deeper,
it seems aparent to me two things: 1, you're using DRI. Wether or not you
actually do any 3D stuff, DRI is loaded, and thus is in effect. At 1600x1200
on that card, DRI is not possible. Disable DRI and the problem should go away.
Also, the config file shows "Depth 32". Depth 32 is non-existant. The only
depth's are 8,15,16,24. There is no such thing as depth 32.
The X server takes your depth setting, and uses the appropriate fbbpp for
bpp in the server transparently. Thus depth 24 is 32bpp if the hardware
supports it, and the driver does as well, and is 24bpp if 32bpp isn't supported.
At any rate, on Voodoo hardware, having DRI enabled *and* not using depth 16,
is an invalid configuration.
Workaround: Xconfigurator --preferxf4 --nodri
or, just disable DRI yourself. Again, if you need/want DRI, you *must* use
depth 16. This is a 3dfx Voodoo hardware limitation.
I'm afraid I have to disagree about the "resolved" status. I tried a new
Voodoo3 3000 PCI graphics card, but it does not work with XFree 4.0.3-9.
Even with DRI turned off (--nodri), 24-bit color mode produces a garbled
display. The monitor is syncing fine, because the mouse cursor is perfect,
but anything else is scrambled.
With DRI turned off, 16-bit mode appears to work, but the X server locks
up very frequently. Starting gimp locks it up reliably. Using the page-down
or page-up button in Netscape locks it up nearly every time. Sometimes
when the X server has started to misbehave, small pieces of text and/or
graphics appear in wrong places on the screen when scrolling Netscape or
sometimes when doing nothing.
(I'll attach the config file and log file from the 16-bit attempt.)
I tried to update to the indicated newer XFree version, but I couldn't find one
that works with 7.0. There is no XFree anything under the 7.0 branch, and
the XFree 4.0.3-21 under the 7.1 branch requires glibc 2.2.3.
Is there a version of XFree 4.0.3-14 or greater that works with 7.0?
Is it safe to upgrade a 7.0 system to glibc 2.2.3?
Will XFree 4.0.3-21 source RPMs compile and run on 7.0?
Is there another solution likely to work, given a 7.0 system?
Created attachment 22107 [details]
config file used for 16-bit attempt
Created attachment 22108 [details]
log file from 16-bit attempt