Red Hat Bugzilla – Bug 465422
Nv driver confused when BIOS boot screen pref set to external VGA port
Last modified: 2018-04-11 08:41:08 EDT
Created attachment 319327 [details] Xorg log This is ona Lenovo T61 (nVidia Quadro NVS 140M). When booting F10-beta with an external LCD screen connected on the latop VGA port, the distro boots into a black screen (instead of the GDM graphical login screen). Looking at the logs, X seems to start normally, but the screens just aren't displays (black screen on both external and laptop LCDs). Logs are attached. Note that this is NOT a question a nv supporting dual-head: if I boot with only the laptop screen and login normally, I can hot-plug the external monitor and configure dual-head with xrandr or the Screen Resolution configuration. That works no problem. This is only a GDM/boot issue. Also note there is no /etc/X11/xorg.conf file.
Created attachment 319328 [details] /var/log/messages of boot process
Could we get /var/log/Xorg.0.log as well, please? Thanks a lot, Matěj
Err, it's already there :-) (1st attachment)
Sorry, too many bugs after beta, so I make mistakes all the time. Sorry.
Hey no problem ;-) Bug is still occurring today with latest updates...
BTW, is there any difference if you try nouveau? Some users reported surprisingly good results with that.
Matej, No I haven't had a chance to try nouveau. Is there an easy way, like a boot line cmd, to tell the autodetect code to use nouveau instead of nv ? Or do I have to write my own xorg.conf file ? (I currently use the nvidia driver as it used to be the only option for this chipset). The reason I filed this bug is that "nv" is chosen by default, and this means no installation and no live CD for people with external monitors, a scenario that is quite common amongst laptop users. The boot process happens in text mode, but as soon as X is started for GDM, there is some logic in there that picks a default mode that does not work, even though "nv" does actually support this setup reasonably well.
Gave nouveau a shot. With external LCD connected, I get a kernel hang. With the laptop screen only, nouveau "seems" to work judging from Xorg.0.log, but the screen remains hopelessly black... I would have been surprised if nouveau had worked with a Quadro chipset... Thinking of it, this could be affected by the BIOS setup.
a) no, there is no automagic way how to make nouveau work -- it is still more or less experimental feature and we don't want to let it loose on our poor users (maybe, we should reconsider this position, but certainly not in F10) b) could we still get /var/log/Xorg.0.log from this unsuccesful attetmpt, please? Thanks
Created attachment 320088 [details] Xorg log when using nouveau driver Here's /var/log/Xorg.0.log when booting the T61 with the nouveau driver (using only the laptop screen). You'll notice the lack of errors in the log file, yet the screen remains dark.
Created attachment 320089 [details] /var/log/messages excerpts of nouveau problems Attaching excerpts of /var/log/messages showing various nouveau problems, including crash traces, when logging with external monitor hooked up.
Update on the "nv" aspect of the bug. The problem seems to stem from a BIOS setting. The BIOS settings has "default boot screen" set to VGA. When I set that back to "Thinkpad LCD", the problem disappears, and the system boots with the "nv" driver fine with the external monitor (the GDM screen is mirrored on both screens), and when I login it remembers my screen resolution prefs and switches to dual-head mode automatically. Nice! Updating the subject of this bug. Is it worth keeping this bug around ? Or should I report that directly upstream instead ? Also, do you want me to open a separate bug for nouveau support of the Quadro chip ? I don't know if you have anyone at RH working on nouveau. If not, I'll report that directly upstream also. -denis
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
There's no real difference as far as nouveau's concerned between GeForce and Quadro chips. Your chip should be working fine with the drivers in F11. As for the problems in both nv and nouveau if the VBIOS doesn't program the laptop panel on startup, this is currently unavoidable in both drivers. We don't know yet how to program the panel fully ourselves, and attempting to do so leads to the display engine locking up.
Problem still exists with F-11 today.
Having boot video set to external, or nouveau in general? If it's the former, that's the expected behaviour currently. As I mentioned, neither nouveau or nv knows how to program LVDS without the VBIOS's help. If nouveau doesn't work at all, please post /var/log/Xorg.0.log from after a failed attempt!
I can confirm that nouveau works when BIOS default screen is set to laptop LCD. Including dual-head support. One issue I ran into. With dual-head setup used. If I type Ctr-Alt-F2 to go to a getty terminal, I get a garbled screen. No lockups, I can login and type commands "blindly", but screen contains random patterns. typing Ctrl-Alt-F1 brings me back to the desktop with no problems...
Ok, thanks for that! I'm very close to being able to fix the original issue you reported in nouveau, this won't be something that's feasible for the nv driver however. For your other problem, can you file a separate report please, so this bug doesn't get confused!
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. 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 '10'. 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 10'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 10 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 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 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.