Bug 119462 - X-Windows will not run @ 1400x1050 (savage driver)
X-Windows will not run @ 1400x1050 (savage driver)
Status: CLOSED DUPLICATE of bug 118205
Product: Fedora
Classification: Fedora
Component: XFree86 (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Mike A. Harris
Depends On:
  Show dependency treegraph
Reported: 2004-03-30 13:55 EST by Scott Archer
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 14:02:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
X1msgs (5.61 KB, text/plain)
2004-03-30 14:05 EST, Scott Archer
no flags Details
XF86Config (2.67 KB, text/plain)
2004-03-30 14:05 EST, Scott Archer
no flags Details
Xfree86.0.log (92.16 KB, text/plain)
2004-03-30 14:06 EST, Scott Archer
no flags Details
Bzip2 tarball of XFree86.0.logs, XF86Configs and kernel boot params (17.64 KB, application/octet-stream)
2004-04-08 17:13 EDT, David Carrigan
no flags Details

  None (edit)
Description Scott Archer 2004-03-30 13:55:16 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6)
Gecko/20040206 Firefox/0.8

Description of problem:
I have an IBM Thinkpad T23.
X-Windows worked fine in fedora core 1, however in fedora core 2 test
2 I cannot get X Windows to work at a resolution higher than 1024x768
with the savage driver.

I tried a working XF86Config from when I had gentoo installed and It
did not work with that config either. It does work @ 1024x768 but the
LCD's native resolution is 1400x1050.

At first I upgraded from Fedora Core 1 then after I failed to get X
Windows working I did a fresh install of Fedora Core 2 Test 2 (i had
to boot into rescue and change the XF86Config so that i could go
through the wizzard that sets up your computer after the initial install)

I got X Windows to come up using the 'vesa' driver but It caused other
problems when I tried switching from X back to the console (never got
video back in the console)

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Buy an IBM T23 that runs with an lcd native @ 1400x1050
2.Install Fedora Core 2 Test 2

Actual Results:  X Windows started but I saw a blue background on
about 1/3 of the screen the rest of the screen is black.

Expected Results:  X Windows starts and I see the Fedora Background
and everything works :)

Additional info:

I see this on my screen when X starts

