Repository navigation
Conversation
…r run Three things a first boot on a laptop needs and the report did not say: - Why a sleep was short. The laptop section now gives the interrupt that ended the last sleep, where the kernel keeps it (/sys/power/ pm_wakeup_irq, under PM_SLEEP_DEBUG), and the five wakeup sources that fired most. Where there is an IVRS table it also says whether the firmware gives Pluton's device (MSFT0201) and has pre-boot DMA protection on (IVinfo bit 1). AMD's family 1Ah processors need both to sleep with the IOMMU on, which amd-debug-tools checks, and a firmware setting can take either away. - Which TPM came up. The firmware line names the TPM's driver and the hardware random number generator the kernel reads, as some firmware TPMs register none. - How the clock is set. A cpufreq line gives the driver, the governor, the energy hint and amd-pstate's mode: power.sh's hints act only in a driver's active mode, and a firmware without CPPC leaves amd-pstate out. The fixture test checks each line, an empty wakeup interrupt, no AMD line without an IVRS table, and both IVRS answers.
…bug-tools asks for From 93's read: - A wakeup source's wakeup_count grows only while events_check_enabled is set (drivers/base/power/wakeup.c), which only a write to /sys/power/wakeup_count turns on, and kryptikd sleeps by writing "mem" to /sys/power/state alone. So every count stayed 0 and the lines never printed. The five that fired most now come by event_count, as the comment said they did, and the fixture's wakeup_count is the 0 a Kryptik machine shows. - The IVRS line's comment said more than amd-debug-tools does: its rule is for family 1Ah models 0x20-0x2e, 0x60-0x6e and 0x70-0x7e, it takes MSFT0201 named in the IVRS in place of pre-boot DMA protection, and it calls MSFT0201 an ACPI device, nothing more. The comment now says that, and the line gains "msft0201 in ivrs yes|no", so protection off is not read as a laptop that cannot sleep.
DevomB
marked this pull request as ready for review
October 23, 2026 11:59
laptop() had grown past the cognitive-complexity line with the wakeup sources and the AMD IOMMU line (Tectonix: complex functions 69 to 70). sleeping() and cameras() take those parts as they were, and laptop() calls them where they stood, so the report reads the same.
DevomB
added a commit
that referenced
this pull request
Oct 23, 2026
…t into their own functions, the same output
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Based on hardware-list (2fafcbd), for the integrator's second batch. The report is the main evidence from the first physical boot, and three things it needs were missing.
What the report gains
woken by irq: Nfrom/sys/power/pm_wakeup_irq. It exists only underPM_SLEEP_DEBUG, which comes withPM_DEBUG=yin the same batch; elsewhere it prints-.wakeup_count.amd iommu: msft0201 present|absent, pre-boot dma protection on|off. AMD's family 1Ah processors need both for s2idle with the IOMMU on: Pluton's ACPI device, and IVinfo bit 1 at byte 36. That's amd-debug-tools' iommu check, and Kryptik always runs the IOMMU strict.tpm: version 2, driver tpm_tis; hwrng: tpm-rng-0replacestpm: version 2. It shows which driver the TPM came up under and whether anything feeds the kernel's hwrng.cpufreq: DRIVER, governor G, epp E, amd-pstate MODE. power.sh's energy hints act only in a driver's active mode, and amd-pstate falls back when the firmware lacks CPPC.What is unchanged:
tools/check-hardware.shreads none of these lines, so older reports still check. Nothing new is read beyond sysfs and one ACPI table, which root alone reads.Checked:
tools/tests/hwreport.shcovers each new line on the fixture: