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 driver. redhat-config-xfree86 attempts to load X right away and this fails. This works: redhat-config-xfree86 --set-driver=vesa 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): XFree86-4.3.0-2 How reproducible: Always Steps to Reproduce: 1.Install Red Hat Linux 9 in graphics or 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 Additional info:
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 the problem. 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 problem down. Please backup your current working "vesa" config file, and run: redhat-config-xfree86 --reconfig 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: Option "noaccel" 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. Thanks.
If I start without an XF86Config file and do: redhat-config-xfree86 --reconfig 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 XFree86.setup.log created from: redhat-config-xfree86 --reconfig 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 with.
Created attachment 90942 [details] XF86Config file from a failure This is also from a failure using the savage driver. I have tested the following combinations: 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 Option "ForceInit" 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' >latest version). 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 files. 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 driver. 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 http://probo.probo.com/pipermail/savage40/2003-July/000038.html 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: http://www.linux.org.uk/~alan/S3.zip 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 Linux. 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 Castlerock video. 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 xfree86-list also to follow progress as I'll be posting new info there as well. Thanks.
*** Bug 103534 has been marked as a duplicate of this bug. ***
Any news with Via savage driver? I'm almost selling this motherboard!
Alexandre, Don't sell that mb! Have a look at the Savage mailing list archives over here: http://probo.probo.com/pipermail/savage40/2003-July/thread.html 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: [80] 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 to test. Some other less attractive alternatives for people experiencing this problem include: - 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 monitor it. 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: http://fedora.redhat.com/download 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" component. 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".