You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The linux-riscv64-mengzhuo machine has a flaky network connection. Recent builds have timed out trying to obtain things like the tip-of-tree for a repository and trying to download prebuilt toolchains from the CAS service. The consecutive failures of the latter led the machine to be quarantined, draining the pool of linux-riscv64 machines for some time.
I will note that some of the work cmd/coordinator used to do is now done on the bot itself. This is just a consequence of the switch to LUCI's execution model.
@mengzhuo is there anything that can be done either by you or us to improve the stability of the machine? For instance, if we're OK with making builds slower, we can skip the prebuild on this platform and always run make.bash, even for subrepos. Fetching the tip-of-tree is a bit unavoidable for subrepo builds though, because those builds can only be triggered by one source. Perhaps we can target a different service, or add some other exception.
The text was updated successfully, but these errors were encountered:
All my riscv-builders are located in my homelab in Shenzhen, China, which is home ADSL network.
may be I can transfer these riscv development boards/boxes to a server-farm if possible for more stable/better QoS network. (Looking for funding from RISCV companies here.)
This is a ping latency graph of go.googlesoure.com/*.appspot.com in 24 hours, it looks pretty good to me that all packages go around the whole planet (<180ms)
Thanks for looking into that! The other category of issues I've seen is that the cas download step fails (because the attempt to download, and the retries) fail too. I can provide some instructions on how to try to reproduce that if it would be helpful.