Skip to content

pmdomain: apple: restore J613 memory bandwidth with a PACC0 demand floor - #1486

Merged
DjDeveloperr merged 5 commits into
aurora-silicon:integration/aurorafrom
satchlj:satchlj/j613-memory-floor-20261110
Nov 11, 2026
Merged

DjDeveloperr merged 5 commits into
aurora-silicon:integration/aurorafrom
satchlj:satchlj/j613-memory-floor-20261110

Conversation

@satchlj

@satchlj satchlj commented Nov 10, 2026 •

Copy link
Copy Markdown
Member

Qualification update on 98e4d336787e70c86d73d09d6d5a8fef86a83f6d: the owner’s later reports now cover default-on/boot veto, repeated loaded runtime toggles, suspend floor release/resume and normal cpufreq-policy removal/reappearance. A 600s-per-mode follow-up records sustained system power, validated bandwidth and functioning thermal limiting. These reports include this exact feature head in a combined J613 kernel; they are not isolated-PR qualification. The earlier statements below that no exact-head sustained measurements exist are superseded by comments6804319345 and6806427775.

Explicit limits remain: physical CPU hotplug is unavailable on the installed spin-table boot path; instrumented PMP device removal, KASAN/lockdep and adequate-supply/near-full steady-state testing were not completed. The new SMC data measures battery-assisted total-system consumption, not adapter input or battery-only power; the on→off trial is not randomized or thermally equilibrated. The whole-script diagnostic grep still exits nonzero on an unchanged baseline wireless-extensions warning, so no entirely green script exit is claimed. No new hardware action is requested by this update.

On J613 (M3 MacBook Air, T8122), the memory controller stays at its low DCS/SOC state under CPU and GPU load, limiting copy bandwidth to about 21 GB/s.

This series adds a demand-driven PACC0 memory-floor governor, on by default for J613 and off on every other board. Enablement comes from the existing native J613 PMP report's compatible match data, with an additional J613 board check, T8122 supplier/firmware UUID validation and native-table admission. No global Kconfig default or DT/binding change is needed. Disable at boot with pmp_report.j613_floor=0, or at runtime by writing 0 to the report device's j613_floor/enable sysfs attribute.

The governor requests DCS4/SOC2 only under demand: any core at least 80% busy, a cluster's summed busy time at least 90% of one CPU, or outstanding GPU work at least 40%. It samples every 30 ms; two demand samples raise the floor, with a 500 ms hold and 100 ms minimum transition interval. It returns to valid floor zero after demand subsides. Disable, fault, suspend, remove and shutdown withdraw the floor. Requests are read once before ownership and never echoed after stores; confirmation uses DVFS-STATE responses.

Three commits provide policy, driver integration and tests, directly on integration/aurora dc8f6f7, which remains current and merges cleanly. No unmerged dependency, diagnostic AGX eligibility vote, display, RTC or CPU0 tuning changes.

Measurements and remaining qualification

Retained November 9–10 owner measurements justify enabling the demand-driven floor on J613:

  • CPU 4T copy: 92.4–93.3 GB/s with the floor versus 20.5–21 GB/s without, reaching the earlier macOS reference range of 82–93 GB/s. No new matched macOS CPU measurement was made on the rebased kernel.
  • GPU copy: about 21 GB/s off. On Linux rebase-2, floor-on GLES host timing reaches 85.6–86.5 GB/s at 256 MiB; Vulkan GPU timestamps give 93.6–95.3 GB/s at 64 MiB. Matched November 10 native Metal comparisons at 16–256 MiB show macOS parity (Vulkan about 1–7% higher); 4 MiB cases still substantially favor macOS. These are validated read+write decimal GB/s measurements; host and GPU times are separate. The invalid GLES GPU timer is excluded.
  • Idle battery power was unchanged within session noise: 2.053 W on versus 2.064 W off (about 2.05 versus 2.06 W), in comparable final 60-second windows. Brightness was not continuously recorded; this is not a controlled efficiency study or fresh rebase-2 power measurement.

Power under sustained load with the floor engaged has not been measured separately. A hardware result on this exact head will follow. This update uses offline checks only. Other boards have not been hardware-tested and cannot acquire a floor owner, even with the parameter enabled.

The Linux GPU runs used 7.3.0-aurora73-rebase-2-ARCH (integration/aurora c880586 plus retained J613 enablement and R3 fixes), with AGX eligibility voting disabled. CPU0's unresolved low IPC remains outside this series.

