Bug 497785
|
Description
Niels Haase
2009-04-27 08:35:53 UTC
Which display does GRUB show on when you've booted with the external monitor plugged in? Created attachment 342616 [details]
boot log with kernel 2.6.29.1-111 and nouveau-0.0.12-31.20090421git47bb00f
Thanks you for helping me with this. Sorry for the late replay but my day job has me tight atm.
I'm not sure if I understand the question right. Anyway, the grub screen shows up on the first external monitor (the internal is off, because the lid is closed). After selecting the kernel, I can see this "Unknown boot option `nouveau.modeset=1': ignoring" message an two more lines (but thy appear so fast that a have no change to read it, something like FIXME or so) and then the screen blanked out, the first stay active and the second remains in stand-by.
I attached a the boot log from my last try with:
kernel-2.6.29.1-111.fc11.x86_64
xorg-x11-drv-nouveau-0.0.12-31.20090421git47bb00f.fc11.x86_64
I there anything else that might be helpful for you?
Thanks for your work on this!
Created attachment 343568 [details]
xorg.0.log of non working dual display
I'm seeing issues with nouveau on dual displays too. Not sure when it started but it worked on Wed 29th when I was last in the office and now doesn't when spanned.
kernel-2.6.29.2-126.fc11.x86_64
xorg-x11-drv-nouveau-0.0.12-34.20090507git1072103.fc11.x86_64
Xorg.0.log attached. I have the onboard laptop display on LVDS-0 and a external monitor on VGA-0
My xorg.conf has the following:
# cat /etc/X11/xorg.conf
Section "Device"
Identifier "Builtin Default nouveau Device 0"
Driver "nouveau"
EndSection
Section "Screen"
Identifier "Builtin Default nouveau Screen 0"
Device "Builtin Default nouveau Device 0"
SubSection "Display"
Virtual 3120 1050
EndSubSection
EndSection
Section "ServerLayout"
Identifier "Builtin Default Layout"
Screen "Builtin Default nouveau Screen 0"
EndSection
peter, I don't think your issue is the same, but it's hard to be sure from the details you gave. Niels' issue is that X entirely fails to start for him, if two monitors are connected - not that it starts in clone mode, but he has problems if he tries to set it to span both displays. Ben - this sounds very similar to my issue: https://bugzilla.redhat.com/show_bug.cgi?id=480393 Niels confirms the behaviour is the same - works with a single display, hangs at black screen when starting X with two displays connected, works if you boot to nvidia then switch to nouveau without rebooting. Do we close this as a dupe, or does the fact that the chipset is not the same make this a different bug? Do you need further information from Niels if it's not a dupe? Thanks! Peter: going by your comment on fedora-test-list: "It was working fine two weeks ago when I was last in the office but now when I run the "xrandr --output LVDS-0 --left-of VGA-0" command to move the config from mirrored to spanned I get a corrupted display." yours is definitely a different issue. This bug causes X to fail to start completely if more than one display is attached. Ben suggests that your bug is likely: https://bugzilla.redhat.com/show_bug.cgi?id=499301 can you take a look, and if so, add your comment there? Otherwise, file a new bug. Thanks! Niels: suggestion from Ben - try booting with 'nouveau.uscript=1' as a kernel parameter. It's a very experimental and mostly untested probable fix for your problem. Ben doesn't really recommend using it, but it can't make things any worse :) Let us know what happens with that. Also worth noting that nouveau.uscript=1 only has any effect with kms enabled (nouveau.modeset=1). The option causes nouveau to run the output init scripts provided by the VBIOS, which should complete the initialisation of your panel in the cases where the VBIOS hasn't done it already (such as when you boot with an external display connected). (In reply to comment #4) > peter, I don't think your issue is the same, but it's hard to be sure from the > details you gave. Niels' issue is that X entirely fails to start for him, if > two monitors are connected - not that it starts in clone mode, but he has > problems if he tries to set it to span both displays. It sounded similar when he confirmed it in this thread http://www.redhat.com/archives/fedora-test-list/2009-May/msg00478.html I wasn't sure at first but its very similar. Either way 2 weeks ago this worked, in F10 this worked. Dual screen on nv/nouveau worked in F10 and less than 2 weeks ago in F11 rawhide so it needs to be fixed. I will be testing the late april rpm that Niels mentions and will test when I'm back in the office tomorrow. See my last comment. For you, per your email, X starts up in clone mode and only fails when you try and switch to spanning. That is not the same bug. That doesn't make it more or less important, it just means that it shouldn't be discussed in this report as it will lead only to confusion. Thanks for your suggestion on this Ben. I tried to boot with nouveau.modeset=1 and nouveau.uscript=1 kernel parameters. But the Issue is still the same. Last message that is displayed on the first external screen are the "Unknown boot option" messages (now double, because of two nouveau parameters). There is a little difference, don't know if it relevant or not, the primary screen goes immediately after showing the "Unknown..." message into stand-by. But I'm stile able to SSH into the system. Therefore I saved the /var/log/message from boot time and also the Xorg.0.log. Another problem is that with the usage of nouveau.uscript=1 KMS/X also fails if no external display are connect, only the internal display. So it seams that it can make things any worse :) It there anything that I can try additional? I'm very interesting to solve this problem, so I will try everything that may be helpful for you to breakdown this. Again, thanks for your time and help with this! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Created attachment 343861 [details]
Xorg.0.log after booting with KMS and uscript enabled
Created attachment 343863 [details]
dmesg after booting with KMS and uscript enabled
Hmm, I'd be interested in seeing an Xorg.0.log from nv with all three displays connected (2xDVI + panel). Looking at the output table your VBIOS provides I'm really not certain how that's supposed to work yet! Also, are you able to test with each DVI port connected individually? I'd probably expect 1 of them to boot OK (perhaps only with uscript=1), and the other to fail regardless. Thanks, Ben! It needs some time to test the all the modes, but here are the results. All tests with nouveau but _without_ KMS and _without_ uscript. Since the usage of uscript work with not any configuration (after GRUB no KMS and X). tested with: 2.6.29.3-140.fc11.x86_64 xorg-x11-drv-nouveau-0.0.12-34.20090507git1072103.fc11.x86_64 xorg-x11-server-Xorg-1.6.1-14.fc11.x86_64 Internal only works Internal and DVI1 (or DVI2) GDM shows up, but after login, X crash DVI1 (or DVI2) only[1] works DVI1 and DVI2 GDM shows up, but after login, X crash DVI1 + analogue works 1: Even the lid is closed, the internal display and DVI are in mirror mode, but the internal can be disable and the DVI set to the maximum resolution without problems. Is any Xorg.log file from one of the above constellations required? Thanks for looking at it. Created attachment 344037 [details]
Xorg.0.log after booting with nv (lid closed, DVI1 and DVI2 connected
X is coming up with nv, but the internal display and DVI1 are in mirror mode (but internal is not centred, it's moved a fourth down with black area above. But xrandr means mirror is not active, after playing a little bit with xrandr to disable the internal screen and enable both DVI, X locks up. Power-off required.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Hey! I'd be interested in hearing an update on the situation if you grab the kernel build from http://koji.fedoraproject.org/koji/buildinfo?buildID=112059, and enable *both* KMS and uscript. If things are still bad, dmesg output with "drm.debug=1 nouveau.modeset=1 nouveau.uscript=1" would be very useful! Thanks! No update? Created attachment 359044 [details]
dmesg with drm.debug=1 nouveau.modeset=1 nouveau.uscript=1
dmesg with drm.debug=1 nouveau.modeset=1 nouveau.uscript=1 on kernel 2.6.30.5-32.fc11.x86_64
Created attachment 359045 [details]
messages with drm.debug=1 nouveau.modeset=1 nouveau.uscript=1
messages with drm.debug=1 nouveau.modeset=1 nouveau.uscript=1 on kernel 2.6.30.5-32.fc11.x86_64
(In reply to comment #19) > No update? Oops, it seams that I missed the information in comment 18. Sorry for the late replay. I tried to use drm.debug=1 nouveau.modeset=1 nouveau.uscript=1 with kernel 2.6.30.5-32.fc11.x86_64 (since the one you pointed out on comment 18 is deleted on koji). But at least no lock. After some kernel messages in non-native resolution, the screen turns black. Please find hopefully all necessary information in the last two attached files. I tried this with both display connected over DVI. Thank you. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Created attachment 360547 [details]
messages after boot with drm.debug=1
Booting while the lid is closed and both DVI Displays are connected.
Created attachment 360548 [details]
dmesg after boot with drm.debug=1
Booting while the lid is closed and both DVI Displays are connected.
Created attachment 360549 [details]
Xorg.0.log after boot with drm.debug=1
Booting while the lid is closed and both DVI Displays are connected.
Ben, I moved the bug to rawhide after I try this again at the nouveau test day. Kernel 2.6.31-2.fc12.x86_64 xorg-x11-drv-nouveau-0.0.15-9.20090910git806eaf6.fc12.x86_64 It's all working here (KMS, Suspend/Hibernate) but not the mutihead thing. The failure is like the F11 times. After grub, some kernel in non-native resolution shows up on first DVI screen and then it goes black (meanwhile lid was closed and second DVI stays at stand by). The system can be accessed over SSH without problems. I've attached dmesg, messages and Xorg.0.log while drm.debug=1 was set during the start-up. Please ask if you need more information or some packages to test. Thank you again for all your honourable work at the nouveau driver project! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Can you update to the latest packages in rawhide, then install http://koji.fedoraproject.org/koji/buildinfo?buildID=139738 (kernel-2.6.31.5-117.fc12) and boot with drm.debug=1 nouveau.regdebug=0x200 in your boot options and post the dmesg log again please? That boot option will enable some additional debugging output as a clue to what's going wrong. Correction, it's nouveau.reg_debug=0x200 Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages (at least F12Beta, but even better if the very latest versions). Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you. If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. [This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.] This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. [Note please, that this is machine generated comment for large amount of bugs; due to some technical issues, it is possible we've missed some of the responses -- it is happens, please, just a make a comment about that; that we will see. Thank you] Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as INSUFFICIENT_DATA. |