[systemd-devel] Illegal CPUID instruction causes systemd core dump

[vcaputo at pengaru.com]

On Thu, Dec 28, 2017 at 10:08:59PM +0100, Lennart Poettering wrote:
> On Do, 28.12.17 20:26, Reindl Harald (h.reindl at thelounge.net) wrote:
> 
> > 
> > 
> > Am 28.12.2017 um 20:07 schrieb tedheadster:
> > > I am doing regression testing on old hardware. systemd-233 just
> > > generated the following error on startup:
> > > 
> > > I believe it is getting an illegal instruction trap on this first
> > > generation 486 because it is calling "cpuid" in detect_vm_cpuid()
> > > without first checking if the hardware supports it; it doesn't in this
> > > case.
> > > 
> > > The gcc compiler provides a workaround in the cpuid.h header file. You
> > > can call __get_cpuid_max() first and check the return value > 0.
> > > 
> > > https://stackoverflow.com/questions/14266772/how-do-i-call-cpuid-in-linux#14266932
> > > 
> > > The Linux kernel still supports the 486 so we have to code around this
> > > case, even if it is ancient hardware
> > 
> > don't get me wrong - i am for 15 years now in the IT and my first PC in 1999
> > was a i686
> > 
> > i don't see how a brand new systemd and a mordern userland is supposed to
> > run on 20 years or older hardware where nearly eveyr distribution these days
> > is i586 or i686 only or starts to drop 32bit at all
> 
> Well, we carry compat code for m68k, hence I figure i486 support
> should be OK to have, too. I figure m68k processors are even more
> legacy than i486 is, and certainly require more porting work than i486
> does, hence i486 support should be fine to have by a long shot.
> 

Additionally Intel was still manufacturing 386 and 486 chips as recently
as 2007 [1].  Why not maintain support for such systems?  It shouldn't
be a substantial burden with a codebase that already supports 32-bit in
general.

Regards,
Vito Caputo

[1] https://www.theregister.co.uk/2006/05/18/intel_cans_386_486_960_cpus/