机台死锁问题排查总结

设备跑货时设备突然停机，报了死锁报警。现场情况是：只跑一个工艺步骤进 PMA 没问题，但加上第二个步骤要进 PMB 或 PMC 就会卡死。排查后发现是 Bug#474 的代码改动引起的。

什么是死锁

调度器就像一个调度员，负责把 wafer 按顺序送到各个腔去加工。调度员有个自我检查机制：如果发现有活要干，但连续 60 秒一个新任务都派不出去，就判定为”死锁”，说明哪里卡住了，需要报警让人来处理。

Bug#474 改了什么

这次改动的目的是优化调度员的判断流程。调度员在送 wafer 进腔之前，会先看看哪些腔当前能接第一道工序的 wafer，然后拿着这份”可用腔名单”，去检查这个 Job 的每一道工序——每一步需要的腔在名单里能找到吗？都找得到，Job 就可以跑；哪一步找不到，就先 hold 住。

问题在哪

这份”可用腔名单”本身就只包含了第一道工序能用哪些腔，但它却被拿去检查了 Job 的所有工序。比如 Job 的第一道工序只指定 PMA，那名单上就只有 PMA，PMB 和 PMC 再空闲也不会出现在名单上。当调度员拿这份名单去检查第二道工序”需要 PMB”时，自然找不到，于是判定 Job 不能跑，hold 住——实际上 PMB 完全可以用，只是名单上根本没有它。

打个比方：你去餐厅吃饭，服务员只看了你们第一个人的口味（只要素菜），就判定你们整桌人都只吃素菜，拒绝给你们下单。后面的人明明要吃肉菜，服务员也不管——因为他的”菜单”是根据第一个人的需求生成的。

具体到这次问题：Job 要先在 PMA 加工 step3，再去 PMB 加工 step4。调度员看的是第一道工序 step3 只能用 PMA，于是名单上只有 PMA。检查 step3——PMA 在名单里，没问题；检查 step4（需要 PMB）——名单上没有 PMB，判定 Job 不能跑，hold 住。一片 wafer 都没取就卡死了。

只跑一个步骤时不会出问题，因为只有一道工序要检查，名单刚好够用。

怎么修的

修复很简单：这份名单只用来检查第一道工序，后面的工序要让调度员去看所有腔，而不是只盯着这份只有第一道工序信息的名单。这样 step4 检查 PMB 时就能正确找到，不会误把 Job hold 住。

总结

这次问题的核心是拿了一个只包含部分信息的列表，当成了完整信息来用。EstimateJustInTimeWaferLoading 的职责是评估”第一片 wafer 当前能进哪些腔”，它天然只关注第一道工序对应的腔。但 HoldNewJob 需要的是”Job 的每一步都有腔可用”这个全局判断，两者需求不同，不能直接把前者的结果塞给后者用。