Not sure whether it needs to be addressed or not, but for completeness there is the possibility of some sequence of events occasionally emptying the mca_freelist, and then my understanding is that mca_record_entry() will work in "degraded mode" directly call mca_log() in an interrupt context (next to "MCA: Unable to allocate space for an event.\n"), and as long as that situation persists, the corresponding MCA printf() won't be ratechecked any more.

document scheduled removal as 14.0 as suggested.

Document plan for removal as 14.0

In D29385#658103, @cem wrote:

Please update the manual page (which refers to 2^32 now, despite the previously-wrong file comment mentioning 2^31) along with this change.

Updates random.9 man page

I did a couple of experimentation, and bit 0x20 of io-reg 0x61 seems entirely controlled by the chipset "timer-8254" counter2 functionality. You can reset it to zero with "outb(0x43, 0xb0)" and check the effect on inb(0x61) . I don't think it is possible for ipmi/bmc to have any control over it, so it might not be a suitable bit to use to discriminate the possible origin of a NMI.

Thanks for review.

Minor mostly cosmetic improvements.

Remove spurious comment.

Just pushed style fixes.

• Style fixes.

In D19648#420593, @jhb wrote:

I'm curious which hypervisor you have tested this under and did you consider using one of the virtualized clocks if one was available? I know that there are some early patches to add kvmclock support to bhyve for example.

Updating D19648: Add/enable option to allow tsc as timecounter for VM