[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"news-slug-loongarch-la664-atomic-add-lost-ai-debug-2026":3,"topics-all":38,"news-related-a86df58c-c601-4949-b42d-ba26c2feccb2":57},{"id":4,"title":5,"summary":6,"content":7,"original_url":8,"source_id":9,"tags":10,"translations":24,"news_slug":31,"published_at":32,"created_at":33,"modified_at":34,"is_published":35,"publish_type":36,"image_url":14,"view_count":37},"a86df58c-c601-4949-b42d-ba26c2feccb2","AI 两天锁 LoongArch 原子加丢更新:谁干关键活?","LoongArch 处理器 LA664 核心被发现在特定条件下原子加等指令会丢更新。开发者 8 月借助 AI,两天锁定 LASX xvld 向量化读取触发,排查从 6 个月压缩到 2 天。龙芯两周修复,固件 10 月 1 日前发布。","LoongArch 处理器系列被发现一个不显性的一阶硬错误:在 LA664 核心(主要用于 3C6000\u002FS 和 3A6000)的特定条件下,无数据屏障的原子加、原子比较交换等指令会出现更新丢失。而这起排查中真正值得注意的是:从 2026 年 2 月首次观察到现象,到 8 月借助 AI 在两天内复现并锁定根因,前后耗时近半年,但真正起决定作用的两天里 AI 和开发者都不可或缺。\n\n## 从一个打包死循环说起\n\n故事开始于 2026 年 2 月,LoongArch64 移植版 Debian 13(代号 loong13)维护者王邈在为 normaliz 数学软件打包时,撞上一次死循环:程序卡在循环里退不出来,原因是累计计数永远追不上目标值。OpenMP 编译指示 `#pragma omp atomic` 看上去是按规范写的,反汇编也确认编译器生成了 LoongArch64 的 `amadd.d` 原子加指令,符合预期。\n\n排查一度陷入死胡同:把 normaliz 的逻辑简化成最小测试程序时,无法复现;在 normaliz 实际代码里逐段注释、缩小范围,问题依然顽固。6 个月里,先后怀疑过内存序、OpenMP 实现、龙芯的指令语义,都没有结果。\n\n## AI 两天内锁定 LASX 向量化内存读取\n\n8 月,开发者换了个做法:不再由人去定位,而是让 AI 去寻找最小复现,人负责指挥 AI 的调查方向。第一轮 AI 注意到循环异常,但没有得出原子加存在问题的结论;提示该问题只在 LoongArch 上出现,AI 也未能给出明确判断;直到开发者直接告诉 AI 已经定位到原子加有问题,要求它给出最小复现样例,AI 才把注意力放到 glibc `memcpy` 的向量化实现上。\n\n两天后,AI 给出了一个能稳定复现的最小程序:每条线程对每个数据点先做一次向量化内存搬运,再对共享计数器做一次 relaxed 原子加。复现需要同时满足三个条件:线程运行在不同物理核上、对同一地址执行不带数据屏障的原子操作、其中至少一个线程穿插了内存读取。\n\n进一步追查,熔化过程在 LASX 256 位 SIMD 读取指令 `xvld` 上最易触发,概率几乎到 100%;LSX 128 位读取 `vld` 不触发;独立研究者 Rong \"Mantle\" Bao 还发现,当原子变量所在的内存地址与读取地址满足特定位置关系时,普通标量读取也能触发,只是概率更小。glibc 中 `memcpy` 会按硬件特性自动选择最优实现,在启用 `--enable-multi-arch` 的系统里走 LASX 路径,这就解释了为什么在 Debian 上稳定复现、AOSC OS 却复现不出来:后者在 2 月后发布的 Core 13 版本里误关了 `--enable-multi-arch`,无意间规避了这个 bug。\n\n## 多个原子指令都受影响,影响超出 normaliz\n\n进一步验证发现,受影响的不只是 `amadd`,还包括 `amcas`、`amswap`、`ammax`、`ammin`、`amxor`、`amand`、`amor` 等多个原子操作。带 data barrier 的版本(`am\u003COP>_db.*`)则不受影响,这也是为什么带屏障的 `amcas_db.d` 在同样条件下失败率为 0%。\n\n`ammax`、`ammin` 等没有 C 标准对应接口,编译器通常不会生成;`amcas` 属于 LoongArch64 v1.1 新指令,默认也不会生成。但 `amadd` 在引用计数场景非常常见——Rust 标准库中 `std::sync::Arc` 的引用计数、`std::sync::mpsc` 的 `Sender` 克隆,都用了不带数据屏障的 `amadd`。作者用 safe Rust 程序构造了两个测试,触发后表现为 SIGABRT 或 glibc 报告堆被破坏,意味着已经造成 use-after-free。\n\n不过该问题难以被用于安全攻击:两个线程必须对同一进程内同一对象的同一计数器并发操作,无法跨越进程隔离,因此不太可能被远程利用。AI 在整个排查中的角色,更像是\"快速生成假设 + 自动最小化复现\",而不是独立完成推理——开发者事先已经做了第一轮排查,知道现象是什么、要找什么,才能引导 AI 把注意力放到 `memcpy` 上。\n\n## 龙芯两周修复,固件 10 月 1 日前发布\n\n8 月 26 日开发者把问题反馈给龙芯,9 月 9 日就拿到了测试固件,3A6000 和 3C6000\u002FS 实测都恢复正常,修复速度超出常态。龙芯给出的修复方式是设置内部 CSR MCSR24 的 bit 13,该寄存器手册中并未注明功能;设置后问题不再复现,且单核性能无影响,多核性能略微下降。\n\n如果用户暂时无法更新主板固件,也可以在 Linux 内核里直接写入该 bit,等效完成修复。详细复现条件、benchmark 表与规避方法见原作者 jia.je 的博客(https:\u002F\u002Fjia.je\u002Fhardware\u002F2026\u002F09\u002F24\u002Floongson-cpu-erratum\u002F)。龙芯已表示该固件将在国庆节前公开发布。\n\n这起事件真正的教训不是\"AI 能找 bug\",而是\"AI 在人给出方向后能把模糊假设压成最小复现\"。6 个月的卡顿被压缩到 2 天,前提是开发者已经知道 bug 在哪里、问对了问题;AI 只是把人不愿意做的注释化、编译、运行、缩小的体力活接了过去。CPU 漏洞并不稀奇,ARM 公版核的 errata 文档里同样有访存、原子指令相关的条目;难的是在用户报上来的真实故障里,把这颗头真正钉出来。","https:\u002F\u002Fjia.je\u002Fhardware\u002F2026\u002F09\u002F24\u002Floongson-cpu-erratum\u002F","b15aa1fb-838a-434a-a3b0-2aaead47b012",[11,15,18,21],{"id":12,"name":13,"slug":13,"description":14,"color":14},"5e628969-6d2a-437f-998a-104e4b16cfb1","ai-progress",null,{"id":16,"name":17,"slug":17,"description":14,"color":14},"40269b40-7942-4650-9672-ed2e6524d37a","ai-technology",{"id":19,"name":20,"slug":20,"description":14,"color":14},"e82b2d09-81b2-43d1-977e-e018443b3c14","coding-agent",{"id":22,"name":23,"slug":23,"description":14,"color":14},"e0d31e94-ce47-4c8f-831c-d3d2926d42f3","hardware",[25],{"id":26,"lang":27,"title":28,"summary":29,"content":30},"13c8d027-9b7a-40af-8db5-45d99f3239d4","en","AI Pinned LoongArch Atomic-Add Lost Update in Two Days","LoongArch LA664 atomic ops lose updates under LASX loads. AI reproduced in 2 days; Loongson fixed in 2 weeks; firmware ships before Oct 1.","A subtle first-order hardware erratum has been found in the LoongArch processor family: under specific conditions on the LA664 core (used in 3C6000\u002FS and 3A6000), unbarriered atomic-add and atomic-CAS instructions can silently lose updates. The most interesting part of the investigation is not the bug itself, but the workflow that found it: from the first observation in February 2026 to AI-assisted root cause in August 2026 spanned nearly half a year, yet the decisive two days of work depended on both humans and AI in different, irreplaceable ways.\n\n## It started with a packaging deadlock\n\nIn February 2026, Wang Miao (GitHub: @shankerwangmiao), a maintainer of loong13, the LoongArch port of Debian 13, ran into a deadlock while packaging the math software normaliz: the program's self-test got stuck in a loop that never terminated, because a counter that should have equaled the target value always fell short. The OpenMP `#pragma omp atomic` looked correctly written; disassembly confirmed the compiler emitted the LoongArch64 `amadd.d` instruction as expected.\n\nThe first investigation stalled. Simplifying normaliz's logic into a minimal test program could not reproduce the bug. Commenting out sections of normaliz's actual code still left the issue stubbornly present. Over six months, the developers suspected memory ordering, the OpenMP implementation, and the LoongArch ISA itself. None panned out.\n\n## AI pinned it to LASX vectorized memory reads in two days\n\nIn August, the team tried a different approach: instead of letting humans hunt the bug, let AI hunt the minimal reproducer while humans steered the investigation. In the first round of dialogue, the AI noticed the looping behavior but did not conclude that atomic-add was at fault. Even when prompted that the issue only existed on LoongArch, the AI did not give a definitive answer. Only after the developers told the AI directly that atomic-add was suspected and asked for a minimal reproducer did the AI's attention shift to glibc's `memcpy`.\n\nTwo days later, the AI delivered a stable reproducer: each thread does a vectorized memory move on every data point, then performs a relaxed atomic-add on a shared counter. Reproducing the lost update required three conditions to hold simultaneously: threads running on different physical cores, unbarriered atomic ops on the same address, and at least one thread performing a memory read in between.\n\nFurther analysis found the trigger most reliable on the LASX 256-bit vectorized load instruction `xvld` — failure rate near 100% in the team's setup. The 128-bit LSX `vld` did not trigger. Independent researcher Rong \"Mantle\" Bao later discovered that under a specific address relationship between the atomic variable and the read target, even a plain scalar load can trigger the issue, though with lower probability. glibc's `memcpy` chooses the optimal implementation based on hardware features; on systems built with `--enable-multi-arch`, it takes the LASX path. That also explains why Debian reproduced reliably while AOSC OS did not: AOSC accidentally disabled `--enable-multi-arch` in its Core 13 release after February, inadvertently sidestepping the bug.\n\n## Multiple atomic instructions are affected; impact extends beyond normaliz\n\nFurther validation found that the issue is not limited to `amadd`. Affected instructions include `amcas`, `amswap`, `ammax`, `ammin`, `amxor`, `amand`, and `amor`. The data-barrier variants (`am\u003COP>_db.*`) are not affected — which is why the barriered `amcas_db.d` showed a 0% failure rate under the same conditions.\n\n`ammax`, `ammin` and similar instructions have no C standard interface, so compilers will rarely emit them. `amcas` belongs to LoongArch64 v1.1 and is also not generated by default. The instruction likely to cause widespread impact is `amadd`, the unbarriered atomic add — common in reference counting. Rust's `std::sync::Arc` reference counter and `std::sync::mpsc` `Sender` clone both use unbarriered `amadd` on LoongArch. The author constructed safe Rust programs that triggered SIGABRT or glibc heap-corruption reports, indicating real use-after-free.\n\nThat said, the issue is hard to weaponize: the two threads must operate on the same counter of the same object within the same process, and cross-process isolation makes remote exploitation unlikely. The AI's role throughout was less \"finding bugs independently\" and more \"rapidly generating hypotheses and shrinking a reproducer\". The developers had already done the first round of investigation, already knew what the symptom was, and could steer the AI toward `memcpy`. AI took over the undifferentiated labor: commenting out code, compiling, running, and shrinking.\n\n## Loongson fixed it in two weeks; firmware ships before October 1\n\nThe team reported the issue to Loongson on August 26. By September 9 — two weeks later — they had test firmware; the fix restored normal behavior on both 3A6000 and 3C6000\u002FS. Loongson's fix is to set bit 13 of the internal CSR MCSR24, whose function is not documented in the manual. With the bit set, lost updates stop occurring; single-core performance is unaffected and multi-core performance drops only slightly.\n\nUsers who cannot immediately update their motherboard firmware can also write the bit directly from the Linux kernel, achieving the same effect. The full reproduction conditions, benchmark table, and workarounds are documented in the original jia.je blog post (https:\u002F\u002Fjia.je\u002Fhardware\u002F2026\u002F09\u002F24\u002Floongson-cpu-erratum\u002F). Loongson has stated that the public firmware will ship before National Day (October 1).\n\nThe real lesson from this incident is not \"AI can find bugs\", but \"AI can compress fuzzy hypotheses into a minimal reproducer once humans have pointed it in the right direction\". Six months of stalling were compressed into two days, but only because the developers already knew where the bug lived and how to ask. AI took on the mechanical labor of commenting, compiling, running, and shrinking. CPU errata are not rare — ARM's public errata notice lists plenty of memory-access and atomic-instruction issues for its reference cores; the hard part is nailing down a real fault when users start reporting intermittent failures.","loongarch-la664-atomic-add-lost-ai-debug-2026","2026-09-28T01:00:00Z","2026-09-28T01:07:26.726916Z","2026-09-28T01:07:26.726930Z",true,"agent",981,[39,48],{"slug":40,"tag_slug":40,"title_zh":41,"title_en":42,"intro_zh":43,"intro_en":44,"id":45,"is_active":35,"created_at":46,"modified_at":47},"ai-for-science","AI for Science 2026：从 UniPert 到 GPT-Rosalind 的硬核进化","AI for Science 2026: from UniPert to GPT-Rosalind","生命科学、化学材料、物理世界模型——AI 正在从\"语言工具\"变成\"实验伙伴\"。本专题收录 AI 在三大科学方向的关键节点：UniPert 统一基因与化学扰动空间、GPT-Rosalind 端到端生命科学推理、达摩院 AI 智能体 28 小时找到 4 种超导新材料、Anthropic Claude Science 把工作台做成标准品。","From language tool to lab partner — AI is reshaping life sciences, chemistry\u002Fmaterials, and physical world models. This topic covers the key milestones: UniPert unifying genetic-chemical perturbation spaces, GPT-Rosalind's end-to-end life-sciences reasoning, DAMO's AI agent discovering 4 superconducting materials in 28 hours, and Anthropic's Claude Science workbench going mainstream.","988a4300-5fab-41c4-b5d8-63711a2dc757","2026-09-10T01:34:15.296649Z","2026-09-10T01:34:15.296663Z",{"slug":49,"tag_slug":49,"title_zh":50,"title_en":51,"intro_zh":52,"intro_en":53,"id":54,"is_active":35,"created_at":55,"modified_at":56},"h3-series","MiniMax H3 系列：从开源权重到 35 倍吞吐","MiniMax H3 Series: from open weights to 35x throughput","MiniMax H3 自 2026 年 8 月开源以来节奏密集：官方把生成、参考与编辑收回一个模型；ComfyUI 当天压进 RTX 3060；摩尔线程 3 小时完成国产 GPU 适配；fal 后训练版把吞吐拉到 35 倍；FastH3 蒸馏再砍推理成本。本专题持续追踪 H3 的发布—开源—蒸馏—部署全链路。","Since MiniMax open-sourced H3 in August 2026 the pace has been relentless: one unified omni-modal model, same-day ComfyUI support down to an RTX 3060, a 3-hour Day-0 port to Moore Threads GPUs, fal's post-trained H3 Max at 35x throughput, and FastH3 distillation cutting inference cost further. This topic tracks the full H3 chain — release, open weights, distillation, deployment.","83ef0daa-3c31-4cb3-86ed-e5ee58654d5f","2026-09-08T07:33:19.942193Z","2026-09-08T07:33:19.942209Z",{"items":58},[59,64,69,74,79,84],{"id":60,"title":61,"news_slug":62,"published_at":63},"f6e7c791-0e6b-47c4-8d26-af7163609235","LoongArch LA664 原子指令丢更新:AI 两天定位,龙芯 14 天出固件","loongarch-la664-atomic-erratum-ai-debug","2026-10-07T03:00:00+00:00",{"id":65,"title":66,"news_slug":67,"published_at":68},"552761c1-2fb8-4952-bee5-b2a35c712ccb","谷歌把 TPU 卫星送上天:Gemma 只能跑 15 分钟","google-project-suncatcher-trillium-tpu-gemma-orbit-prototype","2026-10-18T04:00:00+00:00",{"id":70,"title":71,"news_slug":72,"published_at":73},"9db08b3d-e12c-4761-9a34-69451e126ae1","谷歌把冰箱大小的 Suncatcher 送上近地轨道","google-suncatcher-tpu-gemma-orbital-launch-v2","2026-10-06T00:00:00+00:00",{"id":75,"title":76,"news_slug":77,"published_at":78},"e1374b1b-13f1-4e08-a58a-c45e4f6b92af","AMD 82亿美元拿下 World Labs：李飞飞出任 AMD 首席科学家","amd-acquires-world-labs-fei-fei-li","2026-09-29T04:00:00+00:00",{"id":80,"title":81,"news_slug":82,"published_at":83},"33c8038a-f1dc-4b64-b6b7-604baf43f729","CESA 数据:85.8% 日本游戏开发者已把生成式 AI 写进工作流","cesa-2026-japan-game-dev-genai-85pct","2026-09-20T00:00:00+00:00",{"id":85,"title":86,"news_slug":87,"published_at":88},"b398dc77-58a1-498e-a9ed-c045c83c90be","AI 抢走消费级 DRAM:一年涨价五倍,手机路由器全被拖下水","ai-dram-consumer-electronics-price-surge","2026-09-14T01:00:00+00:00"]