Slashdot Mirror

https://www.amd.com/en/corpora...

The shills Intel pay at AMD?
https://www.amd.com/en/corpora...
They admit there are hardware issues and that page describes which software mitigations are required.
ARM have also admitted all of their speculative execution cores are vulnerable to some of the spectre attacks.

AMD already sells a GPU with an integrated SSD: https://www.amd.com/en/product...

If you wanted a heater, the 2nd gen Threadripper 2950X uses more power (TDP) for a lot less money . . .

Yes, perhaps you should do that, I already did (2xxx).

I'm just going to have to go ahead and point out that your retort qualifies as kind of snippy, considering that you actually said "Ryzen 2 (2xxx)" which is wrong, or at best adds to the confusion.

Well, I do kind of already using the thousand terminology that you have pointed out above and AMD website refers to the series as 2nd Generation Ryzen Processors, while many publications have dubbed them as either Ryzen 2nd Gen, Ryzen+, or Ryzen 2. Asking me to use the thousand terminology without addressing your own use of "Ryzen 2 on 7nm" is well.. not fair. What exist today is Zen 2 architecture on 7nm, and whatever product that uses it is not yet named

AMD Epyc supports 4TB of RAM, with that you have plenty.

They kept the firmware completely current

EVERY B350 / X370 has current firmware.

All manufacturers were forced to issue a BIOS update a few months ago with the release of Ryzen 2 which is incompatible with the existing BIOSes on boards with those chipsets. So incompatible that if you go out and buy a B350 and a Ryzen 2 there's a chance you may think it's Dead On Arrival.

AMD even offer a "kit" for you to fix this. If you take a photo of your 2ng Gen Ryzen, your motherboard including serial numbers for both and a receipt, AMD will mail you an loaner A6 processor and the BIOS on a memory stick so you can get your computer started and perform the required BIOS upgrades.

https://support.amd.com/en-us/...

https://www.amd.com/en/where-t...

Personally I really want a new Thinkpad with Ryzen Pro, but they ain't cheap.

AMD64 is the architecture, like 486 or 8080. Intel 64 bit processors are AMD64 architecture.

Literally everything you said was wrong. amd64 is the instruction set. The architectures have code names by which we know them, and none of them are called "AMD64". Intel 64 bit processors duplicate the AMD64 instruction set, but they have different underlying architecture than the AMD processors. They are similar because they perform similar jobs, but they are not identical.

Replying again.

Here You piece of shit. Right from the creators of the AMD64 artchitecture. You can't even get the capitalization right.

I'm sick and tired of this culture of ignorance that has saturated technology. We are supposed to be nice now. We are supposed to not act like Theo or Linux. We are supposed to be inclusive for diversity's sake. We always were inclusive except for people that are incompetent. That is why BSD and Linux just work better most of the time. People like you are tolerated. People like you think you can spew ignorance while jerking your ego because nobody calls you on that shit.

This trash is why people are still being hacked. This trash is why everyone has to do weekly updates on everything made within that trash culture. This trash is why everything is fragile. Some think technical specifics don't matter. Technical specifics are the difference between the Hubble Space Telescope and the Challenger. Technical specifics are the difference between the OKC federal building standing after an asshat destroyed half of it and what happened in New York. This is why Trump is president, Russia and China continue to get what they want from us, and garbage people like you make the lives of everyone you know to be a little worse. These things matter, your feelings don't.

I mean, except for the AMD 9590 from June 2013...

https://www.amd.com/en/product...

None of this makes me feel any more inclined to favor Intel over AMD. This isn't their first "brown paper bag" bug and I doubt it will be their last.

AMD has bugs in their chips too. They're vulnerable to Spectre as well.

If only a 3 year warranty is even offered on some of the highest-end chips they made at the time, when some new cars are warrantied for 10

You only see a 10 year warranty on powertrains (which seldom break) and even then it isn't a 10 year warranty, It's typically a 10 year OR 100,000 mile warranty, whichever comes first. The comprehensive warranties are 3-5 years OR 30-50K miles.

I think that says something really awful about even Intel's own assessment of whether its products can be supported in the long term.

