linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* ❌ FAIL: Test report for kernel 5.13.0-rc4 (arm-next, 8124c8a6)
@ 2021-06-02  1:35 CKI Project
  2021-06-02 10:12 ` Will Deacon
  0 siblings, 1 reply; 6+ messages in thread
From: CKI Project @ 2021-06-02  1:35 UTC (permalink / raw)
  To: skt-results-master, will, catalin.marinas, linux-arm-kernel
  Cc: Memory Management, Jan Stancek, Fendy Tjahjadi, Jeff Bastian


Hello,

We ran automated tests on a recent commit from this kernel tree:

       Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
            Commit: 8124c8a6b353 - Linux 5.13-rc4

The results of these automated tests are provided below.

    Overall result: FAILED (see details below)
             Merge: OK
           Compile: OK
             Tests: FAILED

All kernel binaries, config files, and logs are available for download here:

  https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/index.html?prefix=datawarehouse-public/2021/06/01/313156257

One or more kernel tests failed:

    aarch64:
     ❌ LTP
     💥 stress: stress-ng

We hope that these logs can help you find the problem quickly. For the full
detail on our testing procedures, please scroll to the bottom of this message.

Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.

        ,-.   ,-.
       ( C ) ( K )  Continuous
        `-',-.`-'   Kernel
          ( I )     Integration
           `-'
______________________________________________________________________________

Compile testing
---------------

We compiled the kernel for 1 architecture:

    aarch64:
      make options: make -j24 INSTALL_MOD_STRIP=1 targz-pkg



Hardware testing
----------------
We booted each kernel and ran the following tests:

  aarch64:
    Host 1:
       ✅ Boot test
       ✅ ACPI table test
       ✅ ACPI enabled test
       ❌ LTP
       ✅ CIFS Connectathon
       ✅ POSIX pjd-fstest suites
       ✅ Loopdev Sanity
       ✅ jvm - jcstress tests
       ✅ Memory: fork_mem
       ✅ Memory function: memfd_create
       ✅ AMTU (Abstract Machine Test Utility)
       ✅ Networking bridge: sanity
       ✅ Ethernet drivers sanity
       ✅ Networking socket: fuzz
       ✅ Networking: igmp conformance test
       ✅ Networking route: pmtu
       ✅ Networking route_func - local
       ✅ Networking route_func - forward
       ✅ Networking TCP: keepalive test
       ✅ Networking UDP: socket
       ✅ Networking cki netfilter test
       ✅ Networking tunnel: geneve basic test
       ✅ Networking tunnel: gre basic
       ✅ L2TP basic test
       ✅ Networking tunnel: vxlan basic
       ✅ Networking ipsec: basic netns - transport
       ✅ Networking ipsec: basic netns - tunnel
       ✅ Libkcapi AF_ALG test
       ✅ pciutils: update pci ids test
       ✅ ALSA PCM loopback test
       ✅ ALSA Control (mixer) Userspace Element test
       ✅ storage: SCSI VPD
       ✅ trace: ftrace/tracer
       🚧 ✅ xarray-idr-radixtree-test
       🚧 ✅ i2c: i2cdetect sanity
       🚧 ✅ Firmware test suite
       🚧 ✅ Memory function: kaslr
       🚧 ✅ audit: audit testsuite test

    Host 2:
       ✅ Boot test
       ✅ xfstests - ext4
       ✅ xfstests - xfs
       ✅ selinux-policy: serge-testsuite
       ✅ storage: software RAID testing
       ✅ Storage: swraid mdadm raid_module test
       🚧 ❌ Podman system integration test - as root
       🚧 ❌ Podman system integration test - as user
       🚧 ✅ xfstests - btrfs
       🚧 ✅ IPMI driver test
       🚧 ✅ IPMItool loop stress test
       🚧 ✅ Storage blktests
       🚧 ✅ Storage block - filesystem fio test
       🚧 ✅ Storage block - queue scheduler test
       🚧 ✅ Storage nvme - tcp
       🚧 ✅ Storage: lvm device-mapper test
       🚧 💥 stress: stress-ng

  Test sources: https://gitlab.com/cki-project/kernel-tests
    💚 Pull requests are welcome for new tests or improvements to existing tests!

Aborted tests
-------------
Tests that didn't complete running successfully are marked with ⚡⚡⚡.
If this was caused by an infrastructure issue, we try to mark that
explicitly in the report.

Waived tests
------------
If the test run included waived tests, they are marked with 🚧. Such tests are
executed but their results are not taken into account. Tests are waived when
their results are not reliable enough, e.g. when they're just introduced or are
being fixed.

Testing timeout
---------------
We aim to provide a report within reasonable timeframe. Tests that haven't
finished running yet are marked with ⏱.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: ❌ FAIL: Test report for kernel 5.13.0-rc4 (arm-next, 8124c8a6)
  2021-06-02  1:35 ❌ FAIL: Test report for kernel 5.13.0-rc4 (arm-next, 8124c8a6) CKI Project
@ 2021-06-02 10:12 ` Will Deacon
  2021-06-02 10:34   ` ? " Mark Rutland
       [not found]   ` <CAMj1kXENsUScpTg294HDiQUUXuUBz438hysEM9M4N-Jcq+q2fA@mail.gmail.com>
  0 siblings, 2 replies; 6+ messages in thread
