On Thu, 18 Sep 2014 12:14:59 -0700 Andy Lutomirski <l...@amacapital.net> wrote:
> On 09/18/2014 06:52 AM, Henrique de Moraes Holschuh wrote: > > The new Haswell microcode update[1] removes the "hle" (hardware lock > > elision) processor capability. And it is not cosmetic, either: Intel TSX > > opcodes will cause an illegal opcode trap after the microcode update[2]. > > > > This means cpu_info()->x86_capability becomes stale after the microcode > > update. > > > > We could add logic to compute the new x86_capability after a microcode > > update run, and OOPS the kernel if something too important (i.e. anything > > the kernel uses) went away. Otherwise, refresh cpu_info()->x86_capability. > > > > Is that doable? > > > > > > [1] sig 0x000306f2, pf mask 0x6f, 2014-09-03, rev 0x0029, size 28672 > > sig 0x000306c3, pf mask 0x32, 2014-07-03, rev 0x001c, size 21504 > > sig 0x00040651, pf mask 0x72, 2014-07-03, rev 0x001c, size 20480 > > sig 0x00040661, pf mask 0x32, 2014-07-03, rev 0x0012, size 23552 > > This is HSD136, right? Do you have a link to where that ucode comes > from? Does it have release notes? > https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=24290&lang=eng I can't find any release notes. Haswell-EP is also affected, it appears: http://techreport.com/news/26911/errata-prompts-intel-to-disable-tsx-in-haswell-early-broadwell-cpus > > > > [2] instantly segfaulting every running process using libpthread-2.19, > > as well as any other users of Intel TSX. > > https://bugs.launchpad.net/intel/+bug/1370352 > > > > And yes, this means we will kill support for microcode updates > > outside of the initramfs/early-initramfs, at least in Debian, > > and likely in Ubuntu. > > > > Given that there is exactly one microcode update like this (at least of > the sort that blows up userspace), I think that we should seriously > consider blacklisting just this particular microcode update once > userspace is running. > All future updates for these CPUs will have this problem. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