Find me ANY large chip maker offering support on a ten year old chip. Why would they offer support on chips that by computer industry standards are ancient when none of their competitors do either? AMD certainly isn't offering 10 year warranties.

AMD may or may not be drastically better, but Intel has set a very low bar, and it is going to take them serious time to earn back my business, assuming they ever do.

Sounds to me like you already preferred AMD and were just looking for a reason to bash Intel. If you prefer AMD that's fine. They make good products in general and I'd have no quarrel with someone choosing AMD chips. But if you think AMD is going to be any better on the support front than Intel you are being naive.

From my blog:

Meltdown affects all Intel Processors with Out-of-Order-Execution (OOE) and, more importantly, Speculative-Execution, perhaps going back to the Original PentiumPro, and all Atom processors made after 2013 (the original Atoms were In-Order-Execution). AMD processors are immune [3], and Via (remember Via?) has remained silent. Meltdown also affects other architectures, like several ARM processors, including the up-and-coming Cortex-A75 (intended for datacenter use), as well as many others used in cellphones and appliances [5], also IBM’s POWER7+, 8 and 9 are affected [4]. But this paper is not concerned with other architectures.

[3] https://www.amd.com/en/corpora...
[4] https://www.ibm.com/blogs/psir...
[5] https://developer.arm.com/supp...

The Full Blog is here:
https://technologyunderbelly.b...

It is important to understand what processors are safe and what processors are affected by Meltdown and Specter's 2 variants.

https://www.networkworld.com/article/3246707/data-center/meltdown-and-spectre-how-much-are-arm-and-amd-exposed.html

That article contains errors. In particular, the article claims that AMD processors are "potentially vulnerable to only one of the three variants of Meltdown". This is incorrect for two reasons.

(1) There is only one "variant" of Meltdown. Presumably, the author mistakenly considers Spectre Variant 1 and Spectre Variant 2 to be "variants" of Meltdown.

(2) According to AMD's own statement (which is linked in the article), AMD processors are immune to Meltdown, but vulnerable to both variants of Spectre. But Spectre Variant 1 can be avoided by patching the operating system. After the operating system patch is applied, AMD processors are only vulnerable to Spectre Variant 2.

AMD also says that in 2019 they will begin shipping processors that are immune to Spectre Variant 2.

In their defense, the AMD article also looked like PR fluff too. Read the January 3rd update AMD published here.

https://www.amd.com/en/corpora...

They actually published something useful yesterday, 8 days after the public disclosure.

The Verge is obvioulsy a non-credible source. Or does that just apply to stories editors don't want to publish (*ahem* twitter *ahem) ?

What a terrible article. Here Slashdot editors, a better one from a no-name site that actually gets the facts right :

https://www.lowyat.net/2018/152301/amd-begin-distributing-firmware-updates-patch-spectre-vulnerability/

Or just use the damn primary source :

http://www.amd.com/en/corporate/speculative-execution

AMD never said there was a near zero risk for Spectre.

To be fair they did say that there is Near zero risk of exploitation of Spectre variant 2 (Branch Target Injection):

Variant Two Branch Target Injection
Differences in AMD architecture mean there is a near zero risk of exploitation of this variant. Vulnerability to Variant 2 has not been demonstrated on AMD processors to date.

According to AMD, AMD is vulnerable to one variant of the attack, and possibly vulnerable to a second variant.

http://www.amd.com/en/corporat...

AMD chips are, according to AMD, vulnerable to a bounds check bypass related to speculative execution. In the details, they say "Resolved by software / OS updates to be made available by system vendors and manufacturers."

They do NOT say they are immune to the branch target injection vulnerability either. The say the following which is much less reassuring: "Differences in AMD architecture mean there is a near zero risk of exploitation of this variant."

http://www.amd.com/en/corporat...

Thank you for noting that you're not 100% sure it's right, and for the excellent summary. There's a ton of misinformation going around, especially with 0100010001010011 dude on Slashdot repeatedly posting that Meltdown is INTEL ONLY, which is false, as some ARM products are affected. What is true is that Meltdown does not affect AMD and affects only a few of ARM's processors.

As you state, it's important to rely on the original sources. Here is each CPU vendor's response to the security issues:
https://www.amd.com/en/corpora...
https://www.intel.com/content/...
https://developer.arm.com/supp...

