Bug 107848
Created attachment 95440 [details]
Original non-functional XF86Config
Created attachment 95441 [details]
Functional (self modified) XF86Config
Is this still an issue with Fedora Core 4 test3 or FC3? It has x.org instead of XFree86. FC3 was not IIRC materially different: (WW) TSENG(0): Mode pool is empty (EE) TSENG(0): No valid modes found ... (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found The fatality was corrected by adding the following to Section "Monitor": VideoRam 4096 I probably won't be changing anything before FC4 is final. Created attachment 119440 [details]
initial xorg.conf from installing FC4
This is using the vesa driver instead of the tseng driver. It is functional,
but still not quite right. I specified 1400x1050 during installation, which the
installer put into the file in SubSection "Display" for 16 bit, but when X
starts, it is using the unwanted 5/4 aspect ratio 1280x1024. The display I'm
using actually supports both 1600x1200 and 1400x1050, and in fact does do
1400x1050 and 1600x1200 when I manually alter xorg.conf.
Created attachment 119441 [details]
working xorg.conf from FC4 running 1600x1200 on ET6x00 4M
Created attachment 119443 [details]
working xorg.conf from FC4 running 1400x1050 on ET6x00 4M
This uses the tseng driver. The vesa driver doesn't seem to want to do
1400x1050 or 1280x960 @ depth 16.
so the theme here seems to be that we're unable to size VRAM properly. can you attach your Xorg.0.log so we can see why we're failing to do so? Created attachment 128003 [details]
FC4 Xorg.0.log using xorg.conf generated by 'X -configure'
X loops forever trying unsuccessfully to start using the xorg.conf file
generated by 'X -configure'. Only way I know out of the loop is CAD.
Do you have a rom file for the PCI device? Look in /sys/bus/pci/devices/0000:00:0b.0/ for a file named 'rom'. If the file exists, then do: su echo 1 > rom cp rom /tmp/rom and attach the /tmp/rom file to this bug. Presumably the ROM just has the VRAM size information in a different place. Also if you could attach the output of 'lspci -v' that might be helpful. Created attachment 134804 [details]
lspci -v output
Doing:
su
echo 1 > rom
cp rom /tmp/rom
only creates a 2 byte file consisting of:
31 0A
/sys/bus/pci/devices/0000:00:0b.0/rom is a link to /sys/devices/pci0000:00/0000:00:0b.0/rom 16384K Created attachment 134815 [details]
ET6100 EPROM code
In FC6, 'X -configure' generates an xorg.conf with the tseng driver and no modes in Section "Screen", and consequently the maximum resolution is 800x600. Running system-config-display and choosing 16 bit 1600x1200 resolution generates an xorg.conf with the tseng driver and the following list of modes in Section "Screen": 1600x1200 1400x1050 1280x1024 1280x960 1280x800 1152x864 1152x768 1024x768 800x600 640x480, but X uses 1280x800, even though display is a standard 4:3 CRT (Dell P991). If I manually edit xorg.conf and remove the 1280x800 mode, then X starts in 1152x864. If I manually edit xorg.conf and add to Section "Device" 'VideoRam 4096', then starting X puts the display in sleep mode, unless I remove all modes higher than 1152x864. If I manually edit xorg.conf and switch the driver from tseng to vesa, even using 'VideoRAM 4096', then the maximum resolution it will do is 1152x864. Xorg.0.log for VESA driver reports, among other things: 1-(II) VESA(0): VESA VBE Total Mem: 2048 kB 2-(II) VESA(0): Not using mode "1600x1200" (no mode of this name) 3-(II) VESA(0): Not using mode "1400x1050" (no mode of this name) 4-(II) VESA(0): Not using mode "1280x960" (no mode of this name) 5-(**) VESA(0): Using "Shadow Framebuffer" Created attachment 142078 [details]
Xorg.0.log that puts display to sleep on kdm startup
I tried Option "noaccel", but that didn't help. SUSE 10.0 and Kubuntu Edgy 6.10
on the same system both run 1400x1050x16bpp just fine.
this suse bug might provide some guidance on fixing https://bugzilla.novell.com/show_bug.cgi?id=221987 Alright, I can't figure out how to find the amount of RAM you really have, but I do know how to ask the VESA BIOS for how much RAM it thinks you have. Can you try this driver and see if it works any better? http://people.redhat.com/ajackson/xorg-x11-drv-tseng-1.1.0-4.fc7.jx.i686.rpm That should at least get it to detect 2M, which will get you up at 800x600 instead of failing completely. Can that be installed in FC6? I won't have time to deal with FC7 before it gets released at the earliest. Yeah, should be fine in FC6. Created attachment 151064 [details] /var/log/Xorg.0.log from startx after installing comment 17 rpm startx fails with a fresh xorg.conf file generated by 'system-config-display --reconfig -v --set-driver=tseng' after rpm -Uvh the comment 17 rpm. Bleh. Goofy failure, not worth worrying about. Try again with FC7 final I guess, once it comes out. Created attachment 291502 [details]
xorg.conf that works w/ tseng driver @ 1400x1050x16bpp in current OpenSUSE Factory
Even worse in F8. Now not only does startx send display into "out of range", it
reboots the computer if I use this file that works perfectly in current
OpenSUSE Factory (11.0 alpha). If I modify it to prefer 1152x864 instead of
1400x1050, then it only sends display into out of range and does not reboot.
system-config-display aborts unless I give it --set parameters, in which case
it writes a file that ignores all of them. If I tweak the result sufficiently,
then I can get it to work with the VESA driver, but only up to 1152x864.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |
Description of problem: Graphical install went just fine, but on reboot into new severn3 installation, no X. Parameters contained in /etc/X11/XF86Config are either wrong or missing, and /var/log/XFree86.0.log contains several fatal (EE) errors . To make X work, I must manually alter /etc/X11/XF86Config based upon previous installs that worked just fine (e.g. Mandrake & SuSE in in various 4.x XFree flavors). How reproducible: 100% (same as shrike) Steps to Reproduce: 1.Install on non-DDC monitor on system with (ancient) Tseng ET6x00 PCI graphics adapter. Actual results: 1.X won't start Expected results: 1.X works Additional info: This file in my SuSE 8.1 install on the same box (and which runs non-interlaced 1280x1024 on the same IBM 2118 monitor) contains the following section, which is missing entirely from the severn install: Section "Modes" Identifier "Modes[0]" Modeline "1024x768" 63.74 1024 1040 1216 1400 768 768 775 802 Modeline "1280x1024" 79.87 1280 1296 1552 1736 1024 1024 1031 1070 Modeline "800x600" 37.44 800 816 928 1072 600 600 607 626 Modeline "640x480" 23.96 640 656 720 864 480 480 487 501 Modeline "1024x768" 65.0 1024 1048 1184 1344 768 771 777 806 -hsync -vsync EndSection The screens section of the file was missing any modes lines. I added 'Modes "1024x768" "800x600" "640x480"' to the depth 16 section, but still was limited to 800x600. Only after changing HorizSync 31.5 - 37.9 to HorizSync 31.5 - 48.0 was I able to reach 1024x768. In the past, I've also had to add two lines to the device "tseng" section: VideoRam 4096 Option "NoAccel" which I automatically add after any install, normally before starting X the first time.