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] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.2110231853170.38243@angie.orcam.me.uk>
Date:   Sat, 23 Oct 2021 19:44:07 +0200 (CEST)
From:   "Maciej W. Rozycki" <macro@...am.me.uk>
To:     Arnd Bergmann <arnd@...nel.org>
cc:     Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Krzysztof Adamski <krzysztof.adamski@...ia.com>,
        Oleksij Rempel <o.rempel@...gutronix.de>,
        Baruch Siach <baruch@...s.co.il>,
        Russell King - ARM Linux <linux@...linux.org.uk>,
        Daniel Tang <dt.tangr@...il.com>,
        Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
        Jamie Iles <jamie@...ieiles.com>,
        Barry Song <song.bao.hua@...ilicon.com>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Jonas Jensen <jonas.jensen@...il.com>,
        Marc Gonzalez <marc.w.gonzalez@...e.fr>,
        Hartley Sweeten <hsweeten@...ionengravers.com>,
        Lubomir Rintel <lkundrak@...sk>,
        Neil Armstrong <narmstrong@...libre.com>,
        Shawn Guo <shawnguo@...nel.org>, Alex Elder <elder@...aro.org>,
        Alexander Shiyan <shc_work@...l.ru>,
        Koen Vandeputte <koen.vandeputte@...ntric.com>,
        Hans Ulli Kroll <ulli.kroll@...glemail.com>,
        Vladimir Zapolskiy <vz@...ia.com>,
        Wei Xu <xuwei5@...ilicon.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        Mark Salter <msalter@...hat.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>
Subject: Re: Old platforms: bring out your dead

Hi Arnd,

 Old discussion, but I lost it in the mid-Jan linux-mips.org crash and 
only got my unread mailbox from that time restored recently and got at 
wading through it now.  I think an update on a couple of platforms of 
interest to me is going to be valuable anyway.

On Fri, 8 Jan 2021, Arnd Bergmann wrote:

> These are the oldest one by architecture, and they may have reached
> their best-served-by-date:
> 
> * 80486SX/DX: 80386 CPUs were dropped in 2012, and there are
>   indications that 486 have no users either on recent kernels.

 I continue using my 486DX2 box for defxx driver maintenance, as it's my 
only EISA machine.  A few years ago it suffered from a PSU failure, but 
that has been fixed now (I now have a spare PSU too, as it's an unusual 
industrial unit needed by the box due to its form factor).  Also its 16MiB 
of RAM it came with has indeed become insufficient recently, but I now 
have a 128MiB upgrade in the post, and will add another 128MiB to max it 
out once I get at suitable modules (the system requires 72-pin parity FPM 
SIMMs with gold fingers, which are uncommon at 64MiB).

 In any case I last booted 5.11.0 on it just fine and will get back at it 
once I have installed the RAM upgrade (scheduled second half of Nov; the 
box is in my remote lab, so I need to actually get there).

 FTR I also have a dual Pentium MMX box with 512MiB of RAM now installed 
and PCIe expansion.  It feels so fast after the RAM upgrade!

 There are some corner-case issues with both systems though and I have 
been posting patches to get them gradually addressed.  Expect more to 
come.

> * Alpha 2106x: First generation that lacks some of the later features.
>   Since all Alphas are ancient by now, it's hard to tell whether these have
>   any fewer users.

 I have a pair of Alpha 21064A (EV45) boxes, one of which is ready to run;
I just need to schedule some time to get an OS installed on it.  The other 
box will require some porting to get Linux run on it.  I have both of them 
locally here, so I can fiddle with them at any time.  Both have reasonable 
amounts of RAM, but I can't remember how much offhand.  Either or both my 
end up in my remote lab eventually.

> * MIPS R3000/TX39xx: 32-bit MIPS-II generation, mostly superseded by
>   64-bit MIPS-III (R4000 and higher) starting in 1991. arch/mips still
>   supports these in DECstation and Toshiba Txx9, but it appears that most
>   of those machines are of the 64-bit kind. Later MIPS32 such as 4Kc and
>   later are rather different and widely used.

 I have numerous boxes built around the R3000 and the R2000 CPU even.  All 
have booted recent Linux kernels just fine.  The R2000 box has its maximum 
of 24MiB of RAM installed, which has become a bit of a problem.  OTOH the 
R3000 boxes support up to 480MiB of RAM, and I reckon I have an odd amount 
of like 352MiB installed in one of them, which makes it work quite nicely 
even without swap.  There has been some outstanding work in the driver 
area for these; I know.

 NB I have some of these boxes wired in my remote lab and scheduled to run 
GCC CI for legacy MIPS support once I get the test harness sorted.  Based 
on my experience they should be fast enough for that purpose.

 FAOD I can boot and control, including any software changes, any machine 
in my remote lab at any time as it's been the whole point of the lab.  Of 
course any hardware change requires an actual visit.

 FWIW,

  Maciej

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