Bug 497785 - KMS and X fails while two monitors are connected (Quadro NVS 160M [10de:06eb])
KMS and X fails while two monitors are connected (Quadro NVS 160M [10de:06eb])
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Ben Skeggs
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks: fedora-x-target
  Show dependency treegraph
 
Reported: 2009-04-27 04:35 EDT by Niels Haase
Modified: 2010-05-10 19:08 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-10 19:08:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Xorg log while laptop is on docking station (no KMS, runlevel 3, startx) (37.64 KB, text/plain)
2009-04-27 04:35 EDT, Niels Haase
no flags Details
boot log with kernel 2.6.29.1-111 and nouveau-0.0.12-31.20090421git47bb00f (160.89 KB, text/plain)
2009-05-06 05:01 EDT, Niels Haase
no flags Details
xorg.0.log of non working dual display (195.02 KB, text/plain)
2009-05-12 07:40 EDT, Peter Robinson
no flags Details
Xorg.0.log after booting with KMS and uscript enabled (61.01 KB, text/plain)
2009-05-13 15:53 EDT, Niels Haase
no flags Details
dmesg after booting with KMS and uscript enabled (103.34 KB, text/plain)
2009-05-13 15:54 EDT, Niels Haase
no flags Details
Xorg.0.log after booting with nv (lid closed, DVI1 and DVI2 connected (27.19 KB, text/plain)
2009-05-14 15:48 EDT, Niels Haase
no flags Details
dmesg with drm.debug=1 nouveau.modeset=1 nouveau.uscript=1 (122.79 KB, text/plain)
2009-08-28 06:15 EDT, Niels Haase
no flags Details
messages with drm.debug=1 nouveau.modeset=1 nouveau.uscript=1 (24.99 KB, text/plain)
2009-08-28 06:16 EDT, Niels Haase
no flags Details
messages after boot with drm.debug=1 (89.16 KB, text/plain)
2009-09-10 14:34 EDT, Niels Haase
no flags Details
dmesg after boot with drm.debug=1 (122.39 KB, text/plain)
2009-09-10 14:35 EDT, Niels Haase
no flags Details
Xorg.0.log after boot with drm.debug=1 (60.45 KB, text/plain)
2009-09-10 14:36 EDT, Niels Haase
no flags Details

  None (edit)
Description Niels Haase 2009-04-27 04:35:53 EDT
Created attachment 341404 [details]
Xorg log while laptop is on docking station (no KMS, runlevel 3, startx)

Description of problem:
Laptop on docking station with two DVI LCD's connected (both connected to the docking station). If the system get started, the grub screen is the last visible on the screen, after the start of KMS the screen stays active (no sleep mode or anything else) but shows nothing more. Deactivation of KMS and boot into runlevel 3 is possible. But the start of X fails with the same symptoms. Switch to a tty is not possible, also the kill of X over ssh brings not back the screen.

Version-Release number of selected component (if applicable):
xorg-x11-drv-nouveau-0.0.12-31.20090421git47bb00f.fc11.x86_64
kernel-2.6.29.1-102.fc11.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Push laptop into docking station
2. power on laptop
  
Actual results:
Screen stays black while KMS is active, also X

Expected results:
X should work with the dual screens

Additional info:
nVidia Corporation Quadro NVS 160M, no xorg.conf config file.
Pushing the Laptop built in key for change of display output change nothing. Starting the laptop without the docking station and push it back after X is started show the screen in xrandr, but the activation of the two external screen show only the message "could not find a suitable configuration of screens". Try to active one external and the internal display changes all screens to black.
smolt profile (while in docking station) http://www.smolts.org/client/show/?uuid=pub_34502599-b7ea-404d-884b-e29b6590331c

Thanks for help!
Comment 1 Ben Skeggs 2009-05-04 00:45:04 EDT
Which display does GRUB show on when you've booted with the external monitor plugged in?
Comment 2 Niels Haase 2009-05-06 05:01:41 EDT
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!
Comment 3 Peter Robinson 2009-05-12 07:40:42 EDT
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
Comment 4 Adam Williamson 2009-05-12 15:31:27 EDT
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.
Comment 5 Adam Williamson 2009-05-12 16:18:30 EDT
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!
Comment 6 Adam Williamson 2009-05-12 17:26:12 EDT
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!
Comment 7 Adam Williamson 2009-05-12 17:28:04 EDT
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.
Comment 8 Ben Skeggs 2009-05-12 18:08:53 EDT
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).
Comment 9 Peter Robinson 2009-05-12 18:11:35 EDT
(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.
Comment 10 Adam Williamson 2009-05-12 19:12:51 EDT
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.
Comment 11 Niels Haase 2009-05-13 15:51:53 EDT
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
Comment 12 Niels Haase 2009-05-13 15:53:58 EDT
Created attachment 343861 [details]
Xorg.0.log after booting with KMS and uscript enabled
Comment 13 Niels Haase 2009-05-13 15:54:42 EDT
Created attachment 343863 [details]
dmesg after booting with KMS and uscript enabled
Comment 14 Ben Skeggs 2009-05-13 17:23:09 EDT
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!
Comment 15 Niels Haase 2009-05-14 15:43:09 EDT
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.
Comment 16 Niels Haase 2009-05-14 15:48:07 EDT
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.
Comment 17 Bug Zapper 2009-06-09 10:38:23 EDT
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
Comment 18 Ben Skeggs 2009-06-29 05:07:37 EDT
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!
Comment 19 Ben Skeggs 2009-08-23 22:59:37 EDT
No update?
Comment 20 Niels Haase 2009-08-28 06:15:37 EDT
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
Comment 21 Niels Haase 2009-08-28 06:16:42 EDT
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
Comment 22 Niels Haase 2009-08-28 06:25:09 EDT
(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
Comment 23 Niels Haase 2009-09-10 14:34:16 EDT
Created attachment 360547 [details]
messages after boot with drm.debug=1

Booting while the lid is closed and both DVI Displays are connected.
Comment 24 Niels Haase 2009-09-10 14:35:13 EDT
Created attachment 360548 [details]
dmesg after boot with drm.debug=1

Booting while the lid is closed and both DVI Displays are connected.
Comment 25 Niels Haase 2009-09-10 14:36:07 EDT
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.
Comment 26 Niels Haase 2009-09-10 14:47:47 EDT
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
Comment 27 Ben Skeggs 2009-11-04 22:39:58 EST
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.
Comment 28 Ben Skeggs 2009-11-04 22:40:26 EST
Correction, it's nouveau.reg_debug=0x200
Comment 29 Matěj Cepl 2009-11-05 12:13:04 EST
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.]
Comment 30 Bug Zapper 2009-11-16 04:56:51 EST
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
Comment 31 Matěj Cepl 2010-02-26 07:27:22 EST
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]
Comment 32 Matěj Cepl 2010-05-10 19:08:06 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.