Hey Giacomo,
For the first two patches I can't access the failing Kokoro due to re-runs
overwriting the log. In the last one,
https://gem5-review.googlesource.com/c/public/gem5/+/56303/1, I'm not
seeing a timeout issue. That appears to be my aforementioned issue, which
I've come to guess is due to
Thanks Bobby,
Here are some examples:
https://gem5-review.googlesource.com/c/public/gem5/+/56426
https://gem5-review.googlesource.com/c/public/gem5/+/55964/6
https://gem5-review.googlesource.com/c/public/gem5/+/56303/1
(If you check the verification history of the last patch you can see it first
Are there examples of this timeout happening recently? I can't see any over
the past week.
There's a separate issue affecting one of Gabe's patches that I'm looking
into (here: https://gem5-review.googlesource.com/c/public/gem5/+/56303) but
these appear to be due to dynamic libraries not linking c
The gem5art test fix has just been submitted. For problematic patchsets try
rebasing to the HEAD of develop. Let me know if you observe similar
failures when with fix is included.
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616
web: https://www.bobbybruce.net
On Thu, Aug
One more:
https://source.cloud.google.com/results/invocations/8f6a185e-0258-4f9c-b573-e79d1a86a5a1/targets/gem5%2Fgcp_ubuntu%2Fpresubmit/log
On Thu, Aug 5, 2021 at 3:02 PM Gabe Black wrote:
> Yeah, I wouldn't be surprised if it was specific to kokoro, or something
> about how its networking is
Yeah, I wouldn't be surprised if it was specific to kokoro, or something
about how its networking is set up. Those failures seem to have stopped
happening now, or at least are happening much less. I don't remember seeing
one for a while at least. Hopefully we can avoid making our timeout any
longer
That theory could be true, and I certainly don't have any better ideas,
though I've never observed any hang on my local machine when recreating
this issue. It could be something specific to Kokoro.
I've fixed the gem5art error here:
https://gem5-review.googlesource.com/c/public/gem5/+/49044. We ca
Another possibility is that while the gem5-art error may not actually kill
the run, it may, for instance, have failed trying to download something
with a generous timeout, and waiting for that timeout pushed the rest of
the run out enough to trip the timeout? Just a thought. I haven't checked
exhau
Ok, thanks. I don't know if you saw the CL I put up recently where the
src/base/cprintftime.cc executable (the one built from that source) was
broken, which made kokoro fail. The breakage was real and worth fixing, but
I'm not sure why kokoro was trying to build it in the first place? Maybe
sometim
Ok, so I did look into this today and didn't find anything. On my desktop
machine the difference in running the pre-submit tests from the stable
branch and develop branch (including building the binaries) was only 10
minutes so we've really not done anything to increase the build/test times
to a si
Ok thanks, Bobby. Please let me know if you find anything, especially if it
looks like it's a bug in kokoro itself somehow.
Gabe
On Wed, Jul 21, 2021 at 3:52 PM Bobby Bruce wrote:
> There's definitely something funny going on with the gem5art tests there
> but I believe that error is happening
There's definitely something funny going on with the gem5art tests there
but I believe that error is happening without triggering a non-zero exit
code. The gem5art test script is set to `set -e`, which means the script
should exit immediately after a failure, yet it doesn't. The testing also
contin
12 matches
Mail list logo
