Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Per a random forum I found[forums.overclockers.co.uk], it sounds like the Gigabyte P35C-DS3R supports that instruction (out of the box?) (and the Abit IP35 Pro XE does with a possibly-custom BIOS - which is the subject of that thread - but the link to said BIOS backup is dead).
It's a bit weird that Steam would care about this, though. I take it you've already reached out to Steam's support?
https://github.com/ValveSoftware/steam-for-linux/issues/7046
If I understood it correctly this instruction needs to run properly to ensure secure execution of libcef (the embeded browser used for store pages, forums and now the games library)... the update is likely there to enforce steam to run only when the instruction is available, for security reasons, even if games would actually work without it...
maybe they can be persuaded to change the behaviour into running it like "steam --no-browser" instead of refusing entirely to run... this does mutilate the app but allows installing, updating and launching games, setting up controllers, etc... the store and etc can be used via an external browser, so it looks like a good compromise without risking security.
edit: i doubt steam is clever enough, but maybe try running "steam --no-browser" yourself and see if it lets you use it then... it should, but probably won't, but still worth trying
anyway, support for a legacy OS (winXP) may seem like a "don't touch it and it will keep working" affair, but is in fact quite hard... supporting software over legacy hardware in a recent OS is a bit easier (with the Linux Kernel to back you up) but still throws some curveballs
in any case, maybe you can use Lutris / GameHub / Gnome Games or some similar opensource launcher without a builtin browser to help run Steam games in that vintage PC via a modern linux distro? WinXP is *really* a bad idea if the machine isn't completely isolated from the rest of the world... and even then why not linux instead?
Unless it's for a museum exhibit... then you need to get old versions of Steam to match up with the hardware and the OS!
I'm running Ubuntu 18.04 and my CPU meets all the named requirements (it's a Xeon E5450). It really sucks to not be able to play the games I've payed for and have been enjoying up to now.
then
did any of you try it already?
Same error on my machine with Xeon X5460. I submitted an issue to the Steam Support yesterday. Let's see if this can be fixed.
Also, if you haven't already, definitely validate that the required CPU flags are indeed reported (i.e. "grep flags /proc/cpuinfo" and ensure that the lm, cx16, and pni flags are all present). If they are, then Valve done goofed. If they aren't, well, Valve still done goofed IMO (if it ain't broke why fix it) but there's likely not much you can do beyond replacing the CPU and/or motherboard.
For my X5460 /proc/cpuinfo really shows only cx8.
Motherboard info:
I'll wait for Support's feedback on this issue. I would also like to know are these new requirements applied to Linux only or Windows is also affected (but I do not have windows installed).
Still, requirements state that Pentium 4 is required to run Steam Client, so Valve should change requirements in this case, or revert the changes made in the last client update.
As a side-note, AFAIK microcode can be updated by Linux distros at boot too, so it's a bit odd that it exists and was missing for you, in particular for CPU microcode... other microcodes obviously aren't as carefully curated, but this is IMHO a bit of an unexpected gap.
bypassing the cpu feature check is annoying as a permanent solution but it may at least serve as confirmation that the feature works as intended and is simply undetected / or that it is now actually broken