On Tue, 2018-12-04 at 11:41 +0000, Chris Wilson wrote: > Quoting Mika Kahola (2018-12-04 09:46:39) > > Occasionally, we get the following error in our CI runs > > > > [853.132830] Workqueue: events i915_hotplug_work_func [i915] > > [853.132844] RIP: 0010:drm_wait_one_vblank+0x19b/0x1b0 > > [853.132852] Code: fe ff ff e8 b7 4e a6 ff 48 89 e6 4c 89 ff e8 6c > > 5f ab ff 45 85 ed 0f 85 > > 15 ff ff ff 89 ee 48 c7 c7 e8 03 10 82 e8 b5 4b a6 ff <0f> 0b e9 00 > > ff ff ff 0f 1f 40 00 66 > > 2e 0f 1f 84 00 00 00 00 00 8b > > [853.132859] RSP: 0018:ffffc9000146bca0 EFLAGS: 00010286 > > [853.132866] RAX: 0000000000000000 RBX: ffff88849ef00000 RCX: > > 0000000000000000 > > [853.132873] RDX: 0000000000000007 RSI: ffffffff820c6f58 RDI: > > 00000000ffffffff > > [853.132879] RBP: 0000000000000000 R08: 000000007ffc637a R09: > > 0000000000000000 > > [853.132884] R10: 0000000000000000 R11: 0000000000000000 R12: > > 0000000000000000 > > [853.132890] R13: 0000000000000000 R14: 000000000000d0c2 R15: > > ffff8884a491e680 > > [853.132897] FS: 0000000000000000(0000) GS:ffff8884afe80000(0000) > > knlGS:0000000000000000 > > [853.132904] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > [853.132910] CR2: 00007f63bf0df000 CR3: 0000000005210006 CR4: > > 0000000000760ee0 > > [853.132916] DR0: 0000000000000000 DR1: 0000000000000000 DR2: > > 0000000000000000 > > [853.132922] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: > > 0000000000000400 > > [853.132927] PKRU: 55555554 > > [853.132932] Call Trace: > > [853.132949] ? wait_woken+0xa0/0xa0 > > [853.133068] intel_dp_retrain_link+0x130/0x190 [i915] > > [853.133176] intel_ddi_hotplug+0x54/0x2e0 [i915] > > [853.133298] i915_hotplug_work_func+0x1a9/0x240 [i915] > > [853.133324] process_one_work+0x262/0x630 > > [853.133349] worker_thread+0x37/0x380 > > [853.133365] ? process_one_work+0x630/0x630 > > [853.133373] kthread+0x119/0x130 > > [853.133383] ? kthread_park+0x80/0x80 > > [853.133400] ret_from_fork+0x3a/0x50 > > [853.133433] irq event stamp: 1426928 > > > > I suspect that this is caused by a racy condition when retraining > > the > > DisplayPort link. My proposal is to wait for one additional vblank > > event before we send out a hotplug event to userspace for > > reprobing. > > Problem is just by waiting for the next vblank doesn't rule out > hitting > the same race with another/delayed retraining. If you want > serialisation, please do add some -- and it may be sensible for the > hotplug to wait for the vblank after any ongoing work has finished. This bug rarely happens so that's why I suspected some racy condition. Maybe link retraining just takes too much time so we sometimes hit vblank timeout? Would it be simple enough solution to wait for one vblank between the link retrainings? -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
