Bug 80346 - (savagemx) S3 Savage/MX Problems
S3 Savage/MX Problems
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
8.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
: MoveUpstream
: 72476 80278 80423 82394 85858 (view as bug list)
Depends On:
Blocks: 79579 82788
  Show dependency treegraph
 
Reported: 2002-12-24 15:16 EST by Chris Tooley
Modified: 2007-04-18 12:49 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-02-21 18:35:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
log,config,strace (153.39 KB, application/octet-stream)
2002-12-26 15:10 EST, Chris Tooley
no flags Details
XFree86 current log (32.59 KB, text/plain)
2003-02-25 11:03 EST, Andrew
no flags Details

  None (edit)
Description Chris Tooley 2002-12-24 15:16:23 EST
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):


How reproducible:
Always

Steps to Reproduce:
1.  Install on OmniBook X3
2.  Boot up
3.
    

Actual Results:  Garbage on screen, X won't start

Expected Results:  Get gnome desktop

Additional info:
Comment 1 Chris Tooley 2002-12-24 17:03:01 EST
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.
Comment 2 Brent Fox 2002-12-26 11:30:34 EST
This doesn't look like a firstboot problem.  Maybe something is wrong with X? 
mharris, have you seen this problem before?
Comment 3 Chris Tooley 2002-12-26 11:41:15 EST
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.

Chris Tooley
Comment 4 Chris Tooley 2002-12-26 15:10:26 EST
Created attachment 88921 [details]
log,config,strace

/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.
Comment 5 Mike A. Harris 2002-12-26 22:42:36 EST
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.
Comment 6 Mike A. Harris 2002-12-26 22:44:40 EST
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.
Comment 7 Gilbert Fernandes 2002-12-27 05:24:47 EST
Hello all.

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 !
Comment 8 Gilbert Fernandes 2002-12-27 06:14:02 EST
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 ?
Comment 9 Chris Tooley 2002-12-27 08:51:31 EST
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.

Thank you.
Comment 10 Brent Fox 2003-01-06 01:15:26 EST
So Chris, how do you want to proceed on this report?
Comment 11 Chris Tooley 2003-01-06 09:33:39 EST
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.
Comment 12 Brent Fox 2003-01-06 14:36:42 EST
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.
Comment 13 Chris Tooley 2003-01-06 20:31:00 EST
As it's more than just me that seems to have exhibited this issue I doubt that
it's my peice of hardware.
Comment 14 Mike A. Harris 2003-01-23 07:32:42 EST
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.
Comment 15 Chris Tooley 2003-01-23 08:10:33 EST
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.
Comment 16 Mike A. Harris 2003-01-23 08:33:22 EST
Ok, that was nice and quick.  ;o)

Can you look at bug #82394 as I think this issue and that one are identical.
Comment 17 Kaj J. Niemi 2003-01-23 10:25:57 EST
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
instructions)

Comment 18 Chris Tooley 2003-01-23 14:22:53 EST
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.
Comment 19 Mike A. Harris 2003-01-23 23:47:10 EST
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.
Comment 20 Mike A. Harris 2003-01-24 01:06:46 EST
*** Bug 82394 has been marked as a duplicate of this bug. ***
Comment 21 Mike A. Harris 2003-01-24 02:10:29 EST
*** Bug 72476 has been marked as a duplicate of this bug. ***
Comment 22 Panu Matilainen 2003-01-24 02:33:00 EST
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.
Comment 23 Thomas M Steenholdt 2003-01-24 05:05:24 EST
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
driver.
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

Comment 24 Thomas M Steenholdt 2003-01-24 05:07:59 EST
please excuse the messy wording on that last post from me. If you need me to
clear anything up, please let me know :(
Comment 25 Panu Matilainen 2003-01-24 05:18:06 EST
Oh.. for the record I'm using XFree86-4.2.99.4-20030121.0 from rawhide with the
new savage driver (which works nicely, except for the swcursor thingy)
Comment 26 Chris Tooley 2003-01-24 08:49:21 EST
Installation instructions for the 1.27 driver are:

Download (see 82394 for link) the driver.

Untar
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.
Comment 27 Thomas M Steenholdt 2003-01-24 14:56:38 EST
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!
Comment 28 Mike A. Harris 2003-01-24 15:35:51 EST
*** Bug 80423 has been marked as a duplicate of this bug. ***
Comment 29 Mike A. Harris 2003-01-24 15:45:16 EST
Things are looking good.  Now I just need the driver source code....
Patience is a virtue however.  ;o)
Comment 30 Chris Parker 2003-01-24 15:46:44 EST
This is the only thing keeping me from testing the new beta.
Comment 31 Mike A. Harris 2003-01-26 03:17:22 EST
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
purpose.
Comment 32 Mike A. Harris 2003-02-05 03:07:51 EST
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.
Comment 33 Mike A. Harris 2003-02-13 06:34:18 EST
*** Bug 80278 has been marked as a duplicate of this bug. ***
Comment 34 Mike A. Harris 2003-02-17 15:19:12 EST
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.
Comment 35 Pete Toscano 2003-02-18 10:48:14 EST
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.  
Comment 36 Mike A. Harris 2003-02-19 22:12:08 EST
The new driver is in XFree86-4.2.99.902-20030218.0 in rawhide and
on ftp://people.redhat.com/mharris/testing/unstable

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.
Comment 37 Dumitru Ciobarcianu 2003-02-20 02:24:27 EST
Works like a charm for me
Comment 38 Panu Matilainen 2003-02-20 03:50:44 EST
Um, something fishy going on here. The XFree-package from your testing-directory
tells me this:
XFree86 Version 4.2.99.902 (4.3.0 RC 2) (Red Hat Linux release:
4.2.99.902-20030218.0)
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.