From: Will Deacon @ 2021-06-02 10:12 UTC (permalink / raw)
  To: CKI Project, ardb, lorenzo.pieralisi, anshuman.khandual,
	mark.rutland, maz
  Cc: skt-results-master, catalin.marinas, linux-arm-kernel,
	Memory Management, Jan Stancek, Fendy Tjahjadi, Jeff Bastian

Hi all,

On Wed, Jun 02, 2021 at 01:35:01AM -0000, CKI Project wrote:
> We ran automated tests on a recent commit from this kernel tree:
> 
>        Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
>             Commit: 8124c8a6b353 - Linux 5.13-rc4

As above, this is a run against plain -rc4 in preparation for testing the
5.14 queue on top to detect any regressions.

> The results of these automated tests are provided below.
> 
>     Overall result: FAILED (see details below)
>              Merge: OK
>            Compile: OK
>              Tests: FAILED
> 
> All kernel binaries, config files, and logs are available for download here:
> 
>   https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/index.html?prefix=datawarehouse-public/2021/06/01/313156257
> 
> One or more kernel tests failed:
> 
>     aarch64:
>      ❌ LTP

The two tests failing here are 'statx04' and 'hugeshmat04':

https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/datawarehouse-public/2021/06/01/313156257/build_aarch64_redhat%3A1310052388/tests/LTP/10079826_aarch64_1_resultoutputfile.log

(grep for FAIL). I've not had a chance to dig into them yet.

>      💥 stress: stress-ng

This explodes pretty badly. Some CPUs detect RCU stalls when trying to use
the EFI "efi_read_time" service, which eventually fails but soon after we
explode trying to access memory which I think is mapped by
acpi_os_ioremap(), so it looks like the f/w might be the culprit here. Is
the "HPE Apollo 70" machine known to have bad EFI firmware?

https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/datawarehouse-public/2021/06/01/313156257/build_aarch64_redhat%3A1310052388/tests/stress_stress_ng/10079827_aarch64_2_dmesg.log

