Re: net/asterisk22: Illegal instruction

Am Tage des Herren Sat, 21 Jun 2025 15:16:40 +0200
Guido Falsi <mad@madpilot.net> schrieb:

> On 6/21/25 14:17, A FreeBSD User wrote:
> > Hello,
> > 
> > After a recent upgrade of a 14-STABLE (14.3-STABLE #0 n271755-ef360183df81: Sat Jun 21
> > 11:23:41 CEST 2025 amd64) appliance and net/asterisk22 (poudriere build, builder host is
> > also 14-STABLE, just for the record) the asteriks binzry quits with
> > 
> > Illegal instruction (platform: PCEngine APU4C2, hw.model: AMD GX-412TC SOC).
> > 
> > Does anybody see this issue, too?
> > 
> >   
> 
> If I understand correctly you are building binaries yourself.

That is correct.

> 
> Do you use any optimization options, especially -march and similar ones?

I;m not aware of using optimizations on net/asterisk* ports themselfs but I have made a "make
rmconfig config" recently due to the same thought as of yours. On net/asterisk, I haven't
changed anything within the past few months, but I also do not track versions, my fault - so
the statement is a kind of useless. I also have no clue about faulty optimizations in
adjacent/required ports like those mutually transcribing codecs which are candidates for
vectore unit optimizations, I guess. What happened is: I exchanged my builder platform from
Intel based, much outdated Xeon Ivybridge to recent AMD Zen 5 based equipment. While  in the
bureau an older dual socket Intel Xeon performs the same task without problems, first guess is
a problem with compiling AMD Zen5 code.
 
> 
> The error could be caused by a binary optimized for a newer arch 
> supporting features (so instructions) not supported by the actual CPU 
> you're using.
> 
> It is quite possible that with the same optimizations the previous 
> version used to work and the newer one does not. Maybe the code in the 
> old version did not cause the compiler to output any instructions not 
> compatible with your CPU, while some code in the new version does.
> 
> 
> This is just one possibility though, maybe there are more possible causes.
> 
That possibility sounds reasonable, see my comment on the hardware vendor change of the CPU. I
disabled all optimization flags as far I got a handle on them and/or being aware of, so the
host is just right now a complete new repository for 14-STABLE. It did not help just disabling
the optimization flag on both net/asterisk20 and net/asterisk22 (both suffer from the same
issue). Will report back.

Kind regards,
oh



-- 

A FreeBSD user