Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Intel Bug Hardware

Errata Prompts Intel To Disable TSX In Haswell, Early Broadwell CPUs 131

Posted by Soulskill from the somebody-is-getting-fired dept.
Dr. Damage writes: The TSX instructions built into Intel's Haswell CPU cores haven't become widely used by everyday software just yet, but they promise to make certain types of multithreaded applications run much faster than they can today. Some of the savviest software developers are likely building TSX-enabled software right about now. Unfortunately, that work may have to come to a halt, thanks to a bug—or "errata," as Intel prefers to call them—in Haswell's TSX implementation that can cause critical software failures. To work around the problem, Intel will disable TSX via microcode in its current CPUs — and in early Broadwell processors, as well.
This discussion has been archived. No new comments can be posted.

Errata Prompts Intel To Disable TSX In Haswell, Early Broadwell CPUs More

Errata Prompts Intel To Disable TSX In Haswell, Early Broadwell CPUs

Comments Filter:

  • Not all that surprising... (Score:5, Interesting)

    by K. S. Kyosuke ( 729550 ) on Tuesday August 12, 2014 @02:18PM (#47657287)
    So, basically, they've just been forced to get rid of the most complex (that's why it's not all that surprising) yet also most beneficial feature with regards to server loads? I'm sure there are some Opterons laughing right now.
    • What of the folks that purchased these chips for these specific instructions? Surely many optimization experts (...assembler gurus) are going to feel quite burned...

      • Re:Not all that surprising... (Score:5, Funny)

        by gstoddart ( 321705 ) on Tuesday August 12, 2014 @02:28PM (#47657373) Homepage

        What of the folks that purchased these chips for these specific instructions?

        Same as happens to all early adopters -- the feature may or may not work, and even if it does, there's no guarantee it will be supported (or the same) in the next version.

        This is a pretty big 'errata', which is an awesome marketing speak for "really bad QA".

        Engineers Release Really Awful Tech. Awesome!

      • I almost became one of those people, that's why I'm mentioning it.

      • Re: (Score:1)

        by crbowman ( 7970 )

        Suppose I bought chips specifically for this feature and now you've disabled that feature in firmware. Can you say class action law suit?

      • Re: (Score:3)

        by AmiMoJo ( 196126 ) *

        The law in most European countries requires that defective products be replaced. If a feature was advertised but doesn't work the vendor (not the manufacturer) can either replace it with one that does work or give a refund. The refund can either but full or partial, negotiated with the buyer and depending on how useful the product is without that feature.

        If I had one of these chips I'd be looking for a full refund or replacement with a fixed version as soon as a fix was available.

    • Re: (Score:2)

      by Predius ( 560344 )

      A feature that has yet to appear in the Xeon line, and Intel claims to already have a fix to bake into the next steppings so... Opterons can go back to being scared of the future.

      • Except thar even if the future Xeons with this are going to work, on what machines are developers going to develop the software for them in advance? That's just awesome, isn't it?

        • Uh.. given that sort of standard, no Android application has ever been developed since the x86 PCs that are used to develop 100% of Android applications lack practically all features of the ARM SoCs that run those applications (the only exceptions being the newer Baytrail Android tablets that are also x86).

          Also: There's a space of about a million miles between "TSX ALWAYS FAILS EVERY SINGLE TIME NO EXCEPTIONS AND CAN NEVER BE USED EVAR!!" with "Oh, we found through extensive testing that under certain con

          • Except that at least the Android SDK provides you with a reasonable substitute, and given the performance ratio between a developer box and the typical target machine, simulation with dynamic translation is bearable for the purpose. I just can't see reasonably testing and tuning large TSX apps (which is to say all TSX apps you can expect) on any sort of simulation. There's a reason why they put a transactional memory controller into those chips. Now it turns out some people who bought it for that reason hav

            • Re:Not all that surprising... (Score:5, Insightful)

              by CajunArson ( 465943 ) on Tuesday August 12, 2014 @04:54PM (#47658559) Journal

              Nobody has been robbed.
              TSX today works exactly as well as TSX worked yesterday, and considering that Haswell has been on the market for over 1 year, I assure you that anybody who has been chomping at the bit to use TSX has been using TSX.

              If the TSX erratum were trivially easy to trigger, then this article would have been posted last spring before Haswell even launched.

              Intel has done the responsible thing by acknowledging the bug (trust me son, AMD & Nvidia often don't bother with that part of the process) and giving developers the OPTION to either use TSX as-is or disable it to ensure that it cannot cause instability no matter what weird operating conditions can occur.

              Tell ya what, why don't you take all your nerd-rage over to AMD or ARM where they won't rob you of all kinds of advanced features that they just don't bother to implement at all.

      • Re: (Score:2, Informative)

        by Anonymous Coward

        Huh? TSX shipped with Xeon-E3 v3 CPUs. I bought one LAST YEAR so I could play around with TSX.

        Note the RTM at the end of the flags. That signals support for the new TSX instructions. RTM means "Restricted Transactional Memory", as opposed to the other half of TSX, HLE, which is a backwards compatible change in semantics.

        $ cat /proc/cpuinfo | head -n25
        processor : 0
        vendor_id : GenuineIntel
        cpu family : 6
        model : 60
        model name : Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz
        stepping : 3
        microcode

    • Considering that even with TSX disabled, the chips will still perform above and beyond a comparable AMD CPU in almost every way, I doubt anyone other than fanboys are laughing.

      • 1: There are no comparable AMD CPUs to i7-anything.

        2: Where AMD do compete (down at i5 level) they're significantly cheaper.

        3: Horses for courses. Unless you've been optimising for TSX it doesn't matter.

    • Re:Not all that surprising... (Score:5, Informative)

      by gman003 ( 1693318 ) on Tuesday August 12, 2014 @03:05PM (#47657651)

      I'm sure there are some Opterons laughing right now.

      Yes, but some of them take a while to get the joke because their TLB had to be disabled.

      (Certain releases of the "Barcelona" Opterons had a bug that could lock up the system. A workaround would prevent it, but had a stiff performance penalty. Later steppings had it fixed.)

    • They were going to get together and laugh about it, but turned up to the wrong address.

      According to AMD, "a very specific sequence of consecutive back-to-back pops and (near) return instructions, can create a condition where the process or incorrectly updates the stack pointer"

      • You can easily avoid that issue by not generating code like that. A simple compiler update resolves the issue. The same kind of fix won't work for suddenly missing memory transactions, though.

        • Re: (Score:2)

          by fnj ( 64210 )

          Sorry to say, I flat out don't believe you.

          • What is there not to believe? If memory transactions (for any random programming language) were implementable by a compiler fix, why did Intel bother to add all that complex circuitry? Perhaps you could point it out to them how to do it.

        • There's all these issues too.. http://support.amd.com/TechDoc... [amd.com]

          And these ones http://support.amd.com/TechDoc... [amd.com]

          And these http://support.amd.com/TechDoc... [amd.com]

          Any probably many more, but these are just the first 3 Google hits

          All chip manufactures have problems with their chips, Opterons are no exception.

        • Possibly, although the described sequence sounds exactly like what happens in a ROP attach. In this case, giving the attacker the opportunity to incorrectly update the stack pointer may make the attack easier.
          • Doesn't using a method that appears to behave in a non-deterministic way seem to make the exploiter's job harder, rather than easier?
            • If it's nondeterministic, yes. If it's 'you can change the stack pointer in this way with this sequence of instructions' then it may be easier.

    • Re:Not all that surprising... (Score:4, Informative)

      by Sun ( 104778 ) on Tuesday August 12, 2014 @10:56PM (#47660269) Homepage

      I have a firend who came to me, eyes all glowing, about this new feature his shining new CPU has. I listened in and was skeptical.

      He then tried, for over a month, to get this feature to produce better results than traditional synchronization methods. This included a lot of dead ends due to simple misunderstandings (try to debug your transation by adding prints: no good - a system call is guaranteed to cancel the transaction).

      We had, for example, a lot of hard times getting proper benchmarks for the feature. Most actual use cases include a relatively low contention rate. Producing a benchmark that will have low contention on the one hand, but allow you to actually test how efficient a synchronized algorhtm is on the other is not an easy task.

      After a lot of going back and forth, as well as some nagging to people at Intel (who, suprisingly, answered him), he came across the following conclusion (shared with others):
      Many times a traditional mutex will, actually, be faster. Other times, it might be possible to gain a few extra nanoseconds using transactions, but the speed difference is, by no means, mind blowing. Either way, the amount you pay in code complexity (i.e. bugs) and reduced abstraction hardly seems worth it.

      At least as it is implemented right now (but I, personally, fail to see how this changes in the future. Then again, I have been known to miss things in the past), the speed difference isn't going to be mind blowing.

      Shachar

      • Re:Not all that surprising... (Score:4, Informative)

        by TheRaven64 ( 641858 ) on Wednesday August 13, 2014 @04:02AM (#47661311) Journal

        It depends a lot on the data structures. There were a number of papers using TSX at EuroSys this year. The main conclusion was that TSX lets you get similar performance from simple approaches as you can get already from complex approaches. For example, you can protect a long linked list in a single lock and use HLE to get a big speedup with lots of concurrent insertions and accesses, but you can achieve similar performance with a fine-grained locking scheme. There was a nice paper about Cuckoo hashing where they initially found that TSX gave them a performance win, but then were able to get a similar speedup without it.

        The big win with TSX is that it's pretty easy to reason about coarse-grained locking and much harder to reason about fine-grained locking. If you can make coarse-grained locking almost as fast as fine-grained, then that's a huge saving on testing and debugging time.

      • I thought TSX would work best with zero contention? You execute code that supposedly does a transactional operation, but because of a prefix code it doesn't actually do anything transactional - unless things go wrong, it rolls back what it has done, and does the same code properly transactional.

        So when there is no contention (which is most of the time), that's when TSX is most efficient. An example would be the gcc library std::string code. std::string doesn't need to be thread safe, but gcc's implementa
      • It has always been my understanding that HTM may not necessarily increase execution performance (outright), but always offers one huge win in terms of operation composability, which is something that individual locks are never going to have. In other words, even if it doesn't make identical programs faster, it ought to make the programming process faster, which is what modern programming seems to be about. An interesting question is what percentage of performance increase can one expect from significant res

  • Well, we call them... (Score:3, Funny)

    by ThatsDrDangerToYou ( 3480047 ) on Tuesday August 12, 2014 @02:22PM (#47657317)
    "Featurata"

  • Can I have a refund? (Score:2, Informative)

    by Anonymous Coward

    In some countries I would be entitled to get the product that was advertised or get a refund.

  • a bug != errata (Score:4, Insightful)

    by Ecuador ( 740021 ) on Tuesday August 12, 2014 @02:25PM (#47657339) Homepage
    You either say "bugs - or errata" or "a bug - or erratum", since bug is singular and errata plural. At least the error - or "erratum" (see what I did here) in this case was in TFA and not introduced in the /. summary.

    • Re: (Score:2)

      by tepples ( 727027 )
      "A notice of errata", on the other hand, is singular.

  • The only reason I got a 4770 instead of a 4770K was to play with this instruction in assembler code. To me this sounds like a reason for a partial reimbursement or a fixed chip, not just a BS "fix" that disables the whole feature.

    • Re: (Score:3, Informative)

      by CajunArson ( 465943 )

      You can still "play with this instruction" all you want.

      What happened here is that a third party developer managed to uncover a corner case where certain interactions with TSX can lead to instability. In order to be safe, Intel acknowledged the bug (a refreshing response) and is now giving you the OPTION to disable TSX if you feel that it could impinge the stability of a production load.

      So basically: Go ahead and play with TSX all you want, but be aware of the errata and that it's theoretically possible to

    • Re: (Score:1)

      by Anonymous Coward

      If broken interrupt remapping on the 55xx chipset does not qualifty for a new stepping and recall, why the hell do you think TSX would?

      Without interrupt remapping, the IOMMU is so severely crippled that you lose any protection it could give you against malicious attacks between VMs over PCI. It still provides isolation, but it is badly crippled and trivial to bypass.

  • It would have been nice if TFA had told us what chips were affected, or how to determine that, rather than saying "haswell" and expecting everybody reading it to do their own research.

    I just spent ten minutes looking around the web, trying to determine if the processor in my laptop is one of those affected - preperatory to perhaps trying to figure out, if it is, how to apply the "disable the broken feature" fix - without installing windows - to avoid the memory corruption bogyman if somebody distributes software that uses, or abuses the feature.

    No joy. The documentation seems to say that:
      - Core i7 is Haswell
      - TSX is NOT supported on versions up to somethng BEFORE the processor version in my laptop (i7-4700MQ)
      - But the descriptions of that processor I've found so far don't say, one way or another, whether it does or doesn't have TSX. B-b

    The "flags" field in /proc/cpuinfo doesn't include a "tsx". But would it?

    Can anyone tell us a simple way to check?

    • Re: (Score:2)

      by heezer7 ( 708308 )
      Check the Intel ARK page for your model number Ex: http://ark.intel.com/products/... [intel.com]

    • Re: (Score:1)

      by Anonymous Coward

      If you have never updated your firmware, then you don't have to apply a fix.
      I think the fix is only for people who update their firmware constantly.

    • Can anyone tell us a simple way to check?
      Intel has on their website info on the processors.
      For example, for yours (i7-4700mq) you would look at:

      http://ark.intel.com/products/75117/Intel-Core-i7-4700MQ-Processor-6M-Cache-up-to-3_40-GHz [intel.com]

      Or you can look for all products that were "formerly haswell":
      http://ark.intel.com/products/codename/42174/Haswell#@All [intel.com]

      how to apply the "disable the broken feature" fix - without installing windows

      I would do some searches for updating BIOS from linux - ex:
      https://wiki.archlinu

    • Re: (Score:3, Informative)

      by Anonymous Coward

      Wikipedia has very detailed information on Intel processors. This page [wikipedia.org] does not list TSX for your processor and does list it for others.

      Most Linux distros automatically handle Intel microcode patches (which I assume is how this errata will be handled). See Debian wiki [debian.org] or Arch wiki [archlinux.org] for details.

    • ARK is your friend if you don't have the CPU. dmesg, kernel boot showing feature flags, or CPU-id or whatever the windows app is will all tell you what your CPU supports.

      Your Linux box will probably just have an update with new microcode for the issue and you'll never need to know anything about it, or it will fiddle with the cpu flags to show it as disabled anyway.

      Basically 'if you don't know, it doesn't affect you'

    • Honestly, if you're asking, it probably doesn't affect you. This really only affects a tiny percentage of users, who are specifically coding with feature.

    • If you have a recent version of the cpuid tool, you can run:

      cpuid |grep RTM

      and you'll see something like:

      RTM: restricted transactional memory = false
      RTM: restricted transactional memory = false
      RTM: restricted transactional memory = false
      RTM: restricted transactional memory = false

      /proc/cpuinfo doesn't show it, presumably because no kernel support is needed at all for this feature. (And that's why, if this is indeed a privilege escalation issue, it won't be e

  • If anyone can tell, it's ' Intel '.

  • Are there any actual details of how the bug works?

  • Problem and possible alternatives (Score:5, Informative)

    by enriquevagu ( 1026480 ) on Tuesday August 12, 2014 @07:28PM (#47659461)

    This is a real pity for the TM community. This is not the first chip with transactional memory support in hardware: The Sun Rock [wikipedia.org] was announced to have hardware TM support, and the IBM Blue Gene/Q Compute chip [wikipedia.org] also supports it. Unlike other proposals for unbounded transactional memory [berkeley.edu], all these systems employ Hybrid Transactional Memory (ref [cs.sfu.ca], ref [unine.ch], ref [auckland.ac.nz]), in which restricted hardware transactions are designed to correctly coexist with unbounded software transactions, so a software transaction can be started in case a hardware transaction fails for some unavoidable issue (such as lack of cache size or associativity to hold speculative data from the transaction, not because of a conflict). Note that, in any case, very large transactions should arguably be very uncommon, since they would significantly reduce performance (similar to very large critical sections protected by locks).

    The problem with the hardware implementation of transactional memory is that they are not simply a new set of instructions which are independent from the rest of the processor. HTM implies multiple aspects, including multiversioning caching for speculative data; allowing for the commit of speculative (transactional) instructions, which could be later rolled back (note that in any other speculative operation such as instructions after branch prediction, the speculation is always resolved before instruction commits because the branch commits earlier); a tight integration with the coherence protocol (see LogTM-SE [wisc.edu] for an alternative to this very last issue, but still...); a mechanism to support atomic commits in presence of coherence invalidations... From the point of view of processor verification, this is a complete nightmare because these new "extensions" basically impact the complete processor pipeline and coherence protocol, and verifying that every single instruction and data structure behaves as expected in isolation does not guarantee that they will operate correctly in presence of multiple transactions (and non-transactional conflicting code) in multiple cores. There are some formal studies such as this [nyu.edu] or this [cs.sfu.ca], and the IBM people discuss the verification of their Blue Gene TM system in this paper [acm.org] (paywalled).

    As some others commented before, the nature of the "bug" has not been disclosed. However, since it seems to be easy to reproduce systematically, I would expect it to be related to incorrect speculative data handling in a single transaction (or something similar), rather than races between multiple transactions.

    Regarding the alternatives, Intel cannot simply remove these instructions opcodes because previous code would fail. I assume that the patch will make all hardware transactions fail on startup, with an specific error (EAX bit 1 indicates if the transaction can succeed on a retry; setting this flag to 0 should trigger a software transaction). In such case, execution continues at the fallback routine indicated in the XBEGIN instruction, which should begin a software transaction. Effectively, this will be similar to a software TM (STM) with additional overheads (starting the hardware transaction and aborting it; detecting conflicts with nonexistent hardware transactions) that would make it slower than a pure STM implementation.

    • Regarding the alternatives, Intel cannot simply remove these instructions opcodes because previous code would fail. I assume that the patch will make all hardware transactions fail on startup, with an specific error (EAX bit 1 indicates if the transaction can succeed on a retry; setting this flag to 0 should trigger a software transaction). In such case, execution continues at the fallback routine indicated in the XBEGIN instruction, which should begin a software transaction. Effectively, this will be similar to a software TM (STM) with additional overheads (starting the hardware transaction and aborting it; detecting conflicts with nonexistent hardware transactions) that would make it slower than a pure STM implementation.

      This seems unlikely to me. I'd expect that the patch will clear the cpuid bit for TSX and cause #UD (undefined opcode) on XBEGIN, etc.

  • Look on the bright side... at least it performs addition correctly, I know for fact as I recently upgraded to a Haswell based desktop. This isn't like that other 0.99912656367 time when they had the Pentium FDIV bug.

  • Alternatively, Intel should stop artificially segmenting their product line on every last instruction set extension or feature. ECC and VT-D should be standard features, yet are intentionally crippled on other Intel chips. If I paid extra for a Xeon, then I expect those to work and TSX is no different.

    It is infuriating that developers and users alike must face such a mishmash of arbitrarily enabled functionality just so Intel can extract further profit, even while bragging about their low defect rate on

    • Re: (Score:2)

      by Z00L00K ( 682162 )

      Add to it that it's not obvious in easily accessible documents what the differences are between the processor models aside from cache size and other features that are easy to show to customers but when you have two processors with vastly different price but same basic specs (Clock, Cache, addressable memory) it's hard to understand why one is more expensive than the other.

      • Re: (Score:2)

        by kav2k ( 1545689 )

        ark.intel.com qualifies as "easily accessible", no?

        • Re: (Score:2)

          by Z00L00K ( 682162 )

          Fails in the obvious part, the hard thing is to know that it exists, then it comes down to that the web page doesn't work unless you select Internet Explorer.

          So they could do more on the accessibility of the information. The documentation is also hard to get a grip on unless you read through it before you can decide if it's useful for a specific application or not.

  • This article at least provided more information about the existence of the feature than any release note provided.

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Close