Page 1 of 3
Kernel 5.9
Posted: Tue Aug 04, 2020 1:16 pm
by xeno74
Hi All,
The Linux
5.9 merge window is open now so I released the
first alpha today.
New:
Download:
linux-image-5.9-alpha1-X1000_X5000.tar.gz
Please test the kernels.
Thanks,
Christian
Re: Kernel 5.9
Posted: Wed Aug 05, 2020 1:06 pm
by xeno74
Hi All,
I compiled the
alpha2 (latest Git kernel) today.
New:
Unfortunately, Xorg doesn't start on some Linux distributions anymore. For example on Fienix (Debian Sid PowerPC 32-bit) and on ubuntu MATE 16.04.6 (PowerPC 32-bit). I tested these distributions on the X1000, X5000, and in a virtual e5500 QEMU machine with a virtio_gpu.
Error messages:
Code: Select all
systemd-journald[2238]: Failed to send WATCHDOG-1 notification message: Connection refused
systemd-journald[2238]: Failed to send WATCHDOG-1 notification message: Transport endpoint is not connected
systemd-journald[2238]: Failed to send WATCHDOG-1 notification message: Transport endpoint is not connected
systemd-journald[2238]: Failed to send WATCHDOG-1 notification message: Transport endpoint is not connected
systemd-journald[2238]: Failed to send WATCHDOG-1 notification message: Transport endpoint is not connected
systemd-journald[2238]: Failed to send WATCHDOG-1 notification message: Transport endpoint is not connected
But Xorg works on Ubuntu 10.04.4 (PowerPC 32-bit), openSUSE Tumbleweed 20190722 PPC64 and on Fedora 27 PPC64 with the
alpha2 (latest Git kernel).
I was able to revert the
dma-mapping updates with the following command:
Code: Select all
git revert 2ed90dbbf7be3b7cd2790fc6fa946c478ab496b8 -m 1
Code: Select all
[master 1196b8b16801] Revert "Merge tag 'dma-mapping-5.9' of git://git.infradead.org/users/hch/dma-mapping"
26 files changed, 416 insertions(+), 415 deletions(-)
But the reverting of the dma-mapping updates doesn't solve the issue.
Cheers,
Christian
Re: Kernel 5.9
Posted: Fri Aug 07, 2020 9:10 am
by xeno74
Hi All,
I compiled the latest Git kernel today. Unfortunately the issue with Xorg still exists.
I bisected today.
-
-
Code: Select all
git bisect good bcf876870b95592b52519ed4aafcf9d95999bc9c
(Good: Linux 5.8)
-
Code: Select all
git bisect bad 7b4ea9456dd3f73238408126ab00f1d906963d81
(Bad: Revert "x86/mm/64: Do not sync vmalloc/ioremap mappings" -- 2020-08-06 12:02:58 -0700)
- git bisect bad
- git bisect good
- git bisect bad
- git bisect bad
- git bisect good
- git bisect good
- git bisect bad
- git bisect bad
- git bisect good
- git bisect good
- git bisect bad
- git bisect bad
- git bisect good
Result:
net/scm: Regularize compat handling of scm_detach_fds() (c0029de50982c1fb215330a5f9d433cec0cfd8cc) is the first bad commit.
Code: Select all
c0029de50982c1fb215330a5f9d433cec0cfd8cc is the first bad commit
commit c0029de50982c1fb215330a5f9d433cec0cfd8cc
Author: Kees Cook <[email protected]>
Date: Tue Jun 9 16:11:29 2020 -0700
net/scm: Regularize compat handling of scm_detach_fds()
Duplicate the cleanups from commit 2618d530dd8b ("net/scm: cleanup
scm_detach_fds") into the compat code.
Replace open-coded __receive_sock() with a call to the helper.
Move the check added in commit 1f466e1f15cf ("net: cleanly handle kernel
vs user buffers for ->msg_control") to before the compat call, even
though it should be impossible for an in-kernel call to also be compat.
Correct the int "flags" argument to unsigned int to match fd_install()
and similar APIs.
Regularize any remaining differences, including a whitespace issue,
a checkpatch warning, and add the check from commit 6900317f5eff ("net,
scm: fix PaX detected msg_controllen overflow in scm_detach_fds") which
fixed an overflow unique to 64-bit. To avoid confusion when comparing
the compat handler to the native handler, just include the same check
in the compat handler.
Cc: Christoph Hellwig <[email protected]>
Cc: Sargun Dhillon <[email protected]>
Cc: Jakub Kicinski <[email protected]>
Cc: [email protected]
Cc: [email protected]
Acked-by: Christian Brauner <[email protected]>
Signed-off-by: Kees Cook <[email protected]>
:040000 040000 b309c4be7d13b31a56f770d2eb6c76fe66b7eb19 70f6594345d1cf1aae088f9b5da99fab56d63f52 M include
:040000 040000 8abcdca26e3d17c6dccc3fcfd445adc692e58965 eb8157a8cff232956d71ca37a115aa6ee73e51f0 M net
This commit has been merged with the
seccomp updates v5.9-rc1 on 2020-08-04 14:11:08 -0700. Since these updates, Xorg doesn't start anymore on some Linux distributions.
Unfortunately I wasn't able to revert the first bad commit.
The first bad commit depends on many other commits, which unfortunately I don't know. I tried to remove the modifications of the files from the first bad commit but without any success. There are just too many dependencies.
Christian
Re: Kernel 5.9
Posted: Fri Aug 07, 2020 4:13 pm
by xeno74
Hi All,
I compiled a linux-next kernel because of the issue with the latest Git kernel.
Sources:
Code: Select all
git clone git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next a
This kernel includes all available updates. Unfortunately this kernel doesn't boot. It can't initialize the graphics card.
I think we have to wait for some updates.
Cheers,
Christian
Re: Kernel 5.9
Posted: Fri Aug 07, 2020 5:01 pm
by xeno74
Re: Kernel 5.9
Posted: Fri Aug 07, 2020 9:19 pm
by xeno74
Hi All,
Kees has released a patch because of the Xorg issue. I think his patch works because I can patch the Git source code but the kernel doesn’t boot. In my point of view his modifications aren’t responsible for this second issue. The kernel can’t initialize the graphics card anymore. I think the latest DRM updates are responsible for the second issue. Because of this second issue I can’t test his patch.
Cheers,
Christian
Re: Kernel 5.9
Posted: Sat Aug 08, 2020 4:24 am
by xeno74
Kees’ patch is in the Git kernel now.
seccomp-v5.9-rc1-fix1
I tried to revert the DRM updates today but without any success because of dependencies so I can’t test Kees’ patch.
Re: Kernel 5.9
Posted: Sat Aug 08, 2020 5:59 am
by xeno74
Re: Kernel 5.9
Posted: Sun Aug 09, 2020 3:43 pm
by xeno74
Hi All,
I compiled the latest Git kernel today. The issue with Xorg is solved.

The X5000 boots and works with the latest Git kernel. Unfortunately the X1000 doesn't boot anymore. It can't initialize the graphics card anymore.
I bisected today.
-
-
Code: Select all
git bisect good bcf876870b95592b52519ed4aafcf9d95999bc9c
(Good: Linux 5.8)
-
Code: Select all
git bisect bad 7b9de97711225559af213dc52b6ea883ef1ea7a8
(Bad: powerpc/ptrace: Fix build error in pkey_get() -- 2020-08-07 18:27:26 -0700)
- git bisect good
- git bisect good
- git bisect good
- git bisect bad
- git bisect bad
- git bisect bad
- git bisect good
- git bisect bad
- git bisect good
- git bisect bad
- git bisect good
- git bisect good
- git bisect good
Result:
powerpc/book3s64/pkeys: Simplify pkey disable branch (a4678d4b477c3d2901f101986ca01406f3b7eaea) is the first bad commit.
Code: Select all
a4678d4b477c3d2901f101986ca01406f3b7eaea is the first bad commit
commit a4678d4b477c3d2901f101986ca01406f3b7eaea
Author: Aneesh Kumar K.V <[email protected]>
Date: Thu Jul 9 08:59:32 2020 +0530
powerpc/book3s64/pkeys: Simplify pkey disable branch
Make the default value FALSE (pkey enabled) and set to TRUE when we
find the total number of keys supported to be zero.
Signed-off-by: Aneesh Kumar K.V <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
:040000 040000 ba5ec72c45ced2ec3059d47db0ab493e63c3d07c 7d11c97b991b194aa834ef0ea0967c07710dbc06 M arch
Unfortunately I wasn't able to revert the first bad commit.
The first bad commit depends on many other commits, which unfortunately I don't know. I tried to remove the modifications of the files from the first bad commit but without any success. There are just too many dependencies.
I reverted the commit
selftests/powerpc: Fix pkey syscall redefinitions and compiled a new kernel but without any success.
Christian
Re: Kernel 5.9
Posted: Sun Aug 09, 2020 4:20 pm
by xeno74
I reported the X1000 boot issue to the kernel developers.
Link:
[PASEMI] Nemo board doesn't boot anymore after the commit "powerpc/book3s64/pkeys: Simplify pkey disable branch"
I will create a test kernel for the X5000 tomorrow because the kernel boots on the X5000.