Red Hat Bugzilla – Full Text Bug Listing
|Summary:||nv video cards do not work well with DVI|
|Product:||[Retired] Red Hat Linux||Reporter:||Brian Stretch <bstretch>|
|Component:||XFree86||Assignee:||Mike A. Harris <mharris>|
|Status:||CLOSED DUPLICATE||QA Contact:||David Lawrence <dkl>|
|Version:||9||CC:||katzj, m, msf|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-02-21 13:51:56 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Brian Stretch 2003-02-21 15:48:10 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030211 Description of problem: When the Phoebe3 graphical installer starts X, my ViewSonic VG191b LCD monitor connected to the DVI port of my nVidia Ti4200 video card displays its "OUT OF SYNC" error message. Ctrl-alt-del causes a clean shutdown and reboot of the system and it appears that Phoebe thought (incorrectly) that the X server had started OK. If I shutdown, switch to the VGA port, and reboot, everything's fine. My assumption is that the VGA port is being selected regardless of whether a monitor is hooked up to it. Similar behavior has been reported by other users with ATI dualhead cards on phoebe-list. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Boot with monitor connected to DVI port 2. Continue installation until X starts 3. Actual Results: Monitor displays "OUT OF SYNC" error message Expected Results: X should display on the monitor. Additional info:
Comment 1 Mike A. Harris 2003-02-21 17:03:22 EST
This would be video driver specific. ATI users should report their own bugs separately, and with full information. I might be able to do something about the ATI problems perhaps, as I have ATI hardware and docs (although no LCD display). I do not have any Nvidia documentation, so any problems with the "nv" driver like this should be reported to email@example.com please.
Comment 2 Matthew Rothenberg 2003-02-21 21:55:16 EST
Perhaps this isn't driver specific?--I am having *exact* same problem with an ATI Radeon 9500 Pro and a Sony SDM-P232 23" flat panel.
Comment 3 Jim Cornette 2003-02-22 08:54:55 EST
A similar problem was encountered and submitted at this bug. Also talking on the beta list, with others. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=84854
Comment 4 Charles 2003-02-22 10:28:28 EST
Also similar problem reported by here here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=84656
Comment 5 Brian Stretch 2003-02-22 18:49:59 EST
I just did a clean install of Phoebe3 and this time I switched cables from DVI to VGA after the X server had started up. As I suspected, Phoebe3 had switched the display to the VGA port. After installation I tried booting with DVI, and once again, Phoebe3 switched to the VGA port.
Comment 6 Shane Smart 2003-03-06 15:26:44 EST
I'm using a Dell 20" LCD FP2000 in which goes "out of sync" or "idle/safe mode" upon entering the RHLinux Phoebe3 installer boot. Some mentioned about ATi cards, but I'm using a Geforce 4 Ti4600 (P4, 2.4ghz) and have the same problem. Hopefully we see this fixed in an upcoming release :)
Comment 7 Mike A. Harris 2003-03-06 17:15:55 EST
Shane) You are using Nvidia hardware, and so your problem will be a totally separate issue, since Nvidia hardware uses the "nv" driver, and anything related to issues like this is video driver specific. This type of stuff is not handled in generic code that touches all hardware - it is video driver specific, and in fact specific to the exact video card hardware. As I said above: >I do not have any Nvidia documentation, so any problems with the "nv" >driver like this should be reported to firstname.lastname@example.org please. If there are any problems with the "nv" driver, they will continue to be problems until someone reports them to XFree86 directly and the video driver maintainer can examine them. This bug report here, is concerning DVI related problems on Radeon hardware, and since this is a driver specific issue, there is no reason to talk about Nvidia driver specific problems in this bug report please.
Comment 8 Mike A. Harris 2003-03-06 19:56:46 EST
Brian) If there are 2 displays plugged into the card, the DVI port will always be considered the Primary head by the radeon video driver. This is the way the driver is hard coded. If you're using only singlehead with DVI, then the DVI head should be the Primary display as well. I don't have any DVI panels to test or troubleshoot this with however, so I'm not sure there is anything that I can do if there is a problem with the Radeon driver and DVI panels, as I just don't have the hardware to attempt to reproduce the problem.
Comment 9 Matthew Rothenberg 2003-03-06 20:12:28 EST
I just tested with both a CRT and LCD using the VGA and DVI ports, plugging things in at various times and etc. *I can confirm identical behavior to what Brian Stretch is reporting: Phoebe switches itself over to the VGA port rather than the DVI port no matter what. However, Brian is using Nvidia card and I am on ATI Radeon 9500... and we have very very similar reports from other users on both types of card (Shane with Nvidia, someone else with an ATI 8500 on the mailing list, some others I dont recall off the top of my head). Can this really be a driver issue then? It seems strange to me that both drivers would experience the exact same problem, affecting so many different setups...
Comment 10 Mike A. Harris 2003-03-06 20:39:35 EST
The monitor detection code is part of the video driver. So yes, this can be driver specific. Please press enter at the end of your line after about 60 characters so your messages are readable in bugzilla without having to scroll sideways. Thanks.
Comment 11 Charles 2003-03-06 22:41:15 EST
This is still a problem for me too using nvidia geforce4 ti with a vga port and dvi port. I only have 1 monitor (samsung lcd) hooked up to it. When I have my lcd connected to the dvi port, I get a blank screen after text anaconda probe. When I have my lcd connected to the vga port, I get the gui install after text anaconda probe. So, the output is being forced to the vga port. As an aside: I don't have this problem with RH 8.0. I can hook my monitor up with the dvi port and install RH 8.0 and it installs perfectly (i.e. I get the gui installation).
Comment 12 Shane Smart 2003-03-07 03:27:23 EST
I'm going to send an email to email@example.com shortly here. But I want to comment on #9 and #11; that indeed these are almost the same problems. If you look at it, it could be Phoebe related.
Comment 13 Shane Smart 2003-03-08 18:22:49 EST
An update from Mark @ XFree86.org: I don't know much about RedHat's installer. My impression was that they used the vesa driver, not the "nv" driver for their installation and it wasn't until later that they configured the "nv" driver. If they are trying to do the install with the "nv" driver, that would be a mistake since it has some problems detecting flat panels and which head they are on so it usually doesn't "just work" when a flat panel is used. You could always install in non-graphical mode. Mark. ------------------------------ Hopefully this information helps :)
Comment 14 Mike A. Harris 2003-03-08 20:53:59 EST
Mark's impression is incorrect. Our installer attempts to use the driver which is listed in the Cards database for the detected card. In almost all cases, this is the native video driver for the card. If the native driver fails to start up, then the installer will fall back to the vesa driver. >If they are trying to do the install with the "nv" driver, that would be >a mistake since it has some problems detecting flat panels and which head >they are on so it usually doesn't "just work" when a flat panel is used. It would be a mistake of our installer to assume the driver works? I don't follow the logic there personally. I can change this to default to the "vesa" driver, however doing so will not just change the default driver used in the installer, but will change the default driver to be "vesa" for all Nvidia hardware, even at runtime. We really do not have the resources to maintain 2 separate video driver mapping databases, one for our installed OS, and one for the installer. That is just not reasonable. It's also not reasonable to add hacks to our installer per video card. I personally consider this a "nv" driver bug. It wont get fixed in the nv driver until fixed upstream however, since we don't have the capability to do so. The only thing that I personally can do is: 1) Change the default video driver for both installer+installed system to be vesa instead of nv. or 2) Ask our installer team to make installer hacks to special case Nvidia hardware and default to using the vesa driver during install for all Nvidia hardware. I know that "vesa" however does not work properly on all Nvidia hardware (GeForce 4 for example) due to past bug reports during the development of Red Hat Linux 8.0 where I defaulted the GF4 to vesa. Also to be considered, is that "vesa" only works on x86 hardware, and we can not rely on it working on all other architectures that we support such as ia64, x86_64, ppc, ppc64. So the true fix here, is to fix the "nv" driver to do the right thing. I am carbon coying some of our installer developers so they can comment as to wether or not installer hacks specific to Nvidia can be incorporated or not.
Comment 15 Shane Smart 2003-03-08 21:09:01 EST
Mark Harris- Thanks for your time and posting in this particular bugzilla thread. You suggest to: â1) Change the default video driver for both installer+installed system to be vesa instead of nv.â How do you do this? On my gaming rig, I donât have a previous Linux build installed. How would I modify the installer to use Vesa instead of NV? Thanks again, hope to hear from you, Shane Smart
Comment 16 Brian Stretch 2003-03-08 21:32:06 EST
Ugh. I hate to say it, but it sounds like the best thing to do is simply release note this problem and post fixed binaries in Red Hat Updates as soon as they're available, assuming that the problem isn't fixed before RH8.1 goes gold. It's just very confusing as to why RH8.0 worked and Phoebe doesn't, and why are ATI users having the same problem? Also, it's clear that Red Hat needs to dip into the leftover IPO money kitty and buy Mike a flat panel and appropriate video card :-). Maybe nVidia can slide a shiny new GeForce FX5600 your way? (Though the FX series probably breaks all sorts of additional things...) Samsung has a slightly cheaper replacement of their excellent 191T coming out soon, should be very nice, if you can live with 1280x1024 res. 19" panels are the best bang/buck IMHO.
Comment 17 Shane Smart 2003-03-08 21:43:07 EST
I'm sure the problem will be fixed before gold :) At least I hope. I did try working with text-mode and that works ;)
Comment 18 Mike A. Harris 2003-03-08 21:45:02 EST
Sorry, you misunderstood me. What I mean, is that the default video driver used by our installer in graphical install mode, is the exact same driver that will be used in XFree86 on the installed system. The driver used, is the one listed in the "Cards" video card to video driver mapping database. Whatever is listed there, is what the installer will use, and what your installed system will use. If the listed driver fails for whatever reason during install, the installer will try to fall back to the "vesa" driver. _I_ can change the default driver to be "vesa", however that does not just change it in the installer, it changes it both in the installer, and it makes it the default video driver used in your installed system. Basically, whatever is listed in the "Cards" file in the hwdata package, is the driver that anaconda (the installer) will use during installation. As such, it is nontrivial to make the installer use vesa, but the installed system use "nv" for one or more specific cards. Adding some kind of infrastructure to allow this, would be IMHO a complex mess, and would really only be working around video driver bugs. At this point in time, there is no way that our installer will be modified to do anything differently for any particular hardware. Users who have the problem described in this bug report will have to perform a text mode installation due to the buggy broken "nv" driver. For future development however, I there are several options: 1) Add a new flag to the "Cards" file called INSTALLER_DRIVER, which if present is the driver for the installer to use. This is a bad idea, as it requires additional maintenance of the driver database by the distribution vendor, to work around bugs in the XFree86 video drivers. It also does not really handle non-x86 architectures very well, and also requires kludges to the installer. Since the "nv" driver is the only problem driver here, I do not believe spending the time to do this kind of a hack is a good use of our engineering resources. or 2) I can change the default video driver to "vesa" for any video card that is reported to have problems with the "nv" driver (or any other driver) during installation, due to driver bugs, or whatever other reason. This also means that the "vesa" driver will be the default video driver used on the user's installed system as well, unless the user manually configures X to use the native video driver themselves. or 3) Our installer is modified with hard coded per-video-card ugly hacks to use a particular driver during install, where the native default driver in the cards database is known to be broken (the nv driver in this example). I consider this to be an ugly hack to work around inadequacies of the broken X driver. I do not know if our installer team will consider this type of hack or not. If not, then only option 1 or 2 are available, and likely if they do not consider #3 to be viable, then they wont consider #1 to be any more viable either I presume. So the most likely scenario is that in our future development, any video hardware which fails during installation, will have the default driver changed in our Cards database to the "vesa" driver, which will then end up being used on that video card both for installation, as well as post installation XFree86 usage. The real solution, is for XFree86 to have working video drivers by default, and then we don't need to worry about any kind of ugly hacks. Only people who have access to the technical specifications of a given video card however stand any real chance of making the hardware work properly with a given native video driver. Red Hat does not have the technical specifications for this particular hardware, and thus can not really do much about the native video driver being broken, other than use "vesa".
Comment 19 Brian Stretch 2003-03-08 22:11:11 EST
Maybe there should be a manual override that users could invoke to select which video head to use (inconvenient for the user but generic), rather than attempt to add complexity to the vidcard database (convenient for the user but error prone)? Maybe reintroduce the "Test video mode" feature and add a "switch heads" button there? Given the reality of XFree driver bugs it looks like we really need that test feature, even though it's annoying for 99% of the users out there. Maybe put a "Use VESA driver" override button there too? Release noting the recommendation to switch video heads or try textmode install if the correct video head is not autodetected in graphical install mode is a good idea. That's probably all that's needed really given that we're dealing with a recently introduced bug that ought to be correctable. Also, the nv driver *thinks* it started correctly, so there's nothing to trigger a fallback to VESA.
Comment 20 Mike A. Harris 2003-03-08 23:05:19 EST
>Ugh. I hate to say it, but it sounds like the best thing to do is simply >release note this problem and post fixed binaries in Red Hat Updates as soon as >they're available, assuming that the problem isn't fixed before RH8.1 goes gold. Sorry, but if this isn't fixed in XFree86.org sources prior to my final XFree86 build for our next release, it just will not be fixed in the final release either. I do not have Nvidia technical specs, and I've only got 2 Nvidia cards present to test with, and no DVI hardware. Even if I had DVI hardware, and one of every single Nvidia card here, I would be unable to fix the problem without Nvidia specs, and that simply is not going to happen. Assuming this problem does not get fixed in time by upstream, then it will remain a problem probably for many months, as we simply do not provide XFree86 updates for single bug fixes, nor for one video driver problem. We generally release XFree86 erratum only when there is a major XFree86 security problem which requires an update, and at that time, we generally include all of the bug fixes that have accumulated in the mean time. We will not respin and QA test an entire XFree86 package set just for one specific video card problem or even one specific video driver problem either. It is just not economically feasible to do so. Not as long as XFree86 ships as one huge monolithic source code build anyway. If the video drivers were built individually, that might be an option to ship one video driver update. But it is not an option at this point in time. >It's just very confusing as to why RH8.0 worked and Phoebe doesn't, and It's not confusing to me at all. Red Hat Linux 8.0 shipped with XFree86 4.2.0, and Phoebe beta ships with XFree86 4.3.0. The 4.3.0 nv video driver is extensively changed compared to the 4.2.0 driver. There are hundreds of opportunities for the video driver changes to create problems in the 4.3.0 codebase that were not present in the 4.2.0 codebase, since the driver changed dramatically in the last 1+ years since the code was frozen for the driver that appears in Red Hat Linux 8.0 (4.2.0). So, it is completely feasible that driver changes occured in the nv driver in 12+ months of XFree86.org development, which broke the driver, and perhaps were not adequately tested by XFree86.org and/or driver maintainers. >why are ATI users having the same problem? Well, ATI users would not be having this problem because this problem is specific to the "nv" driver. However, it is entirely within the realm of possibility however that ATI users may indeed be having a very similar problem. Coincidences do indeed happen in this world. But any coincidence between an Nvidia user experiencing this kind of a problem using the "nv" driver, and an ATI user experiencing this problem with the given ATI driver, are just that - a coincidence, since as I have stated rather clearly before, this is not a generic problem, because the code used to detect monitors and LCD panels, is not generic X server code. It is video driver specific source code, contained in the video driver specific directory. That would be radeon_driver.c in the Radeon driver, and radeon_driver.c is not part of the "nv" driver, so the problem is definitely not "one" problem common to 2 drivers. It is 2 problems that are coincidentally similar, which are individual driver problems. I don't really see it to be very beneficial to comment on this further in bugzilla however, as we already know the problem (the nv driver has bugs in it), and the solution (wait for upstream development to fix the driver).
Comment 21 Mike A. Harris 2003-03-08 23:12:38 EST
bstretch) I appreciate your suggestions, but they are only workarounds for the real problem, and there is already a viable workaround for this problem, which is to use text mode to install. Increasing the complexity of the installer is not IMHO a good idea. We already have plans for future releases of Red Hat Linux, to remove X configuration from the installation phase and push it into the "firstboot" phase which occurs post install. When this happens, problems such as this one, which are caused by buggy video drivers, will not happen during install anymore. We are setting out to make the installation of Red Hat Linux more simpler, and to present first time users with less confusing questions. We're also setting out to make video configuration just work out of the box as much as possible, with as little as possible user intervention. Making any card specific and/or driver specific hacks, or making any kind of custom installer kludge/option, just makes things more complicated for users, and does not simplify anything. The only options I see happening at all for this release, are the ones I described above. Anything more complex than the above would be way too much change at this stage of development, and is just not going to happen. Once our release is finalized, then future options can be considered, however as I've stated above, I do not forsee it being a problem in the future, as firstboot will handle X configuration. Hopefully also, the nv driver will be fixed and work properly too.
Comment 22 Shane Smart 2003-03-08 23:16:43 EST
Well, I can live with using text-mode. Text mode isn't that bad, I mean, its the same thing w/o the GUI. I'm just hoping Nvidia releases a updated copy of their Linux driver build upon the RHLinux 8.1 release. Mark, thanks for clearing this up for us. Looking forward the gold release of RHLinux 8.1 :)
Comment 23 Brian Stretch 2003-03-08 23:39:07 EST
Ditto what Shane said. I meant to imply that hopefully the nv bug would be fixed upstream in time for RH8.1, not that you should fix it Mike, though I still think RH should buy you a panel and DVI card so you'll have a better chance of seeing these fun problems before betas go out. Besides, one should never miss an opportunity to request cool toys :-). I didn't realize that XFree was *that* monolithic. And yes, nVidia needs a good whack with the cluebat for not being more open with their documentation. Now I understand why we're left with the textmode install fallback as the only viable solution, thanks.
Comment 24 Charles 2003-03-10 21:03:54 EST
Mike, thanks for all your comments. You're right; given the relative infrequency the problem, it doesn't make sense for RH to spend a lot of time hacking away at a temporary fix. Text mode install is fine. I would, however, put a notation in the release notes so newbies that happen to have h/w similar to mine (geforce 4 ti 4200 dual head vga/dvi and samsung lcd monitor) won't freak when 8.1 appears to not install [assuming they read release notes, of course :)]. Thanks again and can't wait for 8.1!
Comment 25 Matthew Rothenberg 2003-03-10 21:36:41 EST
Wait, so is this affecting you guys only during the graphical installer? For me, it happens post-install as well. E.g., using X is entirely impossible, even after a successful text install. Just seeing if we're all on the same page here.
Comment 26 Charles 2003-03-11 07:33:03 EST
M Rothenberg: This only affects me at install. I have a geforce4 ti 4200 with vga port and dvi port. I have it hooked up to my lcd thru the dvi port. When I install pheobe 3, the anaconda probe finds my monitor, geforce4 ti 4200 etc and tries to load the "nv" driver, which gives me a blank screen. So, I use text mode install, then when installation is done, I boot to prompt, change xf86config to change reference from "nv" to "vesa", restart X, and I've got X working fine. I then did a second pheobe install on same box, but used vga connection rather than dvi. I got the gui install from the very start and had no problems with X at all. So, to me it looks like the "nv" driver is forcing the output from dvi to vga.
Comment 27 Mike A. Harris 2003-04-09 05:12:18 EDT
Changing the bug Summary from "phoebe forces blah blah" to "nv video cards do not work well with DVI" to more accurately describe the problem, because this has nothing to do with Phoebe beta, Red Hat Linux 9, nor with Red Hat specifically. The problem is that the "nv" driver never has supported DVI hardware in the past, and now it has "some" support, but it is not very good. Please report any bugs with DVI support using the "nv" driver to XFree86.org bugzilla so that the "nv" driver maintainer whom works at Nvidia, is aware of the problems and can investigate and fix them. Changing bug status to UPSTREAM pending upstream solution being made available. Please report issue at http://bugs.xfree86.org Thanks.
Comment 28 Brian Stretch 2003-04-09 13:18:07 EDT
A fellow Slashdot reader pointed me to the "FlatPanel" option, and a little digging turned up the relevant documentation in the nv man page: Option "CrtcNumber" "integer" nForce2, Quadro4, GeForce4 and NV30 may have two video outputs. The driver attempts to autodetect which one the monitor is con- nected to. In the case that autodetection picks the wrong one, this option may be used to force usage of a particular output. The options are "0" or "1". Default: autodetected. Option "FlatPanel" "boolean" The driver usually cannot autodetect the presence of a flat panel so this option should be set when used with a flat panel. With this driver a flat panel will only work if it was POSTed by the BIOS, that is, the machine must have booted to the panel. Default: off. I'm happily using nVidia's closed-source drivers now so I haven't experimented with these nv options, but I suspect some of the rest of y'all can make use of them.
Comment 29 Mike A. Harris 2003-07-17 06:31:10 EDT
I'm processing UPSTREAM flagged bug reports for upstream fixes currently, and noticed that this bug was flagged upstream but has no upstream bug URL, and I was unable to find an upstream bug report of this issue in XFree86 bugzilla located at: http://bugs.xfree86.org Closing bug report as WONTFIX as I'm unable to track upstream until a bug report has been filed upstream, and the URL provided for tracking. If this issue is still relevant in the latest XFree86 packages in rawhide, after reporting upstream at http://bugs.xfree86.org, feel free to add the bug report URL to this report and reopen if you'd like the issue to be tracked and any fixes from upstream investigated for inclusion in future Red Hat XFree86 updates.
Comment 30 Brian Stretch 2003-07-23 21:50:38 EDT
Severn forces the selection of the VGA port instead of DVI but doesn't hose the video card, which is an improvement. RH9 did the same thing (forced VGA port but otherwise worked) on the new box I built for a friend with a shiny new GeForceFX 5600 card (nForce2 motherboard); I'll assume Severn would've done the same. So things are fixed enough for users to work around the problem. Install nVidia's closed-source drivers and you can switch back to DVI. Or do the textmode install thing. Whichever.
Comment 31 Mike A. Harris 2003-09-26 21:00:26 EDT
*** This bug has been marked as a duplicate of 88360 ***
Comment 32 Red Hat Bugzilla 2006-02-21 13:51:56 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.