# Nouveau isn't detecting display ports

## axl

Hello good gentoo folks. I'm having a bit of a weird problem with a video card nvidia 960 gtx. I haven't been using it for a year now. When I last used it, it used to work with both nvidia drivers and nouveau kms modesetting driver. 

I've tried it now, and it seems to me it doesn't recognize when a monitor is attached to the display ports.

So according to X:

```
[   272.873] (II) NOUVEAU(0): EDID for output DVI-I-1

[   272.876] (II) NOUVEAU(0): EDID for output DP-1

[   273.030] (II) NOUVEAU(0): EDID for output DP-2

[   273.190] (II) NOUVEAU(0): EDID for output DP-3

[   273.191] (II) NOUVEAU(0): EDID for output HDMI-1

[   273.191] (II) NOUVEAU(0): Output DVI-I-1 disconnected

[   273.191] (II) NOUVEAU(0): Output DP-1 disconnected

[   273.191] (II) NOUVEAU(0): Output DP-2 disconnected

[   273.191] (II) NOUVEAU(0): Output DP-3 disconnected

[   273.191] (II) NOUVEAU(0): Output HDMI-1 disconnected

[   273.191] (WW) NOUVEAU(0): No outputs definitely connected, trying again...
```

I suspect something at kernel level changed enough for my board to be classified as something else. For one thing because it has 2 DVI ports. but according to X its only looking for a monitor on one of them. I also tried connecting and disconnecting another monitor on different ports. switched cables. also both monitors/cables work just fine with nvidia-drivers.

According to the kernel, this is relevant:

```
[    0.000000] Command line: BOOT_IMAGE=/kernel-genkernel-x86_64-4.16.11-gentoo root=/dev/mapper/magdalina ro rootwait crypt_root=/dev/nvme0n1 root_key=magdalina.key nouveau.runpm=0 drm.edid_firmware=edid/xb270h.edid.bin

[    0.000000] Kernel command line: init=/usr/lib/systemd/systemd net.ifnames=0 consoleblank=0 domdadm dolvm BOOT_IMAGE=/kernel-genkernel-x86_64-4.16.11-gentoo root=/dev/mapper/magdalina ro rootwait crypt_root=/dev/nvme0n1 root_key=magdalina.key nouveau.runpm=0 drm.edid_firmware=edid/xb270h.edid.bin

[    8.336313] nouveau 0000:02:00.0: NVIDIA GM206 (126010a1)

[    8.431357] nouveau 0000:02:00.0: bios: version 84.06.14.00.fe

[    8.432212] nouveau 0000:02:00.0: fb: 4096 MiB GDDR5

[    8.432308] nouveau 0000:02:00.0: bus: MMIO write of 8000014a FAULT at 10eb14 [ IBUS ]

[    8.504903] nouveau 0000:02:00.0: DRM: VRAM: 4096 MiB

[    8.504998] nouveau 0000:02:00.0: DRM: GART: 1048576 MiB

[    8.505094] nouveau 0000:02:00.0: DRM: TMDS table version 2.0

[    8.505188] nouveau 0000:02:00.0: DRM: DCB version 4.1

[    8.505283] nouveau 0000:02:00.0: DRM: DCB outp 00: 01000f02 00020030

[    8.505381] nouveau 0000:02:00.0: DRM: DCB outp 01: 02000f00 00000000

[    8.505479] nouveau 0000:02:00.0: DRM: DCB outp 02: 02811f76 04400020

[    8.505578] nouveau 0000:02:00.0: DRM: DCB outp 03: 02011f72 00020020

[    8.505676] nouveau 0000:02:00.0: DRM: DCB outp 04: 04822f86 04400010

[    8.505775] nouveau 0000:02:00.0: DRM: DCB outp 05: 04022f82 00020010

[    8.505872] nouveau 0000:02:00.0: DRM: DCB outp 06: 04833f96 04400020

[    8.505969] nouveau 0000:02:00.0: DRM: DCB outp 07: 04033f92 00020020

[    8.506065] nouveau 0000:02:00.0: DRM: DCB outp 08: 02044f62 00020010

[    8.506161] nouveau 0000:02:00.0: DRM: DCB outp 15: 01df5ff8 00000000

[    8.506258] nouveau 0000:02:00.0: DRM: DCB conn 00: 00001030

[    8.506355] nouveau 0000:02:00.0: DRM: DCB conn 01: 00020146

[    8.506451] nouveau 0000:02:00.0: DRM: DCB conn 02: 01000246

[    8.506547] nouveau 0000:02:00.0: DRM: DCB conn 03: 02000346

[    8.506642] nouveau 0000:02:00.0: DRM: DCB conn 04: 00010461

[    8.506737] nouveau 0000:02:00.0: DRM: DCB conn 05: 00000570

[    8.549635] nouveau 0000:02:00.0: DRM: failed to create encoder 1/8/0: -19

[    8.549724] nouveau 0000:02:00.0: DRM: Virtual-1 has no encoders, removing

[    8.627418] nouveau 0000:02:00.0: DRM: MM: using COPY for buffer copies

[    8.642614] nouveau 0000:02:00.0: DRM: DDC responded, but no EDID for DP-1

[    8.961406] [drm] Initialized nouveau 1.3.1 20120801 for 0000:02:00.0 on minor 0

[    8.976448] nouveau 0000:02:00.0: DRM: DDC responded, but no EDID for DP-1

[    9.306461] nouveau 0000:02:00.0: DRM: DDC responded, but no EDID for DP-1
```