Validation

  • PMP host runner: 21/21 pass, including default-on/off/disable assertions and three new negative mutations, existing floor mutations, graph/supplier regressions, AGX-vote regressions and the DT fixture.
  • Arm64 Image/modules/DTBs: pass with LLVM 18 / Rust 1.85, retained kit config, debug info/BTF disabled and the floor KUnit module enabled. Unrelated whole-tree warnings remain. Published-file hashes match the build inputs.
  • QEMU Cortex-A76: all six floor KUnit cases pass, including enablement and shared-release deadlines, with no failures/skips; not exhaustive whole-tree KUnit coverage.
  • Each commit passes checkpatch with --ignore FILE_PATH_CHANGES (generic new-file MAINTAINERS reminders excluded); git diff --check passes. Human Signed-off-by and Assisted-by: LLM trailers are retained.
  • Touched-DT dtbs_check: not applicable; no DT/binding files changed. DTBs build successfully.

Provenance

Register behavior was learned by tracing macOS under the hypervisor on the owner's hardware (HV traces 1152/1163), not by reading Apple code. The series contains Linux implementation and synthetic tests, with no copied Apple source, firmware, trace dumps, private paths or hostnames. R3 shared-release deadline handling is included; its independent AGX-vote input remains inactive because that diagnostic client is excluded.

AI attribution follows Documentation/process/coding-assistants.rst: Assisted-by: LLM, with the human DCO sign-off. This default-on revision was implemented with Codex (GPT-6.1 Sol); the original series was prepared with Claude Code.

Recognize any-core 80% or cluster-sum 90% CPU demand and outstanding GPU
work. Debounce raises, hold DCS4/SOC2 through short gaps and rate-limit
transitions. Keep request encoding and admission checks independent of
MMIO for testing.

Carry the R3 aggregate-response release deadline helper: independent
demand restarts the quiet interval, and a future publication timestamp
cannot underflow the deadline.

Signed-off-by: Satya Benson <satya@benson.earth>
Assisted-by: LLM
J613 stays at the lowest memory-controller state under Linux load. macOS
hypervisor traces 1152/1163 and controlled experiments identify PACC0 as
a DCS and SOC floor client. DCS4/SOC2 restores CPU bandwidth from about
21 GB/s to 92-93 GB/s.

Admit only validated J613 native PMP tables, discover PTD offsets by
range ID and read the request once before owning it. Publish through the
update alias and confirm only through DVFS-STATE responses. Drop to
valid level zero on disable, suspend, reboot and removal. Count a new
raise superseding pending release confirmation, as in the R3 fix.

Enable the governor by default through the native J613 report match
data, retaining the J613 board check. Disable it for debugging with
pmp_report.j613_floor=0 or the existing j613_floor/enable sysfs control.
Other machines remain inactive. No diagnostic AGX eligibility vote is
included; the R3 independent-vote deadline input is therefore inactive.

Register behavior was learned by tracing macOS under the hypervisor on
owner hardware, not from Apple source code. Discover the native PMP
directly through its report phandle and validate its firmware UUID; no
external-display branch is required.

Signed-off-by: Satya Benson <satya@benson.earth>
Assisted-by: LLM
Exercise request ownership, CPU cluster demand, hold and rate limiting
with KUnit and production-header host fixtures. Cover the six R3
aggregate release deadline cases, including concurrent future
timestamps. Register negative mutations and update the PMP graph fixture
for floor-owner admission.

Signed-off-by: Satya Benson <satya@benson.earth>
Assisted-by: LLM
@satchlj

satchlj commented Nov 10, 2026 •

Copy link
Copy Markdown
Member Author

GPT-6.1 Sol on @satchlj's behalf

J613/T8122 M3 MacBook Air, firmware 26.6.2/25G83. Tested exact head 49bae2a733a314554e925df882c81f2bfdd021f4 on integration dc8f6f77934b471a13c91e7780e2d91ebc904b3d, no extra source commits/PRs. Same Image/modules/config; on UKI has no floor parameter (live Y), off uses pmp_report.j613_floor=0 (live N). Unique trial release 7.3.0-aurora73-pr1486-49bae2a-ARCH.

