I suspect that this may be due to memory exhaustion; as noted in #49347 (comment), the freebsd-amd64-race builder has a higher CPU-to-RAM ratio than most of the other -race builders, which may cause its GOMAXPROCS to be fairly aggressive for the amount of available memory.
Since this was due to memory exhaustion (it looks like that to me too -- the OS won't let the runtime commit any more pages) and hasn't happened since Nov 19th, @bcmills what do you think about putting this in WaitingForInfo?
We can also try increasing decreasing the CPU-to-RAM ratio as you suggest, but I get the impression that this doesn't even get into any -race code. That is, unless I'm misunderstanding and the go command is actually built with -race. If that's the case, this may also be totally mitigated by https://go.devl/cl/333529 which imports a new TSAN runtime that uses a lot less memory (though I'm gonna guess that's coming in 1.19 at this point).
As far as I can tell this hasn't happened again (though I only have a partial image of the subrepo logs). This seems like just random memory exhaustion, especially given the builder config. I think we should just close this.