Re: [PATCH v8 02/12] accel/rocket: wait for a running IRQ handler before resetting a core

[Igor Paunovic <royalnet026@gmail.com>]

Hi Jiaxing,

The three-run design with the deterministic third arm is exactly the
de-confounding you promised, and declaring the fourth run void instead
of letting it pad the table is the kind of honesty that makes the rest
easy to trust. Glad the third bullet closed on silicon - one line, as
you say - and thank you for the Reported-by.

Meanwhile the differential finished here. The base build existed as a
pair with the patched one from the start, so this is the same machine,
same morning, same session.

Base kernel: identical tree and config, same JOB_TIMEOUT_MS=2 local
patch, with 1/12 and 2/12 not applied. Same protocol, two passes per
kernel at console_loglevel 8 and 4:

              loglevel 8   loglevel 4   recovery   oracle
  with 1+2/12     12            8        all clean  48/48 both passes
  without         12           13        all clean  48/48 both passes

Zero MMU_DTE_ADDR, zero "Error during raw reset", zero lockdep or
atomic-sleep hits on either kernel; the domain dropped and all three
cores returned to runtime-suspended between rounds on both.

Your distinction between the two tests deserves my numbers next to it:
all 45 of my resets hit a healthy block crossing a 2 ms timeout, and
the domain dropped every single time, on both kernels. Whether a
genuinely hung block would keep an RK3588 domain up the way your
failing runs stay up on RK3576, this protocol cannot say - I do not
yet know how to manufacture a real hang deliberately. So the honest
summary of that difference: the step your failing runs are missing
simply never goes missing here under my conditions, and I cannot
reproduce yours.

The race itself did not manifest in the 45 resets on either kernel.
Timeouts are easy to induce; a completion racing the reset inside a
microseconds-wide window is not, so the justification for the pair
remains the source analysis. The tag attests what was actually tested:
recovery and absence of regressions on the patched kernel, against a
differential base.

For 1/12 my v7 Tested-by carries to the v8 shape as re-run here. For
2/12:

Tested-by: Igor Paunovic <royalnet026@gmail.com> # RK3588, three cores,
                                                 # induced reset, differential
                                                 # base, JOB_TIMEOUT_MS=2

I understand the v9 sync patch will carry the interrupt mask and so
change shape; the harness here is standing, so say the word when v9 is
posted and I will re-run the protocol on it as-is.

Regards,
Igor