J613 measurement Floor on (default) Explicit off
CPU copy 1T, CPU0, GB/s 38.829 18.035
CPU copy 1T, CPU5, GB/s 82.574 19.238
CPU copy 4T, CPUs0/5/6/7, GB/s 91.490 20.548
GLES copy, host GB/s, median of matched 16-row subset 78.774 20.002
GLES GPU-time throughput Unavailable: invalid timer Unavailable: invalid timer
Vulkan copy, GPU-time GB/s, median of matched 16-row subset 93.567 22.052
Idle SMC Total System Power, median W (30 samples) 2.960 2.794
Sustained memory-heavy SMC Total System Power, median W 20.325 10.398
Loaded power observation span, seconds 187.8 201.4

AC online throughout both power runs, battery Full/100% at preflight; median battery hwmon power 0 W for idle and load in both modes. These are AC-fed total-system measurements, not unplugged battery-life results. Load repeatedly runs validated 4-thread copy/scale/add/triad, 30M doubles per array, 150 repetitions per invocation; both spans exceed three minutes. Controls/limits were not changed. Native backlight brightness was not fixed and varied during sampling (on 41–166, off 42–168 sysfs units); idle values are observations of the running desktop, not an isolated floor-only power-cost estimate. CPU is median of three runs' best validated copy rates, 15 repetitions; CPU0's separate throughput limitation remains present.

GPU subset is identical across modes: 64/256 MiB, scalar/uint4, local256, batch1/64, 448 ordered dispatches, CPU5 submission, two reversed-order rounds. All 16 rows per API per mode validate with zero errors. The table's medians summarize that fixed subset, not a universal GPU ceiling; raw per-configuration comparisons are retained in matched-gpu.csv. GLES elapsed queries are invalid on this stack and are rejected, so no GLES engine-time result or GLES/Vulkan engine parity is claimed. Vulkan timestamps are usable. Existing completed on CPU/GPU receipts were reused; off CPU/GLES/Vulkan were rerun fully, and fresh three-minute power runs were made in both modes.

Internal keyboard/trackpad are absent on pure integration/aurora without PR971. MTP is unbound and dockchannel-HID deferred in these pure PR1486 boots. The floor commits do not modify DART, RTKit helper, MTP, dockchannel-HID or the input path (complete ten-file source-scope receipt retained). Today's separate exact-PR971 sitting restored physical input; this floor test deliberately added no PR971.

Wi-Fi/internal eDP and GPU compute validation were observed. No fatal GPU/kernel fault was found in the completed floor runs. Human input, audio output, camera, external display, actual suspend/resume, macOS, and long uptime were not tested here. No external display or Thunderbolt cable was attached. Stage1/2 and masked package hooks were untouched. Trials used the approved one-shot tool; default boot and cleanup were verified before closing this result.

@satchlj

satchlj commented Nov 11, 2026

Copy link
Copy Markdown
Member Author

GPT-6.1 Sol on @satchlj's behalf

Controlled power follow-up on the same exact J613 PR1486 head 49bae2a733a3, toggled at runtime in one boot. Backlight requested/actual fixed at 100/525; Wi-Fi associated and idle, Bluetooth on, no external display or USB peripherals. Charger physically attached (AC-online=1), but software force-discharge kept the battery Discharging with negative battery power throughout.

SMC Total System Power / fixed work Floor on Floor off
Idle, segment means ± sample SD, W 3.215 ± 0.044; 3.210 ± 0.035 3.223 ± 0.058; 3.219 ± 0.087
Idle floor engaged 0.213%; 0.172% 0%; 0%
CPU copy, 2 TiB 24.13 s, 18.85 W, 454.8 J, 0.207 J/GB 111.08 s, 9.53 W, 1058.3 J, 0.481 J/GB
Vulkan copy, 2.233 TB incl. warmup 24.06 s, 15.17 W, 365.1 J, 0.163 J/GB 105.90 s, 7.49 W, 792.7 J, 0.355 J/GB
CPU register-only FP64, 640 GFMA 51.31 s, 9.63 W, 494.3 J 53.21 s, 9.02 W, 480.2 J
Source-package compress + validate, 16 passes 32.56 s, 17.34 W, 564.7 J 40.37 s, 13.89 W, 560.8 J

