Discussion:
Illegal CPUID instruction causes systemd core dump
(too old to reply)
tedheadster
2017-12-28 19:07:30 UTC
Permalink
Raw Message
I am doing regression testing on old hardware. systemd-233 just
generated the following error on startup:

traps:systemd[1] trap invalid opcode ip:b7d97361 sp:bfa2f6bc error:0
in libsystemd-shared-233.so[b7d3e000+1cc000]
systemd[1]: Caught <ILL>, dumped core as pid 78.
systemd[1]: Freezing execution

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.

- Matthew
Reindl Harald
2017-12-28 19:26:06 UTC
Permalink
Raw Message
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
Lennart Poettering
2017-12-28 21:08:59 UTC
Permalink
Raw Message
On Do, 28.12.17 20:26, Reindl Harald (***@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.

Lennart

--
Lennart Poettering, Red Hat
v***@pengaru.com
2017-12-28 23:11:45 UTC
Permalink
Raw Message
On Thu, Dec 28, 2017 at 10:08:59PM +0100, Lennart Poettering wrote:
> On Do, 28.12.17 20:26, Reindl Harald (***@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/
Christopher Cox
2017-12-28 19:37:10 UTC
Permalink
Raw Message
On 12/28/2017 01:26 PM, Reindl Harald wrote:
>
>
...snippity

>> Am 28.12.2017 um 20:07 schrieb tedheadster:
>>
>> 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

While 386 was dropped in kernel 3.8, I have no idea of the plans to drop
486 support. But the assertion about distros and 32bit is certainly true.

Could be quite frustrating trying to obtain "old stuff" for testing...
D.S. Ljungmark
2018-01-05 04:51:14 UTC
Permalink
Raw Message
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).

On Thu, Dec 28, 2017 at 8:26 PM, Reindl Harald <***@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
>
> _______________________________________________
> systemd-devel mailing list
> systemd-***@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



--
8362 CB14 98AD 11EF CEB6 FA81 FCC3 7674 449E 3CFC
Reindl Harald
2018-01-05 05:47:24 UTC
Permalink
Raw Message
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 <***@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
D.S. Ljungmark
2018-01-05 20:09:35 UTC
Permalink
Raw Message
On Fri, Jan 5, 2018 at 6:47 AM, Reindl Harald <***@thelounge.net> wrote:
>
>
> 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!

Up until two years ago, yeah. Then we migrated them to ARM.

>
> 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?
>

Sure, once Evolution + Seahorse unbreaks in combination and stops
dying with gpg2.
Until then, it's sadly web-frontends.



>
>> On Thu, Dec 28, 2017 at 8:26 PM, Reindl Harald <***@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
>
> _______________________________________________
> systemd-devel mailing list
> systemd-***@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



--
8362 CB14 98AD 11EF CEB6 FA81 FCC3 7674 449E 3CFC
Lennart Poettering
2017-12-28 20:18:10 UTC
Permalink
Raw Message
On Do, 28.12.17 14:07, tedheadster (***@gmail.com) wrote:

> I am doing regression testing on old hardware. systemd-233 just
> generated the following error on startup:
>
> traps:systemd[1] trap invalid opcode ip:b7d97361 sp:bfa2f6bc error:0
> in libsystemd-shared-233.so[b7d3e000+1cc000]
> systemd[1]: Caught <ILL>, dumped core as pid 78.
> systemd[1]: Freezing execution
>
> 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.

Please send a patch for this. We lack the relevant hardware and
can't test this. In fact, for most such portability support for
less-than-mainsrtream systems we rely on external patches.

Lennart

--
Lennart Poettering, Red Hat
Mike Gilbert
2017-12-28 21:29:06 UTC
Permalink
Raw Message
On Thu, Dec 28, 2017 at 3:18 PM, Lennart Poettering
<***@poettering.net> wrote:
> On Do, 28.12.17 14:07, tedheadster (***@gmail.com) wrote:
>
>> I am doing regression testing on old hardware. systemd-233 just
>> generated the following error on startup:
>>
>> traps:systemd[1] trap invalid opcode ip:b7d97361 sp:bfa2f6bc error:0
>> in libsystemd-shared-233.so[b7d3e000+1cc000]
>> systemd[1]: Caught <ILL>, dumped core as pid 78.
>> systemd[1]: Freezing execution
>>
>> 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.
>
> Please send a patch for this. We lack the relevant hardware and
> can't test this. In fact, for most such portability support for
> less-than-mainsrtream systems we rely on external patches.

I created a PR for this. I have not tested it on a VM, or on an i486.
Hopefully one of the CI systems can cover the former case. ;-)

https://github.com/systemd/systemd/pull/7758
tedheadster
2017-12-29 03:25:41 UTC
Permalink
Raw Message
On Thu, Dec 28, 2017 at 4:29 PM, Mike Gilbert <***@gentoo.org> wrote:
> On Thu, Dec 28, 2017 at 3:18 PM, Lennart Poettering
> <***@poettering.net> wrote:
>>
>> Please send a patch for this. We lack the relevant hardware and
>> can't test this. In fact, for most such portability support for
>> less-than-mainsrtream systems we rely on external patches.
>
> I created a PR for this. I have not tested it on a VM, or on an i486.
> Hopefully one of the CI systems can cover the former case. ;-)
>
> https://github.com/systemd/systemd/pull/7758

This patch worked nicely. I think Lennart wants you to clean up the
formatting, but I can confirm the first draft is functional.

Thank you for the speedy response.

- Matthew
Loading...