timeouts and failure

[Joel Sherrill]

On Sat, Mar 18, 2017 at 9:00 AM, Joel Sherrill <joel at rtems.org> wrote:

> These are all long running tests. Gedare is on a new computer which I
> assume is quite fast. So he has fewer timeouts.
>
> I am out of town but can try to remember to use tsim to get the running
> time for some of these in real CPU time. My recollection is that crypt01
> takes a long time compared to other tests.
>
>
FWIW here are my results for sparc/erc32:

Passed:   548
Failed:     1
Timeouts:   5
Invalid:    0
-------------
Total:    554

Failures:
 spcontext01.exe
Timeouts:
 fileio.exe
 top.exe
 termios.exe
 capture.exe
 monitor.exe
Average test time: 0:00:01.729638
Testing time     : 0:15:58.219870

That is much better than yours and is really only the known spcontext01.exe
failure.

I noticed you have 17 tests more than I do enabled. How did you configure?
This
is mine:

../rtems/configure --target=sparc-rtems4.12 --enable-rtemsbsp=erc32
--prefix=/home/joel/rtems-work/tools/4.12 --disable-networking
--enable-posix --disable-multiprocessing --disable-smp --enable-tests
--enable-cxx --enable-maintainer-mode

--joel


--Joel
>
>
> On Mar 18, 2017 4:55 AM, "Tanu Hari Dixit" <tokencolour at gmail.com> wrote:
>
> Gedare,
> By erc32 under gdb do you mean using --debug-trace=gdb option with
> rtems-test ?
> I ran a normal
>  ./rtems-test --log=log_erc32_run_alltest_new --rtems-bsp=erc32-run
> --rtems-tools=$HOME/development/rtems/4.12
> /home/thd/development/rtems/src/builds/b-erc32_allt/sparc-rt
> ems4.12/c/erc32/testsuites
>
> without the debug trace option and got the following results:
>
> Passed:   543
> Failed:     6
> Timeouts:  12
> Invalid:    0
> -------------
> Total:    561
>
> Failures:
>  mdosfs_fsscandir01.exe
>  spcontext01.exe
>  jffs2_fsscandir01.exe
>  mrfs_fsscandir01.exe
>  imfs_fsscandir01.exe
>  mimfs_fsscandir01.exe
> Timeouts:
>  mdosfs_fsrdwr.exe
>  mimfs_fserror.exe
>  fsdosfsname01.exe
>  mimfs_fspatheval.exe
>  mouse01.exe
>  fsdosfswrite01.exe
>  malloctest.exe
>  math.exe
>  crypt01.exe
>  fsdosfsformat01.exe
>  mdosfs_fstime.exe
>  mimfs_fsrdwr.exe
>
> Regards,
> Tanu Hari Dixit.
>
> On Sat, Mar 18, 2017 at 11:47 AM, Chris Johns <chrisj at rtems.org> wrote:
> > On 18/3/17 11:46 am, Gedare Bloom wrote:
> >> I just ran tests and observe the following on erc32 under gdb, can
> >> anyone confirm/replicate the timeouts and failure, and know why this
> >> is happening?
> >
> > How many cores are you using with rtems-test and so how many tests are
> > running in parallel? This can effect the time per test and it is
> > difficult to know the effect this has on the timeout per host machine
> > being used.
> >
> > Chris
> >
> >>
> >> Passed:   554
> >> Failed:     1
> >> Timeouts:   6
> >> Invalid:    0
> >> Total:    561
> >>
> >> Result: timeout    Time: 0:03:00.219154 fsdosfsformat01.exe
> >> Result: timeout    Time: 0:03:00.228353 fsdosfsname01.exe
> >> Result: timeout    Time: 0:03:00.217955 fsdosfsname02.exe
> >> Result: timeout    Time: 0:03:00.189769 fsrfsbitmap01.exe
> >> Result: timeout    Time: 0:03:00.203202 imfs_fserror.exe
> >> Result: timeout    Time: 0:03:00.207983 crypt01.exe
> >> Result: failed     Time: 0:00:02.056732 spcontext01.exe
> >> _______________________________________________
> >> devel mailing list
> >> devel at rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
> >>
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170318/52b5b4ed/attachment-0002.html>