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: Always Steps to Reproduce: 1.Buy an IBM T23 that runs with an lcd native @ 1400x1050 2.Install Fedora Core 2 Test 2 3. 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.
Created attachment 98975 [details] X1msgs
Created attachment 98976 [details] XF86Config
Created attachment 98977 [details] Xfree86.0.log
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 wonky. 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: http://www.freedesktop.org/~dri/snapshots/savage-20040316-linux.i386.tar.bz2
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 fbdev), 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 option. Also, the savage driver behaves the same with/without the "vga=" and "video=" kernel boot parameters. "Screen Expansion"(sic) on the T23 is disabled. Results: 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 system. 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: kernel-2.6.4-1.305 xorg-x11-0.6.6-0.2004_03_30.5 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.
Do you think this is similar to bug #118205? Try kernel 2.6.5-1.308 to see if it works for you.
Kernels 2.6.5-1-{305,308,319} all exhibit the same (poor) behavior. Thanks for the catch on BUG https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118205 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 image... 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" Thanks! *** This bug has been marked as a duplicate of 118205 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.