Hi Jiaxing, Thanks for going back over it, but the correction needs one more turn: both sets of numbers are mine, from two different days.
The 45 (12 + 8 + 12 + 13) is the 19 August A/B square on v8 1-2/12 [1]: no manifestation on either arm, oracle 48/48 throughout. That is what the patch text describes, and it is right. The 102 is the 25 August re-run on v9 as posted [2]: v9 arm 12 + 11 resets, all 48/48; differential arm (same base, 1/13 and 2/13 removed) five runs, 8/10/12/8/15; plus 13 + 13 on a third arm with 3/13 added [3]. In one of the five differential runs the inference issued after the forced autosuspend/resume "succeeded" and returned all 48 output channels at 0x80 while the CPU reference varied normally, with nothing in dmesg, lockdep or on the serial console. That run was on RK3588, on my board, and the v10 cover quoted it as I wrote it. So the signature is shared, not carried over. Your explanation of it (fresh shmem BO zeroed, teflon readback adding 0x80) is the same mechanism I inferred from the scorer, which flagged 128 as not this model's zero point, i.e. an output buffer that was never written. What holds is the caveat I put on it then: one event in 53 differential resets, zero in 49 with the patches, timing-dependent, and my protocol cannot tell a genuinely hung block from a lost completion. It bounds; it does not prove. The artifacts (scorer output, runtime and genpd state, journal, serial log) are preserved if you or Tomeu want them. If you respin, both statements can stand next to each other: 45 resets with no manifestation on 19 August, and one silent completion on the unpatched arm out of 102 resets on 25 August. [1] https://lore.kernel.org/all/[email protected]/ [2] https://lore.kernel.org/all/caewpsh5mxtbuknouxm6yecmzyvdowquhvyvhaxq8homthd5...@mail.gmail.com/ [3] https://lore.kernel.org/all/caewpsh5mvzoqmafoeq93+1popmcxcdnfuxsv5j-x8lb1fy_...@mail.gmail.com/ Regards, Igor