Here are two corrections to make:
1) Meltdown:
One of your bold statements "AMD and ARM are not affected" is untrue. See here, from ARM directly:
https://developer.arm.com/supp...

ARM has confirmed that A75 is vulnerable to Meltdown. In addition, A15, A57, and A72 are vulnerable to a variant of Meltdown (Variant 3a) which ARM has added. ARM has stated that they believe this variant is NOT exploitable, however, there is already userspace code out there that can do some limited exploits:
https://github.com/lgeek/spec_...

AMD is not affected by Meltdown, in any form. From AMD's press release:
https://www.amd.com/en/corpora...

2) Variant 1: While other vendors may require application changes to address this issue, AMD appears to be able to address this with an OS update, based on their post:
https://www.amd.com/en/corpora...


Summary:
Variant 1: Some manufacturers (ARM) appear to not be able to fix it and are recommending compiler changes, but AMD will fix this in OS updates. Unclear how Intel is addressing this vulnerability.
Variant 2: Correct, from what I can tell.
Variant 3 (Meltdown): Affects nearly all Intel (within the last 10 years) and ARM A75 chips. AMD not affected.
Variant 3a (Modified Meltdown): Affects a larger set of high performance ARM chips

Finally, Intel has done a terrible job (intentionally?) at conflating the two issues, which is unfair. These are 3 separate security issues, with their own priorities and impacts. If you read Intel's official press release for this issue, there's no differentiation between variants 1-3, like there is for AMD and ARM:
https://www.intel.com/content/...

Thank you for noting that you're not 100% sure it's right, and for the excellent summary. There's a ton of misinformation going around, especially with 0100010001010011 dude on Slashdot repeatedly posting that Meltdown is INTEL ONLY, which is false, as some ARM products are affected. What is true is that Meltdown does not affect AMD and affects only a few of ARM's processors.

As you state, it's important to rely on the original sources. Here is each CPU vendor's response to the security issues:
https://www.amd.com/en/corpora...
https://www.intel.com/content/...
https://developer.arm.com/supp...

Here are two corrections to make:
1) Meltdown:
One of your bold statements "AMD and ARM are not affected" is untrue. See here, from ARM directly:
https://developer.arm.com/supp...

ARM has confirmed that A75 is vulnerable to Meltdown. In addition, A15, A57, and A72 are vulnerable to a variant of Meltdown (Variant 3a) which ARM has added. ARM has stated that they believe this variant is NOT exploitable, however, there is already userspace code out there that can do some limited exploits:
https://github.com/lgeek/spec_...

AMD is not affected by Meltdown, in any form. From AMD's press release:
https://www.amd.com/en/corpora...

2) Variant 1: While other vendors may require application changes to address this issue, AMD appears to be able to address this with an OS update, based on their post:
https://www.amd.com/en/corpora...


Summary:
Variant 1: Some manufacturers (ARM) appear to not be able to fix it and are recommending compiler changes, but AMD will fix this in OS updates. Unclear how Intel is addressing this vulnerability.
Variant 2: Correct, from what I can tell.
Variant 3 (Meltdown): Affects nearly all Intel (within the last 10 years) and ARM A75 chips. AMD not affected.
Variant 3a (Modified Meltdown): Affects a larger set of high performance ARM chips

Finally, Intel has done a terrible job (intentionally?) at conflating the two issues, which is unfair. These are 3 separate security issues, with their own priorities and impacts. If you read Intel's official press release for this issue, there's no differentiation between variants 1-3, like there is for AMD and ARM:
https://www.intel.com/content/...

Thank you for noting that you're not 100% sure it's right, and for the excellent summary. There's a ton of misinformation going around, especially with 0100010001010011 dude on Slashdot repeatedly posting that Meltdown is INTEL ONLY, which is false, as some ARM products are affected. What is true is that Meltdown does not affect AMD and affects only a few of ARM's processors.

As you state, it's important to rely on the original sources. Here is each CPU vendor's response to the security issues:
https://www.amd.com/en/corpora...
https://www.intel.com/content/...
https://developer.arm.com/supp...

