VOGONS


VME Broken on AMD Ryzen

Topic actions

First post, by awgamer

User metadata
Rank Oldbie
Rank
Oldbie

Oops.
http://www.os2museum.com/wp/vme-broken-on-amd-ryzen/

Reply 1 of 31, by kode54

User metadata
Rank Member
Rank
Member

TL;DR: 32 bit operating systems are mostly broken on Ryzen, whether bare metal or run under virtualization on a 64 bit host operating system. It is not known whether a mere microcode update could fix this, as the behavior of the broken instructions may well be at least partially ingrained on the hardware itself.

E: This has no effect on most/all? emulators, as they do not usually make use of virtualization extensions to execute legacy code directly, but instead employ recompilation or interpreter routines to adapt the legacy code to the host operating system.

Reply 4 of 31, by cyclone3d

User metadata
Rank l33t++
Rank
l33t++

Why would you even be running a 32-bit OS on RYZEN in the first place?

For my main system, I have not run 32-bit since Windows XP x64 came out.

Yeah, you can see it if you run a VM, but you can also disable it so it works.

Also, the current Intel CPUs apparently don't work properly with x87 code.

Pretty much every CPU is going to have some errata. The things are just so amazingly complex anymore that it is almost impossible to test every possible scenario.

Yamaha YMF modified setupds and drivers
Yamaha XG resource repository - updated November 27, 2018
Yamaha YMF7x4 Guide
AW744L II - YMF744 - AOpen Cobra Sound Card - Install SB-Link Header
Epstein didn't kill himself

Reply 5 of 31, by Jo22

User metadata
Rank l33t++
Rank
l33t++

A lot of of people asked "why". Well, I can think of several scenarios.

1) XP. I'm using it very often in a VM. Be it for games or to run my older compilers without compatibility issues,
Delphi 1-7, VB6 and VB.Net 2005.

2) DOS. I like to have a DOS VM around for testing purposes. Emulators are good,
but sometimes it is preferable to have a true DOS VM (where you can't install a real EMS board and QEMM uses VME).
Be it for development (serial, parallel pass-trough to control industrial stuff or ham radios)
or for having all VMs connected in the same virtual network.

3) NVTDM. A few years a go, I've seen active DOS sessions on Windows-PCs in computer shops.
I assume they were still running ancient productivity software written in Clipper or dBase.
(Why not ? Every software is outdated somewhen. DOS is at least simple and well documented..)

Anyway, I'm not blaming AMD for anything. To err is human, and mistakes happen.
But let's face it - we are living in the virtual age now (cloud storage, etc.).
Everything is going to be virtualized and VMs are very important.

In the next decades, current computers are gone. Emulation and virtualization do remain important
to run old software, to preserve our past. Without archived software, we may loose the ability to read old obscure formats.
So yes, XP is one important piece of history. It had the same influence to pop culture like Win95.
So hopefully AMD fixes the issue or disables VME by default. If not, someone else will. Maybe VBox will offer a workaround.

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 6 of 31, by Scali

User metadata
Rank l33t
Rank
l33t

Not good for AMD's track record. This is the third time in a row that they release a new CPU architecture that has fundamental flaws (as in, not just a bunch of errata in a datasheet, with perhaps one in a million chance that you'd ever be affected by them in practice. But actual hard crashes in everyday use, easily reproducible):
Barcelona: TLB bug
Bulldozer: BSODs because of issues in power saving management
Ryzen: See above

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 7 of 31, by Carlos S. M.

User metadata
Rank Oldbie
Rank
Oldbie

For some people, this is gonna be a dealbreaker, especially with VMs and other stuff.

What is your biggest Pentium 4 Collection?
Socket 423/478 Motherboards with Universal AGP Slot
Socket 478 Motherboards with PCI-E Slots
LGA 775 Motherboards with AGP Slots
Experiences and thoughts with Socket 423 systems

Reply 8 of 31, by awgamer

User metadata
Rank Oldbie
Rank
Oldbie

Supposedly this can be worked around, obviously not optimal. The deal breaker for me is the for all cases all the time crippled memory controller; limited to two of the four memory slots at slow speed screams AMD rushed out a gimped engineering sample for launch. I'm keen to see what gets fixed with ryzen 2.0, preferably memory and vm + appreciable catch up with IPC to close that 30+% deficiency. Oh yeah, and increase the bandwidth link between cores since people are measuring a big enough performance drop there. Oh yeah 2, fix their half speed AVX implementation as well.

Reply 9 of 31, by eton975

User metadata
Rank Newbie
Rank
Newbie
Scali wrote:
Not good for AMD's track record. This is the third time in a row that they release a new CPU architecture that has fundamental f […]
Show full quote

