Hi Jiaxing, Thanks for flagging the job_lock change in the cover. I re-ran the same protocol today on v13 as posted, 2+3 and 2+3+4, three runs each, same board, base and config as on 12 September (JOB_TIMEOUT_MS=2, PROVE_LOCKING, DEBUG_ATOMIC_SLEEP): 73 induced resets with nothing from the driver beyond the timeout message itself, no MMU faults, no lockdep report or warning, and lockdep still armed at the end on both kernels. Of the 126 inferences scored, 118 matched the CPU reference within 1 on all 48 channels, and 8 missed on all 48 with the channels the scorer prints reading 0x80; in the two runs traced with the kprobe, those 5 results sit exactly where the 5 -ECANCELED completions do.
The limits are those of my 12 September mail (all resets on core 0, one client), plus one more: the model is a single 1x1 convolution, which Mesa submits as a one-task job (one completion interrupt per good inference), so hw_submit() never ran from the IRQ thread, which the race you describe needs. So this shows the lock adds no lockdep report or hang on this path, not that it closes the race. On that basis the tag stands for the v13 form of 3/14, with the same comment: Tested-by: Igor Paunovic <[email protected]> # RK3588, three cores, induced reset, JOB_TIMEOUT_MS=2 If 4/14 changes shape in v14, I will re-run that arm. The scripts and the tallies were prepared with an LLM assistant; every number above was counted from the raw files of each run (scorer output, kernel and serial logs, kprobe trace), not from the scripts' summaries. Regards, Igor