Any kind of pointers might help.

----------

## joanandk

Hi,

I have similar problem with Nvidia Quadro M2000M. With the stable Kernel 4.9.95-gentoo, my external display is working fine. But with newer Kernel (4.12 and newer), I am unable to reliably get the external monitor working. In most cases the whole system crashes either by loading the nouveau driver or as soon as I change from integrated (Intel) to dedicated video card.

For me, it would be nice to have 4.12 or newer working, as this supports multiple monitor, while 4.9.x only supports one monitor on the DP port.

If you are using 4.12 or newer Kernel, I have the impression by starting sysrescue-cd and rebooting (warm reboot) seems to help in 25% of the cases to get nouveau detect the external monitors.

BR

----------

## axl

I've spent a few hours researching this thing online. I've heard similar stories from other distros. Used to work... broke about mid summer last year. Also knew it only used to work on ONE monitor. 

Anyway, other then nvidia-drivers, was wondering at what point it broke. I'll invest today trying out various kernels.

----------

## axl

I wasn't able to test kernels yet because of a raid issue. Still have to wait an hour to finish the resync. 

Meanwhile I got the change logs for the entire kernel 4 series, ordered by date. I don't see any changes to nouveau since then that would lead me to believe that 4.9.95 would actually work for me. That is because nouveau didn't change at all since then. And others started to complain about this problem during last summer, and 4.9.95 is from april this year. so the issue has to be older. 

As soon as this array finishes the resync I'll start testing. Maybe I can pin point where exactly it broke and why.

----------

## axl

hi. so far, what i have been able to pin point is that it broke during the 4.12 line. every kernel in 4.9 line works. even 4.9.105. same in 4.10. 4.11. 

i only tried 4.12.0 and 4.12.the_last_one. 

same for every major revision, tried first one, last one. nothing up of 4.12.14 works. not 4.13, not 4.14, not 4.15, not 4.16. 

tomorrow maybe i'll try every 4.12 kernel, maybe it will be easier to post a bug report on kernel. I am dreading that.

----------

## Hu

If v4.12 is broken for you, and v4.11.* work, then the bad change likely was added during the merge window.  There are typically thousands of commits in the merge window, so you cannot try all of them in reasonable time.  git bisect can help you quickly hunt down the first bad commit.

----------

## axl

4.12.0 works fine. 4.12.14 doesn't. 

so breakage is in there somewhere. 

today i tried:

/boot/kernel-genkernel-x86_64-4.10.17

/boot/kernel-genkernel-x86_64-4.11.0

/boot/kernel-genkernel-x86_64-4.11.12

/boot/kernel-genkernel-x86_64-4.12.0

/boot/kernel-genkernel-x86_64-4.12.14

/boot/kernel-genkernel-x86_64-4.13.0

/boot/kernel-genkernel-x86_64-4.13.16

/boot/kernel-genkernel-x86_64-4.14.0

/boot/kernel-genkernel-x86_64-4.14.34-gentoo

/boot/kernel-genkernel-x86_64-4.14.44

/boot/kernel-genkernel-x86_64-4.14.44-gentoo

/boot/kernel-genkernel-x86_64-4.15.0

/boot/kernel-genkernel-x86_64-4.15.10

/boot/kernel-genkernel-x86_64-4.15.11

/boot/kernel-genkernel-x86_64-4.15.12

/boot/kernel-genkernel-x86_64-4.15.18

/boot/kernel-genkernel-x86_64-4.15.9

/boot/kernel-genkernel-x86_64-4.16.12-gentoo

/boot/kernel-genkernel-x86_64-4.9.103-gentoo

