Bug 532711 - External DVI monitors aren't detected on Dell Latitude E6400
External DVI monitors aren't detected on Dell Latitude E6400
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Ben Skeggs
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-11-03 10:52 EST by Erik van Pienbroek
Modified: 2011-06-02 13:41 EDT (History)
5 users (show)

See Also:
Fixed In Version: kernel-2.6.34.1-11.fc13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-02 13:41:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg output (61.45 KB, text/plain)
2009-11-03 10:52 EST, Erik van Pienbroek
no flags Details
xorg.conf (271 bytes, text/plain)
2009-11-03 10:53 EST, Erik van Pienbroek
no flags Details
Xorg logs (60.00 KB, text/plain)
2009-11-03 10:53 EST, Erik van Pienbroek
no flags Details
Verbose xrandr output (3.81 KB, text/plain)
2009-11-03 10:54 EST, Erik van Pienbroek
no flags Details
dmesg with 1 DVI monitor connected, with additional kernel arguments (63.63 KB, text/plain)
2009-11-16 07:30 EST, Florian van Oudgaarden
no flags Details
dmesg with 1 DVI monitor connected, no addtional kernel arguments (84.88 KB, text/plain)
2009-11-16 07:33 EST, Florian van Oudgaarden
no flags Details
Serial console output with 2 DVI monitors connected and nouveau debug flags (49.06 KB, text/plain)
2009-11-16 08:08 EST, Florian van Oudgaarden
no flags Details
Kernel messages with kernel-2.6.33-1.fc13.x86_64 (docking station+2 DVI monitors)) (42.14 KB, text/plain)
2010-03-17 05:18 EDT, Erik van Pienbroek
no flags Details
Kernel messages with drm.debug=15 nouveau.reg_debug=0x200 on kernel-2.6.34-0.10.rc1.git0.fc14 (356.44 KB, text/plain)
2010-03-17 06:19 EDT, Erik van Pienbroek
no flags Details
dmesg of kernel 2.6.33.2-43.fc13 (40.76 KB, text/plain)
2010-04-13 10:28 EDT, Erik van Pienbroek
no flags Details
VBIOS when using the LVDS and VGA output (using docking station) (64.00 KB, application/octet-stream)
2010-05-04 08:20 EDT, Erik van Pienbroek
no flags Details
lspci (33.69 KB, text/plain)
2010-05-04 08:20 EDT, Erik van Pienbroek
no flags Details
MMIOTrace with binary nVidia driver and 2 DVI monitors pre-configured (8.89 MB, application/x-bzip2)
2010-05-04 09:24 EDT, Erik van Pienbroek
no flags Details

  None (edit)
Description Erik van Pienbroek 2009-11-03 10:52:59 EST
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.
Comment 1 Erik van Pienbroek 2009-11-03 10:53:32 EST
Created attachment 367318 [details]
xorg.conf
Comment 2 Erik van Pienbroek 2009-11-03 10:53:52 EST
Created attachment 367319 [details]
Xorg logs
Comment 3 Erik van Pienbroek 2009-11-03 10:54:13 EST
Created attachment 367320 [details]
Verbose xrandr output
Comment 4 Erik van Pienbroek 2009-11-03 10:57:00 EST
(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)
Comment 5 Ben Skeggs 2009-11-04 04:37:39 EST
Can you give this build of the kernel a try: http://koji.fedoraproject.org/koji/buildinfo?buildID=139686
Comment 6 Erik van Pienbroek 2009-11-05 04:41:34 EST
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.
Comment 7 Erik van Pienbroek 2009-11-10 09:07:23 EST
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.
Comment 8 Ben Skeggs 2009-11-10 16:22:17 EST
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.
Comment 9 Florian van Oudgaarden 2009-11-16 07:30:45 EST
Created attachment 369682 [details]
dmesg with 1 DVI monitor connected, with additional kernel arguments
Comment 10 Florian van Oudgaarden 2009-11-16 07:33:40 EST
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
Comment 11 Florian van Oudgaarden 2009-11-16 07:38:17 EST
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.
Comment 12 Florian van Oudgaarden 2009-11-16 08:08:31 EST
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.
Comment 13 Bug Zapper 2009-11-16 09:59:54 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 14 Erik van Pienbroek 2010-03-17 05:16:32 EDT
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
Comment 15 Erik van Pienbroek 2010-03-17 05:18:30 EDT
Created attachment 400697 [details]
Kernel messages with kernel-2.6.33-1.fc13.x86_64 (docking station+2 DVI monitors))
Comment 16 Erik van Pienbroek 2010-03-17 05:33:24 EDT
Kernel 2.6.33-10.fc13.x86_64 doesn't work either
Comment 17 Erik van Pienbroek 2010-03-17 06:19:07 EDT
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
Comment 18 Erik van Pienbroek 2010-04-13 10:28:02 EDT
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)
Comment 19 Erik van Pienbroek 2010-05-03 07:10:00 EDT
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
Comment 20 Ben Skeggs 2010-05-03 19:25:06 EDT
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.
Comment 21 Erik van Pienbroek 2010-05-04 01:20:31 EDT
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?
Comment 22 Ben Skeggs 2010-05-04 01:38:37 EDT
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!
Comment 23 Erik van Pienbroek 2010-05-04 08:20:17 EDT
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
Comment 24 Erik van Pienbroek 2010-05-04 08:20:49 EDT
Created attachment 411267 [details]
lspci
Comment 25 Erik van Pienbroek 2010-05-04 09:24:40 EDT
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"
Comment 26 Erik van Pienbroek 2010-06-12 11:20:44 EDT
Have the VBIOS and MMIOTrace been of any use to you? Is there anything else we can help with to research this bug?
Comment 27 Ben Skeggs 2010-06-25 21:37:41 EDT
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!
Comment 28 Erik van Pienbroek 2010-06-26 02:31:59 EDT
Okay, thanks for the update
Comment 29 Ben Skeggs 2010-06-28 01:01:27 EDT
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.
Comment 30 Erik van Pienbroek 2010-06-28 07:02:14 EDT
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
Comment 31 Erik van Pienbroek 2010-07-01 06:40:28 EDT
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!
Comment 32 Ben Skeggs 2010-07-07 03:23:59 EDT
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
Comment 33 Erik van Pienbroek 2010-07-08 14:27:33 EDT
Hi Ben,

The new scratch build does NOT work here. When switching to KMS, the DVI monitors remain blank.
Comment 34 Ben Skeggs 2010-07-08 23:36:52 EDT
Thanks, that matches a few other reports.  Some additional fixes are available:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2307587
Comment 35 Erik van Pienbroek 2010-07-09 13:38:44 EDT
That scratch builds works fine. Both DVI monitors get enabled and even compiz works!
Comment 36 Ben Skeggs 2010-07-14 00:03:42 EDT
The fixes are available in kernel-2.6.34.1-11.fc13 (http://koji.fedoraproject.org/koji/buildinfo?buildID=183346)
Comment 37 Fedora Update System 2010-08-07 01:01:11 EDT
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
Comment 38 Fedora Update System 2010-08-07 19:29:08 EDT
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
Comment 39 Fedora Update System 2010-08-10 19:54:09 EDT
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
Comment 40 Fedora Update System 2010-08-11 03:26:29 EDT
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
Comment 41 Bug Zapper 2011-06-02 13:31:15 EDT
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
Comment 42 Erik van Pienbroek 2011-06-02 13:41:39 EDT
The issue has already been resolved for some time, closing bug

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