From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021127
Description of problem:
Using a HP Omnibook X3 with an 8meg Savage/MX card and a 15" 1400x1050 lcd
screen. booting into run level 5 works, but the screen is all messed up.
Nothing but the pointer shows up. Moving the mouse gives artifacts of the
pointer but nothing more.
In Starting X with (startx -- :1) will actually start gnome but only to the
point of staring the X server, drawing the background and stopping. Again the
pointer is visible but leaves artifacts. Using Alt+F1 or Alt+F2 does draw a box
but it is empty.
At the gdmgreeter screen if you type a username and password (and happen to know
what the screen is supposed to look like) you can "log in" but that gives you
the same as running startx.
I can navigate with Ctrl+Alt+Fkey and get to tty's.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install on OmniBook X3
2. Boot up
Actual Results: Garbage on screen, X won't start
Expected Results: Get gnome desktop
This appears to be because of a missing XFree86 link? It is a flashing red file
that doesn't say what it is supposed to be linked to.
This doesn't look like a firstboot problem. Maybe something is wrong with X?
mharris, have you seen this problem before?
It is in fact a problem with X and not firstboot. That was merely the first
time I'd tried it. I have tested by just starting X and it fails. It should be
noted that when installed /usr/X11/bin/X is a symlink to /usr/bin/X11/XFree86
which is a link (I think a hard link) to a non-existent thing. It is red at any
rate though not flashing like a broken symlink.
I can start X and it gives no apparent failure but does not load properly. I
hope there is more that I can do.
Created attachment 88921 [details]
/var/log/XFree86.0.log, XF86Config, /var/log/messages and strace of X Startup
The XF86Config.new was generated with XFree86 -configure as the one that came
out of the box didn't work at all, saying there were no screens. I should note
that there are errors trying to get the sync's from my monitor (I've just noted
this happening) and this could also be the issue.
If the X symlink is not properly set up, then that is definitely not
an XFree86 problem. It is the responsibility of the configuration tool
to point the X symlink to the XFree86 X server. For new installs,
the X symlink should point to XFree86, and for upgrades, the installer
should *force* the symlink to point to the XFree86 4.x server, and
should also force an X reconfiguration, because if the user was using
a 3.3.6 server before, their 3.3.6 server will have been uninstalled
during upgrade as 4.x now obsoletes 3.3.6, and yet their configuration
will remain for 3.3.6. That leaves a user without an X server, with
the symlink pointing to the wrong X server (which doesn't exist anymore),
and a non-working setup.
Definitely not an X server bug.
Ugh. When attaching log files, please attach one file per attachment,
and do so uncompressed also. I have to download these and decompress
them in order to view them, which is much more inconvenient than clicking
on them in mozilla.
You are also using a non Red Hat kernel, which means unsupported platform.
Red Hat does not support SGI kernels. Red Hat supports Red Hat, and only
Red Hat kernels.
I have my boss who is using a laptop with that same chipset. He upgraded
to the Phoebe Beta as I gave him the CDs yesterday and he was having the same
problem : on launch, the cursor was not removed when moving it, and it did not
work. I use XFree -config to create a new XF86Config but this did not gave
results good enough. So I went farther : I tried various options of the savage
driver, using its man page as reference. Found it : if you turn Accel off, it
works fine. At first I had tried to disable the BIOS (check savage man page
about that and why) but this option :
Option "NoAccel" "true"
Solved it. X launches normally and works fine, the new Red Hat 8.0.9 desktop
loads. This is not a installation procedure problem but a problem with the
savage driver who requires a NoAccel when used on a SAVAGE/MX chip.
Contact me if you need more information, or a copy of our working XF86Config.
Long life Red Hat !
Something else. A X shaped cursor kept appearing in the middle of the screen.
Since it's a laptop with two mouses (one internal to the laptop, and another one
connected on the USB port) I thought the first X-shaped one was coming from the
internal mouse, but it seems not. Checking again the savage man page shows the
savage forces a hardware cursor per default, so I added this to the previous
NoAccel option :
Option "HWCursor" "false"
That damn X-shaped cursor is gone :-)
To the first poster about that bug : can you try NoAccel and tell us what
happens, and if so, do you also get that hardware cursor stuck in the middle of
the screen ?
Sorry about the attachment issue. The reason for the SGI kernel is to get stuff
off of my 8.0 partition. It had no bearing whatsoever on the X issue as the
same thing happened with the RedHat kernel.
The link problem seems not to be the cause here as it is still red and yet I can
start X. The NoAccel issue was the cause, though now I have a 640x480 screen
that flickers madly and is all of 8 bits of color. But, I think I can go from
there. The hardware mouse was showing up, and turning off the hardware mouse
solved it. It looks as though, NoAccel was the issue afterall.
So Chris, how do you want to proceed on this report?
At the moment there is a workaround (turn off hwaccel and hardware cursor
manually) but those are hardly end user kind of changes as the only tool I've
found to do them is a text editor.
Problem does seem resolved after that though.
I don't see a good way to expose this to the user in the UI though. It won't be
clear to anybody that you need to click the "Disable Hardware Acceleration" and
"Disable Hardware Cursor" checkboxes to make the video card work.
It seems to me that either the Savage driver is broken or the hardware itself is
buggy beyond all hope. In either case, I think trying to fix this in the config
tool is treating the symptom and not the actual problem.
I will transfer this bug to mharris who may be able to tell if this is a driver
problem or a hardware problem.
As it's more than just me that seems to have exhibited this issue I doubt that
it's my peice of hardware.
It is probably a driver issue, and I'll treat it as such.
Please test Phoebe beta 2 and let me know if it works or not.
This is still identical in phoebe 2 as it was in phoebe 1, at least for me. I
did an upgrade, ran XFree86 -configure and it still tried to run in accelerated
mode. I modified the XF86Config to turn of acceleration and all was well.
Ok, that was nice and quick. ;o)
Can you look at bug #82394 as I think this issue and that one are identical.
Chris, you could try using Tim's 1.1.27 driver with your 4.2.99.xxxx XFree86,
it's a simple install really (bug #82394 contains pointer and installation
See link to New Savage driver in 82394. This issue is resolved in the new
version and the speed issues I was having with Phoebe are gone.
Thanks to all.
Fantastic. I'll investigate updating the driver in part or in full,
once Tim believes it to be stable and updates the website with changelog
and new driver sources.
*** Bug 82394 has been marked as a duplicate of this bug. ***
*** Bug 72476 has been marked as a duplicate of this bug. ***
The new 1.1.27t driver indeed resumes native mode acceleration on S3 Inc.
86C270-294 Savage/IX-MV (rev 13). The only quirk still left is the need for
"swcursor", without it the X cursor still occasionally appears (and later at
some seemingly random point disappears).
And yes, I believe #80423 is a duplicate of this one.
This bug looks very much like the #80423 one...
However in my case, on Phoebe .93 i am unable to wourk around the problem using
Option "noaccel" "true" - The only thing that works for me is switching to vesa
My problem, to a large extent is the fact that the entire image is flickering
just like an old TV set with a really bad antenna... The system is usable enough
wor work around in though!
I tried the updated .27t driver and that wouldn't run on the Phoebe .93
(Unresolved symbol in libvbe.a), so I can't really comment on the results of that
please excuse the messy wording on that last post from me. If you need me to
clear anything up, please let me know :(
Oh.. for the record I'm using XFree86-22.214.171.124-20030121.0 from rawhide with the
new savage driver (which works nicely, except for the swcursor thingy)
Installation instructions for the 1.27 driver are:
Download (see 82394 for link) the driver.
cp savage_drv.o /usr/X11R6/lib/modules/drivers
cp libvbe.a /usr/X11R6/lib/modules
cp libint10.a /usr/X11R6/lib/modules
cp libint10.a /usr/X11R6/lib/modules/linux
Those steps allowed me to remove the "NoAccel True" line from my XF86Config file
and have accelerated X.
Thanks for the guidance...
I forgot to update /usr/X11R6/lib/modules/linux/libint10.a
After having updated all the file where they needed to be updated with the .27t
version of the savage driver, X started fine and... Flicker and strange
behaviour gone on my system! Everything looks nice!
*** Bug 80423 has been marked as a duplicate of this bug. ***
Things are looking good. Now I just need the driver source code....
Patience is a virtue however. ;o)
This is the only thing keeping me from testing the new beta.
Changing the bug alias of this bug from "savage" to "savagemx" to remove
namespace pollution and allow the "savage" alias to be used for an alternate
It looks like this problem is not going to get fixed before 4.3.0
unfortunately. I have contacted the Savage driver maintainer nonetheless,
and told him that his driver 1.1.27t indeed is reported by you all as fixing
the Savage MX problems.
I've been watching his website almost daily awaiting the updated driver
source code, and can only assume that the driver has a glitch in it that
he is investigating prior to making an official updated driver release.
At this point, I am unable to do anything further about this problem
until the updated driver source code is publically available to me, so
this problem may not get fixed in XFree86 4.3.0. When fixes are
publically available, at some point I will investigate integrating them
into the distribution.
For now though, I'm closing the bug as awaiting UPSTREAM fix.
*** Bug 80278 has been marked as a duplicate of this bug. ***
I have obtained the source code of the 1.1.27t driver from Tim Roberts, and
am integrating it for a build soon. I will require each of you to test
the new driver extensively. Please test it in as many video modes, and
depths as possible, and with video, etc. It is critically important that
you test the heck out of the new driver, as I need to know as soon as
possible if there are any regressions in 1.1.27t compared to 1.1.26t which
is the current driver. I don't have any savage hardware personally, so
I can't test it myself.
I'll update this report when the new driver is available for download.
Where can we get this new driver? I downloaded the binary from Tim's site last
week and it seems to work fine so far, but I haven't tested it much.
The new driver is in XFree86-126.96.36.1992-20030218.0 in rawhide and
Please everyone upgrade to this ASAP and test it, and provide feedback.
Make sure your config file is using the savage driver, and not vesa.
Works like a charm for me
Um, something fishy going on here. The XFree-package from your testing-directory
tells me this:
XFree86 Version 188.8.131.522 (4.3.0 RC 2) (Red Hat Linux release:
Release Date: 17 February 2003
(II) SAVAGE: driver (version 1.1.26) for S3 Savage chipsets: Savage4,
Note the version 1.1.26! This is just as hosed for me as it was before (Savage
IX-MV) but dropping the binary version of 1.1.27t cures the situation as before.
I'll have to back comment #38... Thats exactly what i would have written here,
if not Panu had beat me to it :)
Mike, this new package also does NOT fix the problem for my SavageIX/MX in my
IBM T20. Same problem as before.
Ugh, I suck.
I added the driver, and rebuilt, but I did not toggle the WithNewSavageDriver
flag in rpm, so it got the old driver. Duh.
0218.2 release has this fixed. Sorry for the goofup.
Please test ASAP
where can I find "0218.2 release" ?
After another goofup, this one really really really has the new savage
driver. To be clear though, I'm not claiming it fixes the problems, just
that I want you all to test it and tell me, and to do so ASAP. It's on
No improvement with the latest package either. Looking at diffs of the
XFree-logs compared to Tims binary driver the problem seems to be that your
version doesn't detect VESA BIOS at all (the lines with + mean XFree with the
- compiled for 184.108.40.2062, module version = 1.1.0
- ABI class: XFree86 Video Driver, version 0.6
+ compiled for 4.2.0, module version = 1.0.0
+ ABI class: XFree86 Video Driver, version 0.5
+(II) SAVAGE(0): VESA BIOS detected
+(II) SAVAGE(0): VESA VBE Version 2.0
+(II) SAVAGE(0): VESA VBE Total Mem: 8192 kB
+(II) SAVAGE(0): VESA VBE OEM: S3 Incorporated. M7 BIOS
+(II) SAVAGE(0): VESA VBE OEM Software Rev: 1.0
+(II) SAVAGE(0): VESA VBE OEM Vendor: S3 Incorporated.
+(II) SAVAGE(0): VESA VBE OEM Product: VBE 2.0
+(II) SAVAGE(0): VESA VBE OEM Product Rev: Rev 1.1
(--) SAVAGE(0): Chip: id 8c12, "Savage/IX-MV"
(--) SAVAGE(0): Engine: "MobileSavage"
(--) SAVAGE(0): mapping MMIO @ 0xf1000000 with size 0x80000
@@ -357,7 +366,7 @@
(--) SAVAGE(0): - Limiting video mode to 1024x768
(II) SAVAGE(0): Monitor0: Using hsync range of 31.50-48.50 kHz
(II) SAVAGE(0): Monitor0: Using vrefresh range of 40.00-70.00 Hz
-(II) SAVAGE(0): Clock range: 10.00 to 220.00 MHz
+(II) SAVAGE(0): Clock range: 10.00 to 250.00 MHz
 0 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU)
