Bug 82527

The bug you reference was about DP. But display stuff got a substantial rework in 3.16 (with an eye to DP) and even more changes are queued for 3.17. Would you mind giving the linux-3.17 branch a shot (http://cgit.freedesktop.org/nouveau/linux-2.6/log/?h=linux-3.17)? If that doesn't help, please provide a boot log with

nouveau.debug=VBIOS=trace,DISP=debug,I2C=debug,DRM=debug

in the kernel commandline (or otherwise passed to the module). Also mention how the monitor is connected.

Created attachment 104544 [details]
boot.log

With kernel 3-17 (boot log attached) there is indeed a change:

Now the monitor does not react at all on "xset dpms force off".

The monitor is connected over DVI

Two comments/questions:

(1)

1:10 slim[256]: (EE) module ABI major version (13) doesn't match the server's version (15)

That seems a little unhappy... I hope that's not referring to the ddx's module. I guess you have an old module? As long as nouveau's not involved in this, it shouldn't matter.

(2)

Did you try to do a "xset dpms force off" in that log, or was that not included. In case it wasn't included, could you?

Lastly, I forgot that the drm core may also provide some useful information. Would you mind adding "drm.debug=0xe" to the kernel command line in addition to the nouveau.debug setting I mentioned earlier, and provide a log which also includes you trying to "xset dpms force off"?

(In reply to comment #3)
> 1:10 slim[256]: (EE) module ABI major version (13) doesn't match the
> server's version (15)

This was the v4l driver. I recompiled, but unsurprisingly, it does not change anything concerning the reported problem.

> Did you try to do a "xset dpms force off" in that log

This produced no output in the log, also not with the following:

> Would you mind adding "drm.debug=0xe" to the kernel command line

This did not change the output, either. Still no output when calling
xset dpms force off

I will attach the new boot log, but it is practically the same.

Created attachment 104594 [details]
boot.log

As in the previous log, some obviously unrelevant information (like disk or network initialization messages) have been removed manually by me.

You misunderstood my suggestion... you have:

nouveau.debug=VBIOS=trace,DISP=debug,I2C=debug,DRM=debug,drm.debug=0xe

You should have:

nouveau.debug=VBIOS=trace,DISP=debug,I2C=debug,DRM=debug drm.debug=0xe

Created attachment 104604 [details]
boot.log

Still no output with "xdpms force off" (tried several times).

At a few minutes later (I cannot associate to an action of me) there appeared:

[kernel] nouveau T[   VBIOS][0000:01:00.0] inc() == 3
[kernel] nouveau T[   VBIOS][0000:01:00.0] dec() == 2

s/xdpms/xset dpms/

*** Bug 83244 has been marked as a duplicate of this bug. ***

My display re-enabe resume issue (#83244) resolved for me with http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=a68e95365a4248d3f58c8663e4513c79273ac704 which references this ticket. Thus the duplicate marker. Feel free to rectify this, if not correctly done.

I do not have physical access to the machine with the card in the next months, so I cannot confirm/test anything.

I can confirm that the regression reported in comment #2 that I bisected to d55b4af909bc16f7982c2b8b8656f0898158627b is now fixed as of 80ad99da8bd213e12b925407f1c97a303aa8f87f (which pulled in 5838ae610ff36777b8fce6f353c2417980c1a1fa).  Additionally I haven't been able to reproduce the case that this bug was originally opened for yet, (prior to 3.17 I could but it was always a bit finicky).  Still, it's probably too early to say that its fixed for sure; I have a slightly different card than Martin's (a 10de:042f, NVIDIA Corporation G86 [Quadro NVS 290] (rev a1)).

By accident, I am now traveling and have access on the machine for 1 or 2 days.

I installed linux-3.17.2, and have still exactly the same faulty behaviour as described in the original posting:

xset dpms force off holds for about 20 seconds and then switches on again.

For what it's worth, I see similar behavior with the Nouveau driver on OpenSUSE 13.2 (kernel 3.16.7-24, xf86-video-nouveau-1.0.11-1.3)

My office machine has two displays connected to a GTS450.  Both displays go into standby mode.  After a short delay -- I haven't measured by hand but the aforementioned 20-second value sounds about right -- the secondary display comes out of standby.  Near as I can tell, this behavior only affects the secondary display.  I can also confirm that the behavior did not occur when using the proprietary nVidia drivers.

Another data point that may be useful when diagnosing the problem: I'm also using the nVidia card for audio.  I'm away from the office for a few days but I'm reasonably confident that both displays are connected via DVI and that my speakers are connected to the secondary display's audio line-out jack.  Is it possible that the secondary display's inability to remain in standby mode is somehow audio-related?

I don't know why this issue was marked as FIXED.
The behaviour hasn't changed since my first posting.

I am not using audio from nvidia, so at least in my case this is certainly not related.

I haven't been at the nvidia machine for a while.
Sometimes during the previous months the problem has indeed been fixed.