Link Basics
The states that hold a link back
Between the working state and power off sit three pauses, and a device that is present but slow to answer is usually waking from one of them.
The pauses inside the machine
Between the working state L0 and the powered-down state L2 sit three intermediate positions, L0s, L1 and the recovery path between them. They are the states that hold a link back from traffic without releasing it, and they are the source of most complaints that a PCI Express device is present but slow to answer.
L0s is the shallow pause. A transmitter can idle into it on its own initiative when it has nothing to send, and the return to L0 is designed to be short, on the order of a re-acquisition rather than a retrain. L1 is deeper. Entry to L1 is negotiated: one end proposes, the other accepts, and both sides drop their transmitters together. The saving is larger and so is the cost of coming back, because the link must re-establish lock before packets move again. L2 sits below both, the state entered on the way to removing main power, where only auxiliary power and the wake logic remain alive.
The pause that is requested rather than fallen into has parallels far outside signaling. A Danish reading desk on play and its risks documents a documented pause from play, the enforced break a participant can ask a system to hold them to, and the parallel is instructive: L1 works the same way, a pause one side proposes and the other agrees to hold, with a defined way back rather than a crash out.
What the pauses cost
The cost of a pause is latency at the wrong moment. A device that sends rarely and answers quickly is well served by L0s and L1; a device that must answer on the first edge of a request pays the exit time on every transaction. The platform expresses this trade through Active State Power Management, ASPM, the collection of controls that decide which pauses a given link is allowed to take. Operating systems expose it because the right answer differs by workload: a storage device under a batch job wants the savings, and a device feeding a real-time task wants the link awake.
The recovery state is the bridge. Recovery re-runs enough of the training sequence to re-establish bit lock and symbol lock without renegotiating width or rate, which is why exit from L1 is measured in training symbols rather than in a full Detect to L0 pass. The full sequence these pauses leave and return to is described in the counted sequence, and the rates the re-lock runs at are listed in the link speed table.
How do you know a pause is the problem?
The signature is a device that works and a link that hesitates. Reads and writes complete, but the first transaction after an idle stretch carries a delay the steady state does not show. In a trace this reads as gaps followed by clusters; in a latency histogram it reads as a second population of slow completions. Neither is a fault in the error-recovery sense, which is why it survives ordinary debugging: nothing is wrong, the link is simply waking up.
The platform view confirms it. The link capabilities and the ASPM settings of both ends are enumerable, and the kernel documents how ASPM is negotiated and where its policy lives in the PCI and ACPI notes, read on September 6, 2026. A link whose two ends disagree on which pauses are allowed is a configuration question, not a signal question.
| State | How it is entered | What the return costs |
|---|---|---|
| L0s | Unilateral, when the transmitter goes idle | Short re-acquisition to L0 |
| L1 | Negotiated between the two ends | Re-lock through Recovery |
| L2 | On the way to main power removal | Wake event or full retrain |
Why do the pauses exist?
Because the alternative is a link burning full power to carry nothing. A serial link spends much of its life idle, and the power saved by idling the transmitters is the reason portable systems can afford wide links at all. The background of why the trade exists is sketched in the literature on low-power electronics, read on September 6, 2026: energy spent holding an idle line ready is energy spent on no information at all.
The other reason is that the pauses are recoverable. A link that had to re-run Detect every time it rested would pay for idle time with availability, and nobody would take the deal. L0s and L1 are the negotiated middle: deep enough to matter, shallow enough to leave quickly, with Recovery as the stairs between the basement and the working floor.
Checks before blaming a pause
- Look for the pattern: slow first transaction after idle, fast ones after. That shape is an exit latency, not a fault.
- Read the ASPM capabilities of both ends before changing either; a mismatch is a configuration finding.
- Separate L0s exits from L1 exits in the trace: they return by different paths and cost different amounts.
- Confirm the workload actually needs first-edge latency before disabling the pauses it was designed around.
Common mistakes
- Calling a wake-up delay a link failure. The packets arrive; they are simply late by the exit time.
- Disabling ASPM platform-wide to fix one workload. The control is per link, and the fix should be too.
- Reading L1 as a deeper Detect. L1 is negotiated and returns through Recovery; Detect restarts the count.
- Forgetting the other end's policy. One end can offer a pause the other refuses, and the refusal is in the capabilities.
The states that hold a link back are not the enemy of throughput; they are the price of having the link at all in a power-limited box. Read them as a contract between two ends about how much sleep the traffic can afford, and debug them the way the contract is written: entry conditions, exit path, and the rate the return runs at.
The page behind these facts
The state names L0s, L1, L2 and Recovery come from the PIPE specification revision 7.1, Intel reference 643108, read on September 6, 2026. The power-management framing and the platform controls are summarized in the PCI Express article's power management section and the kernel's PCI and ACPI notes, linked above, both read the same day.