/boot/kernel-genkernel-x86_64-4.9.85

/boot/kernel-genkernel-x86_64-4.9.85-gentoo

/boot/kernel-genkernel-x86_64-4.9.86

/boot/kernel-genkernel-x86_64-4.9.87

/boot/kernel-genkernel-x86_64-4.9.88

/boot/kernel-genkernel-x86_64-4.9.95-gentoo

really can't be that hard to get and compile all 14 versions of 4.12.

i'll admit i'm an old dog, and it's hard to teach new tricks to old dogs, but, let me at least ask, how does bisect help me here? (not being sarcastic. i just got the vanilla version, although tried some versions from portage tree).

----------

## Hu

I misunderstood your earlier post.  I thought you meant that v4.11 worked, v4.12.* for all *, including 0, failed.  If so, that would mean the bad commit is somewhere after v4.11 and before v4.12, which would give you 15736 commits to consider.  That is not reasonable to test by hand.

Since v4.12.0 works and later v4.12.x do not, you have a much smaller search space.  Searching each stable v4.12.x is feasible, although still suboptimal.  When you find the first bad v4.12.x, you still need to identify which patch added to that stable release caused your problem.  If you instead ignored specific releases and used bisect to guide a search, you could test approximately log2(837 commits), which is feasible and, on completion, would identify a specific Git commit responsible for your problem.  In the ideal case, you will only need 10 tests, which is both fewer tests than your method and leads you to an exact culprit, rather than a general area.

----------

## ct85711

One of the key things on why it would be helpful to find the commit that broke, is so that the kernel devs can look at the broken commit and figure out why it broke it and fix it much sooner otherwise.  One of the hardest things when troubleshooting something is when you are told something broke, but not what.  You may tell them, that something broke in the displayport area, and one of the devs would look at the area.  The issue is, is that without knowing where, they will push it off to the back burner.  This is especially true, when you consider the kernel devs are working on 4.16/4.17+...  Unless it was fixed in 4.13+ (i.e., verify it is still broken in 4.16 kernel), it is a good chance the devs don't know the problem exists and/or know where.  Either way, that means it is a good chance it won't be fixed for a while until the devs inadvertently fixes it while working on something else or someone finally helps give them more information (which could be unlikely, since it hasn't been fixed yet).

In short, without helping them find it, and only complaining it broke.  Falls in the same category of garbage in = garbage out.  The same of giving them a pile of turds and expecting them do something with it.

----------

## axl

```
38f5d65ad997efdded1ac08eeb0ca3f6190ff5f7 is the first bad commit

commit 38f5d65ad997efdded1ac08eeb0ca3f6190ff5f7

Author: Ben Skeggs <bskeggs@redhat.com>

Date:   Wed Jul 19 16:49:59 2017 +1000

    drm/nouveau/i2c/gf119-: add support for address-only transactions

    commit 13a86519202c5d119d83640d6f781f3181205d2c upstream.

    Since switching the I2C-over-AUX helpers, there have been regressions on

    some display combinations due to us not having support for "address only"

    transactions.

    This commits enables support for them for GF119 and newer.

    Earlier GPUs have been reverted to a custom I2C-over-AUX algorithm.

    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

    Cc: Ilia Mirkin <imirkin@alum.mit.edu>

    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

:040000 040000 4540f172f019291963bd1aea3e2b0ece64698edb 51b8e7f3995b243cce54cfd8643f28dead604a9d M   drivers

```

ok. pretty much narrowed it down to this. i think.

PS BTW neat little trick this git bisect thingie. I love it. Thanks for the help  :Smile: 

[Moderator edit: added [code] tags to preserve output layout. -Hu]

----------

## Hu

Good work.  The commit message sounds plausible for a Nouveau related regression, and since it discusses using different techniques for different generations, it is likewise plausible that no one upstream tested the specific hardware that now fails for you.

Your next step is to report upstream that this caused a regression for you.  Tell them the full Git commit of the bad patch, preferably both its ID in v4.12.x (38f5d65ad997efdded1ac08eeb0ca3f6190ff5f7) and its upstream (Linus tree) commit (13a86519202c5d119d83640d6f781f3181205d2c according to the log message you quoted).  Tell them as much as you can about your specific hardware and how your results differ between the good and bad kernels.  At a minimum, tell them everything you have told us.  Be prepared for them to ask for more information and/or for them to ask for you to test specific patches to try to resolve the problem without a full revert.  They may ask you to test a tip-of-tree kernel (v4.16.x or even a -rc series kernel from Linus).

----------

## axl

Thanks for the tips  :Smile: 

----------

