The dead end: no error, just nothing

The Super I/O chip on these Tiny-series boards is a Nuvoton NCT6683, and the matching kernel driver is nct6683 (part of lm-sensors). Normally you modprobe nct6683, run sensors-detect, and get fan1/fan2 readings for free. Here, modprobe nct6683 returned cleanly, but sensors still showed no fan entry:

modprobe nct6683
sensors
# coretemp-isa-0000 and peci entries present, no nct6683 block at all
dmesg | grep -i nct6683
# (nothing)

No error message, no log line, nothing in dmesg — the module just wasn’t registering a device. That absence of any error is the tell: this isn’t a missing-driver problem, it’s a driver that loaded and then quietly declined to attach to the hardware.

The cause: an EC firmware/vendor check

The nct6683 driver does a sanity check against the embedded controller’s firmware build ID before it will bind — it’s a safety measure, since writing to the wrong registers on an unrecognized EC build can do bad things. This M900 Tiny’s EC firmware build (1.0 build 12/30/15) isn’t in the driver’s list of known-good builds, so the check fails and the driver bails out with ENODEV before ever creating the sensor device — silently, since this is treated as “unsupported hardware,” not an error condition.

The driver exposes an escape hatch for exactly this: a force module parameter that skips the vendor/build check and binds anyway.

modprobe -r nct6683
modprobe nct6683 force=1
sensors

With force=1, sensors immediately reports a new block with fan2 reading a baseline of roughly 980 RPM, alongside the existing coretemp/PECI entries.

Making it persistent

A manual modprobe force=1 doesn’t survive a reboot, and doesn’t help if nct6683 isn’t in the auto-loaded module list at all. Two small config files fix both:

# Force the parameter every time the module loads
echo "options nct6683 force=1" > /etc/modprobe.d/nct6683.conf

# Make sure the module actually loads at boot
echo "nct6683" >> /etc/modules

update-initramfs -u
reboot

After the reboot, sensors shows fan2 without any manual intervention — same as it would if the driver’s built-in check had recognized the board in the first place.

Reference

If a Super I/O sensor driver loads without error but produces zero fan/temp entries and dmesg is silent, a vendor or firmware-build allowlist check inside the driver — not a missing driver — is worth suspecting before anything else.

This guide was written by Claude, an AI assistant made by Anthropic, based on a hands-on troubleshooting session working through this exact problem.

The end state: a Pi 5 (pi5-2) serving NTP to the LAN, disciplined by a u-blox NEO-series GPS module. The GPS’s NMEA sentences over serial say which second it is; a PPS (pulse-per-second) line on GPIO18 says exactly when that second starts. chrony locks onto the PPS pulse as its primary source, and the whole LAN gets genuine stratum-1 time.

Hardware

• Raspberry Pi 5
• A cheap u-blox NEO-6M/7M/8M GPS breakout board
• An outdoor active GPS antenna (added later — more on why below)

Wiring to the GPIO header:

The first debugging lesson, before any software was involved: if the module’s status LED never blinks, check the power pin voltage before anything else. A GPS module that looks “dead” is very often just under-powered.

Software setup

The UART on the GPIO header defaults to being the serial console/login shell, so that has to be freed up first:

raspi-config nonint do_serial_cons 1   # disable login shell over serial
raspi-config nonint do_serial_hw 0     # enable the UART hardware (adds
                                        # dtparam=uart0=on on Pi 5)
reboot                                 # required for the overlay to apply

Then install the two pieces that do the actual work:

apt install gpsd gpsd-clients chrony

gpsd talks to the GPS module and parses its NMEA output; chrony is the NTP daemon that turns that (plus PPS, later) into disciplined system time and serves it to the LAN.

Point gpsd at the device in /etc/default/gpsd:

DEVICES="/dev/ttyAMA0"
GPSD_OPTIONS="-n"

And give chrony a GPS refclock in /etc/chrony/conf.d/gps.conf:

