Discussion:
Illegal CPUID instruction causes systemd core dump
(too old to reply)
tedheadster
2017-12-28 19:07:30 UTC
Permalink
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
Post by tedheadster
I am doing regression testing on old hardware. systemd-233 just
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
Post by tedheadster
I am doing regression testing on old hardware. systemd-233 just
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
Post by Lennart Poettering
Post by tedheadster
I am doing regression testing on old hardware. systemd-233 just
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
On 12/28/2017 01:26 PM, Reindl Harald wrote:
...snippity
Post by Reindl Harald
Post by 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
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).
Post by tedheadster
I am doing regression testing on old hardware. systemd-233 just
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
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
Post by 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?
Post by D.S. Ljungmark
Post by tedheadster
I am doing regression testing on old hardware. systemd-233 just
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
Post by Reindl Harald
Post by 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.
Post by Reindl Harald
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.
Post by Reindl Harald
Post by D.S. Ljungmark
Post by tedheadster
I am doing regression testing on old hardware. systemd-233 just
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
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
Post by tedheadster
I am doing regression testing on old hardware. systemd-233 just
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
On Thu, Dec 28, 2017 at 3:18 PM, Lennart Poettering
Post by Lennart Poettering
Post by tedheadster
I am doing regression testing on old hardware. systemd-233 just
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
Post by Mike Gilbert
On Thu, Dec 28, 2017 at 3:18 PM, Lennart Poettering
Post by Lennart Poettering
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...