On Fri, Sep 20, 2013 at 08:56:10AM +0200, Akim Demaille wrote: > > Le 6 sept. 2013 à 22:18, Michael Felt <[email protected]> a écrit : > > > Each line is 15 seconds between the next entry. > > This is amazing… > > > Initiall with smt2 so the 50% idle is the unused thread. During the test > > run I turned off the smt setting (see new header) and %idle goes to zero. > > > > Is there something I can add to see where test #24 is hanging? > > There is nothing special about this test that could explain. > > Try passing '-d -x -v' to the test suite, and run just 24: > > make check TESTSUITEFLAGS='-d -v -x 24' > Please excuse me for jumping in here, but I'm seeing the exact same problem on a current build of linux on ppc. The box is one of the last powermac G5s (single processor, horrendously slow with current software). The new system is based on linuxfromscratch-7.4, so pretty much everything is up to date.
Mine is a chroot build using a 3.10-series kernel (on a 3+ years old host system) and 'linux32' to pretend to be just ppc (host is ppc64 with only 32-bit userspace). When I first realised the tests were going nowhere (after about 3 hours), I think that all processes were more or less idle. I then installed the package without tests after google found Michael's previous post. Now, I've got to the end of the build (still in chroot, not 100% confident it will actually boot 8-) and I've been running your command for test 24 for about 1 hr 30 min. Bison is still taking as much CPU as it can get, but nothing extra is showing up with those flags. The end of the stdout+stderr output hasn't changed since test 24 started: [...] torture.at types.at ## ------------------------- ## ## GNU Bison 3.0 test suite. ## ## ------------------------- ## 24. input.at:1038: testing Unclosed constructs ... ++ cat ++ set +x ./input.at:1067: VALGRIND_OPTS="$VALGRIND_OPTS --leak-check=summary --show-reachable=no"; export VALGRIND_OPTS; bison -fno-caret -fcaret -o input.c input.y and similarly testsuite.dir/024/testsuite.log only shows: # -*- compilation -*- 24. input.at:1038: testing Unclosed constructs ... ++ cat ++ set +x ./input.at:1067: VALGRIND_OPTS="$VALGRIND_OPTS --leak-check=summary --show-reachable=no"; export VALGRIND_OPTS; bison -fno-caret -fcaret -o input.c input.y Is there anything else those of us on ppc can do to get more information on what is happening in test 24 ? As you'll see below, I'm running the tests as root (new build, it's easier) - mentioned just in case that is part of the problem (it didn't affect x86_64 or i686). I'll leave it for a bit longer (somehow I never seem to keep regular hours these days!), but I'll probably kill it in the end. What is really odd is that bison isn't actually using memory, as if it is in a code loop. 'top' showed the following a few minutes ago: top - 02:10:50 up 12:38, 1 user, load average: 1.08, 1.51, 1.59 Tasks: 108 total, 2 running, 106 sleeping, 0 stopped, 0 zombie Cpu(s): 12.3%us, 87.4%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.3%hi, 0.0%si, 0.0%st Mem: 1999912k total, 1966028k used, 33884k free, 261528k buffers Swap: 2929684k total, 320k used, 2929364k free, 1299576k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5382 root 20 0 2316 816 696 R 97.7 0.0 78:51.06 bison and now (8 min later) bison's memory usage hasn't changed although it has been running at 95%+ of CPU for all the extra time. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce
