Hi,
On 19-05-2024 2:55 p.m., 陈 晟祺 wrote:
My concern now is that the results do not seem to be stable or reproducible.
That's an reoccurring problem in lots of places, yes.
Is there any convention in handling such situation? E.g., should I mark all
zfs-test-suite-x
as flaky and treat them
Hi,
> 2024年5月19日 13:51，Paul Gevers 写道：
>
> I already noticed yesterday and had it run; it failed. (Currently) top one
> here: https://ci.debian.net/packages/z/zfs-linux/testing/amd64/
>
My concern now is that the results do not seem to be stable or reproducible.
Seven tests have been run
Hi
On 19-05-2024 6:25 a.m., 陈 晟祺 wrote:
I have made more adjustments, basically skipping some flaky tests in VM.
Now new version 2.2.4-1 is in the archive, please try that again when available.
I already noticed yesterday and had it run; it failed. (Currently) top
one here:
Hi,
>
> The test ran. Unfortunately zfs-test-suite-1 failed.
>
I have made more adjustments, basically skipping some flaky tests in VM.
Now new version 2.2.4-1 is in the archive, please try that again when available.
Thanks,
Shengqi Chen
Hi,
On 08-04-2024 3:51 a.m., 陈 晟祺 wrote:
With resources limited to one CPU (AMD EPYC 7551) and 2G memory,
my local test could now reproduce the test hang and following time out error.
Ouch.
I think it is caused by insufficient resources (e.g. OOM killer, but I am not
sure).
Even we can
Hi Paul,
> 2024年4月7日 21:10，Paul Gevers 写道：
>
> Hi,
>
> The host that runs this is an m3-large instance at equinix [1].
>
> We create the qemu image with autopkgtest-build-qemu (default settings as far
> as I know).
>
> From within the testbed:
> root@host:~# lscpu
> lscpu
> Architecture:
6 matches
Mail list logo