(scroll to the end for the fireworks)

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: ? FAIL: Test report for kernel 5.13.0-rc4 (arm-next, 8124c8a6)
  2021-06-02 10:12 ` Will Deacon
@ 2021-06-02 10:34   ` Mark Rutland
       [not found]   ` <CAMj1kXENsUScpTg294HDiQUUXuUBz438hysEM9M4N-Jcq+q2fA@mail.gmail.com>
  1 sibling, 0 replies; 6+ messages in thread
From: Mark Rutland @ 2021-06-02 10:34 UTC (permalink / raw)
  To: Will Deacon
  Cc: CKI Project, ardb, lorenzo.pieralisi, anshuman.khandual, maz,
	skt-results-master, catalin.marinas, linux-arm-kernel,
	Memory Management, Jan Stancek, Fendy Tjahjadi, Jeff Bastian

On Wed, Jun 02, 2021 at 11:12:27AM +0100, Will Deacon wrote:
> Hi all,
> 
> On Wed, Jun 02, 2021 at 01:35:01AM -0000, CKI Project wrote:
> > We ran automated tests on a recent commit from this kernel tree:
> > 
> >        Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
> >             Commit: 8124c8a6b353 - Linux 5.13-rc4
> 
> As above, this is a run against plain -rc4 in preparation for testing the
> 5.14 queue on top to detect any regressions.
> 
> > The results of these automated tests are provided below.
> > 
> >     Overall result: FAILED (see details below)
> >              Merge: OK
> >            Compile: OK
> >              Tests: FAILED
> > 
> > All kernel binaries, config files, and logs are available for download here:
> > 
> >   https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/index.html?prefix=datawarehouse-public/2021/06/01/313156257
> > 
> > One or more kernel tests failed:
> > 
> >     aarch64:
> >      ❌ LTP
> 
> The two tests failing here are 'statx04' and 'hugeshmat04':
> 
> https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/datawarehouse-public/2021/06/01/313156257/build_aarch64_redhat%3A1310052388/tests/LTP/10079826_aarch64_1_resultoutputfile.log
> 
> (grep for FAIL). I've not had a chance to dig into them yet.

I'm dumping some info below in case this is helpful for anyone.

For statx04, the logs at:

https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/datawarehouse-public/2021/06/01/313156257/build_aarch64_redhat%3A1310052388/tests/LTP/10079826_aarch64_1_syscalls.run.log

... have a bunch of successful successful statx04 tests, then one fails
on a FUSE directory:

| tst_test.c:899: TINFO: Trying FUSE...
| tst_test.c:1311: TINFO: Timeout per run is 0h 05m 00s
| statx04.c:44: TPASS: sys_statx(AT_FDCWD, mntpoint/test_dir1, 0, 0, &buf)
| statx04.c:53: TFAIL: STATX_ATTR_COMPRESSED flag is not set
| statx04.c:58: TFAIL: STATX_ATTR_APPEND flag is not set
| statx04.c:63: TFAIL: STATX_ATTR_IMMUTABLE flag is not set
| statx04.c:68: TFAIL: STATX_ATTR_NODUMP flag is not set
| statx04.c:77: TPASS: sys_statx(AT_FDCWD, mntpoint/test_dir2, 0, 0, &buf)
| statx04.c:86: TPASS: STATX_ATTR_COMPRESSED flag is not set
| statx04.c:91: TPASS: STATX_ATTR_APPEND flag is not set
| statx04.c:96: TPASS: STATX_ATTR_IMMUTABLE flag is not set
| statx04.c:101: TPASS: STATX_ATTR_NODUMP flag is not set
| tst_test.c:1379: TINFO: Testing on tmpfs
| tst_test.c:888: TINFO: Skipping mkfs for TMPFS filesystem
| tst_test.c:1311: TINFO: Timeout per run is 0h 05m 00s
| statx04.c:127: TCONF: FS_IOC_GETFLAGS not supported: ENOTTY (25)

I don't know whether that's expected or not -- do we have a good run to
compare to? ... and is this potentially the first time we've tested
this?

For hugeshmat04 the logs at:

https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/datawarehouse-public/2021/06/01/313156257/build_aarch64_redhat%3A1310052388/tests/LTP/10079826_aarch64_1_hugetlb.run.log

... don't give much of an indication of the problem:

| tst_hugepage.c:58: TINFO: 1 hugepage(s) reserved
| tst_test.c:1311: TINFO: Timeout per run is 0h 05m 00s
| tst_hugepage.c:58: TINFO: 513 hugepage(s) reserved
| hugeshmat04.c:60: TBROK: shmat: EINVAL (22)

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: ❌ FAIL: Test report for kernel 5.13.0-rc4 (arm-next, 8124c8a6)
       [not found]   ` <CAMj1kXENsUScpTg294HDiQUUXuUBz438hysEM9M4N-Jcq+q2fA@mail.gmail.com>
@ 2021-06-02 10:51     ` Will Deacon
       [not found]       ` <CA+tGwnn+9XCDB69LxY1AEoNih_qCovwYsuNHzbwyUN8LmZTTAg@mail.gmail.com>
  0 siblings, 1 reply; 6+ messages in thread
