Bug 100610 - [BYT] WARNING: CPU: 1 PID: 16615 at drivers/gpu/drm/drm_debugfs_crc.c:185 crtc_crc_open+0x1d0/0x1f0 [drm]
Summary: [BYT] WARNING: CPU: 1 PID: 16615 at drivers/gpu/drm/drm_debugfs_crc.c:185 crt...
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: Other All
: high critical
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
Whiteboard: PatchSubmitted
Keywords: bisected, regression
Depends on:
Reported: 2017-04-07 11:02 UTC by Chris Wilson
Modified: 2018-04-26 07:09 UTC (History)
1 user (show)

See Also:
i915 platform: BYT
i915 features: display/Other


Description Chris Wilson 2017-04-07 11:02:06 UTC
[66285.716870] WARNING: CPU: 1 PID: 16615 at drivers/gpu/drm/drm_debugfs_crc.c:185 crtc_crc_open+0x1d0/0x1f0 [drm]
[66285.716877] Modules linked in: i915 intel_powerclamp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel cryptd intel_gtt i2c_algo_bit lpc_ich mfd_core drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops prime_numbers drm video button autofs4 sd_mod ahci libahci libata i2c_i801 scsi_mod i2c_designware_platform i2c_designware_core i2c_core
[66285.716929] CPU: 1 PID: 16615 Comm: kms_frontbuffer Not tainted 4.11.0-rc5+ #7
[66285.716935] Hardware name: GIGABYTE GB-BXBT-1900/MZBAYAB-00, BIOS F8 03/02/2016
[66285.716941] Call Trace:
[66285.716955]  dump_stack+0x4d/0x6f
[66285.716966]  __warn+0xc1/0xe0
[66285.716975]  warn_slowpath_null+0x18/0x20
[66285.717004]  crtc_crc_open+0x1d0/0x1f0 [drm]
[66285.717014]  ? wake_atomic_t_function+0x50/0x50
[66285.717024]  full_proxy_open+0xf0/0x1b0
[66285.717032]  ? full_proxy_release+0x80/0x80
[66285.717042]  do_dentry_open.isra.17+0x14b/0x2d0
[66285.717051]  vfs_open+0x42/0x60
[66285.717064]  path_openat+0x5e7/0x13d0
[66285.717074]  ? refcount_dec_and_test+0x11/0x20
[66285.717081]  ? down_read+0xd/0x30
[66285.717087]  do_filp_open+0x85/0xf0
[66285.717093]  ? __vfs_write+0x23/0x120
[66285.717100]  ? __alloc_fd+0x3a/0x170
[66285.717107]  do_sys_open+0x11e/0x1f0
[66285.717113]  ? do_sys_open+0x11e/0x1f0
[66285.717119]  SyS_openat+0xf/0x20
[66285.717125]  entry_SYSCALL_64_fastpath+0x17/0x98
[66285.717131] RIP: 0033:0x7f5f2235146a
[66285.717135] RSP: 002b:00007ffd892e6bc0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
[66285.717142] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5f2235146a
[66285.717147] RDX: 0000000000000000 RSI: 00007ffd892e6c40 RDI: 0000000000000006
[66285.717151] RBP: 00007ffd892e6b20 R08: 0000000000000000 R09: 000000000000000f
[66285.717156] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
[66285.717161] R13: 00007ffd892e6b10 R14: 0000000000000004 R15: 00000000007e61f4
Comment 1 Chris Wilson 2017-04-07 11:03:00 UTC
Just beautiful it asks to be interrupted and then complains when it is:

         * Only return once we got a first frame, so userspace doesn't have to
         * guess when this particular piece of HW will be ready to start
         * generating CRCs.
        ret = wait_event_interruptible_lock_irq(crc->wq,

Comment 2 Chris Wilson 2017-04-07 11:03:37 UTC
Introduced by commit e8fa5671183c80342d520ad81d14fa79a9d4a680
Author: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Date:   Mon Jan 2 13:59:10 2017 +0100

    drm: crc: Wait for a frame before returning from open()
    Don't return from the open() call on the crc/data file until the HW has
    produced a first frame, as there's great variability in when the HW is
    able to do that and userspace shouldn't have to guess when this specific
    HW is ready to start giving frame CRCs.
    Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: http://patchwork.freedesktop.org/patch/msgid/20170102125912.22305-3-tomeu.vizoso@collabora.com
Comment 3 Elizabeth 2017-06-29 22:01:04 UTC
Hello Chris,
Has this issue got any update?
Thank you.
Comment 4 Abdiel Janulgue 2017-07-17 08:02:39 UTC
Hi Tomeu, any word on this?

Note that bug can be reproduced with igt@debugfs_test@read_all_entries
Comment 5 Abdiel Janulgue 2017-07-17 08:25:18 UTC
Actually we have https://patchwork.freedesktop.org/patch/165548/ potential fix from Maarten.

Currently testing this.
Comment 6 Abdiel Janulgue 2017-07-17 08:48:32 UTC
Tested patch from Maarten. Improvement is cosmetic; at least the kernel crash disappeared (removal of WARN_ON). However opening the crc data file descriptor still takes forever.
Comment 7 Jani Saarinen 2018-03-29 07:10:49 UTC
First of all. Sorry about spam.
This is mass update for our bugs. 

Sorry if you feel this annoying but with this trying to understand if bug still valid or not.
If bug investigation still in progress, please ignore this and I apologize!

If you think this is not anymore valid, please comment to the bug that can be closed.
If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Comment 8 Jani Saarinen 2018-04-20 14:07:01 UTC
Chris, Abdiel, is this still valid?
Comment 9 Abdiel Janulgue 2018-04-25 07:59:20 UTC
I think we can close this. I can't reproduce the problem in drm-tip at least.

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.