<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 11, 2019 at 5:35 PM Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 11, 2019 at 5:16 PM Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Joel,<br>
<br>
Thank you for running these tests and publishing the results.<br></blockquote><div><br></div><div>:) 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.</div><div><br></div><div>It will eventually run Coverity </div><div><br></div><div>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:</div><div><br></div><div>git rev-list HEAD...origin/master --count<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
On 12/4/19 8:10 am, <a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a> wrote:<br>
> Testing time : 0:10:37.757133<br>
> Average test time: 0:00:01.084621<br>
> <br>
> Host<br>
> ====<br>
> Linux-3.10.0-862.11.6.el7.x86_64-x86_64-with-centos-7.5.1804-Core (Linux <a href="http://rtbf64c.rtems.com" rel="noreferrer" target="_blank">rtbf64c.rtems.com</a> 3.10.0-862.11.6.el7.x86_64 #1 SMP Tue Aug 14 21:49:04 UTC 2018 x86_64 x86_64)<br>
> <br>
> Configuration<br>
> =============<br>
> Version: 5.0.0.ad87de4a67d8ce7e75d0b844efc03b98c3ecda1a<br>
> Build : RTEMS_POSIX_API<br>
> Tools : 7.4.0 20181206 (RTEMS 5, RSB 9a3e12e5820918057633798c3fe2a1f952fb4e56, Newlib 1d35a003f)<br>
> <br>
> Summary<br>
> =======<br>
> <br>
> Passed: 560<br>
> Failed: 14<br>
> User Input: 6<br>
> Expected Fail: 0<br>
> Indeterminate: 0<br>
> Benchmark: 3<br>
> Timeout: 5<br>
> Invalid: 0<br>
> Wrong Version: 0<br>
> Wrong Build: 0<br>
> Wrong Tools: 0<br>
> ------------------<br>
> Total: 588<br>
> <br>
> Failures:<br>
> fsimfsgeneric01.exe<br>
> block11.exe<br>
> devfs02.exe<br>
> rbheap01.exe<br>
> termios01.exe<br>
> psx12.exe<br>
> psxchroot01.exe<br>
> psximfs02.exe<br>
> psxpipe01.exe<br>
> spconfig02.exe<br>
> spfatal31.exe<br>
> spmountmgr01.exe<br>
> spprivenv01.exe<br>
> spstdthreads01.exe<br>
> User Input:<br>
> dl10.exe<br>
> monitor.exe<br>
> termios.exe<br>
> top.exe<br>
> capture.exe<br>
> fileio.exe<br>
> Benchmark:<br>
> whetstone.exe<br>
> dhrystone.exe<br>
> linpack.exe<br>
> Timeouts:<br>
> fsrfsbitmap01.exe<br>
> dl08.exe<br>
> dl09.exe<br>
<br>
The `dl.*` test timeouts look like the test is running too long and if you have<br>
a number of tests running at once this could be the reason.<br></blockquote><div><br></div><div>When run by hand, dl08 passes with this much time used:</div><div><br></div><div>real 0m7.194s</div><div>user 0m5.997s</div><div>sys 0m0.703s</div><div><br></div><div> dl09 is less. Those aren't very long. I don't know why they timeout with the tester.</div><div><br></div><div>fsrfsbitmap01 is over 4.5 minutes of host CPU time and stuck here:</div><div><br></div><div>=============</div><div> 23. Cleared bit still set: bit = 126<br></div><div><br></div><div> Testing bitmap_map functions with zero initialized bitmap control pointer</div><div><br></div><div> Allocate most of memory - attempt to fail while open bitmap - expect ENOMEM</div><div>============= </div><div><br></div><div>I will let it continue overnight but this one is either hung or needs tweaking to </div><div>consume most of memory a single large allocation and then force the the rfs bitmap error.</div></div></div></div></div></div></blockquote><div><br></div><div>Of course it failed as soon as I sent that email.</div><div><br></div><div> Allocate most of memory - attempt to fail while open bitmap - expect ENOMEM</div><div><br></div><div>*** FATAL ***</div><div>fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)</div><div>exception vector 3 (0x3)</div><div> next PC or address of fault = 0x0001980c</div><div> saved MSR = 0x0000a072</div><div><br></div><div>It had consumed over 5 minutes of host time when that happened.</div><div><br></div><div>This fault was in rtems_bdbuf_read() in the true case of this if:</div><div><br></div><div><div> if (rtems_bdbuf_is_read_ahead_active (dd))</div></div><div><br></div><div>doing chain operation.</div><div><br></div><div>--joel</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I see a couple of possible solutions, adding timeout control to the tests which<br>
rtems-test can see of I can drop the loop count to 10. The loop count is the<br>
simplest.<br>
<br>
The loop lets me see a repeating set of addresses being used so I can check for<br>
leaks.<br></blockquote><div><br></div><div>I don't think that's the issue. The dl tests run quickly by hand. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Chris<br>
</blockquote></div></div></div></div></div>
</blockquote></div></div></div></div>