On Fri, Apr 07, 2017 at 06:42:46PM +0200, Daniel Vetter wrote: > On Fri, Apr 07, 2017 at 01:55:00PM +0200, Tomeu Vizoso wrote: > > On 04/07/2017 01:17 PM, Chris Wilson wrote: > > > The code does not like to be interrupted when waiting for the first > > > vblank after opening a debugfs/crc channel, so don't. > > > > > > [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 > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100610 > > > Fixes: e8fa5671183c ("drm: crc: Wait for a frame before returning from open()") > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > > Cc: Tomeu Vizoso <tomeu.vizoso@xxxxxxxxxxxxx> > > > Cc: Daniel Vetter <daniel.vetter@xxxxxxxx> > > > > Reviewed-by: Tomeu Vizoso <tomeu.vizoso@xxxxxxxxxxxxx> > > > > Sounds good to me, there isn't any good reason for the wait to be > > interruptible. > > Applied to drm-misc-next, thanks. Oh no. The other side is using wake_up_interruptible(), so only the interruptible waiters are woken and not us anymore :( diff --git a/drivers/gpu/drm/drm_debugfs_crc.c b/drivers/gpu/drm/drm_debugfs_crc.c index aa13e734c9e5..1ec04f864437 100644 --- a/drivers/gpu/drm/drm_debugfs_crc.c +++ b/drivers/gpu/drm/drm_debugfs_crc.c @@ -354,7 +354,7 @@ int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool has_frame, spin_unlock(&crc->lock); - wake_up_interruptible(&crc->wq); + wake_up(&crc->wq); return 0; } Undoes the damage, or revert? -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