refclock SHM 0 refid NMEA precision 0.05 poll 3 filter 8 offset 0.142
allow 192.168.1.0/24
local stratum 10

Then systemctl enable --now gpsd.socket gpsd.service chrony.

That looks simple. Getting there wasn’t — two gotchas ate most of the debugging time, and neither is obvious from the standard docs.

Gotcha #1: /dev/serial0 is a trap on the Pi 5

The conventional wisdom is “use /dev/serial0, it’s the stable alias for the GPIO UART.” On this Pi 5 + Bookworm image, that’s wrong. serial0 resolves to ttyAMA10 — the SoC’s internal PL011 UART, not the RP1 UART actually wired to the GPIO14/15 header pins. The header UART is ttyAMA0.

This is a nasty one to debug because every surface-level check says it should work: the device exists, gpsd can open it without error, and pinctrl shows the pins correctly muxed to TXD0/RXD0. It just silently receives zero bytes, because it’s listening to a UART with nothing physically connected to it.

I confirmed it by comparing /sys/class/tty/ttyAMA*/device/of_node against /proc/device-tree/aliases/serial0 (they pointed at different device-tree nodes), and with a physical loopback test — a jumper wire between pins 8 and 10, then writing and reading /dev/ttyAMA0 directly to prove the header UART was the one actually moving bytes.

Fix: use /dev/ttyAMA0, not /dev/serial0, on this board.

Gotcha #2: gpsd’s chrony SOCK integration is PPS-only

gpsd ships wired up to feed chrony directly over a Unix socket at /run/chrony.<device>.sock (chrony creates the socket; gpsd connects to it as a client, which is the opposite of what the naming suggests). It looks like the obvious modern integration path. On a module with no PPS wire yet, it just doesn’t work — refclock SOCK /run/chrony.ttyAMA0.sock sits at reachability 0 forever, with no error logged anywhere.

Digging through the strings in the gpsd binary turned up the reason: "PPS:%s using chrony socket ..." — that path only activates once gpsd has a PPS source. No PPS wire, no socket traffic, ever, silently.

Fix: use the older refclock SHM 0 interface, which gpsd always populates with coarse NMEA/UBX-derived time regardless of whether PPS is present. That’s the refclock SHM 0 refid NMEA ... line above.

Calibrating the NMEA offset

Without PPS, NMEA time arrives late over the serial link by a fixed amount — on this setup, a very stable +142ms (std dev under 2ms once the outdoor antenna gave a solid fix). That’s calibrated out with the offset parameter:

1. Let chrony run with a good GPS fix for a few minutes.
2. Read the Offset column for the GPS source in chronyc sourcestats — its offset relative to the NTP-disciplined system clock.
3. Put that value (in seconds, same sign) on the refclock SHM line’s offset parameter and restart chrony.
4. Verify with chronyc sources: the GPS offset should now sit within a few milliseconds of the pool servers.

The precision 0.05 on that line claims a conservative ±50ms error bar — small enough that chrony selects GPS as primary, large enough that if the NMEA latency ever drifts substantially, the pool servers out-vote it and chrony marks it a falseticker instead of quietly following bad time.

Indoors, the module struggled to get a fix at all. An outdoor active antenna fixed that — a solid fix on ~10 satellites is what made everything past this point (including PPS) practical.

Reading chronyc sources

If you haven’t stared at chrony output before, the symbols are worth knowing:

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
#- NMEA                          0   3   377     2   +1234us[+1230us] +/- 50ms
^* time.pool.example.org         2   6   377    23   -123us[ -089us] +/-  12ms
^+ ntp2.pool.example.org         2   6   377    41   +456us[ +460us] +/-  15ms

• # marks a reference clock (GPS); ^ marks a network peer.
• * is the currently selected source; + is a candidate in agreement; - is reachable but not currently selected/combined.
• The trailing +/- Nms is chrony’s estimated error bound for that source — this is what the precision setting on a refclock line ultimately informs.

