On Sun, Apr 07, 2024 at 02:43:20PM +0000, tony mancill wrote:
Source: capnproto
Version: 1.0.1-3
Severity: serious
Tags: ftbfs
https://buildd.debian.org/status/fetch.php?pkg=capnproto&arch=armhf&ver=1.0.1-3%2Bb2&stamp=1711652087&raw=0
I am assuming that if the futux syscall here:
https://sources.debian.org/src/capnproto/1.0.1-3/src/kj/mutex.c%2B%2B/#L250
which also gets passed a timespec, was the culprit, that more things would be broken on armhf than just a few tests. But that's an area I need to explore further.
So assumptions can be wrong... :) Many thanks to Tom Lee for creating
a simple test case [1] that demonstrates the futex syscall returning
early on armhf + t64, while being successful on the same architecture
with the pre-t64 userspace and other architectures.
Results on the porter box with t64 userspace:
(sid_armhf-dchroot)$ uname -a
Linux abel 4.19.0-21-armmp-lpae #1 SMP Debian 4.19.249-2 (2022-06-30) armv7l GNU/Linux
(sid_armhf-dchroot)$ ./futex-test
futex returned too early: 26640 ns
(sid_armhf-dchroot)$ ./futex-test
futex returned too early: 34560 ns
(sid_armhf-dchroot)$ ./futex-test
futex returned too early: 23920 ns
(sid_armhf-dchroot)$ ./futex-test
futex returned too early: 33560 ns
Running the same code compiled against the bookworm userspace on the
same armhf porterbox is successful:
(bookworm_armhf-dchroot)$ uname -a
Linux abel 4.19.0-21-armmp-lpae #1 SMP Debian 4.19.249-2 (2022-06-30) armv7l GNU/Linux
(bookworm_armhf-dchroot)$ ./futex-test-bookworm
ok: 10069107
(bookworm_armhf-dchroot)$ ./futex-test-bookworm
ok: 10067586
(bookworm_armhf-dchroot)$ ./futex-test-bookworm
ok: 10068587
(bookworm_armhf-dchroot)$ ./futex-test-bookworm
ok: 10068187
(bookworm_armhf-dchroot)$ ./futex-test-bookworm
ok: 10069026
This may be a naive question, but since we're dealing with a syscall
that passes a timespec, is there a minimum kernel version required for
the time_t 64 userspace?
In any event, I'm not sure about the next steps here. Any suggestions?
Should I work with DSA to try to get a porter box with a newer kernel to confirm that that resolves the issue with the test? (I think this would
have eventual implications for the buildds.)
Thank you,
tony
[1]
https://gist.githubusercontent.com/thomaslee/e8484eeae64004e2a3be8be88e2e25e8/raw/e9edc3025d54afbff6b0492998ee624d8b2ac317/futex-test.c
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAmYTQSUACgkQIdIFiZdL PpYEfhAAgXiKoiu1ewunQA+UboMPQeaLXyLsgrjIpk4H7Q4Uj6+dZ9eEaoIC+uMi /64MnfmsJL4YiUYibKhhskx0IGlRbj+89YW45T4XjGSQ6SrEOkC2b67zlGs4R/kD yuptSwIOVhtkOS4gimbYpwlFMnIHMgdTkoUhOV+VQtJZ3s3QTl6zEJtc1bmCfXNR s6Wz8mKQkRCXfeWJKTxzLddZMIbbl1/lnpbHOMeHTzW3NPOayqwf0rWbJpm/NmCL CjEZyxjryyVSzbjhGprzi1Hs4CjjmULeE+b6rZvDytENsZvZz81puQpM3RMTHYX0 MI5GHAMQy66q+qbSMBz+5JjAuMFagvAcLQUbIO74PG2jdkZdZMYMql6tggOQnA6z RnQzNsr/ffJtRuCtpY8jeUsuB4qaLbwru4uyov1QWswZu1GcybN/g1LjJwI+Fh0+ HQVGxIsdUVe+hItADNy8x9ny8fhn3CqVOZO8UqSjUDyFAZ1fIjHX1pxcSlcrYsjL b6EnWEMSlpmOeaE5bJJpmq0Leibia3Hp1Zqx7M7fetWdd0YULPZyBilEnNQ3yybI O+aoC+5cLoNzYV0tGejNBHDaLCk+4BJOZ3KWdo59kxY4fAchgRXf3SM6kNX0nFoN E9CTAAlOHxJrXJHHBFtfU0qYpz9VTXw7/cTMOBO8NeRiCXQLzfM=
=Vewu
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)