red-ray wrote on 2025-05-25, 15:18:

Oh, I did not know there is a fan status bit, is it documented how do I read it and if so where please? I wonder if it reports the RPM, where can I get it from?

The official Intel datasheet just says "contact Intel for more information": https://datasheets.chipdb.org/Intel/x86/486/a … ts/29043606.PDF page 60:

Overdrive Processors datasheet wrote:

12.6 Fan Protection Mechanism and THermal ERRor Bit

The Pentium OverDrive processor employs an active fan/heatsink unit to assist in cooling the processor. Another integral part of this cooling solution is the ability for software to poll the status of the fan to determine if the fan has fallen to a speed that is unacceptable to cool the processor. Should the fan fall into a speed range that is too slow, a control register will record the event. (For more information, please contact Intel.

There also is a reference to a fan monitoring tool by Intel in the Pentium Overdrive application note. https://ardent-tool.com/CPU/docs/Intel/Pentiu … /241428-003.pdf pdf page 587 might possibly refer to the 486 PODP, but possibly later Socket 5 PODPs instead. In any case, it wouldn't surprise me if the mechanism on the PODP is as described. While the PODP does not support the Machine Check Exception, the Thermal Error bit in the Machine Check Type MSR is explicitly stated to not be related to generation of Machine Check Exceptions. So you might just try whether bit 5 in MSR 1 (the Machine Check Type MSR) also works on the P24T.

red-ray wrote on 2025-05-25, 15:18:

It's not just the PODs I was considering, I was thinking about doing this for all P5 CPUs.

Indeed, measuring the difference between 50*3 and 60*2.5 on a P54C at 150MHz might be interesting. In this case, the algorithm needs to cope with 32-byte cache lines and the dual execution unit architecture. I might consider doing a separate P5mul for that. As the P5 architecture is still in-order, this approach may be usable. This approach is likely harder to implement on out-of-order architectures like the K6 or 6x86 though.

mkarcher wrote on 2025-05-25, 07:55:

The scope of this tool is to report reliable results all the time in DOS. The key idea is to show an algorithm that could be used by BIOS writers in auto-configuration mode to distinguish 2*50 from 3*33 for processors that do not yet report the multiplier in the CPUID value / DX after reset. It is written in a way that it likely also well in multitasking environments, as long as the handling of timer channel 2 and its interoperation with port 61 is emulated properly, or those bits are passed through to the actual hardware. Tests show good results on both the Windows 95 and Windows 2000 DOS compatibility now, but there might be situations in which the measurement fails.

Since a BIOS writer can write chipset-specific code, does that help any in this case, or even with that ability do chipsets not really help you measure the external vs. internal clocks precisely?
And even if it can, I suspect AMI/Award tried to cordon off CPU detection as chipset-neutral, so they aren't having to think about how to detect a TI Potomac (for example) when porting to a new chipset.

By the way, is the socket 3 Pentium OverDrive fan thing the first example of thermal throttling ever?

jakethompson1 wrote on 2025-05-25, 17:44:

Since a BIOS writer can write chipset-specific code, does that help any in this case, or even with that ability do chipsets not really help you measure the external vs. internal clocks precisely?

I am not aware of chipsets that provide an easy way to measure the bus clock. You might get away by timing a REP INSB on some chipset control port, and in case that control port is implemented on the ISA side, by previously initializing a well-known ISA divider.

jakethompson1 wrote on 2025-05-25, 17:44:

And even if it can, I suspect AMI/Award tried to cordon off CPU detection as chipset-neutral

Both the code to detect the CPU (Cyrix via flags on DIV and their DIR, all others via DX-on-reset) and to detect the CPU clock is chipset neutral, at least in the Award BIOS. With 386 processors (not talking about the 486SLC2 or stuff like that), autoconfig could just use the CPU clock, but with the arrival of clock-doubled processors, the BIOS needed a way to determine the FSB clock for autoconfig. Award has an "is clock doubled" bit in the processor type byte(s), and later upgraded to two bits (IIRC) to also support "is clock trippled" or "is clock quadrupled". These bits are typically initialized with the processor identification. IIRC Award special-cases "clock doubled, fCPU=100MHz" and remaps it to "clock trippled" to support CPUs that "look like" a DX2, but are a DX4 instead.

jakethompson1 wrote on 2025-05-25, 17:44:

By the way, is the socket 3 Pentium OverDrive fan thing the first example of thermal throttling ever?

It's not "thermal" throttling. The fan failure detection is driven by a tachometer, not a temperature sensor. Possibly its the first widespread implementation of gracefully handling a failed cooling system in standard PC components, though. I don't know of anything like that offhand. I do know that some systems, e.g. Compaq Deskpro XL computers, refused to power up if the fan unit was not correctly connected to the mother board, but this is not "graceful" or "throttling", but just "emergency shutoff".

jakethompson1 wrote on 2025-05-25, 17:44:

By the way, is the socket 3 Pentium OverDrive fan thing the first example of thermal throttling ever?

I neither would call that throttling.
Although I do not know what Pentiums did, but at least later Pentium 3 Tualatins halted clock when overheating without any resume until reset.
Pentium 4 did slow down heavily but that was reversible.
Athlons? Well, it was some kind of... lava generation.

You need to know that power density on a silicon die of a CPU was in the region of active fuel rods of a nuclear power plant...