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

[Reindl Harald]

Am 05.01.2018 um 05:51 schrieb D.S. Ljungmark:
> If you want I can bring a small form factor early x86 to Fosdem.
> 
> Industrial, rugged little things with x86 chipset was rather popular
> for a while, and you can still order them new.  The ones I have aren't
> i486 but a 586 (cyrix, I think).

i am sure you can find everything if you want

but are you running a recent distribution with the newest software on 
that box? i strongly doubt!

P.S.: what about using proper mail- clients which knows list-headers 
instead "reply-all" and break threads because the faster offlist-mail 
leading to filter out the list-mail with the headers which comes later 
or do they also not exist on such old hardware?

> On Thu, Dec 28, 2017 at 8:26 PM, 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
>>
>> if you have that old hardware normally you don't use leading edge software
>> on it and as a user (not systemd developer) i would love to see erevry
>> single line of code for 20 years old hardware is removed to make it cleaner
>> and in doubt faster on recent systems