Issues with the first PowerPC updates for the kernel 6.1

Christian Zigotzky chzigotzky at xenosoft.de
Wed Nov 2 03:46:30 AEDT 2022


On 30 October 2022 at 02:30 pm, Christian Zigotzky wrote:
> 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)

Hello,

I compiled the RC3 of kernel 6.1 today. Unfortunately the issue still 
exists. I still need the patch above for a working kernel.

Cheers,
Christian


More information about the Linuxppc-dev mailing list