Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

PCI_ER_06: replace coarse DPC link-recovery waits with bounded polling

Open
  • Is something wrong?
#674 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@cdwilde is already working on this.

Since Oct 28, 2026.

  • #675 by @cdwilde — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
25/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Stale
Tech stack
c
Domain
testing

Research direction

Start with test_pool/exerciser/e024.c and trace the PCI_ER_06 DPC recovery check after Secondary Bus Reset deassertion. Review its timeout and DLL Link Active handling, then validate bounded polling against the stated deadline and failure cases while preserving the separate initialization delay and cleanup. Done means recovery succeeds only when observed within 100 ms and the existing endpoint and error-mode coverage still passes.

Written by the indexing model from the issue text.

Description

Summary

The DPC functionality check in test_pool/exerciser/e024.c spends unnecessary time waiting for link recovery after Secondary Bus Reset (SBR). Polling DLL Link Active with an architectural-counter deadline reduced this check's elapsed simulated time from approximately 332.9 ms to 174.0 ms (47.7%) on one emulation platform, with the check passing.

Current behavior

After deasserting SBR, the check:

  1. Executes an uncalibrated TIMEOUT_LARGE spin.
  2. Reads DLL Link Active.
  3. If the link is inactive and reporting is supported, requests a 100 ms delay before checking again.

This cannot detect recovery during the requested delay, even if the link becomes active much sooner. The spin also does not provide a portable time-based recovery window.

There is a separate 100 ms post-link initialization delay. That delay is not the target of this proposal.

Proposed change

Replace the spin and one-shot recovery delay with:

  • An immediate DLL Link Active check, followed by 1 ms polling-delay requests.
  • A 100 ms recovery window measured using val_get_timeout_to_ticks() and ArmArchTimerReadReg(CntPct), rather than the number of requested delays.
  • Success as soon as the link is observed active within the deadline; failure if it remains inactive or is first observed active after the deadline.
  • Explicit failure for invalid counter frequency, failed delay calls, or unsupported/unexpected link-status reporting.

Counter-based accounting matters because a PAL may scale delay requests. Counting polling iterations instead could unintentionally shorten the recovery window.

Preserve the SBR assertion hold time, separate post-link initialization delay, both error-injection modes, endpoint coverage, configuration restoration, and existing cleanup.

Behavioral point for review: unsupported DLL Link Active reporting previously could continue without demonstrating recovery. The proposed implementation fails recovery in that case; this is an intentional stricter behavior, not merely a timing change.

Validation

On an emulation configuration with eight exerciser endpoints and two error modes per endpoint:

Version PCI_ER_06 elapsed simulated time Result
Before 332.866 ms Passed
With bounded polling 173.954 ms Passed

The updated run exercised all eight endpoints, with two recovery iterations per endpoint. These are check-local timings, not whole-suite or wall-clock improvements. The platform scales PAL delays, so the percentage should not be assumed to apply to other platforms. Full-suite validation is still in progress.

Additional validation:

  • 13 actual-source host scenarios passed at both -O0 and -O2, covering immediate/early recovery, scaled delays, deadline boundaries, persistent link-down, late status reads, unsupported/unexpected status, delay failure, invalid counter frequency, and counter wraparound.
  • The changed source cross-compiled for AArch64 with GCC 13.2 at both optimization levels, with -Wall -Wextra -Werror.

An implementation and focused regression tests are prepared for a follow-up PR.

Dominant language
C
Stars
23
Forks
40
Avg merge
6h 36m
Merged PRs (30d)
92

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ARM-software/sysarch-acs

All issues in ARM-software/sysarch-acs

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.