TSX borked in Haswell and Broadwell

[Fjodor2001]

http://ark.intel.com/compare/80815,80817

There is a 10-15$ difference between 4460 and 4590. The difference includes faster GPU, higher clocks, TXT, TSX, SIPP and vPro. All in favour of the 4590.

Intel sure dont put much value in TSX if so.

http://ark.intel.com/sv/compare/75047,75048

The list price difference between a 4670 and 4670K is only $19.

In other words Intel does not put much value in the unlock feature. So if it turned out the unlock feature actually did not work on the K chips, it should be perfectly ok. The customers just have to take the pain despite having paid extra for it. That's your logic?

 

[Phynaz]

Compare products where the only difference is that one of them has TSX, and you'll find that the one with TSX is more expensive.

Please link to your proof of this.

You can't because there is no such product. You're making stuff up in order to win your anti-Intel argument.

 

[zir_blazer]

I would be careful to blame the engineers at first. They are constrained by decisions coming from the top. And you can see what the #1 rule the CEO lives by: "Do the absolute minimum. Get this shit out the door in whatever state it is in two weeks".

I don't think that they think like that. Do you know how expensive a recall is? Intel had several.


Where I live at, K Series are usually a luxury part and well beyond Joe Average regular price range. Because vendors asume that only enthusiast buy those, it is much easier to get a K Series Processor than the normal equivalent because not everyone carry it. At least, the new Devil's Canyons fixes the most important feature disparity that there was with normal Core i5/i7 which was VT-d and TSX. vPro and TXT are of much more limited usefulness.

 

[ViRGE]

Alright kids, the thread title is "TSX borked in Haswell and Broadwell".

So if you aren't talking about TSX being borked and the ramifications thereof, you're in the wrong place. Go start another thread (or better yet, go to another forum entirely) if you want to argue semantics over pricing.

-ViRGE

 

[Fjodor2001]

Isn't it strange that Intel has not published info on how to reproduce the TSX bug? It should be known to them by now, so why not publish it?

 

[mv2devnull]

https://bbs.archlinux.org/viewtopic.php?id=172305

That is from last year. Back then the question was: "which software component has a bug?" Now we could add the hardware to the suspects.

It is true that not all processors have the TSX.
It is true that all programs do not use the TSX instructions.
The glibc is the core system library, so it can use TSX on behalf of every threaded application on the system. Not all Linux do use TSX-enabled glibc though.
It is true that Linux has very small market.

However, there are already Haswell-based servers on the market. It is quite likely that with TSX support present in glibc and compilers (GCC) the recently built server applications do make use of the feature, even though stability is emphasized on servers.

The fact that glibc can use TSX on Linux creates the question whether others, like Microsoft and Apple, have done similar feature updates to their OS? That would undermine the "only some apps use it" assumption.

 

[ShintaiDK]

The fact that glibc can use TSX on Linux creates the question whether others, like Microsoft and Apple, have done similar feature updates to their OS? That would undermine the "only some apps use it" assumption.

Windows 7(2008R2) and Windows 8(2012) doesnt support TSX. I am not sure if 8.1 or 2012R2 support it. Or if its first in Windows 9/2015.

 

[Phynaz]

Isn't it strange that Intel has not published info on how to reproduce the TSX bug? It should be known to them by now, so why not publish it?

What would be the point? Does AMD publish how to reproduce each of their errata? Does anyone?

By the way, the last two are rhetorical.

 

[JoeRambo]

What would be the point? Does AMD publish how to reproduce each of their errata? Does anyone?

By the way, the last two are rhetorical.

Actually there is a point, as TSX was made out of two features:

1) RTM - some crazy hardware transaction scheme, requires recompilation and runs on Haswell (and noone in their right minds would make software for it, cause it is incompatible with old CPUs)

2) HLE - Hardware Lock Elision, this one is extremely useful for library and OS writers, cause it allows for performance benefits on Haswell, while maintaining compat with older CPUs (instructions are NOPs on olders CPUs).

So if it's RTM that is broken ( I suspect that, cause it has crazy complexity of hw transaction abort etc), and HLE is OK, ppl are not really exposed to the bug (and software compiled for RTM instructions can simply do CPU family/revision check and refuse to run the buggy code).

 