From: Will Deacon @ 2021-06-02 10:51 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: CKI Project, Lorenzo Pieralisi, Anshuman Khandual, Mark Rutland,
	Marc Zyngier, skt-results-master, Catalin Marinas, Linux ARM,
	Memory Management, Jan Stancek, Fendy Tjahjadi, Jeff Bastian

On Wed, Jun 02, 2021 at 12:40:07PM +0200, Ard Biesheuvel wrote:
> On Wed, 2 Jun 2021 at 12:12, Will Deacon <will@kernel.org> wrote:
> >
> > Hi all,
> >
> > On Wed, Jun 02, 2021 at 01:35:01AM -0000, CKI Project wrote:
> > > We ran automated tests on a recent commit from this kernel tree:
> > >
> > >        Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
> > >             Commit: 8124c8a6b353 - Linux 5.13-rc4
> >
> > As above, this is a run against plain -rc4 in preparation for testing the
> > 5.14 queue on top to detect any regressions.
> >
> > > The results of these automated tests are provided below.
> > >
> > >     Overall result: FAILED (see details below)
> > >              Merge: OK
> > >            Compile: OK
> > >              Tests: FAILED
> > >
> > > All kernel binaries, config files, and logs are available for download here:
> > >
> > >   https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/index.html?prefix=datawarehouse-public/2021/06/01/313156257
> > >
> > > One or more kernel tests failed:
> > >
> > >     aarch64:
> > >      ❌ LTP
> >
> > The two tests failing here are 'statx04' and 'hugeshmat04':
> >
> > https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/datawarehouse-public/2021/06/01/313156257/build_aarch64_redhat%3A1310052388/tests/LTP/10079826_aarch64_1_resultoutputfile.log
> >
> > (grep for FAIL). I've not had a chance to dig into them yet.
> >
> > >      stress: stress-ng
> >
> > This explodes pretty badly. Some CPUs detect RCU stalls when trying to use
> > the EFI "efi_read_time" service, which eventually fails but soon after we
> > explode trying to access memory which I think is mapped by
> > acpi_os_ioremap(), so it looks like the f/w might be the culprit here. Is
> > the "HPE Apollo 70" machine known to have bad EFI firmware?
> >
> > https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/datawarehouse-public/2021/06/01/313156257/build_aarch64_redhat%3A1310052388/tests/stress_stress_ng/10079827_aarch64_2_dmesg.log
> >
> > (scroll to the end for the fireworks)
> >
> 
> Wow that looks pretty horrible. I take it this tree has your MAIR changes?

Nope, this is just vanilla -rc4! I'm trying to get a "known good" base
before I throw all the new things at it :)

> Would be useful to have a log with efi=debug, to see what the EFI
> memory map looks like.

Veronika -- please could you help us with that?

> Note that efi_read_time() kicks a separate worker thread to perform
> the actual call into the firmware, so the CPU stalling on
> efi_read_time() is kind of expected and not as interesting as the one
> doing the actual call.

