Re: [patch 2/2] timekeeping: Always check for negative motion

From: Guenter Roeck
Date: Wed Nov 27 2024 - 18:02:30 EST


On 11/27/24 14:08, John Stultz wrote:
On Sun, Nov 24, 2024 at 4:48 PM Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
On Thu, Oct 31, 2024 at 01:04:08PM +0100, Thomas Gleixner wrote:
clocksource_delta() has two variants. One with a check for negative motion,
which is only selected by x86. This is a historic leftover as this function
was previously used in the time getter hot paths.

Since 135225a363ae timekeeping_cycles_to_ns() has unconditional protection
against this as a by-product of the protection against 64bit math overflow.

clocksource_delta() is only used in the clocksource watchdog and in
timekeeping_advance(). The extra conditional there is not hurting anyone.

Remove the config option and unconditionally prevent negative motion of the
readout.

Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>

This patch causes the kuda-bmc qemu emulation to stall. Reverting it fixes
the problem.


I'm not familiar with kuda-bmc and I'm not finding too many details
searching on it.

Sorry, I keep misspelling it. kudo-bmc.

From other qemu bmc reults I'm guessing this is an arm32 architecture?

Yes.

Do you have any more details about where it's stalling? Also dmesg
details might help illuminate what clocksource was used, etc.
I'm wondering if the clocksource mask value is incorrect for the
clocksource being used here?


An example log is at [1]. It says

clocksource: npcm7xx-timer1: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 597268854 ns
...
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
...
clocksource: Switched to clocksource npcm7xx-timer1

I don't know where exactly it stalls; sometime after handover to userspace.
I'll be happy to do some more debugging, but you'll nee to let me know what
to look for.

Thanks,
Guenter

---
[1] https://kerneltests.org/builders/qemu-arm-v7-master/builds/324/steps/qemubuildcommand/logs/stdio