Hi folks. When I run the test script main.py locally on an otherwise passing tree, I get 8 test failures. 6 of those are from x86 dynamic linking tests which use a host library which uses a system call gem5 doesn't implement. That is annoying, but I understand that problem.
The other 2 are from ARM dual CPU tests (like realview64-simple-timing-dual-ARM-x86_64-opt-MatchFileRegex) which fail because the second CPU doesn't come up, and the check doesn't see the message it expects. This is very surprising to me, since I don't think these tests would have any host dependence, and I'm *pretty* sure that the files they use would come from the resources thing and should be up to date, etc. The system in the test seems to otherwise boot up, it's just that the second CPU never comes online and linux prints an error message about it instead of the normal one. Does anybody know of something else I can try to update, etc, which might fix these tests? Could there be stale system files it's using floating around somewhere? I would really like to get that sorted out, since that could affect whether I can successfully test my locked memory helper function change, since the earlier version of that had caused problems with O3 multi-CPU tests for ARM, sort of right in line with this false positive on these tests. Thanks! Gabe
_______________________________________________ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