[Fjodor2001]

What would be the point? Does AMD publish how to reproduce each of their errata? Does anyone?

By the way, the last two are rhetorical.

For example: Because people want to know how their SW is affected by the TSX bug, if a workaround can be made in SW, and how to write code for TSX once the new CPUs are released where the bug is fixed.

E.g. I suppose it is no longer ok to dynamically detect TSX compatibility anymore and have your SW make use of it if present. So will there be some new way of detecting actual working TSX support?

Such questions need to be answered from a SW perspective.

 

[SOFTengCOMPelec]

It was found by someone outside of intel according to this article here.

Thanks for the link.
I'm looking forward to Intel, or some other source if they don't (found out by experimentation), announcing more details about this TSX bug/fault. Then we can decide how to best handle the TSX situation, and how badly Intel have let us down, as regards a possible issue with their testing/validation systems.

From all the flap here, the same applies to enthusiasts!
TSX is not something that your CPU would use directly. It would be used by large database servers. An example of the advantage to you would be a fraction of a second saved when buying something online if it is during a high use period. The server is what uses it not your computer.

Ignore the above if your computer has a many terabytes size database that serves hundreds of users every minute!

Although I agree with you that databases are a significant part of what TSX was for, I also thought that modern multi-tasking software, could also potentially benefit from using TSX, especially where there was a significant area of shared memory (between multiple cores/threads), which can be the case in applications, which are not only databases.
E.g. Scientific applications and possibly even upcoming (very multi-core enabled) games (e.g. big shared memory physics model scheme).
The scientific software is viable, but the gaming software would be problematic, because many Intel cpus (because of over zealous market segmentation) and AMD/Arm cpus, DON'T have TSX, anyway. Hence the software would also have to be written to work without TSX, being present.

 

[frozentundra123456]

Actually there is a point, as TSX was made out of two features:

1) RTM - some crazy hardware transaction scheme, requires recompilation and runs on Haswell (and noone in their right minds would make software for it, cause it is incompatible with old CPUs)

2) HLE - Hardware Lock Elision, this one is extremely useful for library and OS writers, cause it allows for performance benefits on Haswell, while maintaining compat with older CPUs (instructions are NOPs on olders CPUs).

So if it's RTM that is broken ( I suspect that, cause it has crazy complexity of hw transaction abort etc), and HLE is OK, ppl are not really exposed to the bug (and software compiled for RTM instructions can simply do CPU family/revision check and refuse to run the buggy code).

But Intel is disabling TSX entirely, if I am correct, so there would be no way to use it in any of these applications. I agree it would be nice to know how and when the bug occurs, but if Intel disables TSX entirely, it is sort of an academic point.

 

[Edgemeal]

Isn't it strange that Intel has not published info on how to reproduce the TSX bug? It should be known to them by now, so why not publish it?

If the bug only happened when using TSX in a certain way then they would post workaround(s) for developers to use, but apparently its broke beyond that, and that is all us programmers really need to know.

 

[Fjodor2001]

But Intel is disabling TSX entirely, if I am correct, so there would be no way to use it in any of these applications. I agree it would be nice to know how and when the bug occurs, but if Intel disables TSX entirely, it is sort of an academic point.

The problem it is requires a microcode update in the CPU, which may not reach all CPUs (e.g. not everyone may update their BIOS, or allow any other delivery mechanism it). I.e. SW always needs to be prepared for that the SW may be running on a CPU with the TSX bug present and active.

 

[Fjodor2001]

If the bug only happened when using TSX in a certain way then they would post workaround(s) for developers to use, but apparently its broke beyond that,

Hmmm.... do we really know that? I don't think Intel has communicated that it's not possible to do workarounds in SW. Intel has said this:

So possibly if those conditions where the bug occurs on can be avoided, the bug can also be avoided. Intel may want to disable TSX anyway though, since there can be already existing SW that uses TSX which will not be rewritten to include such a workaround. I.e. better to disable TSX completely to be safe.

Finally, SW developers also need to know how to distinguish a buggy TSX CPU from a working one (once those are released), so they know how to write SW for it properly. Just detecting TSX instruction support as currently will not work, since you don't know if TSX is broken or not.

 

