----- lu...@debian.org wrote: > On 14/11/16 at 02:47 -0800, Lars Tangvald wrote: > > > > ----- lu...@debian.org wrote: > > > > > On 13/11/16 at 22:59 -0800, Lars Tangvald wrote: > > > > > > > > ----- lu...@debian.org wrote: > > > > > > > > > > Do you have the logs from the last run? > > > > > > While we could disable the test that's failing, it would be > > > > > counterproductive since we can't reproduce the issue in any > of > > > our > > > > > normal build environments. > > > > > > > > > > This is the log without your patch applied > > > > > > > > > > Lucas > > > > > > > > Or did you mean with? > > > > > > no, the log was without the patch. I did not keep the log with > the > > > patch > > > > > > > It's failing in a different way. I think the way it's failing > here > > > is to do with insufficient system resources. > > > > > > unlikely, that node has 64 cores and 256 GB of RAM. > > > > > > Lucas > > > > I got it backwards, then :) > > A high number of cores might cause this if fs.aio-max-nr is set low > (cat /proc/sys/fs/aio-max-nr | aio-nr), or rather, too low for the the > parallelization used by the test run. > > https://www.kernel.org/doc/Documentation/sysctl/fs.txt > > Well, it was also failing on a more standard machine. The test suite > should be robust to that... > The original failure you reported was something else; a test failing because of an issue with the build environment. The patch I uploaded should make it more robust to that.
We could probably set some upper bound on the number of tests run in parallel based on the value of this setting, as Robie suggests. -- Lars > Lucas