Not good for AMD's track record. This is the third time in a row that they release a new CPU architecture that has fundamental flaws (as in, not just a bunch of errata in a datasheet, with perhaps one in a million chance that you'd ever be affected by them in practice. But actual hard crashes in everyday use, easily reproducible):
Barcelona: TLB bug
Bulldozer: BSODs because of issues in power saving management
Ryzen: See above

Amen to that.

I hear people saying that this'll never affect anyone in the real world and I just scratch my head. 32-bit Windows is still being installed and run on modern PCs and this is a huge deal because the software will just crash due to the improperly implemented INT instruction.

I hear people saying this isn't a big deal and in my mind: aren't these processors supposed to be x86-compatible and fully capable of running even the darndest old DOS software, correctly? If not, then just maybe perhaps AMD shouldn't be releasing engineering samples as commercial product and should remove the advertised support for VM86 mode from the CPUID?

I can boot into 32-bit Win7 and run 16-bit software (still round!) on any Pentium III or higher, why can't a 2017 Ryzen do the same?

Reply 10 of 31, by swaaye

User metadata
Rank Moderator
Rank
Moderator

One has to wonder how AMD would miss this during the usual rigorous validation a CPU receives. They probably just launched the CPU aware of the issue.

Reply 15 of 31, by Joey_sw

User metadata
Rank Oldbie
Rank
Oldbie
eton975 wrote:

Looks like AGESA 1.0.0.6 fixes the issue, so mobo manufacturers should be shipping new BIOS updates with this patch:

Source

Somehow i got this 'feel' that the patch would simply told VME aren't available instead of actually fixing its erronous implementation.

And there video record that VME also affecting Windows 10 PXE boot chainloader.
https://youtu.be/9e78Ui_Acf4

-fffuuu

Reply 16 of 31, by Azarien

User metadata
Rank Oldbie
Rank
Oldbie
Joey_sw wrote:

Somehow i got this 'feel' that the patch would simply told VME aren't available instead of actually fixing its erronous implementation.

But would that really matter? As I understand this, VME is just an optional extension to vm86 that allows better performance.
I think Ryzen even without VME is more than fast enough for any 16-bit application.

And there video record that VME also affecting Windows 10 PXE boot chainloader.

Or it's yet another bug... anyways, this VME issue should be fixed one way or another, no matter how many people say "who wants to run 32-bit systems on Ryzen".

I'm planning to buy a new machine and I think it'll be Ryzen, but I won't buy it unless I know this issue is fixed.

Reply 17 of 31, by Jo22

User metadata
Rank l33t++
Rank
l33t++
Azarien wrote:
Joey_sw wrote:

Somehow i got this 'feel' that the patch would simply told VME aren't available instead of actually fixing its erronous implementation.

But would that really matter? As I understand this, VME is just an optional extension to vm86 that allows better performance.
I think Ryzen even without VME is more than fast enough for any 16-bit application..

You're right, that's how it is supposed to be. But in pratice.. Who knows?
Maybe there is some piece of software out there which doesn't properly work with its built-in alternate code path.
Remember, VME was a part of the original i586. It's unlikely that the alternate code was thoroughly tested,
because only the oddball CPUs had no VME (NexGen, maybe ?).

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 18 of 31, by yuhong

User metadata
Rank Newbie
Rank
Newbie
Jo22 wrote:
You're right, that's how it is supposed to be. But in pratice.. Who knows? Maybe there is some piece of software out there which […]
Show full quote
Azarien wrote:
Joey_sw wrote:

Somehow i got this 'feel' that the patch would simply told VME aren't available instead of actually fixing its erronous implementation.

But would that really matter? As I understand this, VME is just an optional extension to vm86 that allows better performance.
I think Ryzen even without VME is more than fast enough for any 16-bit application..

You're right, that's how it is supposed to be. But in pratice.. Who knows?
Maybe there is some piece of software out there which doesn't properly work with its built-in alternate code path.
Remember, VME was a part of the original i586. It's unlikely that the alternate code was thoroughly tested,
because only the oddball CPUs had no VME (NexGen, maybe ?).

Win2000 had such a bug.

Reply 19 of 31, by Azarien

User metadata
Rank Oldbie
Rank
Oldbie
Jo22 wrote:

Maybe there is some piece of software out there which doesn't properly work with its built-in alternate code path.

If there is an alternate code path at all.. they could have thought: so our system requires Pentium "or higher", and we use VME because it's cool, and we don't even check cpuid for it, but that's okay, it's not that it is ever going away...