From a resume stall to a driver workflow

Date: 2026-10-04
Scope: Review of the repository’s September 2026 development burst.
Starting point: A small Go command scaffold and an investigation into a long Linux suspend-to-idle resume delay on a ThinkPad T14 Gen 2 AMD.
Outcome: A DKMS-based AMD PMC driver variant, a lifecycle CLI, diagnostic output, tests, and operating notes.

Executive summary

This repository tackles a laptop problem: waking from suspend-to-idle could pause for about ten seconds. The investigation traced the delay to an AMD Platform Management Controller (PMC) quirk missing from the kernel’s DMI table for one machine variant. The project added the quirk to an out-of-tree driver build and wrapped its maintenance in kpatch, a Go command-line tool.

The work grew into an operational workflow. kpatch fetches driver sources, builds and installs through DKMS, manages Secure Boot signing, switches between patched and stock drivers, inspects status, and analyzes resume timing. A debug build reports the selected quirk through sysfs. The repository records 42 commits on September 21, eleven tickets, and 21 Go test functions across six files. A quota-enforced test run during this review passed go vet and go test ./....

The investigation and the decision

The notes distinguish the kernel’s resume path from userspace and compare possible fixes. The chosen route reused upstream amd_pmc with an added DMI quirk, packaged as a DKMS module. Research explains why userspace sleep hooks run too late and why disabling PCIe power management would sacrifice the low-power S0i3 state.

Tickets show the approach narrowing: investigate (002), compare remedies (005), acquire source and prove an unmodified canary build (006), then patch and validate (007). The work log records resume-device time of 0.47 seconds across three cycles on the target machine. That is local validation, not a promise for every system.

A bug at the boundary between names

One failure mode sat between DKMS and Linux module loading. The package was amd-pmc-kpatch, but the kernel module was amd_pmc. DKMS needs the package name; modprobe needs the kernel name. Conflating them made switching unreliable. Packaging also had to match the upstream module name for depmod to prefer the replacement, and remove an incorrect BUILT_MODULE_LOCATION so DKMS could find the built object.

Session notes add a safety rule: confirm a stock module is available before unloading the patched driver. Also, modinfo -n reports the preferred installed file, not necessarily the loaded one, so status reports runtime state explicitly. These details cross packaging, module resolution, Secure Boot, and live hardware.

The optional debug variant adds a read-only sysfs attribute for the selected quirk; compile-time separation keeps it out of the clean production variant. The CLI verifies the requested variant before loading it, letting operators check what the running driver selected.

What the agent workflow contributed

Tickets served as plan and evidence trail: close-out notes connect commits to implementation and verification, while the source canary reduced uncertainty before patching. The session record describes Harnez lean-sprint handoffs to developer agents: read-only plan, approved implementation, and host review. Early launcher/session confusion led to a practical lesson: retain the live session identifier and distinguish launcher cleanup from worker teardown.

This history cannot prove one developer could not build the same result. It does show why agents helped: one packed day covered hardware research, C driver integration, DKMS, a tested Go CLI, Secure Boot, manuals, runbooks, and live validation. The evidence is traceability: eleven tickets, forty-two commits, and checks at several boundaries. Small steps kept the broad task reviewable.

Honest post-mortem

The project notes describe confused handoffs and fixes for module naming and DKMS discovery. The canary, explicit verification, and status reporting addressed separate risks. This review found no failing Go tests, but no root README or public website entry point; ticket 012 tracks that discovery gap.

Quality and invariants

Facts

Key learning

For agentic systems work, make external boundaries explicit: package name versus module name, installed file versus loaded module, requested build variant versus active runtime variant. Pair each boundary with a cheap canary or an observable status check, and link the evidence back to a ticket. That practice is visible here in the canary build, variant verification, and runtime sysfs probe.

File and diff summary

This review adds the study and ticket 012, with no source-code changes. make test-q1 passed.