Bug 433931 - Vesa driver fails for radeon 9200 + NEC LCD 2010X
Vesa driver fails for radeon 9200 + NEC LCD 2010X
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-vesa (Show other bugs)
i686 Linux
low Severity low
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-02-22 02:14 EST by Bruno Wolff III
Modified: 2018-04-11 07:20 EDT (History)
2 users (show)

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

Attachments (Terms of Use)
Xorg.0.log from one of the failed startups. (41.47 KB, text/plain)
2008-02-22 02:14 EST, Bruno Wolff III
no flags Details
xorg.conf (1012 bytes, text/plain)
2008-02-22 02:16 EST, Bruno Wolff III
no flags Details
No xorg.conf but used failed attempt to force vesa driver (32.08 KB, text/plain)
2008-02-22 11:32 EST, Bruno Wolff III
no flags Details
Xorg.0.log from successful vesa start up (45.83 KB, application/octet-stream)
2008-02-23 09:36 EST, Bruno Wolff III
no flags Details

  None (edit)
Description Bruno Wolff III 2008-02-22 02:14:15 EST
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):

How reproducible:
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.

Additional info:
Comment 1 Bruno Wolff III 2008-02-22 02:14:15 EST
Created attachment 295594 [details]
Xorg.0.log from one of the failed startups.
Comment 2 Bruno Wolff III 2008-02-22 02:16:11 EST
Created attachment 295595 [details]
Comment 3 Matěj Cepl 2008-02-22 06:33:13 EST
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.
Comment 4 Bruno Wolff III 2008-02-22 11:32:13 EST
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
what it
does with the vesa driver and no special options.
Comment 5 Bruno Wolff III 2008-02-23 09:36:00 EST
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.
Comment 6 Matěj Cepl 2008-02-25 16:17:17 EST
Does it mean, we can close this bug?
Comment 7 Bruno Wolff III 2008-02-25 20:54:03 EST
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.)
Comment 8 Bruno Wolff III 2008-02-25 23:52:25 EST
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).
Comment 9 Adam Jackson 2008-03-04 15:20:22 EST
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?
Comment 10 Bruno Wolff III 2008-03-04 17:49:40 EST
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.
Comment 11 Bruno Wolff III 2008-03-08 11:08:16 EST
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.)
Comment 12 Bruno Wolff III 2008-03-15 21:10:59 EDT
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.
Comment 13 Bruno Wolff III 2008-05-12 12:46:43 EDT
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
Comment 14 Bug Zapper 2008-05-14 01:20:14 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 15 Matěj Cepl 2008-10-10 12:46:53 EDT
(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?
Comment 16 Bruno Wolff III 2008-10-10 13:38:06 EDT
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.
Comment 17 Bruno Wolff III 2009-01-25 12:10:54 EST
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.
Comment 18 Bug Zapper 2009-06-09 19:36:52 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: 
Comment 19 Bug Zapper 2009-07-14 13:27:39 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.