Errata prompts Intel to disable TSX in Haswell, early Broadwell CPUs

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.

I believe my friend David Kanter was first to report this problem via a tweet the other day. Intel revealed the news of the erratum to a group of journalists during briefings in Portland last week. I was among those in attendance and was able to talk with Intel architects about the situation.

The TSX problem was apparently discovered by a software developer outside of Intel, and the company then confirmed the erratum through its own testing. Errata of this magnitude aren't often discovered this late in the life of a CPU core.

As is customary in such cases, Intel has disabled the TSX instructions in current products using a CPU microcode update delivered via new revisions of motherboard firmware. Disabling TSX should ensure stable operation for Haswell CPUs, but those chips will no longer be capable of supporting TSX's features, including hardware lock elision and restricted transactional memory.

Software developers who wish to continue working with TSX will have to avoid updating their systems to newer firmware revisions—and in doing so, they'll retain the risk of TSX-related memory corruption or crashes.

This erratum was evidently discovered quite recently, too late for a fix to be included in the first revision of Intel's upcoming Broadwell Y-series chips. As we reported yesterday, Intel is currently shipping production Broadwell-Y silicon to its customers for use in Core M-based tablets this holiday season. These first production Broadwell chips will also have TSX disabled via microcode.

Intel has a fix in the works for Broadwell's next stepping. We don't yet know when Broadwell production will transition to the new stepping or how prevalent the TSX erratum will be among the first wave of Broadwell-based systems.

Given that most Haswell and all Broadwell CPUs affected are shipping in consumer-class systems, the impact of this TSX snafu ought to be relatively minimal. The obvious initial targets for TSX optimization are server-class applications like transactional database servers. At present, Intel's server-class Xeon lineup relies on the older Ivy Bridge core, which lacks TSX entirely.

Also, because the problem is apparently restricted to the use of TSX instructions, this erratum isn't likely to prompt the sort of dire consequences the TLB erratum in AMD's Barcelona chip did. As we exclusively reported at the time, the Barcelona TLB problem caused AMD to stop the shipment of Opteron processors and issue a performance-impacting microcode patch for consumer Phenom CPUs. By contrast, the most unfortunate impact of this TSX erratum may be to slow the development of TSX-capable software.

Update: An Intel spokesperson has provided TR with a brief statement on the TSX erratum, confirming that Intel has "addressed the issue" and "disabled the TSX feature on affected products." He further stated that Intel is "committed to the feature" over the long run and plans to "re-implement it in future processors."  We have inquired about how the TSX erratum will affect upcoming Haswell-EP-series server CPUs and will post another update if we learn more.

Update II: Intel has gotten back to us with some more information about how the TSX erratum affects its upcoming Xeon CPUs.

The launch of Intel's high-volume Haswell-EP processors is rapidly approaching, and the TSX errata apparently won't delay that product launch. Instead, a spokesperson for the firm informs us that TSX will be available for software developers to enable "for development purposes" on Haswell-EP, so that their code will be "ready for production" once the higher-end Haswell-EX processors arrive at a later date.

In other words, we expect Haswell-EP to ship on schedule with the TSX erratum still etched into its silicon and TSX instructions disabled via a microcode patch. Those who wish to risk working with TSX in Haswell-EP will have the option to enable it via a firmware menu, but Intel recommends waiting for Haswell-EX before using TSX in production systems.

Since the single-socket, enthusiast-oriented Haswell-E processors are based on the same silicon as the lower-end Xeon EP parts, I'd expect the upcoming Core i7 Extreme CPUs to have TSX disabled in microcode, as well.

Intel will surely issue new steppings of its production Haswell processors with the TSX erratum fully corrected in hardware, but the firm hasn't stated any timetables for the delivery of revised chips.

Update III: Intel has published a specification update (PDF) documenting the TSX erratum. Here's the brief description of the problem that it offers.

A bit later, the document says:

Due to Erratum HSw136, TSX instructions are disabled and are only supported for software development. See your Intel representative for details.

That's all we know at present.

