Bug 532711
Created attachment 367318 [details]
xorg.conf
Created attachment 367319 [details]
Xorg logs
Created attachment 367320 [details]
Verbose xrandr output
(In reply to comment #0) > The same problem also occurs when booting the kernel with 'nomodeset' This should have read: When using 'nomodeset' no screen gets activated at all (not even the internal notebook screen) Can you give this build of the kernel a try: http://koji.fedoraproject.org/koji/buildinfo?buildID=139686 Thanks for the very quick fix! Unfortunately I can't test the result right now as the person who owns the notebook in question is currently ill. I'll report back the results as soon as I can. I've just received word from the owner of the notebook that the fix in the latest kernel has made things worse. When the notebook is started while connected to the docking station (with 2 DVI monitors) all screens remain blank (even the internal screen). Unfortunately I don't have physical access to the notebook until early next week so I can't provide you a new dmesg yet. Do things work correctly now when plugged into a single DVI monitor? If so, can I grab the dmesg output with "nouveau.reg_debug=0x200 3" appended to the boot options with both plugged DVI plugged in. Thanks. Created attachment 369682 [details]
dmesg with 1 DVI monitor connected, with additional kernel arguments
Created attachment 369683 [details]
dmesg with 1 DVI monitor connected, no addtional kernel arguments
On boot only the internal notebook screen is activated. The DVI monitor remains inactive. When trying to start X, screen corruption occurs
When trying to boot with both DVI monitors connected, the system hangs during boot, so we're unable to retrieve a dmesg from that situation. Created attachment 369688 [details]
Serial console output with 2 DVI monitors connected and nouveau debug flags
With the help of a NULL-modem we managed to collect the kernel output when booted with 2 DVI monitors connected. This is with the requested kernel flags to enable nouveau debugging. As soon as plymouth gets activated all screens get disabled.
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 We've just tried the latest F-13 kernel and nouveau driver, but the detection of external monitors is still broken. All screens remain black when the laptop is situated in a docking station with 2 DVI monitors attached. No special kernel options are used. A new kernel dmesg (caught using a serial console) has been added to this bug. Kernel version: kernel-2.6.33-1.fc13.x86_64 Nouveau version: xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.x86_64 Created attachment 400697 [details]
Kernel messages with kernel-2.6.33-1.fc13.x86_64 (docking station+2 DVI monitors))
Kernel 2.6.33-10.fc13.x86_64 doesn't work either Created attachment 400706 [details]
Kernel messages with drm.debug=15 nouveau.reg_debug=0x200 on kernel-2.6.34-0.10.rc1.git0.fc14
Kernel-2.6.34-0.10.rc1.git0.fc14 also doesn't give any improvement.
A dmesg with the kernel parameters drm.debug=15 nouveau.reg_debug=0x200 is attached
In the dmesg a suspicious message was found: [Firmware Bug]: Duplicate ACPI video bus devices for the same VGA controller, please try module parameter "video.allow_duplicates=1"if the current driver doesn't work.
However, adding this kernel parameter doesn't change anything
Created attachment 406262 [details]
dmesg of kernel 2.6.33.2-43.fc13
As today is the F13 nouveau test day, we decided to give this bug another try.
when using kernel-2.6.33.2-43.fc13 the issue still remains. We also tried updating the BIOS to the latest version (from version 1.12 to 1.20), but that also didn't help.
New dmesg is attached (without any special kernel parameters)
Kernel 2.6.33.3-73 (which contains some DP monitor detection fixes) doesn't solve this issue. The two DVI monitors enter suspend mode as soon as KMS kicks in Your monitors are actually being detected just fine, it's just for some reason no image is being displayed on them. This issue has been reported a few places now, it appears DVI over various laptop docking stations that be DP or DVI are failing. Unfortunately I don't have such a configuration to test on and track this down as of yet. Is there anything we can do to aid you on this bug like collecting a VBIOS dump or a trace using the binary nvidia driver? They could prove useful, it's a long process to track down without it in front of me to try, but we can see :) http://nouveau.freedesktop.org/wiki/MmioTrace has instructions on how to obtain a trace of the NVIDIA binary driver. Tracing the VBIOS may prove easier however, that is if you can convince the VBIOS to program the external display instead of the LVDS panel (there may be options in the SBIOS setup to control this). If you can manage that OK, let me know and I'll post instructions on tracing what the VBIOS does. Thank you! Created attachment 411266 [details]
VBIOS when using the LVDS and VGA output (using docking station)
I also tried to catch a VBIOS when one DVI monitor is connected, but the VBIOS remains the same. In the regular BIOS (SBIOS?) there's no option to disable the internal display
Created attachment 411267 [details]
lspci
Created attachment 411293 [details]
MMIOTrace with binary nVidia driver and 2 DVI monitors pre-configured
This is a MMIOTrace caught using kernel 2.6.33.3-79.fc13.x86_64.debug and nVidia driver 195.36.24 (coming from RPMFusion)
At the start of the trace, X wasn't running (runlevel 3).
After starting the trace the mark 'startx' was added and X was manually started using startx.
After X was fully started, both DVI monitors were activated and the mark 'X is running on dvi1 and dvi2' was added.
Soon thereafter, I added the mark 'starting logout'. Right after adding that mark, I performed a logout from the window manager and X shut down nicely.
After X was fully shut down, the trace was closed
Here are the relevant xorg.conf fragments about the display configuration of the binary nvidia driver:
Option "TwinView" "1"
Option "TwinViewXineramaInfoOrder" "DFP-1"
Option "metamodes" "DFP-1: nvidia-auto-select +0+0, DFP-2: nvidia-auto-select +1280+0"
Have the VBIOS and MMIOTrace been of any use to you? Is there anything else we can help with to research this bug? I haven't had a chance to look as of yet sorry, I've been on PTO for the last couple of weeks. I'm back in the office on Monday, and will try and take a look at this problem during the week. It's high up on my list, just unfortunate I don't have an effected configuration to directly work with! Okay, thanks for the update Are you able to test the kernel build at: http://koji.fedoraproject.org/scratch/bskeggs/task_2276325/ and see if you notice any improvement? It's not guaranteed, but it looks like this issue may be the same as something else I was investigating today. Thanks for the scratch build. Unfortunately I can't test it right now as I don't have access to the hardware at the moment. I expect that the hardware is available for me again in two weeks. I'll keep you informed Hi Ben, Today I just tested the new kernel on a similar laptop (which has the same problem) and with the new kernel, the problem is solved. The DVI monitor gets activated! Thanks for your help! Hi Erik, are you able to test this new scratch build for me also? It hopefully fixes the same problem (I don't have the configuration to be able to test), but in a way that doesn't break other systems. http://koji.fedoraproject.org/koji/taskinfo?taskID=2299699 Hi Ben, The new scratch build does NOT work here. When switching to KMS, the DVI monitors remain blank. Thanks, that matches a few other reports. Some additional fixes are available: http://koji.fedoraproject.org/koji/taskinfo?taskID=2307587 That scratch builds works fine. Both DVI monitors get enabled and even compiz works! The fixes are available in kernel-2.6.34.1-11.fc13 (http://koji.fedoraproject.org/koji/buildinfo?buildID=183346) kernel-2.6.34.2-34.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/kernel-2.6.34.2-34.fc13 kernel-2.6.34.2-34.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/kernel-2.6.34.2-34.fc13 kernel-2.6.34.3-37.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/kernel-2.6.34.3-37.fc13 kernel-2.6.34.3-37.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kernel'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/kernel-2.6.34.3-37.fc13 This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. 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 '13'. 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 13'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 13 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 The issue has already been resolved for some time, closing bug |
Created attachment 367317 [details] dmesg output We've just tried to install the Fedora 12 beta on a Dell Latitude E6400. This notebook has a NVIDIA Quadro NVS 160M (device id: 0x298580a2). After the installation completed we updated it to the latest rawhide (November 3rd) including xorg-x11-drv-nouveau-0.0.15-16.20091030git5587f40.fc12.x86_64 and kernel-2.6.31.5-112.fc12.x86_64 pulled from Koji. The notebook is docked in a docking station where two DVI monitors are connected. However, these two monitors aren't detected during boot (when KMS gets activated). Only the internal screen of the notebook is used. After the boot has finished, the monitors are 'disconnected' according to xrandr: $ xrandr Screen 0: minimum 320 x 200, current 1440 x 900, maximum 8192 x 8192 LVDS-0 connected 1440x900+0+0 (normal left inverted right x axis y axis) 303mm x 190mm 1440x900 60.0*+ 40.0 1152x864 60.0 1024x768 59.9 800x600 59.9 640x480 59.4 720x400 59.6 640x400 60.0 640x350 59.8 VGA-0 disconnected (normal left inverted right x axis y axis) DP-0 disconnected (normal left inverted right x axis y axis) DP-1 disconnected (normal left inverted right x axis y axis) The dmesg contains some suspicious messages from nouveau: [drm] nouveau 0000:01:00.0: 0xE5BC: Condition still not met after 2000ms, skipping following opcodes [drm] nouveau 0000:01:00.0: 0xC1AA: parsing output script 0 [drm] nouveau 0000:01:00.0: 0xC7DC: parsing output script 0 [drm] nouveau 0000:01:00.0: 0xC5CE: parsing output script 0 [drm] nouveau 0000:01:00.0: 0xC7DC: parsing output script 0 [drm] nouveau 0000:01:00.0: 0xC5CE: parsing output script 0 and a bit further: [drm] nouveau 0000:01:00.0: Detected a DisplayPort connector [drm] nouveau 0000:01:00.0: Detected a DisplayPort connector [drm] nouveau 0000:01:00.0: DCB I2C port type 6 unknown [drm] nouveau 0000:01:00.0: Detected DP connected, ignoring! [drm] nouveau 0000:01:00.0: DCB I2C port type 6 unknown [drm] nouveau 0000:01:00.0: Detected DP connected, ignoring! [drm] nouveau 0000:01:00.0: allocated 1440x900 fb: 0x40250000, bo ffff880116272400 The same problem also occurs when booting the kernel with 'nomodeset' Full logs are attached.