Comment 39 Thomas M Steenholdt 2003-02-20 08:58:22 EST
I'll have to back comment #38... Thats exactly what i would have written here,
if not Panu had beat me to it :)
Comment 40 David Lawrence 2003-02-20 14:26:11 EST
Mike, this new package also does NOT fix the problem for my SavageIX/MX in my
IBM T20. Same problem as before.
Comment 41 Mike A. Harris 2003-02-20 16:03:42 EST
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
Comment 42 petrosyan 2003-02-20 16:30:05 EST
where can I find "0218.2 release" ?
Comment 43 Mike A. Harris 2003-02-21 08:02:48 EST
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
my ftpsite.

XFree86-4.2.99.902-20030218.3
Comment 45 Panu Matilainen 2003-02-21 12:23:04 EST
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
binary driver):

-       compiled for 4.2.99.902, 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
....
        [23] 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.
Comment 46 petrosyan 2003-02-21 12:58:30 EST
read the following comment:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=82394#c8
Comment 47 Thomas M Steenholdt 2003-02-21 13:42:57 EST
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! :-(
Comment 48 Mike A. Harris 2003-02-21 13:59:15 EST
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
gratuitously.

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.
Comment 49 Mike A. Harris 2003-02-21 15:29:35 EST
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>
To: cvs-commit@XFree86.Org
List-Id: CVS commit messages from the XFree86 repository
    <cvs-commit.XFree86.Org>
Subject: CVS Update: xc (branch: trunk)
 
CVSROOT:        /home/x-cvs
Module name:    xc
Changes by:     alanh@public.xfree86.org.       02/12/16 01:38:27
 
Log message:
  no need to softboot twice, reduces startup time
 
Modified files:
      xc/programs/Xserver/hw/xfree86/drivers/savage/:
        savage_driver.c
 
  Revision      Changes    Path
  1.30          +2 -3     
xc/programs/Xserver/hw/xfree86/drivers/savage/savage_driver.c



This new driver is available for download at:
    ftp://people.redhat.com/mharris/savage_drv.o


It will appear in rawhide, in build:  XFree86-4.2.99.902-20030220.1

Changing bug to MODIFIED pending individual testing results.
Comment 50 petrosyan 2003-02-21 16:11:01 EST
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.
Comment 51 David Lawrence 2003-02-21 16:15:43 EST
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.
Comment 52 petrosyan 2003-02-21 16:26:39 EST
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.
Comment 53 petrosyan 2003-02-21 16:29:36 EST
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 ).
Comment 54 Thomas M Steenholdt 2003-02-21 16:35:36 EST
I'm NOT getting fuzziness and NOT getting fragments with the latest savage_drv.o
driver installed!
I AM running 24 bit (1024x768) and it's looking great here!
Comment 55 Mike A. Harris 2003-02-21 18:35:22 EST
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
Comment 56 petrosyan 2003-02-23 21:28:11 EST
i have upgraded to rawhide version of XFree ( 4.2.99.902-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
installation.
Comment 57 Andrew 2003-02-25 11:03:17 EST
Created attachment 90352 [details]
XFree86 current log
Comment 58 Andrew 2003-02-25 11:04:51 EST
OK, I am currently running XFree 4.2.99.902-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)

/var/log/XFree86.0.log says:
(--) 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 4.2.99.902-20030218.1 didn't do it for me - I
still had to revert to vesa driver instead of savage.
Comment 59 Mike A. Harris 2003-02-25 12:20:27 EST
This issue is resolved and closed.  If you've got a problem with the
current XFree86 package:

  ftp://people.redhat.com/mharris/testing/unstable/XFree86/4.2.99.902-20030224.1

....  then please open a new bug report and explain the problem in
detail, with logs, configs, etc.

Thanks.
Comment 60 Andrew 2003-02-25 13:24:56 EST
Yep, resolved!

Thanks.
Comment 61 Mike A. Harris 2003-03-12 10:29:57 EST
*** Bug 85858 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.