rust-lang/rust · error · io::Error

Operation Timed out

Error message

Operation Timed out

What it means

Returned by Rust std's UEFI TCP4 implementation in wait_or_cancel when wait_for_flag does not observe the completion flag within the supplied timeout. The implementation cancels the outstanding EFI_TCP4_COMPLETION_TOKEN and returns ErrorKind::TimedOut. UEFI networking is event-driven; this error means the asynchronous connect/transmit/receive never signalled completion in time.

Source

Thrown at library/std/src/sys/net/connection/uefi/tcp4.rs:339

    /// Wait for an event to finish. This is checked by an atomic boolean that is supposed to be set
    /// to true in the event callback.
    ///
    /// Optionally, allow specifying a timeout.
    ///
    /// If a timeout is provided, the operation (specified by its `EFI_TCP4_COMPLETION_TOKEN`) is
    /// canceled and Error of kind TimedOut is returned.
    ///
    /// # SAFETY
    ///
    /// Pointer to a valid `EFI_TCP4_COMPLETION_TOKEN`
    unsafe fn wait_or_cancel(
        &self,
        timeout: Option<Duration>,
        token: *mut tcp4::CompletionToken,
    ) -> io::Result<()> {
        if !self.wait_for_flag(timeout) {
            let _ = unsafe { self.cancel(token) };
            return Err(io::Error::new(io::ErrorKind::TimedOut, "Operation Timed out"));
        }

        Ok(())
    }

    /// Abort an asynchronous connection, listen, transmission or receive request.
    ///
    /// If token is NULL, then all pending tokens issued by EFI_TCP4_PROTOCOL.Connect(),
    /// EFI_TCP4_PROTOCOL.Accept(), EFI_TCP4_PROTOCOL.Transmit() or EFI_TCP4_PROTOCOL.Receive() are
    /// aborted.
    ///
    /// # SAFETY
    ///
    /// Pointer to a valid `EFI_TCP4_COMPLETION_TOKEN` or NULL
    unsafe fn cancel(&self, token: *mut tcp4::CompletionToken) -> io::Result<()> {
        let protocol = self.protocol.as_ptr();

        let r = unsafe { ((*protocol).cancel)(protocol, token) };

View on GitHub (pinned to 7088e4b63a)

Solutions

  1. Increase the timeout passed to the connect/read/write operation.
  2. Verify the UEFI network device driver is loaded and DHCP has assigned an address.
  3. Confirm the peer address/port is correct and reachable from the firmware's network stack.
  4. Handle ErrorKind::TimedOut explicitly to retry or degrade gracefully rather than aborting.

Example fix

// before
stream.set_read_timeout(Some(Duration::from_secs(1)))?;
let n = stream.read(&mut buf)?; // Operation Timed out

// after
stream.set_read_timeout(Some(Duration::from_secs(10)))?;
match stream.read(&mut buf) {
    Ok(n) => { /* use n */ }
    Err(e) if e.kind() == io::ErrorKind::TimedOut => { /* retry / fallback */ }
    Err(e) => return Err(e),
}
Defensive patterns

Strategy: retry

Validate before calling

fn sane_timeout(t: std::time::Duration) -> std::time::Duration {
    t.max(std::time::Duration::from_secs(5))
}
// stream.set_read_timeout(Some(sane_timeout(configured)))?;

Try / catch

match stream.read(&mut buf) {
    Ok(n) => Ok(n),
    Err(e) if e.kind() == io::ErrorKind::TimedOut => {
        // optionally retry once, then degrade gracefully
        Err(e)
    }
    Err(e) => Err(e),
}

Prevention

When it happens

Trigger: Calling TcpStream connect/read/write (or the underlying EFI TCP4 protocol wrappers) with a timeout on a UEFI application where the peer is unreachable, slow, or the network stack is misconfigured. wait_or_cancel receives Some(duration), polls wait_for_flag, and on timeout calls cancel(token) and returns the error.

Common situations: UEFI firmware network boot/diagnostic tool timing out against a missing DHCP/TFTP server; unreachable peer IP; firewall dropping packets; read/write timeout set lower than the remote response time.

Understand the failure class

Related errors


AI-assisted analysis of rust-lang/rust@7088e4b63a (2026-08-10). Data as JSON: /api/errors/6995c3b4f06ac571. Report an issue: GitHub.