Here are two corrections to make:
1) Meltdown:
One of your bold statements "AMD and ARM are not affected" is untrue. See here, from ARM directly:
https://developer.arm.com/supp...

ARM has confirmed that A75 is vulnerable to Meltdown. In addition, A15, A57, and A72 are vulnerable to a variant of Meltdown (Variant 3a) which ARM has added. ARM has stated that they believe this variant is NOT exploitable, however, there is already userspace code out there that can do some limited exploits:
https://github.com/lgeek/spec_...

AMD is not affected by Meltdown, in any form. From AMD's press release:
https://www.amd.com/en/corpora...

2) Variant 1: While other vendors may require application changes to address this issue, AMD appears to be able to address this with an OS update, based on their post:
https://www.amd.com/en/corpora...


Summary:
Variant 1: Some manufacturers (ARM) appear to not be able to fix it and are recommending compiler changes, but AMD will fix this in OS updates. Unclear how Intel is addressing this vulnerability.
Variant 2: Correct, from what I can tell.
Variant 3 (Meltdown): Affects nearly all Intel (within the last 10 years) and ARM A75 chips. AMD not affected.
Variant 3a (Modified Meltdown): Affects a larger set of high performance ARM chips

Finally, Intel has done a terrible job (intentionally?) at conflating the two issues, which is unfair. These are 3 separate security issues, with their own priorities and impacts. If you read Intel's official press release for this issue, there's no differentiation between variants 1-3, like there is for AMD and ARM:
https://www.intel.com/content/...

Because ARM itself claims they are affected: https://developer.arm.com/supp...
AMD also claims one variant of the bug affects their CPU's: https://www.amd.com/en/corpora...

It's true that AMD isn't affected by Meltdown

According to the AC. AMD, on the other hand, says they are indeed affected.

Sigh, did anyone actually read the spectre paper;

Exploiting Indirect Branches.

The bit about execution beyond software checks is explaining a specific detail about memory side effects. The above section builds on that concept to show that you can induce these memory side effects by tricking the branch predictor to execute existing code in an unexpected way.

Okay, to go into more details :
there are two things that are call spectre, which are both based around speculative execution.

The first one, which gets around software check, to which every single deeply-pipelined/out-of-order CPU that does speculative execution (lots of vendors, some as long back as mid 90s), and which is basically still "speculative execution working as intended", is the one I've described in my post.

That the one to which every piece of software running on nearly any CPU (except perhaps older Intel Atoms, Intel Xeon Phis, and older ARM 32bits as those don't do speculative execution, because as a matter of fact they have way to short pipelines) is susceptible, but which in practice isn't very concerning because it basically targets software which has "please exploit me!" design flaws written all-over it.

The second things which is called "spectre", also uses speculative execution, but is an extremely specific stuff that only targets specific CPUs :
only specific Intel CPUs are concerned, only in extremely specific circumstances. AMD CPUs are not affected. And that's expected because each CPU uses an entirely different strategy to predict branches.

Just like with Meltdown, it against boils down to Intel CPU trying to be way too much clever, trading security to shave a few performance points.
It boils down to an address (here a jump target) to even being known at the time when instruction start to pour into the pipeline. Some CPUs may try to guesstimate where the execution would go next.
The way some specific Intel CPU store their estimations means there's a risk of aliasing/confusion (CPU has learned that instruction A usually jumps to point B, but when the CPU sees instruction C it get things mixed up and think that there's a high chance it will also jump to point B and start speculatively executing there, even if that ends up not being the case and C actually jumps to a different point B).

By knowing the specific make of affected Intel CPUs, and by knowing the exact way in which this aliasing and confusion happens in that specific Intel CPUs, and by allocating a shit ton of memory (so you end up with an address that can actually be confused/aliased with your target) and by the way knowing in advance the foreign address you're trageting (because, you know, ASLR gets in the way) and spending around half an hour doing stuff (according to the Google demo) in order to get the exact thing you need so that specific Intel CPU confuses the thing exactly the way you need, then you can have the CPU guess wrong and jumping speculatively to the completely random address you've asked it to jump to (until it notice it's wrong, throws nearly everything out - except the already prefetched cache - and jumps back to the actual correct execution).

This is not something that affects every speculatively executing CPU in existence, this is not a CPU still working as it should (unlike the other exploit).

This is some specific CPU (happens to be by Intel) that each take wild guesses - way too much wild guesses - and if you know exactly how this CPU takes its too wild guesses, you can abuse to make it guess wrong. No other CPU will be affect.

Given the complexity of the taks, this is not something that you're going to see a lot in the wild and automated (not in drive-by Javascript attacks). This is something that is going to be specially crafted manually, for some very specific attacks (an attacker want to break the specific hyper visor in which it's currently staying).

