A subtle first-order hardware erratum has been found in the LoongArch processor family: under specific conditions on the LA664 core (used in 3C6000/S 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.
It started with a packaging deadlock
In 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.
The 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.
AI pinned it to LASX vectorized memory reads in two days
In 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.
Two 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.
Further 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.
Multiple atomic instructions are affected; impact extends beyond normaliz
Further 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<OP>_db.*) are not affected — which is why the barriered amcas_db.d showed a 0% failure rate under the same conditions.
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.
That 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.
Loongson fixed it in two weeks; firmware ships before October 1
The 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/S. 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.
Users 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://jia.je/hardware/2026/09/24/loongson-cpu-erratum/). Loongson has stated that the public firmware will ship before National Day (October 1).
The 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.