Quoting Rodrigo Vivi (2018-03-30 18:41:08) > On Wed, Mar 28, 2018 at 03:30:45PM -0700, José Roberto de Souza wrote: > > In the 2 eDP1.4a pannels tested set or not set bit have no effect > > but is better set it and comply with specification. > > > > Signed-off-by: José Roberto de Souza <jose.souza@xxxxxxxxx> > > Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@xxxxxxxxx> > > Reviewed-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> > > patches 1-9 pushed to dinq. Thanks for patches and reviews. Might be coincidental, but this GPF hasn't occurred before: https://intel-gfx-ci.01.org/tree/drm-tip/kasan_26/fi-cfl-s3/dmesg15.log <7>[ 40.159658] [drm:intel_enable_sagv [i915]] Enabling the SAGV <0>[ 40.162715] kasan: CONFIG_KASAN_INLINE enabled <0>[ 40.162884] kasan: GPF could be caused by NULL-ptr deref or user memory access <4>[ 40.162910] general protection fault: 0000 [#1] PREEMPT SMP KASAN PTI <4>[ 40.179985] Modules linked in: i915 cdc_ether usbnet x86_pkg_temp_thermal r8152 intel_powerclamp mii coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel e1000e mei_me mei prime_numbers <4>[ 40.180000] CPU: 9 PID: 1395 Comm: kms_color Tainted: G U 4.16.0-rc7-g29940f138482-kasan_26+ #1 <4>[ 40.180002] Hardware name: Intel Corporation CoffeeLake Client Platform/CoffeeLake S UDIMM RVP, BIOS CNLSFWR1.R00.X118.B19.1802080131 02/08/2018 <4>[ 40.180055] RIP: 0010:intel_psr_flush+0x140/0x4b0 [i915] <4>[ 40.180057] RSP: 0018:ffff880404fd7818 EFLAGS: 00010202 <4>[ 40.180060] RAX: dffffc0000000000 RBX: ffff8803b4820000 RCX: 0000000000000000 <4>[ 40.180062] RDX: 00000000000000bc RSI: 0000000000000000 RDI: 00000000000005e0 <4>[ 40.180076] RBP: ffff8803b482a5d8 R08: ffffffff8b02b360 R09: ffffffff8a32df20 <4>[ 40.180078] R10: ffff880404fd7818 R11: 0000000000000000 R12: 0000000000000100 <4>[ 40.180079] R13: 0000000000000000 R14: 0000000000000100 R15: 0000000000000000 <4>[ 40.180081] FS: 00007ff255bfe980(0000) GS:ffff88041dc40000(0000) knlGS:0000000000000000 <4>[ 40.180083] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 40.180085] CR2: 00007fdf372522f8 CR3: 0000000419d9a005 CR4: 00000000003606e0 <4>[ 40.180086] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4>[ 40.180088] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 <4>[ 40.180089] Call Trace: <4>[ 40.180125] intel_frontbuffer_flush+0x8e/0xb0 [i915] <4>[ 40.180161] intel_prepare_plane_fb+0x699/0xb20 [i915] <4>[ 40.180167] drm_atomic_helper_prepare_planes+0x118/0x480 <4>[ 40.180202] ? haswell_crtc_compute_clock+0xc4/0xc4 [i915] <4>[ 40.180237] intel_atomic_commit+0x215/0xcd0 [i915] <4>[ 40.180242] set_property_atomic+0x1d5/0x250 <4>[ 40.180245] ? drm_object_property_get_value+0xe0/0xe0 <4>[ 40.180251] drm_mode_obj_set_property_ioctl+0x334/0x5b0 <4>[ 40.180254] ? drm_mode_obj_find_prop_id+0x180/0x180 <4>[ 40.180257] ? drm_is_current_master+0x5a/0x100 <4>[ 40.180260] ? drm_mode_obj_find_prop_id+0x180/0x180 <4>[ 40.180262] drm_ioctl_kernel+0x189/0x200 <4>[ 40.180265] ? drm_ioctl_permit+0x2b0/0x2b0 <4>[ 40.180269] drm_ioctl+0x662/0x880 <4>[ 40.180272] ? drm_mode_obj_find_prop_id+0x180/0x180 <4>[ 40.180274] ? drm_getstats+0x20/0x20 <4>[ 40.180277] ? lock_acquire+0x390/0x390 <4>[ 40.180281] ? debug_check_no_locks_freed+0x270/0x270 <4>[ 40.180284] ? __might_fault+0xea/0x1a0 <4>[ 40.180288] do_vfs_ioctl+0x171/0xe50 <4>[ 40.180292] ? ioctl_preallocate+0x170/0x170 <4>[ 40.180295] ? __task_pid_nr_ns+0x17b/0x3d0 <4>[ 40.180298] ? lock_acquire+0x390/0x390 <4>[ 40.180302] SyS_ioctl+0x36/0x70 <4>[ 40.180304] ? do_vfs_ioctl+0xe50/0xe50 <4>[ 40.180307] do_syscall_64+0x18a/0x5c0 <4>[ 40.180311] entry_SYSCALL_64_after_hwframe+0x42/0xb7 <4>[ 40.180313] RIP: 0033:0x7ff254cf65d7 <4>[ 40.180315] RSP: 002b:00007ffc2f0fca58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 <4>[ 40.180317] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ff254cf65d7 <4>[ 40.180319] RDX: 00007ffc2f0fca90 RSI: 00000000c01864ba RDI: 0000000000000003 <4>[ 40.180321] RBP: 00007ffc2f0fca90 R08: 0000000000000001 R09: 0000000000000000 <4>[ 40.180322] R10: 000055be9798e010 R11: 0000000000000246 R12: 00000000c01864ba <4>[ 40.180324] R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000 <4>[ 40.180328] Code: ea 03 80 3c 02 00 0f 85 4c 03 00 00 4d 8b ad 48 ff ff ff 48 b8 00 00 00 00 00 fc ff df 49 8d bd e0 05 00 00 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e ee 01 00 00 4d 63 ad e0 05 <1>[ 40.180402] RIP: intel_psr_flush+0x140/0x4b0 [i915] RSP: ffff880404fd7818 <4>[ 40.180416] ---[ end trace 53653c4618c4b0b4 ]--- A null pointer in intel_psr_flush, probably crtc? The code where we case the psr.enabled in the intel_psr_work preamble is unlocked, and we do race there with intel_psr_disable() setting it to NULL before cancelling the work. E.g. diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index 2d53f7398a6d..c0a7295920dd 100644 --- a/drivers/gpu/drm/i915/intel_psr.c +++ b/drivers/gpu/drm/i915/intel_psr.c @@ -758,6 +758,8 @@ void intel_psr_disable(struct intel_dp *intel_dp, if (WARN_ON(!CAN_PSR(dev_priv))) return; + cancel_delayed_work_sync(&dev_priv->psr.work); + mutex_lock(&dev_priv->psr.lock); if (!dev_priv->psr.enabled) { mutex_unlock(&dev_priv->psr.lock); @@ -771,8 +773,6 @@ void intel_psr_disable(struct intel_dp *intel_dp, dev_priv->psr.enabled = NULL; mutex_unlock(&dev_priv->psr.lock); - - cancel_delayed_work_sync(&dev_priv->psr.work); } static void intel_psr_work(struct work_struct *work) Haven't spotted the chain of events that leads to intel_psr_flush() crashing though. -Chris _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
