Linux Kernel Starts Retiring Support for AMD's 30-Year-Old K5 CPUs (phoronix.com) 91
Linux 7.1 started phasing out support for Intel's 37-year-old i486 processor. Linux 7.2 removed drivers for the old AMD Elan 32-bit systems on a chip.
And now some i586 and i686 class processors are being removed, reports Phoronix: Supporting those vintage GPUs without the Time Stamp Counter "TSC" instruction are becoming a burden... TSC-capable Intel Pentium processors and the likes will still be supported with this just being for TSC-less i586/i686 CPUs. Among the CPUs impacted by this latest change is the AMD K5 as well as various Cyrix processor models. The K5 was AMD's first entirely in-house designed processor that was first introduced in 1996 to counter the Intel Pentium CPU.
TSC "support can now be assumed as a boot requirement for modern Linux," the article points out, which will allow the removal of various non-TSC code paths from the Linux kernel's x86 code.
Tom's Hardware remembers the K5 "wasn't a very popular processor as it arrived late, then offered lackluster performance in the competitive environment it joined." Launch SKUs in 1996 were limited to clocks from 75 MHz to 133 MHz, and, due to being late, Intel's Pentium line was already faster. AMD still managed to get an edge on the Cyrix 6x86, though.
And now some i586 and i686 class processors are being removed, reports Phoronix: Supporting those vintage GPUs without the Time Stamp Counter "TSC" instruction are becoming a burden... TSC-capable Intel Pentium processors and the likes will still be supported with this just being for TSC-less i586/i686 CPUs. Among the CPUs impacted by this latest change is the AMD K5 as well as various Cyrix processor models. The K5 was AMD's first entirely in-house designed processor that was first introduced in 1996 to counter the Intel Pentium CPU.
TSC "support can now be assumed as a boot requirement for modern Linux," the article points out, which will allow the removal of various non-TSC code paths from the Linux kernel's x86 code.
Tom's Hardware remembers the K5 "wasn't a very popular processor as it arrived late, then offered lackluster performance in the competitive environment it joined." Launch SKUs in 1996 were limited to clocks from 75 MHz to 133 MHz, and, due to being late, Intel's Pentium line was already faster. AMD still managed to get an edge on the Cyrix 6x86, though.
Damn, I'm old (Score:2)
Re: (Score:3)
I'm still a bit miffed after buying a 6x86 and then Quake being released later in the year. It ran terrible. https://liam-on-linux.livejour... [livejournal.com]
Re: (Score:2)
The FPU on the Cyrix 6x86 chips was definitely their weak point. I had one and it struggled to play a MP3 while multitasking. On the other hand, the AMD K6-2/3 chips could play an MP3 in the background and it barely affected what I was doing. For non-FPU heavy tasks though the 6x86 was certainly competitive with the Pentium chips and was a good alternative for things like office work.
Re: (Score:2)
I remember building a bunch of Cyrix boxes for in-house use at my second job out of uni. It was an interesting time for x86-compatible processors, it seemed like the x86-compatible ecosystem was going to expand with a whole bunch of manufacturers getting in on it, some with very different approaches (remember Transmeta?). Didn't really work out that way though.
Cyrix is tied to that pinball 2000 (Score:2)
Cyrix is tied to that pinball 2000
Re: (Score:2)
Transmeta was purchased by Apple, and that's where the Apple A-series chips came from.
Re: Damn, I'm old (Score:2)
Re: (Score:3)
The first processor maker to print "Fan/Heatsink Required" on their processors.
Cyrix chips (including original Cyrix, Centaur, and VIA) were an amazing value and bargain.
Cyrix P200+ was my first CPU. (Score:2)
It was awesome. I even got this special grafics card calles Matrox Mystique which had this very special function: It would specifically support enhanced gaming(!). A brand new concept, can you imagine?
Re: (Score:2)
I had 3dfx Voodoo cards and S3 ViRGE along with other commercial video card failures back then, heheh.
Re: (Score:2)
To be fair, the 3Dfx Voodoo / Voodoo2 and Voodoo Banshee were the best you could get at the time. Then they decided to compete with their customers by releasing the Voodoo3 series, and literally every one of their customers started licensing Nvidia Riva TNT / TNT2.
3Dfx was a dead company 2 years later, with Nvidia buying the asset portfolio, and Nvidia SLI was born.
Re: (Score:2)
Re: (Score:2)
Ahh, the Mystique. I also had one. No texture filtering, no mipmapping, no alpha blending, no fog. 3D looked almost identical to software rendering and rarely ran much better. It basically achieved similar visuals to the original PlayStation - 2 years after the PlayStation launched - but the number of games the Mystique actually supported was tiny. There were only 12 Matrox Simple Interface API games, and the D3D support was atrocious; most D3D games simply didn't work at all.
Best you can say about it was i
Re: Damn, I'm old (Score:2)
Re: (Score:2)
I had K5 and Cyrix 6x86, but I quite supporting them about 30 years ago.
Child, I had a Cyrix math co-processor for my 286 computer.
Speaking of "old", did you know that there was an 80186 microprocessor? The company I worked for made its own custom controller board using that chip. I had thought it was only ever used as an embedded processor, but just recently I learned that there was at least one PC produced that used a 186.
Re: (Score:3)
Speaking of "old", did you know that there was an 80186 microprocessor? The company I worked for made its own custom controller board using that chip. I had thought it was only ever used as an embedded processor, but just recently I learned that there was at least one PC produced that used a 186.
Research Machines built weird PCs in the 80s based around the 186. It was almost PC compatible but had to have its own special versions of DOS and Windows 2. Unfortunately Research Machines had some kind of lock on the UK education sector, so schools that weren't still using BBC Micros or Acorn Archimedes machines, had these strange 90% IBM-compatible abominations. (Just looked it up, it was called the "RM Nimbus")
Re: (Score:2)
I remember the nimbus!
My school had a network of discless machines.
They could also boot into BBC mode with a reasonably good BBCBasic interpreter and RM mode as xxx well.
They were pretty good in their niche, really though the Archi was a fool 32 bit very fast RISC computer that knocked the competition into a cocked hat. Struggled on a bit but then vanquished into the embedded space until a few years ago.
Re: (Score:2)
Child, I had a Cyrix math co-processor for my 286 computer.
Damn youngsters with their PC ATs, grumble, grumble...
I had a good old XT, with a CGA green monochrome monitor, chock full with 640k of RAM (which, let me tell you, was sufficient for everybody!) and an enormous 20MB hard disk, so big the OS couldn't even conceive such a thing can exist - so I had to split it in a 4MB partition and a 16 Mb one!
You haven't had fun until you played "The Secret of Monkey Island" on a 320 x 200 pixels screen in 4 shades of green, with PC beep sounds.
Re: (Score:3)
This FA is about Linux dropping support for "AMD K5 as well as various Cyrix processor models", I think your dodo is long out-of-support.
Re: (Score:2)
Around 1990, I worked for a couple months on an embedded device that had an 80186 and a megabyte of RAM. At one point, I had access to a huge pile of 1MB SIMMs and took a stack home for the evening and using memory boards that allowed you to stack up to 8 of them into one SIMM slot in your computer to figure out just how little RAM Windows NT 3.5 really needed to boot. It booted successfully with 12MB of RAM. It really wasn't usable, but it did boot up. Nowadays, Windows is probably only marginally usa
That's okay Linux, I retired you in 1998. (Score:1)
Re: (Score:2)
The K5 wasn't bad.
Cyrix was shit. The only way they could compete was to overclock the bus, which fucked up your PCI and AGP slot timings because everything was a multiple of the main system bus. Instead of running it at 66Mhz they decided that 75 gets them where they want on the CPU, with their customers not realizing that they are running the PCI bus at 38Mhz instead of 33; and any AGP slot at 75 instead of 66, and how that might just screw up a GPU that was designed to run at peak performance with a st
Just go 64 bit only at this point (Score:1)
Re:Just go 64 bit only at this point (Score:5, Insightful)
Hardly. Windows 11 depreciated perfectly viable hardware. On the flip side trying to get a modern Linux distribution running on a K5 would be like a trip to the dentist. Actually you could do both because your system probably won't have finished booting by the time your dentist is done with your root canal ;-)
There's a big difference between depreciating a 8 year old CPU and a 37 year old CPU.
Re: (Score:3)
There's a big difference between depreciating a 8 year old CPU and a 37 year old CPU.
The Windows fanbois are not rational.
Re: (Score:1)
Re: (Score:2)
More than that - are there any improvements happening to 32-bit Linux that would have any positive effect on a 25-year old system?
At some point you just surround it in bricks and let it go as long as it's gonna go.
Re: (Score:2)
Actually, yes. The improvements and speedup to swap in 7.0 and later would have their biggest impacts on the machines that swap the hardest with the least CPU/bandwidth available... aka the stuff that's getting dropped. I may still do up a 6.17 vs 7.0 test on my Soekris 486s just to see what could have been for giggles.
Re: (Score:2)
How about a modern kernel on a 486? https://github.com/Sharktastic... [github.com]
Re: (Score:2)
Wrong question. It's no "how" about a modern kernel, it's "why" a modern kernel? What are you doing with your 486? Is it sitting in the corner humming away controlling the building AC, or are you live connected to the internet running some endpoint from a cloud connection?
Before we talk about using modern kernels on old hardware the question is why are we not using modern hardware for the purpose.
Obsolescence is a thing as well, when considering the idea of "it still works" you have to also ask what happens
No (Score:2)
The problem is that chips like the Vortex86 (still in production) are getting caught up in this. I use the Vortex86 for other purposes, but by losing Linux support the Vortex86 will go out of production that much sooner. (Of note, gamers like the Vortex86 because it runs classic videogames natively.)
More generally this is a sign of a kernel-wide "cleanup" effort where stuff that's old is getting yoinked for no particular reason. I used the Minix filesystem pretty regularly and I am certain that is going to
Re: (Score:2)
More generally this is a sign of a kernel-wide "cleanup" effort where stuff that's old is getting yoinked for no particular reason.
The particular reason is that their time and effort is finite. If very few people are using them, then it is being removed from future versions as they do not want to keep maintaining them. Remember that your current versions do not suddenly stop working. Also if someone else wants to maintain it, they can. They will not maintain it.
Re: (Score:2)
Is there some purge of all previous versions of the kernel underway from every system in existence, or can you continue to run the version you're running today, forever?
Re: (Score:2)
Re: (Score:2)
Can you define the problem that fits into the Venn diagram of requiring this particular chip while also needing to run on Linux 7.2, and as you formulate your answer do so in a way that takes into account that 6.18 (LTS) will still support this thing first hand for another 2.5 years, and will continue to have backported support in distributions for years after that as well, so only include problems that will still exist in the 2030s.
Re: (Score:2)
On the flip side trying to get a modern Linux distribution running on a K5 would be like a trip to the dentist. Actually you could do both because your system probably won't have finished booting by the time your dentist is done with your root canal ;-)
For future versions of Linux, it will be more difficult to get running on a K5. Current working versions are not affected. However, I cannot imagine anyone running a K5 now needs all the new features of 7.2 going forward. They can continue to use the 7.1 kernel and older.
Re: (Score:2)
> depreciated
You keep using that word. I do not think it means what you think it means.
Re: (Score:2)
You are right, seems like I mistranslated it.
Re: (Score:3)
Re: (Score:2)
Not sure the situation is comparable.
A lot of modern software will work on an older kernel. The difference between successive Linux kernels tends to be device-driver driven, not feature driven. Even when new features are implemented, usually they don't result in new APIs, and if the APIs are extended or modified, it's very often (usually?) the case that only certain tools would need it.
Your problem getting GNOME 257 to work on K5 is more likely (1) have you ever used GNOME? and (2) more specifically, memory
Re: (Score:1)
No, because Linux isn't shitty.
alternatively (Score:5, Insightful)
The K5 was a fantastic budget CPU. It slid rather neatly between 486 and P5 performance, outperforming the highest end 486 units while being cheaper, and for most non multimedia home/desktop PC use of the day did not offer an experience that suffered much vs Pentium machines.
IMHO it was good chip it was not marked to the right segment by AMD, and the Wintel cartel also was in place that kept it out of the market segment where it needed to be anyway.
Re: (Score:2)
Indeed. I had one and I was quite satisfied with it. No idea why they feel the need to portray it as a near-failure.
Re: (Score:1)
It was economically a near-failure, and it was a commercial product, so that's how you measure its level of success.
They were late bringing it to market, so the performance was underwhelming, which is why it failed in the market. Few people will buy an underdog without a clear price advantage.
The K6 had that clear price advantage, and it and its variants were successful in the market. They sold a lot of units. It was very common to find them in laptops because they were cheap and relatively power efficient,
Re: (Score:2)
The K6-2+ and K6-3+ with their huge caches really changed the landscape of Super Socket 7.
It was ever so slightly too little, too late. Super Socket 7 lived about three years longer than it should have, but I saved a ton of money building computers on that platform.
DIY PC (Score:2)
Re: (Score:2)
Super Socket 7 lived about three years longer than it should have, but I saved a ton of money building computers on that platform.
Same here. I had a Cyrix 6x86 and a couple of different K6s including a K6/3+ before I went to Slot 1 and then Slot A, and it's been all AMD since...
Re: (Score:2)
There were problems if you didn't know what to look for, and in the early days of the Internet, people didn't know what to look for.
Namely: crap motherboards that would overclock the PCI or AGP busses, crap motherboards that would share interrupts between PCI and AGP slots, and due to the presence of ISA bus devices, could not enter the world of PCI bus mastery and edge-level triggered interrupts.
Also, there were problems with Windows 95 that would cause random bluescreens and shit if you didn't load some s
Re: (Score:2)
Aside from being low performance and late to market, there were other challengers as well, such as Cyrix and later Centaur. So there were alternatives for PC buyers to shop, if they were into this level of detail
Re: (Score:2)
Same here but this lack of support will matter much less than dropping i486.
There are still embedded systems sold today that only meet i486 specs. I don't use them but some industries do.
Sure a $12 ESP32 can handle those tasks but it's a revalidation thing.
Not that anybody from those vendors stepped forward to maintain a tree.
Pare down the bloat (Score:2)
Surely, the kernel could benefit from a concerted effort to pare down support for devices that are 30+ years past their prime and focus more on chasing bugs?
Re: Pare down the bloat (Score:1)
Re: Pare down the bloat (Score:5, Insightful)
That's a bit short sighted. While a 37 year old CPU is no longer useful, 10-15 year old hardware is not only perfectly viable but actually widely and actively used. I myself am running a modern up to date Linux on a 14 year old CPU with adequate performance and have zero intention to change it unless something physically breaks in the short term.
There's no reason to depreciate hardware unless a specific feature is absent (maybe things will change if we mandate TPMs - but right now that is optional for every Linux distro)
Re: (Score:2)
This there decision needs to reflect the actual support costs. Right now x86-64v2 is probably the least common denominator in terms of not requiring a lot of special hoops to support. Maybe you could argue x86-64v1 stuff is still viable but I'd counter you have a lot of instruction set inconsistency there in those products and from a performance and efficiency perspective it probably does not make sense to be using them as daily drivers of contemporary software.
Re: (Score:2)
You are overlooking what is used in the industrial field.
Re: (Score:2)
Not really. The industrial field isnt trying to use the latest kernels or software. They are trying to run some LTS release that does support their hardware and they don't want software changes other than fixes for all the same reasons they don't want to implement hardware changes.
I am not suggesting still supported LTS releases should dump old hardware. However there is no reason anyone realistically should be spending time trying to get first gen althon64s supported on Linux 7.0. There may be no-reaso
Re: (Score:2)
Well, an LTS kernel only lives so long and that is a problem. Maybe they should so a sort-of extreme LTS that gets security patches for 20 years and then drop all the old drivers from newer kernels.
Re: (Score:2)
This there decision needs to reflect the actual support costs. Right now x86-64v2 is probably the least common denominator in terms of not requiring a lot of special hoops to support. Maybe you could argue x86-64v1 stuff is still viable but I'd counter you have a lot of instruction set inconsistency there in those products and from a performance and efficiency perspective it probably does not make sense to be using them as daily drivers of contemporary software.
Wouldn't v2 be backwards compatible w/ v1, the way CPUs are designed? What exactly would have been introduced into v2 that would have broken v1 compatibility to the point that one would need separate codebases for each? I can understand the 32-bit vs 64-bit argument, but not this
Re: (Score:2)
The point is that you want to start optimizing for contemporary-ish instructions and feature sets, which often perform a lot better. Yes you can continue to target v1 and it will work on v2 and v3, but you're leaving a lot on the table, or you make separate paths v1 and v2+ but now you have added effort to support v1.
At some point it is time to say goodbye to v1 support in the mainline branch.
Re: Pare down the bloat (Score:4, Insightful)
Re: (Score:2)
I'm on a Q820 from 17 years ago at home.
Still runs fine, still had more RAM and disc than a number of new laptops which is a bit sad.
Re: (Score:2)
Indeed. My firewall / fileserver is on an 18 year old Phenom II 4-core with 32GB RAM and there is no need to replace it. The only thing that broke about 8 years ago was the PSU. Replaced that and it is good fore the foreseeable future.
Re: (Score:2)
Same thing here. My firewall/router is a core 2 duo box that set me back $35. I would like to replace it but it keeps chugging along without complaint.
Re: (Score:2)
Then you do not understand how long some industrial equipment runs. "Older kernel" is only a solution if it gets maintenance. You do want that MRI machine taking your pictures to run on a maintained kernel, do you?
Re: Pare down the bloat (Score:4, Informative)
You do want that MRI machine taking your pictures to run on a maintained kernel, do you?
That would be nice, but odds are it runs an unmaintained version of Windows, and there is no upgrade path — neither the drivers nor the software have been updated for a newer version. I've been spending a lot of time in hospitals and dentists' offices lately and virtually everything runs on Windows.
Re: (Score:2)
I guarantee you due to vendor licensing agreement the version of Windows it was running when it was brand new was also well out of date without the current patches applied. In reality I want that machine to sit on a closed network without easy access to the internet.
Re: Pare down the bloat (Score:2)
Re: (Score:2)
A stock kernel on an MRI machine?
No, I don't want that level of DIY on any equipment that is critical to anything.
Almost nobody runs stock kernels. Stock kernels are used by distributions to build their own kernels.
That MRI machine is running on a 1.2 kernel. Maybe 2.0. It's separated from the hospital network by a firewall.
If the MRI machine is getting attacked then a LOT has gone wrong already.
Re: (Score:2)
If industrial equipment is running a 37 year old cpu, it isn't getting new software.
Re: (Score:2)
Then you do not understand how long some industrial equipment runs. "Older kernel" is only a solution if it gets maintenance. You do want that MRI machine taking your pictures to run on a maintained kernel, do you?
No I don't and it most certainly wasn't running on an up to date kernel even when it was new and under maintenance. I want that MRI machine on a protected network and locked down to not have internet facing functions.
But interesting choice of shock example. I actually don't really care if that MRI machine will get compromised. It's not like the PC gives the operator the option to kill or otherwise maim the person in it, nor does the machine make a medical decision based on the materials that it comes from.
Re: Pare down the bloat (Score:2)
If the MRI reports are mixed between patients due to hacks, it could lead to incorrect medical decisions. You still want some level of security. While MRI don't expose you to radiation, CT and xray machines do, and that requires proper security.
Re: (Score:2)
If the MRI reports are mixed between patients due to hacks, it could lead to incorrect medical decisions. You still want some level of security. While MRI don't expose you to radiation, CT and xray machines do, and that requires proper security.
MRIs can be dangerous too... wouldn't want to be in an MRI during a magnetic quench.
Re: (Score:2)
I want the MRI to run on whatever allows it to generate a valid imaging. I don't give two fucks if it runs a 10 year old kernel, or a 10 day old kernel.
There are ways to keep things secure through network sequestration if you have an embedded system that isn't getting updates - this isn't a new concept, and we've been doing that since embedded systems started existing.
Re: (Score:2)
Sorry, but what a first world, rich baby comment!
Not all world can afford new computers and computers with 15 years are perfectly good... sure, you can't play top games there, but still are great for working, web, servers, NAS, home automation, etc. In many countries, you use what you can get and old distros mean most of the time lack of updates and security issues.
386, 486, k5, pentium (1, the first) are now too old and too slow, any RPi, arm board or very old computer is faster, cheaper to run and easier
Re: (Score:2)
What I'd rather they do is start creating more APIs for userland device drivers so stuff can be moved out of the kernel without breakages. Obviously for stuff like processors, that's not practical. But for drivers of older hardware, from network cards (especially Wi-Fi) to ISA industrial controllers, it'd be a god-send.
Re: (Score:2)
Why? Drivers are drivers. Ultimately they are required to run with the kinds of privileges where bugs will allow memory access, arbitrary code execution, and privilege escalation. You can't move things to the userland without also breaking the functionality, and if you provide enough access to retain the functionality then bugs become just as severe.
Re: (Score:2)
Because you're moving the responsibility from the kernel developers to whoever wants the drivers to continue to exist. I thought that was obvious.
It's a hell of a lot easier to have third parties maintain small projects than have them be a part of the Linux kernel development team and have every single change they want to make approved by a single dictator, however benevolent.
Re: (Score:2)
I think everything over 10 or 15 years should be ripped out of the current kernel to keep the bloat down, if someone has older hardware they can run an older version of the kernel or find an older distro version, there are old versions still available for download
No thanks, half of the systems around here are over a dozen years old.
Re: (Score:3, Informative)
Surely, the kernel could benefit from a concerted effort to pare down support for devices that are 30+ years past their prime and focus more on chasing bugs?
These devices are being removed now because supporting them is becoming difficult now. There was no need to remove them for that reason before. There is a need to remove them for that reason now. That's why it's happening now. HTH, HAND.
Re: (Score:2)
Something like not having TSC (which itself comes in several variants depending on whether it's from the era where you actually had 'a' CPU that just ran at a speed, or if it's one of the ones that tries to compensate for the complications of variable clocks and multiple cores) presumably comes up in a variety of nasty places related to the bad things that happen when things are
Re: (Score:2)
Surely, the kernel could benefit from a concerted effort to pare down support for devices that are 30+ years past their prime and focus more on chasing bugs?
I can certainly understand ending support for 32-bit CPUs if 64-bit is now the norm
However, I don't get why beyond that, older CPUs have to be abandoned. I know that's not what was mentioned in this article, but if AMD introduced the Athlon-64 and the Opteron-64, I don't see why support for them needs to drop, since they use the same instruction set as today's Ryzens, sans whatever AMD may have introduced since. Since it's a subset, it can be a common base, and anything specific to newer CPUs can be add
Welp, over to NetBSD (Score:1)
Welp, time to go over to NetBSD.
what is Debian going to do (Score:2)
Re: (Score:2)
Seriously? That is not happening soon.
There is a Toy Story 5 next month.
Re: (Score:2)
Why do you think Debian has a two year release cycle? I didn't bother to count them but there's got to be at least 50 characters mentioned here [wikipedia.org]. That gives them a century, assuming Toy Story 6 bombs, Disney is outlawed, and nobody writes any fan fiction that ever takes off...
I'm taking this far too seriously aren't I? ;-)
Re: (Score:3)
When they run out of Toy Story characters to name their releases after???
Maybe Debian will just commission Pixar to write yet another Toy Story?
Meanwhile, MIPS still plods along (Score:2)
Meanwhile, MIPS still plods along.
Think of all the traffic lights and other embedded systems that will stop working had they not chosen MIPS for them.
Re: (Score:2)
Why do people think that embedded systems that don't get kernel updates will stop working because kernel maintainers are not supporting 40 year old hardware for next year's kernel release?
It's not like every previous kernel winks out of existence the instant a new version is published. They can go right on running Linux 6.x on their 40 year old hardware forever.