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:

[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]

[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