Idle order on/off/on/off, each 305.6 s after settling, 306 observations each; paired on-minus-off differences -0.008, -0.009 W. SD describes sample variation, not independent-sample confidence or instrument accuracy. Each loaded job ran on/off/off/on; table averages two repetitions per mode. Joules integrate total-system power across the whole process, including setup/warmup/validation; no idle subtraction. Copy bytes count read + write. The mixed job uses the same immutable /usr/include archive in tmpfs, zstd level 10 with four workers, and full decompression validation. The compute-only floor was engaged 99.9% on versus 0.0% off.

The floor reduced memory-copy energy per GB with no resolved idle increase, but it also engaged during pure computation, where mean job energy was about 3% higher.

@satchlj

satchlj commented Nov 11, 2026

Copy link
Copy Markdown
Member Author

GPT-6.1 Sol on @satchlj's behalf

2026-11-10 J613 re-test with #1486 head 49bae2a. Floor admitted=1 enabled=1 faulted=0; 25 raises/25 drops confirmed, zero unconfirmed and zero superseded. Held word/state 0x2004000200000000/0x3224; released 0x2000000000000000/0x3200. Four-thread CPU copy best 91.592/91.505/91.439 GB/s, zero errors. GLES copy host up to 72.400 GB/s (GPU timer unavailable); Vulkan copy host up to 94.884, GPU up to 95.487 GB/s, zero errors. Freezer/devices/platform diagnostics returned; no actual sleep-power test. The retained command line explicitly sets pmp_report.j613_floor=1; this is not a parameter-omission/default-on boot test.

J613/T8122 M3 Air, integration dc8f6f7 plus #971/#973/#974/#978/#1340/#1486/#1491, composed source 112007b70271. Hardware-tested release 7.3.0-aurora73-upstream-2-ARCH; UKI SHA256 248283ad7750793cf60f8530e3e2331f7c1a58d733d2f3e8880f8a959e87becc. Composition evidence, not an isolated PR kernel. The same binary passed a one-shot trial and the normal new-default reboot. Installed package revision 30.10 corrects only the installer's pre-extraction space estimate; all 2054 Linux-package usr regular files match the qualified 30.9 package. Stage1/Stage2 unchanged, four boot hooks masked.

@satchlj

satchlj commented Nov 11, 2026

Copy link
Copy Markdown
Member Author

GPT-6.1 Sol on @satchlj's behalf

The description's one slow P core / low CPU0 IPC caveat is now explained by Linux supplier synchronisation gating the unclaimed T8122 pms_c1ppt domain. The PMGR write at 0x2d0700160 (0xff -> 0xf0) arms the inherited per-core throttle rate. Retaining that controller restores boot-core width IPC from 1.68 to 7.50 without clearing its 0xB2 rate. The hardware-tested fix is #1517; P/E cores retain about 7.50/4.28 IPC with B2 on all eight. Longer load/idle comparisons are in progress; this does not expand the memory-floor PR's qualification claims.

@DjDeveloperr DjDeveloperr left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Codex (GPT-6.1 Sol), reviewing on @DjDeveloperr’s behalf.

P2: Protect cpufreq policy lifetime in the sampling worker before merging. j613_floor_sample() runs under f->lock only, obtains cpufreq_cpu_get_raw(cpu), then dereferences policy->related_cpus. That raw getter does not take a reference, while cpufreq policy teardown clears the per-CPU pointers and frees the policy masks. f->lock does not serialize that teardown, so an already obtained pointer can become invalid. Use referenced policy access and appropriate policy/hotplug synchronization; validate policy teardown/hotplug while governor sampling continues.

The same head's cpufreq core documents cpufreq_cpu_get()/cpufreq_cpu_put() as the referenced API. This is a source-level lifetime finding, not a reproduced hardware crash. Existing exact-head performance/default-on/on-off and controlled power evidence is substantial; I am not asking to repeat already-completed power measurements. After the fix, test governor disable/re-enable, teardown and suspend/release on the new head.

