jp wrote: > Still having the old error. I used strace to trace it, as I had been advised.
What about the contents of the .out file?
> 3 processes are started. the 3rd is created by the second, and the 2nd by the
> 1st.
Yep. The tst-mutex9 executable forks to run the test function (like all
the glibc test executables); the test function forks again and runs all the
mutex tests in the child.
> the problem is with the 3rd and strace reveals this:
> futex(0xb7ee5004, 0x100 /* FUTEX_??? */, 2, {1244666445, 178371000}) = -1
> ENOSYS (Function not implemented)
> in the last trace file.
How do you know this is the problem? Can you send the *full* trace file?
(If the list won't accept it because of size, I'll take a look if you send
it directly to me...)
Hmm, did you turn off futexes in your kernel? (CONFIG_FUTEX)
Is this a 64-bit kernel, or a 32-bit one? (I don't know if the Sempron
that you have can do 64-bit, but it's worth asking.) I assume that your
userspace is 32-bit.
That call is FUTEX_WAIT | FUTEX_CLOCK_REALTIME (your strace probably
doesn't know about that last flag yet). Not a lot of info there... Uh,
hang on, yes there is. See kernel/futex.c:
clockrt = op & FUTEX_CLOCK_REALTIME;
if (clockrt && cmd != FUTEX_WAIT_BITSET)
return -ENOSYS;
FUTEX_WAIT_BITSET is 10, not 0 (which is what your glibc is passing in).
Poking around in glibc, this *looks* like a bug in it (at least in 2.10.1).
If the __ASSUME_FUTEX_CLOCK_REALTIME preprocessor macro is defined, then it
uses FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME when trying the real-time
variant of the futex call (to see if it works). But if that is not
defined, then it uses FUTEX_WAIT instead of FUTEX_WAIT_BITSET, which (based
on the kernel source) is wrong. (See both nptl/init.c (which is correct)
and nptl/sysdeps/unix/sysv/linux/i386/486/lowlevellock.S (which is wrong)
for the sources.)
I *think* that --enable-kernel modifies the various __ASSUME_* macros...
> By the time writing this, linux-2.6.30 has been released. I restart all the
> build with it.
If the bug is really the ENOSYS errno values that you're getting, and the
cause of those is the constants that glibc is passing to the kernel (as
appears to be the case), then this won't help...
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