Fucking God Dammit shitel shill, the article is using Shitels PR statement as reference, and you keep posting the same FUCKING incorrect information. So fuck off, I will say it again just stop fucking shilling , here is exactly what AMD said https://www.amd.com/en/corpora... , and what Linus Tovalds said about the god dam PR statement you linked to http://www.businessinsider.com...

You're totally right; I misread the table -- the G34 socket and Opteron 6300 is a Piledriver chip, not Ryzen.

AMD Epyc the new brand name that replaces AMD's Opteron server line (can I say I hate rebranding?)

It's the Epyc 7551 is ZEN architecture, uses the SP3 LGA socket, and has 32 cores/64 threads.

SuperMicro appears to have some in the pipeline, and even has a dual-socket model, with IPMI 2.0.

128 threads in a single system ain't too shabby...

Branch Target Injection: Differences in AMD architecture mean there is a near zero risk of exploitation of this variant. Vulnerability to Variant 2 has not been demonstrated on AMD processors to date.

Near zero implies that it is possible! What are the differences, and why do they make it unlikely? could enhancements to the attack make it feasible?

I think I understand it better now.
There are actually, 3 vulnerabilities: 2 spectre and 1 meltdown.
AMD Zen CPU's are actually affected by the first spectre vulnerability and they admit to that: https://www.amd.com/en/corpora...

The other Spectre vulnerability and the meltdown don't affect Zen. Meltdown is the vulnerability that needs the KPTI patch. Presumably there is some other patch on the way to fix spectre.

Look at the blog post I linked.

You mean the one that says "AMD provided the following link: http://www.amd.com/en/corporate/speculative-execution? It contains the following in a table:

Variant One Bounds Check Bypass Resolved by software / OS updates to be made available by system vendors and manufacturers. Negligible performance impact expected.
Variant Two Branch Target Injection Differences in AMD architecture mean there is a near zero risk of exploitation of this variant. Vulnerability to Variant 2 has not been demonstrated on AMD processors to date.
Variant Three Rogue Data Cache Load Zero AMD vulnerability due to AMD architecture differences.

So yes, some of the attacks work against AMD processors. However, due to architectural differences, mitigation will involve minimal performance impact, unlike Intel. Once again, we see that AMD has superior architecture, and Intel has superior process technology.

http://www.amd.com/en/corporat... AMD's official statement seems to confirm they are vulnerable to variant one of the attack which will be corrected in OS/vendor software. Variant 2 unlikely to be vulnerable, Variant 3 not vulnerable.

I managed to find ARM's press release.

As an aside, AMDâ(TM)s Opteron-A is Cortex-A57 design, which ARM explicitly states is vulnerable to 3 out of 4 variants of the bug in their press release. Iâ(TM)ve heard Google's Project Zero released more details too (sorry, no link, I haven't read it yet).

Intel is still being a weasel in their press release, of course.

AMD's AMD64 chips don't have the flaw.

AMD's Opteron-A, however, is an ARM64 chip which does have the flaw.

The AMD Opteron-A, that's why.

Because other CPU manufacturers are pumping out devices that have this issue, and have done so for years.

ARM64 is also affected - and includes chips made by virtually every silicon maker, including AMD, Apple, Samsung, Texas Instruments, Renesas, STMircro, Microchip, Broadcomm, Qualcomm, and others. They are in virtually every recent tablet or smartphone.

Even the decidedly non-Intel Raspberry Pi 3 is affected.

AMD's AMD64 may be unaffected, but AMD's Opteron-A processors are absolutely affected.

ARM64 is also affected, which means pretty much any phone or tablet made in the past 3-4 years.

