Wakeup takes ages after DPMS kicked in

Graphics / Linux Linux
1

Hello,

On Debian (Stable/Jessie), unlocking takes ages (up to 30 minutes!) after DPMS kicked in.

Since our shop is using Debian XFCE along LightDM, the unlocking process is:

  • wake up the screen-locker from DPMS on X:1 and provide credentials (this works flawlessly)
  • on success, screen-locker passes control back to the user session on X:0 → takes ages (screen remains black with stuck mouse cursor; user can’t even CTRL+ALT+…)

I’ve been struggling with this issue for months. So far:

  • Issue showed up on drivers 340.96, disappeared on 352.63 (backported from Experimental at that time) and re-appeared on 367.44 (current official Jessie Backport)

  • Issue does not depend on GPU, be it a GT610 (GF119) or a GTX Titan (GK110)

  • Issue does not depend on any Xorg configuration I’ve tried: IgnoreDisplayDevices, ConnectedMonitor, UseEDID, IgnoreEDID, etc.

  • Issue does not depend on MSI deactivation (NVReg_EnableMSI=0)

  • The ONLY way to prevent the issue to appear is not using DPMS, either by “xset -dpms” or in the Xorg configuration

  • The only weird sign showing up along this issue is a huge number of “NVIDIA(GPU-0): (): connected” while DPMS is on.

  • The issue show up on all ~100 workstations (thus resulting in an extra ~5kW screen power consumption - and wear - at night or when people are away, when DPMS is prevented to kick in)

While not a show-stopper, it still is a nuisance. And we can not go back to 352 since we need Pascal support for our newly-acquired GPU (we’re an academic shop running deep machine learning research 24h/24h, on a computation grid that includes users workstations at night)

Any idea what else I could try to get rid of this issue ?
Or why it disappeared in 352 and re-appeared in 367 ?

Thanks for your help,

Cédric

2

UPDATE:

Finally made progress on this one, by changing the screen attached to the nVidia card. Using a Samsung SyncMaster BX2235, the issue disappears, with only a single “reconnect” entry in the logs when the screen/GPU wakes up from DPMS:

[414575.329] (II) NVIDIA(0): Setting mode “DFP-0:nvidia-auto-select”
[414575.389] (–) NVIDIA(GPU-0): CRT-0: disconnected
[414575.389] (–) NVIDIA(GPU-0): CRT-0: 400.0 MHz maximum pixel clock
[414575.389] (–) NVIDIA(GPU-0):
[414575.390] (–) NVIDIA(GPU-0): CRT-1: disconnected
[414575.390] (–) NVIDIA(GPU-0): CRT-1: 400.0 MHz maximum pixel clock
[414575.390] (–) NVIDIA(GPU-0):
[414575.413] (–) NVIDIA(GPU-0): Samsung SMBX2235 (DFP-0): connected
[414575.413] (–) NVIDIA(GPU-0): Samsung SMBX2235 (DFP-0): Internal TMDS
[414575.413] (–) NVIDIA(GPU-0): Samsung SMBX2235 (DFP-0): 330.0 MHz maximum pixel clock
[414575.413] (–) NVIDIA(GPU-0):
[414575.413] (–) NVIDIA(GPU-0): DFP-1: disconnected
[414575.413] (–) NVIDIA(GPU-0): DFP-1: Internal TMDS
[414575.413] (–) NVIDIA(GPU-0): DFP-1: 165.0 MHz maximum pixel clock
[414575.413] (–) NVIDIA(GPU-0):

Using a Philips 247E3LHSU/00, the logs fills up with such “reconnect” entries issued every ~100ms, starting when the user X session is supposed to wake-up and ending when the the screen/GPU eventually “unfreeze” (up to 30 minutes later; the longer the DPMS suspend, the longer the “unfreeze” time).

Now, is the culprit the screen itself or the nVidia driver? Your call you nVidia guys! ;-)

3

Perhaps the SmartControl Software version: v1.2.0.6, zip file, 8.7 MB, published July 21, 2016 offers some additional and relevant clues:

Visit the support page for your Philips LED monitor 247E3LHSU/00
[url]Error 404