Comments closed
    • Sahrin
    • 5 years ago

    This is on top of the annoying USB bug. Not that I don’t like my 4770K, but it seems like this is the worst Intel core since Prescott.

      • NeelyCam
      • 5 years ago

      What USB bug..?

        • exilon
        • 5 years ago

        The one on the [i<]chipset[/i<] where if you leave certain brands of USB drives connected while coming out of standby, it will disconnect and reconnect. That can cause programs to think that the file disappeared.

    • ronch
    • 5 years ago

    Does TSX still work OK when running 3DNow! code?

    • edwpang
    • 5 years ago

    The bug was found after a year Haswell was released, and probably 2 + years of INTEL test and verification. This probably means it happens very rarely, and shouldn’t be cause of concern for us [b<]consumers[/b<] even if it's NOT disabled. Edited: I meant consumer not customer.

      • chuckula
      • 5 years ago

      Would I trust my safety-critical control system to run TSX instructions? Nope.*
      Is TSX still perfectly fine to use for development and experimentation? Sure. Of course, how much value TSX provides is up for debate, but you can use it on an ordinary machine and the world will not end.

      * But then again, those systems typically aren’t running on x86-consumer hardware and have redundancies anyway.

      • exilon
      • 5 years ago

      That’s not going to stop AMD users from complaining about losing a feature that they can’t use, on a line of CPUs they don’t own.

    • shaurz
    • 5 years ago

    Transactional memory is hard to get right, I can probably forgive them the once.

    • ptsant
    • 5 years ago

    I was tempted by the idea of a Haswell-E Xeon for work, but I think it will have to wait a little bit. Maybe DDR4 will also come to reasonable price levels at the same time.

    I was a bit surprised to see the number of errors in the documentation. Although most are quite esoteric and unimportant, it is a bit annoying to see such a number of errors in a new processor family like the Haswell. I also had a look at the AMD product revision documents. It appears that the Vishera core (FX-8350) has relatively few bugs so that was a bit reassuring.

      • ronch
      • 5 years ago

      As fast and well-received as the Core 2 is, it seems to have a lot of bugs, and it wouldn’t surprise me if its descendants all the way to Haswell (yes, SB only eschews the P6 entirely but it has a lot of things in common with Core 2 and Nehalem) are still riddled with more than the usual number of bugs in processors of this kind of complexity. Apart from Barcelona which AMD was able to catch right away, I would think AMD processors also contain relatively fewer bugs. Some people also say AMD processors are more reliable, assuming external factors are taken out (cooling, faulty VRMs, etc.).

        • barich
        • 5 years ago

        [citation needed]

          • ronch
          • 5 years ago

          What is this, Wikipedia? We’re just discussing, dude.

            • nanoflower
            • 5 years ago

            Well you’ve stated your opinion so it would be nice to have some data to back it up because I (and likely others) think differently. I expect both companies (and ARM) have lots of errata over the lifespan of any of their chips. That’s in the nature of something as complex as a modern CPU and for the most it doesn’t impact the majority of users because the problems are in seldom used areas or there are work arounds that don’t significantly impact performance. Without hard data on the number of errata for a given comparison of CPUs or data on a significant number of computers reliability using a given set of CPUs it will always be just an opinion. It may be backed up by your experience but that’s just like with HDs were some people swear by Seagate and others swear at Seagate because of their experiences.

            • ronch
            • 5 years ago

            If you read my post in response to ptsant I DID imply that all CPUs do have bugs. Yes, I am aware that’s normal. However, sometimes a chip has more bugs than normal. Here, check this out:

            [url<]http://www.pcmag.com/article2/0,2817,2152622,00.asp[/url<] As for reliability, I cannot cite online sources. I got the impression by talking to people.

            • ptsant
            • 5 years ago

            It is easy to find out the errata for both Intel and AMD cpus. The document for the FX-8350, that I own, is the revision guide for familh 15h 00h. Similarly, the Intel document has been cited in the article.

            Obviously, one can imagine that AMD CPUs have many bugs that are poorly documented, or conversely that AMD CPUs are intrinsically less buggy. Furthermore, a single show-stopper bug (like Intel fdiv or the Phenom TLB bug) is much more serious than several rare race condition involving esoteric instructions, which is what most errata are about.

            In the end, the fact that the FX-8350 from 2012 has few errata reassures me. Few bugs are expected to crop-up now. However, if I’m about to pay serious money for the Haswell-E Xeon, which looks like it’s going to be a great CPU, I’d want the TSX thing fixed. Even if I don’t have an immediate use case for that feature.

    • ronch
    • 5 years ago

    Well, I’m glad I got an AMD processor and so I’m not affected by this issue at all! 😛

    • LoneWolf15
    • 5 years ago

    I don’t know about everyone else, but when I buy a new processor, a lot of my purchase is based on features. I use Intel’s ARK website to look at what gets added from generation to generation before I buy; it’s more than a clock speed increase or a die process shrink.

    I bought a Devil’s Canyon because I’d get VT-d. And AVX2 instructions. And TSX. And it’s highly disappointing that a feature that maybe I don’t use yet, but purchased a product because of, will be gone. To me, Intel just sweeping it under the rug is kind of like what nVidia did when a number of generations of video card or chipset became buggy (Geforce 6800 +PureVideo, nForce 3 and hardware firewall, etc.). Promise one thing and when a problem arrives, take the feature away and hope nobody bitches loud enough to make it a problem for your company. Highly disappointing.

      • ronch
      • 5 years ago

      That’s right. Advertise a product as having a certain feature and oops… sorry, we found a problem with it so we’re just gonna disable it. Do you have a problem with that? Then go get AMD.

      I just hope other companies don’t use this as an example of how to deal with things like this in the future. It could get ugly.

      • Bauxite
      • 5 years ago

      ARK is notoriously bad about having proper documentation, they occasionally mess up basic facts from time to time and silently correct it weeks or months later.

      Two big ones I encountered were various Ivy Bridge E cpus listed as having TSX-NI for awhile, and had wrong GPUs listed for some E3 V2 xeons for months. You can probably dig the former out of google cache, I printed out the latter a few years back as I actually bought some affected models.

      BTW, has anyone actually tested DC as having working VT-d? Not just enabling in the bios, but actually installing ESXi and using it with a passed through card. When I first saw the info I assumed it was Yet Another ARK Screwup, caveat emptor.

        • ronch
        • 5 years ago

        Well, ARK is certainly a lot more reliable than AMD’s tables. I remember looking up a Phenom II X4 SKU and it says the L2 cache is 512KB. 512KB for the entire chip or 4 x 512KB? It’s like AMD hired a bunch of low-rent devs in Asia to produce their website, I’m telling you.

        • Forge
        • 5 years ago

        They are real and they are spectacular.

        I don’t use it often, but I ran up a nested ESXi config on my main machine right after I got my 4790K, with PCIe NICs passed through to different VMs. It was pretty excellent, I’m hopeful that VMware Workstation will add support some day, it could be really epic.

    • Krogoth
    • 5 years ago

    Intel is trying to avoid another FDIV debacle. This is a non-issue for 95%+ of the Haswell userbase and for its product lifespan.

    • PHGamer
    • 5 years ago

    wouldn’t making sure not to update the bios allow you to still use TSX?

      • chuckula
      • 5 years ago

      Yes, but most firmware will still give you the option to re-enable TSX even after it is turned off by default.

    • UnfriendlyFire
    • 5 years ago

    In 2008, Autodesk required SSE2 compatibility in order to run Inventor.

    SSE2 was first introduced with the Willamette Pentium 4s back in 2001. [url<]http://knowledge.autodesk.com/support/inventor-products/troubleshooting/caas/sfdcarticles/sfdcarticles/Failure-to-initialize-SSE2-instruction-sets-missing.html[/url<] If someone was using a sub 2.0 GHz Pentium 4 for 3D engineering design and simulation, then I wonder how did they get the money to buy such an expensive license and yet not have enough to replace their computer. Moral of the story, don't expect brand-new stuff to be immediately used. I recall someone was talking about how AVX2 and the upcoming AVX-512 was going to smash AMD's face in, and someone else talking about how HSA+Mantle was going to smash Intel's face in. I laughed at both of them. EDIT: Granted, this bug reminds me of Sandy Bridge's SATA3 problem and how long-term usage would cause the SATA3 controller to progressively lose bandwidth.

    • moose17145
    • 5 years ago

    As much as this sucks… cause it does… I hate to say it… But honestly I am kind of impressed this sort of thing does not happen more often. These chips from Intel, AMD, NVidia, ARM, etc… they are honestly complex enough that I am often shocked they work at all let alone work as well and flawlessly as they do as often as they do. That being said computers are still new… we are bound to have some growing pains. I mean I am just saying computers as we know them have been around less than a 100 years. That is a pretty short time frame to have come as far as we have with them when you think about it… so as good as we think we are at this whole building technology thing, mistakes still happen.

    • barich
    • 5 years ago

    A recall probably isn’t necessary but they should offer some sort of rebate or exchange program for people who will actually be affected by this. If you were a developer and bought a Haswell-based system specifically to write software that uses those instructions I think you’d rightfully expect something from Intel.

    • ludi
    • 5 years ago

    Show of hands: who else read the headline and envisioned Intel wrecking an Acura?

    • USAFTW
    • 5 years ago

    How about enabling unlocked multiplier through the microcode update for those consumers who had to compromise between having TSX and being able to overclock? That could soften the blow wouldn’t it?

      • chuckula
      • 5 years ago

      Can’t be done. The multiplier is blocked out physically through cuts to on-chip components that would enable an adjustable multiplier. Otherwise there could be (and would be) unlock microcodes floating around on the interwebs that would let you unlock regular chips.

      This microcode update is just artificially turning off TSX and of course you have the option of not applying the microcode and leaving it turned on (for better or worse).

        • xeridea
        • 5 years ago

        Yeah, CPUs and GPUs were in the past often locked with softlocks or bios, but they are likely physically disabled now. I don’t know if cores are still bios unlockable, I don’t think so. In the past, if you were really lucky, you could turn your dual or triple core into a quad… possibly stable.

          • derFunkenstein
          • 5 years ago

          I had a Phenom II X2 550 that would unlock to a “Phenom II X4 B50” (weird model number). It was splendid.

          Some Athlon II X4’s were Phenoms with disabled cache that some people successfully unlocked. There were also pencil-trick Socket A Athlons and “golden fingers” Slot A Athlons. Then you’re getting to the era of fully unlocked CPUs where Intel and AMD trusted people with DIP switches to not sell them in sneaky-overclocked systems. Allegedly that practice is why CPUs got locked.

        • ronch
        • 5 years ago

        Unless you delid your chips and found some little dots on the packaging and do the pencil trick.

      • Kurotetsu
      • 5 years ago

      [quote=”USAFTW”<]--for those consumers who had to compromise between having TSX and being able to overclock?[/quote<] They don't exist*. So Intel has no one to appease. *[sub<](In real life. I'm certain this won't stop someone from contriving such a user, though)[/sub<]

        • aarongolliver
        • 5 years ago

        Good to know I’m contriving myself then

        • reitzen
        • 5 years ago

        I did exactly this. Bought a 4770 because I thought there’d be some interesting alpha ports of software that used TSX, though this hasn’t materialized (software transactional memory is heating up on the other hand). My last CPU was a 2600k.

        FWIW, I’d suggest that this was not at all uncommon among enthusiasts that are also programmers.

          • Heighnub
          • 5 years ago

          I did exactly the same thing

    • maxxcool
    • 5 years ago

    Nice fail … what is this 1994 !?

    • S_D
    • 5 years ago

    Interestingly TSX isn’t available on the 4770k anyway, so a lot of us aren’t missing out…

      • Kougar
      • 5 years ago

      It is/was available on the 4790K though…

    • Bauxite
    • 5 years ago

    [quote<]At present, Intel's server-class Xeon lineup relies on the older Ivy Bridge core, which lacks TSX entirely.[/quote<] E3 v3 Xeons are LGA 1150 haswell and have been shipping for awhile in quite a few single socket servers, they are faster (and way cheaper per Ghz) than E5/E7 for single threaded code.

    • chuckula
    • 5 years ago

    Interesting… I’d be curious to see how the bug is triggered. Part of the problem with new features that get added into CPUs is that many of them are rather esoteric and are not widely used or tested.

      • mczak
      • 5 years ago

      FWIW the bug is documented already:
      [url<]http://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200v3-spec-update.html[/url<] Doesn't say anything though how it can be triggered (Errata HSW 136, Spec Change HSW 1). "Under a complex set of internal timing conditions and system events, software using the Intel TSX (Transactional Synchronization Extensions) instructions may result in unpredictable system behavior." "Due to Erratum HSw136, TSX instructions are disabled and are only supported for software development. See your Intel representative for details."

        • chuckula
        • 5 years ago

        That sort of language makes it sound like some sort of nasty race condition. The Heisenbugs are always the hardest to spot & fix.

    • MetricT
    • 5 years ago

    Does anyone know if this errata applies to Haswell-E? We’ve actually been chomping at the bit for a TSX-capable Xeon for development at work. We develop a parallel filesystem that can scale to 1000’s of threads per server and considered TSX a key requirement for our next generation of hardware.

      • chuckula
      • 5 years ago

      That’s of interest because a feature like TSX becomes more interesting in highly parallel workloads that run on higher-core count parts. Something tells me that if this bug is truly a new discovery, then the first versions of Haswell-E will be vulnerable. A later stepping could conceivably fix the problem.

      • the
      • 5 years ago

      [s<]Considering that Haswell-E launch is a month away, it'll be affected. The more open question is Haswell-EX for the larger multi-socket systems. It is due in the beginning of 2015 so there is time to address this errata on that chip. While the launch is ~6 months away, I'd be nice to hear some confirmation form Intel if the EX is affected. I'd guestimate that Broadwell-E and Broadwell-EX will not have this bug as they're at least a year away.[/s<] Article update clarified all this.

      • Damage
      • 5 years ago

      I’ve added an update to the article addressing your question. Looks like Haswell-EP (and likely -E) will be affected, but the problem will be resolved before Haswell-EX hardware ships.

        • MetricT
        • 5 years ago

        Does Intel have any further information on the nature of the errata? Is it a bug that could be triggered reasonably often? Or one of those “once in a blue moon” things that requires your heat sink fan to be in resonance with Jupiter while the moon is full?

          • moose17145
          • 5 years ago

          ^^^ This

          • ronch
          • 5 years ago

          As long as Enceladus isn’t blocking Saturn and Pluto isn’t in the constellation Virgo, you’ll be just fine.

    • DPete27
    • 5 years ago

    [quote<]Errata of this magnitude aren't often discovered this late in the life of a CPU core.[/quote<] Possibly because (unfortunately) nobody is paying attention to it because TSX enabled processors are few and far between. Hey Intel, if you want developers to use your great new features, how about enabling it on more than just the multiplier locked i7's.

      • UnfriendlyFire
      • 5 years ago

      But then how would they get people to pay more for “upgraded” CPUs?

      Ex: ECC is supported on i3s and Xeon chips. Not on i5s or i7s.

      • MetricT
      • 5 years ago

      TSX isn’t really necesssary in today’s household apps. Like they said, its current use would be database and other servers that scale to high thread count.

      Intel probably included it on the I7 Haswell to give programmers a head start with it, so that in another tick/tock or two, when consumer chips looks a lot more like Knight’s Landing than Haswell, it will be of more practical benefit.

        • Orwell
        • 5 years ago

        The point is that TSX and other instructions are probably implemented in every shipping Haswell core, or at least the one that share dies (i.e., all i5’s and i7’s in this case).

        Intel basically disables the stuff even if it’s already there using microcode during the binning process.

        In other words, noone benefits from this shady tactic, except Intel. There’s no saving die area or power consumption or anything related.

      • absurdity
      • 5 years ago

      I have to imagine that the multiplier locked chips are by far the majority of their shipments, no?

      • Forge
      • 5 years ago

      My i7-4790K supports TSX.

      Well, it used to, anyways.

    • ronch
    • 5 years ago

    So Intel’s response to folks who have affected chips is… to merely disable TSX functionality through a firmware update and that’s it? No recalls or replacements?

    And people are OK with that? What if you bought a car and the manufacturer said, hey, we found something wrong with the key fob and you guys shouldn’t use it. Don’t worry, you can still use your car just fine and there are no safety concerns… just lay off the key fob.

    I thought Intel was more professional than this.

    Edit – OK, TSX may not be used by 99% of people, but you guys know Intel is the master of product segmentation. TSX is probably included in products that consumers who might care about TSX are likely to buy, and disabled in products that people who wouldn’t care about the feature would buy. So people who bought TSX-enabled SKUs are probably aware of its existence and could have bought the SKU because one of their reasons is TSX. What about this scenario? They just lost a feature they could’ve been wanting. They could be a developer or just someone curious about tinkering with it or someone who just wants to have it in there.

      • Flying Fox
      • 5 years ago

      Ever since FDIV, and more recently the 6-series chipset, Intel is trying really hard not to go the recall route. All sorts of justification will be used to see if they can get away with it. In this case, TSX is really not popular yet (I would imagine most of the software are still in development), and hard to imagine consumer/desktop apps needing to utilize the instructions.

      • Theolendras
      • 5 years ago

      Not realistic, total profit per article sold isn’t the same as a car and is modular per design, not to mention it is a novel and not a killer function and that it’s not prohibited to continue to use it.

      Also it happened quite often that new instructions adoption begin to be revelant only as the first generation is EoL anyway.

      Some sort of rebate could make sense tough.

        • UnfriendlyFire
        • 5 years ago

        “Some sort of rebate could make sense tough.”

        When you have little competition in the desktop/server market, why care about consumer loyalty?

        • w76
        • 5 years ago

        Right, to ronch’s example, this is more the equivalent of the key fob not working — so they replace the ENTIRE CAR. Can’t just replace a few transistors, it’s all or nothing.

        I don’t know, a rebate would be nice, but folks need to be realistic. There’s a risk with every transaction, and just because the vast majority of the time Intel delivers doesn’t mean we’re entitled to a risk-free consumer existence (just as businesses aren’t entitled to a risk-free existence; I mean, I wish I was, looking at my accounts aging reports from some of my customers). Even with this error, we’ve got it pretty good as tech consumers. If one looks at reliability data from other industries, Intel is a rockstar.

        Granted, most other industries produce things with moving parts, which inherently changes the game… but still. Intel is no GM/Ford/Chrysler during the bad ol’ years.

          • mesyn191
          • 5 years ago

          Car manufacturers do recalls all the time without issue for no customer cost.

          • ronch
          • 5 years ago

          Cars are quite a bit different from processors. Unfortunately, with CPUs it’s all or nothing, isn’t it? Replacing the whole chip is painful but what other alternatives are there?

            • mesyn191
            • 5 years ago

            hurr

            • ronch
            • 5 years ago

            As I’ve said, CPUs aren’t quite the same as cars.

            • mesyn191
            • 5 years ago

            durr

            • ronch
            • 5 years ago

            Not sure you are reading my posts right, man. I AM for replacing the CPU. w76 did state that my analogy is like saying the whole car should be replaced, which I countered by saying cars and processors are different. You can replace a part of a car that’s faulty but you can’t do that with CPUs. And if you can’t do that with CPUs, what alternative do you have? Replacement, obviously. Get my drift?

            • mesyn191
            • 5 years ago

            OK you’re right I misread, sorry.

            • ronch
            • 5 years ago

            No problem. Here, let me pour you a drink.

          • Theolendras
          • 5 years ago

          Presicely where you put your foot in the mouth, you don’t replace entire cars for key fob, you replace the keyfob, the faulty sensor or wire.

      • srg86
      • 5 years ago

      Sounds no worse than what AMD did with the TLB erratum. I don’t remember them issuing recalls. The new stepping of the chip had a new product number for the Phenom.

        • hansmuff
        • 5 years ago

        It sounds much better than AMD’s TLB problem, where the patch delivered negative performance impact all around [url<]https://techreport.com/review/13741/phenom-tlb-patch-benchmarked/3[/url<] We don't need TSX in games or applications for the desktop, it's really as simple as that. The impact is zero for all but a few; those few may elect to just not upgrade their BIOS (which is where the CPU microcode patches come from). It's kind of sad if this delays TSX' benefits on server applications, but worse things have happened.

          • derFunkenstein
          • 5 years ago

          Totally agreed. Assuming there are no negative performance impacts (which I’m sure that’s the case) then there’s nothing to see here.

            • mesyn191
            • 5 years ago

            But there is a negative impact. You lose TSX. Hard performance numbers are difficult to come by but generally its thought to be able to improve performance for multiprocessing 10-20% easily. It should make programming for multiprocessor environments easier too.

            Just because its use is widespread yet doesn’t mean there are no negative effects.

            • derFunkenstein
            • 5 years ago

            You lose something you never used so………….?

            • mesyn191
            • 5 years ago

            Just because I’m not using it now doesn’t mean I won’t ever use or want it.

            • Kurotetsu
            • 5 years ago

            [quote=”mesyn191″<]Just because I'm not using it now doesn't mean I won't ever use or want it.[/quote<] And by that time the bug will be fixed. That is unless you plan on never upgrading away from Intel's current generation.

            • tfp
            • 5 years ago

            This features is already disabled on my Q9400!?!?!

            • mesyn191
            • 5 years ago

            Won’t be fixed on the CPU I paid for.

            There is also a significant but hard to quantify market effect to Intel’s actions here.

            I mean what if Intel had a bug requiring a similar treatment (disablement via microcode update) in their SSE2 or x64 implementation on the 1st chips that had those features? It would’ve set back a widespread adoption of those features a fair amount of time easily. Years even.

            Why would you ever give a pass to Intel here anyways? They use their monopoly position (thanks to a lack of competition + dirty tricks to sabotage competitors) to milk the market for money. You owe them no favors or respect.

            • srg86
            • 5 years ago

            err The TLB errata was not fixed on CPUs that people who paid for Phenom chips either, yet you’re going to give AMD a pass on that. In that case they didn’t lose a single feature, but stability of the overall system.

            We’re not giving Intel a pass, we’re just saying that just crying about Intel is hypocritical if you’re not going to include AMD on this.

            I see the AMD fanboys are out in force with this one.

            • mesyn191
            • 5 years ago

            Quote the section where I gave AMD a pass on anything or even mentioned them once.

            The discussion is about Intel’s recent screw up so is it really so unreasonable I’m only talking about Intel here?

            • srg86
            • 5 years ago

            When you start ranting on about monopoly and dirty tricks, it makes it obvious, as it’s only ‘evil Intel’ that would do this, when others have done this as well.

            • mesyn191
            • 5 years ago

            No its not cuz’ none of that gives a AMD a pass on anything.

            You’re interpreting my post to see what you want to see here.

            • hansmuff
            • 5 years ago

            Apples and Oranges.
            SSE2 and x64 both were features a large user base was going to use in games, operating systems and so on.

            TSX is not used anywhere with today’s binaries, except perhaps in academia or very limited commercial software development. Just because you have a TSX feature doesn’t mean it’s used.

            This is an unfortunate setback for this feature, for sure, but again very limited impact. Performance wise, no, you don’t lose 10-20%. You lose nothing unless you fall into the category of folks who write enterprise software or operating systems implementing TSX. And in that case, just don’t update your BIOS.

            Intel gets the pass because of the very limited impact, nothing else.

            • mesyn191
            • 5 years ago

            Who told you TSX won’t be used in games or OS? Both types of software would greatly benefit from better multi processor utilization. Games in particular.

            That TSX doesn’t have widespread use or support now doesn’t matter. It will, or was supposed to, in the future and Intel was quite proud and excited about TSX when it was released. Anything that greatly improves and eases development of multiprocessor software in a many-core/thread future is a pretty big deal.

            Limited impact? All Haswell and some Broadwell CPU’s are effected. Those are the first 2 CPU’s to support TSX, one of which was sold for a fair amount of time on the market! That IS a pretty big deal any which way you look at it.

            • hansmuff
            • 5 years ago

            Games in particular will not greatly or at all benefit from TSX. Multi-threading in games is so limited that it simply will not make a lick of a difference. Software methods of locking resources are not any kind of hindrance in game performance. If you’re very, very lucky you see 4-8 threads in a game, and those aren’t competing for resources they do parallel processing of audio or physics or AI. That’s not a market for TSX.

            And I said nothing about OS never benefiting. If you put TSX/HLE logic into glibc for some subroutines to process locks better, that can help server applications who put huge loads in terms of threaded transactions on the OS, or perhaps web servers responding to as many clients as possible while sharing resources. But again, no current user scenario applies.

            [url<]http://www.extremetech.com/computing/117501-intels-haswell-will-include-new-multi-core-enhancements[/url<]

            • mesyn191
            • 5 years ago

            OK that is the situation now and not in the future though. Games and other software are gradually becoming much more multi processor oriented, its just has taken years to happen.

            Basically in order for your earlier comments to make sense you have give a scenario for why software will either become less multi CPU/thread oriented and show why it is, at least, highly likely if not certain.

            OS’s were one of the examples of widely used software you mentioned that benefited from x64 and SSE2 which was why I also used it as an example. I wasn’t suggesting you were saying OS’s wouldn’t benefit from TSX.

            • hansmuff
            • 5 years ago

            Software will not become less threaded than it’s now, that would not make sense.
            I am saying, as it is now and having had 4C/8T CPUs in the consumer market for a number of years, we have seen performance restrictions in IPC, GPU speed, memory and cache sizes, bus bandwidth in some cases, all that.

            But inefficient multi-threading just doesn’t come up in any application but those I mentioned already. Perhaps something could come along that is greatly complex and massively multithreaded and love TSX, let’s say some sort of new AI for games. That’d be sweet and all but even if TSX wasn’t broken now, the terrible performance on all non-TSX CPUs would make that a non-starter.

            And that’s where I think we intersect; it’s a shame TSX is getting kicked down the road a little just because of this bug. But I maintain, TSX wasn’t even on the K series chips until the 4790, it’s just now starting to fully roll out and that roll-out now is getting delayed. And perhaps in 3 years someone on a Devil’s Crayon sorry I mean Canyon will go berserk because the chip is still awesome and said new AI will suck on it.
            But don’t forget, even that DC user could go into their BIOS and remove the TSX disabling setting; at least that is what Intel is saying so far. And chances are very high that it’ll work just fine.

            The disabling is specifically because TSX is a big deal with server and datacenter software and they can’t afford undefined behavior malfunctions in their environment.

            • mesyn191
            • 5 years ago

            Every time a new CPU feature comes a long the old hardware eventually gets to start looking verrrry slow in comparison but that hasn’t slowed or stopped the adoption of new features at all.

            We don’t actually know if TSX is getting kicked ‘a little down the road’ though. Generally it takes a long time for new features, even highly useful ones, to get widespread acceptance because there has to be enough of them out there for developers to not worry about sales restrictions. A heap of Haswells have been sold for a while now. Its literally the whole market that has been tainted.

            Most people aren’t going to go modifying their own CPU’s microcode or even touch the BIOS either. Developers know that.

          • anubis44
          • 5 years ago

          “Sounds no worse than what AMD did with the TLB erratum”

          “It sounds much better than AMD’s TLB problem”

          In fact, it’s not even a problem at all! Since it’s Intel that did it, it’s actually a feature!

          Nice to see you all climbing over yourselves to excuse Intel’s screw-up. Pathetic.

        • Waco
        • 5 years ago

        …unless you just bought a machine for TSX development and deployment. Then it’s a lot bigger deal than a slower TLB.

      • Kougar
      • 5 years ago

      A recall & replacement isn’t realistic. Given literally 99% of Haswell owners don’t use software that makes use of TSX, a recall isn’t really needed either.

      If Intel offered to replace them they’d have to redesign Haswell, verify the fix works, send it to the fab, then it would take time to produce a sufficiently large quantity of them. The time scales involved would mean you wouldn’t see a replacement anytime this year, probably well into next year depending on how many people requested a replacement. If not closer to 2016 depending on the redesign and verification stages is my guess.

      Now if the bug affects Haswell-E, and it sounds like it does, then that’s a problem. Broadwell is just a consumer chip, but Haswell-E is made into server and enterprise Xeons that actually will be used for TSX. Will be interesting to see how Intel handles that.

        • Vaughn
        • 5 years ago

        “Haswell-E is made into server and enterprise Xeons that actually will be used for TSX. Will be interesting to see how Intel handles that.”

        You have that in the wrong order.

        The chips we get are based on Xeon’s not the other way around.

        But I agree most of the people bitching about this will probably never touch a piece of TSX enable software throughout the life of your build. Its an Enterprise feature enthusiast seem to get confused by that.

      • txgs
      • 5 years ago

      Except that the key fob is a widely used functionality. The TSX thing would be more related to a remote start setup, since it is not as widespread (TSX is probably less widespread on software than remote start is to cars) and it doesnt affect the overall functionality of the vehicle security system, unlike a key fob, where you actually need it to disable the alarm and prevent the car from going into limp mode in modern systems.

      In the same sense, the TSX market is small and doesnt affect the overall functionality of the processor.

      However, considering the nature of a microprocessor, its not as easy as “swap” the problematic part and thats it. So these two examples are not equivalent.

      • Ninjitsu
      • 5 years ago

      TSX was in all i5s and i7s except the K series. Devil’s Canyon brought it to the K series as well.

      Outside of SiSoftware’s Sandra, I personally am not aware of any software that uses it. It may have been an in-development feature, and i guess high profile devs can wait a bit till Haswell-EX is launched.

      Also note that HLE was designed to be ignored by older architectures and only implemented by Haswell, while RTM required TSX to be run at all.

      So in that sense damage is probably even less, though anyone who bought a whole bunch of Haswell chips just for this is probably important enough to Intel to get a free replacement or a discount.

      • derFunkenstein
      • 5 years ago

      Your edit makes sense on the surface, but don’t forget that EVERY locked i3, i5, and i7 has TSX, so I don’t think it’s very likely that there are many affected people. It might a disappointment (or in this case, a sense of schadenfreude for an AMD fanbooiiiii), but what do you want them to do about it?

      • TREE
      • 5 years ago

      Actually in the UK, what Intel has done is breaking trading laws.

      There is a law here that states:

      “If the goods do not conform to the contract, in other words are not of satisfactory quality, fit for purpose or [b<]as described[/b<], you are legally entitled to one of the following remedies: A FULL REFUND REPAIR OR REPLACEMENT RESCISSION (cancelling) OR REDUCTION IN PRICE DAMAGES The law states that a trader's legal responsibility for faulty goods lasts for six years from the date of the contract. This does not mean the goods have to last this length of time, but this is the time limit that the law gives you to take legal action."

      • jss21382
      • 5 years ago

      …You’d be surprised how often that actually happens in the automotive world. Either a feature is disabled due to safety concerns, or replacement parts no longer have the same features as the original due to part consolidation.

    • Forge
    • 5 years ago

    Given my Haswell laptop and Devil’s Canyon desktop, I am less than thrilled to find out that features will be going away, even ones I’m less likely to use. 🙁

      • James296
      • 5 years ago

      hopefully, intel can fix this before Haswell-E ships

        • UnfriendlyFire
        • 5 years ago

        I doubt it. They said that first Broadwell steppings will have the TSX disabled.

          • nanoflower
          • 5 years ago

          Yes, but those are already shipping. Haswell-E hasn’t started shipping yet so there may be enough time to fix it. Unless Intel has hard ship dates for Haswell-E it would be well worth the pain to hold off shipments until they have fixed it since the E class is intended to be the top of the line in performance and features.

            • derFunkenstein
            • 5 years ago

            Haswell-E also seems the most likely candidate for a platform where having TSX actually matters.

            • Vaughn
            • 5 years ago

            This will not be fixed in Haswell E.

            Did you guys skip the second last paragraph.

            • derFunkenstein
            • 5 years ago

            No, it is labeled “update II” – these comments were here before that, and they didn’t delete comments just because they updated the article. Pay attention, son!

      • hansmuff
      • 5 years ago

      I liked that they did not disable it on DC chips, hopefully that holds true for other K series chips going forward. It’s a cool feature.

      • LoneWolf15
      • 5 years ago

      Ditto. I buy CPUs with the featurelist in mind, including my new DC i-4790k.

      • Bauxite
      • 5 years ago

      Well, try buying a couple low power xeons because they don’t supply the desktop versions to any distributors and finding out that half the GPU was disabled and they “forgot” to tell anyone for awhile. Then you would be in my shoes in 2012.

    • Neutronbeam
    • 5 years ago

    Oops! Ah well–let the chips fall where they may!

      • derFunkenstein
      • 5 years ago

      /rimshot

Pin It on Pinterest

Share This