mirrors/linux
1
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git synced 2025-12-27 11:06:41 -05:00
Code Issues Packages Projects Releases Wiki Activity

m68k: mac: Improve clocksource driver commentary

Browse Source 
qemu-system-m68k -M q800 has an old bug that causes the kernel to
occasionally complain about a soft lockup:

    watchdog: BUG: soft lockup - CPU#0 stuck for 5107s!

There isn't any actual lockup. The via1 clocksource produced a large
jump in jiffies, causing the watchdog to detect a stale timestamp.

The 32-bit clocksource counter runs at 783360 Hz and its period is
about 5482 seconds. Applying the "nanosecond" approximation used in
get_timestamp() in kernel/watchdog.c then yields the duration reported
in the log message above (always 5107 or 5108 in my tests):

0xffffffff / VIA_CLOCK_FREQ * 10**9 / 2**30 = 5106.209 seconds

It is notoriously difficult to correctly emulate a MOS6522 VIA chip. So
it seems wise to document the VIA clocksource driver better, especially
those hardware behaviours which the kernel relies upon.

Cc: Joshua Thompson <funaho@jurai.org>
Signed-off-by: Finn Thain <fthain@linux-m68k.org>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Link: https://lore.kernel.org/f7b4c02a1c8ed74ccceb5535d7e1e202deada8ce.1750739568.git.fthain@linux-m68k.org
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
This commit is contained in:
Finn Thain
2025-06-24 14:32:48 +10:00
committed by Geert Uytterhoeven
parent c4958c118c
commit c8995932db
1 changed files with 16 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
arch/m68k/mac/via.c
View File

@@ -621,6 +621,22 @@ static u64 mac_read_clk(struct clocksource *cs)
* These problems are avoided by ignoring the low byte. Clock accuracy
* is 256 times worse (error can reach 0.327 ms) but CPU overhead is
* reduced by avoiding slow VIA register accesses.
*
* The VIA timer counter observably decrements to 0xFFFF before the
* counter reload interrupt gets raised. That complicates things a bit.
*
* State | vT1CH | VIA_TIMER_1_INT | inference drawn
* ------+------------+-----------------+-----------------------------
* i | FE thru 00 | false | counter is decrementing
* ii | FF | false | counter wrapped
* iii | FF | true | wrapped, interrupt raised
* iv | FF | false | wrapped, interrupt handled
* v | FE thru 00 | true | wrapped, interrupt unhandled
*
* State iv is never observed because handling the interrupt involves
* a 6522 register access and every access consumes a "phi 2" clock
* cycle. So 0xFF implies either state ii or state iii, depending on
* the value of the VIA_TIMER_1_INT bit.
*/
local_irq_save(flags);