ARM64 is not only a different chip maker -- but an entirely different architecture, which is produced by many vendors -- AMD, Samsung, LG, Qualcomm, Apple, Microchip, Broadcom, Renesas, STMicro, Texas Instruments, and many, many others.

AMD also makes ARM64 chips (Opteron-A), so AMD absolutely has affected products.

Erm, AMD has PSP. It is not that much different from IME.

The Platform Security Processor (PSP) is built in on all Family 16h + systems (basically anything post-2013), and controls the main x86 core startup. PSP firmware is cryptographically signed with a strong key similar to the Intel ME. If the PSP firmware is not present, or if the AMD signing key is not present, the x86 cores will not be released from reset, rendering the system inoperable.

The PSP is an ARM core with TrustZone technology, built onto the main CPU die. As such, it has the ability to hide its own program code, scratch RAM, and any data it may have taken and stored from the lesser-privileged x86 system RAM (kernel encryption keys, login data, browsing history, keystrokes, who knows!). To make matters worse, the PSP theoretically has access to the entire system memory space (AMD either will not or cannot deny this, and it would seem to be required to allow the DRM “features” to work as intended), which means that it has at minimum MMIO-based access to the network controllers and any other PCI/PCIe peripherals installed on the system.

So, as I said, PSP (neigh ASP) is AMD's version of Intel's ME and is based on ARM TrustZone. It's literally an ARM core with TrustZone that manages the boot process and provides various out-of-band features separate from the x86 cores.

You are correct, though, that TrustZone is something completely different; but AMD's PSP (ASP) relies on TrustZone. I did misunderstand how much of that functionality came from TrustZone so, thank you for the additional info.

Check the hardware for linux compatibility.

Since when does the packaging of mainstream* laptop PCs include a penguin logo or other notice of compatibility with X11/Linux?

you might also want an AMD machine (though they may have their own secrets.)

