https://bugzilla.kernel.org/show_bug.cgi?id=207383 Duncan (1i5t5.duncan@xxxxxxx) changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #290101|0 |1 is obsolete| | --- Comment #39 from Duncan (1i5t5.duncan@xxxxxxx) --- Created attachment 290105 --> https://bugzilla.kernel.org/attachment.cgi?id=290105&action=edit Partial git bisect log update #3 (In reply to Duncan from comment #38) > With luck I'll get a couple more bad ones > right away and narrow it down quickly. And so it is. 28 candidates ATM, several of which are OCFS2 or spelling fixes neither of which should affect this bug. Excluding those there are eleven left; the penultimate (next to last) one looks to be a good candidate: 5f2d5026b mm/Makefile: disable KCSAN for kmemleak b0d14fc43 mm/kmemleak.c: use address-of operator on section symbols 667c79016 revert "topology: add support for node_to_mem_node() to determine the fallback node" 3202fa62f slub: relocate freelist pointer to middle of object 1ad53d9fa slub: improve bit diffusion for freelist ptr obfuscation bbd4e305e mm/slub.c: replace kmem_cache->cpu_partial with wrapped APIs 4c7ba22e4 mm/slub.c: replace cpu_slab->partial with wrapped APIs c537338c0 fs_parse: remove pr_notice() about each validation 630f289b7 asm-generic: make more kernel-space headers mandatory 98c985d7d kthread: mark timer used by delayed kthread works as IRQ safe 4054ab64e tools/accounting/getdelays.c: fix netlink attribute length My gut says it's 98c "kthread: mark ... delayed kthread... IRQ safe". Not a coder but the comment talks about delayed kthreads, we always see the workqueue in the traces, and mnrzk observes in comment #30 that forcing drm_atomic_helper_commit to run directly instead of using the workqueue seems to eliminate the freeze. If it's called from the amdgpu code and that commit changes the IRQ-safety assumptions the amdgpu code was depending on in the workqueue, where the unqueued context is automatically IRQ-safe... Still could be wrong, but at 11 real candidates it's a 9% chance even simply statistically, and it sure seems to fit. Anyway, if it /is/ correct, the next few bisect steps should be bisect bad and thus go faster, narrowing it down even further. Regardless, we're down far enough that someone that can actually read code might be able to take a look at that and the others now, so my bisect shouldn't be the /entire/ bottleneck any longer. -- You are receiving this mail because: You are watching the assignee of the bug. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
