rt/tst-aio7 weirdness on ppc

[Roland McGrath <roland at redhat dot com>]

I just put the following change in:

  2002-09-29  Roland McGrath  <roland@redhat.com>

	  * test-skeleton.c (timeout_handler): Use WUNTRACED flag in waitpid.
	  Examine the child's status and print something different if it wasn't
	  just killed by our SIGKILL.
	  (main): In the child process call setpgid to put it in its own pgrp.

I think this is the right thing for the test driver to do, but the setpgid
call seems to mask the problem I was seeing on ppc.  What I had been seeing
is that a make check run would hit rt/tst-aio7 and the whole thing would be
suspended with SIGTTIN.  The test-skeleton.c change is intended to make any
test program that generates a job control signal just hang itself and be
noticed by the test driver, rather than suspend the entire pgrp containing
the test program, which is probably the "make check" run or build script.

What I see on ppc is that the problem just disappeared in make check.
However, when I run rt/tst-aio7 outside of make check, via the testrun.sh
script, it has some new weirdness.  When its stdout is not redirected, it
runs just fine most of the time, even if it's in a background pgrp.  When
it works right, it completes very quickly on my machine.  However, once in
a while it behaves in the foreground with stdout going to the tty just like
it does in the background redirected case.  That failure mode is that it
writes its output (0 1 2 3 4 5 6 7), then waits for several seconds, then
dies with SIGSTKFLT--which I think is total bogosity, I'm not sure this
signal is ever really generated by anything.  

When I remove the setpgid call just added to test-skeleton.c, then it goes
back to the original failure mode: SIGTTIN to the whole pgrp.  

I have never seen a failure running with --direct.

It seems likely this is a kernel bug, especially because of the strange
signal and the fact that the weird crash hits about one of ten times when
run in the foreground.  My machine is SMP, so a race seems not unlikely.

My ppc system is debian sid with the debian 2.4.19-powerpc-smp kernel.
Can anyone else reproduce any of this weirdness on another system?