created | 2021-08-21T15:06:13Z |
---|---|
begin | 2021-08-14T00:00:00Z |
end | 2021-08-15T00:00:00Z |
path | src/sys |
commits | 1 |
date | 2021-08-14T03:12:51Z | |||
---|---|---|---|---|
author | jsg | |||
files | src/sys/dev/pci/drm/include/linux/workqueue.h | log | diff | annotate |
message |
call task_del() from destroy_work_on_stack() prompted by jcs@ reporting a protection fault trap in drm_mode_rmfb_work_fn() while playing a youtube video in firefox on a kaby lake machine. He later saw the same trace on tiger lake. The previous attempt to avoid this situation by changing work flush functions from taskq_barrier() to taskq_del_barrier() resulted in suspend sometimes not working on various intel based thinkpads. The only code we build which calls destroy_work_on_stack() is in drm_framebuffer.c so the scope of this change is more limited. Linux only uses destroy_work_on_stack() for debugging so the workqueue behaviour still doesn't match. This version is confirmed to not break suspend on x260 by sthen@ and x280 by tb@ and still avoids the original problem according to jcs@ |