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): xorg-x11-drv-vesa-1.3.0-12.20071113.fc9.i386 How reproducible: Seems to be 100% now, though recently was intermittant. Steps to Reproduce: 1.Reboot 2. 3. 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:
Created attachment 295594 [details] Xorg.0.log from one of the failed startups.
Created attachment 295595 [details] xorg.conf
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 what it 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 rawhide.) 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
(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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.