On Sun, Jul 3, 2011 at 7:22 PM, John David Anglin <dave.anglin@xxxxxxxx> wrote:
> Hi Carlos,
>
> From what I see below, you have learned a lot about the failure. There's
> probably an operation
> in the kernel that isn't hooked up although one would tend to think most of
> this should be generic.
OK, fixed the kernel. We were still using the no-op futex
implementation I checked in 5 years ago :-(
Fixing the kernel doesn't fix the testcase but instrumenting glibc
further reveals the cause of the failure:
~~~
carlos@firin:~/fsrc/glibc-work/tests/tst-cputimer1$ ./tst-cputimer1
do_clone: ARCH_CLONE...
clock_gettime returned timespec = { 0, 40000000 }
clock_getres returned timespec = { 0, 1 }
do_clone: ARCH_CLONE...
timer_helper_thread: creating thread...
do_clone: ARCH_CLONE...
timer_helper_thread: pthread_create ret 0
timer_segev_thread: tid 20077
timer_helper_thread: creating thread...
pthread_create: ALLOCATE_STACK failed.
timer_helper_thread: pthread_create ret 22
~~~
The second threads stack fails to allocate.
I don't know why, the stack allocation on hppa is tricky because of
S_G_U and the placement of stack guards.
Why it would fail for one thread and not the other is odd.
I'll keep digging.
Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
