Help with RTEMS Tester Results for uC5282

Joel Sherrill joel at rtems.org
Mon Jul 19 23:32:35 UTC 2021


On Mon, Jul 19, 2021, 5:43 PM <gerberhe11 at gmail.com> wrote:

> Hello all,
>
>
>
> I’ve been working on getting support into Qemu for the uC5282 board
> recently, and today got the rtems-test tool running with this Qemu
> emulation for that board. The results with the first run of the full test
> suite since the emulation has been operational appears very promising,
> which is great news! However, there are a couple tests that either fail or
> (in the case of sptests specifically) always timeout. Included at the
> bottom of this email are the results of running the tests through this
> emulation. Dr. Bloom mentioned that some of these results could likely be
> due to flawed TLS implementation of m68k. Any input, guidance, or
> suggestions about these results (especially the tests that failed/timed
> out) would be really valuable to this work of getting truly reliable uC5282
> emulation running!
>
>
>
> Thanks so much,
>
>
>
> *Harrison Gerber*
>
> gerberhe11 at gmail.com
>
>
>
> TEST RESULTS:
>
>
>
> Passed:        547
>

Quite good!

> Failed:          7
>
> User Input:      6
>
> Expected Fail:   1
>
> Indeterminate:   0
>
> Benchmark:       3
>
> Timeout:         7
>
> Test too long:   0
>
> Invalid:         0
>
> Wrong Version:   0
>
> Wrong Build:     0
>
> Wrong Tools:     0
>
> ------------------
>
> Total:         571
>
> Failures:
>
> sppercpudata01.exe
>
> sptimecounter02.exe     ß Passes when run individually
>
> Qemu us a mystery on this. We have seen tests passing when run alone but
not in parallel batches. It would be good to know why this happens. But I
wouldn't punish you for that. ;)

>
>
> ttest02.exe                         ß Passes when run individually
>
>
> sptls02.exe
>
> ts-validation-0.exe
>
This requires support in the port itself to clobber registers in a
particular way and validate they context switch ok. See the arm or SPARC
ports for examples.

> stringto01.exe
>

This needs to be looked into. Shouldn't normally fail for something related
to a.port or BSP.

> dl06.exe
>

Perhaps a relocation type not supported yet?

> User Input:
>
> dl10.exe
>
> fileio.exe
>
> monitor.exe
>
> capture.exe
>
> termios.exe
>
> top.exe
>
> Expected Fail:
>
> psxfenv01.exe
>
> Benchmark:
>
> whetstone.exe
>
> dhrystone.exe
>
> linpack.exe
>
> Timeouts:
>
> spinternalerror01.exe
>
> spfatal26.exe
>
> spsysinit01.exe
>
> spfatal33.exe
>
> sptimecounter01.exe
>
> spfatal12.exe
>
> spfatal09.exe
>
> Average test time: 0:00:01.901600
>
> Testing time     : 0:18:05.814003
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon> Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link>
> <#m_-784980626469659469_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> _______________________________________________
> 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/20210719/a2fe79d0/attachment-0001.html>


More information about the devel mailing list