Re: php-fpm (7.4, 8.0) on armv7 doesn't work

[George Koehler]

On Wed, 11 May 2022 21:06:57 +0200
Sven Wolf  wrote:

> ===>  Building package for apache-httpd-2.4.53p1
> Create /usr/packages/arm/all/apache-httpd-2.4.53p1.tgz
> Error: Libraries in packing-lists in the ports tree
> and libraries from installed packages don't match

I often see this kind of error on macppc, when its snapshot packages are
too old.  arm/armv7 is slowest, and macppc/powerpc is 2nd slowest, when
the platforms build snap packages.  I would try to pass this error by
downdating the library's port to match my installed package, with
"cvs up -D -MM-DD", because I got my ports from anoncvs.  Another
way is to try PKG_CREATE_NO_CHECKS from bsd.port.mk(5).  Either way
might fail.

I would have wanted to add the snap package of apache-httpd, instead
of building it.  This command might have helped,
$ make prepare FETCH_PACKAGES=

> On Monday the new snapshot packages for the arm/armv7 platform were 
> pushed to the mirrors.
> And now my php-fpm problem, I've tested php-8.0.17p2 and php-8.1.4p1, is 
> solved. In my opinion the cause for my issue was, that I use a snapshot 
> operating system but the last snapshot packages for armv7 were build on 
> 2021-11-16.

Good, then we don't need the DEBUG=-g build.

I had studied your crashing instruction,

> (gdb) disas $pc,$pc+1
> Dump of assembler code from 0x510a0fc to 0x510a0fd:
> => 0x0510a0fc:vst1.64 {d16-d17}, [r1]
> End of assembler dump.
> (gdb) print $r1
> $1 = 1849557212

I'm not sure, but this vst1.64 might store an 8-byte double-precision
float to the address in r1.  This address 1849557212 was 4 more than a
multiple of 8, so the double was misaligned.

I have no hardware that would SIGBUS here.  I instead wrote a small
program using ptrace(2) to trap and emulate the double stores on
powerpc, because I know how a powerpc cpu stores doubles (stfd, stfdx).
I found no misaligned double stores while tracing php-fpm-8.0 from
powerpc's php-8.0.17p2; every address was a multiple of 8.  This is
consistent with your report that arm's php-8.0.17p2 doesn't SIGBUS.

--George

Re: php-fpm (7.4, 8.0) on armv7 doesn't work

[Stuart Henderson]

On 2022/05/11 21:06, Sven Wolf wrote:
> 
> 
> On 5/9/22 12:43, Stuart Henderson wrote:
> > You might get some more usable trace if you build PHP yourself including
> > debug symbols ("make FETCH_PACKAGES= prepare && make DEBUG=-g package")
> > and run that.
> > 
> > Even if we know whether the SIGBUS is due to misaligned access or one of
> > the other conditions that can result in this, without a backtrace it
> > will be hard to find which source code is involved.
> > 
> 
> I tried to build the php8 port with debug informations but I got the
> message:
> 
> ===>  Building package for apache-httpd-2.4.53p1
> Create /usr/packages/arm/all/apache-httpd-2.4.53p1.tgz
> Error: Libraries in packing-lists in the ports tree
>and libraries from installed packages don't match
> 
> I used the snapshot ports.tar.gz on my armv7 snapshot system.
> 
> On Monday the new snapshot packages for the arm/armv7 platform were pushed
> to the mirrors.
> And now my php-fpm problem, I've tested php-8.0.17p2 and php-8.1.4p1, is
> solved. In my opinion the cause for my issue was, that I use a snapshot
> operating system but the last snapshot packages for armv7 were build on
> 2021-11-16.

Oh right, it didn't click that you would have been using old packages..
yes those are not really expected to work though I wouldn't have expected
the SIGBUS. And in the meantime the arm package build for 7.1 finished
so you got newer packages.

