Hi Gabe, >From an Arm perspective, could you make sure you are using the latest >bootloader? I remember there was a change some time ago which required the bootloader to be rebuilt
You could either download latest tarball from https://www.gem5.org/documentation/general_docs/fullsystem/guest_binaries Or rebuild the bootloader yourself Kind Regards Giacomo > -----Original Message----- > From: Jason Lowe-Power via gem5-dev <gem5-dev@gem5.org> > Sent: 22 September 2021 17:12 > To: gem5 Developer List <gem5-dev@gem5.org> > Cc: Gabe Black <gabe.bl...@gmail.com>; Jason Lowe-Power > <ja...@lowepower.com> > Subject: [gem5-dev] Re: failing ARM dual CPU tests? > > Hey Gabe, > > > To solve this and the x86 test issue you've been having, I think there are a > couple of possibilities: > > 1. Can you use the docker images that kokoro uses? This will guarantee that > you are using the *exact* same "host" setup when running gem5. I think this > is the only way to have a consistent set of tests without something like > Bazel's reproducible build and test. > 2. We're open to modifying and improving the tests. If the tests don't work > for you, they probably don't work for others as well. Improving the > documentation so it's more clear how to use the tests or improving the > testing infrastructure or modifying the tests so that they work more easily > for > more people would be a *very* welcome contribution. > > Cheers, > Jason > > On Tue, Sep 21, 2021 at 6:22 PM Gabe Black via gem5-dev <gem5- > d...@gem5.org <mailto:gem5-dev@gem5.org> > wrote: > > > 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 <mailto:gem5- > d...@gem5.org> > To unsubscribe send an email to gem5-dev-le...@gem5.org > <mailto:gem5-dev-le...@gem5.org> > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ 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
