On Wed, Mar 25, 2015 at 09:25:21PM +0000, Ken Moffat wrote: > On Wed, Mar 25, 2015 at 09:48:58PM +0100, Armin K. wrote: > > On 03/25/2015 09:19 PM, Ken Moffat wrote: > > > > > > For me, the first question is: do we need early microcode loading > > > (for CPU microcode) ? The process looks comlicated, and I did not > > > immediately grok everything. > > > > I believe that I read somewhere that early microcode loading is the only way > > to get it to load on some (or all) Haswell CPU's due to some issue occouring > > when using the "normal" microcode loading method. > > > OK. I suggest that we deal with those separately within intel > (unless and until CPU microcode has to be loaded early). > This is probably the 'Haswell TSX' issue : (applies to Haswell and Broadwell) - according to http://www.pcworld.com/article/2464880/intel-finds-specialized-tsx-enterprise-bug-on-haswell-broadwell-cpus.html only some i5 and i7 processors have the feature, on later steppings it is apparently already turned off.
According to the comment from 'cesarb' in https://lwn.net/Articles/632687/ the C library (which is vulnerable to this particular erratum in current glibc, according to what google found) has already been loaded by the time late microcode is loaded. That matches the dmesg output on the AMD system I'm currently using (no microcode updates for this one) where the lines before the first mention of microcode show the kernel freeing unused kernel memory and then starting udevd, by which stage glibc must have been loaded. ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