+(II) Loading sub module "int10"
+(II) LoadModule: "int10"
+(II) Reloading /usr/X11R6/lib/modules/linux/libint10.a
+(II) SAVAGE(0): initializing int10
+(II) SAVAGE(0): Primary V_BIOS segment is: 0xc000
(II) SAVAGE(0): VESA BIOS detected
-(II) SAVAGE(0): Using 1247 lines for offscreen memory.
+(--) SAVAGE(0): Chose mode 117 at 60Hz.
+(II) SAVAGE(0): Using 1279 lines for offscreen memory.
read the following comment:
The 218.3 has the updated driver alright, or at least 1.1.27mh is reported as
the driver version - However the functionality of the driver is just the same as
the previous ones. this one is not good either! :-(
Ok, perfect. This confirms my suspicion that XFree86.org changes to Tim's
stock drivers break the driver. 1.1.26t stock works, 1.1.26 does not,
1.1.27t stock works, 1.1.27mh does not.
1.1.27mh is Tim's 1.1.27 plus the differences between 1.1.26t and 1.1.26
ported forward as they'd be if XFree86.org were to commit 1.1.27t to CVS
tomorrow and call it 1.1.27.
You guys have good eyes with spotting the VESA VBE stuff as I think I found
the problem in the patch from 1.1.26t->1.1.26 now where a VBE call got moved
I don't know what the correct fix is, but I suspect undoing that one change
should fix things.
My next build will do just that.
dkl has just confirmed my latest driver fixes this problem for him. The
vbe change I suspected above was in fact the culprit here.
The change went into X CVS on Dec 16th:
Date: Mon, 16 Dec 2002 01:38:54 -0800 (PST)
From: Alan Hourihane <alanh@XFree86.Org>
List-Id: CVS commit messages from the XFree86 repository
Subject: CVS Update: xc (branch: trunk)
Module name: xc
Changes by: email@example.com. 02/12/16 01:38:27
no need to softboot twice, reduces startup time
Revision Changes Path
1.30 +2 -3
This new driver is available for download at:
It will appear in rawhide, in build: XFree86-220.127.116.112-20030220.1
Changing bug to MODIFIED pending individual testing results.
the new driver works.
in 24 bit mode it gives some fuzzy artifacts when I move my mouse.
after i switch to 16 bit mode the artifacts are gone.
I also am seeing the fuzzy color artifacts on solid color backgrounds when using
24bit mode. Changing to 16 bit is fine. I have seen this before when running
high color with older drivers so it is not a regression with me and thought may
be a hardware problem.
i have also seen the fuzziness with the older versions of the driver.
so this fuzziness is not new. but the 1.1.27t driver downloaded from Tim's
webpage was not giving any fuzziness.
anyways i think we should keep this driver, just set 16 bit color depth by
default during the installation. ( right now it sets 24 bits by default ).
I'm NOT getting fuzziness and NOT getting fragments with the latest savage_drv.o
I AM running 24 bit (1024x768) and it's looking great here!
Ok, thanks guys. I consider this particular bug fixed now and am closing
it as RAWHIDE. The "fuzziness issue" you are describing is not part of
this bug, so please one of you experiencing the bug file a new bug report
in bugzilla for the fuzzy thing, and we'll tackle that one separately.
If Tim's driver did not fuzz out, then it is possible one of the other
XFree86.org changes has fuzzed up the driver once again. ;o)
Again, please file a separate report, and we'll go from there.
Closing as fixed in RAWHIDE
i have upgraded to rawhide version of XFree ( 18.104.22.1682-20030220.1 ).
and the fuzziness issues are gone for all resolutions and color depths.
the screen resizing (via xrandr ) also works beautifully.
there is no need to restrict the color depth of Savage cards to 16 bits at the
Created attachment 90352 [details]
XFree86 current log
OK, I am currently running XFree 22.214.171.1242-20030220.1 on a Toshiba Tecra 8100
(850 PIII) using the Savaga MX chipset; 512MB RAM. O/S is Phoebe 8.0.93, kernel
is 2.4.20-2.54 from Rawhide with /vga=791 in grub.conf. Default depth and
resolution is 1024x768, 16-bit (from redhat-config-xfree86)
(--) SAVAGE(0): Chip: id 8c10, "Savage/MX-MV"
(--) SAVAGE(0): Engine: "MobileSavage"
(--) SAVAGE(0): mapping MMIO @ 0xf1000000 with size 0x80000
(==) SAVAGE(0): Using gamma correction (1.0, 1.0, 1.0)
(**) SAVAGE(0): videoram = 8192k
Every so often, my mouse cursor turns to a 1" square with black and white
garbage in it. Seems to happen most often when scrolling (at least within
Mozilla 1.2.1). Scroll with the Microsoft Intellimouse Optical USB connected to
the Toshiba USB port seems to do it as well as clicking on the scroll bar and
dragging a few times.
Note, the previous XFree86 RPMs 126.96.36.1992-20030218.1 didn't do it for me - I
still had to revert to vesa driver instead of savage.
This issue is resolved and closed. If you've got a problem with the
current XFree86 package:
.... then please open a new bug report and explain the problem in
detail, with logs, configs, etc.
*** Bug 85858 has been marked as a duplicate of this bug. ***