Date: Wed, 3 Aug 2022 22:30:34 +0000 From: David Holland <dholland-curr...@netbsd.org> Message-ID: <yur3cjwpjcluc...@netbsd.org>
| 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