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

["Taylor R Campbell via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/60467; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Bruno Haible <bruno%clisp.org@localhost>
Cc: kern-bug-people%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
	gnats-admin%netbsd.org@localhost, gnats-bugs%netbsd.org@localhost
Subject: Re: 
	Re: kern/60467 (timers and console keyboard driver broken with 32 GiB of RAM)
Date: Thu, 20 Aug 2026 18:57:17 +0000

 > Date: Mon, 20 Jul 2026 18:27:43 +0200
 > From: Bruno Haible <bruno%clisp.org@localhost>
 >=20
 > > Can you also try a netbsd-9 image and a netbsd-11 image to compare?
 >=20
 > 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.
 >=20
 > 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.
 >=20
 > > Can you please share the output of:
 > > - dmesg
 > > - sysctl kern.timecounter
 > > with the two different RAM amounts?
 >=20
 > Find attached the output files, one for each of the situations.
 >=20
 > 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 =3D TSC(q=3D-100, f=3D622668240 Hz) clockinterrup=
 t(q=3D0, f=3D100 Hz) lapic(q=3D-100, f=3D309578000 Hz) ACPI-Safe(q=3D900, f=
 =3D3579545 Hz) i8254(q=3D100, f=3D1193182 Hz) dummy(q=3D-1000000, f=3D10000=
 00 Hz)
 + kern.timecounter.choice =3D TSC(q=3D-100, f=3D-639859150 Hz) clockinterru=
 pt(q=3D0, f=3D100 Hz) lapic(q=3D-100, f=3D2607492568 Hz) ACPI-Safe(q=3D900,=
  f=3D3579545 Hz) i8254(q=3D100, f=3D1193182 Hz) dummy(q=3D-1000000, f=3D100=
 0000 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=3D1.9#47
 
     345 			slen =3D snprintf(buf, sizeof(buf), "%s%s(q=3D%d, f=3D%" 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=3D1.80#345
 
 But presumably there's a sign-extended 32-bit/64-bit mixup happening
 somewhere too to make things negative in some cases.