ad45873a1b
Priority aging in xenia-cpu/scheduler.rs:pick_runnable
(effective_priority = base + age_bonus(now_round - last_run_round),
capped at +31, AGING_ROUNDS_PER_BONUS=1). Strict-priority was parking
priority=0 threads behind CPU-bound priority=15 audio mixer
(sub_824D1328 guest spinwait at PC=0x824d1404 on CPU5). Aging
eventually picks the starved thread, breaking the producer-consumer
cycle that caused 5-tid wedge at PC=0x824ac578 since AUDIT-049 (10 May).
Cascade observed: tid=13 clean exit; events 121K -> 13M (107x); last
host_ns 767ms -> 51,011ms (66x); 8 new threads spawn; VdSwap 1 -> 2.
Complete two-day iterate sequence (2026-05-27 -> 2026-05-28):
- 2.F: VdSwap drain timeout 900ms -> 1ms (xenia-gpu/handle.rs); 876x
perf win on VdSwap kernel callback
- 2.H: vA0000000 physical heap bucket added (state.rs, exports.rs);
ctx_ptrs now in 0xA0000000-0xBFFFFFFF range matching canary
- 2.L: Phase-A diff harness categorized [return_value mismatch],
[status mismatch], [args_resolved.path mismatch] tags
(tools/diff-events/diff_events.py); closes reading-error #41
(silent test-harness state leak invalidating trace diffs)
- 2.M: always-on exit-thread-state.json sibling to Phase-A JSONL
(event_log.rs + xenia-app/main.rs); closes reading-error #42
(Phase-A blind to blocked-forever waits)
- 2.Q: signal.match kernel instrumentation in NtSetEvent /
NtReleaseSemaphore / KeSetEvent / KeReleaseSemaphore
(exports.rs); emits target_handle + waiter_count + waiter_tids
- 2.T: wake.requested kernel instrumentation in wake_eligible_waiters
(exports.rs); emits target_tid + transition + new_state
- 2.V: scheduler priority aging (xenia-cpu/scheduler.rs) [keystone]
Plus accumulated WIP from earlier May (contention_manifest,
phase_b_snapshot, xam/xaudio enhancements, analysis db, xex loader,
xenia-app main loop, etc.). Audit-runs/ artifacts remain untracked
per project convention.
Tests: 300 xenia-cpu / 227 xenia-kernel / 5 xenia-app / 19 xenia-path
/ 30+ smaller suites -- all PASS, 0 regressions. Determinism preserved
(2x cold runs bit-identical at 13,003,881 events post-2.V).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
48 lines
2.6 KiB
Markdown
48 lines
2.6 KiB
Markdown
---
|
||
address: 0x82457EF0
|
||
classification: thread_proc
|
||
confidence: high
|
||
last_audit: 060
|
||
aliases:
|
||
- "tid=6 thread_proc"
|
||
---
|
||
|
||
# sub_82457EF0 — tid=6 thread_proc (worker entry)
|
||
|
||
## Synopsis
|
||
|
||
Thread procedure for tid=6 in ours. 0 static callers — and that is *correct* for a `thread_proc`: it is installed as an entry-point via `ExCreateThread` somewhere in boot, not invoked via `bl`. AUDIT-059's "only-caller of [sub_82458B90](sub_82458B90.md) has 0 callers — fnptr-array only" inference was wrong; the actual activation is thread creation.
|
||
|
||
## Evidence
|
||
|
||
- AUDIT-060 Probe O ours: fires **1× on tid=6** (HW=2, cycle=0, lr=`0xbcbcbcbc` — thread-entry sentinel).
|
||
- `lr=0xbcbcbcbc` is the Xbox 360 / xenia convention for "this is the very first instruction of a thread proc; no return address". This is a diagnostic that distinguishes thread entry from a normal `bl` fire.
|
||
- Calls [sub_82458B90](sub_82458B90.md) at `+0x24` (1 callee at this offset).
|
||
|
||
## Activation
|
||
|
||
Registered as a thread entry-point via `ExCreateThread` (or similar). The caller of `ExCreateThread` that installs this entry has not yet been traced — that's the *real* activation site, and tracing it would close the loop on tid=6's purpose. Once tid=6 starts, the OS scheduler runs `sub_82457EF0` from PC `0x82457EF0` with LR=`0xbcbcbcbc`.
|
||
|
||
## Static graph
|
||
|
||
- Static callers (`bl`): **0** (correct — see classification).
|
||
- Callees: `bl sub_82458B90` at `+0x24` (PC `0x82457F18`).
|
||
- The "indirect call site" that activates this fn is the `ExCreateThread` invocation, captured at runtime, not in static `xrefs`.
|
||
|
||
## Audit log
|
||
|
||
- **AUDIT-060 (2026-05-12)** — identified as tid=6 thread_proc via `lr=0xbcbcbcbc` thread-entry sentinel + HW=2 + cycle=0 first-fire context. AUDIT-059's static-reachability inference invalidated. [confirmed]
|
||
- **AUDIT-059 (2026-05-11)** — flagged as "only-caller of canary signaler A; 0 callers — fnptr-array only". [STATUS: partially correct (0 callers true; fnptr-array WRONG), corrected by AUDIT-060 — it's a thread_proc.]
|
||
|
||
## Open questions
|
||
|
||
- Where is `ExCreateThread(entry=sub_82457EF0, ...)` called from? Probe the `ExCreateThread` import thunk in both engines with filtered LR/r3 to find the install site.
|
||
- What does the thread body do beyond calling [sub_82458B90](sub_82458B90.md) once? Likely it's a loop that waits on a queue, dequeues work, and signals completion via the bl at `+0x24`. Disassemble the body.
|
||
|
||
## Cross-references
|
||
|
||
- Thread-body callee: [sub_82458B90](sub_82458B90.md).
|
||
- Install site (`ExCreateThread` caller): not yet identified.
|
||
- Audits: 059, 060.
|
||
- Artifacts: `audit-runs/audit-060-fnptr-array-bootstrap/ours-phase1.stdout` (the `lr=0xbcbcbcbc` sentinel evidence).
|