date:20220105

✅ PASS: Test report for kernel 5.15.13-100.fc34 (fedora-34)

2022-01-05 Thread CKI Project

Hello,

We ran automated tests on the following kernel build:

Kernel package: kernel-5.15.13-100.fc34
 Task URL: https://koji.fedoraproject.org/koji/taskinfo?taskID=80874708

The results of these automated tests are provided below.

Overall result: PASSED
 Tests: OK



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/2022/01/05/442311453

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.
For the full detail on our testing procedures, please scroll to the bottom of
this message.

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

Hardware testing

We booted each kernel and ran the following tests:

  aarch64:
Host 1:
   ✅ Boot test
   ✅ Reboot test
   ✅ ACPI table test
   ✅ LTP - cve
   ✅ LTP - sched
   ✅ LTP - syscalls
   ✅ LTP - can
   ✅ LTP - commands
   ✅ LTP - containers
   ✅ LTP - dio
   ✅ LTP - fs
   ✅ LTP - fsx
   ✅ LTP - math
   ✅ LTP - hugetlb
   ✅ LTP - mm
   ✅ LTP - nptl
   ✅ LTP - pty
   ✅ LTP - ipc
   ✅ LTP - tracing
   ✅ LTP: openposix test suite
   ✅ CIFS Connectathon
   ✅ Loopdev Sanity
   ✅ Memory: fork_mem
   ✅ Memory function: memfd_create
   ✅ AMTU (Abstract Machine Test Utility)
   ✅ Ethernet drivers sanity
    ✅ xarray-idr-radixtree-test
    ✅ NFS Connectathon

Host 2:
   ✅ Boot test
   ✅ Reboot test
   ✅ xfstests - ext4
   ✅ xfstests - xfs
   ✅ Storage: swraid mdadm raid_module test
    ✅ xfstests - btrfs
    ✅ Storage blktests - blk
    ✅ Storage blktests - nvme-tcp
    ✅ Storage block - filesystem fio test
    ✅ Storage block - queue scheduler test
    ✅ Storage block - storage fio numa
    ✅ storage: software RAID testing
    ✅ stress: stress-ng - interrupt
    ✅ stress: stress-ng - cpu
    ✅ stress: stress-ng - cpu-cache
    ✅ stress: stress-ng - memory
    ✅ stress: stress-ng - os

Host 3:
   ✅ Boot test
   ✅ Reboot test
    ❌ Storage blktests - nvmeof-mp

Host 4:
   ✅ Boot test
   ✅ Reboot test
    ✅ Storage blktests - srp

Host 5:

   ⚡ Internal infrastructure issues prevented one or more tests (marked
   with ⚡⚡⚡) from running on this architecture.
   This is not the fault of the kernel that was tested.

   ⚡⚡⚡ Boot test
   ⚡⚡⚡ Reboot test
   ⚡⚡⚡ Ethernet drivers sanity - mlx5

Host 6:
   ✅ Boot test
   ✅ Reboot test
   ✅ Ethernet drivers sanity - mlx5

  ppc64le:
Host 1:
   ✅ Boot test
   ✅ Reboot test
   ✅ LTP - cve
   ✅ LTP - sched
   ✅ LTP - syscalls
   ✅ LTP - can
   ✅ LTP - commands
   ✅ LTP - containers
   ✅ LTP - dio
   ✅ LTP - fs
   ✅ LTP - fsx
   ✅ LTP - math
   ✅ LTP - hugetlb
   ✅ LTP - mm
   ✅ LTP - nptl
   ✅ LTP - pty
   ✅ LTP - ipc
   ✅ LTP - tracing
   ✅ LTP: openposix test suite
   ✅ CIFS Connectathon
   ✅ Loopdev Sanity
   ✅ Memory: fork_mem
   ✅ Memory function: memfd_create
   ✅ AMTU (Abstract Machine Test Utility)
   ✅ Ethernet drivers sanity
    ✅ xarray-idr-radixtree-test
    ✅ NFS Connectathon

Host 2:
   ✅ Boot test
   ✅ Reboot test
    ❌ Storage blktests - nvmeof-mp

Host 3:
   ✅ Boot test
   ✅ Reboot test
   ✅ xfstests - ext4
   ✅ xfstests - xfs
   ✅ Storage: swraid mdadm raid_module test
    ✅ xfstests - btrfs
    ✅ Storage blktests - blk
    ✅ Storage blktests - nvme-tcp
    ✅ Storage block - filesystem fio test
    ✅ Storage block - queue scheduler test
    ❌ Storage block - storage fio numa
    ✅ Storage: lvm device-mapper test - upstream
    ✅ storage: software RAID testing

Host 4:
   ✅ Boot test
   ✅ Reboot test
    ❌ Storage blktests - srp

  s390x:
Host 1:
   ✅ Boot test
   ✅ Reboot test
   ✅ Storage: swraid mdadm raid_module test
    ✅ Storage blktests - blk
    ✅ Storage blktests - nvme-tcp
    ✅ stress: stress-ng - interrupt
    ✅ stress: stress-ng - cpu
    ✅ stress: stress-ng - cpu-cache
    ✅ stress: stress-ng - memory
    ✅ stress: stress-ng - os

