[DF4842] test1 (case B): scheduler thread busy in run_job() when drm_sched_fini() runs
[DF4842] sched thread: task=0xfffff8008f8ecf00 dfly_td=0xfffff800905fc100 cpu=1
[DF4842] run_job(job=0xfffff8008f8ed080): entered on td=0xfffff800905fc100 cpu=1 - now BUSY-SPINNING 4s (no blocking: td stays TDF_RUNNING)
Sep 24 12:31:35 dfbsd kernel: [drm] amdgpu kernel modesetting enabled.
[DF4842] run_job(job=0xfffff8008f8ed080): spin done (too late for kthread_stop's 1s window)
[DF4842] calling drm_sched_fini(): kthread_stop sets SHOULD_STOP, tsleeps its FIXED 1s, then lwkt_free_thread() on the still-TDF_RUNNING td 0xfffff800905fc100 -> expect KKASSERT panic
[DF4842] drm_sched_fini RETURNED (no panic?!)
[DF4842] test2 (case A): idle sched thread exits fast; td parked in gd_freetd AND objcache_put by kthread_stop
[DF4842] round 1: sched thread td=0xfffff8008e11ce00 on cpu=2; calling drm_sched_fini() (kthread_stop: 1s tsleep + lwkt_free_thread)
[DF4842] drm_sched_fini returned; sysctl cpu was 1, now 1; staging gd_freetd proof on cpu 2
[DF4842] probe: cpu=2 gd_freetd=0xfffff8008e11ce00 tdS=0xfffff8008e11ce00 -> == tdS STILL PARKED in gd_freetd (while kthread_stop already objcache_put() it into thread_cache: DOUBLE OWNERSHIP)
[DF4842] launching sacrificial exit thread on cpu=2
[DF4842] sacr: exiting on cpu=2 - lwkt_exit() will now objcache_put(gd_freetd=tdS 0xfffff8008e11ce00) AGAIN (2nd put)
[DF4842] scan(cpu=2) alloc 1: thread_cache handed out tdS 0xfffff8008e11ce00 — SAME struct thread in a NEW allocation while the 2nd put also sits in the cache
[DF4842] scan(cpu=2): done, 1 tdS hits in 16 allocs
[DF4842] round 1 result: 1 allocation hit(s) for tdS 0xfffff8008e11ce00 after the double put