[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: CPU requirements for powerpc

Your evidence is compelling.  Even if it doesn’t present a smoking gun.
It definitely looks like you’ve got enough material for a bug report against syslog-ng.
You can always add to the bug report later when you have a suggested patch.


On Oct 9, 2016, at 1:58 AM, Christoph Biedl <debian.axhn@manchmal.in-ulm.de> wrote:

> Rick Thomas wrote...
>> Can you give us some more details?
> In general I'm somewhat reluctant since first conclusions are usually
> wrong and I certainly don't want to create noise at the wrong place.
> So I'd rather debug a little longer until I can identify the real
> cause, and create a patch to prove I was right. So yesterday I would
> wrongly have blamed openssl, now it rather looks like pcre3. Which
> still might not be true.
> But since I'm rather busy today doing other things, here are the bits
> if you want to take over:
>> 1) Which debian (stable/testing/sid)?
>> 2) Which packages?
>> 3) Which G4 boxes?
> This is Debian stretch, package is syslog-ng 3.7.3-3, box is a
> PowerMac G4 running a "7410, altivec supported" CPU.
> Rebuild syslog-ng, you should see four errors in the test suite, the
> first being
> | PASS: lib/transport/tests/test_aux_data
> | ../../test-driver: line 107: 77989 Illegal instruction     "$@" > $log_file 2>&1
> This is triggered by ./lib/logproto/tests/test_logproto, started
> without any parameters.
> Using gdb you will encounter SIGILL in the libcrypt initialization,
> that's ok, openssl probes the CPU capabilities (see above). Second
> time it's something like
> | #0  0xb7faf008 in ?? ()
> | #1  0x0fc42a38 in ?? () from /lib/powerpc-linux-gnu/libpcre.so.3
> | #2  0x0fc67c20 in ?? () from /lib/powerpc-linux-gnu/libpcre.so.3
> where disassemble shows different instructions when tried again, it's
> either "mflr" or "mr". Next step would be to identify where the actual
> instruction comes from and how the code path is triggered. Also big
> question why this doesn't happen more often.
> The package used to build with 3.7.3-1 back in July, the changes in
> syslog-ng are minimal, and nothing obvious in pcre3 (was 2:8.38-3.1,
> now it's 2:8.39-2).
> Godspeed, and please share any findings so I can focus on other
> issues.
>    Christoph

Reply to: