loongson2f deadlocks fix
[email protected] Tue, 8 Aug 2017 13:03:23 +0000
| Newsgroups | gmane.os.netbsd.ports.mips.devel,gmane.os.netbsd.ports.evbmips |
|---|---|
| Message-ID | <[email protected]> |
Hi, It looks like we didn't build our LOONGSON kernels with the full loongson2f errata workaround. I changed so now we add the following two flags that were previously missing to kernel builds: -Wa,-mfix-loongson2f-jump -Wa,-mfix-loongson2f-nop I assume the jump fix is the 'big one' (I didn't test it separately), it also sounds costly. It seems like it changes this code: ffffffff802057c0: dec20010 ld v0,16(s6) ffffffff802057c4: 0040f809 jalr v0 ffffffff802057c8: 00000000 nop Into this: ffffffff80205ec0: dec20010 ld v0,16(s6) ffffffff80205ec4: 3c01cfff lui at,0xcfff ffffffff80205ec8: 3421ffff ori at,at,0xffff ffffffff80205ecc: 00411024 and v0,v0,at ffffffff80205ed0: 0040f809 jalr v0 ffffffff80205ed4: 00200825 move at,at My machine seems a lot more stable, but with a rare occurring issue it's hard to know for sure. Additionally we were not clearing RAS which linux does (also changed to match). If we have additional issues, it sounds like we may want to consider building userland with the changed nops. my machine seems stable now, and it was described as a rare issue. https://sourceware.org/ml/binutils/2009-11/msg00387.html https://www.linux-mips.org/archives/linux-mips/2010-03/msg00149.html