Bug 107848 - /etc/X11/xorg.conf created unusable for tseng(4)
/etc/X11/xorg.conf created unusable for tseng(4)
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: pyxf86config (Show other bugs)
9
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Jackson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-10-23 15:08 EDT by Felix Miata
Modified: 2013-01-13 08:31 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 12:47:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Original non-functional XF86Config (3.06 KB, text/plain)
2003-10-23 15:10 EDT, Felix Miata
no flags Details
Functional (self modified) XF86Config (3.47 KB, text/plain)
2003-10-23 15:10 EDT, Felix Miata
no flags Details
initial xorg.conf from installing FC4 (2.71 KB, text/plain)
2005-09-29 17:35 EDT, Felix Miata
no flags Details
working xorg.conf from FC4 running 1600x1200 on ET6x00 4M (4.83 KB, text/plain)
2005-09-29 17:35 EDT, Felix Miata
no flags Details
working xorg.conf from FC4 running 1400x1050 on ET6x00 4M (4.80 KB, text/plain)
2005-09-29 17:59 EDT, Felix Miata
no flags Details
FC4 Xorg.0.log using xorg.conf generated by 'X -configure' (28.45 KB, text/plain)
2006-04-19 15:09 EDT, Felix Miata
no flags Details
lspci -v output (2.31 KB, text/plain)
2006-08-24 09:17 EDT, Felix Miata
no flags Details
ET6100 EPROM code (16.00 KB, application/octet-stream)
2006-08-24 10:17 EDT, Felix Miata
no flags Details
Xorg.0.log that puts display to sleep on kdm startup (33.79 KB, text/plain)
2006-11-24 11:54 EST, Felix Miata
no flags Details
/var/log/Xorg.0.log from startx after installing comment 17 rpm (11.13 KB, text/plain)
2007-03-27 15:07 EDT, Felix Miata
no flags Details
xorg.conf that works w/ tseng driver @ 1400x1050x16bpp in current OpenSUSE Factory (3.25 KB, text/plain)
2008-01-13 09:42 EST, Felix Miata
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Novell 221987 None None None Never

  None (edit)
Description Felix Miata 2003-10-23 15:08:33 EDT
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.
Comment 1 Felix Miata 2003-10-23 15:10:33 EDT
Created attachment 95440 [details]
Original non-functional XF86Config
Comment 2 Felix Miata 2003-10-23 15:10:39 EDT
Created attachment 95441 [details]
Functional (self modified) XF86Config
Comment 3 Marius Andreiana 2005-05-31 13:03:55 EDT
Is this still an issue with Fedora Core 4 test3 or FC3? It has x.org instead of
XFree86.
Comment 4 Felix Miata 2005-05-31 14:53:41 EDT
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.
Comment 5 Felix Miata 2005-09-29 17:35:03 EDT
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.
Comment 6 Felix Miata 2005-09-29 17:35:24 EDT
Created attachment 119441 [details]
working xorg.conf from FC4 running 1600x1200 on ET6x00 4M
Comment 7 Felix Miata 2005-09-29 17:59:55 EDT
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.
Comment 8 Adam Jackson 2006-04-19 13:30:19 EDT
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?
Comment 9 Felix Miata 2006-04-19 15:09:32 EDT
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.
Comment 10 Adam Jackson 2006-08-18 21:35:53 EDT
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.
Comment 11 Felix Miata 2006-08-24 09:17:05 EDT
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
Comment 12 Felix Miata 2006-08-24 09:26:10 EDT
/sys/bus/pci/devices/0000:00:0b.0/rom is a link to
/sys/devices/pci0000:00/0000:00:0b.0/rom 16384K
Comment 13 Felix Miata 2006-08-24 10:17:27 EDT
Created attachment 134815 [details]
ET6100 EPROM code
Comment 14 Felix Miata 2006-11-06 09:53:52 EST
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"
Comment 15 Felix Miata 2006-11-24 11:54:05 EST
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.
Comment 16 Felix Miata 2007-01-04 15:37:21 EST
this suse bug might provide some guidance on fixing
https://bugzilla.novell.com/show_bug.cgi?id=221987
Comment 17 Adam Jackson 2007-03-15 15:07:14 EDT
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.
Comment 18 Felix Miata 2007-03-15 16:39:02 EDT
Can that be installed in FC6? I won't have time to deal with FC7 before it gets
released at the earliest.
Comment 19 Adam Jackson 2007-03-15 19:47:26 EDT
Yeah, should be fine in FC6.
Comment 20 Felix Miata 2007-03-27 15:07:52 EDT
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.
Comment 21 Adam Jackson 2007-03-28 11:01:47 EDT
Bleh.  Goofy failure, not worth worrying about.  Try again with FC7 final I
guess, once it comes out.
Comment 22 Felix Miata 2008-01-13 09:42:35 EST
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.
Comment 23 Bug Zapper 2008-05-13 21:55:34 EDT
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
Comment 24 Bug Zapper 2009-06-09 17:57:51 EDT
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
Comment 25 Bug Zapper 2009-07-14 12:47:06 EDT
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.

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