Fair enough, although the _dev_err() in the backtrace implies the call
failed so I became suspicious.

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: ❌ FAIL: Test report for kernel 5.13.0-rc4 (arm-next, 8124c8a6)
       [not found]       ` <CA+tGwnn+9XCDB69LxY1AEoNih_qCovwYsuNHzbwyUN8LmZTTAg@mail.gmail.com>
@ 2021-06-02 17:10         ` Will Deacon
       [not found]           ` <CA+tGwn=Y63hMdHpP16i4YD1qx-hwnSxfWsNgC+Kh-SDxXZpqGA@mail.gmail.com>
  0 siblings, 1 reply; 6+ messages in thread
From: Will Deacon @ 2021-06-02 17:10 UTC (permalink / raw)
  To: Veronika Kabatova
  Cc: Ard Biesheuvel, Mark Rutland, Lorenzo Pieralisi,
	Anshuman Khandual, Marc Zyngier, Memory Management,
	skt-results-master, Jeff Bastian, CKI Project, Catalin Marinas,
	Jan Stancek, Linux ARM

On Wed, Jun 02, 2021 at 01:00:47PM +0200, Veronika Kabatova wrote:
> On Wed, Jun 2, 2021 at 12:51 PM Will Deacon <will@kernel.org> wrote:
> > On Wed, Jun 02, 2021 at 12:40:07PM +0200, Ard Biesheuvel wrote:
> > > On Wed, 2 Jun 2021 at 12:12, Will Deacon <will@kernel.org> wrote:
> > > > On Wed, Jun 02, 2021 at 01:35:01AM -0000, CKI Project wrote:
> > > > >      stress: stress-ng
> > > >
> > > > This explodes pretty badly. Some CPUs detect RCU stalls when trying to use
> > > > the EFI "efi_read_time" service, which eventually fails but soon after we
> > > > explode trying to access memory which I think is mapped by
> > > > acpi_os_ioremap(), so it looks like the f/w might be the culprit here. Is
> > > > the "HPE Apollo 70" machine known to have bad EFI firmware?
> > > >
> > > > https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/datawarehouse-public/2021/06/01/313156257/build_aarch64_redhat%3A1310052388/tests/stress_stress_ng/10079827_aarch64_2_dmesg.log
> > > >
> > > > (scroll to the end for the fireworks)
> > > >
> > >
> > > Wow that looks pretty horrible. I take it this tree has your MAIR changes?
> >
> > Nope, this is just vanilla -rc4! I'm trying to get a "known good" base
> > before I throw all the new things at it :)
> >
> > > Would be useful to have a log with efi=debug, to see what the EFI
> > > memory map looks like.
> >
> > Veronika -- please could you help us with that?
> 
> Sure, I'll get a rerun with that option and report back when I have any
> results. I am also planning just a plain rerun on the machine to see if it
> reproduces somewhat reliably, however the machine is taken up by
> other automation now so it will take a while.

Thanks. In the meantime, I've pushed a bunch of new stuff into for-kernelci,
so I can at least see if it regresses when compared to the three failures
we're seeing here.

> My original reply is sitting in moderation queue as I wasn't subscribed
> (hopefully now after subscribing this email will get to the list...) but for
> the new people on the thread, one of the LTP issues is a potential
> testing bug:
> 
> https://gitlab.com/cki-project/kernel-tests/-/issues/577

Aha, good. That at least looks like a generic (non-arm64) thing that we can
ignore for the purposes of the arm64 tree.

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: ❌ FAIL: Test report for kernel 5.13.0-rc4 (arm-next, 8124c8a6)
       [not found]             ` <CA+tGwn=BG6nUQcs_Q2a1h=UDPwR6ern2wQPwQ84kz=c2xB5-Wg@mail.gmail.com>