(EE) SAVAGE(0): vm86() syscall generated signal 11.
(EE)SAVAGE(0): Failed to fetch any BIOS modes. Disabling BIOS.
/etc/X11/xinit/xinitrc: line 25: [: missing `]'

I see that first line over & over and then the lines under it.
Comment 1 Scott Archer 2004-03-30 14:05:20 EST
Created attachment 98975 [details]
Comment 2 Scott Archer 2004-03-30 14:05:50 EST
Created attachment 98976 [details]
Comment 3 Scott Archer 2004-03-30 14:06:20 EST
Created attachment 98977 [details]
Comment 4 David Carrigan 2004-04-02 23:07:09 EST
I too have the same hardware, and a similar issue with the Xorg server
and savage driver.

In addition to earlier comments, I have also tried disabling DRI
(by commenting the "Load dri" entry in XF86Config), and also
using the vesa driver (kernel bootloader option "video=vesa", and
also the old "video=vesa,mtrr,ywrap" with the "Driver vesafb").

While with the vesa driver I *do* get 1400x1050 dimensions, when
exiting X11, the system hangs. That is whether I switch to a virtual
console, or merely "Log Out."

I also loaded the kernel with pci=noapci, apci=off, AND noacpi in
favor of the use of apmd. These attempts are in response to some
reports that IBM TPs don't do this well, and IRQ conflicts may
arise. This was all for nought... the video driver is still

I also consulted the old Savage40 website for additional info,
but the author--and author of savage 1.27--has not updated this
page in a long while.

Again: in RHL 9, RHEL3 and FC1 this driver performed well, despite
the lack of DRI capability. I have not built the CVS DRI module
avialable curently as I have no real need for it... or maybe I(we)
do? URL for the CVS code I found is:


Comment 5 David Carrigan 2004-04-08 17:13:12 EDT
Created attachment 99249 [details]
Bzip2 tarball of XFree86.0.logs, XF86Configs and kernel boot params

After re-reading my post, I decided you might want more info. The attached
tarball contains logs for three different video drivers (savage, vesa and
for one bit depth(16), and two dimensions(1400x1050 & 1024x768... 14x10 & 10x7
as named in the files). Constants are: bit depth, the LCDClock option(which
gives us a little more legible 1400x1050 w/the savage driver) and UseBIOS
Also, the savage driver behaves the same with/without the "vga=" and "video=" 
kernel boot parameters. "Screen Expansion"(sic) on the T23 is disabled.


   savage driver produces a good and stable display for 10x7, but a jittery
	  7/8 screen fill for 14x10. Not useful @ 10x7 really... it's a screen
	  the size of 10x8 inches.

   fbdev driver produces good and stable displays always. Thanks to a 1GHz CPU,

	 the redraw is OK. This is what I now use to simply work with this

   vesa driver is useless. Yes, the displays are good and stable, but this
	driver renders the system not useful on logout, or switch to vt...
	one must always remove power to the system to un(dead)lock the video
	resources... not so good for data protection ;)

RPM versions:


lspci -v for the v-card:

01:00.0 VGA compatible controller: S3 Inc. SuperSavage IX/C SDR (rev 05)
(prog-if 00 [VGA])
	Subsystem: IBM ThinkPad T23 (2647-4MG)
	Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 11
	Memory at c0100000 (32-bit, non-prefetchable)
	Memory at e8000000 (32-bit, prefetchable) [size=64M]
	Memory at e4000000 (32-bit, prefetchable) [size=64M]
	Memory at e0000000 (32-bit, prefetchable) [size=32M]
	Capabilities: [dc] Power Management version 2
	Capabilities: [80] AGP version 2.0

Hope this helps a bit more.
Comment 6 Ling Li 2004-04-14 20:06:36 EDT
Do you think this is similar to bug #118205? Try kernel 2.6.5-1.308 to
see if it works for you.
Comment 7 David Carrigan 2004-04-15 01:37:47 EDT
Kernels 2.6.5-1-{305,308,319} all exhibit the same (poor)
behavior. Thanks for the catch on BUG


as I installed Warren's 2.6.5-1.322.disabled4G.i686 and, well 
WOW, this kernel works (with the savage. not tried vesa). 
Will mark this bug as "duplicate" of 118205 (kernel).

NB-The "default" H & V sync/refresh of 70 & 90 respectively were
NOT used. Below are the values used for a super stable, full screen
        HorizSync    30.0 - 110
        VertRefresh  50.0 - 160
(I got them from a list posting claiming that LCD's cannot be as
easily thrown out of whack than CRTs. FWIW, xvidtune reported my
stable image @ HSync 94 and VRefresh 86 @ 1400x1050)

From /var/log/XFree86.0.log:
(--) PCI:*(1:0:0) S3 Inc. SuperSavage IX/C SDR rev 5, Mem @
0xc0100000/19, 0xe80
00000/26, 0xe4000000/26, 0xe0000000/25
(II) LoadModule: "savage"
(II) Loading /usr/X11R6/lib/modules/drivers/savage_drv.o
(II) Module savage: vendor="The XFree86 Project"
(II) SAVAGE: driver (version 1.1.27) for S3 Savage chipsets: Savage4,
        Savage3D, Savage3D-MV, Savage2000, Savage/MX-MV, Savage/MX,
        Savage/IX-MV, Savage/IX, ProSavage PM133, ProSavage KM133,
        ProSavage PN133, ProSavage KN133, SuperSavage/MX 128,
        SuperSavage/MX 64, SuperSavage/MX 64C, SuperSavage/IX 128,
        SuperSavage/IX 128, SuperSavage/IX 64, SuperSavage/IX 64,
        SuperSavage/IXC 64, SuperSavage/IXC 64, ProSavage DDR,
        ProSavage DDR-K
(--) Chipset SuperSavage found
(**) SAVAGE(0): Depth 16, (--) framebuffer bpp 16
(==) SAVAGE(0): RGB weight 565
(==) SAVAGE(0): Default visual is TrueColor
(II) SAVAGE(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset
is 0x0000
(==) SAVAGE(0): Using HW cursor
(==) SAVAGE(0): Using video BIOS to set modes
(II) SAVAGE(0): Primary V_BIOS segment is: 0xc000
(II) SAVAGE(0): VESA BIOS detected
(II) SAVAGE(0): VESA VBE Version 2.0
(II) SAVAGE(0): VESA VBE Total Mem: 15168 kB
(II) SAVAGE(0): VESA VBE OEM: S3 Incorporated. Paramont 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.0
(--) SAVAGE(0): Chip: id 8c2e, "SuperSavage/IXC 64"
(--) SAVAGE(0): Engine: "SuperSavage"


*** This bug has been marked as a duplicate of 118205 ***
Comment 8 Red Hat Bugzilla 2006-02-21 14:02:16 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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