> If I'm wrong please correct me. But maybe I should not use snapshot on the
> armv7 platform. The snapshots for the operating system are quite often
> updated. But the snapshots for the packages are rebuild not so frequently
> (in contrast to the amd64 platform). And this could lead to some errors.
> I also could stay on the snapshot based operating system and build my
> required ports. But how can I prevent that the required build dependencies,
> like apr, brotli for php8 are pulled as packages (which maybe don't match)?
> In my opinion for the armv7 platform it also makes sense that the required
> build dependencies are build from the ports and are not used from (the
> outdated) packages.

It takes something like 6 weeks to build arm packages, so there is
pretty much 0 chance of them being in sync for a snapshot.

In a nutshell: if you use armv7 and want to use pre-built packages,
stick to releases, and you'll need to wait some time after the main
release is finished before arm packages are available.

If you're running -current snapshots then you'll need to build your
own packages from ports.

Re: php-fpm (7.4, 8.0) on armv7 doesn't work

[Sven Wolf]

On 5/9/22 12:43, Stuart Henderson wrote:
You might get some more usable trace if you build PHP yourself including 
debug symbols ("make FETCH_PACKAGES= prepare && make DEBUG=-g package") 
and run that.


Even if we know whether the SIGBUS is due to misaligned access or one of 
the other conditions that can result in this, without a backtrace it 
will be hard to find which source code is involved.




I tried to build the php8 port with debug informations but I got the 
message:


===>  Building package for apache-httpd-2.4.53p1
Create /usr/packages/arm/all/apache-httpd-2.4.53p1.tgz
Error: Libraries in packing-lists in the ports tree
   and libraries from installed packages don't match

I used the snapshot ports.tar.gz on my armv7 snapshot system.

On Monday the new snapshot packages for the arm/armv7 platform were 
pushed to the mirrors.
And now my php-fpm problem, I've tested php-8.0.17p2 and php-8.1.4p1, is 
solved. In my opinion the cause for my issue was, that I use a snapshot 
operating system but the last snapshot packages for armv7 were build on 
2021-11-16.


If I'm wrong please correct me. But maybe I should not use snapshot on 
the armv7 platform. The snapshots for the operating system are quite 
often updated. But the snapshots for the packages are rebuild not so 
frequently (in contrast to the amd64 platform). And this could lead to 
some errors.
I also could stay on the snapshot based operating system and build my 
required ports. But how can I prevent that the required build 
dependencies, like apr, brotli for php8 are pulled as packages (which 
maybe don't match)? In my opinion for the armv7 platform it also makes 
sense that the required build dependencies are build from the ports and 
are not used from (the outdated) packages.


Thanks,
Sven

Re: php-fpm (7.4, 8.0) on armv7 doesn't work

[Sven Wolf]

On 5/9/22 06:53, George Koehler wrote:

On Sat, 7 May 2022 19:23:18 +0200
Sven Wolf  wrote:


Reading symbols from php-fpm-8.0...(no debugging symbols found)...done.
[New process 413320]
Core was generated by `php-fpm-8.0'.
Program terminated with signal SIGBUS, Bus error.
#0  0x0510a0fc in ?? ()
(gdb) bt
#0  0x0510a0fc in ?? ()
#1  0x0510a0e4 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)


This SIGBUS might be an alignment trap, if your armv7 needs strict
alignment.  Misaligned integers don't cause alignment traps on amd64,
i386, powerpc, nor powerpc64; so I probably can't reproduce this
SIGBUS on my computers.  Someone with aarch64, mips64, riscv64, or
sparc64 might or might not reproduce it.

Can you cause egdb to disassemble the trapped instruction, and print
its registers?  The command,
(gdb) disas $pc,$pc+1
might show the instruction.  If a register like "r0" appears in the
instruction, then "print $r0" might print it.

For example, I made a core dump of a misaligned float on powerpc:

(gdb) disas $pc,$pc+1
Dump of assembler code from 0x1fde0a18 to 0x1fde0a19:
=> 0x1fde0a18 :lfs f1,1(r3)
End of assembler dump.
(gdb) print $f1
$1 = 0
(gdb) print $r3
$2 = 3043988480


Here is the disassembled output:
egdb php-fpm-8.0 /var/crash/php-fpm-8.0/3047.core
...
Reading symbols from php-fpm-8.0...(no debugging symbols found)...done.
[New process 413320]
Core was generated by `php-fpm-8.0'.
Program terminated with signal SIGBUS, Bus error.
#0  0x0510a0fc in ?? ()
(gdb) bt
#0  0x0510a0fc in ?? ()
#1  0x0510a0e4 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) disas $pc,$pc+1
Dump of assembler code from 0x510a0fc to 0x510a0fd:
=> 0x0510a0fc:   vst1.64 {d16-d17}, [r1]
End of assembler dump.
(gdb) print $r1
$1 = 1849557212
(gdb)

In the next step I'll try to build the php port with debug symbols.

Sven

Re: php-fpm (7.4, 8.0) on armv7 doesn't work

[Stuart Henderson]

You might get some more usable trace if you build PHP yourself including 
debug symbols ("make FETCH_PACKAGES= prepare && make DEBUG=-g package") and 
run that.


Even if we know whether the SIGBUS is due to misaligned access or one of 
the other conditions that can result in this, without a backtrace it will 
be hard to find which source code is involved.


--
 Sent from a phone, apologies for poor formatting.

On 9 May 2022 05:54:13 George Koehler  wrote:


On Sat, 7 May 2022 19:23:18 +0200
Sven Wolf  wrote:


Reading symbols from php-fpm-8.0...(no debugging symbols found)...done.
[New process 413320]
Core was generated by `php-fpm-8.0'.
Program terminated with signal SIGBUS, Bus error.
#0  0x0510a0fc in ?? ()
(gdb) bt
#0  0x0510a0fc in ?? ()
#1  0x0510a0e4 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)


This SIGBUS might be an alignment trap, if your armv7 needs strict
alignment.  Misaligned integers don't cause alignment traps on amd64,
i386, powerpc, nor powerpc64; so I probably can't reproduce this
SIGBUS on my computers.  Someone with aarch64, mips64, riscv64, or
sparc64 might or might not reproduce it.

Can you cause egdb to disassemble the trapped instruction, and print
its registers?  The command,
(gdb) disas $pc,$pc+1
might show the instruction.  If a register like "r0" appears in the
instruction, then "print $r0" might print it.

For example, I made a core dump of a misaligned float on powerpc:

(gdb) disas $pc,$pc+1
Dump of assembler code from 0x1fde0a18 to 0x1fde0a19:
=> 0x1fde0a18 :lfs f1,1(r3)
End of assembler dump.
(gdb) print $f1
$1 = 0
(gdb) print $r3
$2 = 3043988480

Re: php-fpm (7.4, 8.0) on armv7 doesn't work

[George Koehler]

On Sat, 7 May 2022 19:23:18 +0200
Sven Wolf  wrote:

> Reading symbols from php-fpm-8.0...(no debugging symbols found)...done.
> [New process 413320]
> Core was generated by `php-fpm-8.0'.
> Program terminated with signal SIGBUS, Bus error.
> #0  0x0510a0fc in ?? ()
> (gdb) bt
> #0  0x0510a0fc in ?? ()
> #1  0x0510a0e4 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb)

This SIGBUS might be an alignment trap, if your armv7 needs strict
alignment.  Misaligned integers don't cause alignment traps on amd64,
i386, powerpc, nor powerpc64; so I probably can't reproduce this
SIGBUS on my computers.  Someone with aarch64, mips64, riscv64, or
sparc64 might or might not reproduce it.

Can you cause egdb to disassemble the trapped instruction, and print
its registers?  The command,
(gdb) disas $pc,$pc+1
might show the instruction.  If a register like "r0" appears in the
instruction, then "print $r0" might print it.

For example, I made a core dump of a misaligned float on powerpc:

(gdb) disas $pc,$pc+1
Dump of assembler code from 0x1fde0a18 to 0x1fde0a19:
=> 0x1fde0a18 :lfs f1,1(r3)
End of assembler dump.
(gdb) print $f1
$1 = 0
(gdb) print $r3
$2 = 3043988480

Re: php-fpm (7.4, 8.0) on armv7 doesn't work

[Sven Wolf]

On 5/7/22 17:52, Stuart Henderson wrote:

On 2022/05/07 14:30, Sven Wolf wrote:



On 5/7/22 12:11, Stuart Henderson wrote:

Do you also get a crash from e.g. "php-8.0 -i"?

If so, can you run that under gdb and try and get a backtrace?

pkg_add gdb
egdb php-8.0
set args -i
run
bt



php-8.0 -i runs without any problems.


In that case, can you try and get php-fpm to save a core??

sysctl kern.nosuidcoredump=3
mkdir /var/crash/php-fpm-8.0
(trigger the crash)

Hopefully you'll have a core in /var/crash/php-fpm-8.0; if so,
point gdb at it and backtrace:

egdb php-fpm-8.0 /var/crash/php-fpm-8.0/12345.core
bt



I got the crash dumps, but for me there are no useful informations :(

cat /var/log/php-fpm.log
[07-May-2022 19:12:16] NOTICE: fpm is running, pid 89312
[07-May-2022 19:12:16] NOTICE: ready to handle connections
[07-May-2022 19:12:16] WARNING: [pool www] child 3047 exited on signal 
10 (SIGBUS - core dumped) after 0.664546 seconds from start

[07-May-2022 19:12:16] NOTICE: [pool www] child 66691 started
[07-May-2022 19:12:17] WARNING: [pool www] child 80860 exited on signal 
10 (SIGBUS - core dumped) after 0.980099 seconds from start

[07-May-2022 19:12:17] NOTICE: [pool www] child 62432 started
[07-May-2022 19:12:17] WARNING: [pool www] child 66691 exited on signal 
10 (SIGBUS - core dumped) after 0.370234 seconds from start

[07-May-2022 19:12:17] NOTICE: [pool www] child 89043 started
...

For the pid 89312 there is not crashdump


egdb php-fpm-8.0 /var/crash/php-fpm-8.0/3047.core 



GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-unknown-openbsd7.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from php-fpm-8.0...(no debugging symbols found)...done.
[New process 413320]
Core was generated by `php-fpm-8.0'.
Program terminated with signal SIGBUS, Bus error.
#0  0x0510a0fc in ?? ()
(gdb) bt
#0  0x0510a0fc in ?? ()
#1  0x0510a0e4 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)


sbc3# egdb php-fpm-8.0 /var/crash/php-fpm-8.0/66691.core 



GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-unknown-openbsd7.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from php-fpm-8.0...(no debugging symbols found)...done.
[New process 456848]
Core was generated by `php-fpm-8.0'.
Program terminated with signal SIGBUS, Bus error.
#0  0x0510a0fc in ?? ()
(gdb) bt
#0  0x0510a0fc in ?? ()
#1  0x0510a0e4 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)


sbc3# egdb php-fpm-8.0 /var/crash/php-fpm-8.0/80860.core 



GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-unknown-openbsd7.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from php-fpm-8.0...(no debugging symbols found)...done.
[New process 546453]
bCore was generated by `php-fpm-8.0'.
Program terminated with signal SIGBUS, Bus error.
#0  0x0510a0fc in ?? ()
t(gdb) bt
#0  0x0510a0fc in ?? ()
#1  0x0510a0e4 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

Re: php-fpm (7.4, 8.0) on armv7 doesn't work

[Stuart Henderson]

On 2022/05/07 14:30, Sven Wolf wrote:
> 
> 
> On 5/7/22 12:11, Stuart Henderson wrote:
> > Do you also get a crash from e.g. "php-8.0 -i"?
> > 
> > If so, can you run that under gdb and try and get a backtrace?
> > 
> > pkg_add gdb
> > egdb php-8.0
> > set args -i
> > run
> > bt
> > 
> 
> php-8.0 -i runs without any problems.

In that case, can you try and get php-fpm to save a core??

sysctl kern.nosuidcoredump=3
mkdir /var/crash/php-fpm-8.0
(trigger the crash)

Hopefully you'll have a core in /var/crash/php-fpm-8.0; if so,
point gdb at it and backtrace:

egdb php-fpm-8.0 /var/crash/php-fpm-8.0/12345.core
bt

Re: php-fpm (7.4, 8.0) on armv7 doesn't work

[Sven Wolf]

On 5/7/22 12:11, Stuart Henderson wrote:

Do you also get a crash from e.g. "php-8.0 -i"?

If so, can you run that under gdb and try and get a backtrace?

pkg_add gdb
egdb php-8.0
set args -i
run
bt



php-8.0 -i runs without any problems.

php-8.0 -i
phpinfo()
PHP Version => 8.0.10

System => OpenBSD sbc3.fusion-zone.net 7.1 GENERIC#35 armv7
Build Date => Oct 26 2021 18:40:20
Build System => OpenBSD armv7-1.ports.openbsd.org 7.0 GENERIC#80406 armv7
Configure Command =>  './configure'
...


Here is the output of 'egdb php-8.0'
 egdb php-8.0
GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-unknown-openbsd7.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from php-8.0...(no debugging symbols found)...done.
(gdb) set args -i
(gdb) run
Starting program: /usr/local/bin/php-8.0 -i

Program received signal SIGILL, Illegal instruction.
0x7ffcfee0 in _armv8_pmull_probe () at 
/usr/src/lib/libcrypto/armv4cpuid.S:91

91  /usr/src/lib/libcrypto/armv4cpuid.S: No such file or directory.
(gdb) bt
#0  0x7ffcfee0 in _armv8_pmull_probe () at 
/usr/src/lib/libcrypto/armv4cpuid.S:91
#1  0x7ffda950 in OPENSSL_cpuid_setup () at 
/usr/src/lib/libcrypto/armcap.c:69
#2  0x77570b2c in _dl_call_init_recurse (object=0x9440d600, 
initfirst=initfirst@entry=0) at /usr/src/libexec/ld.so/loader.c:831
#3  0x775709ec in _dl_call_init_recurse (object=0x8161cc00, 
initfirst=initfirst@entry=0) at /usr/src/libexec/ld.so/loader.c:806
#4  0x775709ec in _dl_call_init_recurse (object=object@entry=0x8bf39000, 
initfirst=0) at /usr/src/libexec/ld.so/loader.c:806
#5  0x7757c544 in _dl_call_init (object=0x8bf39000) at 
/usr/src/libexec/ld.so/loader.c:776
#6  _dl_boot (argv=, envp=, 
dyn_loff=, dl_data=0xbfff1a3c) at 
/usr/src/libexec/ld.so/loader.c:697

#7  0x7757cb08 in _dl_start () at /usr/src/libexec/ld.so/arm/ldasm.S:61
#8  0x7757cb08 in _dl_start () at /usr/src/libexec/ld.so/arm/ldasm.S:61
...



The manual start of php-fpm-8.0 shows following warning message. But 
also the comment of line 143 doesn't solve the problem.


/usr/local/sbin/php-fpm-8.0
[07-May-2022 13:36:54] WARNING: Nothing matches the include pattern 
'/etc/php-fpm.d/*.conf' from /etc/php-fpm.conf at line 143.




Here is the output of '/usr/local/sbin/php-fpm-8.0'
egdb /usr/local/sbin/php-fpm-8.0 



GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-unknown-openbsd7.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/sbin/php-fpm-8.0...(no debugging symbols 
found)...done.

(gdb) run
Starting program: /usr/local/sbin/php-fpm-8.0

Program received signal SIGILL, Illegal instruction.
0x87bf4ee0 in _armv8_pmull_probe () at 
/usr/src/lib/libcrypto/armv4cpuid.S:91

91  /usr/src/lib/libcrypto/armv4cpuid.S: No such file or directory.
(gdb) bt
#0  0x87bf4ee0 in _armv8_pmull_probe () at 
/usr/src/lib/libcrypto/armv4cpuid.S:91
#1  0x87bff950 in OPENSSL_cpuid_setup () at 
/usr/src/lib/libcrypto/armcap.c:69
#2  0x644b0b2c in _dl_call_init_recurse (object=0x5d0c6200, 
initfirst=initfirst@entry=0) at /usr/src/libexec/ld.so/loader.c:831
#3  0x644b09ec in _dl_call_init_recurse (object=0x70f88000, 
initfirst=initfirst@entry=0) at /usr/src/libexec/ld.so/loader.c:806
#4  0x644b09ec in _dl_call_init_recurse (object=object@entry=0x8ad54000, 
initfirst=0) at /usr/src/libexec/ld.so/loader.c:806
#5  0x644bc544 in _dl_call_init (object=0x8ad54000) at 
/usr/src/libexec/ld.so/loader.c:776
#6  _dl_boot (argv=, envp=, 
dyn_loff=, dl_data=0xbffc6a3c) at 
/usr/src/libexec/ld.so/loader.c:697

#7  0x644bcb08 in _dl_start () at /usr/src/libexec/ld.so/arm/ldasm.S:61
#8  0x644bcb08 in _dl_start () at /usr/src/libexec/ld.so/arm/ldasm.S:61
...

After I populated /usr/src (src.tar.gz and sys.tar.gz from 
https://ftp.artfiles.org/openbsd/7.1/) there is no file 

Re: php-fpm (7.4, 8.0) on armv7 doesn't work

[Stuart Henderson]

Do you also get a crash from e.g. "php-8.0 -i"?

If so, can you run that under gdb and try and get a backtrace?

pkg_add gdb
egdb php-8.0
set args -i
run
bt

Re: php-fpm (7.4, 8.0) on armv7 doesn't work

[Sven Wolf]

I'm sorry,

I didn't provide enough information.
For me this issue is an new one on the armv7 platform. I installed 
php-fpm the first time on the armv7 platform. On amd64 I use it for a 
long time without any issues.


Here is the dmesg output for this sbc.

OpenBSD 7.1-current (GENERIC) #35: Tue May  3 06:34:09 MDT 2022
dera...@armv7.openbsd.org:/usr/src/sys/arch/armv7/compile/GENERIC
real mem  = 954212352 (910MB)
avail mem = 924856320 (882MB)
random: good seed from bootblocks
mainbus0 at root: LeMaker Banana Pi
cpu0 at mainbus0 mpidr 0: ARM Cortex-A7 r0p4
cpu0: 32KB 32b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache
cpu0: 256KB 64b/line 8-way L2 cache
cortex0 at mainbus0
psci0 at mainbus0: PSCI 0.0
sxiccmu0 at mainbus0
agtimer0 at mainbus0: 24000 kHz
simplebus0 at mainbus0: "soc"
sxiccmu1 at simplebus0
sxipio0 at simplebus0: 175 pins
sxirtc0 at simplebus0
sxisid0 at simplebus0
ampintc0 at simplebus0 nirq 160, ncpu 2: "interrupt-controller"
"system-control" at simplebus0 not configured
"interrupt-controller" at simplebus0 not configured
"dma-controller" at simplebus0 not configured
"spi" at simplebus0 not configured
"lcd-controller" at simplebus0 not configured
"lcd-controller" at simplebus0 not configured
"video-codec" at simplebus0 not configured
sximmc0 at simplebus0
sdmmc0 at sximmc0: 4-bit, sd high-speed, mmc high-speed, dma
"usb" at simplebus0 not configured
"phy" at simplebus0 not configured
ehci0 at simplebus0
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Generic EHCI root hub" rev 
2.00/1.00 addr 1

ohci0 at simplebus0: version 1.0
"crypto-engine" at simplebus0 not configured
"hdmi" at simplebus0 not configured
sxiahci0 at simplebus0: AHCI 1.1
sxiahci0: port 0: 3.0Gb/s
scsibus0 at sxiahci0: 32 targets
sd0 at scsibus0 targ 0 lun 0:  
naa.5001b44e30ed56ae

sd0: 120196MB, 512 bytes/sector, 246162672 sectors, thin
ehci1 at simplebus0
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Generic EHCI root hub" rev 
2.00/1.00 addr 1

ohci1 at simplebus0: version 1.0
"timer" at simplebus0 not configured
sxidog0 at simplebus0
"ir" at simplebus0 not configured
"codec" at simplebus0 not configured
sxits0 at simplebus0
com0 at simplebus0: dw16550
com0: console
com1 at simplebus0: dw16550
com2 at simplebus0: dw16550
sxitwi0 at simplebus0
iic0 at sxitwi0
axppmic0 at iic0 addr 0x34: AXP209
sxitwi1 at simplebus0
iic1 at sxitwi1
"gpu" at simplebus0 not configured
dwge0 at simplebus0: rev 0x00, address 02:8a:07:xx:xx:xx
rgephy0 at dwge0 phy 1: RTL8169S/8110S/8211 PHY, rev. 5
"hstimer" at simplebus0 not configured
"display-frontend" at simplebus0 not configured
"display-frontend" at simplebus0 not configured
"display-backend" at simplebus0 not configured
"display-backend" at simplebus0 not configured
gpio0 at sxipio0: 32 pins
gpio1 at sxipio0: 32 pins
gpio2 at sxipio0: 32 pins
gpio3 at sxipio0: 32 pins
gpio4 at sxipio0: 32 pins
gpio5 at sxipio0: 32 pins
gpio6 at sxipio0: 32 pins
gpio7 at sxipio0: 32 pins
gpio8 at sxipio0: 32 pins
usb2 at ohci0: USB revision 1.0
uhub2 at usb2 configuration 1 interface 0 "Generic OHCI root hub" rev 
1.00/1.00 addr 1

usb3 at ohci1: USB revision 1.0
uhub3 at usb3 configuration 1 interface 0 "Generic OHCI root hub" rev 
1.00/1.00 addr 1

simplefb0 at mainbus0: 720x576, 32bpp
wsdisplay0 at simplefb0 mux 1
wsdisplay0: screen 0-5 added (std, vt100 emulation)
scsibus1 at sdmmc0: 2 targets, initiator 0
sd1 at scsibus1 targ 1 lun 0:  removable
sd1: 14804MB, 512 bytes/sector, 30318592 sectors
umass0 at uhub0 port 1 configuration 1 interface 0 "SanDisk Cruzer 
Blade" rev 2.10/1.00 addr 2

umass0: using SCSI over Bulk-Only
scsibus2 at umass0: 2 targets, initiator 0
sd2 at scsibus2 targ 1 lun 0:  removable 
serial.07815567130824104331

sd2: 14939MB, 512 bytes/sector, 30595072 sectors
umass1 at uhub1 port 1 configuration 1 interface 0 "SanDisk Cruzer 
Blade" rev 2.10/1.00 addr 2

umass1: using SCSI over Bulk-Only
scsibus3 at umass1: 2 targets, initiator 0
sd3 at scsibus3 targ 1 lun 0:  removable 
serial.07815567130824111405

sd3: 14944MB, 512 bytes/sector, 30605312 sectors
vscsi0 at root
scsibus4 at vscsi0: 256 targets
softraid0 at root
scsibus5 at softraid0: 256 targets
bootfile: sd0a:/bsd
boot device: sd0
root on sd0a (af9d22e08b6bb901.a) swap on sd0b dump on sd0b

Thanks,
Sven

On 5/6/22 19:08, Sven Wolf wrote:

Hi list,

I tried to use php-fpm (php-7.4.23p0 and php-8.0.10p0) on my LeMaker 
Banana Pi (armv7).


I always get following error messages (/var/log/php-fpm.log)

[06-May-2022 18:45:21] NOTICE: fpm is running, pid 10910
[06-May-2022 18:45:21] NOTICE: ready to handle connections
[06-May-2022 18:45:21] WARNING: [pool www] child 60509 exited on signal 
10 (SIGBUS) after 0.061336 seconds from start

[06-May-2022 18:45:21] NOTICE: [pool www] child 33092 started
[06-May-2022 18:45:21] WARNING: [pool www] child 33092 exited on signal 
10 (SIGBUS) after 0.010144 seconds from start

[06-May-2022 18:45:21] NOTICE: [pool www] 

php-fpm (7.4, 8.0) on armv7 doesn't work

[Sven Wolf]

Hi list,

I tried to use php-fpm (php-7.4.23p0 and php-8.0.10p0) on my LeMaker 
Banana Pi (armv7).


I always get following error messages (/var/log/php-fpm.log)

[06-May-2022 18:45:21] NOTICE: fpm is running, pid 10910
[06-May-2022 18:45:21] NOTICE: ready to handle connections
[06-May-2022 18:45:21] WARNING: [pool www] child 60509 exited on signal 
10 (SIGBUS) after 0.061336 seconds from start

[06-May-2022 18:45:21] NOTICE: [pool www] child 33092 started
[06-May-2022 18:45:21] WARNING: [pool www] child 33092 exited on signal 
10 (SIGBUS) after 0.010144 seconds from start

[06-May-2022 18:45:21] NOTICE: [pool www] child 35844 started
[06-May-2022 18:45:21] WARNING: [pool www] child 35844 exited on signal 
10 (SIGBUS) after 0.000310 seconds from start

[06-May-2022 18:45:21] NOTICE: [pool www] child 26407 started
[06-May-2022 18:45:21] WARNING: [pool www] child 26407 exited on signal 
10 (SIGBUS) after 0.010286 seconds from start

[06-May-2022 18:45:21] NOTICE: [pool www] child 65800 started
[06-May-2022 18:45:21] WARNING: [pool www] child 65800 exited on signal 
10 (SIGBUS) after 0.010071 seconds from start

[06-May-2022 18:45:21] NOTICE: [pool www] child 51310 started
[06-May-2022 18:45:21] WARNING: [pool www] child 51310 exited on signal 
10 (SIGBUS) after 0.009919 seconds from start

[06-May-2022 18:45:21] NOTICE: [pool www] child 56910 started
[06-May-2022 18:45:21] WARNING: [pool www] child 56910 exited on signal 
10 (SIGBUS) after 0.009972 seconds from start

[06-May-2022 18:45:21] NOTICE: [pool www] child 76952 started
[06-May-2022 18:45:21] WARNING: [pool www] child 76952 exited on signal 
10 (SIGBUS) after 0.009968 seconds from start

[06-May-2022 18:45:21] NOTICE: [pool www] child 36337 started


I think it's an armv7 specific problem. On my amd64 and i386 (also with 
only a 1 GB RAM) machines everything is fine.
On i386 there are other minor versions (php-7.4.29 and php-8.0.18) 
available, but this shouldn't be the root cause.


/etc/php-fpm.conf exists and the machine runs the current armv7 snapshot 
(7.1 GENERIC#35 armv7)



Do you've any ideas, if there is a fix for php-fpm on armv7?
In 2018 there was a similar request:
https://marc.info/?l=openbsd-ports=154689826613814=2

Thanks and best regards,
Sven