
386-DX/SX support nuked from Linux Kernel - dfc
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=743aa456c1834f76982af44e8b71d1a0b2a82e21
======
astrodust
To think that support for something so edge-case has been supported this long
is remarkable.

Even very basic embedded x86 processors are 80486 caliber. Those more feeble
than that have no hope of running the current kernel in any meaningful
fashion.

~~~
asveikau
In 2000, someone gave me a 386 desktop that they were about to throw out, and
I ran OpenBSD on it until 2005 or so. (I was a student, so getting new
hardware was more of a big deal then.) To get it working I had to recompile
the kernel (which I did on a "more capable" Celeron 366) without support for
newfangled hardware such as USB and PCI in order to have enough memory to boot
and log in in a tolerable amount of time. (Otherwise too painful due to swap.)

So I was pretty grateful at the time that it was still working, even though
what I was doing was, now I can say with the benefit of hindsight, pretty
crazy.

~~~
SoftwareMaven
I loved my Celeron. I had a 300 which over clocked amazingly well to 450Mhz.

In fact, those were the last days of my "dinking" with hardware. The Pentium
and beyond offered such diminishing rewards that it wasn't worth it.

~~~
dspillett
Celerons of that era were very easy to officially overclock generally because
a great many of them were _underclocked_ by Intel.

