Re: Weird clock behaviour with current (amd64) kernel

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

    Date:        Wed, 3 Aug 2022 22:30:34 +0000
    From:        David Holland <dholland-current%netbsd.org@localhost>
    Message-ID:  <Yur3CjWpjcLucNQf%netbsd.org@localhost>

  | so if your previous kernel was fairly old and you
  | still have older boot logs lying around you might check them for
  | such notices.

This is an entirely new system, the oldest kernel it has ever run is 9.99.97
(and that fairly briefly - I had it prepared to install before the hardware
arrived, once it was running I updated the sources and self-built a 9.99.98
(HEAD at the time) system).  It is currently on 9.99.99 from this month
(kernel, userland is still mostly 9.99.98 - though I boot HEAD occasionally
to test X updates).

The issue only occurs when I boot a kernel with options PCI_CONFIG_DUMP
enabled, which is (one way or the other) almost certainly responsible for
the issue - though the problem you mention may be involved in the kernel's
failure to detect that the TSC measurement is being messed up by that option.

I don't really even run with that option any more - it turned out to be
useless (or perhaps useful) for the reason I had it enabled ... I have an
add in PICe SATA card, that the BIOS sometimes manages to hide, and I wanted
to see if I could see what was happening.   That ended up showing me that
as far as NetBSD is concerned, (when in that state) the card simply does not
exist, the slot it is connected to seems empty.

I don't understand how that happens - I would have thought that NetBSD (with
all the options enabled to make this happen - which I think I have) should be
doing PCI config cycles, and everything connected to the bus should be
responding - and the BIOS should not be involved in any of that at all.
A standard PCI bus, as I remember it, has no hidden pins to cause a device
to not respond to a config request, and a plug in card only has the bus as
its interface to the system.  That's certainly what happened when I used to
write code to do that kind of thing (not on an x86 architecture system) long
long long ago.

But that was before PCIe - while at the time I considered PCI to be the one and
only technology to have emerged from the PC world (hardware and software) that
was well enough designed to stand the test of time, I am not sure that PCIe
has continued down the same path, it looks to be to be targeted much more
at the PC world (only) and so perhaps the BIOS is given hidden (to everyone
else) config options which do allow devices to simply vanish, perhaps by being
able to tell the bus slot not to pass on (or through, whatever) CONFIG 
requests.

On the other hand, and while my experience with these on this system is
very limited, I have never seen windows or linux fail to detect the SATA
card (that may be that they never booted while the BIOS was trying to hide it).

kre