@ 2021-06-11 10:34               ` Will Deacon
  0 siblings, 0 replies; 6+ messages in thread
From: Will Deacon @ 2021-06-11 10:34 UTC (permalink / raw)
  To: Veronika Kabatova
  Cc: Ard Biesheuvel, Mark Rutland, Lorenzo Pieralisi,
	Anshuman Khandual, Marc Zyngier, Memory Management,
	skt-results-master, Jeff Bastian, CKI Project, Catalin Marinas,
	Jan Stancek, Linux ARM

On Thu, Jun 10, 2021 at 01:59:12PM +0200, Veronika Kabatova wrote:
> On Thu, Jun 3, 2021 at 12:44 PM Veronika Kabatova <vkabatov@redhat.com> wrote:
> >
> > On Wed, Jun 2, 2021 at 7:10 PM Will Deacon <will@kernel.org> wrote:
> > >
> > > On Wed, Jun 02, 2021 at 01:00:47PM +0200, Veronika Kabatova wrote:
> > > > On Wed, Jun 2, 2021 at 12:51 PM Will Deacon <will@kernel.org> wrote:
> > > > > On Wed, Jun 02, 2021 at 12:40:07PM +0200, Ard Biesheuvel wrote:
> > > > > > On Wed, 2 Jun 2021 at 12:12, Will Deacon <will@kernel.org> wrote:
> > > > > > > On Wed, Jun 02, 2021 at 01:35:01AM -0000, CKI Project wrote:
> > > > > > > >      stress: stress-ng
> > > > > > >
> > > > > > > This explodes pretty badly. Some CPUs detect RCU stalls when trying to use
> > > > > > > the EFI "efi_read_time" service, which eventually fails but soon after we
> > > > > > > explode trying to access memory which I think is mapped by
> > > > > > > acpi_os_ioremap(), so it looks like the f/w might be the culprit here. Is
> > > > > > > the "HPE Apollo 70" machine known to have bad EFI firmware?
> > > > > > >
> > > > > > > https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/datawarehouse-public/2021/06/01/313156257/build_aarch64_redhat%3A1310052388/tests/stress_stress_ng/10079827_aarch64_2_dmesg.log
> > > > > > >
> > > > > > > (scroll to the end for the fireworks)
> > > > > > >
> > > > > >
> > > > > > Wow that looks pretty horrible. I take it this tree has your MAIR changes?
> > > > >
> > > > > Nope, this is just vanilla -rc4! I'm trying to get a "known good" base
> > > > > before I throw all the new things at it :)
> > > > >
> > > > > > Would be useful to have a log with efi=debug, to see what the EFI
> > > > > > memory map looks like.
> > > > >
> > > > > Veronika -- please could you help us with that?
> > > >
> > > > Sure, I'll get a rerun with that option and report back when I have any
> > > > results. I am also planning just a plain rerun on the machine to see if it
> > > > reproduces somewhat reliably, however the machine is taken up by
> > > > other automation now so it will take a while.
> > >
> > > Thanks. In the meantime, I've pushed a bunch of new stuff into for-kernelci,
> > > so I can at least see if it regresses when compared to the three failures
> > > we're seeing here.
> > >
> >
> > Hi,
> >
> > I don't have very good news so far. We did 4 targeted runs with the machine
> > and weren't able to reproduce the panic. However, there was a panic hit in
> > the new test run you should have in the inbox and it also reproduced in a
> > completely unrelated test run with *this* kernel (not the new one). In all 3
> > cases the HW model is the same, but they were all different machines.
> >
> > I'm currently doing a full run which includes all tests from the run instead
> > of just stress-ng to see if it reproduces that way - there was a panic case
> > last year (not ARM specific :) that we weren't able to pinpoint to a nice
> > reproducer and had to run multiple tests to trigger it so it's possible this
> > one is similar. I'll try to pair down the tests if this strategy works and
> > keep you updated.
> >
> 
> I just wanted to follow up here. Outside of the single run I mentioned
> previously, we are still unable to reproduce the panic. We tried a lot of
> runs on the various machines of the model that hit it, with both full test
> runs and stress-ng test only.
> 
> We'll still reach out if we manage to hit it in the future, but it looks like
> a race condition that's not easy to reproduce. Of course if anyone has
> an idea we should try (whether it's about reproducing or debugging what
> the problem is) we can try that.

Thanks for the follow-up, Veronika. I also noticed that it seems to have
disappeared from subsequent runs :/

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2021-06-11 10:37 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-02  1:35 ❌ FAIL: Test report for kernel 5.13.0-rc4 (arm-next, 8124c8a6) CKI Project
2021-06-02 10:12 ` Will Deacon
2021-06-02 10:34   ` ? " Mark Rutland
     [not found]   ` <CAMj1kXENsUScpTg294HDiQUUXuUBz438hysEM9M4N-Jcq+q2fA@mail.gmail.com>
2021-06-02 10:51     `  " Will Deacon
     [not found]       ` <CA+tGwnn+9XCDB69LxY1AEoNih_qCovwYsuNHzbwyUN8LmZTTAg@mail.gmail.com>
2021-06-02 17:10         ` Will Deacon
     [not found]           ` <CA+tGwn=Y63hMdHpP16i4YD1qx-hwnSxfWsNgC+Kh-SDxXZpqGA@mail.gmail.com>
     [not found]             ` <CA+tGwn=BG6nUQcs_Q2a1h=UDPwR6ern2wQPwQ84kz=c2xB5-Wg@mail.gmail.com>
2021-06-11 10:34               ` Will Deacon

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).