They ended up with far more of the more expensive 400+MHz capable parts than
they expected to produce (presumably they were overly cautious when predicting
how well the production process would work and therefor how many of the better
rates chips thye'd get) but too few of the cheaper 300Mhz and 333MHz rated
parts that were actually selling well - so they rebadged faster units as
slower ones to fufil sales promises for the slower units.

This meant buying a machine based around a Celeron 300 or 333 (often referred
to as "Silly-rons" at the time) was a lottery: you might have got one that is
genuaninely expected not to be stable if run much faster, or you might have
got one that Intel could have sold as a 450+MHz device.

~~~
astrodust
It wasn't so much as they were underclocked, but that Intel's process was so
refined that they were often produced over-spec.

The other thing that made them so easy to over-clock was that, unlike the
Pentium Pro, II and III, there was no on-chip L2 cache that would malfunction
at higher speeds. All you were over-clocking was the CPU.

I had a dual-Celeron system that ran like a champ for the better part of ten
years.

~~~
Klinky
The binning process where higher end CPUs are marketed as lower end parts has
been going on forever.

Only the first generation Celerons (which everyone hated) had no L2 cache. The
second generation had 128KB of full-speed on-chip cache, which is actually why
it overclocked well. The Pentium II and early Pentium III had 512KB of half-
speed off-chip cache which struggled to keep up with the CPU when
overclocking.

------
lucisferre
Wait you mean it won't run Linux now even if I press the turbo button?

~~~
neovive
Wow. I miss the turbo button. They should have been required for all computers
shipping with Windows 98 through XP with the message -- "Push this button
every 10 minutes if you haven't reformatted this computer after 6 months."

------
j45
386's were the first computers I ever used Linux on. Man.

I will say this much, a 386 sx/16 was a large part of learning learn how to
get so much done with so little resources.

It's amazing how Linux was more efficient than windows even then, while the
decade of driver drought was being bridged.

~~~
kzrdude
Isn't this the platform Linus used for Linux when he started too?

~~~
pdw
That's what Ingo is referring to. "Unfortunately there's a nostalgic cost:
your [i.e. Linus'] old original 386 DX33 system from early 1991 won't be able
to boot modern Linux kernels anymore. Sniff."

Turns out Linus is not the nostalgic type.

~~~
tytso
I sent my original 40 Mhz 386 that I used when hacking Linux 0.12 back in 1991
to be recycled last year, after it was displayed on exhibit at Linux's 20th
year anniversary party. I tried to see if anyone (like the Computer Museum)
wanted it, but ultimately, I'm not the nostalgic type either.

------
Greynum
Even The Hubble Space telescope had it's processor upgraded to a 486 from a
386 and it's in space.

[http://www.theregister.co.uk/1999/12/27/hubble_telescope_get...](http://www.theregister.co.uk/1999/12/27/hubble_telescope_gets_intel/)

------
jmspring
The 386sx was a fun processor. Lack of a math coprocessor was fun to work
around. I'm surprised support lasted this long.

~~~
maximilianburke
All 386's lacked the math co-processor, the SX just had a 16-bit data bus.

~~~
sageikosa
Yep. The 486SX was the 486 with disconnected math processors that failed
quality control. The coprocessor "487" upgrade chip was simply a fully working
pin incompatible (only fit in the upgrade slot) 486.

On the 386 line, the SX/DX distinction was the equivalent of the 8088/8086
distinction for data bus width (NOTE: the 8086 was the wider processor, the
cheaper 8088 was in the IBM PC).

~~~
jmspring
Yeah, I meant the 486sx, but the little grey cells were not up to snuff when
posting that apparently.

I got a fair amount of grief about not having a math co-processor due to some
programming friends and I were doing at the time.

That said, those were the formative days where getting dirty and playing with
your machine (building your own rig) started for me. I've since given that up
since most machines are fast enough these days for my uses.

------
jrmski
Nostalgia is not as good as it used to be anyway.

~~~
jmspring
Nostalgia will return in the form of JS emulation...

~~~
mariuz
I think this patch will be needed for jslinux in the future

<http://bellard.org/jslinux/tech.html>

------
frogurt
I would have thought that support for this architecture would have been useful
to keep, since a lot of rad-hardened systems (think space, satellite
applications) still use it.

~~~
kev009
I'm into retrocomputing so these kinds of retirements always sting a bit.

In realistic long term operations, deprecations don't hurt. I.e. your air
traffic control system running on PA-RISC and HP-UX doesn't care that HP-UX
only run on Itanium now. You keep running the old software and set up some
kind of support schedule to keep the system patched during it's service life
through the vendor or otherwise.

~~~
JeremyMorgan
It's comforting to know others are interested in "retrocomputing". For some
reason I like slow old computers too. (Not being sarcastic here at all)

~~~
stusmall
I've got a soft spot for the Z80 and they were considered out of date by the
time I was born. A few years ago I found a great book on how to build a simple
microcomputer based on the Z80. I learned a ton working through that book and
that little chip brought me a lot of joy. I've still got a couple Z80s in my
part drawer... you know... just in case...

~~~
aidenn0
Z80 was only out of date when you were born if you're not TI.

------
JeremyMorgan
I love old hardware big time, but if the current kernel can be trimmed up,
let's do it. Those older machines probably shouldn't be rocking the latest
kernel anyway.

I'm typing this from a 2004 PPC Powerbook running Ubuntu 10.04. There are a
lot of packages and software I simply can't get anymore. But it's ok, because
it doesn't have the power to run them anyway. It's frozen in time, and I know
that. Anyone running on relying on 386 stuff should just stick with the older
software that's working and pray they don't have a hardware failure. If the
kernel starts packratting stuff it's going to be bloated and huge and it will
hinder future development.

Maybe they should set a time limit on stuff, like 10 years before they drop
support, or maybe 15 for the military and law offices.

------
ck2
There are always LTS older builds.

<http://xkcd.com/619/>

------
jdelsman
386-DX was my first PC. This is incredibly sad, even more so because it makes
me realize I'm getting old!

~~~
neovive
I remember my first Gateway 2000 / 486 DX2 Tower. They computer was so big,
all of my friends were envious.

------
agildehaus
I ran Windows 95 on a 386 SX 16MHz for a few months. Not amazing speed-wise,
but it worked.

Amazing little processor for its time.

~~~
yuhong
Yea, it is unfortunate MS ended up screwing the move to protected mode so
badly that it took 10 years after its release in 1985 before 32-bit
programming became popular. While Intel waiting until 1988 to release the SX
didn't help, look up the MS OS/2 2.0 fiasco (begin with "MS OS/2 2.0 SDK" and
"Microsoft Munchkins") for some pretty horrible history.

------
smegel
I never really got why back support should be an issue - its all x86
instructions, if only a subset of what is used today right? I'm curious to
know exactly what makes supporting old cpus so hard.

~~~
bdonlan
It's not just instructions - it's CPU bug workarounds, too. For example, some
386s did not honor the write-protect bit in the page table when in supervisor
mode. Now, since Linux normally does copies from kernel to userspace by
writing straight to userspace and letting the WP bit detect writes to read-
only memory, it's a problem if the WP bit doesn't work (it'd let you overwrite
write-protected userspace memory). So Linux had a check that tested (at boot
time) whether WP worked properly in supervisor mode, and if so it would set a
flag to perform a slower, software-checked copy. This adds overhead to _every_
copy from kernel to userspace, as it needs to check this flag, and branch to
the fallback implementation.

~~~
daeken
That seems... odd. Why wouldn't you just swap implementations at startup, if
it's a non-negligible performance hit?

~~~
dietrichepp
How? If you use function pointers, you end up paying more than the cost of a
branch.

~~~
daeken
Simplest way: have two implementations, copy the proper one into place (and
relocate if necessary). No overhead.

~~~
simias
Or you know, use a flag. And if it becomes a performance issue later on
_after_ some profiling, consider a more complicated approach. Don't
underestimate your CPU's branch prediction.

Self modifying code is a can of worms. Many things can go wrong, and good luck
debugging the mess.

~~~
daeken
This is all resting on the assumption that the flag does actually have an
impact, which was an argument in the original comment.

As for self-modifying code, the dangers are way overstated IMO. Having written
a lot of it as well as reverse-engineered and debugged code using self-
modifying code heavily, I look at it as just another tool in the chest. It's
pretty easy to chop your limb off using self-modifying code, but having
audited a whoooole lot of static code, I'd say that argument applies to just
about any tool.

------
kragen
Last time I tried to install Linux on a 386 (in 1998 or so) I couldn't get it
to boot anyway. I never did figure out what the problem was. The existing
Windows installation ran fine.

------
marris
Does anyone know what the speculative execution notes in processor.h are
talking about? The code seems to be trying to set up spec execution
"barriers."

What does that mean? I thought speculative execution was a micro-architecture
optimization (and the speculatively executed instructions won't be retired
until the processor knows that it wants the side-effects).

In contrast, I've only seen barriers come up for x86 at the ISA-level (and
even then, only for multiprocessors setups).

------
rpm4321
"NOOOOOOOO!!!!!!!!!!!!" \- No one

------
pjmlp
The 386SX 20 MHz was the first PC I got to buy after my trusty Timex 2068.

Along with some Amiga 500 and Amstrad PCW at school and friend's places.

Oh I'm becoming a bit nostalgic.

------
jfreak53
Just run older Linux software if it's that's important to run. There are old
archives of Linux out there to download, I myself still have Mandrake 6 and
FreeBSD 3.0 laying here in my cabinet ha ha, for just such an occasion ;) Or
in that case download Ubu 5 and get it up and running, sure no updates but
it'll run :)

------
frozenport
I wonder if this has implications for the Intel MIC, whose processors are not
dissimilar to the 386. Maybe run a 64 cluster on a single chip?

~~~
Moto7451
MICs are actually roughly based on an updated Pentium 1 (P54) platform so it
won't matter.

[http://m.extremetech.com/extremetech/#!/entry/intels-50core-...](http://m.extremetech.com/extremetech/#!/entry/intels-50core-
champion-indepth-on-xeon-phi,50a7077394f4be71692bda10/3)

------
fsiefken
i still have an old toshiba 386 laptop i used 20y ago, pretty much outdated
and outperformed by current hardware. I could run the latest linux on it but I
am not sure linux 3.7 can be made to run comfortably in 4 MB ram.

