Someone unplugs an external drive while it is being written. The host's next write goes to a link that no longer has anything at the other end. On a well-designed system, the operating system reports "device removed", fails the outstanding I/O, and carries on. On a badly designed one, a request waits for ever, and the machine freezes. The cable was the only thing that changed.
How does each side know the other is there, and what must happen when it suddenly is not?
The obvious assumption is that the other side is always there: it is soldered on, or it was there at boot. For fixed connections that is true; for anything with a connector or a separate power domain it is not. A protocol that assumes presence has no defined behaviour when the partner vanishes, and "undefined" usually means a hang (lesson 9.9).
Event | Detected by | What must happen |
|---|---|---|
Arrival | A presence-detect pin, a receiver detecting a termination, or a link that trains | Train the link (lesson 11.4), negotiate capabilities (11.5), enumerate (11.6), then start traffic |
Orderly removal | A request from the user or software (a button, an eject command) | Quiesce: stop new requests, drain outstanding ones (lesson 12.5), then power down and release |
Surprise removal | Presence lost, or the link drops unexpectedly | Mark the device gone at once; complete every outstanding request with an error; release its resources; let software recover |
Every outstanding request must end: with a completion timeout at least, ideally completed with an error as soon as the link is known to be down.
Accesses after removal must fail fast: a read from a removed device should return an error (often all 1s, with an error logged) rather than hang.
State tied to the device must be freed: tags, credits, buffers and translation entries.
Software must tolerate it: drivers must expect errors and all-1s data at any time on removable devices.
Protocol | Presence and hot-plug |
|---|---|
PCI Express | Hot-plug slots report presence detect and may support surprise removal. System software marks surprise-removed devices disconnected so further accesses fail rather than wait; orderly removal quiesces the device first. |
USB | Built for hot-plug: the host detects attach and detach on each port and enumerates new devices (lesson 11.6). |
On-chip interfaces to switchable power domains | A powered-down partner is effectively absent; isolation logic drives safe values, and requests to it are blocked or answered with errors. |
The opening freeze (illustrative): the storage driver issued a read just as the drive was pulled; the read's completion never came, and the driver had disabled completion timeouts for performance. With timeouts enabled, and the hot-plug controller failing outstanding requests on link-down, the same removal produced an error message and a clean recovery.
Orderly removal lets the system stop and drain traffic first; surprise removal leaves requests in flight that must be completed with errors.
It cannot answer requests; unless something blocks or answers them, requests to it hang, exactly as with a removed device.
A side must detect its partner's presence before talking and survive its disappearance while talking.
Orderly removal quiesces and drains; surprise removal must fail every outstanding request with an error at once.
Free all state tied to a removed device and make drivers tolerate errors at any time.