We have profiled WiFi vendors who are hostile, indifferent, and chaotic. Today we leave wireless behind and discuss a driver that has nothing to do with networking.

Today we discuss the chip that watches your motherboard.

The Supreme Leader boots BSD too, and the chip does not care. The register map is the same on whichever Unix you choose; only the tooling names change.

The Super I/O.

Right now, on your motherboard, there is a small chip that most users have never noticed, most administrators have never configured, and most engineers have never thought about. It is not the CPU. It is not the RAM. It is not the GPU or the NVMe controller or the WiFi radio. It is a chip the size of a fingernail, soldered near the south bridge, connected over a bus called LPC — Low Pin Count — that runs at the speed of hardware designed in 1998.

This chip reads your fan speeds. It monitors your CPU temperature. It watches your voltage rails. It controls whether your fans spin at 800 RPM or 3000 RPM. If your motherboard has a temperature alarm, this chip triggers it. If your BIOS shows “CPU Temperature: 45°C” on the hardware monitor page, this chip provided that number.

It is called the Super I/O. It has been on every PC motherboard since the late 1980s. And the company that makes most of them is Nuvoton.

The Lineage:

Nuvoton Technology Corporation was spun off from Winbond Electronics on July 1, 2008. Winbond’s computer IC, consumer electronics IC, and logic product divisions became Nuvoton. The company went public on the Taiwan Stock Exchange in September 2010.

But Nuvoton’s Super I/O chips did not start in 2008. They started as Winbond chips — the W83627, the W83697, and their many variants. If you ran lm_sensors on a Linux machine between 2000 and 2010, you probably loaded the w83627hf or w83627ehf driver. Those were Winbond chips. Same silicon lineage, same register layouts, new company name.

When Nuvoton took over, the chip series became the NCT6775, NCT6776, NCT6779, and eventually the NCT6791, NCT6793, NCT6796, NCT6797, NCT6798, and beyond. The driver in the Linux kernel is nct6775, and it replaced the old w83627ehf driver for the newer chips.

Same function. Same bus. Same register-level dance with the BIOS. Different branding.

What the Chip Does:

The Super I/O is the motherboard’s nervous system. It handles everything that is too slow, too simple, or too legacy for the main chipset to bother with:

Function	Details
Temperature monitoring	Up to 25 sources — direct sensors, PECI (CPU), PCH, SMBUS
Fan speed monitoring	4 to 5 fan tachometer inputs
Fan speed control	PWM outputs, automatic regulation based on temperature curves
Voltage monitoring	8 to 15 analog inputs — CPU, RAM, 3.3V, 5V, 12V rails
Hardware alarms	Beep warnings if temperature or voltage exceeds thresholds
Legacy I/O	Serial ports (UART), parallel ports, PS/2 keyboard/mouse
GPIO	General-purpose I/O pins for OEM-specific functions

The chip communicates over the LPC bus — a low-bandwidth interface between the Super I/O and the chipset’s south bridge. LPC replaced ISA in the late 1990s. Before that, Super I/O chips sat on the ISA bus. Before that, they were on expansion cards.

The LPC bus runs at 33 MHz with a 4-bit data width. In an age where your NVMe drive reads at 7 GB/s, the chip that monitors your system health talks to your CPU at the speed of a 1998 modem negotiation. This is fine. Fan speeds do not change at gigabit rates. Temperatures do not need nanosecond polling. The Super I/O is slow because it does not need to be fast.

The Driver Problem:

Here is where the story gets interesting. And by interesting, I mean infuriating.

The Super I/O chip is controlled by two masters: the BIOS and the operating system. Both want to read the same sensors. Both want to control the same fans. They access the same hardware registers through the same I/O ports. And they do not coordinate.

On Linux, when you run sensors-detect from the lm_sensors package, it probes the Super I/O chip by writing to I/O ports 0x2E/0x2F or 0x4E/0x4F. These are the same ports the BIOS uses. If the BIOS has registered these ports as ACPI resources — which it often does — the kernel will refuse to let the hardware monitoring driver access them.

The error looks like this: “ACPI resource conflict”. The BIOS claims ownership of the hardware. The driver cannot load. Your fan speeds are invisible to the OS.

The workaround: add acpi_enforce_resources=lax to your kernel parameters. This tells the kernel to ignore the ACPI resource claims and let the driver access the ports anyway. This works. It is also the kernel equivalent of picking a lock on a door that belongs to you.

The BIOS and the OS are fighting over the same chip, on the same motherboard, that you own. The BIOS got there first and claimed the registers. The OS respects the claim. You must tell the OS to stop respecting it.

The ASUS Problem:

ASUS motherboards deserve special mention.

