Issues with the first PowerPC updates for the kernel 6.1
Christian Zigotzky
chzigotzky at xenosoft.de
Mon Oct 31 00:30:16 AEDT 2022
On 29 October 2022 at 01:44 pm, Christian Zigotzky wrote:
> On 17 October 2022 at 09:53 am, Christian Zigotzky wrote:
>>> On 17. Oct 2022, at 02:43, Michael Ellerman <mpe at ellerman.id.au> wrote:
>>> Previously BIG_ENDIAN && GENERIC_CPU would use -mcpu=power5, now it
>>> uses
>>> -mcpu=power4.
>> Maybe this is the issue. We will wait and not release the RC1 for
>> testing because it is a risk for our testers to test these new
>> kernels because of this issue.
>>
>>>
>>> cheers
>>>
>>>
> I compiled the RC2 of kernel 6.1 today.
>
> After the first boot of the RC2, the file system was immediately to
> 100% used. This is the same issue we have seen with the git kernel 3
> weeks ago.
>
> The Cyrus+ and Nemo boards are affected.
>
> I wrote 3 weeks ago:
>
> Hi All,
>
> I successfully compiled the latest git kernel with the first PowerPC
> updates yesterday.
>
> Unfortunately this kernel is really dangerous. Many things for example
> Network Manager and LightDM don't work anymore and produced several
> gigabyte of config files till the partition has been filled.
>
> I deleted some files like the resolv.conf that had a size over 200 GB!
>
> Unfortunately, MintPPC was still damaged. For example LightDM doesn't
> work anymore and the MATE desktop doesn't display any icons anymore
> because Caja wasn't able to reserve memory anymore.
>
> In this case, bisecting isn't an option and I have to wait some weeks.
> It is really difficult to find the issue if the userland will damaged
> again and again.
>
> Cheers,
> Christian
>
> ---
>
> Maybe there is an issue in my kernel configs. Could you please check
> the configs? Please find attached the configs. Could you please test
> the RC2 on your FSL and pasemi machines?
>
> Thanks,
> Christian
>
Hi All,
I bisected today because Void PPC is recovering after a reboot. Memory
space is released again. [1]
Result: c2e7a19827eec443a7cbe85e8d959052412d6dc3 (powerpc: Use generic
fallocate compatibility syscall) is the first bad commit. [2]
I was able to create a patch for reverting this bad commit. [3]
I compiled the kernel with this patch. After that the kernel works
without any problems.
Please check the first bad commit. [2]
Thanks,
Christian
[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=56099#p56099
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c2e7a19827eec443a7cbe85e8d959052412d6dc3
[3] syscall.patch:
diff -rupN a/arch/powerpc/include/asm/syscalls.h
b/arch/powerpc/include/asm/syscalls.h
--- a/arch/powerpc/include/asm/syscalls.h 2022-10-30
13:53:28.956001116 +0100
+++ b/arch/powerpc/include/asm/syscalls.h 2022-10-30
13:55:39.166300756 +0100
@@ -15,6 +15,7 @@
#include <asm/unistd.h>
#include <asm/ucontext.h>
+long compat_sys_fallocate(int fd, int mode, u32 offset1, u32 offset2,
u32 len1, u32 len2);
#ifndef CONFIG_ARCH_HAS_SYSCALL_WRAPPER
long sys_ni_syscall(void);
#else
diff -rupN a/arch/powerpc/include/asm/unistd.h
b/arch/powerpc/include/asm/unistd.h
--- a/arch/powerpc/include/asm/unistd.h 2022-10-30 13:53:28.957001103 +0100
+++ b/arch/powerpc/include/asm/unistd.h 2022-10-30 13:56:44.851441888 +0100
@@ -45,7 +45,6 @@
#define __ARCH_WANT_SYS_UTIME
#define __ARCH_WANT_SYS_NEWFSTATAT
#define __ARCH_WANT_COMPAT_STAT
-#define __ARCH_WANT_COMPAT_FALLOCATE
#define __ARCH_WANT_COMPAT_SYS_SENDFILE
#endif
#define __ARCH_WANT_SYS_FORK
diff -rupN a/arch/powerpc/kernel/sys_ppc32.c
b/arch/powerpc/kernel/sys_ppc32.c
--- a/arch/powerpc/kernel/sys_ppc32.c 2022-10-30 13:53:28.967000972 +0100
+++ b/arch/powerpc/kernel/sys_ppc32.c 2022-10-30 13:58:28.993078689 +0100
@@ -97,6 +97,13 @@ PPC32_SYSCALL_DEFINE4(ppc_truncate64,
return ksys_truncate(path, merge_64(len1, len2));
}
+long compat_sys_fallocate(int fd, int mode, u32 offset1, u32 offset2,
+ u32 len1, u32 len2)
+{
+ return ksys_fallocate(fd, mode, merge_64(offset1, offset2),
+ merge_64(len1, len2));
+}
+
PPC32_SYSCALL_DEFINE4(ppc_ftruncate64,
unsigned int, fd, u32, reg4,
unsigned long, len1, unsigned long, len2)
More information about the Linuxppc-dev
mailing list