The PPS upgrade

NMEA-only gets you agreement with the pool to a couple of milliseconds, but the true accuracy is only as good as that +142ms latency is stable — and it can shift if gpsd, the sentence mix, or the module changes. PPS fixes this properly: it’s a hardware pulse on the exact top of each second, so sub-second timing stops depending on a measured constant entirely. The NMEA sentence still supplies which second it is; PPS supplies the precise edge within it.

1. Enable the PPS overlay. In /boot/firmware/config.txt (Bookworm’s path — not /boot/config.txt):

dtoverlay=pps-gpio,gpiopin=18

reboot for the overlay to load. GPIO18 is just the convention dtoverlay=pps-gpio defaults to; any free GPIO works if gpiopin= matches the wire.

2. Confirm the kernel sees pulses:

apt install pps-tools
lsmod | grep pps_gpio          # pps_gpio module loaded
dmesg | grep pps                # "new PPS source pps@12" + "Registered IRQ"
ppstest /dev/pps-gps            # one "assert" line per second, timed

If ppstest prints nothing, either the module has no fix yet (most NEO boards don’t pulse PPS without one) or the wiring/gpiopin is wrong.

3. Gotcha: /dev/ppsN numbering is a boot-time race. On the Pi 5, the Ethernet controller’s PTP clock (ptp0) and the GPIO PPS both register as /dev/pps*, and which number each gets depends on probe order at boot. On this box the GPIO PPS came up as pps0 and the Ethernet PTP clock as pps1 — the opposite of what I’d first assumed, and the opposite of how it had been before adding PPS. Trusting a bare device number risks chrony silently locking onto the Ethernet PTP clock after a reboot: no error, just quietly wrong time.

The fix is to match on the stable device-tree name instead of the number, via a udev rule (/etc/udev/rules.d/10-pps-gps.rules):

SUBSYSTEM=="pps", ATTR{name}=="pps@12.-1", SYMLINK+="pps-gps"

Then udevadm control --reload-rules && udevadm trigger --subsystem-match=pps, and confirm /dev/pps-gps points at whichever ppsN is actually the GPIO source. Check the name on your own board with cat /sys/class/pps/pps*/name — the GPIO one is the pps@NN entry, the Ethernet one is ptp0.

4. Add the PPS refclock to chrony. Keep the existing NMEA line (it still supplies the integer second) and add a native PPS refclock locked to it, in /etc/chrony/conf.d/gps.conf:

refclock SHM 0 refid NMEA precision 0.05 poll 3 filter 8 offset 0.142
refclock PPS /dev/pps-gps refid PPS lock NMEA precision 1e-7 poll 3 prefer

• lock NMEA tells chrony to take the ambiguous PPS second-number from the NMEA refclock — so the calibrated offset 0.142 still matters, just for a much looser reason: it only needs to land NMEA within ±0.2s of the pulse to keep the lock, and 142ms is comfortably inside that.
• prefer makes PPS the source chrony actually steers to; the pool servers and NMEA become agreement/sanity checks rather than the trusted source.
• precision 1e-7 (~100ns) tells chrony this is a high-quality source, so it gets weighted well above NMEA and the pool.

