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
signature.asc
Description: PGP signature