AMD kit includes the analogous AMD Secure Processor, which runs ARM TrustZone. (It used to be called the Platform Security Processor until people who bought AMD-powered PS4 consoles were disappointed that they couldn't download and play purchased PSP games.) But at least ARM TrustZone is a multi-vendor standard.

* By which I exclude the more expensive, mail-order-only products of System76 and the like.

They changed the name to AMD Secure Processor: http://www.amd.com/en-us/innov...

The biggest question for me when deciding on any hardware purchase is how well the manufacturer supports the development of Free, open-source drivers for their hardware, either through the availability of specifications or actually contributing to driver development. (...) I used to be a big fan of AMD, but it feels like they have not kept up, particularly since they purchased ATI.

Huh? ATI was totally closed source, as bad as nVidia or worse. AMD is releasing tons of open documentation, here for example is a 239 page guide describing the Vega ISA and as for the drivers Phoronix said:

It's phenomenal seeing the open-source driver support one day-one and that for Linux OpenGL games the performance even surpasses AMDGPU-PRO. This Vega launch is easily the most successful discrete GPU launch ever where it's backed by fully-open drivers.

That said, the problem for open source graphics on Linux is that the gaming market share is falling despite /. posting about how many indie games there are. The latest Steam survey says 0.60% and a whooping 96.6% for Windows, it used to be about 1%. It's hard to get AMD to spend more of their very limited cash on a near non-existent market.

You are forgetting SATA ports and USB 3.1 gen1 and gen2 is also coming from cpu

On Ryzen?
I saw he said that.

Care to link or explain it in full instead of just dropping so little information?

http://www.amd.com/en-us/produ...
List 2+10+6 USB on X370 chipset, and 6 SATA + x2 NVMe or 4 SATA + x4 NVMe + 2 SATA express.
But that's listed on chipset, not processor.

What you mean? Suck that you posted as AC.

As much as I appreciate the price/performance of Ryzen based CPUs and the competition it has sparked, I will stay away from any Zeppelin-Die-based CPUs until AMD provides a proper explanation and fix for the "gcc segmentation fault" bug that haunts Ryzen CPUs.

After many months of not admitting any bug existence to the affected users, AMD finally admitted there is one, yet they neither recalled affected CPUs nor do they tell us how to distinguish affected from unaffected CPUs - so even if you buy a Ryzen today, you can still buy one unsuitable for ordinary gcc compilation tasks.

Given that they cannot (or do not want to) say which CPUs are affected, and given that AMD did never explain a root cause of this bug and how it is fixed, I do not believe they actually have fixed it or know how to fix it. Even CPUs that were manufactured in calender week 25 of 2017 have turned out to be affected!

Why should I believe they fixed this for "Threadripper"?
Sure, they know by now how to test individual CPU exemplars for the bug, and might deliver unaffected ones to the press for reviews. Does that tell me they will do the same testing for the exemplars delivered to the mass market? No.

More information on this bug via https://forum.level1techs.com/... and https://community.amd.com/thre...

You make it sound like this is unique to Intel. It is not.

AMD's TrustZone is basicallly the same thing---a processor which has supervisory access to the hardware and operating system.

Read all about it at:

http://www.amd.com/en-us/innov...

Maybe they should have use Epyc, which has much better RAS features than Broadwell: http://www.amd.com/system/file...

Windows 10 Pro has the SMT bug. It's reliably reproducible locally and via network nodes.

I can't find any posts of people reproducing crashes with the SMT bug though?

Nor does AMD's official response seem to acknowledge a crash issue at all?

It doesn't really make sense to me why lower performance would cause compilers to crash? I have nodes with much lower end hardware (approaching 8 years old - We were replacing those progressively with these Ryzen systems until we noticed this issue) that are less performant and aren't crashing?

Even my current "low-end" card (an RX 460) can drive six normal-ish displays: One HDMI, one DVI-D, and four HDMI on its singular DisplayPort output using an adapter.

I guess you should let AMD know, since they say:

Up to 5 displays with DisplayPort MST hub

Not sure why that's still a subject though... for non-intensive applications I think it's been solved a while and for games I'd rather go for a single ultra-wide, if games have trouble you can presumably set it to a normal 16:9 resolution and get black bars. There was a time you couldn't get monitors to match but with the current 34/38" monsters the only advantage to multi-monitor is if you get them cheap/free. And for a big video wall there's probably cheaper solutions that are simple splitters.

Ryzen CPU hangs/causes kernel panics and MCE errors, most easily reproducible on Linux

https://community.amd.com/thread/215773?start=180&tstart=0

I hope they can finally fix it. Newest posts (as of today) claim people who RMA'd their CPU and got replacement experience improvement.

That said right now it looks like an an Intel tech, did anyone see anything about AMD/nVidia support?

AMD has had SR-IOV support baked into their GPUs for a while now. It shouldn't take much to add support for it into the Radeon Open Compute kernel driver if it isn't already there.

It's actually a direct quote from the article that way. As a direct cut and paste:

The X300 is no exception—like the X370, the X300 supports dual-channel DDR4 memory, PCIe 3.0, M.2 SATA devices, NVMe, and USB 3.1 Gen 1 and Gen 1.

Read more at http://hothardware.com/news/am...

What's funny is the link wasn't even part in the selection that I cut; which means that the article page has javascript that inserts additional text to the clipboard. It actually requires looking at AMD's page to realize for certain that they mean to say USB 3.1 Gen 1 and Gen 2. Perhaps what should have been added is an [sic] tag after the line to indicate that this piece of quality writing is on Paul Lilly's and HotHardware's heads; not MojoKid's or Slashdot's.

Uhhh they already did that over a year ago and sadly Linux users showed how much they really cared about "free as in freedom" when AMD's sales didn't go up a single percent and every Linux forum (including here) kept right on going "herp derp buy Nvidia".

They can scream and gnash their teeth and mod me down all they want but truth is truth and if Linux users actually paid more than lip service to "free as in freedom" then we'd see every Linux article saying "buy AMD" as AMD has gone above and beyond to give to the FOSS community, from GPUOpen to Vulkan, from ACL to basing their own compiler on GCC and contributing to FOSS projects, what did it get them? Precisely NOTHING.

Is it any wonder why companies don't want to spend the money to support Linux with drivers? All they have to do is take one look at how little it got AMD to realize its just throwing away money, it brings them nothing in return, not sales, not even good will of the community, nothing.