Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Nouveau isn't detecting display ports
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
axl
Guru
Guru


Joined: 11 Oct 2002
Posts: 386
Location: Romania

PostPosted: Wed May 23, 2018 11:07 pm    Post subject: Nouveau isn't detecting display ports Reply with quote

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:
Code:
[   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:
Code:
[    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.
Back to top
View user's profile Send private message
joanandk
n00b
n00b


Joined: 12 Feb 2017
Posts: 53

PostPosted: Thu May 24, 2018 10:10 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
axl
Guru
Guru


Joined: 11 Oct 2002
Posts: 386
Location: Romania

PostPosted: Thu May 24, 2018 11:00 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
axl
Guru
Guru


Joined: 11 Oct 2002
Posts: 386
Location: Romania

PostPosted: Fri May 25, 2018 11:20 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
axl
Guru
Guru


Joined: 11 Oct 2002
Posts: 386
Location: Romania

PostPosted: Sat May 26, 2018 8:11 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 12612

PostPosted: Sat May 26, 2018 9:41 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
axl
Guru
Guru


Joined: 11 Oct 2002
Posts: 386
Location: Romania

PostPosted: Sat May 26, 2018 9:49 pm    Post subject: Reply with quote

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).
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 12612

PostPosted: Sat May 26, 2018 11:36 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
ct85711
Veteran
Veteran


Joined: 27 Sep 2005
Posts: 1603

PostPosted: Sun May 27, 2018 12:49 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
axl
Guru
Guru


Joined: 11 Oct 2002
Posts: 386
Location: Romania

PostPosted: Sun May 27, 2018 3:08 pm    Post subject: Reply with quote

Code:
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 :)

[Moderator edit: added [code] tags to preserve output layout. -Hu]
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 12612

PostPosted: Sun May 27, 2018 3:41 pm    Post subject: Reply with quote

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).
Back to top
View user's profile Send private message
axl
Guru
Guru


Joined: 11 Oct 2002
Posts: 386
Location: Romania

PostPosted: Sun May 27, 2018 3:47 pm    Post subject: Reply with quote

Thanks for the tips :)
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum