Bug 436684 - [trident] X refuses to start
[trident] X refuses to start
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-trident (Show other bugs)
rawhide
All Linux
high Severity high
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-09 06:17 EDT by Alex Lancaster
Modified: 2008-03-13 04:23 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-12 16:43:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/var/log/Xorg.0.log (12.02 KB, text/plain)
2008-03-09 06:17 EDT, Alex Lancaster
no flags Details
Working /etc/X11/xorg.conf (1.42 KB, text/plain)
2008-03-12 04:36 EDT, Alex Lancaster
no flags Details

  None (edit)
Description Alex Lancaster 2008-03-09 06:17:07 EDT
Description of problem:
X doesn't start at all in rawhide with the trident driver:

(==) Log file: "/var/log/Xorg.0.log", Time: Sun Mar  9 03:05:59 2008
(EE) Unable to locate/open config file
New driver is "trident"
(==) Using default built-in configuration (30 lines)
(EE) Failed to load module "fbdev" (module does not exist, 0)
(EE) TRIDENT(0): No valid modes found
(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:
no screens found
giving up.
xinit:  Connection refused (errno 111):  unable to connect to X server
xinit:  No such process (errno 3):  Server error.

This appears to be an X wide or kernel problem rather than the trident driver
itself as the driver package itself hasn't been updated, and it did work up
until recently, but I'm filing it here as I don't know where else it should go.

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

These are some relevant versions of the kernel and the Xorg server:

kernel-2.6.25-0.95.rc4.fc9.i686
xorg-x11-server-Xorg-1.4.99.901-1.20080307.fc9.i386

How reproducible:
Always

Steps to Reproduce:
1. Update to rawhide
2. Move /etc/X11/xorg.conf aside if there is one there
3. startx
  
Actual results:
See attachment

Expected results:
X should start

Additional info:
I moved aside the xorg.conf which didn't make any difference.  I also tried
manually setting it to the vesa driver, but didn't work either.
Comment 1 Alex Lancaster 2008-03-09 06:17:07 EDT
Created attachment 297352 [details]
/var/log/Xorg.0.log
Comment 2 Alex Lancaster 2008-03-12 04:31:38 EDT
Hmm, it *does* actually appear to be trident-specific.  I used the default
/etc/X11/xorg.conf created by system-config-display and then modified the driver
line to:

driver: vesa

X starts.  What's also odd is that if I moved the xorg.conf completely,
system-display-config didn't seem able to automatically fall back to the vesa
driver by itself.

Cc'ing Dave Airlie who fixed the trident driver when it wasn't working in an
earlier rawhide (bug #433254).
Comment 3 Alex Lancaster 2008-03-12 04:36:40 EDT
Created attachment 297737 [details]
Working /etc/X11/xorg.conf

This xorg.conf works.  To generate this I ran "system-config-display", then
changed the Driver in "Device" section from "trident" to "vesa".  

To reproduce bug, simply rename "vesa" back to "trident"
Comment 4 Alex Lancaster 2008-03-12 05:29:32 EDT
Similar issue with cirrus driver: bug #437081.

This could be an X-wide issue, not limited to a few drivers, I suspect, see also:

http://www.redhat.com/archives/fedora-test-list/2008-March/msg00421.html
Comment 5 Matěj Cepl 2008-03-12 06:46:37 EDT
Assigning to ajax, to whom it belongs (looks like either Xserver issue or
trident issue), but could I ask you as well to try to move /etc/X11/xorg.conf
somewhere behind the corner and then to restart X (or whole computer) without
the one? What happens? Could we get /var/log/Xorg.0.log from this experiment as
well, please?
Comment 6 Alex Lancaster 2008-03-12 06:55:21 EDT
(In reply to comment #5)
> Assigning to ajax, to whom it belongs (looks like either Xserver issue or
> trident issue), but could I ask you as well to try to move /etc/X11/xorg.conf
> somewhere behind the corner and then to restart X (or whole computer) without
> the one? What happens? Could we get /var/log/Xorg.0.log from this experiment as
> well, please?

The /var/log/Xorg.0.1 in the attachment *is* the result of that experiment.
Comment 7 Alex Lancaster 2008-03-12 06:58:43 EDT
Attachment #297352 [details] notes that there was no /etc/X11/xorg.conf at the time I took
the /var/log/Xorg.0.log:

"(EE) Unable to locate/open config file"

this was taken right after a reboot.
Comment 8 Adam Jackson 2008-03-12 16:43:36 EDT
Should be fixed in xserver 1.4.99.901-4
Comment 9 Alex Lancaster 2008-03-13 04:23:02 EDT
Just confirming that xorg-x11-server-Xorg-1.4.99.901-6.20080310.fc9.i386 pulled
manually from koji here:

http://koji.fedoraproject.org/koji/buildinfo?buildID=42769

does appear to get X to start (with trident).   Thanks!

Although there are some issues with choosing too small a resolution mode when no
xorg.conf is present, but that's another issue (bug #433423).

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