Similar report at https://bugzilla.kernel.org/show_bug.cgi?id=105261, let's track all of it here.

Logged error and stack trace copied from similar bug report referenced above:

[drm:check_crtc_state [i915]] *ERROR* mismatch in limited_color_range (expected 0, found 1)
------------[ cut here ]------------
WARNING: CPU: 0 PID: 8262 at drivers/gpu/drm/i915/intel_display.c:12324 check_crtc_state+0x8df/0xf80 [i915]()
pipe state doesn't match!
Modules linked in: fuse nfnetlink_queue nfnetlink_log nfnetlink bluetooth bbswitch(O) ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 uvcvideo videobu
 rfkill mii kvm_intel i915 drm_kms_helper drm intel_gtt mei_me mei shpchp i2c_algo_bit i2c_i801 lpc_ich snd_hda_intel snd_hda_codec snd_hda_c
 atkbd libps2 ahci libahci crct10dif_pclmul crc32_pclmul xhci_pci crc32c_intel ehci_pci ghash_clmulni_intel xhci_hcd libata ehci_hcd aesni_in
CPU: 0 PID: 8262 Comm: Xorg Tainted: G        W  O    4.2.1-1-ARCH #1
Hardware name: Hewlett-Packard HP Pavilion dv7 Notebook PC/181F, BIOS F.0B 06/19/2012
 0000000000000000 00000000ab424e4b ffff8802c62e7468 ffffffff8156b77a
 0000000000000000 ffff8802c62e74c0 ffff8802c62e74a8 ffffffff81074846
 00000001c62e74d8 ffff88034de5d350 ffff880095f05000 ffff88034de5d000
Call Trace:
 [<ffffffff8156b77a>] dump_stack+0x4c/0x6e
 [<ffffffff81074846>] warn_slowpath_common+0x86/0xc0
 [<ffffffff810748d5>] warn_slowpath_fmt+0x55/0x70
 [<ffffffffa07cdf7f>] check_crtc_state+0x8df/0xf80 [i915]
 [<ffffffffa07e09f6>] intel_modeset_check_state+0x216/0xb50 [i915]
 [<ffffffffa07db00c>] ? __intel_set_mode+0x92c/0xb60 [i915]
 [<ffffffffa07e2037>] intel_crtc_set_config+0x4c7/0x580 [i915]
 [<ffffffffa06ea9f6>] drm_mode_set_config_internal+0x66/0x100 [drm]
 [<ffffffffa0750552>] restore_fbdev_mode+0xc2/0xf0 [drm_kms_helper]
 [<ffffffffa07524b9>] drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x70 [drm_kms_helper]
 [<ffffffffa0752522>] drm_fb_helper_set_par+0x22/0x40 [drm_kms_helper]
 [<ffffffffa07f06ca>] intel_fbdev_set_par+0x1a/0x60 [i915]
 [<ffffffff81328cb6>] fb_set_var+0x236/0x460
 [<ffffffff81160d5c>] ? __alloc_pages_nodemask+0x17c/0x960
 [<ffffffffa07c14ad>] ? gen6_read32+0xdd/0x1a0 [i915]
 [<ffffffff8131f8a2>] fbcon_blank+0x312/0x360
 [<ffffffff81399b33>] do_unblank_screen+0xc3/0x190
 [<ffffffff8138feea>] vt_ioctl+0x50a/0x12e0
 [<ffffffff811dd71e>] ? path_parentat+0x3e/0x80
 [<ffffffff81384085>] tty_ioctl+0x3b5/0xba0
 [<ffffffff810d64e7>] ? call_rcu+0x17/0x20
 [<ffffffff813cadf3>] ? vga_arb_release+0xe3/0x130
 [<ffffffff811e29b5>] do_vfs_ioctl+0x295/0x480
 [<ffffffff811ef894>] ? mntput+0x24/0x40
 [<ffffffff811ecaa7>] ? __fget+0x77/0xb0
 [<ffffffff811e2c19>] SyS_ioctl+0x79/0x90
 [<ffffffff81570cee>] entry_SYSCALL_64_fastpath+0x12/0x71
---[ end trace 3ca0f09428c0569c ]---

Any known workaround for this? I am stuck on kernel 4.1.6 without a fix.

Please attach full dmesg with drm.debug=14 module parameter set.

Cc: Ville, any ideas?

(In reply to Jani Nikula from comment #4)
> Please attach full dmesg with drm.debug=14 module parameter set.
> 
> Cc: Ville, any ideas?

My initial hunch was that atomic and/or fastboot broke things. So something for Maarten to look at.

Created attachment 119209 [details]
dmesg with drm.debug=14 module parameter

As requested, attached dmesg output with drm.debug=14 parameter.

(In reply to Ville Syrjala from comment #5)
> (In reply to Jani Nikula from comment #4)
> > Please attach full dmesg with drm.debug=14 module parameter set.
> > 
> > Cc: Ville, any ideas?
> 
> My initial hunch was that atomic and/or fastboot broke things. So something
> for Maarten to look at.

Maarten?

Fastboot's not part of v4.2 iirc, full modesets still happen.

Does the problem occur on v4.3.rcXX too?

Yes, last I checked (a week ago or so), the issue was reproducible on 4.3rc

What additional info is needed? I think all requested info has been provided.

Same problem here, what kind of info or tests is needed to resolve this?

I also have the same issue and would happy to help troubleshoot.

Well a bisection would be nice. I'm not sure what the difference between v4.1 and v4.2 is here, no immediate suspect comes to mind.

Could this be bisected?

While starting to bisect this, I discovered that the problem does NOT exist in kernel v4.3 tagged yesterday. Can someone else confirm on different hardware?

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

No problem with debian@4.3.0.

The "workaround"

xrandr --output HDMI3 --set "Broadcast RGB" "Full"

works as expected.

On my fedora 22 system, the latest kernel has this problem:

kernel-4.2.3-200.fc22.x86_64

If I boot an older kernel, the problem goes away:

kernel-4.1.10-200.fc22.x86_64

(In reply to Tom Horsley from comment #17)
> On my fedora 22 system, the latest kernel has this problem:
> 
> kernel-4.2.3-200.fc22.x86_64
> 
> If I boot an older kernel, the problem goes away:
> 
> kernel-4.1.10-200.fc22.x86_64

The question is now, is it fixed in v4.3?

(In reply to Jani Nikula from comment #18)
> (In reply to Tom Horsley from comment #17)
> > On my fedora 22 system, the latest kernel has this problem:
> > 
> > kernel-4.2.3-200.fc22.x86_64
> > 
> > If I boot an older kernel, the problem goes away:
> > 
> > kernel-4.1.10-200.fc22.x86_64
> 
> The question is now, is it fixed in v4.3?

I'd love to know that, but I checked updates-testing to see if there was a 4.3 fedora kernel available to try out, and there isn't one yet. I presume there will be one eventually. If it ever shows up, I'll report back.

We have two reports that v4.3 fixes the problem. I am just waiting for official 4.3 kernel to land in Arch repo (should be anytime now), and if that works, too, this can be closed IMHO.

I installed Linux 4.3 on Arch from testing repo and it seems to solve the problem.

I can confirm that kernel 4.3 from testing is working fine.

Enough reports that v4.3 fixes the issue, closing. Please reopen if that turns out not to be the case. Thanks.