linux-kernel - RE: [PATCH] x86/smpboot: Remove 486-isms from the modern AP boot path

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.21.2004011354050.3939520@eddie.linux-mips.org>
Date:   Wed, 1 Apr 2020 14:26:16 +0100 (BST)
From:   "Maciej W. Rozycki" <macro@...ux-mips.org>
To:     David Laight <David.Laight@...LAB.COM>
cc:     Thomas Gleixner <tglx@...utronix.de>,
        "hpa@...or.com" <hpa@...or.com>,
        Andrew Cooper <andrew.cooper3@...rix.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "x86@...nel.org" <x86@...nel.org>,
        Jan Kiszka <jan.kiszka@...mens.com>,
        James Morris <jmorris@...ei.org>,
        David Howells <dhowells@...hat.com>,
        Matthew Garrett <mjg59@...gle.com>,
        Josh Boyer <jwboyer@...hat.com>,
        Zhenzhong Duan <zhenzhong.duan@...cle.com>,
        Steve Wahl <steve.wahl@....com>,
        Mike Travis <mike.travis@....com>,
        Dimitri Sivanich <dimitri.sivanich@....com>,
        Arnd Bergmann <arnd@...db.de>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Giovanni Gherdovich <ggherdovich@...e.cz>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Len Brown <len.brown@...el.com>,
        Kees Cook <keescook@...omium.org>,
        Martin Molnar <martin.molnar.programming@...il.com>,
        Pingfan Liu <kernelfans@...il.com>,
        "jailhouse-dev@...glegroups.com" <jailhouse-dev@...glegroups.com>
Subject: RE: [PATCH] x86/smpboot: Remove 486-isms from the modern AP boot
 path

On Wed, 1 Apr 2020, David Laight wrote:

> >  Even though we supported them by spec I believe we never actually ran MP
> > on any 486 SMP system (Alan Cox might be able to straighten me out on
> > this); none that I know of implemented the MPS even though actual hardware
> > might have used the APIC architecture.  Compaq had its competing solution
> > for 486 and newer SMP, actually deployed, the name of which I long forgot.
> > We never supported it due to the lack of documentation combined with the
> > lack of enough incentive for someone to reverse-engineer it.
> 
> I also remember one of those Compaq dual 486 boxes.
> We must have has SVR4/Unixware running on it.
> 
> I suspect that any such systems would also be too slow and not have
> enough memory to actually run anything recent.

 For reasons mentioned above I cannot speak about 486 SMP systems.

 However I have a nice Dolch PAC 60 machine, which is a somewhat rugged 
luggable computer with an embedded LCD display and a detachable keyboard, 
built around a pure EISA 486 baseboard (wiring to an external display is 
also supported).  Its original purpose was an FDDI network sniffer with a 
DOS application meant to assist a field engineer with fault isolation, and 
as you may know FDDI used to have rings up to ~100km/60mi in length, so 
people often had to travel quite a distance to get a problem tracked down.

 It used to boot current Linux with somewhat dated userland until its PSU, 
an industrial unit, failed a couple years back, taking the hard disk with 
itself due to an overvoltage condition (its +12V output went up to +18V).  
I failed to repair the PSU (I suspect a fault in the transformer causing 
its windings to short-circuit intermittently, and only the +5V output is 
regulated with the remaining ones expected to maintain fixed correlation), 
which the box has been designed around, making it difficult to be replaced 
with a different PSU.

 However I have since managed to track down and install a compatible 
replacement PSU from the same manufacturer whose only difference are 
slightly higher power ratings, and I have a replacement hard disk for it 
too, so I plan to get it back in service soon.

 With 16MiB originally installed the machine is somewhat little usable 
with current Linux indeed, however the baseboard supports up to 512MiB of 
RAM and suitable modules are still available for purchase, even brand new 
ones.  Once expanded so that constant swapping stops I expect the machine 
to perform quite well, as the performance of the CPU/RAM didn't seem to be 
a problem with this machine.  We actually keep supporting slower systems 
in the non-x86 ports.

 And as I say, the userland is not (much of) our business and can be 
matched to actual hardware; not everyone needs a heavyweight graphical 
environment with all the bells and whistles burning machine cycles.

 Again, FWIW,

  Maciej