Host 2:
   ✅ Boot test
   ✅ Reboot test
   ✅ LTP - cve
   ✅ LTP - sched
   ✅ LTP - syscalls
   ✅ LTP - can
   ✅ LTP - commands
   ✅ LTP - containers
   ✅ LTP - dio
   ✅ LTP - fs
   ✅ LTP - fsx
   ✅ LTP - math
   ✅ LTP - hugetlb
   ✅ LTP - mm
   ✅ LTP - nptl
   ✅ LTP

Re: [OS-BUILD PATCHv2] Turn CONFIG_DEVMEM back off for aarch64

2022-01-05 Thread Justin M. Forbes (via Email Bridge)

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1408#note_802380446

With the new push, we end up with:

kernel-aarch64-debug-rhel.config
```
CONFIG_DEVMEM=y
# CONFIG_IO_STRICT_DEVMEM is not set
# CONFIG_STRICT_DEVMEM is not set
```

kernel-aarch64-rhel.config
```
# CONFIG_DEVMEM is not set
# CONFIG_IO_STRICT_DEVMEM is not set
# CONFIG_STRICT_DEVMEM is not set
```
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[OS-BUILD PATCHv2] Turn CONFIG_DEVMEM back off for aarch64

2022-01-05 Thread Justin M. Forbes (via Email Bridge)

From: Justin M. Forbes 

Turn CONFIG_DEVMEM back off for aarch64

We have ended up with a config mismatch for the RHEL configs in a way
that was unclear and untracked. CONFIG_STRICT_DEVMEM is enabled in
configs/common/generic, but CONFIG_DEVMEM was disabled for aarch64 in
RHEL (though not in Fedora). This creates a mismatch situation where the
configs do not get generated in the way they are set.  Our options are
to either turn off CONFIG_STRICT_DEVMEM as I have here, or turn on
CONFIG_DEVMEM for aarch64.  I went with the former after discussion in
the MR.

Signed-off-by: Justin M. Forbes 

diff --git a/redhat/configs/ark/generic/arm/aarch64/CONFIG_STRICT_DEVMEM 
b/redhat/configs/ark/generic/arm/aarch64/CONFIG_STRICT_DEVMEM
new file mode 100644
index blahblah..blahblah 100644
--- /dev/null
+++ b/redhat/configs/ark/generic/arm/aarch64/CONFIG_STRICT_DEVMEM
@@ -0,0 +1 @@
+# CONFIG_STRICT_DEVMEM is not set
diff --git a/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_DEVMEM 
b/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_DEVMEM
deleted file mode 100644
index blahblah..blahblah 0
--- a/redhat/configs/pending-common/generic/arm/aarch64/CONFIG_DEVMEM
+++ /dev/null
@@ -1 +0,0 @@
-CONFIG_DEVMEM=y

--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1408
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [OS-BUILD PATCH] Turn CONFIG_DEVMEM back on for aarch64

2022-01-05 Thread Justin M. Forbes (via Email Bridge)

From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1408#note_802369351

> (2) are we turning this on because there is a Customer need, or because the
script for configs can't handle it?  The former makes sense, but the latter
would be puzzling to me.

The script for configs can handle any valid configs, the problem is you have
an invalid config.  As to what has been reviewed and approved, aarch64 would
have CONFIG_DEVMEM off and CONFIG_STRICT_DEVMEM on.  The later would silently
flip CONFIG_DEVMEM to on, but our scripts alert us that it is happening and
will not allow it because it is not what we have set.

> If we're going to leave it enabled, we want STRICT_DEVMEM=y so it's not so
easy to crash the kernel. But turning DEVMEM on only for the -debug kernel
makes the most sense to me.

I am happy to flip it back to off for aarch64 RHEL configs. The mismatch just
has to be cleared up in one way or another.  As it was, we had untracked files
in pending-common.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [OS-BUILD PATCH] Turn CONFIG_DEVMEM back on for aarch64

2022-01-05 Thread Mark Salter (via Email Bridge)

From: Mark Salter on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1408#note_802354124

Back in the RHELSA-7 days, we decided to turn off CONFIG_DEVMEM because
certain userspace tools which were not sufficiently Arm-aware would crash the
kernel. Someone (Applied Micro or Cavium) complained that there was debug
value in having it enabled so we enabled it in -debug kernels. With RHEL-8, we
missed the addition of STRICT_DEVMEM and it defaulted to =y even though DEVMEM
was turned off so it didn't matter. Now we have DEVMEM enabled on RHEL-9 non-
debug kernel. If we're going to leave it enabled, we want STRICT_DEVMEM=y so
it's not so easy to crash the kernel. But turning DEVMEM on only for the
-debug kernel makes the most sense to me.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [OS-BUILD PATCH] Turn CONFIG_DEVMEM back on for aarch64

