diff options
| -rw-r--r-- | STATE-CURRENT.md | 52 |
1 files changed, 28 insertions, 24 deletions
diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md index 5ec4667..4d9dc83 100644 --- a/STATE-CURRENT.md +++ b/STATE-CURRENT.md @@ -1,6 +1,6 @@ # Open-IOV Current State -> **Snapshot: 2026-10-01 14:07.** This is a dated public status page, not live +> **Snapshot: 2026-10-01 14:20.** This is a dated public status page, not live > state; it is refreshed on every progress check. Live working notes are > maintained outside this repository; the public known-knowns/unknowns document > is authoritative here: @@ -36,14 +36,14 @@ meant to execute on the physical GPU. resource-manager's own error journal and root-caused the failure: the boot queue was missing the two pre-boot initialization messages the matching driver queues before the kernel kick (a system-information message and a - packed registry table). That handshake is now implemented, and a real - registry profile with display disabled is sent; the error journal collapsed - from 29 unique/851 total records to 3 unique/4 total (the dominant assert - family is gone and so is the late display event), and the GPU timer is now - programmed before the kick. Initialization still ends in the same - un-journaled resource-manager error, now being chased through the recorded - assert call-sites; each of cycles 4-7 released the device cleanly with no - reboot. | + packed registry table). That handshake is now implemented and **verified + live**: the registry transport and packing are proven (a display-disable key + took effect in the server's journal), and the GPU timer is programmed before + the kick. The fatal error is now root-caused to a **device-id/board + validation** in the server's static-config collection, and the corresponding + device-id override key is implemented in the registry profile; the next + supervised cycle is in flight. Each of cycles 4-7 released the device + cleanly with no reboot. | | Graphics (3D), video | ❌ | | Faults, multi-version, Windows, migration, multi-tenancy, performance | ❌ | @@ -87,21 +87,25 @@ chain succeeds. cycle now **releases cleanly back to the distribution driver without a reboot**: the server's own shutdown sets the remaining secure-scratch handoff bit, so all four handoff bits are set and a single `rmmod` clears - the protected region, rebinds the distribution driver and releases the -power-domain locks. The error-journal capture has since run on four -supervised cycles (each one attempt, each released cleanly with no reboot): -the journal was read, and the failure was root-caused to two pre-boot -initialization messages the matching driver queues before the kernel kick (a -system-information message and a packed registry table) - our boot queue was -empty. That handshake is now implemented and a real registry profile with -display disabled is sent; the journal collapsed from 29 unique/851 total -records to 3 unique/4 total, the dominant assert family and the late display -event are gone, and the GPU timer is programmed before the kick. -Initialization still ends in the same un-journaled resource-manager error, -now being chased through the recorded assert call-sites; the next leads are -those call-sites, the remaining zeroed system-information fields, the -video-memory workspace layout branch, and a build-matched log database for -the fatal path. + the protected region, rebinds the distribution driver and releases the + power-domain locks. The error-journal capture has since run on four + supervised cycles (each one attempt, each released cleanly with no reboot): + the journal was read, and the failure was root-caused to two pre-boot + initialization messages the matching driver queues before the kernel kick (a + system-information message and a packed registry table) - our boot queue was + empty. That handshake is now implemented and **verified live**: the boot + consumes a true system-information message and a real registry profile, the + registry transport and packing are proven (a display-disable key took effect + in the server's journal), the journal collapsed from 29 unique/851 total + records to 3 unique/4, and the GPU timer is programmed before the kick (the + live timer line was observed, and the generation-correct zero timer offset + was confirmed). The fatal error is now root-caused to a **device-id/board + validation** inside the server's static-config collection, and the + corresponding device-id override key is implemented in the registry + profile. The next supervised cycle is in flight. If it still fails, the + fallback leads are the device-id mirror read and the board/panel-ID tables, + the remaining zeroed system-information fields, the video-memory workspace + layout branch, and a build-matched log database for the fatal path. - **The full CUDA driver-API smoke test passes with correct data**: the client completes `cuCtxCreate -> cuMemAlloc -> cuMemcpyHtoD -> cuMemcpyDtoH -> cuMemFree -> cuCtxDestroy` and prints `ALL OK`, with the 64-byte payload |