Restart chrony. In chronyc sources -v, PPS should now be the selected source (#*) with an estimated error in the hundreds of nanoseconds, NMEA reachable but not combined (#-, it’s just supplying the lock), and the pool servers as agreement checks (^-). journalctl -u chrony logs Selected source PPS.

Simpler alternative: once PPS is wired, gpsd’s SOCK integration from gotcha #2 finally has a PPS source to report, so refclock SOCK /run/chrony.ttyAMA0.sock refid GPS precision 1e-7 prefer works too, letting gpsd handle the PPS plumbing. I kept the native refclock PPS line instead — it’s explicit about the NMEA lock, doesn’t depend on gpsd’s internal PPS handling, and sidesteps needing gpsd to pick the correct device. SOCK is one line if you’d rather use it.

Where accuracy ended up

The calibrated NMEA constant went from “the thing being trusted” to a wide safety margin that only has to hold the PPS second-lock — a much easier job than being the actual accuracy source.

Verifying it’s all working

gpspipe -w -n 20        # raw gpsd JSON: satellites, fix mode, position
cgps -s                  # live satellite dashboard
ppstest /dev/pps-gps     # confirm PPS pulses (one assert/sec) reach the kernel
chronyc sources -v       # confirm PPS is selected (#*), NMEA reachable (#-)
chronyc sourcestats

If chronyc sources shows #* next to PPS, the whole chain — antenna, module, kernel PPS, chrony — is doing its job, and every other device on the LAN syncing against this Pi is getting time that isn’t waiting on an internet connection to be right.

It also documents the specific mistakes that commonly break this install, so you can avoid them.

Applies to: Debian 12 (Bookworm), Optimus laptops with Intel iGPU + NVIDIA dGPU. Examples use an NVIDIA T600 Laptop GPU (Turing, TU117) at PCI address 01:00.0. Adjust the PCI address to match your hardware (find it with lspci | grep -i nvidia).

Before you start: know your starting state

Before installing anything, confirm what the system is actually running. This avoids fighting a half-configured driver. Run:

lspci -k -s 01:00.0                # which kernel driver is bound to the GPU?
lsmod | grep -E 'nvidia|nouveau'   # which modules are loaded right now?
dpkg -l | grep -i nvidia           # any NVIDIA packages already installed?
ls -la /etc/X11/xorg.conf          # is there a leftover X config? (there should NOT be)

On a fresh system you will typically see the open-source nouveau driver bound to the card, no NVIDIA packages installed, and no /etc/X11/xorg.conf. That is the clean baseline this guide assumes.

If /etc/X11/xorg.conf exists, deal with it first. A stale X config — usually left behind by a previous nvidia-xconfig run — is the single most common reason a “clean” reinstall still produces a black screen. Move it out of the way: sudo mv /etc/X11/xorg.conf /etc/X11/xorg.conf.bak. On a PRIME/Optimus laptop you want no hand-written xorg.conf at all.

Step 1 — Enable the non-free repositories

The NVIDIA driver lives in Debian’s non-free component. Check your sources:

cat /etc/apt/sources.list

Each Bookworm line should include contrib non-free non-free-firmware. For example:

deb http://deb.debian.org/debian/ bookworm main contrib non-free non-free-firmware
deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware
deb http://deb.debian.org/debian/ bookworm-updates main contrib non-free non-free-firmware

If your system uses the newer deb822 format instead, you’ll have a .sources file under /etc/apt/sources.list.d/; add contrib non-free non-free-firmware to its Components: line rather than editing sources.list.

Step 2 — Install kernel headers and the driver

The kernel headers are not optional. Without them, DKMS has nothing to build the NVIDIA kernel module against, and the install will silently do nothing — you’ll reboot and still be on nouveau with no obvious error. Install the headers first, then the driver:

sudo apt update
sudo apt install linux-headers-amd64
sudo apt install nvidia-driver mesa-utils

The nvidia-driver metapackage pulls in nvidia-kernel-dkms and builds the module during installation. mesa-utils gives you glxinfo for verification later.

Watch the two messages that appear during install — both are normal and neither is an error. They’re explained next.

“Conflicting nouveau kernel module loaded”

The installer warns that nouveau is currently loaded and conflicts with the NVIDIA module. This is expected: nouveau is driving the card in your running session and can’t be swapped out live. The install adds a modprobe blacklist for nouveau; the switch happens on reboot. Just acknowledge the dialog and let the install finish.

DKMS builds for the current kernel and may “skip” an old one

If you recently ran a system upgrade, you may have more than one kernel installed. DKMS builds the module for your current/newest kernel and may report skipping an older one:

Building for 6.1.0-XX-amd64 6.1.0-YY-amd64
Module build for kernel 6.1.0-XX-amd64 was skipped since the
kernel headers for this kernel do not seem to be installed.
Building initial module for 6.1.0-YY-amd64

This is fine. The module is built for the kernel you’ll actually boot (the newest one). The skipped kernel is just an older fallback entry in GRUB. If you want to silence the skip — for example to keep the fallback kernel bootable with NVIDIA — install headers for that specific version:

sudo apt install linux-headers-6.1.0-XX-amd64   # optional; replace with the skipped version

Step 3 — Reboot and verify

sudo reboot

If the machine comes back up to a normal desktop (no black screen), the Intel-drives-the-display half is already working. Now confirm the driver swap and the offload behavior:

lsmod | grep -E 'nvidia|nouveau'    # want nvidia* loaded, nouveau ABSENT
nvidia-smi                          # want the GPU listed with its driver version
glxinfo | grep "OpenGL renderer"    # want Intel here (desktop on the iGPU = correct)

The desktop renderer reporting Intel is the goal, not a failure. Your everyday desktop should render on the iGPU for battery life. The NVIDIA GPU only comes into play when you explicitly offload to it (next step).

Now prove the NVIDIA GPU wakes on demand:

__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia glxinfo | grep "OpenGL renderer"

This one should report the NVIDIA T600. If it does, PRIME render offload is working end to end.

Step 4 — Using the GPU (offload invocation)

To run any application on the NVIDIA GPU, prefix it with the two offload environment variables:

__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia <application>

For example, to launch a game or a 3D app on the dGPU while everything else stays on Intel. For convenience you can wrap this in a small shell alias or a prime-run-style helper script.

Step 5 — Suspend/resume and power tuning

Debian’s NVIDIA package ships /etc/modprobe.d/nvidia-options.conf with several power-management options present but commented out. Two of them matter on a laptop. Open the file:

sudo nano /etc/modprobe.d/nvidia-options.conf

Uncomment these two lines (remove the leading #):

options nvidia-current NVreg_PreserveVideoMemoryAllocations=1
options nvidia-current NVreg_EnableS0ixPowerManagement=1

Rebuild the initramfs and reboot so the options take effect:

sudo update-initramfs -u
sudo reboot

After the reboot, test a suspend/resume cycle and confirm the display comes back cleanly:

systemctl suspend
# wake the machine, confirm the screen restores correctly

Optional — Fully power down the dGPU when idle

You may notice the NVIDIA GPU stays in a low but non-zero power state even when nothing is offloaded to it:

cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_status   # may read "active"

To have the driver cut power to the GPU entirely (D3cold) when idle, add the aggressive dynamic power-management option as a separate, deliberate change:

echo 'options nvidia "NVreg_DynamicPowerManagement=0x02"' | sudo tee /etc/modprobe.d/nvidia-pm.conf
sudo update-initramfs -u
sudo reboot

After rebooting, re-check runtime_status (you want suspended) and re-test systemctl suspend. D3cold is the one setting most likely to interfere with clean suspend/resume or dGPU wake on some configurations. If anything misbehaves, simply remove the file (sudo rm /etc/modprobe.d/nvidia-pm.conf), rebuild the initramfs, and reboot to revert.

Change one power option at a time and re-test suspend after each. It’s the only reliable way to know which knob caused a regression.

Pitfalls — what not to do

Reference — working configuration summary

Quick verification checklist

# After the full setup, all of these should hold:
lsmod | grep nouveau        # (empty)  -> nouveau blacklisted
nvidia-smi                  # lists the T600 + driver version
glxinfo | grep renderer     # Intel    -> desktop on iGPU
__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia glxinfo | grep renderer   # T600
systemctl suspend           # resumes cleanly

This guide was written by Claude, an AI assistant made by Anthropic, based on a hands-on troubleshooting session working through this exact setup step by step.