On Jul 8, 2009, at 4:49 AM, Anton Shterenlikht wrote: > On Tue, Jul 07, 2009 at 05:29:06PM -0700, Marcel Moolenaar wrote: >> >> On Jul 7, 2009, at 6:36 AM, Rink Springer wrote: >>>> I tried to reproduce the error, got this on the way: >>>> >>>> # XXX: bogusly disabled high FP regs >>> >>> I get this message quite often as well; I intend to figure out >>> what's >>> going on. Marcel, if you have any idea, please let me know. >> >> It's a race condition. The high FP registers are lazily >> context-switched and this error is emitted when a thread >> wants to use the high FP registers when they are disabled >> and the CPU onto which the thread is running has the high >> FP registers corresponding to that thread in registers. >> In that scenario the high FP registers should not even be >> disabled. >> >> In the above case the kernel simply enables the high FP >> registers and continues the thread. For the most part the >> condition is harmless, but I've been looking at a panic >> that's the result of inconsistency in the high FP state, >> so the race is potentially fatal. >> >> BTW: I never got the error when doing a buildworld. I >> think Anton's non-standard compiler options make GCC much >> more FP intensive and thus prone to causing the race. > > Marcel, sorry, I probably misunderstood "compiler options" > in the previous reply. Did you mean -j option in > make -j10 buildworld? -j is a make option. Modulo the FP race you're perfectly fine with any -j value that matches the number of CPUs in your box (with 4xNCPUS a rule-of-thumb maximum probably). If the compiler isn't FP intensive, then even -j128 on a dual- CPU box is not causing you problems (it's pointless though :-) FYI, -- Marcel Moolenaar xcllnt_at_mac.comReceived on Wed Jul 08 2009 - 14:26:14 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:51 UTC