On Wed, Mar 12, 2014 at 10:07:43PM +0100, Thomas Karmann wrote: > On 12.03.2014 (21:20), Aurelien Jarno wrote: > > While it shows that the problem is at the CPU level, it's not really a > > fix, as the bus is not locked anymore, so it might results in issues in > > multithreaded solution. > > > > The correct solution would be to apply the solution from Intel, that is > > adding a nop before every instruction with the lock prefix. This means > > rebuilding the code. > > Yes, of course! I forgot to mention that I only did this to find the > cause of the bug and to get Debian running somehow on the Galileo-Board. > > To my understanding the lock prefix only makes sense on multi-core > systems, so the impatient (galileo users) should be safe by removing the > prefix at every occurence until a proper fix is implemented?
For Galileo users yes, for Edison ones, no. > About that: /proc/cpuinfo doesn't include a "microcode" entry, so I > wouldn't bet on a quick fix by Intel. I don't know if this feature is > really missing, though. Let's wait a bit to see what happens on the Intel side before trying to workaround that at the package level, especially having a more precise description of which instruction sequence causes the issue in order to not patch every instruction with the lock prefix if not needed. -- Aurelien Jarno GPG: 1024D/F1BCDB73 [email protected] http://www.aurel32.net -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
