Re: Re: kern/60467 (timers and console keyboard driver broken with 32 GiB of RAM)

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Mon, 20 Jul 2026 18:27:43 +0200
> From: Bruno Haible <bruno%clisp.org@localhost>
> 
> > Can you also try a netbsd-9 image and a netbsd-11 image to compare?
> 
> In a NetBSD 9.0 VM with 32 GiB of RAM, the message
> "Login timed out after 300 seconds" appears after 300 seconds,
> and there is no keyboard problem.
> 
> In a NetBSD 11.0-rc3 VM with 32 GiB of RAM, things are like with
> NetBSD 10.0: the message "Login timed out after 300 seconds" appears
> after 82 seconds, and there is a keyboard problem.
> 
> > Can you please share the output of:
> > - dmesg
> > - sysctl kern.timecounter
> > with the two different RAM amounts?
> 
> Find attached the output files, one for each of the situations.
> 
> Note: A workaround for the keyboard problem is to type each keystroke
> separately as a short, sharp keystroke (no fluent typing).

Thanks!  Sorry about the spam from gnats -- I forgot to move the PR
out of the `feedback' state when you provided feedback last month.

At some point I'll try to reproduce this and the PR 60220 crash under
vbox and/or kvm.  In the mean time, could I trouble you to provide
dmesg from a netbsd-11 or current kernel with `boot -vx' (verbose +
debug boot output), with 31GB and 32GB of RAM?

I'm expecting to find some output with the text `calibrating local
timer' or `recalibrating local timer' and the frequency that NetBSD
thinks the host's lapic timer is running at.

Also, once you've booted it, can you share the output of the following
commands with crash(8), in both boots (once with 31GB and once with
32GB)?

# crash
crash> x/d lapic_per_second
crash> x/d lapic_tval
crash> x/d hz


I saw a symptom like this when we had a bug in lapic timer frequency
calibration:

PR port-amd64/59424: hardclock ticks run at breakneck pace under qemu
https://gnats.NetBSD.org/59424

But the mechanism for that manifestation of the symptom, which
involved both qemu and nvmm, is obviously not relevant when running
under vbox/kvm.

I notice this particularly interesting line in the output you already
provided from netbsd10-32GB.out (-, bad) and netbsd10-31GB.out (+,
good):

- kern.timecounter.choice = TSC(q=-100, f=622668240 Hz) clockinterrupt(q=0, f=100 Hz) lapic(q=-100, f=309578000 Hz) ACPI-Safe(q=900, f=3579545 Hz) i8254(q=100, f=1193182 Hz) dummy(q=-1000000, f=1000000 Hz)
+ kern.timecounter.choice = TSC(q=-100, f=-639859150 Hz) clockinterrupt(q=0, f=100 Hz) lapic(q=-100, f=2607492568 Hz) ACPI-Safe(q=900, f=3579545 Hz) i8254(q=100, f=1193182 Hz) dummy(q=-1000000, f=1000000 Hz)

Note that the tsc frequency is positive 623 MHz in the bad case, and
_negative_ 640 MHz in the _good_ case, which is very weird!
(netbsd10-31GB.out worked fine without the keyboard repeats, right?)

This must happen in part because the uint64_t tc_frequency member is
printed with PRId64 instead of PRIu64:

     47 struct timecounter {
...
     63 	uint64_t		tc_frequency;

https://nxr.netbsd.org/xref/src/sys/sys/timetc.h?r=1.9#47

    345 			slen = snprintf(buf, sizeof(buf), "%s%s(q=%d, f=%" PRId64
    346 					" Hz)", spc, tc->tc_name, tc->tc_quality,
    347 					tc->tc_frequency);

https://nxr.netbsd.org/xref/src/sys/kern/kern_tc.c?r=1.80#345

But presumably there's a sign-extended 32-bit/64-bit mixup happening
somewhere too to make things negative in some cases.