[rtems-test] powerpc/psim: RTEMS_POSIX_API: Passed:560 Failed:14 Timeout:5 Invalid:0 Wrong:0

[Joel Sherrill]

On Thu, Apr 11, 2019 at 5:35 PM Joel Sherrill <joel at rtems.org> wrote:

>
>
> On Thu, Apr 11, 2019 at 5:16 PM Chris Johns <chrisj at rtems.org> wrote:
>
>> Hi Joel,
>>
>> Thank you for running these tests and publishing the results.
>>
>
> :) I'm trying to build up my "rtems-cron" script. Not the fanciest way to
> decide when to test things but it will know how to test them.
>
> It will eventually run Coverity
>
> Any advice on knowing in a script if git needs to update a repo or a pull
> updated? I thought this would work but it didn't show the rtems updates
> today:
>
> git rev-list HEAD...origin/master --count
>
>
>> On 12/4/19 8:10 am, joel at rtems.org wrote:
>> > Testing time     : 0:10:37.757133
>> > Average test time: 0:00:01.084621
>> >
>> > Host
>> > ====
>> > Linux-3.10.0-862.11.6.el7.x86_64-x86_64-with-centos-7.5.1804-Core
>> (Linux rtbf64c.rtems.com 3.10.0-862.11.6.el7.x86_64 #1 SMP Tue Aug 14
>> 21:49:04 UTC 2018 x86_64 x86_64)
>> >
>> > Configuration
>> > =============
>> > Version: 5.0.0.ad87de4a67d8ce7e75d0b844efc03b98c3ecda1a
>> > Build  : RTEMS_POSIX_API
>> > Tools  : 7.4.0 20181206 (RTEMS 5, RSB
>> 9a3e12e5820918057633798c3fe2a1f952fb4e56, Newlib 1d35a003f)
>> >
>> > Summary
>> > =======
>> >
>> > Passed:        560
>> > Failed:         14
>> > User Input:      6
>> > Expected Fail:   0
>> > Indeterminate:   0
>> > Benchmark:       3
>> > Timeout:         5
>> > Invalid:         0
>> > Wrong Version:   0
>> > Wrong Build:     0
>> > Wrong Tools:     0
>> > ------------------
>> > Total:         588
>> >
>> > Failures:
>> >  fsimfsgeneric01.exe
>> >  block11.exe
>> >  devfs02.exe
>> >  rbheap01.exe
>> >  termios01.exe
>> >  psx12.exe
>> >  psxchroot01.exe
>> >  psximfs02.exe
>> >  psxpipe01.exe
>> >  spconfig02.exe
>> >  spfatal31.exe
>> >  spmountmgr01.exe
>> >  spprivenv01.exe
>> >  spstdthreads01.exe
>> > User Input:
>> >  dl10.exe
>> >  monitor.exe
>> >  termios.exe
>> >  top.exe
>> >  capture.exe
>> >  fileio.exe
>> > Benchmark:
>> >  whetstone.exe
>> >  dhrystone.exe
>> >  linpack.exe
>> > Timeouts:
>> >  fsrfsbitmap01.exe
>> >  dl08.exe
>> >  dl09.exe
>>
>> The `dl.*` test timeouts look like the test is running too long and if
>> you have
>> a number of tests running at once this could be the reason.
>>
>
> When run by hand, dl08 passes with this much time used:
>
> real    0m7.194s
> user    0m5.997s
> sys     0m0.703s
>
>  dl09 is less. Those aren't very long. I don't know why they timeout with
> the tester.
>
> fsrfsbitmap01 is over 4.5 minutes of host CPU time and stuck here:
>
> =============
>  23. Cleared bit still set: bit = 126
>
>  Testing bitmap_map functions with zero initialized bitmap control pointer
>
>  Allocate most of memory - attempt to fail while open bitmap - expect
> ENOMEM
> =============
>
> I will let it continue overnight but this one is either hung or needs
> tweaking to
> consume most of memory a single large allocation and then force the the
> rfs bitmap error.
>

Of course it failed as soon as I sent that email.

  Allocate most of memory - attempt to fail while open bitmap - expect
ENOMEM

*** FATAL ***
fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
exception vector 3 (0x3)
  next PC or address of fault = 0x0001980c
  saved MSR = 0x0000a072

It had consumed over 5 minutes of host time when that happened.

This fault was in rtems_bdbuf_read() in the true case of this if:

  if (rtems_bdbuf_is_read_ahead_active (dd))

doing  chain operation.

--joel

>
>
>> I see a couple of possible solutions, adding timeout control to the tests
>> which
>> rtems-test can see of I can drop the loop count to 10. The loop count is
>> the
>> simplest.
>>
>> The loop lets me see a repeating set of addresses being used so I can
>> check for
>> leaks.
>>
>
> I don't think that's the issue. The dl tests run quickly by hand.
>
>>
>> Chris
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190411/d76b4040/attachment-0002.html>