2022-01-05 Thread Al Stone

On 05 Jan 2022 15:40, Mark Langsdorf (via Email Bridge) wrote:
> From: Mark Langsdorf on gitlab.com
> https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1408#note_802171332
> 
> Adding msalter in hopes he can clear this up.

Excellent idea.  I have two concerns: (1) why do we need to turn this
on when upstream has worked so hard to turn it off?  and (2) are we
turning this on because there is a Customer need, or because the script
for configs can't handle it?  The former makes sense, but the latter
would be puzzling to me.
___
> kernel mailing list -- kernel@lists.fedoraproject.org
> To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

-- 
ciao,
al
---
Al Stone
Principal Software Engineer
Red Hat, Inc.
a...@redhat.com
---
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [OS-BUILD PATCH] Turn CONFIG_DEVMEM back on for aarch64

2022-01-05 Thread Mark Langsdorf (via Email Bridge)

From: Mark Langsdorf on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1408#note_802171332

Adding msalter in hopes he can clear this up.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[OS-BUILD PATCH] [redhat] virtio: enable virtio-mem on x86-64 as tech-preview

2022-01-05 Thread David Hildenbrand (via Email Bridge)

From: David Hildenbrand 

[redhat] virtio: enable virtio-mem on x86-64 as tech-preview

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2014492

Let's enable CONFIG_VIRTIO_MEM=m on x86-64 in RHEL 9. As it will be
tech-preview, properly taint the kernel as soon as we're initializing
the driver for an actual device in a !kdump environment where we might
actually hot(un)plug memory when instructed by the hypervisor.

We won't be tainting in a kdump kernel where the sole purpose is to check
if a given PFN is actually part of a plugged virtio-mem device and can
be dumped safely.

Signed-off-by: David Hildenbrand 

diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
index blahblah..blahblah 100644
--- a/drivers/virtio/virtio_mem.c
+++ b/drivers/virtio/virtio_mem.c
@@ -2754,6 +2754,19 @@ static int virtio_mem_probe(struct virtio_device *vdev)
 
/* trigger a config update to start processing the requested_size */
if (!vm->in_kdump) {
+#ifdef CONFIG_RHEL_DIFFERENCES
+   static bool printed;
+
+   /*
+* virtio-mem, and especially its memory hot(un)plug
+* functionality, is tech-preview.
+*/
+   if (!printed) {
+   printed = true;
+   mark_tech_preview("virtio_mem", THIS_MODULE);
+   }
+#endif /* CONFIG_RHEL_DIFFERENCES */
+
atomic_set(>config_changed, 1);
queue_work(system_freezable_wq, >wq);
}
diff --git a/redhat/configs/common/generic/x86/x86_64/CONFIG_VIRTIO_MEM 
b/redhat/configs/common/generic/x86/x86_64/CONFIG_VIRTIO_MEM
index blahblah..blahblah 100644
--- a/redhat/configs/common/generic/x86/x86_64/CONFIG_VIRTIO_MEM
+++ b/redhat/configs/common/generic/x86/x86_64/CONFIG_VIRTIO_MEM
@@ -1 +1 @@
-# CONFIG_VIRTIO_MEM is not set
+CONFIG_VIRTIO_MEM=m
diff --git a/redhat/configs/fedora/generic/x86/x86_64/CONFIG_VIRTIO_MEM 
b/redhat/configs/fedora/generic/x86/x86_64/CONFIG_VIRTIO_MEM
deleted file mode 100644
index blahblah..blahblah 0
--- a/redhat/configs/fedora/generic/x86/x86_64/CONFIG_VIRTIO_MEM
+++ /dev/null
@@ -1 +0,0 @@
-CONFIG_VIRTIO_MEM=m

--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1535
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [OS-BUILD PATCH] Revert "[redhat] Generate a crashkernel.default for each kernel build"

2022-01-05 Thread Philipp Rudo (via Email Bridge)

From: Philipp Rudo on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1534#note_801910634

Hi Coiby,
the commit looks good to me.

Reviewed-by: Philipp Rudo 
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

✅ PASS: Test report for kernel 5.15.13-100.fc34 (fedora-34)

Re: [OS-BUILD PATCHv2] Turn CONFIG_DEVMEM back off for aarch64

[OS-BUILD PATCHv2] Turn CONFIG_DEVMEM back off for aarch64

Re: [OS-BUILD PATCH] Turn CONFIG_DEVMEM back on for aarch64

Re: [OS-BUILD PATCH] Turn CONFIG_DEVMEM back on for aarch64

Re: [OS-BUILD PATCH] Turn CONFIG_DEVMEM back on for aarch64

Re: [OS-BUILD PATCH] Turn CONFIG_DEVMEM back on for aarch64

[OS-BUILD PATCH] [redhat] virtio: enable virtio-mem on x86-64 as tech-preview

Re: [OS-BUILD PATCH] Revert "[redhat] Generate a crashkernel.default for each kernel build"

9 matches

Site Navigation

Mail list logo

Footer information