WARNING when dpms turns monitor off with powered-off monitor

[Paul Slootman]

(Please CC me on replies, I'm not subscribed.)

Since linux kernel version 3.7(.1), whenever I have already turned my
monitor off and the X server's dpms settings engages after the timeout,
I get the following:

[245917.595824] ------------[ cut here ]------------
[245917.595837] WARNING: at drivers/gpu/drm/i915/intel_dp.c:1908 ironlake_crtc_disable+0x5a/0x7a2()
[245917.595839] Hardware name:         
[245917.595840] Modules linked in: pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) nfnetlink ufs ntfs vfat msdos fat jfs reiserfs nfsd nfs_acl nfs lockd fscache sunrpc xt_tcpudp xt_recent iptable_filter ip_tables x_tables xfs sha256_generic dm_crypt hwmon_vid loop firewire_sbp2 fuse wacom mcs7830 usbnet mii snd_hda_codec_realtek coretemp kvm_intel snd_hda_intel kvm snd_hda_codec iTCO_wdt snd_hwdep gpio_ich iTCO_vendor_support snd_pcm hisax snd_page_alloc snd_seq microcode i2c_i801 snd_seq_device lpc_ich mfd_core snd_timer isdn hfcpci mISDN_core snd mei soundcore btrfs libcrc32c zlib_deflate dm_mod crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 ablk_helper cryptd sr_mod xts firewire_ohci lrw cdrom gf128mul firewire_core sg crc_itu_t xhci_hcd e1000e
[245917.595911] Pid: 6036, comm: Xorg Tainted: G        W  O 3.7.1-vs2.3.5.3-wurtelws #4
[245917.595913] Call Trace:
[245917.595919]  [<ffffffff8103b9e7>] ? warn_slowpath_common+0x76/0x8a
[245917.595923]  [<ffffffff812aa4d4>] ? ironlake_crtc_disable+0x5a/0x7a2
[245917.595929]  [<ffffffff8110c233>] ? set_restore_sigmask+0x2d/0x2d
[245917.595933]  [<ffffffff8105fbb8>] ? should_resched+0x5/0x23
[245917.595937]  [<ffffffff81434ecb>] ? _cond_resched+0x6/0x1b
[245917.595941]  [<ffffffff812ae3be>] ? intel_crtc_update_dpms+0x57/0x66
[245917.595945]  [<ffffffff812af5ab>] ? intel_connector_dpms+0x2f/0x53
[245917.595951]  [<ffffffff812851c6>] ? drm_mode_obj_set_property_ioctl+0x16a/0x1fb
[245917.595955]  [<ffffffff81285283>] ? drm_mode_connector_property_set_ioctl+0x2c/0x31
[245917.595959]  [<ffffffff81277adb>] ? drm_ioctl+0x28c/0x36a
[245917.595964]  [<ffffffff8110cbff>] ? core_sys_select+0x1ae/0x1f9
[245917.595968]  [<ffffffff81285257>] ? drm_mode_obj_set_property_ioctl+0x1fb/0x1fb
[245917.595972]  [<ffffffff8110b1c6>] ? vfs_ioctl+0x1e/0x31
[245917.595976]  [<ffffffff8110b9fd>] ? do_vfs_ioctl+0x3ed/0x42f
[245917.595981]  [<ffffffff81079f51>] ? ktime_get_ts+0x42/0x80
[245917.595984]  [<ffffffff8105fbb8>] ? should_resched+0x5/0x23
[245917.595989]  [<ffffffff8104980a>] ? recalc_sigpending+0x12/0x41
[245917.595993]  [<ffffffff8104a2af>] ? __set_task_blocked+0x5e/0x65
[245917.595997]  [<ffffffff8110ba8c>] ? sys_ioctl+0x4d/0x7d
[245917.596000]  [<ffffffff8105fbb8>] ? should_resched+0x5/0x23
[245917.596002]  [<ffffffff81434ecb>] ? _cond_resched+0x6/0x1b
[245917.596007]  [<ffffffff81436469>] ? system_call_fastpath+0x16/0x1b
[245917.596009] ---[ end trace 1494574d9cf0f782 ]---

Yes, sorry about the tainted kernel (virtualbox modules), if anyone
really thinks those could be involved I'll reboot (but I'd rather not...)

This happens every time. If the display is on when dpms is engaged then
there's no problem.

I have a i7-2600K CPU, ie. not ironlake but sandybridge.
Motherboard is an Intel DZ68BC.
Monitor is a Dell 3008WFP 2560x1600, connected by displayport.
I'm happy to supply more info if needed.

BTW, thanks for the 3.7(.1) kernel version, it's the first one that
displays correctly on my monitor everytime without needing to powercycle
my monitor. Sometimes when turning the monitor on it would
display "no signal, powering down" and go into standby; powercycling
would then help. Same thing if the monitor was turned off with dpms,
pressing a key would not turn it on (the first couple of times I thought
the whole system had hung). Occasionally it _would_ simply work...
Sometimes the picture was corrupt (e.g right half of the screen very
green with a hint of what should be displayed there. Sometimes pixels
would flicker...   Now with 3.7.1, after a couple of days, it looks
good! (Besides the WARNING in the kernel log :-)


Paul