Red Hat Bugzilla – Bug 436684
[trident] X refuses to start
Last modified: 2018-04-11 15:00:23 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
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:
Steps to Reproduce:
1. Update to rawhide
2. Move /etc/X11/xorg.conf aside if there is one there
X should start
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.
Created attachment 297352 [details]
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
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).
Created attachment 297737 [details]
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"
Similar issue with cirrus driver: bug #437081.
This could be an X-wide issue, not limited to a few drivers, I suspect, see also:
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
(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.
Attachment #297352 [details] notes that there was no /etc/X11/xorg.conf at the time I took
"(EE) Unable to locate/open config file"
this was taken right after a reboot.
Should be fixed in xserver 220.127.116.111-4
Just confirming that xorg-x11-server-Xorg-18.104.22.1681-6.20080310.fc9.i386 pulled
manually from koji here:
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).