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:
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. Chris Tooley
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.
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.
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 !
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. Thank you.
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 instructions)
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 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
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-4.2.99.4-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. 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.
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 purpose.
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-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.
Works like a charm for me
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.
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 my ftpsite. XFree86-4.2.99.902-20030218.3
ftp://people.redhat.com/mharris/testing/unstable/XFree86/4.2.99.902-20030218.3
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.
read the following comment: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=82394#c8
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 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.
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> To: cvs-commit 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.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.
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 driver installed! 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 ( 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.
Created attachment 90352 [details] XFree86 current log
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.
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.
Yep, resolved! Thanks.
*** Bug 85858 has been marked as a duplicate of this bug. ***