Re: Weird clock behaviour with current (amd64) kernel

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 16 Jul 2022 00:20:41 +0000 (UTC)
    From:        RVP <rvp%SDF.ORG@localhost>
    Message-ID:  <e3cbd85d-cbd-9b20-e01a-f9e748a5c5a1%SDF.ORG@localhost>

  | On Fri, 15 Jul 2022, Robert Elz wrote:
  | > If that is all it is, it is barely worth fixing ... though this
  | > must have happened sometime in the 9.99.9[78] series (sometime
  | > after early last Dec).

  | Farther back than that I think: 9.2_STABLE does the same thing.

Just as likely the relevant change has been pulled up to -9 to get
that result, I haven't booted a -9 with a local kernel recently to
know (but doing that, for other reasons, is possibly going to happen).

But until the graphics update last Dec, I was running HEAD on my
laptop, and updating its kernel frequently, and its cyan console was
100% cyan (no yellow/brown/...) anywhere in sight.   I stopped after
those changes, as my (quite old by then) X server dumped core with the
new drivers, and that wasn't useful...   I believe that issue was fixed,
but before I got around to testing it, the laptop decided to suffer heat
exhaustion (or similar) and really doesn't want to run for more than a
couple of minutes (and right now, is lacking a boot device anyway, I
pulled it).   So I am fairly sure that up until then, all was good
(not using EFI booting though, which now seems to be a difference, it
used EFI partitioning, but using biosboot, with EFI booting, NetBSD seemed
to not find half the hardware ... it does have a fairly early EFI
prom implementation though).

But it appears as if mlelstv@ might have fixed the colour issue now anyway.
(Thanks Michael).   Not that it really was much of an issue.  I will
verify later (maybe tomorrow sometime) - a system with that change
is built already.

kre