Description of problem: Laptop fails to wake up from sleep when using hdmi monitor (Dell U2412m). Steps to reproduce: 1. Put computer to sleep when monitor is plugged in. 2. Unplug cables (hdmi, ethernet, and a USB hub built into monitor) 3. Wake up laptop, at this point computer runs normally 4. Put computer to sleep again. 5. Wake up laptop the second time, the laptop's screen will not show anything (backlight is off). I managed to avoid this bug by unplugging monitor before putting laptop to sleep during step 1. I also use KDE Desktop. Additional info: reporter: libreport-2.1.9 WARNING: CPU: 0 PID: 722 at drivers/gpu/drm/drm_crtc.c:1992 drm_mode_set_config_internal+0xd6/0xe0 [drm]() Modules linked in: binfmt_misc nf_nat_h323 nf_conntrack_h323 nf_nat_pptp nf_nat_proto_gre nf_conntrack_pptp nf_conntrack_proto_gre nf_nat_tftp nf_conntrack_tftp nf_nat_sip nf_conntrack_sip nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp xt_HL nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6t_REJECT rfcomm xt_conntrack bnep ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw fuse arc4 ath9k ath9k_common snd_hda_codec_hdmi ath9k_hw iTCO_wdt ath iTCO_vendor_support mac80211 coretemp microcode snd_hda_codec_realtek uvcvideo snd_hda_intel snd_hda_codec videobuf2_vmalloc snd_hwdep cfg80211 serio_raw lpc_ich videobuf2_memops videobuf2_core videodev media mfd_core joydev btusb atl1c snd_seq snd_seq_device shpchp snd_pcm bluetooth snd_page_alloc snd_timer snd asus_laptop sparse_keymap rfkill soundcore input_polldev acpi_cpufreq mperf uinput dm_crypt nouveau mxm_wmi wmi i2c_algo_bit drm_kms_helper ttm drm video usb_storage i2c_dev i2c_core CPU: 0 PID: 722 Comm: X Not tainted 3.11.9-200.fc19.x86_64 #1 Hardware name: ASUSTeK Computer Inc. N61Vn /N61Vn , BIOS 209 11/04/2009 0000000000000009 ffff88012c69dab8 ffffffff8164764b 0000000000000000 ffff88012c69daf0 ffffffff8106715d ffff88013725eea0 0000000000000000 ffff880136e11000 ffff8801372b6860 0000000000000080 ffff88012c69db00 Call Trace: [<ffffffff8164764b>] dump_stack+0x45/0x56 [<ffffffff8106715d>] warn_slowpath_common+0x7d/0xa0 [<ffffffff8106723a>] warn_slowpath_null+0x1a/0x20 [<ffffffffa0046ac6>] drm_mode_set_config_internal+0xd6/0xe0 [drm] [<ffffffffa007e641>] drm_fb_helper_set_par+0x71/0xf0 [drm_kms_helper] [<ffffffff813456e1>] fb_set_var+0x191/0x430 [<ffffffff8109639d>] ? ttwu_do_activate.constprop.87+0x5d/0x70 [<ffffffff81350ea1>] fbcon_blank+0x1d1/0x2d0 [<ffffffff813c67d4>] do_unblank_screen+0xb4/0x1e0 [<ffffffff813bc6fa>] complete_change_console+0x5a/0xe0 [<ffffffff813bd71e>] vt_ioctl+0xf9e/0x1150 [<ffffffff81646d27>] ? avc_compute_av+0x1a3/0x1b5 [<ffffffff813b1565>] tty_ioctl+0x275/0xb70 [<ffffffff8129a359>] ? avc_has_perm_flags+0xc9/0x180 [<ffffffff811b9fcd>] do_vfs_ioctl+0x2dd/0x4b0 [<ffffffff811ba221>] SyS_ioctl+0x81/0xa0 [<ffffffff8165211e>] ? do_page_fault+0xe/0x10 [<ffffffff81656859>] system_call_fastpath+0x16/0x1b
Created attachment 829906 [details] File: dmesg
I just wanted to add that this problem no longer occurs after I have upgraded to Fedora 20.
Thank you for the update.