From: Igor Paunovic <royalnet026@gmail.com>
To: Jiaxing Hu <gahing@gahingwoo.com>
Cc: Tomeu Vizoso <tomeu@tomeuvizoso.net>,
linux-rockchip@lists.infradead.org,
dri-devel@lists.freedesktop.org,
Igor Paunovic <royalnet026@gmail.com>
Subject: Re: [PATCH v10 00/13] accel/rocket: RK3576 NPU (RKNN) enablement
Date: Fri, 11 Sep 2026 21:28:32 +0200 [thread overview]
Message-ID: <20260911192833.105634-1-royalnet026@gmail.com> (raw)
In-Reply-To: <20260911122832.1364839-1-gahing@gahingwoo.com>
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/20260819073530.6087-1-royalnet026@gmail.com/
[2] https://lore.kernel.org/all/CAEWPSH5mxTbUkNouxm6yecMZYvDowquhvYvhaXQ8HoMtHD5U1g@mail.gmail.com/
[3] https://lore.kernel.org/all/CAEWPSH5MVzoQMaFOEQ93+1pOPmcXCDNfuXsv5j-X8Lb1fy_hrg@mail.gmail.com/
Regards,
Igor
WARNING: multiple messages have this Message-ID (diff)
From: Igor Paunovic <royalnet026@gmail.com>
To: Jiaxing Hu <gahing@gahingwoo.com>
Cc: Tomeu Vizoso <tomeu@tomeuvizoso.net>,
linux-rockchip@lists.infradead.org,
dri-devel@lists.freedesktop.org,
Igor Paunovic <royalnet026@gmail.com>
Subject: Re: [PATCH v10 00/13] accel/rocket: RK3576 NPU (RKNN) enablement
Date: Fri, 11 Sep 2026 21:28:32 +0200 [thread overview]
Message-ID: <20260911192833.105634-1-royalnet026@gmail.com> (raw)
In-Reply-To: <20260911122832.1364839-1-gahing@gahingwoo.com>
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/20260819073530.6087-1-royalnet026@gmail.com/
[2] https://lore.kernel.org/all/CAEWPSH5mxTbUkNouxm6yecMZYvDowquhvYvhaXQ8HoMtHD5U1g@mail.gmail.com/
[3] https://lore.kernel.org/all/CAEWPSH5MVzoQMaFOEQ93+1pOPmcXCDNfuXsv5j-X8Lb1fy_hrg@mail.gmail.com/
Regards,
Igor
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2026-09-11 19:29 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 4:07 [PATCH v10 00/13] accel/rocket: RK3576 NPU (RKNN) enablement Jiaxing Hu
2026-08-31 4:07 ` Jiaxing Hu
2026-08-31 4:07 ` [PATCH v10 01/13] accel/rocket: take the completion register writes under job_lock Jiaxing Hu
2026-08-31 4:07 ` Jiaxing Hu
2026-08-31 4:07 ` [PATCH v10 02/13] accel/rocket: wait for a running IRQ handler before resetting a core Jiaxing Hu
2026-08-31 4:07 ` Jiaxing Hu
2026-08-31 4:07 ` [PATCH v10 03/13] accel/rocket: let the core suspend after a reset Jiaxing Hu
2026-08-31 4:07 ` Jiaxing Hu
2026-08-31 4:07 ` [PATCH v10 04/13] accel/rocket: factor the completion tail out of the IRQ handler Jiaxing Hu
2026-08-31 4:07 ` Jiaxing Hu
2026-08-31 4:07 ` [PATCH v10 05/13] dt-bindings: npu: rockchip: add rockchip, rk3576-rknn-core Jiaxing Hu
2026-08-31 4:07 ` [PATCH v10 05/13] dt-bindings: npu: rockchip: add rockchip,rk3576-rknn-core Jiaxing Hu
2026-08-31 4:07 ` Jiaxing Hu
2026-08-31 4:07 ` [PATCH v10 06/13] dt-bindings: power: rockchip: allow resets in a power domain node Jiaxing Hu
2026-08-31 4:07 ` Jiaxing Hu
2026-08-31 4:07 ` [PATCH v10 07/13] dt-bindings: iommu: rockchip: describe the RK3576 NPU MMU Jiaxing Hu
2026-08-31 4:07 ` Jiaxing Hu
2026-08-31 4:07 ` [PATCH v10 08/13] pmdomain/rockchip: add optional per-domain power-on settle delay Jiaxing Hu
2026-08-31 4:07 ` Jiaxing Hu
2026-08-31 4:08 ` [PATCH v10 09/13] pmdomain/rockchip: cycle optional power-domain resets on power-on Jiaxing Hu
2026-08-31 4:08 ` Jiaxing Hu
2026-08-31 4:08 ` [PATCH v10 10/13] accel/rocket: select the per-core clock and reset counts from match data Jiaxing Hu
2026-08-31 4:08 ` Jiaxing Hu
2026-08-31 4:08 ` [PATCH v10 11/13] accel/rocket: add RK3576 NPU (RKNN) support Jiaxing Hu
2026-08-31 4:08 ` Jiaxing Hu
2026-08-31 4:08 ` [PATCH v10 12/13] arm64: dts: rockchip: rk3576: add NPU (RKNN) nodes Jiaxing Hu
2026-08-31 4:08 ` Jiaxing Hu
2026-08-31 4:08 ` [PATCH v10 13/13] arm64: dts: rockchip: rk3576-rock-4d: enable NPU Jiaxing Hu
2026-08-31 4:08 ` Jiaxing Hu
2026-08-31 7:20 ` [PATCH v10 00/13] accel/rocket: RK3576 NPU (RKNN) enablement Tomeu Vizoso
2026-08-31 7:20 ` Tomeu Vizoso
2026-09-11 12:28 ` Jiaxing Hu
2026-09-11 12:28 ` Jiaxing Hu
2026-09-11 19:28 ` Igor Paunovic [this message]
2026-09-11 19:28 ` Igor Paunovic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260911192833.105634-1-royalnet026@gmail.com \
--to=royalnet026@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gahing@gahingwoo.com \
--cc=linux-rockchip@lists.infradead.org \
--cc=tomeu@tomeuvizoso.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.