[Fjodor2001]

Two more reasons why SW developers need to know what problems the TSX bug can cause and under what conditions they occur:

* Since you cannot rely on TSX being disabled in all CPUs with the TSX bug present, you have to deal with the TSX bug possibly being present. So you need to know how urgent it is to release an updated version of your SW which does not use TSX. Can the TSX bug be exploited causing a security issue? Does the SW crash? Does it produce incorrect calculation results? The answer to such questions are needed to know how urgently this needs to be fixed in your SW.

* If bugs or problems occur in your SW, you'd like to know if it can be the TSX bug causing them or not. You don't want to spend time hunting down a non-existing SW bug, if it's the CPU that is actually causing the problem.

 

[Phynaz]

You do it the same way you have always done it, via feature detect. Does this CPU support TSX 1.1 (or 2.0 or whatever)? If not, don't use TSX.

Simple.

 

[Fjodor2001]

You do it the same way you have always done it, via feature detect. Does this CPU support TSX 1.1 (or 2.0 or whatever)? If not, don't use TSX.

Simple.

Yeah, probably. Solves the issue "SW developers also need to know how to distinguish a buggy TSX CPU from a working one (once those are released)". All the other issues I mentioned are left though, requiring details about the TSX bug to be provided by Intel.

We might also ask ourselves: What reasons could Intel have for not releasing details about the bug (what effect it has, and how to reproduce it)? If it can be exploited and cause a security problem, that could be one reason. But things will always leak to the public eventually in the end, so that's no safe haven. It can be a strategy to delay the info being publicly known though, giving SW developers time to plug the security hole. That's a common strategy - keep exploit info as secret as possible until there's a security fix available. But trying to keep info secret is no long term solution.

 

[Phynaz]

We might also ask ourselves: What reasons could Intel have for not releasing details about the bug (what effect it has, and how to reproduce it)?

Because it does no good to release the info. There's nothing you can do about it. Again, nobody - even AMD - releases the kind of info about errata that you are looking for to the general public.

Here is an AMD errata found by an independent software developer. AMD has never published the details of how to reproduce this crash bug: http://www.bit-tech.net/news/hardware/2012/03/06/coder-finds-amd-chip-bug/1

So ask yourself, what are the reasons AMD has for not releasing the info? Could it be a security problem? Are they trying to hide it from their users?

How about you, are you affected by the AMD bug? How do you know your crashes aren't caused by it?

 

[Fjodor2001]

Because it does no good to release the info. There's nothing you can do about it. Again, nobody - even AMD - releases the kind of info about errata that you are looking for to the general public.

Here is an AMD errata found by an independent software developer. AMD has never published the details of how to reproduce this crash bug: http://www.bit-tech.net/news/hardware/2012/03/06/coder-finds-amd-chip-bug/1

So ask yourself, what are the reasons AMD has for not releasing the info? Could it be a security problem? Are they trying to hide it from their users?

How about you, are you affected by the AMD bug? How do you know your crashes aren't caused by it?

I get your point. But the AMD case you linked to does not say that AMD does not intend to disclose details on the hardware bug. It just says that at the time the article was written it had not been documented in AMD's official list of errata yet. And in fact AMD already had confirmed some details , as the article says: "AMD has taken your example and also analysed the segmentation fault and the fill_sons_in_loop code. We confirm that you have found an erratum with some AMD processor families,' the company told Dillon. The specific compiled version of the fill_sons_in_loop code, through a very specific sequence of consecutive back-to-back pops and (near) return instructions, can create a condition where the processor incorrectly updates the stack pointer".

The Intel TSX bug on the other hand has made it into the Intel official errata list, but without details e.g. on how to reproduce the problem or what problems it can cause.

Also, I think it depends on the severity of the bug. In the TSX case it's the complete TSX instruction set / functionality that is broken and will be disabled. So the seriousness and extent of the problem is much greater. That makes it more important to release detailed info about it.

 

[Azix]

Yeah, looks like my 4770K wasn't such a bad buy after all, lol.

in addition to the virtualization stuff, this TSX thing was supposed to make my 4770 purchase a good deal. I did get it for ~269 with free 8GB RAM but the lack of overclocking was supposed to be w/e.