From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Description of problem:
Fresh Red Hat Linux 9 install on Compaq Presario 6000Z with integrated
ProSavageDDR video card.
/proc/pci reports this as a VT8751 [ProSavageDDR P4M266]
The graphics installer hangs - the X display is blank at most resolutions. At
640x480, I see a combination vertical/horizontal scroll that is unusable.
The system was installed in text mode for further troubleshooting.
/etc/X11/XF86Config shows the board as "S3 ProSavage KM133" and uses a savage
redhat-config-xfree86 attempts to load X right away and this fails.
The memory was also incorrectly auto-probed. It reported 4MB when there is
actually 8MB available (shared video memory configuration set in the BIOS)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Install Red Hat Linux 9 in graphics
2.Install in text mode and use redhat-config-xfree86
Actual Results: X display is blank
Expected Results: KDE or GNOME desktop should appear, which it does if the
vesa driver is used
Please attach both your XFree86 config file, and a log file from
using the savage driver as configured by "redhat-config-xfree86 --reconfig"
Created attachment 90931 [details]
compressed tar file with XFree86.0.log and XF86Config files
contains 2 directories (works and fails) with the XFree86.0.log and XF86Config
files for each. Basically the savage driver fails and the vesa driver works.
When attaching files to bug reports, it is preferred and greatly appreciated
if they are attached as individual uncompressed file attachments, so that they
are viewable inside a web browser by clicking on them. That makes it much
easier to investigate the problem in a minimal amount of time and effort.
I don't see anything in the logs and configs that is obvious to
It is possible that the driver or the hardware database may possibly have
this specific chip misnamed. I will have to confirm that.
However, wether or not the proper chip name is cosmetically displayed on
the screen or in the log file, or written to the config file does not
affect the operation of the driver. It is just that - a cosmetic name.
The "savage" driver is for all supported S3 savage hardware, including this
chip. Do not be too concerned if the name printed on screen seems incorrect
as the displayed name is only for humans. The driver itself doesn't matter
what the label assigned to the card is, it works based on the card's PCI ID,
which is read directly from PCI config space, so it will always be correct.
It seems the driver has a problem with your specific chip, which will have
to be explored by doing some troubleshooting with you to try to narrow the
Please backup your current working "vesa" config file, and run:
It will generate a new config file. Please test it, and attach the config
file and X server log file as individual uncompressed file attachments to
the bug report, as well as indication of wether or not it worked. Try to
test it in a variety of resolutions and color depths, and indicate which ones,
if any work for you.
If this also does not work, try adding the following to the device section
of the config file:
Test that out in a variety of resolutions and color depths also if you can.
>The memory was also incorrectly auto-probed. It reported 4MB when there is
>actually 8MB available (shared video memory configuration set in the BIOS)
I don't know if the XFree86 savage driver supports that mode of operation
or not. I do not have any S3 savage video hardware, but I will contact the
upstream driver maintainer to discuss that issue.
Please change the report back to ASSIGNED status when you update it with
the above test results.
If I start without an XF86Config file and do:
no XF86Config file is generated. The X display comes up blank and hangs until
I do a ctrl-alt-bs.
If I do do a --set-driver=vesa, then I can change the options, including
setting the savage driver. I will include the XFree86.setup.log file for this.
Created attachment 90940 [details]
XFree86.setup.log created from:
No XF86Config file is created - just the setup.log. The X session hangs until
I do a ctrl-alt-bs.
Created attachment 90941 [details]
XFree86.0.log - from a failure
This is the log file from a failure - the X display comes up blank and stays
that way until a c-a-bs. I will also attach the XF86Config that this came
Created attachment 90942 [details]
XF86Config file from a failure
This is also from a failure using the savage driver. I have tested the
with and without NoAccel - no difference
8, 15, 16, and 24 bit depths - no difference
8192 or 31768 videoram - no difference
If the resolution is set to 640x480 with the savage driver, it works. If I use
a resolution of 800x600 or 1024x768, it fails.
With the vesa driver, I can use all the depths and resolutions that I've tried.
I've even tried up to 1280x1024 and it works fine.
Nothing much to add, other than 'me too'. The Prosavage DDR driver on RH 9
can give me 640x480, nothing more. My monitor indicates that the card is
running much too slowly on the horizontal and vertical frequency. This
may be related to the issue mentioned by the driver maintainer, Tim Roberts
at http://www.probo.com/timr/savage40.html (see notes on the 1.1.27t
drop, specifically: "...a bug in the mode switching that caused the refresh rate
on some machines to come up stubbornly at 60Hz, even though the driver and the
log both indicate a higher refresh rate. This is now repaired.").
This may be something to do with it, although my X log (I'm currently at
work, so I can't attach it, nor give much more details) claimed that
the savage.o driver in RH 9 *is* version 1.1.27 (I'm not sure of the
significance of the 't' on the end of Tim Roberts' latest version).
I did attempt to swap the RH driver for the latest binary available above
but it didn't run. I'll try and compile the driver, or swapping the
libs as well. From Ed's X log: (II) SAVAGE: driver (version 1.1.27mh)
does the 'mh' indicate that this is a different version from the 't'?
diff says they differ, but that's not an indication, obviously.
I'd love to get this fixed, by the way - I've a very nice little shuttle
box I'd like to get up & running!
OK, I've got it working to an extent. If I add:
Option "UseBIOS" "no" (and Option "HWCursor" "No", or else I get two pointers)
to the driver section, I can get into 1024x768 (I haven't tried higher) at
a reported 24bpp (although I'm getting nasty banding on the default RH 9.0
gradient background, so I'm not convinced that's 24 bpp). I've tried 32bpp
but that gives me too slow H & V again.
All well and good? Not quite. I now can't switch to other virtual consoles -
the (text!) VCs on CTRL-ALT-F1 etc give me 18.2kHz x 23kHz (HxV) according
to my monitor.
Something odd's going on with this driver! I'm not on email over the weekend,
so if there's anything you want me to try, or log files needed or whatever,
post here (on redhat's bugtraq) & I'll check back occasionally.
Works at 1280x1024, which gives me 64kHz x 60Hz, according to my monitor.
This is again using the "UseBIOS" "no" option.
I can workaround the virtual console problem by doing them in graphics mode.
I can do this by adding vga=828 to my lilo.conf (and rerunning lilo, probably
a similar procedure if you're using grub). This I worked out from another
issue mentioned on Tim Roberts' page regarding switching modes on particular
laptops. He does mention:
"if your console screen is screwed up when you
switch using Ctrl-Alt-F1 or when you exit the server, try adding
to the "Device" section of your /etc/X11/XF86Config."
That didn't do anything for me.
So I've now got a system sortof working, but something needs fixing
for this to work automatically.
Basically, the crux of this, is that there is a bug in the driver in
Red Hat Linux 9, and in order to determine what it is, someone who has
the actual hardware physically in front of them and can reproduce the
problem, and has a strong interest in the problem being fixed, and is
willing to spend some serious time troubleshooting by testing various
things needs to step forward and volunteer to do so. Otherwise all that
can be done is sit and wait for XFree86.org and/or Tim Robert's to come
out with another new driver that hopefully fixes the problem.
>work, so I can't attach it, nor give much more details) claimed that
>the savage.o driver in RH 9 *is* version 1.1.27
There is no driver version "1.1.27". There is however "1.1.27t" and
"1.1.27mh", the latter of which is in Red Hat Linux 9.
>(I'm not sure of the significance of the 't' on the end of Tim Roberts'
Tim Roberts is the official driver maintainer. His drivers contain the
't' suffix to indicate that they are his driver someone is using in log
The stock XFree86 4.3.0 savage driver is version "1.1.26" and that driver
contains numerous bugs on various savage chips, which were very widely
reported during Red Hat Linux 9 development while we shipped the stock
Tim's 1.1.27t driver was also widely reported to fix _all_ of the bugs
in the savage driver that were discovered during beta testing, and so
when the source code became available, it was integrated into Red Hat
Linux. However, I did not just replace the XFree86 1.1.26 stock driver
with Tim's 1.1.27t driver, I merged Tim's driver into XFree86 in the
same manner that XFree86.org would do so when they merge it into CVS.
Since the resulting driver is not Tim's stock driver because it contains
XFree86.org CVS changes, I changed the version to 1.1.27mh to indicate
"Mike Harris" as I produced the driver. This way it is clear in the log
file, what driver is being used if people change them for whatever reasons.
The resulting driver, 1.1.27mh solved all reported savage driver bugs that
had been reported. Many days later it was reported a single new bug -
the one you are being affected by.
It is not known wether the bug is present strictly in 1.1.27mh, or wether
or not it is also present in a properly compiled and installed 1.1.27t, and
also in 1.1.26. And I don't have savage hardware to find out, which means
someone else needs to test various things out to determine where exactly
the problem is, and then help to narrow it down and try to find a solution.
The problem is being fairly widely reported, but I don't have a lot of time
to dedicate to it. I'll probably look at it again in 1-2 months assuming
someone has tracked down what drivers work and which ones don't, and I have
something to go on.
> Basically, the crux of this, is that there is a bug in the driver in
> Red Hat Linux 9, and in order to determine what it is, someone who has
> the actual hardware physically in front of them and can reproduce the
> problem, and has a strong interest in the problem being fixed, and is
> willing to spend some serious time troubleshooting by testing various
> things needs to step forward and volunteer to do so. Otherwise all that
> can be done is sit and wait for XFree86.org and/or Tim Robert's to come
> out with another new driver that hopefully fixes the problem.
I'm volunteering. Where do you want me to start?
Nothing to say but "ME TOO". every single problem related here happens to me. I
tried the very same steps people here did, and only can get a decent working
machine with the vesa driver.
Via has released their modifications of driver. Take a look at
Follows the mail from tim roberts, the one which made the original driver. It
would be REEEEALLLY nice someone get these working for redhat... In fact, this
one deserves a up2date patch for redhat 8 & 9, wouldn't it?
Well, folks, it appears that my Savage driver is now a LONG ways from the state
of the art. I am no longer "da man".
Unbeknownst to me, VIA/S3 have been quietly bulking up their snapshot of the
Savage driver. Recently, they were persuaded to release their driver to the
world in source form:
I have not tried to compile this yet, but based on a quick perusal of the
source code, it looks like it:
* Supports all of the Savage chips
* Supports video4linux for videoport/zoomvideo
* Supports the Chrontel TV part on ProSavageDDR motherboards
* Supports MPEG motion compensation acceleration (XvMC)
and (drum roll, please):
* Supports DRI and OpenGL
They have made so many changes that it is almost impossible for me to determine
whether all of my recent fixes are in their code, but given the thoroughness I
see in other places, I suspect that they are.
So, if you have the inclination and ability to build from source, it would be
well worth your trouble to give this a try. If you do build binaries for
either 4.2.0 or 4.3.0, let me know and I will announce it to this list.
I am on the savage driver announce mailing list, and have received Tim Roberts
email 2 days ago (along with about 10 copies sent to me from other people).
The VIA savage driver is written for XFree86 4.2.0, and the 3D component of
it is written for Mesa 3.4.x, both of which are incompatible with XFree86 4.3.0.
The driver source needs to be ported to the current XFree86 codebase in order
to be incorporated, and work is underway by XFree86 developers currently to
do just that. The Mesa DRI accelerated drivers need porting to Mesa 4.x and/or
Mesa 5.x, and I'm told by other members of the DRI project that people are
working on this now as well.
Finally, the kernel DRM code needs porting to current Linux 2.4.x and 2.5.x
kernels, as it doesn't compile against current kernels. Someone needs to do
that as well.
I have downloaded the source 2 days ago and examined it as well, and see that
there is a fair amount of work that needs to be done before the driver will
be ready for primetime.
There are already developers in the community working on this, and so there
is no point of Red Hat wasting scarce internal developer resources to duplicate
the efforts already underway by the open source community.
Once the driver has been ported by upstream to the current codebase, and added
to XFree86 CVS officially, I can investigate the feasibility of backporting it
to 4.3.0 and including it in our packages, and I'd like to do that when the
code is ready if possible.
Once that happens however, the kernel DRM module will likely require additional
porting work to work with the Red Hat kernel, as the Red Hat kernel contains
bits and pieces of 2.5.x kernel code which require DRM modifications for DRM
to work properly. That is already part of our kernel for all other drivers,
and the upstream DRM has been modified to handle this already also, for both
2.5.x kernels and the Red Hat (and other distros) kernels. The savage DRM
will need this treatment as well before it is useable/shippable in Red Hat
Since this really is new code and requires a lot of development before
it is end-user ready, it is unlikely to just pop into an erratum release
anytime in the future. Once the code is deemed ready, it will be added
at some point down the road, and tested in unofficial packages to see if
it is suitable to get into rawhide for widespread beta testing. If it
is not ready, then we'll wait until it is included in the next XFree86 release
before considering shipping it. If it turns out to be ok, then we may include
it in a future OS release first, and if that proves stable, future XFree86
updates for current releases we include 4.3.0 in may end up with the new
driver in the long run.
Users who do not want to wait for the proper development cycles to complete
both upstream and internally at Red Hat, and proper beta testing and QA
testing cycles to complete, are welcome to join the XFree86 and DRI projects
and help developers port the code and/or test the experimental driver work
in progress. Your assistance will help to expediate the inclusion of the
driver in future releases.
As an additional info, you may wish to note that Red Hat, and in particular
Alan Cox, was instrumental in helping to convince VIA/S3 to release their
driver as open source, so we are very much interested in including their
driver when the time is appropriate. You'll also notice that I've included
via's "via" driver in our current rawhide for EPIA motherboards with the
Thanks to VIA, we'll be able to have good working mostly fully featured
savage driver with 3D support before long too.
I will update this report with any savage related update info when something
changes. You may want to join firstname.lastname@example.org also to follow progress
as I'll be posting new info there as well.
*** Bug 103534 has been marked as a duplicate of this bug. ***
Any news with Via savage driver? I'm almost selling this motherboard!
Don't sell that mb! Have a look at the Savage mailing list
archives over here:
Read the 'better Driver out there' thread. Via have released
an open source driver to Alan Cox, and if you look at Mike
Harris' post, he's hosting RPMs over at people.redhat.com.
Is this a bug that is ever likely to be fixed in RHEL 3, or is this
significant enough that even if a new driver comes out, Red Hat
can't/won't implement it until RHEL 4? The archives of the savage40
list seem awfully quiet...
My lspci -v output:
01:00.0 VGA compatible controller: S3 Inc. VT8375 [ProSavage8
KM266/KL266] (prog-if 00 [VGA])
Subsystem: FIRST INTERNATIONAL Computer Inc: Unknown device 9012
Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 10
Memory at ed000000 (32-bit, non-prefetchable) [size=512K]
Memory at e0000000 (32-bit, prefetchable) [size=128M]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [dc] Power Management version 2
Capabilities:  AGP version 2.0
> Is this a bug that is ever likely to be fixed in RHEL 3
That depends on wether or not the upstream driver maintainers ever
fix the problem or not. It is not a hardware misdetection issue,
but a driver bug.
I haven't reread all of my comments above to know wether I've
stated this already or not, so I'll state or restate briefly:
We do not have physical access to S3 Savage video hardware, nor
the technical specifications for any S3 Savage hardware, nor any
knowledge of the operation of the hardware. The savage driver
is provided as-is, as shipped upstream by XFree86.org and/or
Tim Roberts (the upstream maintainer), whichever seems to be
the newest and fixes the most problems for people at a given point
in time. In general, we are not able to directly debug problems
other than source code review, which may catch some types of
bugs, but not all. The type of problem described in this report
requires direct physical access to the problem hardware in order
to troubleshoot, and very likely the hardware documenation, which
is not available.
As such, this driver's support is limited to what XFree86.org
and Tim Roberts and the community are able to provide for the most
part. As new drivers and/or upstream fixes become available, I
can and will investigate them for consideration in future driver
updates. Without upstream fixes however, there is little to nothing
that can be done.
>or is this significant enough that even if a new driver comes out,
>Red Hat can't/won't implement it until RHEL 4?
It is not possible to know until fixes are available upstream, or
a new driver is made available. Only once there is something new
upstream available that is known to fix the problem am I able to
review it. Wether that happens before we release new releases of
our OS products or not, I am not in a position to say, as I do
not know when the volunteer developers upstream might investigate
this issue and possibly fix it.
>The archives of the savage40 list seem awfully quiet...
Probably because that mailing list was used solely for Tim Roberts
to post new driver announcements until about a month or two ago
when he changed it into a general purpose savage mailing list.
However, I don't think the majority of people realize it is now
a mailing list for general savage postings.
Since there is more or less nothing whatsoever I can do about this
problem until upstream moves on it, and I am in no position to
control upstream bug fixing timelines, I am defering this issue
until there has been a new XFree86 release known to fix the problem,
a bugfix committed to CVS, or a new Tim Roberts driver for people
Some other less attractive alternatives for people experiencing this
- Obtaining alternative video hardware to use instead, which is
supported better by XFree86
- Purchasing drivers from an alternative vendor such as XiG's
Accelerated-X, Metro-X or some other implementation.
The only other thing I can suggest for now which may accelerate
a solution to this problem sooner, is for one or more of those
experiencing this issue, to report it to XFree86.org and work
with the driver maintainer or other developers directly to
accelerate the likelyhood of fixes becoming available sooner,
with lower levels of indirection involved.
If you'd like me to track your upstream bug, attach the URL to this
report once it is filed upstream, and I will copy myself on it and
Setting bug to DEFERRED state, pending upstream bug fix.
Since this bugzilla report was filed, there have been several major
updates to the X Window System, which may resolve this issue. Users
who have experienced this problem are encouraged to upgrade to the
latest version of Fedora Core, which can be obtained from:
If this issue turns out to still be reproduceable in the latest
version of Fedora Core, please file a bug report in the X.Org
bugzilla located at http://bugs.freedesktop.org in the "xorg"
Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes that
become available for consideration in future updates.
Setting status to "CURRENTRELEASE".