On various ASUS boards with the NCT6776F, the CPUTIN temperature input — which should report the CPU temperature — is not connected to anything. It floats. It reports whatever electrical noise is on the trace. Users see temperatures like 112°C or -5°C and panic.

CPUTIN — not to be confused with a certain comrade — conducts its own special operation: reporting fabricated data to cause widespread panic while accomplishing absolutely nothing. The parallels end there. One is a floating pin on an ASUS motherboard. The other is a floating policy in Eastern Europe. Both produce numbers that nobody should trust.

The actual CPU temperature on ASUS boards is available via PECI 0 — a digital interface from the CPU package — or TSI 0. But lm_sensors labels the floating CPUTIN as the CPU temperature because that is what the register name says.

The fix is to ignore CPUTIN on ASUS boards. The kernel driver documentation says this. The lm_sensors configuration guides say this. And every month, a new user on a forum posts “my CPU is at 112°C, is my computer on fire?” because ASUS did not connect a temperature pin and nobody reads the documentation.

This is not a driver bug. This is not a Nuvoton bug. This is a motherboard manufacturer vibecoding a chip — connecting pins based on vibes rather than the datasheet and hoping the numbers make sense. The driver faithfully reports the incorrect data. The driver is honest. The hardware is lying.

The NCT6775 Family:

The kernel driver nct6775 supports a growing list of Nuvoton Super I/O chips:

Chip	Year	Notes
NCT6106D	~2013	Early model
NCT6775F	~2012	First in the new naming scheme
NCT6776F	~2012	No fan divisor (simplified)
NCT6779D	~2013	Drops VID support
NCT6791D	~2015	Added features
NCT6792D	~2015	Variant
NCT6793D	~2016	Common in Ryzen-era boards
NCT6795D	~2017	Variant
NCT6796D	~2017	eSPI support, also -E and -S sub-variants
NCT6797D	~2018	Variant
NCT6798D	~2019	Also -R sub-variant (ASUS boards)
NCT6799D	~2022	Latest — also -R and -S sub-variants, Linux 6.5+

Each new chip adds register offsets, changes sensor counts, or modifies the fan control interface slightly. The kernel driver must handle every variant. One driver file. Dozens of chip revisions. Each with slightly different register maps.

The driver author must reverse-engineer these register maps from datasheets that Nuvoton does not always publish publicly. Some information comes from the chip datasheets. Some comes from studying BIOS behavior. Some comes from trial and error on real hardware.

This is the unglamorous side of driver development. No one writes blog posts about adding NCT6798D support to the nct6775 hardware monitoring driver. No one posts on Hacker News about a new voltage monitoring input. The work is invisible, like the chip it supports.

The TPM Side:

Nuvoton also makes TPM chips — Trusted Platform Modules — the security chips that Windows 11 requires and that store your disk encryption keys.

The Nuvoton NPCT75x TPM has had its own adventures:

• A firmware vulnerability that allowed information disclosure — the security chip leaking information
• An out-of-bounds write vulnerability in the TPM 2.0 module that could cause denial of service
• An ECDSA vulnerability affecting Nuvoton TPM 2.0 chips in Lenovo systems

The chip that is supposed to be the root of trust for your system has had vulnerabilities in its firmware. The chip that guards your secrets has leaked. This is not unique to Nuvoton — TPM vulnerabilities have been found across vendors — but it is ironic.

The Lesson:

The Super I/O chip has been on every PC motherboard for nearly forty years. It is the oldest continuous component class in the PC architecture. CPUs have changed from 286 to x86-64 to ARM. RAM has gone from SIMM to DIMM to DDR5. Storage has gone from IDE to SATA to NVMe. The Super I/O chip is still there, still talking over LPC, still reading fan speeds at 33 MHz.

Nuvoton inherited this legacy from Winbond and maintains it with quiet competence. The chips work. The datasheets exist (mostly). The kernel driver is maintained. Nobody thanks them because nobody thinks about them.

This is the driver that will never trend on social media. The nct6775 module loads silently, reads your fans, monitors your voltages, and if everything is working correctly, you will never know it is there. You will only notice it when something breaks — when CPUTIN reports 112°C, when the ACPI resource conflict blocks the driver, when lm_sensors says “No sensors found.”

The most important driver on your system is not the WiFi driver or the GPU driver. It is the driver that tells you whether your CPU is overheating before the silicon melts. And that driver talks to a chip made by a Winbond spinoff in Hsinchu, over a bus designed in 1998, using I/O ports that your BIOS is trying to steal from you.

In the Republic of Derails, our hardware monitoring is handled by a dedicated officer who places his hand on each server every morning. Analog sensing. No driver conflicts. No ACPI resource issues. The officer has been reporting “temperature nominal” for eleven years. We have not verified his methodology.

— Kim Jong Rails, Supreme Leader of the Republic of Derails