<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 1, 2021 at 11:02 AM 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"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 1, 2021 at 11:56 AM Peter Dufault <<a href="mailto:dufault@hda.com" target="_blank">dufault@hda.com</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">Can the test be marked as a possible emulator failure?  For example (I haven't looked at the report) use "?" (Huh?) and not "!" (Failed!) or "." )(Passed), that is, the test failed as an emulated system and the RTEMS project suspects the emulation itself is causing this.<br></blockquote><div><br></div><div>That's not bad. The BSPs which might want to use this sometimes are qemu only but we have a lot of BSPs (pc, sparc, etc) that run on both simulator and real hardware. For ones like the Zynq where you have a qemu only variant, this would be perfect.  But for ones which can run on both, I don't know how to eliminate the use on hardware. </div></div></div></blockquote><div><br></div><div>I'm fine with this. Unlike hardware, emulation/simulation bugs are transient and can be safely ignored (to an extent) by us.</div><div> </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 class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
You shouldn't be allowed to use this on physical devices.<br></blockquote><div><br></div><div>+1 </div></div></div></blockquote><div><br></div><div>Yes, I had initially thought perhaps this is like hardware bugs/errata, but it is not. You would either fix/workaround the hardware (and want to know it is broken/failing), or you would abandon that device :)</div><div> </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 class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> On Feb 1, 2021, at 12:31 , Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
> <br>
> <br>
> <br>
> On Mon, Feb 1, 2021 at 11:14 AM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br>
> <br>
> <br>
> On Mon, Feb 1, 2021 at 9:42 AM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
> Hi<br>
> <br>
> On the aarch64 qemu testing, we are seeing some tests which seem to pass most of the time but fail intermittently. It appears to be based somewhat on host load but there may be other factors.<br>
> <br>
> There does not appear to be a good test results state for these. Marking them expected pass or fail means they will get flagged incorrectly sometimes.<br>
> <br>
> <br>
> Are they expected to pass every time?<br>
> <br>
> Normally yes. But there appears to be some external factors particularly load impacting qemu which lead to failures on target side code.<br>
> <br>
> <br>
> Intermittent failures are suspicious, and there is limited value to running a test that has an "intermittent failure" state, since it will always be successful if you don't care if it passes or fails.<br>
> <br>
> Yeah. No matter what you mark them, it sucks.<br>
> <br>
> <br>
> I don't see not running them as a good option. Beyond adding a new state to reflect this oddity, any suggestions?<br>
> <br>
> --joel<br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
<br>
Peter<br>
-----------------<br>
Peter Dufault<br>
HD Associates, Inc.      Software and System Engineering<br>
<br>
This email is delivered through the public internet using protocols subject to interception and tampering.<br>
<br>
</blockquote></div></div>
</blockquote></div></div>