" Is it really needed in 2012 to support using a non-SMP i486 kernel on Slackware? "
 

Well, the question is not mine. It is actually Pat's question, posed in extra folder... and the suggestion to open a thread is also Pat's. So I am just taking the initiative, and let's hear some thoughts...

In slackware-current/extra/linux-3.2.13-nosmp-sdk/ , Pat asks...

The actual quote:

"But is it really needed in 2012 to support using a
non-SMP i486 kernel on Slackware?"

So we are talking about removing non-smp i486 kernel? Fine by me.

Was it ever "needed"? My understanding is that the smp-enabled kernels work fine on uni-processor machines.


IMO the huge/generic split doesn't have much value either. I'd be in favour of simplifying this further and just having a single kernel option..

Yes, I agree... even several ARM processors are SMP-capable, so I don't see any point in keeping this in the current mainstream of Slackware. Architectures with memory exclusively dedicated to a single or uni-processor are extremely rare nowadays...

I would vote for a "just drop it"...

As far as I understand the SMP kernel requires i686 at minimum. While I don't see the specific need for a non-SMP kernel, there is still i486 SoC hardware out there, like Soekris. As long as the Linux developers support these, there should at least be left an option in Slackware.

I am not really an expert, but sticking to Wikipedia (http://en.wikipedia.org/wiki/Symmetric_multiprocessing) even since those days of 486 and Pentium-Pro processors, a good bunch of them were already smp-capable.

As long as the Linux developers support these, there should at least be left an option in Slackware. <--- amen to that!

The distribution needs to have as an install option a kernel that will boot on a non-SMP system of the lowest order. This could be a very limited kernel which would allow a older unit to boot, and then it would be up to the user to configure and compile it as required for their system.

I suspect that Slackers are quite capable of building their own kernels.

There was a poll on this in late 2010. http://www.linuxquestions.org/questi...o-i686-834806/

I did have a simple server running 13.37 http://www.linuxquestions.org/questi...3/#post4448588 that required the non-SMP kernel, but it was reverted to running Windows98 late last year. As Hangdog42 pointed out in that thread
I also have some old machines running Windows that I have imaged by booting using the non-SMP kernel from a Slackware 12 install disk with additional support for NTFS added. I actually needed to use an earlier version of Slackware for this as 13.37 requires 128MB RAM. A typical live CD like SystemRescueCd requires even more RAM to boot. I mention this to qualify the point that guzzi made. The distribution already has support for non-SMP systems of the lowest order via the earlier versions, but such systems have physical limits that cannot accommodate the latest huge kernel and associated binaries in the installer.

duron 900 512 mb

IMHO, in topic: no, non-SMP kernels today is not needed for PC's, but need to leave the opportunity to build your own kernel.

Perhaps. But the generic is needed by some (like those who need to disable NOUVEAU to run the NVIDIA proprietary).

I vote for smp only. This will provide a fine excuse for me to clean out my office! I can run older slackware or build my own kernel if needed. A huge kernel is ok, esp. for boot install, as most systems these days have plenty of RAM. The generic kernel should stay, since one doesn't need to load every tom, dick and harry module into memory if you don't have it.

Er no you don't NOUVEAU is a module in both kernels.

Correct. If you want Nvidia you need to blacklist nouveau regardless of kernel, or compile a new kernel.

SMP kernels have always worked on UP machines. The point of UP kernels is that they save locking overhead required for SMP operation.

To answer OP'S question "Is it really needed in 2012 to support using a non-SMP i486 kernel on Slackware?": I run a few UP machines (Pentium 3 class) that I keep up-to-date on Slackware. However, I compile my own kernels, so I for once could live with Slackware shipping only SMP kernels. I also include other patches in my kernels for better desktop interactivity, which are particularly benefitial on an older UP machine.

Actually, I was thinking more along the lines of keeping 'generic' (or something very close to it) and dropping 'huge'.

Dropping the non-SMP kernel would currently prevent anyone from installing Slackware on Pentium M machines, since the SMP kernel has PAE enabled by default, which is not supported by Pentium Ms with Banias core.
So the non-SMP kernel is at least necessary to build a SMP kernel with PAE disabled.

The SMP kernel in Slackware 13.37 doesn't have PAE enabled, so that must have been changed in -current.

Yes, it has. Even the SMP-kernels from 13.37's /testing have PAE enabled.

Yes, it has.... That's how I found this threat.
I've got a DELL Latitude D800 with an Intel pentium M processor and it doesn't support pae.
I'm looking at the "This kernel requires the following features not present on the CPU: pae" error message on my console.
I've been using the hugesmp kernel since forever until now....
Well... Let's compile a kernel that doesn't need pae..... It's a rainy sunday afternoon...

So far in this thread the 'pae' and 'cmov' CPU flags have been identified as being important to identifying processors that may be affected by not having a non-SMP kernel. Can anybody suggests amendments to this?

I admin a fair number of Slackware boxes and a good number of those do not have SMP capable processors. Most are lower end or older processors that still have lots of useful life left in them. I'd hate to see Slackware become another jump on the bandwagon of the "latest and greatest only" mentality.

PAE was first enabled in the Pentium Pro in 1995. Not really "the latest and greatest". But you are right, there must be at least one kernel that runs everywhere to be used as platform to compile a new one.

SergMarkov in a other forum writes about the patch for non-SMP kernels which makes enabled a proprietary video driver for them. But I think these patches just include the SMP-kernel configuration options, although I have not seen these patches. Maybe it?

Well guys,

First, thanks to yars for reactivating the thread.

It looks like there is not really a consensus... at some point looked like majority is in favour of letting the non-SMP support, although is not really overwhelming. If Pat has been peeking a bit here, I reckon he has already made his mind up.

In few days, unless the thread shows an increase in activity, I will be closing it. Hope to hear some few more comments.

Cheers...

Slackware should be able to boot and install on any 486 or newer system. After installation, the user could build his own kernel as needed, but basic functionality should be there.

So yes, there should be an option to boot an "old non-smp" kernel on the installation disc along with "hugesmp" and all the others.

AFAIK, Slackware is a prime choice for old machines, so it wouldn't be a bad idea to keep support.

At the same time, my old Pentium-M computer can't even boot 13.1 because it doesn't have enough RAM. Perhaps some instructions for building a non-smp kernel can be provided, and we can move up to an SMP kernel?

Either way, I doubt I would notice the difference in an SMP-enabled kernel much.

And how are you building a non-SMP kernel if your machine isn't able to run the SMP kernel?

Point taken. Then it could go the other way - make the stock kernel non-SMP, and have instructions for rebuilding the kernel with SMP support.

Actually, that sounds like work that doesn't need to be done. People who really need SMP support know where to get it, and if they don't, any amount of knowledge can be sufficiently replicated by Google.

EDIT: Hold on, Slackware already ships with both kernels - the question is whether the non-SMP kernel gets shipped at all. Whoops!

I say yes then. Eventually those old machines will go by the wayside, but they haven't quite yet. </edit>

On what mashines is older than Pentium 4 (Socket 478 - Prescott, if I am not mistaken) can run the SMP-kernel?

The SMP kernel in its -current form can run on any CPU that does support PAE. So anything newer then Pentium Pro (except the Banias Pentium Ms) and Athlon can run that kernel. That this kernel supports SMP does not mean that it need multi-core, multi-CPU or Hyperthreading machine.

Then, the more it makes sense to abandon the non-SMP kernel. I think, a very old machines are not so much to worry about compatibility with them.

I personally think that Slackware should not drop support for the Pentium Ms and the K6-II(I) CPUs (and may be some of the VIA CPUs, I can't find information about the status of PAE on those chips). Slackware is well known for running without problems on older hardware, and many people still use those machines, especially in countries were newer hardware is expensive and money is in short supply. Dropping the non-SMP kernel would basically mean dropping recent Slackware for those people.

Of course a simple work-around for this situation would be to not enable PAE by default in the SMP kernel and then drop the non-SMP one. A user that needs PAE can easily compile a kernel with PAE enabled. That is simply not possible the other way around.

Or am I missing something? Question: Why is PAE enabled in the newer SMP kernels?

The main problem is, that a PAE capable kernel can't boot on a Non-PAE machine and a Non-PAE kernel can't use more than 4 gigabytes of memory.

Actually that's a design flaw in the Linux kernel and must be fixed upstream. PAE should be detected at runtime and activated if available.

While the first of those is a problem, the second is merely an inconvenience. I'm with Tobi' smp-enabled/pae-disabled default kernel looks to be the best option to get everyone up and running. Those who need PAE can enable it themselves post-install.

Perhaps this is part of the "Your mileage may vary" claim. I had tried and tried to install NVIDIA, but NOUVEAU was always being loaded with the huge, preventing the proprietary from being installed. Blacklisting seemed to never work for me. Then I tried the generic, and low and behold the blacklisting worked. Perhaps I was missing something - but this was how I got it to work for my machines.

On a very old machines, such as Pentium-Pro based, PAE is not needed for works. Also, find the parts for these machines every day is all more is difficult.

that's true i just installed slack on a friends machine since it is the only kernel without pae that could be used.

Too much overhead :o

i personally not use hardware running on slack, who not be minima of i686
on other hand - i see, there is be folks, who used old i586 hardware with current slack.
i think, then we can see, what bonus we have if going to i686 smp only - there is huge gap in performance? or in what? if we have a significant leap from going to i686 kernel, when we have consider that. if no - i cannot see, why not sit on an old tradition...?

As a reminder the question is asked by Pat in a file called BROKEN.TXT in /extra. This doesn't say why but I would tend to guess what he had in mind: less maintenance work and/or less payload for the ISO's and/or the installer, possibly making room for other stuff (only a guess, of course). Meanwhile, I also saw this post which you could interpret as "we will keep non-SMP" -- or not as this is not explicitly stated.

Anyway it amazes what how Pat's "offhand comments" (in his own words) can (certainly unwillingly) spread FUD in our very sensitive community. Or trigger what we call here "une tempête dans un verre d'eau" :)

As a side note I find sometimes difficult to really understand if reactions from us are expected or not, probably because English is not my native language.

It's about the pain, isn't it--compatibility. I was going to say that, if other-than-very-painful, please retain non-smp compatibility if-only for memory reasons.

Up until a month ago, I had Actual i486 & Ppro industrial pc's running it. Purely for space reasons, threw it all out (after a protracted moment of silence and some mental rhapsodizing about damned kids not appreciating kilobytes) and replaced it all with wall-wart-driven "gadgets".

It's not just another lame Geezer-nostalgia rant, more a commentary on a lost decade of an economy. The industrial stuff...well few have had anything to spend on capital equipment for a Good While (tm).

Arguably a narrow use-case, but I'd bet it's larger than people think. New software doesn't support old hardware. Old hardware comes as part of 6- and 7-figure machinery and equipment. Retrofitting/upgrades are within 25% of all-new hardware (aka prohibitive to financial people seeking ever-faster paybacks).

Okay, it turns-out this was a Geezer-rant. It's just a reaction from having been through this pinch a few times before in other forms. Heavy machines and equipment last for decades. Talking to them is ever-more-difficult, but that's not Pat's problem and it's not any of the Slackware Team's problem. I have nothing but gratitude for them.

If i486 survives another rev--great! After that, call it a nice-to-have and let the world move-on (but light a candle first and scream "Gawd save the Queen!", will you?)

Please explain.