Leoda

2026-04-16

8 min read

2026-04-16 Daily

🧠 今天记录

  • debug flagcx connector ✅ 2026-04-16

  • 【bug1】看到flagcxWaitSignal 报错raise RuntimeError(f”FLAGCX error: {error_str}”)

    • 确定了 error 码是 1，就是Unhandled device error ⬇️
    • 先增加了 comm 初始化 并发的隔离，未解决，但是代码保留 ⬇️
    • 然后怀疑是 context 用了其他的 cudaDevice 导致的，加了setCurrentDeive之后导致会出现 hang，不会直接报错了。
    • sanitizer 排查内存问题，
      • sanitizer 跨机给出的 error 分别有：cudaErrorNoKernelImageForDevice (error 209) on cudaGetLastError， CUDA_ERROR_NOT_PERMITTED (error 800) on cuMemCreate，CUDA_ERROR_NOT_SUPPORTED (error 801) on cuMemGetHandleForAddressRange. 三类错误分别是没指定sm90，VMM 不知道为什么分配被拒，不支持ncclCommWindowRegister。❌
      • 发现flagcxOneSideBuildFullMesh内存在下面问题，需要结合 flagcx.cc内flagcxOneSideBuildFullMesh的 for 循环代码来看:
        时间轴 ──────────────────────────────────────────────────────►

  rank0:  [i=0: self↔self] ──完成──► [i=1: while循环开始]
                                       └─ connect(rank1.listen)   TCP 进入 rank1 的 accept queue
                                          accept(rank0.listen)    等待 rank1 来连

  rank1:  [i=0: while循环]
           connect(rank1.self)   TCP 进入 rank1 自己的 accept queue
           accept(rank1.listen)  ← rank1的accept queue里现在有2个连接:
                                      [A] rank1 自己(self-connect, i=0预期)
                                      [B] rank0 发来的 (i=1来的, 不该这轮消费)

  OS 的 accept queue 是 FIFO，但 [A] 和 [B] 谁先到是竞态。如果 rank0 的 TCP connect 先到：

  rank1 的 accept() 拿到了 [B] (rank0 的 i=1 连接)
    → recvComm 设置为来自 rank0 的连接 ✓ (recvComm != NULL)
    → while 条件: sendComm==NULL || recvComm==NULL
                 →  recvComm 非 NULL，accept() 不再被调用

  rank1 的 connect(self) 还卡在 StateSend/StateConnecting
    → 需要有人 accept() 自己发过去的 QP info
    → 但 while 循环里 recvComm 已非 NULL，不会再调 accept()
    → sendComm 永远是 NULL
    → while(sendComm==NULL || recvComm==NULL) 永远成立
    → rank1 无限循环，sendComm 卡死 ← HANG
      问题是，这里在和 MC 讨论中发现 mpich 启动的测试从来不会出现问题，我用 openmpi 会出现问题。就算这里加上 barrier，在 pd 分离的时候依旧会出现 decode 出一样的报错。❌
    • 两边 signal 计数会乱，改成发端统计好有多少signal，通知收端，收端直接只下一次 wait 操作。 ⬇️
    • 在flagcxHeteroWaitSignal内加了D2H的拷贝，把当前收端 current signal 打印出来和 sender 发过来的signal 做对比， 观察到每次连续 runtest的时候第二次测试 recv 端需要 194 个，但是每次卡在 180个左右就再也等不到了，prefill 侧 log 看到 ibrc 打印FLAGCX WARN NET/IB : unable to allocate requests和FLAGCX WARN flagcxRmaProgressThread: op failed peer=1 type=1 res=3 当rma 的 proxyThread 执行的时候，flagcxRmaProgressThread 去调用 ibrc_adaptoe封装的flagcxIbIputSignal，这里当并发大的时候就会返回 flagcxInternalError，然后 flagcxRmaProgressThread 检查不是 flagcxSuccess 就会直接 free 这个 wr。。。。。 
        flagcxRmaProgressThread    ← 从 pending 取出 desc
      └─ netAdaptor->iputSignal()   ← IB adaptor 层
          └─ flagcxIbGetRequest()   ← 从 reqs[256] 里找一个 UNUSED slot
              ← 找到 → 设 type=IPUT, 返回指针存到 desc->request
              ← 找不到 → "unable to allocate requests", 返回 flagcxInternalError
      └─ 成功后: desc 挂到 inProgress 链表
      └─ 后续循环: netAdaptor->test(desc->request)
          └─ flagcxIbTest → flagcxIbCommonTestDataQp
              └─ ibv_poll_cq() 收割 CQE
              └─ events 减到 0 → flagcxIbFreeRequest(r)  ← r->type = UNUSED, slot 回收
          └─ done=1 → rmaDescComplete(desc) → free(desc)
      所以问题就是如果256 个 slots 都不是空的时刻，新进来的请求就会被 flagcxIbGetRequest 函数内的for loop 挡在外面，返回的是flagcxInternalError 导致后续的代码直接 free 掉了当前的 desc，因此在这里尝试了不 free，不成功就把当前的 desc 重新enque 到 proxy 链表后，所有

    if (res != flagcxSuccess) { WARN(“flagcxRmaProgressThread: op failed peer=%d type=%d res=%d”, p, (int)desc→type, (int)res); __atomic_store_n(&proxy→rmaError, 1, __ATOMIC_RELEASE); free(desc); ```

  • 【bug2】tp=2 的 prefill / decode观察到，出现 hang 的时候每一边都另一个 host:ip 服务看不到

    Prefill：flagcx_connector.py:554: Pair comm ready (responder/rank=1) ↔ 10.8.2.169:8999
Decode：flagcx_connector.py:575: Pair comm ready (initiator/rank=0) ↔ tcp://10.8.2.168:8999
    Prefill:
(Worker_TP0 pid=167763) [2026-04-15 19:59:53] INFO flagcx_connector.py:510: Registered 96 KV MRs + per-pair signal buffer for pair comm=0x7fb1d4001160 (signal_ptr=0x7fc0315eb400, signal_device=cuda:0, current_device=0)
(Worker_TP0 pid=167763) [2026-04-15 19:59:53] INFO flagcx_connector.py:554: Pair comm ready (responder/rank=1) ↔ 10.8.2.169:8998
(Worker_TP1 pid=167764) [2026-04-15 19:59:53] INFO flagcx_connector.py:510: Registered 96 KV MRs + per-pair signal buffer for pair comm=0x7f8c88001160 (signal_ptr=0x7f8c60200000, signal_device=cuda:0, current_device=0)
(Worker_TP1 pid=167764) [2026-04-15 19:59:53] INFO flagcx_connector.py:554: Pair comm ready (responder/rank=1) ↔ 10.8.2.169:8999
 
Decode:
INFO flagcx_connector.py:510: Registered 96 KV MRs + per-pair signal buffer for pair comm=0x7fb4e4000ba0 (signal_ptr=0x7fc3515eb000, signal_device=cuda:0, current_device=0)
(Worker_TP0 pid=54913) [2026-04-15 19:59:53] INFO flagcx_connector.py:575: Pair comm ready (initiator/rank=0) ↔ tcp://10.8.2.168:8998
(Worker_TP1 pid=54914) [2026-04-15 19:59:53] INFO flagcx_connector.py:510: Registered 96 KV MRs + per-pair signal buffer for pair comm=0x7f48f8000ba0 (signal_ptr=0x7f48d6200000, signal_device=cuda:0, current_device=0)
(Worker_TP1 pid=54914) [2026-04-15 19:59:53] INFO flagcx_connector.py:575: Pair comm ready (initiator/rank=0) ↔ tcp://10.8.2.168:8999

    这里的改动思想很简单，就是 sender 的 work 第一次进来去告诉receiver 我的uid，同时 decode 的 listen 线程提前开始等待这个，一起开始调用commInitRank和_register_kv_for_comm。解决这个 bug2 后在后续测试 bug1 的几十次 vllm serve 都没有出现开头就 hang 的问题了。✅

🚀 今日TODO

  • 修复 flagcx connector 两个 bug ✅ 2026-04-17
    • bug1: 加错误码发现收端就是Unhandled device error出错⇒加了set current_device解除这个问题后发现高并发依旧会 hang⇒ sanitizer 扫了一遍内存泄露的所有问题都和这个 hang 无关⇒怀疑 fullmesh 的时候connect 和 accept 会在并发的时候竞争产生 hang，但是和 MC 倒腾一下午发现这个只是 openmpi 的问题⇒后续在 waitSignal 和 prefill 侧增加打印发现是发段请求的 signal 数量和收端对不上⇒确定为 sender 请求丢失⇒读完 proxy 处理 rma 操作的源码，确定为没处理完请求队列槽只有 256，如果256 个 slots 都不是空的时刻，新进来的请求就会被 flagcxIbGetRequest 函数内的for loop 挡在外面，返回的是flagcxInternalError 导致后续的代码直接 free 掉了当前的 desc ⇒把当前的 desc 重新enque 到 proxy 链表后，问题解决 ✅ 2026-04-17
    • bug2：tp=2 的 prefill / decode观察到，出现 hang 的时候每一边都另一个 host:ip 服务看不到。改动思想很简单，就是 sender 的 work 第一次进来去告诉receiver 我的uid，同时 decode 的 listen 线程提前开始等待这个，一起开始调用commInitRank和_register_kv_for_comm。解决这个 bug2 后在后续测试 bug1 的几十次 vllm serve 都没有出现开头就 hang 的问题了。 ✅ 2026-04-20

🧩 遇到的问题 / 卡点

  • [ ]

📌 明天该干啥

  • [ ]

💡 随手记录

Graph View