Test failures only on an AMD A10 Kaveri #15996
Comments
From zarniwhoop@ntlworld.comCreated by zarniwhoop@ntlworld.comI'm using linuxfromscratch, and normally I only test perl when I However, on this one machine (AMD A10 Kaveri) I get three extra ../dist/Time-HiRes/t/itimer.t dist/Time-HiRes/t/itimer ....................................... lib/Benchmark .................................................. Illegal division by zero at ../lib/Benchmark.t line 77. t/op/time ...................................................... # Failed test 2 - very basic times test at op/time.t line 33 Retesting in a completed system shows the same failures are present. The other 2 tests look as if it is running too slowly. Current At the moment, idle cores claim to be ruinning at 1400MHz, the core Any advice on trying to diagnose these problems (maybe a poor kernel This isn't the world's fastest machine, and on another AMD last year My command to run the tests is: Unfortunately, although the log showed all the commands for building Retesting now, on a finished system, tail -f on a log works ok so the The data below is from the completed system. On this build I'm Thanks for reading. ĸen Perl Info |
From @jkeenanOn Sat, 03 Jun 2017 00:17:37 GMT, zarniwhoop@ntlworld.com wrote:
Ken, you raise a variety of issues here. I can foresee that there's enough here for multiple RT tickets. So I'll try to comment only where I think I understand the issues you're raising.
This is probably the first report we've had from someone using this distribution (http://www.linuxfromscratch.org/).
These two libraries are maintained upstream on CPAN. Have you reported these test failures in their own bug trackers? https://rt.cpan.org/Dist/Display.html?Name=Compress-Raw-Zlib https://rt.cpan.org/Dist/Display.html?Name=IO-Compress The maintainer of these distributions is quite responsive, so I would urge you to report these failures as per their documentation: http://search.cpan.org/~pmqs/Compress-Raw-Zlib-2.074/ http://search.cpan.org/~pmqs/IO-Compress-2.074/
Would you be able to provide email attachments for the output of each of the following commands? ##### cd t; ./perl harness -v ../lib/Benchmark.t; cd - cd t; ./perl harness -v op/time.t, cd -
It appears that we do not yet have any smoke test reports for gcc-7.1 or -6.3 on any platform (http://perl5.test-smoke.org/search). -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From @demerphqOn 3 June 2017 at 02:17, via RT <perlbug-followup@perl.org> wrote:
I cant speak to chroot, but the tests that are failing time things, I know that Benchmark tests can produce bizarro output if timing the Yves
-- |
From zarniwhoop@ntlworld.comOn Fri, Jun 02, 2017 at 06:09:50PM -0700, James E Keenan via RT wrote:
Yeah, perl's tests mostly work by the time we get to a released Like hte joke about hte boy who didn't speak for years, I guess
I think we looked at the tests, saw a version was hardcoded, and
I seem to have problems with invoking subshells, the attachments are
But 6.3 is so last year ;-) BTW - thanks for your patch in #131337 - when we build our temporary ĸen |
From zarniwhoop@ntlworld.comt/itimer.t: overall time allowed for tests (360s) exceeded! Test Summary Report ../dist/Time-HiRes/t/itimer.t (Wstat: 9 Tests: 1 Failed: 0) |
From zarniwhoop@ntlworld.comIllegal division by zero at ../lib/Benchmark.t line 77. Test Summary Report ../lib/Benchmark.t (Wstat: 65280 Tests: 10 Failed: 0) |
From zarniwhoop@ntlworld.com# Failed test 2 - very basic times test at op/time.t line 33 Test Summary Report op/time.t (Wstat: 0 Tests: 72 Failed: 1) |
From @jkeenanzarniwhoop@ntlworld.com wrote:
I am attaching two files which are essentially stripped-down versions of 2 of the 3 failing test files with some debugging statements thrown in. Can you place 'xtime.t' into 't/op' and then run: ##### My output for that would be: ##### And can you then place 'xBenchmark.t' into 'lib/Benchmark' and then run: ##### My output for that would be: ##### Thank you very much. -- |
From @jkeenan#!./perl -w BEGIN { use warnings; use Benchmark qw(:all); my $DELTA = 0.4; # Some timing ballast my $All_Pattern = # see if the ratio of two integer values is within (1+$delta) sub cmp_delta { my $t0 = new Benchmark; # We use the benchmark object once we've done some work: isa_ok(timeit(5, sub {++$foo}), 'Benchmark', "timeit CODEREF"); isa_ok(timeit(5, '++$bar'), 'Benchmark', "timeit eval"); # is coderef called with spurious arguments? print "# Burning CPU to benchmark things; will take time...\n"; # We need to do something fairly slow in the coderef. # The default is three. |
From @jkeenan#!./perl -w BEGIN { plan tests => 2; # These tests make sure, among other things, that we don't end up ($beguser,$begsys) = times; $beg = time; while (($now = time) == $beg) { sleep 1 } ok($now > $beg && $now - $beg < 10, 'very basic time test'); ok($i >= 2_000_000, 'very basic times test'); |
From zarniwhoop@ntlworld.comOn Sun, Jun 04, 2017 at 07:52:40AM -0700, James E Keenan via RT wrote:
As expected, my output for both is different, but also the Thanks. ĸen |
From zarniwhoop@ntlworld.com1..2 |
From zarniwhoop@ntlworld.com1..10 |
From @jkeenanOn Mon, 05 Jun 2017 18:19:21 GMT, zarniwhoop@ntlworld.com wrote:
So let's first focus on the problem with Benchmark.
In what is presumably a normal environment, the entirety of 'real' is allocated to 'user' (element 1). You got: ##### So, as I suspected, in your environment Benchmark is allocating the entirety of 'real' (element 0) to 'system' (element 2). 'user' is 0 which, after being assigned to $cpu3, leads to the division-by-zero error at +77 lib/Benchmark.t. Is this attributable to the fact that you are in a 'chroot' context? People more knowledgeable than I will have to answer that question. Thank you very much. -- |
From @jkeenanOn Mon, 05 Jun 2017 18:19:21 GMT, zarniwhoop@ntlworld.com wrote:
Can you place new attachment 'ytime.t' into 't/op' and then run: ##### ... and attach output (preferably, with '.txt' file extension so that it shows up well in RT). Thank you very much. -- |
From @jkeenan#!./perl -w BEGIN { plan tests => 2; # These tests make sure, among other things, that we don't end up ($beguser,$begsys) = times; $beg = time; while (($now = time) == $beg) { sleep 1 } ok($now > $beg && $now - $beg < 10, 'very basic time test'); ok($i >= 2_000_000, 'very basic times test'); |
From zarniwhoop@ntlworld.comOn Mon, Jun 05, 2017 at 12:26:39PM -0700, James E Keenan via RT wrote:
Just to confirm, yes this is a normal environment on the completed
But I wasn't in chroot when I ran the two debug versions you sent ĸen |
From zarniwhoop@ntlworld.comOn Mon, Jun 05, 2017 at 12:39:56PM -0700, James E Keenan via RT wrote:
I'll do it tomorrow, at the moment the system is working through a ĸen |
From @iabynOn Mon, Jun 05, 2017 at 11:59:40PM +0100, Ken Moffat wrote:
I suspect its more to do with how your kernel is reporting user and sys @t0 = times; on my system I see: $ time perl5260o /tmp/foo real 0m3.361s -- |
From zarniwhoop@ntlworld.comOn Tue, Jun 06, 2017 at 12:57:10AM -0700, Dave Mitchell via RT wrote:
On my haswell I got similar results, but a bit quicker. With 200_000_000 0.000 usr, 4.020 sys, 0.000 cusr, 0.000 csys real 0m4.033s and with 400_000_000 0.000 usr, 8.010 sys, 0.000 cusr, 0.000 csys real 0m8.014s Doubling it again, perl continues to put all the time in sys, and Does that sound like a kernel config issue ? Apart from very Thanks |
From zarniwhoop@ntlworld.comOn Mon, Jun 05, 2017 at 12:39:56PM -0700, James E Keenan via RT wrote:
Attached. I misthought this was the very slow test, so I left it Thanks |
From zarniwhoop@ntlworld.com1..2 |
From @jkeenanOn Tue, 06 Jun 2017 20:48:51 GMT, zarniwhoop@ntlworld.com wrote:
So you got: ##### ... which suggests that your environment is very slow, at least relative to the environments in which we customarily test Perl. (But I think we knew that already.) Also, as was the case with lib/Benchmark.t, the Perl built-in times() function is allocating all the time to 'system' rather than to 'user'. We don't yet understand why that is happening. Thank you very much. |
From @iabynOn Tue, Jun 06, 2017 at 07:32:13PM +0100, Ken Moffat wrote:
Well its something to do with the kernel or low-level C library. Unless you can provide a valid use case why perl's time-related modules -- |
From zarniwhoop@ntlworld.comOn Wed, Jun 07, 2017 at 02:03:58PM +0100, Dave Mitchell wrote:
Fair enough. Unfortunately my google-fu is not up to this, looks Thanks to you both for the help.
LOL. I like your random .sig generator. ĸen |
From zarniwhoop@ntlworld.comOn Wed, Jun 07, 2017 at 06:04:51AM -0700, Dave Mitchell via RT wrote: A follow-up, hoping this gets into the ticket so that maybe google This is my second A10 Kaveri, it replaces one which died last year The lingering bad settings were CONFIG_NO_HZ_FULL : changing that to CONFIG_VIRT_CPU_ACCOUNTING{,_GEN} - changing that to Thanks again for the help, and sorry for the misplaced noise. -- |
From @khwilliamsonThanks for considering those who come after you. It did make it into the ticket, which I am now closing |
|
@khwilliamson - Status changed from 'open' to 'rejected' |
Migrated from rt.perl.org#131489 (status was 'rejected')
Searchable as RT131489$
The text was updated successfully, but these errors were encountered: