[OS-BUILD PATCH] RHMAINTAINERS: Reassign FIREWIRE
by GitLab Bridge on behalf of prarit
From: Prarit Bhargava <prarit(a)redhat.com>
Reassign FIREWIRE to Jarod.
Signed-off-by: Prarit Bhargava <prarit(a)redhat.com>
Cc: jarod(a)redhat.com
---
redhat/rhdocs/MAINTAINERS/RHMAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/redhat/rhdocs/MAINTAINERS/RHMAINTAINERS b/redhat/rhdocs/MAINTAINERS/RHMAINTAINERS
index a7bf575a4d1d..2ee6d6986ee6 100644
--- a/redhat/rhdocs/MAINTAINERS/RHMAINTAINERS
+++ b/redhat/rhdocs/MAINTAINERS/RHMAINTAINERS
@@ -637,7 +637,7 @@ F: include/linux/dax.h
F: include/trace/events/fs_dax.h
FIREWIRE SUBSYSTEM
-L: kernel-patches(a)redhat.com
+M: Jarod Wilson <jarod(a)redhat.com>
S: Maintained
F: drivers/firewire/
F: include/linux/firewire*.h
--
GitLab
3 years, 6 months
✅ PASS: Test report for kernel 5.8.12-200.fc32 (fedora-32)
by CKI Project
Hello jforbes,
We ran automated tests on the following kernel build:
Kernel package: kernel-5.8.12-200.fc32
Task URL: https://koji.fedoraproject.org/koji/taskinfo?taskID=52406311
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?pre...
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:
⚡ 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
✅ ACPI table test
✅ LTP
✅ Loopdev Sanity
✅ Memory: fork_mem
✅ Memory function: memfd_create
✅ AMTU (Abstract Machine Test Utility)
✅ Ethernet drivers sanity
🚧 ⚡⚡⚡ CIFS Connectathon
Host 2:
✅ Boot test
✅ xfstests - ext4
✅ xfstests - xfs
✅ stress: stress-ng
🚧 ✅ xfstests - btrfs
🚧 ✅ Storage blktests
🚧 ✅ Storage nvme - tcp
ppc64le:
Host 1:
✅ Boot test
🚧 ✅ kdump - sysrq-c
Host 2:
✅ Boot test
✅ xfstests - ext4
✅ xfstests - xfs
🚧 ✅ xfstests - btrfs
🚧 ✅ Storage blktests
🚧 ✅ Storage nvme - tcp
Host 3:
✅ Boot test
✅ LTP
✅ Loopdev Sanity
✅ Memory: fork_mem
✅ Memory function: memfd_create
✅ AMTU (Abstract Machine Test Utility)
✅ Ethernet drivers sanity
🚧 ✅ CIFS Connectathon
s390x:
Host 1:
✅ Boot test
✅ LTP
✅ Loopdev Sanity
✅ Memory: fork_mem
✅ Memory function: memfd_create
✅ AMTU (Abstract Machine Test Utility)
✅ Ethernet drivers sanity
🚧 ✅ CIFS Connectathon
Host 2:
✅ Boot test
✅ stress: stress-ng
🚧 ✅ Storage blktests
🚧 ✅ Storage nvme - tcp
x86_64:
Host 1:
✅ Boot test
✅ ACPI table test
✅ LTP
✅ Loopdev Sanity
✅ Memory: fork_mem
✅ Memory function: memfd_create
✅ AMTU (Abstract Machine Test Utility)
✅ Ethernet drivers sanity
🚧 ✅ CIFS Connectathon
Host 2:
✅ Boot test
🚧 ✅ kdump - sysrq-c
Host 3:
✅ Boot test
✅ xfstests - ext4
✅ xfstests - xfs
✅ stress: stress-ng
🚧 ✅ xfstests - btrfs
🚧 ✅ Storage blktests
🚧 ✅ Storage nvme - tcp
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 ⏱.
3 years, 6 months
[OS-BUILD PATCH] Separate merge-upstream and release stages
by GitLab Bridge on behalf of dzickusrh
From: Don Zickus <dzickus(a)redhat.com>
Now that the merge-upstream stage is separated and working, let's
remove it from the release stage. These scripts are already excuted by the
'merge-upstream' stage. This changes just removes the duplication. Trivial
change.
Signed-off-by: Don Zickus <dzickus(a)redhat.com>
---
redhat/scripts/ci/ark-create-release.sh | 3 ---
1 file changed, 3 deletions(-)
diff --git a/redhat/scripts/ci/ark-create-release.sh b/redhat/scripts/ci/ark-create-release.sh
index 0d4cfd9181e5..aeb3696f5caf 100755
--- a/redhat/scripts/ci/ark-create-release.sh
+++ b/redhat/scripts/ci/ark-create-release.sh
@@ -33,9 +33,6 @@ if [ -n "$BASE_RELEASE" ]; then
fi
git checkout os-build
-./redhat/scripts/ci/ark-rebase-patches.sh "$UPSTREAM_REF" "$PROJECT_ID"
-git checkout os-build
-./redhat/scripts/ci/ark-update-configs.sh "$UPSTREAM_REF" "$PROJECT_ID"
make dist-release
if git tag -v "$UPSTREAM_REF" > /dev/null 2>&1; then
--
GitLab
3 years, 7 months
[OS-BUILD PATCH] Filter out upstream commits from changelog
by GitLab Bridge on behalf of dzickusrh
From: Don Zickus <dzickus(a)redhat.com>
I updated the release code to include more changelog info
in the os-build branch. This resulted in adding upstream
merge commits. This is not interesting for a Fedora tree
as it is covered by a generic 'merge' entry.
Use a simple git trick to filter those upstream commits out, "^master".
See 'man gitrevisions' for more tricks.
Signed-off-by: Don Zickus <dzickus(a)redhat.com>
---
redhat/genspec.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/redhat/genspec.sh b/redhat/genspec.sh
index fbe275f6f4e7..ab135b1a2a1e 100755
--- a/redhat/genspec.sh
+++ b/redhat/genspec.sh
@@ -49,7 +49,7 @@ if [ -z "$lasttag" ]; then
lasttag=$MARKER
fi
echo "Gathering new log entries since $lasttag"
-git format-patch --no-renames -k --stdout ${lasttag}.. -- ":!/redhat/rhdocs" | awk '
+git format-patch --no-renames -k --stdout ^master ${lasttag}.. -- ":!/redhat/rhdocs" | awk '
BEGIN{TYPE="PATCHJUNK"; }
# add an entry to changelog
function changelog(subjectline, nameline, zstream)
--
GitLab
3 years, 7 months
❌ FAIL: Test report for kernel 5.9.0-0.rc7.20.cki.fc33 (ark)
by CKI Project
Hello,
We ran automated tests on a recent commit from this kernel tree:
Kernel repo: https://gitlab.com/cki-project/kernel-ark.git
Commit: 62a58e48134e - [redhat] kernel-5.9.0-0.rc7.19
The results of these automated tests are provided below.
Overall result: FAILED (see details below)
Merge: OK
Compile: FAILED
All kernel binaries, config files, and logs are available for download here:
https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/index.html?pre...
We attempted to compile the kernel for multiple architectures, but the compile
failed on one or more architectures:
aarch64: FAILED (see build-aarch64.log.xz attachment)
ppc64le: FAILED (see build-ppc64le.log.xz attachment)
s390x: FAILED (see build-s390x.log.xz attachment)
x86_64: FAILED (see build-x86_64.log.xz attachment)
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 4 architectures:
aarch64:
rpmbuild arguments: rpmbuild --target aarch64 --with=cross --with=kabidw_base --without=bpftool --without=selftests --without=debug --without=ipaclones --without=perf --without=tools
ppc64le:
rpmbuild arguments: rpmbuild --target ppc64le --with=cross --with=kabidw_base --without=bpftool --without=selftests --without=debug --without=ipaclones --without=perf --without=tools
s390x:
rpmbuild arguments: rpmbuild --target s390x --with=cross --with=kabidw_base --without=bpftool --without=selftests --without=debug --without=ipaclones --without=perf --without=tools
x86_64:
rpmbuild arguments: rpmbuild --target x86_64 --with=kabidw_base --without=debug
3 years, 7 months
❌ FAIL: Test report for kernel 5.9.0-0.rc6.19.cki.fc33 (ark)
by CKI Project
Hello,
We ran automated tests on a recent commit from this kernel tree:
Kernel repo: https://gitlab.com/cki-project/kernel-ark.git
Commit: 4f75c60245f1 - [redhat] kernel-5.9.0-0.rc6.20200927gita1bffa48745a.18
The results of these automated tests are provided below.
Overall result: FAILED (see details below)
Merge: OK
Compile: FAILED
All kernel binaries, config files, and logs are available for download here:
https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/index.html?pre...
We attempted to compile the kernel for multiple architectures, but the compile
failed on one or more architectures:
aarch64: FAILED (see build-aarch64.log.xz attachment)
ppc64le: FAILED (see build-ppc64le.log.xz attachment)
s390x: FAILED (see build-s390x.log.xz attachment)
x86_64: FAILED (see build-x86_64.log.xz attachment)
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 4 architectures:
aarch64:
rpmbuild arguments: rpmbuild --target aarch64 --with=cross --with=kabidw_base --without=bpftool --without=selftests --without=debug --without=ipaclones --without=perf --without=tools
ppc64le:
rpmbuild arguments: rpmbuild --target ppc64le --with=cross --with=kabidw_base --without=bpftool --without=selftests --without=debug --without=ipaclones --without=perf --without=tools
s390x:
rpmbuild arguments: rpmbuild --target s390x --with=cross --with=kabidw_base --without=bpftool --without=selftests --without=debug --without=ipaclones --without=perf --without=tools
x86_64:
rpmbuild arguments: rpmbuild --target x86_64 --with=kabidw_base --without=debug
3 years, 7 months
❌ FAIL: Test report for kernel 5.9.0-0.rc6.18.cki.fc33 (ark)
by CKI Project
Hello,
We ran automated tests on a recent commit from this kernel tree:
Kernel repo: https://gitlab.com/cki-project/kernel-ark.git
Commit: 30a9751b451e - [redhat] kernel-5.9.0-0.rc6.20200926git7c7ec3226f5f.17
The results of these automated tests are provided below.
Overall result: FAILED (see details below)
Merge: OK
Compile: FAILED
All kernel binaries, config files, and logs are available for download here:
https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/index.html?pre...
We attempted to compile the kernel for multiple architectures, but the compile
failed on one or more architectures:
aarch64: FAILED (see build-aarch64.log.xz attachment)
ppc64le: FAILED (see build-ppc64le.log.xz attachment)
s390x: FAILED (see build-s390x.log.xz attachment)
x86_64: FAILED (see build-x86_64.log.xz attachment)
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 4 architectures:
aarch64:
rpmbuild arguments: rpmbuild --target aarch64 --with=cross --with=kabidw_base --without=bpftool --without=selftests --without=debug --without=ipaclones --without=perf --without=tools
ppc64le:
rpmbuild arguments: rpmbuild --target ppc64le --with=cross --with=kabidw_base --without=bpftool --without=selftests --without=debug --without=ipaclones --without=perf --without=tools
s390x:
rpmbuild arguments: rpmbuild --target s390x --with=cross --with=kabidw_base --without=bpftool --without=selftests --without=debug --without=ipaclones --without=perf --without=tools
x86_64:
rpmbuild arguments: rpmbuild --target x86_64 --with=kabidw_base --without=debug
3 years, 7 months
[OS-BUILD PATCH] Create Patchlist.changelog file
by GitLab Bridge on behalf of dzickusrh
From: Don Zickus <dzickus(a)redhat.com>
A source git tree's workflow and Fedora's separation of upstream and distro
contributions don't overlap well.
A source git tree is always merging upstream content and downstream content
while avoiding a rebase. By separating the tarballs and patches out, this
effectively causes a rebase. This 'rebase' causes patches to not apply
correctly as git took care of it previously.
This patch creates a Patchlist.changelog file that lists all the SHAs that
are added to the upstream tree.
The goal is to create a useful file such that the source git tree can
create a single tarball and use the Patchlist.changelog file to adhere
to the spirit of the Fedora's separation rules.
No technical changes, just a new file added to the srpm.
Signed-off-by: Don Zickus <dzickus(a)redhat.com>
---
redhat/genspec.sh | 8 ++++++++
redhat/kernel.spec.template | 1 +
2 files changed, 9 insertions(+)
diff --git a/redhat/genspec.sh b/redhat/genspec.sh
index fbe275f6f4e7..308db0182954 100755
--- a/redhat/genspec.sh
+++ b/redhat/genspec.sh
@@ -273,6 +273,14 @@ if [ "$SINGLE_TARBALL" = 0 ]; then
done
fi
+# generate Patchlist.changelog file that holds the shas and commits not
+# included upstream.
+git log --no-merges --pretty=oneline --no-decorate master.. \
+ ":(exclude,top).gitlab-ci.yml" \
+ ":(exclude,top)makefile" \
+ ":(exclude,top)Makefile.rhelver" \
+ ":(exclude,top)redhat" > $plistf.changelog
+
sed -i "s/%%PATCHLIST%%//" $SPECFILE
sed -i "s/%%APPLYPATCH%%//" $SPECFILE
diff --git a/redhat/kernel.spec.template b/redhat/kernel.spec.template
index 6f591e11bd71..bc12211a7d6b 100644
--- a/redhat/kernel.spec.template
+++ b/redhat/kernel.spec.template
@@ -708,6 +708,7 @@ Source2001: cpupower.config
Source3000: merge.pl
Source3001: kernel-local
Source3002: Patchlist
+Source3003: Patchlist.changelog
Source4000: README.rst
--
GitLab
3 years, 7 months
[OS-BUILD PATCH] Merge Upstream script fixes
by GitLab Bridge on behalf of dzickusrh
From: Don Zickus <dzickus(a)redhat.com>
As part of splitting the merge-upstream and release stages apart,
the merge upstream wasn't working quite right. These are cleanup
fixes to fix that.
The main change is to drop the ark rebase patches script. Running
that through a Makefile through gitlab CI creates a funky environment
where the next script (update-configs.sh) no longer exists because
of the git checkout changes. Keep rebase-patches in the gitlab-ci
script for now.
That will be removed soon enough. No effect on normal workflow.
The other fixes are self-explanatory.
Signed-off-by: Don Zickus <dzickus(a)redhat.com>
---
redhat/Makefile | 5 ++---
redhat/scripts/ci/ark-rebase-patches.sh | 4 ++--
redhat/scripts/ci/ark-update-configs.sh | 2 +-
3 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/redhat/Makefile b/redhat/Makefile
index bfc9cd63df60..27d2cd94e78f 100644
--- a/redhat/Makefile
+++ b/redhat/Makefile
@@ -327,11 +327,10 @@ dist-merge-upstream: git-tree-check
fi;
@# If TAG is empty, script defaults to master:HEAD
- @$(REDHAT)/scripts/ci/ark-rebase-patches.sh $(TAG) || exit 1
git checkout $(DIST_BRANCH)
@$(REDHAT)/scripts/ci/ark-update-configs.sh $(TAG)
-dist-merge-upstream-push: DIST_PUSH="1"
+dist-merge-upstream-push: export DIST_PUSH="1"
dist-merge-upstream-push: dist-merge-upstream
dist-fedora-release: git-tree-check
@@ -340,7 +339,7 @@ dist-fedora-release: git-tree-check
@cd ..; $(REDHAT)/scripts/ci/ark-create-release.sh $(TAG) || \
(echo "Unable to create release tag"; exit 1)
-dist-fedora-release-push: DIST_PUSH="1"
+dist-fedora-release-push: export DIST_PUSH="1"
dist-fedora-release-push: dist-fedora-release
.PHONY: dist-brew dist-koji
diff --git a/redhat/scripts/ci/ark-rebase-patches.sh b/redhat/scripts/ci/ark-rebase-patches.sh
index ef2183ecc799..2e64b90ac277 100755
--- a/redhat/scripts/ci/ark-rebase-patches.sh
+++ b/redhat/scripts/ci/ark-rebase-patches.sh
@@ -99,7 +99,7 @@ fi
if $CLEAN_REBASE; then
if test -n "$DIST_PUSH"; then
- echo "Pushing branch ark-patches to $(get remote get-url gitlab)"
+ echo "Pushing branch ark-patches to $(git remote get-url gitlab)"
git push -f gitlab ark-patches
else
printf "You can safely update ark-patches with 'git push -f <remote> ark-patches'\n"
@@ -114,7 +114,7 @@ if git tag -v "$UPSTREAM_REF" > /dev/null 2>&1; then
printf "Creating branch \"ark/patches/%s\"\n" "$UPSTREAM_REF"
git branch ark/patches/"$UPSTREAM_REF"
if test -n "$DIST_PUSH"; then
- echo "Pushing branch ark/patches to $(get remote get-url gitlab)"
+ echo "Pushing branch ark/patches to $(git remote get-url gitlab)"
git push gitlab ark/patches/"$UPSTREAM_REF"
else
printf "Don't forget to run 'git push <remote> ark/patches/%s'\n" "$UPSTREAM_REF"
diff --git a/redhat/scripts/ci/ark-update-configs.sh b/redhat/scripts/ci/ark-update-configs.sh
index 22dcead23f88..e8baacdb929e 100755
--- a/redhat/scripts/ci/ark-update-configs.sh
+++ b/redhat/scripts/ci/ark-update-configs.sh
@@ -67,7 +67,7 @@ else
fi
if test -n "$DIST_PUSH"; then
- echo "Pushing branch $(git branch --show-current) to $(get remote get-url gitlab)"
+ echo "Pushing branch $(git branch --show-current) to $(git remote get-url gitlab)"
git push gitlab HEAD
echo "Pushing config update branches"
--
GitLab
3 years, 7 months
Re: System no longer distributes load to multiple cores for long
running task
by stan
On Wed, 23 Sep 2020 12:08:22 +0000
"Gregorio ." <devim(a)outlook.it> wrote:
> You can manually set the CPU affinity (see taskset utility) to decide
> the core(s) where to run your process, even if it is already running.
I can see how that would work as a manual intervention. But this used
to happen automatically as the default for the system. I've been
trying to research this but most of the web articles available are
about sharing a single core, and ensuring a fair allocation of that
core's resources to several tasks. This kind of task migration to
random cores while the task is running when there isn't resource
contention does not seem to get much mention.
The kernel documentation has the same bias. My plan right now is to
compile an older kernel, say 5.5 or 5.6 where this was working by
default, and see if it is still working. If it is, then it is a kernel
change. If it isn't, then something changed in the Fedora
configuration. That will narrow down where I have to look.
I'm probably not searching correctly because I have only a vague
understanding of the terminology used for scheduling tasks. And the
interaction of the scheduler and NUMA. When I search the kernel
mailing list, the problem isn't a lack of matches, but an overwhelming
number of matches. This seems to be a very active area of development.
In the end, I might just have to live with it, and use your suggestion
to manually shift the task when I am present and think about it. Maybe
it isn't really an issue, but it seems to me that for the CPU core in
question, it is a lot like over-clocking it.
Thanks for your reply. It gave me another thread to pull.
3 years, 7 months