Hey Gabe, This is very strange and I can't say I've seen this issue before. The problem shouldn't be docker, none of these tests spin up an instance. I was going to suggest deleting the resources (`tests/gem5/resources`) and trying again, but it seems like you've tried that. My only sensible guess at this point is your not downloading the resources needed (network issues?), as, unfortunately, the TestLib downloader fails silently (e.g. if the download fails it tends to continue to try to run the test). Though if this is the case. it'd be weird to just see these tests failing as we download quite a few things to get testing working.
Have you looked into the output under `tests/testing-results` to see what's printing to stdout/stderr for these tests? Do you notice anything unusual there? Kind regards, Bobby -- Dr. Bobby R. Bruce Room 3050, Kemper Hall, UC Davis Davis, CA, 95616 web: https://www.bobbybruce.net On Wed, Sep 22, 2021 at 5:23 PM Gabe Black <gabe.bl...@gmail.com> wrote: > Thanks Giacomo, I *think* since these are running as part of the testing > infrastructure that they are downloading the files they need, and I hope > they are downloading current ones. Clearly *something* is out of whack, but > since this should all be handled automatically I don't know where or what > to look at to try to find what's out of date. I know once upon a time I had > an out of date docker that was causing problems, but I'm not using a docker > for this and so I don't think that's the problem(?). > > Do you have any ideas Bobby? I've tried deleting the resources directory > it downloads under tests, but that didn't seem to fix it. > > Gabe > > On Wed, Sep 22, 2021 at 9:17 AM Giacomo Travaglini < > giacomo.travagl...@arm.com> wrote: > >> 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
