Page MenuHomeFreeBSD
Files F170929005

D59481-EVIDENCE.md
Public
Actions

Authored By
oleglelchuk_gmail.com
Mon, Sep 7, 4:22 PM
Size
11 KB
Referenced Files
None
Subscribers
None

D59481-EVIDENCE.md
View Options

# D59481: historical validation and observation summary
Prepared September 7, 2026 from existing local records. This document separates the author's experience, instrumented observations, API checks, and patch-export verification. Preparing it did not involve a new runtime experiment.
## Author's experience and its limits
I have repeatedly experienced recoverable graphics hangs on my laptop with kernels lacking the PFN backing-preservation changes. With ZFS ARC left at its automatic maximum rather than a manually imposed smaller cap, downloading many large files over the LAN has been associated with a hang in every such non-PFN attempt I recall, using either Sway or Plasma. I have not experienced the same hang on the PFN kernels while performing comparable downloads with the same ARC setting. The hangs have been recoverable by ending the affected desktop session; they have not been kernel panics.
I have not supplied an exact trial count or a controlled success-rate calculation. These observations therefore describe my experience, not a measured universal 100% failure or success probability. I also have not established precisely what the downloads change in VM pressure, reclaim activity, or timing. Here, “uncapped ARC” means automatic ARC sizing, which still has a finite maximum; it does not mean unlimited cache growth.
The historical comparison includes different local kernel and diagnostic revisions and retained unrelated laptop fixes. It is not a matched single-change comparison on otherwise identical sources and settings.
## Historical environment and artifact identity
The historical report identifies FreeBSD 16.0-CURRENT/amd64, an Intel Core Ultra 7 155H laptop, and the i915 graphics driver. This summary does not claim a separately verified PCI device ID or a unique per-process Mesa device binding.
The locally built pfnmap11 kernel and subsequent pfnmap11-opt API validation used FreeBSD source base `48efb6c4eb9febc1c8c50d13a794e9165af71930`, with local changes. The recorded native kernel build was September 6, 2026, 12:55:27 EDT. Its SHA-256 is:
`200c4fc40fdfa136b23a62413a72facb2f2ab255d0245268836797874818550c`
The completed passive preservation recording used the diagnostic-enabled i915 artifact:
`66d611daeec3fe716bb0ee5bd9a6d7874de19fbacb01b2c1c4c982a5b30f0449`
The later opt boot used the same native kernel and this i915 artifact, with expensive diagnostic scans disabled during normal use:
`b559c34dfa9f0287a80d8803b43eb07e5d869dae5822c0bcec510cddee623b19`
The boot audit checked all 35 loaded entries against the opt inventory. Artifact hashes and loader identity are provenance checks, not hashes of relocated running code. Unrelated retained laptop modules were not all rebuilt in that build. The later accounting validation had a 4 GiB ARC cap; it must not be presented as an automatic-ARC graphics stability run.
## What the recorded failure established
The non-PFN kernel in the September 6, 11:35:24 EDT failure recording was based on FreeBSD commit `b54dcb897a5fa66ff1013d0ea403ed8894e34b8a`, with local instrumentation and retained laptop fixes; it was not an unmodified upstream build.
The September 6, 2026, 11:35:24 EDT non-PFN recording associates a still-live small graphics buffer directly with the saved stalled request. Retained CPU copies show nonzero contents still present before the original backing page's retirement. The same logical buffer later acquired replacement zero-filled backing, and its retained CPU copy before a subsequent submission was zero. The retained first and last nonzero copies match. This is a backing-preservation failure, distinct from ordinary zero initialization of a newly created buffer.
Source analysis identifies the mapping path's transfer of pages out of the original shmem owner as consistent with that recorded loss. The recording does not directly measure the GPU's instruction fetch, translation, or cache contents, so exact hardware execution remains an inference.
A later watcher memory sample recorded ARC size 13,336,354,872 bytes and maximum 15,513,432,064 bytes, with 89,169 free pages against a target of 84,056 and no recorded swap-ins or swap-outs. These later readings do not establish instantaneous pressure at retirement, and do not establish ARC itself as the operation that lost the backing contents.
## Preservation observations on pfnmap11
The completed passive recording ran on September 6 from 17:34:11 to 18:28:42 UTC, approximately 54.5 minutes. Its collection and native summaries agree on:
| Observation | Recorded result |
| --- | ---: |
| Validated snapshots / unique native records | 3,272 / 4,182 |
| Tracked lifetimes | 374: 200 large (2 MiB), 174 small (4 KiB) |
| Completed preservation cycles | 74 across 30 distinct objects |
| Cycles by buffer class | 52 large, 22 small |
| Cycles with nonzero retained short samples | 9 |
| Cycles with nonzero page checksum but zero short samples | 19 |
| Zero-compatible cycles | 46 |
| Recorded strict preservation comparison mismatches | 0 |
| Tracked lifetimes reaching closure | 374 |
| Recorded gaps, drops, overwrites, observation races, exhausted IDs | 0 |
A cycle compares recorded identity, generation, ownership, page checksum, and 24 sampled bytes across the observed preservation interval. The large-buffer observer selects page 96; the small-buffer observer selects page 0. Equal checksums and samples are not whole-buffer byte-for-byte equality, continuous observation, or proof of every physical-page identity. A zero-compatible checksum and zero short samples do not prove that every byte was zero. The 74 cycles are not 74 independent desktop trials.
All tracked registrations closed, but this does not prove absence of every internal reference leak or a leak outside observer coverage. Two later checksum changes followed intervening submissions and were outside the preservation intervals; they are not counted as preservation mismatches. Unique automatic Mesa-to-native device correlation remained unresolved. Collector finalization after the desktop session ended completed without a collection error.
## Offline and live API checks
The offline producer, handoff, invalidation, and temporary-hold consumer checks passed using frozen source with mocked VM dependencies and ASan/UBSan. Extracted memory-locking checks separately passed 15 behavioral cases, 10 integration checks, and two negative controls. These do not establish real scheduler, reclaim, or pmap behavior.
The 25 distinct passing live API cases concern memory-locking and accounting policy:
| Coverage group | Cases |
| --- | ---: |
| Ordinary locking: range handling, repeated/partial operations, aliases, fork, limits, future locking, read-only mappings | 10 |
| Basic managed-device mapping exemption with ordinary control | 1 |
| Mixed ranges and future device/ordinary mappings | 2 |
| Extended device mapping/user locking, including protection and cache-mode variants | 5 |
| Kernel-origin own-process query: ordinary success, defined device-buffer failure, intact contents and cleanup | 1 |
| Initialized RACCT accounting and ordinary/device quota enforcement | 6 |
| Total | 25 |
These are finite API conformance checks, not 25 independent reproductions of the backing-loss failure. The first 19 ran on one opt boot; six accounting cases ran on a later opt boot with RACCT initialized and the same kernel/driver identities. An initial accounting controller assertion failed because it confused a conservative reservation with current mapped size. After correcting that expectation, the byte-identical worker passed; no kernel or driver change was needed. The failed and corrected records are retained. Temporary quota rules were removed afterward.
## Published export and outstanding validation
The original D59481 export was based on the newer pristine FreeBSD commit `60c7313074b93adf4ea70ff44b78b3b4fc15c29f`. Actual application to a temporary index initialized from that base, reverse application, and whitespace checks passed. All eleven resulting files matched the checked local functional candidate, including the manual correction. The original upload's SHA-256 was `6125e6d3333eefcf99f9e965ab44446cd1d5e117c10c7817c114e76a20ddec58`. The export excludes diagnostic instrumentation and unrelated laptop changes.
These historical results do not constitute a fresh full kernel/module build or boot of the exact newer-base submission. Any subsequent diff update requires its own export verification. Whole-buffer preservation, exact GPU instruction fetch, every internal reference lifetime, real kernel concurrency under all relevant interleavings, and a matched single-change causal comparison remain unestablished. The records support a candidate correction for the observed managed-shmem ownership failure; they do not certify elimination of all graphics hangs.
## Current revised export verification
The revised 12-file diff is based on pristine FreeBSD main commit `661d1135e4ed12d6017220ea654ae67a6956dc73`, pinned on September 7, 2026. The patch SHA-256 is `653b7e81a50bf101fb0f6ba82a749fe684d168c72db93275a346fe9a92fbe94f`. Its clean application and whitespace checks passed. Actual application to an independent temporary Git index produced tree `6d6e5a573961a4dcbb9b4d9544e9a6ca025eabaf`; actual reverse application returned the identical pristine base tree `0d8501f3cbf916a05a8b8bfa9272ab9bd70f62eb`.
All nine PFN kernel/header postimages are byte-identical to the original checked export. The two manual postimages differ from that export only by restoration of their original document dates. The additional `sys/sys/param.h` hunk raises `__FreeBSD_version` from 1600024 to provisional 1600025. No touched base file changed between the old and newly pinned bases. Both revised manuals pass `mandoc -Tlint` without output. Diagnostic instrumentation remains excluded.
The version number is proposed for review, not officially assigned. Before landing, the accepting committer must confirm or adjust it and add the corresponding Porter's Handbook version entry with the real commit identity and date. The exact revised sources have not received a new full kernel/module build or boot validation.
The separately attached `D59481-EXPORT-VALIDATION.json` records these checks and per-file hashes. Its SHA-256 is `7a0443ffdbe9db7aa5745c689a8f9aaead3053cae852186ed39cbe877ff5c0fd`.
## Provenance of the summarized records
The following filenames identify retained historical inputs. Hashes identify the exact local documents summarized here; the raw archives are not implicitly attached or independently reproduced by publishing this summary. No private machine address, account credential, or hostname is required to assess these findings.
- `failure-FINDINGS.md`: `3d91e27df1ff82eae4a069f9545f3bd94bdeb64b41e91cb53d883861557bcb84`
- `historical-REPORT-DRAFT.md`: `1619619b014953112707c83810938025655365a08adf8a2ce8f98bad17c7f35f`
- `VALIDATION.md`: `7a7e059442c41f030cb6a17bedfd3a021460222551a45cb7139042c1435c5bb9`
- `PROVENANCE.json`: `e604d76490c4eb1409610d3473ca6b9986490ab834543367dc0e3bc8349bf049`
- `preservation-final-summary.json`: `79c8eab9cccc9e7abef486a4390db0b9ce2aca13a24d5d7c6f3e2a2dd6a824b3`
- `preservation-native-summary.json`: `2925d43cf911aedb5c9ba853964396926c1b7c9e820aaf0f721c00f512cb3938`
- `accounting-final-results.json`: `89d5582efff61946cc5d6d16c1b3159f76e702a8ea09a5334d9ddbb067949f83`
- `offline-provenance.json`: `7bbb4e9e288c3c0174cc817331884ae7b18661bb3ff8c3387701b59b7802dffc`
- `boot-audit.json`: `e69b9999a525f5d2760fa20325e6f08c1b29f58752b7782ab6bf315d8afbae69`
- `original-PATCH-VALIDATION.json`: `a25068627428ee7b9174b28f0e3de186f7233f0d69360e5c83e834fe7b1bba9f`

File Metadata

Mime Type
text/plain
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
38524287
Default Alt Text
D59481-EVIDENCE.md (11 KB)

Event Timeline