On 20/8/19 4:59 pm, Jiri Gaisler wrote: > > On 8/20/19 12:44 AM, Chris Johns wrote: >> On 20/8/19 6:53 am, Jiri Gaisler wrote: >>> This patch will add QEMU-4.1.0 as RSB target devel/qemu4. >> Looks good. >> >>> The current devel/qemu target will be preserved. >> Should devel/qemu just point to qemu4? I am OK with this happening. > If preserving the current qemu is not necessary, then I can just update > devel/qemu to version 4.1.0 and not add devel/qemu4. This probably makes more > sense ...
I will leave this for Joel to decide. He would like the engineering manual to say how tests are run for the various archs/bsps and he would like to know what each covers. >>> Builds and installs fine on ubuntu 18.04 x86_64. Build scripts might need >>> tweaks for other platforms. >> It can be a lot of work depending on how building the support libraries >> goes. I >> think we have reached a point where a newer qemu on platforms that can build >> it >> is more important and the problem hosts such as MinGW and MacOS can be >> cleaned >> up after. > Agree. On ubuntu, the supporting libraries are not needed at all as they can > be installed through the standard package manager. MSYS2/MinGW had limited support here and I avoid the packages on MacOS because of the collateral damage they bring, ie the posts about MacOS tools not building that appear from time to time. > But building them inside RSB makes it easier for the end-user who does not > need to figure out what to install (or read the manual .. :-) >>> A few patches are still pulled in, currently hosted on gaisler.org but >>> could be moved to Trac ..? Tested with sparc/leon3 bsp, about 10 unexpected >>> fails/timeouts out of 530 tests. >> Does setting a longer timeout change this? I cannot find a suitable way to >> adjust the timeout depending on the load. > > Not really, the tests are dead-locked somehow. This is probably because of > qemu timing behavior. Here is the list of failures: > > Failures: > dl09.exe > psx12.exe > > Timeouts: > spintrcritical06.exe > spintrcritical07.exe > spintrcritical12.exe > spintrcritical11.exe > spintrcritical13.exe > spintrcritical14.exe > spintrcritical15.exe > spintrcritical18.exe > spintrcritical24.exe > > It would be great if rtems-test could (optionally) take a timeout value from > the bsp file, as some targets need a bit longer delay. (e.g. crypt01.exe > fails on sis/RISC-V due to this). Try creating a ~/.rtemstesterrc file or any file and pass in with --user-config and add the BSP as a section and the timeout ... [leon3] timeout = 30 The INI values are added to the BSP's internal macro map and this should be picked up when the process is exec'ed .... https://git.rtems.org/rtems-tools/tree/tester/rt/config.py#n228 Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
