commaai/openpilot · warning

Connection to panda lost. Attempting reconnect.

Error message

Connection to panda lost. Attempting reconnect.

What it means

Emitted by the PandaStream receive thread (tools/cabana/streams/pandastream.cc) when panda->connected() returns false mid-stream: the USB link to the panda device dropped after a previously successful connect(). The thread logs once per failed poll, tries connect() again, and on failure sleeps 1 s and retries — this is a reconnect notice, not a fatal error.

Source

Thrown at openpilot/tools/cabana/streams/pandastream.cc:53

      if (config.bus_config[bus].can_fd) {
        panda->set_data_speed_kbps(bus, config.bus_config[bus].data_speed_kbps);
      } else {
        // Hack to disable can-fd by setting data speed to a low value
        panda->set_data_speed_kbps(bus, 10);
      }
    }
  }
  return true;
}

void PandaStream::streamThread() {
  std::vector<can_frame> raw_can_data;

  while (!exit_) {
    std::this_thread::sleep_for(std::chrono::milliseconds(1));

    if (!panda->connected()) {
      fprintf(stderr, "Connection to panda lost. Attempting reconnect.\n");
      if (!connect()){
        std::this_thread::sleep_for(std::chrono::milliseconds(1000));
        continue;
      }
    }

    raw_can_data.clear();
    if (!panda->can_receive(raw_can_data)) {
      fprintf(stderr, "failed to receive\n");
      continue;
    }

    MessageBuilder msg;
    auto evt = msg.initEvent();
    auto canData = evt.initCan(raw_can_data.size());
    for (uint i = 0; i<raw_can_data.size(); i++) {
      canData[i].setAddress(raw_can_data[i].address);
      canData[i].setDat(kj::arrayPtr((uint8_t*)raw_can_data[i].dat.data(), raw_can_data[i].dat.size()));

View on GitHub (pinned to 516ec1e682)

Solutions

1. Check and reseat the USB cable/connection to the panda (physical layer first — most common cause).
2. Disable USB autosuspend for the panda: check /sys/bus/usb/devices/*/power/control is 'on', or add a udev rule.
3. If a flash/reboot was intentional, just wait — the thread auto-reconnects within ~1 s of the device returning.
4. Re-run with `lsusb`/dmesg to confirm the device enumerates; if not, the reconnect loop cannot succeed until it does.

Example fix

# before: message repeats, device gone from bus
lsusb | grep -i comma   # nothing
dmesg | tail   # 'device disconnected'

# after: reseat cable / disable autosuspend
echo -1 > /sys/module/usbcore/parameters/autosuspend
lsusb | grep -i comma   # device back; stream reconnects on its own

When it happens

Trigger: Running a live panda stream in cabana and the device disappears: USB cable unplugged, panda rebooted (e.g. after a firmware flash), USB hub power management suspending the device, or the panda entering a bad state. Each loop iteration (~1 ms cadence) with !panda->connected() prints the message; successful reconnect stops it, so a flapping link prints it repeatedly.

Common situations: Loose/damaged USB cable or port during a drive replay or bench testing; panda flashing/firmware update mid-session; udev power-management autosuspend on Linux grabbing the interface; VM passthrough dropping the USB device.

Related errors

• %s
• failed to open panda %s
• write failed: {e}
• flash did not converge within {FLASH_BUDGET:g}s
• expected one chestnut, found {len(found)}

AI-assisted analysis of commaai/openpilot@516ec1e682 (2026-08-15). Data as JSON: /api/errors/e866825ec6e8bfe7. Report an issue: GitHub.