https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221029
--- Comment #63 from Don Lewis <truck...@freebsd.org> --- (In reply to Nils Beyer from comment #61) Hard to say ... If it is something triggered by context switches and is well understood, it might be possible to add some synchronization code in that path as a workaround. It might be a slow path through some logic that was missed by AMD's test procedures. My testing does seem to indicate that there could be a sensitivity to the core clock speed, but it doesn't seem to be a sharp edge, and it also doesn't seem to be temperature sensitive. Doing a better job of testing should catch the bad chips, at the possible expense of throwing out a lot of them. It might be possible to work around that in microcode by allowing more time for the signals propagate. It could also be some sort of other signal integrity problem, which should also be possible to catch in test, but would be more difficult to work around. In either of these cases, the best long term fix is a new stepping. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
