Red Hat Bugzilla – Bug 433931
Vesa driver fails for radeon 9200 + NEC LCD 2010X
Last modified: 2018-04-11 07:20:28 EDT
Description of problem:
X does not successfully start when using the Vesa driver. (The radeon driver is also broken for this combination.)
Recently it used to fail sometimes (around 50%), but starting today it seems to be failing 100% of the time. (Though other problems sometimes cause the boot process to fail before X starts making testing difficult.)
Version-Release number of selected component (if applicable):
Seems to be 100% now, though recently was intermittant.
Steps to Reproduce:
Actual results:The monitor's signal light is green suggesting that the video card is putting out a signal. But the screen is black.
Expected results: Login screen should come up.
Created attachment 295594 [details]
Xorg.0.log from one of the failed startups.
Created attachment 295595 [details]
Thanks for the bug report. We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.
Please try to run X without any /etc/X11/xorg.conf whatsoever and let X11
autodetect your display and video card. Attach to this bug /var/log/Xorg.0.log
from this attempt as well, please.
We will review this issue again once you've had a chance to attach this information.
Thanks in advance.
Created attachment 295651 [details]
No xorg.conf but used failed attempt to force vesa driver
I tried to force the vesa driver to be used with the kernel option
xdriver=vesa (maybe I got it worg), but it didn't work.
X started up OK, but the output doesn't go to the dvi port which is
a different problem that I have already reported.
If I made a mistake with the kernel option, I can try again so that you can see
does with the vesa driver and no special options.
Created attachment 295700 [details]
Xorg.0.log from successful vesa start up
This morning the vesa driver worked on the first try. I don't know if I was
lucky or if this was affected by updates. (I am now sync'd up with the Feb 22
So I thought you might want the log from a successful start up to compare with.
The xorg.conf file is the same one I included previously that has commands to
tell the driver that the display is on the dvi port, not the vga port.
Does it mean, we can close this bug?
I think it is premature to do that unless a change went into rawhide Thursday or
Friday that might have fixed the problem.
The problem has been intermittant. I don't want to do spurious reboots to see if
the probability of it happening is changed unless there is some reason to
believe the problem has been fixed. It can take a lot (half a dozen) reboots to
get the system back up properly because of several different intermittant problems.
I keep an eye on how often the X part fails when I need to reboot for other
reasons (e.g. kernel updates) or if I see vesa or ati driver updates. (I expect
to be doing one for the kernel soon, maybe yet tonight.)
It happened 2 more times (that the boot got that far without triggering
annother problem) and then on the third try X came up (and then went down
after I logged in, but that's a different bug).
Bizarre. The only noticable difference between the log files for failure and
success is that the failed ones fail the checksum, which I think is the only
time I've _ever_ seen that to be true.
The radeon driver should definitely work for this hardware though. What's the
failure like if you use radeon?
With the radeon driver no signal is sent to the display but otherwise things
seem to work. For example vt switching (when it isn't otherwise broken in rawhide).
I suspect that the output is being sent to the vga port instead of the dvi port.
Once upon a time it used to just work. Then later I had to force it to use it
using commands in xorg.conf, then it totally broke. You can take a look at
431691 for more info.
Here is another related bug. In 383791 I had problems in F8 that were fixed.
(The other bug is for things breaking again in rawhide.)
I tried about a dozen reboots today and they all locked up. The good news is
that this motivated me to go look at the radeon driver and I hacked up the
source to work around a change that appears to have what instigated my problem
so I am better off. If you do get something you want me to test, just let me
know. But otherwise I won't be running the Vesa driver.
I retested this today (with current rawhide) and it is still occuring.
The version of the vesa driver is: xorg-x11-drv-vesa-1.3.0-15.20080404.fc9.i386
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
(In reply to comment #12)
> The good news is that this motivated me to go look at the radeon driver and I
> hacked up the source to work around a change that appears to have what
> instigated my problem so I am better off.
Would you venture to share the patch with us?
The patch was for the Radeon driver so it wouldn't really belong in this bug as I haven't been testing the vesa driver out since then. (But could if you wanted the vesa driver restested again.) However the patch itself is useless for general release because I force the monitor type to be MT_DFP instead of MT_NONE which probably isn't always a good idea.
Specifically I edit the radeon-6.9.0-to-git.patch at line 13781.
Initially it is:
MonType = MT_NONE;
And I change it to:
- MonType = MT_NONE;
+ MonType = MT_DFP;
And then I run rpmbuild on it.
I retested the vesa driver in F10 and F11 (currently rawhide) and found it to still be broken in F10, but working in F11. So if this is still open at F9 EOL, it should move to F10 and if it is still open at F10 EOL, it can be closed.
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:
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.