Re: [PATCH] drivers/clocksource/arm_arch_timer: Tighten Allwinner arch timer workaround

From: Marc Zyngier <maz@kernel.org>
To: Ilya Dikariev <dikarill@b-tu.de>
Cc: "Mark Rutland" <mark.rutland@arm.com>,
	"Daniel Lezcano" <daniel.lezcano@linaro.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Samuel Holland" <samuel@sholland.org>,
	"Chen-Yu Tsai" <wens@csie.org>,
	"Jernej Škrabec" <jernej.skrabec@gmail.com>,
	linux-sunxi@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drivers/clocksource/arm_arch_timer: Tighten Allwinner arch timer workaround
Date: Thu, 10 Nov 2022 08:31:21 +0000	[thread overview]
Message-ID: <87k043us6e.wl-maz@kernel.org> (raw)
In-Reply-To: <20221109221049.4bf3c5bb@rosh>

On Wed, 09 Nov 2022 21:10:49 +0000,
Ilya Dikariev <dikarill@b-tu.de> wrote:
> 
> As we know, the Allwinner A64 SoC has a buggy RCU time unit. The

What is RCU?

> workaround named UNKNOWN1 was not sufficient to cover some more buggy
> bunches of this SoC. This workaround diminish the mask to 8 bits instead
> of 9.
> 
> An example run of timer test tool https://github.com/smaeul/timer-tools
> on PinePhone device (owns the A64 SoC) gives following result on a non
> patched kernel (cut off):
> 
> Running parallel counter test...
> 0: Failed after 5507 reads (0.003578 s)
> 0: 0x0000000c8272cbf1 -> 0x0000000c8272ccff -> 0x0000000c8272cc0e (     0.011 ms)
> 2: Failed after 14518 reads (0.009248 s)
> 2: 0x0000000c827513f1 -> 0x0000000c82751300 -> 0x0000000c8275140e (    -0.010 ms)
> 3: Failed after 14112 reads (0.008730 s)
> 3: 0x0000000c8274f3f2 -> 0x0000000c8274f300 -> 0x0000000c8274f40d (    -0.010 ms)
> 1: Failed after 12030 reads (0.008409 s)
> 1: 0x0000000c8274abf1 -> 0x0000000c8274acff -> 0x0000000c8274ac0f (     0.011 ms)
> 1: 0x0000000c827759f2 -> 0x0000000c82775aff -> 0x0000000c82775a0e (     0.011 ms)
> 0: 0x0000000c8277a9f2 -> 0x0000000c8277aaff -> 0x0000000c8277aa0d (     0.011 ms)
> 2: 0x0000000c8278f3f1 -> 0x0000000c8278f300 -> 0x0000000c8278f40e (    -0.010 ms)
> 0: 0x0000000c82785ff2 -> 0x0000000c82784300 -> 0x0000000c8278600d (    -0.309 ms)
> 
> After the proposed patch applied the test runs
> correctly (~2 hours of testing with a tool above without fails)

2 hours seems like an incredibly small amount of time given that the
existing workaround was believed to be correct. Run it continuously
for a couple of weeks on several different machines with varying
workloads and less us know the outcome.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.