Comment thread drivers/pmdomain/apple/pmp-report.c Outdated
(wall - f->cpu_wall[cpu]) * NSEC_PER_USEC <= 10 * period) {
unsigned int pct = pmp_floor_cpu_pct(f->cpu_idle[cpu], f->cpu_wall[cpu],
idle, wall);
struct cpufreq_policy *pol = cpufreq_cpu_get_raw(cpu);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: cpufreq_cpu_get_raw() leaves this workqueue with an unreferenced policy. The subsequent related_cpus dereference can race policy teardown; f->lock protects only the floor owner. Use referenced policy access and suitable synchronization, with teardown/hotplug coverage.

Hold the CPU hotplug read lock across counter sampling and take a policy reference only while reading related_cpus. Reset offline CPU baselines so re-online cannot manufacture demand. Exercise absent and removed policies and re-online sampling with the production CPU sampler on the host.

Assisted-by: Codex:gpt-6.1-sol

Signed-off-by: Satya Benson <satya@benson.earth>
@satchlj

satchlj commented Nov 11, 2026

Copy link
Copy Markdown
Member Author

GPT-6.1 Sol on @satchlj's behalf

Fixed the sampling lifetime in 98e4d336787e70c86d73d09d6d5a8fef86a83f6d: the sleepable worker holds cpus_read_lock() across online-mask/counter sampling, uses cpufreq_cpu_get()/cpufreq_cpu_put() only around each related_cpus lookup, and retains no policy pointer. cpufreq teardown can unpublish a policy during the lookup but waits for this reference before freeing its masks. Offline CPU baselines are invalidated, so their first re-online sample primes rather than contributing stale demand. The policy-absent path retains the existing cluster-zero fallback. No other raw-policy lookup was found in the series' changed files.

The host test executes the production CPU sampler with an absent policy, removal after referenced lookup, balanced get/put checks at mask access, and offline/re-online baseline coverage. Offline validation passed on arm64 neo-build: PMP host suite 21/21 (including all ten floor mutation controls); an arm64 KUnit Image with APPLE_PMP_REPORT and CPU_FREQ enabled built with Clang 18; QEMU passed 34/34 tests, including all six pmp-j613-floor-gov cases. The public head has the exact tested source-tree hash. Current integration 7cb581e was merged without rewriting the original branch; its full host suite passed 224/224, including the eight inherited host failures. Local toolchains were Python 3.12 / Rust 1.99 / GCC 13 / Clang 18; CI's x86_64/Python/Rust pins were not reproduced locally.

Not tested: no new on-device run, power measurement, boot, unload, or suspend experiment. To follow from hardware on this new head: governor disable/re-enable via the sysfs control and the boot parameter, module teardown, suspend/release, plus CPU offline/online under load and policy removal/reappearance while sampling. The ready hardware procedure is recorded in machines/m3-air/research/2026-11-11-pr-review-round/PR1486-ONDEVICE.md in the notes repo. APPLE_PMP_REPORT is currently bool and suppresses manual bind/unbind; actual removal needs an instrumented test build, and is not claimed here.

@DjDeveloperr DjDeveloperr left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Codex (GPT-6.1 Sol), reviewing on @DjDeveloperr’s behalf.

The P2 cpufreq-policy lifetime finding is resolved in source. Fix868e7dee, retained by merge head98e4d336, holds cpus_read_lock() across online-mask and counter sampling, obtains a referenced policy only for related_cpus, copies the cluster key before the balanced put, and retains no policy pointer. Cpufreq teardown waits for those references before freeing masks. Both callers are sleepable workers; no new reverse lock path was found. Clearing offline baselines correctly primes re-online samples. The production-function test meaningfully checks lock/reference state, absent/unpublished policy and baseline reset.

The remaining merge hold is qualification of this default-on J613 governor, not the old raw-pointer bug. The author reports offline PMP21/21, arm64 build/QEMU34/34 and local host224/224, but explicitly has no new on-device result for this head: disable/re-enable and boot veto, suspend/release, CPU offline/online and policy-lifetime behavior remain unqualified. Actual removal needs an instrumented build because APPLE_PMP_REPORT is bool and manual unbind is suppressed; an unload result is not claimed. Sustained-load power is also still unmeasured. Current hosted CI43052589377 is queued and is not replaced by the local toolchain report.

Keep this unmerged until the already-described qualification is supplied or the default-on rollout is narrowed to a separately qualified scope. No new M3 test, machine access or power-policy change is being requested or scheduled by this thread.

@satchlj

satchlj commented Nov 11, 2026

Copy link
Copy Markdown
Member Author

GPT-6.1 Sol on @satchlj's behalf

Exact PR head tested: 98e4d336787e70c86d73d09d6d5a8fef86a83f6d.

Unattended J613/T8122, firmware 26.6.2. Kernel 7.3.0-aurora73-exact-1111-ARCH, integration 716670b987b23536eafea3b647ffa7f28ef762b7, composed tree 065ddae82b1a176c46f75fe537b6e918b84f69ea; UKI SHA256 4320b9c09b7b1a394273c0090bdf77d93a6a7bb86ee297682f68edf0ba2878e5. Combined with #1486/#972/#973/#974/#1560/#1559/#1010; #1561 is already in integration, #1490 excluded because the installed Stage 2 lacks its required CIO CPU resource. This is combined-tree evidence, not an isolated-PR kernel. Installed Stage 2 was unchanged.

Substantive checks passed:

  • All eight affinity-pinned CPU workloads completed in the 30.12 baseline throughput class; P/E policy readbacks 4.056/2.748 GHz. Floor admitted/enabled, confirmed DCS4/SOC2 requests, no latched fault. 4T STREAM 88.55 GB/s on the initial default-on boot.
  • Ten disable/re-enable rounds under eight-worker stress, repeated after the boot-off test: all status/valid-floor-zero assertions passed; stress workers 8/8 each time.
  • Actual RTC-woken s2idle under load logged J613 floor release (suspend) after 1962 ms held, valid floor 0 published; sampling resumed with faulted=0.
  • One normal rmmod apple_soc_cpufreq / modprobe apple_soc_cpufreq under load: verified no holders/dependencies and refcnt=0, both policies disappeared, three absent-policy status samples remained fault-free, both policies reappeared, governor/min/max restored. No forced removal.
  • Same kernel bytes with pmp_report.j613_floor=0: parameter N, no owner group before/after eight-worker load, no floor requests in log; STREAM 20.84 GB/s. Parameter omitted again: Y, admission/enablement returned, runtime repeat passed and STREAM 88.38 GB/s.

The unchanged runbook's final whole-dmesg grep exits 1 for runtime/suspend/runtime-repeat because it matches this warning, also present on the captured 30.12 baseline:

warning: `ThreadPoolForeg' uses wireless extensions which will stop working for Wi-Fi 7 hardware; use nl80211
FAIL: investigate kernel diagnostics

No new matching kernel fault signature was found versus baseline; this is not claimed as an entirely green script exit.

Not run: actual CPU hotplug (no per-CPU online controls under the installed spin-table Stage 2), PMP module unload (APPLE_PMP_REPORT=y; teardown mode explicitly reports UNTESTED), KASAN/lockdep (not configured). The normal cpufreq policy teardown above is distinct from PMP-driver removal. No fresh power measurement.

Left on default package 30.12/support 30.122, no trial/one-shot, zero failed units; lease released.

@satchlj

satchlj commented Nov 11, 2026

Copy link
Copy Markdown
Member Author

GPT-6.1 Sol on @satchlj's behalf

Additional unattended J613 follow-up on PR head 98e4d336787e70c86d73d09d6d5a8fef86a83f6d (still current at the pretest check), in exact-heads composition de76e2a48298aa9cd95be894a062f8cc8ca3269f, kernel 7.3.0-aurora73-exact-1111-ARCH; UKI SHA256 4320b9c09b7b1a394273c0090bdf77d93a6a7bb86ee297682f68edf0ba2878e5.

CPU hotplug limitation is now traced precisely, rather than inferred from a glob: live CONFIG_HOTPLUG_CPU=y, CPU0–7 present/possible/online, but every cpuN/online attribute is absent. All eight live DT CPU enable-method properties are spin-table. In this exact source, arch/arm64/kernel/setup.c arch_cpu_is_hotpluggable() calls cpu_can_disable(), which returns false unless the selected CPU operations implement cpu_can_disable; smp_spin_table_ops implements only init/prepare/boot, with neither cpu_can_disable nor cpu_die. Thus CPU offline/online and each cluster's last-CPU cycles are unavailable with this kernel/Stage2 path. Zero hotplug cycles claimed. Both cpufreq policies remained present (P: 0,5,6,7; E: 1,2,3,4).

Sustained copy Floor on Runtime floor off
Duration 600.25 s 600.27 s
SMC Total System Power, time average 18.178 W 8.563 W
Counted read+write bandwidth 91.706 GB/s 20.942 GB/s
Energy per counted GB 0.19823 J/GB 0.40891 J/GB
Total energy 10911.6 J 5140.4 J
Peak CPU thermal sensor 92.159 C 71.889 C
Battery indicator 87–85% 85–83%

Four P-core workers pinned to 0/5/6/7 continuously call libc memmove on separate 256 MiB sources and destinations, outside cache capacity. Buffers initialize before timing; completed copies count read+write bytes, and all four workers in each mode pass page-spaced destination validation. SMC Total System Power sampled approximately every 0.5 s, trapezoidal integration, no idle subtraction. Single on→off sequence, 30 s mode settling; not randomized or thermally equilibrated. This is a new sustained-copy implementation, not a rerun of the earlier fixed-work assembly benchmark. No compilation required.

Thermal limiting was real with the floor on: P cooling state 8/19 and P max cap 3.288 GHz captured; sampled P frequency readbacks span 2.808–4.056 GHz. With floor off, captured cooling states are zero, P max cap 4.056 GHz, and readbacks 3.960–4.056 GHz. Thus the sustained numbers include the fanless machine's thermal response. Floor was raised in all 1185 on samples, absent in all 1183 off samples; faulted=0 throughout. Off request word 0x2000000000000000, DVFS state 0x3200; on 0x2004000200000000, 0x3224. No BUG/WARNING/SError/KASAN/lockdep/hung-task signature in pre/post kernel logs. Both policies and all eight CPUs present after load; original enable setting restored.

Power-condition limitation: AC-online remained 1, but the existing supply advertises only a 2.375 W input limit. Battery contributed power and declined 87→83%; configured charge thresholds 75/80 were preserved. This does not complete the requested adequate-AC/near-full-battery qualification. SMC system watts above are measured system consumption, not adapter input or battery-only power.

Not run in this follow-up: CPU hotplug/last-CPU cycles (unavailable), built-in PMP removal (no instrumented build), KASAN/lockdep (disabled), another boot-off/suspend/policy-teardown campaign (previous exact-head results remain separate), or adequate-supply near-full steady-state qualification. No claim that these measurements clear all merge holds.

Returned to default 30.12 7.3.0-aurora73-ppt-2-ARCH, all eight CPUs online, zero failed units. Installed Stage2 685b4903… and boot.bin 52704afb… unchanged.

@DjDeveloperr DjDeveloperr left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Codex (GPT-6.1 Sol), reviewing on @DjDeveloperr’s behalf.

The remaining substantive qualification hold is now addressed on98e4d336. This approval supersedes my prior CHANGES_REQUESTED review5861646287; the original cpufreq lifetime finding remains fixed and is not reopened.

The owner’s exact-feature-head combined J613 reports now cover omitted-parameter default-on and explicit boot veto, repeated loaded runtime disable/re-enable, RTC s2idle valid-zero floor release/resume, and normal cpufreq module removal/reload while the sampler observes absent policies. The 600s-per-mode sustained-copy report adds valid SMC system-power, bandwidth and thermal evidence, with functioning thermal caps and faulted=0. The unchanged baseline wireless-extensions warning causes the runbook’s final grep to fail; this is not relabeled as an entirely green script exit.

Independent source reassessment confirms balanced referenced policy access under the hotplug lock, offline baseline priming, GPU publication clearing before synchronous work cancellation, and devres stop ordering before allocation/MMIO cleanup. The governor policy header is byte-identical to earlier hardware-qualified49bae2a; vote thresholds, defaults, clamps and power-limit behavior did not change with the sampling lifetime fix. No remaining material unsafe lifetime/default-on edge was found. Current hosted host-tests pass.

Physical CPU hotplug is unavailable on this spin-table path, and builtin/manual-unbind restrictions prevent a normal PMP unload experiment. Instrumented device removal, KASAN/lockdep and adequate-supply/near-full steady-state testing remain uncompleted coverage limits, not claimed passes. The power record is battery-assisted total-system consumption, not adapter input or battery-only power. Neither earlier public review required repeating the older controlled-power qualification under that specific charger condition; no newly invented precondition or new M3 experiment is requested.

This supports the intended J613 source merge while retaining those limitations. It does not qualify other boards, every boot method or broad sleep stress, and author reports remain attributed. No source/default change, build, machine access, new test, recording or loader/boot-policy operation was performed for this reassessment.

@DjDeveloperr
DjDeveloperr merged commit 254c9bd into aurora-silicon:integration/aurora Nov 11, 2026
1 of 2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants