Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

Soulskill posted about a month ago | from the somebody-is-getting-fired dept.

Intel 131

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.

cancel ×

131 comments

Sorry! There are no comments related to the filter you selected.

LOL ... Pentium 4? (0)

gstoddart (321705) | about a month ago | (#47657243)

Chips don't add?
Transactions don't sync?
Don't be sad,
don't be a dink.

Burma Shave!!

Not all that surprising... (5, Interesting)

K. S. Kyosuke (729550) | about a month ago | (#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.

Re:Not all that surprising... (2)

Rockoon (1252108) | about a month ago | (#47657321)

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... (5, Funny)

gstoddart (321705) | about a month ago | (#47657373)

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!

Re:Not all that surprising... (2)

mwvdlee (775178) | about a month ago | (#47658649)

CPU's with TSX were first releasing in June 2013. Not really "early adopter" terrain any more.

Re:Not all that surprising... (0)

Anonymous Coward | about a month ago | (#47659121)

Yes, I agree with this. For some applications the microcode update that kills TSX is going to measurably reduce performance.

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

rrohbeck (944847) | about a month ago | (#47661127)

Singular: Erratum
Plural: Errata

Re:Not all that surprising... (2)

K. S. Kyosuke (729550) | about a month ago | (#47657509)

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

Re:Not all that surprising... (0)

Anonymous Coward | about a month ago | (#47657521)

They can not upgrade their drivers, and the chips will continue to work as they do now. Which may be not very well.

Re:Not all that surprising... (0)

Anonymous Coward | about a month ago | (#47657545)

See also Pentium 5 and the FDIV bug. It falls under "too bad, so sad, try your luck with the next revision".

Re:Not all that surprising... (0)

Anonymous Coward | about a month ago | (#47657585)

Except with the FDIV bug, there was a whole body of S/W that quit working
    (unless you were using it for govt work where close is good enough.)

Re:Not all that surprising... (2)

ghettoimp (876408) | about a month ago | (#47659349)

The FDIV bug was actually relatively limited in scope. Quoting Wikipedia [wikipedia.org] , "Though rarely encountered by average users (Byte magazine estimated that 1 in 9 billion floating point divides with random parameters would produce inaccurate results),[3] both the flaw and Intel's initial handling of the matter were heavily criticized. Intel ultimately recalled the defective processors."

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

ShanghaiBill (739463) | about a month ago | (#47657671)

See also Pentium 5 and the FDIV bug. It falls under "too bad, so sad, try your luck with the next revision".

No. Intel offered to replace any P5 with the FDIV bug upon request. Most customers did not request a replacement, but the option was available.

Re:Not all that surprising... (1)

Anonymous Coward | about a month ago | (#47657897)

Only because IBM et al threw up a stink about it, Intel knew about the problem for months before but tried to downplay it. Everybody makes mistakes, fine, but trying to sweep them under the carpet is bad form. At least they're being open about it up-front this time round, there's some solace in the reliability of Intel hardware.

Re:Not all that surprising... (0)

Anonymous Coward | about a month ago | (#47658399)

Yeah, but didn't they downplay it because they believed it wasn't that bad?

Then IBM PR jumped on it?

I think I remember that the common use scenario that would require precision (and really, all it was, was a precision bug) was an iterative use of the instruction. In other words, one run would have incorrect precision, but iterative usage would still converge on the same result.

Does any one really know if this was the case? Isn't 20 year old errata fun?

Re:Not all that surprising... (1)

bill_mcgonigle (4333) | about a month ago | (#47658309)

Intel offered to replace any P5 with the FDIV bug upon request.

Fortunately most of the P5's were socketed with a trivial heatsink. People with i7 48xx and 49xx laptops are going to be caught up in this - those could have been a really nice portable KVM machine with TSX.

Then again, Intel chips are so expensive they must have the cost of a possible recall built into each one.

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

Anonymous Coward | about a month ago | (#47658589)

See also Pentium 5 and the FDIV bug. It falls under "too bad, so sad, try your luck with the next revision".

No. Intel offered to replace any P5 with the FDIV bug upon request. Most customers did not request a replacement, but the option was available.

Not at first they didn't.

My friend was doing his master on neural networks (?) at the time and some of his algorithms were giving back hinky results, especially when he compared them to some of the SPARC systems.

He had to actually provide documentation that it effected him, and I think sign an NDA, before Intel would give him anything. He jumped through their hoops to get a replacement, and then the very next week Intel announced their carte blanche replacement program.

It took much screaming in the industry before Intel became "generous".

Re:Not all that surprising... (0)

Anonymous Coward | about a month ago | (#47658665)

The offer to replace Pentium CPUs with the FDIV bug is still valid, and Intel actually still honors it.

Re:Not all that surprising... (0)

Anonymous Coward | about a month ago | (#47658953)

No. Intel offered to replace any P5 with the FDIV bug upon request. Most customers did not request a replacement, but the option was available.

WE ARE PENTIUM OF BORG
DIVISION IS FUTILE
YOU WILL BE APPROXIMATED.

Re:Not all that surprising... (1)

gl4ss (559668) | about a month ago | (#47660251)

this is the first I hear of the option being available.

point being, back in the p5 days, you would hear the switch possibility pretty late.. and I'm fairly sure the local pc magazines didn't cover the replacement possibility either, not even in the articles discussing the problem and showing how to find out if you had the fault or not.

Re:Not all that surprising... (0)

Anonymous Coward | about a month ago | (#47658563)

These are not the instructions you're interested in. Move along, developer. Move along.

Re:Not all that surprising... (1)

crbowman (7970) | about a month ago | (#47660417)

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:Not all that surprising... (1)

Predius (560344) | about a month ago | (#47657355)

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.

Re:Not all that surprising... (1)

K. S. Kyosuke (729550) | about a month ago | (#47657517)

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?

Re:Not all that surprising... (2)

CajunArson (465943) | about a month ago | (#47658043)

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 conditions TSX can cause issues. Don't use it for your nuclear power plant control system, but it's perfectly fine for non-critical testing. Oh, and just to be safe, we've made a microcode update to disable it."

Re:Not all that surprising... (1)

K. S. Kyosuke (729550) | about a month ago | (#47658489)

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 have been robbed. They must be very happy now.

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

CajunArson (465943) | about a month ago | (#47658559)

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:Not all that surprising... (0)

Anonymous Coward | about a month ago | (#47658643)

It is already in the Xeon line. The question is if it can be fixed in time for the coming Haswell E5s.

Re:Not all that surprising... (2, Informative)

Anonymous Coward | about a month ago | (#47659359)

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 : 0x10
cpu MHz : 800.000
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm
bogomips : 6585.24
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:

Re:Not all that surprising... (0)

BitZtream (692029) | about a month ago | (#47657357)

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.

Re:Not all that surprising... (0)

Anonymous Coward | about a month ago | (#47657441)

Sorry, no current AMD cpus are experiencing errata. Just you boi.

Re:Not all that surprising... (1)

BitZtream (692029) | about a month ago | (#47657881)

... Yes, even in perfect operating condition, they still don't compete with the current line of Intel chips. If you want to argue on price per buzzword, AMD is fine, but they are in no way 'the fastest' x86 chips.

And lets not pretend AMD has never had CPU bugs, even if you're too stupid to know about them.

Re:Not all that surprising... (0)

Anonymous Coward | about a month ago | (#47658513)

Sorry, price per compute you're still being smoked.

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

EvilJoker (192907) | about a month ago | (#47658587)

I know this was a troll, but I feel compelled to reply in case someone doesn't know.

ALL CPUs have errata. Some of it more significant than others.

A quick Google for "AMD errata" revealed Revision Guide for AMD Family 16h Models 00h-0Fh [amd.com] , published June 2013, and applying to AMD's Mobile A,E, and G series, and Opteron X1100/X2100 (These are modern CPUs)

There are 21 entries, with descriptions, system impact, and suggested workaround (if any)

Haswell's errata [intel.com] has 131 entries

Re:Not all that surprising... (1)

Shinobi (19308) | about a month ago | (#47660331)

Based on my experience, due to having learned from the FDIV bug experience, Intel much more readily acknowledge errors than AMD does. There are still some issues where AMD engineers are stonewalling us in regards to cache coherency in NUMA mode, causing major stalls forcing us to have to reset state. (And these are issues that Cray/Silicon Graphics solved in the 90's already...)

Re:Not all that surprising... (0)

Anonymous Coward | about a month ago | (#47658261)

What was that, Mr. Pot?

Re:Not all that surprising... (0)

Anonymous Coward | about a month ago | (#47657429)

Bummer one of the features I was looking forward to in mainstream laptops and desktops. Oh well maybe next cpu.

The big one coming up is the doubling of the integer registers from 16 to 32 in skylake. Which should be interesting in emulation scenarios and code that is kind of knarly.

This should be interesting too.
http://en.wikipedia.org/wiki/Intel_MPX

Re:Not all that surprising... (0)

K. S. Kyosuke (729550) | about a month ago | (#47657547)

Awesome, yet another complicated feature forced by the use of unsafe languages. Isn't that spiffy... (I'd expect errata for that as well.)

Re:Not all that surprising... (2, Insightful)

Anonymous Coward | about a month ago | (#47658323)

I for one , would love to know how your 'safe' language manages to avoid dead locks, priority inversion, race conditions or guarantee lock-free processes on anything more complex than a singly linked list. Please enlighten me, I'm clearly ignorant.

Re:Not all that surprising... (1)

viperidaenz (2515578) | about a month ago | (#47658337)

the language being Intel 64 machine code?

Re:Not all that surprising... (1)

K. S. Kyosuke (729550) | about a month ago | (#47658639)

Quite obviously, C and its derivatives. Given that vector/array size is effectively subsumed by type systems, it's difficult for me to see why a type-safe language and compilation environment would require this kind of feature without the machine providing full typed assembly as its interface, since you can't typecheck just *some* type properties of the program - well, in C, you have to, that's the problem.

Re:Not all that surprising... (1)

thestuckmud (955767) | about a month ago | (#47659907)

Modern type safe languages have a lot going for them, but they don't solve the hard problems of concurrency. (n.b. purely functional languages allow easy parallelization of some mathematical functions, but do not solve the hard problem, either). Highly efficient threading, especially at the system level, is not made easier by type safety.

This instruction set extension offers transactional memory access, so a thread can begin speculative execution that modifies a block of memory, and roll back on a conflict, rather than stalling on a semaphore lock.

Re:Not all that surprising... (1)

viperidaenz (2515578) | about a month ago | (#47661151)

You've got your chicken and egg around the wrong way.
CPU's don't have separate levels of memory that require synchronisation between threads because of C.
Also, TSX also has nothing to do with types.

Any "safe" language that supports multiple threads requires synchronisation even more so than a low level language like C.

Re:Not all that surprising... (1)

Anonymous Coward | about a month ago | (#47659955)

the use of unsafe languages
Why wouldnt the supposedly 'safe' languages not use these features?

http://lmgtfy.com/?q=java+exploits
http://lmgtfy.com/?q=python+exploits
http://lmgtfy.com/?q=javascript+exploits

The x86 arch is inherently unsafe. It does not have any sort of built in mechanism for bounds checking other than sprinkling if between conditions everywhere. Just like they do in 'safe' languages. It only has a rudimentary no execute bit which was just a stumbling block to the exploiters.

This describes some of the subtle flaws in the arch we use. http://www.emulators.com/docs/nx03_10fixes.htm Specifically section 2 'Lessons Forgotten'. Basically they are putting functionality back in that we had in the 286 era and other CPUs have built in such as the 68k and powerpc.

But your way works better I guess. Sprinkling if/between everywhere seems to be working very well. Right? /sarc

The flaws are deeper than what language you use stop being such a snob.

Like I said these seem exciting to me. You however seem to want to stand still. Forgive me I didnt realize you wanted your tech to stand still. You will have to pardon me I found it exciting.

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

gman003 (1693318) | about a month ago | (#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.)

Re:Not all that surprising... (1)

Impy the Impiuos Imp (442658) | about a month ago | (#47657875)

I heard none of the ultranerd devs had a tightly-coupled mammary.

Re:Not all that surprising... (1)

viperidaenz (2515578) | about a month ago | (#47658405)

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"

Re:Not all that surprising... (1)

K. S. Kyosuke (729550) | about a month ago | (#47658527)

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:Not all that surprising... (1)

fnj (64210) | about a month ago | (#47658821)

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

Re:Not all that surprising... (1)

viperidaenz (2515578) | about a month ago | (#47661123)

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.

Re:Not all that surprising... (3, Informative)

Sun (104778) | about a month ago | (#47660269)

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... (0)

Anonymous Coward | about a month ago | (#47660843)

It may become interesting when you have a compiler for a language that will produce the correct code every time. That will remove the code complexity issue.

For example PyPy is a Python Just-in-Time compiler, they are working on emulated transactional memory build into the language so that basic types become save to use by multiple threads. Maybe they can use TSX to do it for real.

This is also exactly the kind of load where transactional memory shines, since all mutable object need to be protected but there is rarely any contention, or even sharing.

I would be even better if the compiler could figure out which objects are shared and which are not shared, I am sure they are working on that too.

Well, we call them... (2, Funny)

ThatsDrDangerToYou (3480047) | about a month ago | (#47657317)

"Featurata"

Re:Well, we call them... (1)

NotFamous (827147) | about a month ago | (#47657337)

I predict there will be future problems in this area - futurrata.

Re:Well, we call them... (3, Funny)

wonkey_monkey (2592601) | about a month ago | (#47657737)

It's okay, Intel are setting a new subdivision to undo these problems. And to maximise employee happiness, it's being built in the Canary Islands.

I think I'd enjoy being a Featurata Reverter in Fuertaventura.

Re:Well, we call them... (0)

Anonymous Coward | about a month ago | (#47657859)

Wow, clever.

Can I have a refund? (2, Informative)

Anonymous Coward | about a month ago | (#47657319)

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

Re:Can I have a refund? (0)

Anonymous Coward | about a month ago | (#47657499)

To borrow a car analogy, the Fight Club "a times b times c equals x" formula would apply here, but I'm not sure I trust Intel to do the math accurately.

Re:Can I have a refund? (0)

Anonymous Coward | about a month ago | (#47657701)

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

That is one reason why such chips are not designed by companies from such countries.

Trade offs - they're required in the real world.

Re:Can I have a refund? (1, Flamebait)

jones_supa (887896) | about a month ago | (#47657755)

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

You probably didn't even know about the TSX instruction set before reading this article.

Re:Can I have a refund? (0)

Anonymous Coward | about a month ago | (#47657963)

Wow, are you trolling? If the compiler designers and firmware guys are not here any more , were are they hanging out these days?

Re:Can I have a refund? (2)

Rashdot (845549) | about a month ago | (#47657893)

Of course. According to my Pentium you're entitled to $0.99989960954

Dr. Damage is a Cut-n-paste fucktard (-1)

Anonymous Coward | about a month ago | (#47657323)

Breaking news,

"Dr. Damage is a Cut-n-paste fucktard"

a bug != errata (3, Insightful)

Ecuador (740021) | about a month ago | (#47657339)

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:a bug != errata (1)

tepples (727027) | about a month ago | (#47657569)

"A notice of errata", on the other hand, is singular.

Re:a bug != errata (0)

Anonymous Coward | about a month ago | (#47657743)

Yes, a notice of errata is a notice of bugs/errors. Your point?

Re:a bug != errata (1)

tepples (727027) | about a month ago | (#47659561)

My point is that "an errata" is probably short for "a notice of errata".

skip broadwell 2015 (0)

Anonymous Coward | about a month ago | (#47657417)

I use Skylake for the TSX.

Bought a 4770 instead of 4770K because of TSX (1)

Anonymous Coward | about a month ago | (#47657477)

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:Bought a 4770 instead of 4770K because of TSX (0)

Anonymous Coward | about a month ago | (#47657857)

Write a friendly message to Intel and ask for a reimbursement, who knows if you might actually get one. Explain that you bought your chip specifically for TSX.

Re:Bought a 4770 instead of 4770K because of TSX (1)

viperidaenz (2515578) | about a month ago | (#47658281)

But apparently it's much more fun to bitch anonymously on a website about it.

But considering the 4770 is cheaper than the 4770k, I'm not sure how you would calculate the partial reimbursement.
$404.20NZ for i7-4770
$435.85NZ for i7-4770k

Re:Bought a 4770 instead of 4770K because of TSX (3, Informative)

CajunArson (465943) | about a month ago | (#47658467)

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 hang your machine in some corner cases.

Re:Bought a 4770 instead of 4770K because of TSX (1)

Anonymous Coward | about a month ago | (#47661219)

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.

Is this TSX function bad for security? (0)

Anonymous Coward | about a month ago | (#47657615)

Letting my imagination run, I couldn't help but wonder, clueless as I am, if this TSX function could be bad for security. :)

Re:Is this TSX function bad for security? (1)

BronsCon (927697) | about a month ago | (#47657687)

You're thinking of the TSA.

Re:Is this TSX function bad for security? (0)

Anonymous Coward | about a month ago | (#47657835)

I think you're confusing RSA/TSA (public/private key cryptography)
with TWA or SWA (Security of Winged Aircoaches)

/lol tla

So how does one find out /apply "fix" with linux? (2)

Ungrounded Lightning (62228) | about a month ago | (#47657669)

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:So how does one find out /apply "fix" with linu (2)

heezer7 (708308) | about a month ago | (#47657761)

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

Re:So how does one find out /apply "fix" with linu (1)

Anonymous Coward | about a month ago | (#47657789)

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.

Re:So how does one find out /apply "fix" with linu (2)

cheese_boy (118027) | about a month ago | (#47657899)

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.archlinux.org/index.php/Flashing_BIOS_from_Linux

Or doing a microcode update:
https://wiki.archlinux.org/index.php/Microcode

Until there is a chip for sale that really supports TSX I wouldn't expect anyone to be distributing software that uses it. So I wouldn't be too worried about it yet.

Re:So how does one find out /apply "fix" with linu (3, Informative)

Anonymous Coward | about a month ago | (#47657903)

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.

Re:So how does one find out /apply "fix" with linu (2)

BitZtream (692029) | about a month ago | (#47657909)

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'

Re:So how does one find out /apply "fix" with linu (1)

EvilJoker (192907) | about a month ago | (#47658849)

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.

official list of processors that support tsx-ni (0)

Anonymous Coward | about a month ago | (#47659949)

You asked: Can anyone tell us a simple way to check? [if my laptop's CPU supports TSX-NI]

Here is a list (as of November 2013), scroll down for an Intel reply:
Where are the Haswell laptops with TSX-NI ?
https://communities.intel.com/message/211616 [intel.com]

The list starts with i5-4200H, i5-4350U, i5-4300U, i5-4300M, ... and continues up to the i7 chips

Re:So how does one find out /apply "fix" with linu (1)

johndoe42 (179131) | about a month ago | (#47660683)

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 easily fixed with a kernel change.)

Workaround possible? (0)

Anonymous Coward | about a month ago | (#47657695)

Million dollar question is disabling only viable solution?

Could problem be worked around with clever microcode patching?

Point of order (0)

Anonymous Coward | about a month ago | (#47657987)

"Errata" is plural, with the singular being "erratum". Also, not a bug, nor a feature: It's a notice of error with correction. The errata to a book is then the list of errors found with corrections.

when is a 'bug' a 'feature' (1)

Mister Liberty (769145) | about a month ago | (#47658457)

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

Actual details of the bug? (1)

rbarreira (836272) | about a month ago | (#47658629)

Are there any actual details of how the bug works?

With apologies to Joan Jett (0)

Anonymous Coward | about a month ago | (#47658841)

Hello, Intel! Hello, Dell! I'm your C-C-C-C-C-C-C-CLASS ACTION BOMB!

Problem and possible alternatives (5, Informative)

enriquevagu (1026480) | about a month ago | (#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.

Re:Problem and possible alternatives (1)

johndoe42 (179131) | about a month ago | (#47660675)

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... (1)

ewhenn (647989) | about a month ago | (#47659511)

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.

CPUs should be replaced upon request, or... (1)

KonoWatakushi (910213) | about a month ago | (#47659801)

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 the 22nm process. I'm not saying that processors shouldn't be binned, only that it should be done on the basis of defects. It is criminal to arbitrarily destroy value in the pursuit of profit, and maybe the law should reflect that.

Re:CPUs should be replaced upon request, or... (1)

Z00L00K (682162) | about a month ago | (#47660339)

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:CPUs should be replaced upon request, or... (1)

kav2k (1545689) | about a month ago | (#47661241)

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

Re: CPUs should be replaced upon request, or... (0)

Anonymous Coward | about a month ago | (#47660985)

Doubt they can fix it on haswell . Horse has left the barn a long time ago. Gotta see if there is remuneration available.

As a side note (1)

Z00L00K (682162) | about a month ago | (#47660333)

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

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>