Created attachment 117467 [details] dmesg - warning when switching from X to tty Using 4.2-rc4 on my Haswell laptop I get the warning you can see in the dmesg attached whenever I switch from X to tty. The same happens using 4.2-rc1. This never happened before.
This issue seems to have been fixed in v4.2-rc8. Closing this.
I am seeing this on a Dell E7240 (Haswell) freshly booted into 4.2. The issue was not seen on 4.1.2 or previous. [ 2698.293746] [drm:check_crtc_state] *ERROR* mismatch in ips_enabled (expected 1, found 0) [ 2698.293753] ------------[ cut here ]------------ [ 2698.293761] WARNING: CPU: 0 PID: 1833 at drivers/gpu/drm/i915/intel_display.c:12324 check_crtc_state+0x8ab/0xfd0() [ 2698.293763] pipe state doesn't match! [ 2698.293780] Modules linked in: fuse ctr ccm xt_addrtype xt_conntrack ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 iptable_filter ip_tables x_tables nf_nat nf_conntrack bridge stp llc dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio libcrc32c loop binfmt_misc bnep nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc arc4 nls_utf8 nls_cp437 vfat fat qmi_wwan uvcvideo videobuf2_vmalloc videobuf2_memops iwlmvm videobuf2_core cdc_mbim v4l2_common cdc_ncm cdc_wdm videodev usbnet mii mac80211 media snd_hda_codec_hdmi dell_smm_hwmon intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp btusb snd_hda_codec_realtek snd_hda_codec_generic joydev iwlwifi btintel bluetooth pcspkr efivars i2c_i801 sg snd_hda_intel cfg80211 snd_hda_codec [ 2698.293911] snd_hwdep snd_hda_core snd_pcm snd_timer tpm_tis 8250 serial_core evdev battery ac processor md_mod tpm_rng tpm rng_core efivarfs autofs4 btrfs xor raid6_pq algif_skcipher af_alg crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel ehci_pci ehci_hcd sdhci_pci xhci_pci xhci_hcd thermal sdhci_acpi sdhci mmc_core i2c_hid hid jitterentropy_rng sha256_ssse3 sha256_generic hmac drbg ansi_cprng [ 2698.293977] CPU: 0 PID: 1833 Comm: Xorg Not tainted 4.2.0 #1 [ 2698.293980] Hardware name: Dell Inc. Latitude E7240/07RPNV, BIOS A15 05/19/2015 [ 2698.293998] 0000000000000000 ffffffff819c26e0 ffffffff816898ee ffff8804030bf858 [ 2698.294004] ffffffff810b394c ffff8800d5ba9400 ffff88040c3d1000 ffff88040ab40000 [ 2698.294009] 0000000000000001 ffff88040c3d1350 ffffffff810b39c5 ffffffff819f0f1f [ 2698.294015] Call Trace: [ 2698.294024] [<ffffffff816898ee>] ? dump_stack+0x40/0x50 [ 2698.294048] [<ffffffff810b394c>] ? warn_slowpath_common+0x7c/0xb0 [ 2698.294054] [<ffffffff810b39c5>] ? warn_slowpath_fmt+0x45/0x50 [ 2698.294059] [<ffffffff8146563b>] ? check_crtc_state+0x8ab/0xfd0 [ 2698.294066] [<ffffffff81442c8b>] ? i915_get_crtc_scanoutpos+0x18b/0x230 [ 2698.294093] [<ffffffff81478116>] ? intel_modeset_check_state+0x206/0xb10 [ 2698.294101] [<ffffffff81479789>] ? intel_crtc_set_config+0x529/0x590 [ 2698.294108] [<ffffffff813f6367>] ? drm_crtc_check_viewport+0x27/0xe0 [ 2698.294130] [<ffffffff813f7bf9>] ? drm_mode_set_config_internal+0x59/0xf0 [ 2698.294137] [<ffffffff813fbabf>] ? drm_mode_setcrtc+0x17f/0x4d0 [ 2698.294143] [<ffffffff813edd1d>] ? drm_ioctl+0x16d/0x550 [ 2698.294151] [<ffffffffc024c930>] ? evdev_read+0xc0/0x2c0 [evdev] [ 2698.294175] [<ffffffff811e794e>] ? do_vfs_ioctl+0x2be/0x490 [ 2698.294183] [<ffffffff810bd942>] ? recalc_sigpending+0x12/0x50 [ 2698.294189] [<ffffffff811e7b91>] ? SyS_ioctl+0x71/0x80 [ 2698.294194] [<ffffffff810c08d0>] ? SyS_rt_sigprocmask+0x60/0xa0 [ 2698.294217] [<ffffffff8168f817>] ? entry_SYSCALL_64_fastpath+0x12/0x6a [ 2698.294221] ---[ end trace c252f4cf31b49867 ]---
Reverting d2944cf21305c754fa8b2d6c1eea05ad5dad7944 fixes 4.2 for me.
(In reply to Emil Renner Berthing from comment #3) > Reverting d2944cf21305c754fa8b2d6c1eea05ad5dad7944 fixes 4.2 for me. commit d2944cf21305c754fa8b2d6c1eea05ad5dad7944 Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Tue Aug 11 12:31:11 2015 +0200 drm/i915: Commit planes on each crtc separately.
That commit fixes another issue unfortunately. It looks like post_enable_primary might not be called in some cases. Can I have a drm.debug=0x1e log of the vt switching?
Created attachment 118386 [details] Pipe state mismatch during screen blank/unblank I didn't manage to trigger on a simple VT switch, but doing a screen blank/unblank (manual lock request in GNOME) triggered the attached warning.
I have upgraded to 4.3-rc2 and have not so far been able to reproduce the problem. I will update here if I can do so.
*** Bug 92187 has been marked as a duplicate of this bug. ***
(In reply to Jonathan McDowell from comment #7) > I have upgraded to 4.3-rc2 and have not so far been able to reproduce the > problem. I will update here if I can do so. Presumed fixed, please reopen if the problem reappears with 4.3-rc2 or later.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.