Issues with the first PowerPC updates for the kernel 6.1

2022-11-01 Thread Christian Zigotzky

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  
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 
 #include 

+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


Re: Issues with the first PowerPC updates for the kernel 6.1

2022-10-30 Thread Christian Zigotzky

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  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 
 #include 

+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)


Re: Issues with the first PowerPC updates for the kernel 6.1

2022-10-30 Thread Christian Zigotzky

On 29 October 2022 at 5:33 pm, Segher Boessenkool wrote:

On Mon, Oct 17, 2022 at 09:53:04AM +0200, Christian Zigotzky wrote:

On 17. Oct 2022, at 02:43, Michael Ellerman  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.

It is really important do not to rewrite code, that is well worked before.
Bugfixing and adding some new features is ok but rewriting of good code is 
expensive and doesn’t make any sense.

It was just a bugfix, and a (partial) revert.

471d7ff8b51b says it removed ISA 2.00 support (original power4, "GP").
Support for ISA 2.01 was retained it says.  That is power4+, "GQ", but
also 970 (Apple G5).  That patch actually switched to ISA 2.02 though,
unintendedly, and code generated for ISA 2.02 will not run on systems
like 970, in principle.  It is just one uncommon instruction that is
problematical, namely popcntb, because the kernel does not use floating
point at all, so that is why we got away with it for so long (most code
that does use fp will fall flat on its face in no time).  It still is a
bug fix though!

PA6T is ISA 2.04, it's not clear how this (bugfix, and revert!) change
made code not run on PA6T anymore.  Smells a lot like something indirect
(or triply indirect), a separate bug, something that was introduced in
the last two years maybe, but I'll even bet it is something *exposed* in
that time, a bug that has been here for longer!


Segher

Unfortunately my FSL P5040 system is also affected.

-- Christian


Re: Issues with the first PowerPC updates for the kernel 6.1

2022-10-29 Thread Christian Zigotzky

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  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.0 today.

Typo: I mean the RC2 of kernel 6.1.


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





Re: Issues with the first PowerPC updates for the kernel 6.1

2022-10-17 Thread Christian Zigotzky


> On 17. Oct 2022, at 02:43, Michael Ellerman  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.

It is really important do not to rewrite code, that is well worked before.
Bugfixing and adding some new features is ok but rewriting of good code is 
expensive and doesn’t make any sense.

— Christian

> 
> 
> cheers
> 
>>>> On 16. Oct 2022, at 18:51, Segher Boessenkool  
>>>> wrote:
>>> 
>>> On Fri, Oct 14, 2022 at 06:11:21PM +0200, Christian Zigotzky wrote:
>>>> make oldconfig has asked because of the CPU family. I choosed GENERIC for 
>>>> my P.A. Semi PWRficient PA6T-1682M. Is this correct? Maybe this is the 
>>>> problem.
>>>> 
>>>> config GENERIC_CPU
>>>> -bool "Generic (POWER4 and above)"
>>>> +bool "Generic (POWER5 and PowerPC 970 and above)"
>>>>   depends on PPC_BOOK3S_64 && !CPU_LITTLE_ENDIAN
>>>>   select PPC_64S_HASH_MMU
>>>> 
>>>> There isn’t a POWER4 anymore and I used it via CONFIG_GENERIC_CPU=y before.
>>> 
>>> PA6T is ISA 2.04, just like POWER5+.  It should be fine.
>>> 
>>> 
>>> Segher



Re: Issues with the first PowerPC updates for the kernel 6.1

2022-10-16 Thread Christian Zigotzky
No, it’s not fine. We used the POWER4 CPU config before.

— Christian

> On 16. Oct 2022, at 18:51, Segher Boessenkool  
> wrote:
> 
> On Fri, Oct 14, 2022 at 06:11:21PM +0200, Christian Zigotzky wrote:
>> make oldconfig has asked because of the CPU family. I choosed GENERIC for my 
>> P.A. Semi PWRficient PA6T-1682M. Is this correct? Maybe this is the problem.
>> 
>> config GENERIC_CPU
>> -bool "Generic (POWER4 and above)"
>> +bool "Generic (POWER5 and PowerPC 970 and above)"
>>depends on PPC_BOOK3S_64 && !CPU_LITTLE_ENDIAN
>>select PPC_64S_HASH_MMU
>> 
>> There isn’t a POWER4 anymore and I used it via CONFIG_GENERIC_CPU=y before.
> 
> PA6T is ISA 2.04, just like POWER5+.  It should be fine.
> 
> 
> Segher



Re: Issues with the first PowerPC updates for the kernel 6.1

2022-10-15 Thread Christian Zigotzky
Hi All,

make oldconfig has asked because of the CPU family. I choosed GENERIC for my 
P.A. Semi PWRficient PA6T-1682M. Is this correct? Maybe this is the problem.

config GENERIC_CPU
-   bool "Generic (POWER4 and above)"
+   bool "Generic (POWER5 and PowerPC 970 and above)"
depends on PPC_BOOK3S_64 && !CPU_LITTLE_ENDIAN
select PPC_64S_HASH_MMU

There isn’t a POWER4 anymore and I used it via CONFIG_GENERIC_CPU=y before.

Before the first PowerPC updates:
CONFIG_GENERIC_CPU=y
# CONFIG_POWER5_CPU is not set

Link: 
https://github.com/torvalds/linux/blob/master/arch/powerpc/platforms/Kconfig.cputype

— Christian

> On 13. Oct 2022, at 11:42, Christian Zigotzky  wrote:
> 
> Hi Christophe,
> 
> Thanks a lot for your answer. OK, now, I know, that I don’t need to test it. 
> After the boot of the latest git kernel, my system was extremely damaged. 
> Some config files have a size of several gigabytes for example the 
> resolv.conf. I tried to repair this Debian system but without any success.
> I copied with dd and Netcat via network another rootfs from another computer 
> to the damaged partition.
> I don’t have the time to do it always again and again after a bad bisect 
> result.
> I will wait some weeks and try it again.
> 
> Cheers,
> Christian
> 
>> On 13. Oct 2022, at 09:28, Christophe Leroy  
>> wrote:
>> 
>> 
>> 
>>>> Le 13/10/2022 à 09:03, Christian Zigotzky a écrit :
>>> Hi Andrew,
>>> 
>>> Does this patch also affect 64-bit kernels?
>>> 
>>> We use often 32-bit userlands with 64-bit kernels.
>> 
>> As far as I understand, it was already correct for 32-bit userlands with 
>> 64 bit kernels, aka compat.
>> 
>> The patch applies the same approach for 32 bit kernels, as explained in 
>> the commit message : "Fix this by having 32-bit kernels share those 
>> syscall definitions with compat."
>> 
>> Christophe
>> 
>>> 
>>> Cheers,
>>> Christian
>>> 
>>>>> On 12. Oct 2022, at 09:56, Andrew Donnellan  wrote:
>>>> 
>>>> On Wed, 2022-10-12 at 08:51 +0200, Christian Zigotzky wrote:
>>>>> Hi All,
>>>>> 
>>>>> I use the Nemo board with a PASemi PA6T CPU and have some issues
>>>>> since the first PowerPC updates for the kernel 6.1.
>>>>> 
>>>>> I successfully compiled the git kernel with the first PowerPC updates
>>>>> two days ago.
>>>>> 
>>>>> 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.
>>>> 
>>>> Could you try with
>>>> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20221012035335.866440-1-npig...@gmail.com/
>>>> to see if your issues are related to that?
>>>> 
>>>> Andrew
>>>> 
>>>> -- 
>>>> Andrew DonnellanOzLabs, ADL Canberra
>>>> a...@linux.ibm.com   IBM Australia Limited
>>>> 
> 


Re: Issues with the first PowerPC updates for the kernel 6.1

2022-10-15 Thread Christian Zigotzky



> On 15. Oct 2022, at 11:51, Andrew Donnellan  wrote:
> 
> On Thu, 2022-10-13 at 11:42 +0200, Christian Zigotzky wrote:
>> Hi Christophe,
>> 
>> Thanks a lot for your answer. OK, now, I know, that I don’t need to
>> test it. After the boot of the latest git kernel, my system was
>> extremely damaged. Some config files has a size of several gigabytes
>> for example the resolv.conf. I tried to repair this Debian system but
>> without any success.
>> I copied with dd and Netcat via network another rootfs from another
>> computer to the damaged partition.
>> I don’t have the time to do it always again and again after a bad
>> bisect result.
>> I will wait some weeks and try it again.
> 
> You're right, I was in a rush, saw a processor that wasn't IBM and
> assumed it was 32-bit without thinking too much!
> 
> 
> Andrew

Hi Andrew,

Thanks for your answer. Is it possible to fix it?

Thanks,
Christian

> 
> 
>> 
>> Cheers,
>> Christian
>> 
>>> On 13. Oct 2022, at 09:28, Christophe Leroy <
>>> christophe.le...@csgroup.eu> wrote:
>>> 
>>> 
>>> 
>>>>> Le 13/10/2022 à 09:03, Christian Zigotzky a écrit :
>>>>> Hi Andrew,
>>>>> 
>>>>> Does this patch also affect 64-bit kernels?
>>>>> 
>>>>> We use often 32-bit userlands with 64-bit kernels.
>>> 
>>> As far as I understand, it was already correct for 32-bit userlands
>>> with 
>>> 64 bit kernels, aka compat.
>>> 
>>> The patch applies the same approach for 32 bit kernels, as
>>> explained in 
>>> the commit message : "Fix this by having 32-bit kernels share those
>>> syscall definitions with compat."
>>> 
>>> Christophe
>>> 
>>>> 
>>>> Cheers,
>>>> Christian
>>>> 
>>>>>> On 12. Oct 2022, at 09:56, Andrew Donnellan <
>>>>>> a...@linux.ibm.com> wrote:
>>>>> 
>>>>> On Wed, 2022-10-12 at 08:51 +0200, Christian Zigotzky wrote:
>>>>>> Hi All,
>>>>>> 
>>>>>> I use the Nemo board with a PASemi PA6T CPU and have some
>>>>>> issues
>>>>>> since the first PowerPC updates for the kernel 6.1.
>>>>>> 
>>>>>> I successfully compiled the git kernel with the first PowerPC
>>>>>> updates
>>>>>> two days ago.
>>>>>> 
>>>>>> 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.
>>>>> 
>>>>> Could you try with
>>>>> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20221012035335.866440-1-npig...@gmail.com/
>>>>> to see if your issues are related to that?
>>>>> 
>>>>> Andrew
>>>>> 
>>>>> -- 
>>>>> Andrew DonnellanOzLabs, ADL Canberra
>>>>> a...@linux.ibm.com   IBM Australia Limited
>>>>> 
>> 
> 
> -- 
> Andrew DonnellanOzLabs, ADL Canberra
> a...@linux.ibm.com   IBM Australia Limited
> 



Re: Issues with the first PowerPC updates for the kernel 6.1

2022-10-13 Thread Christian Zigotzky
Edit: fixed typos.

> On 13. Oct 2022, at 11:42, Christian Zigotzky  wrote:
> 
> Hi Christophe,
> 
> Thanks a lot for your answer. OK, now, I know, that I don’t need to test it. 
> After the boot of the latest git kernel, my system was extremely damaged. 
> Some config files have a size of several gigabytes for example the 
> resolv.conf. I tried to repair this Debian system but without any success.
> I copied with dd and Netcat via network another rootfs from another computer 
> to the damaged partition.
> I don’t have the time to do it always again and again after a bad bisect 
> result.
> I will wait some weeks and try it again.
> 
> Cheers,
> Christian
> 
>> On 13. Oct 2022, at 09:28, Christophe Leroy  
>> wrote:
>> 
>> 
>> 
>>>> Le 13/10/2022 à 09:03, Christian Zigotzky a écrit :
>>> Hi Andrew,
>>> 
>>> Does this patch also affect 64-bit kernels?
>>> 
>>> We use often 32-bit userlands with 64-bit kernels.
>> 
>> As far as I understand, it was already correct for 32-bit userlands with 
>> 64 bit kernels, aka compat.
>> 
>> The patch applies the same approach for 32 bit kernels, as explained in 
>> the commit message : "Fix this by having 32-bit kernels share those 
>> syscall definitions with compat."
>> 
>> Christophe
>> 
>>> 
>>> Cheers,
>>> Christian
>>> 
>>>>> On 12. Oct 2022, at 09:56, Andrew Donnellan  wrote:
>>>> 
>>>> On Wed, 2022-10-12 at 08:51 +0200, Christian Zigotzky wrote:
>>>>> Hi All,
>>>>> 
>>>>> I use the Nemo board with a PASemi PA6T CPU and have some issues
>>>>> since the first PowerPC updates for the kernel 6.1.
>>>>> 
>>>>> I successfully compiled the git kernel with the first PowerPC updates
>>>>> two days ago.
>>>>> 
>>>>> 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.
>>>> 
>>>> Could you try with
>>>> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20221012035335.866440-1-npig...@gmail.com/
>>>> to see if your issues are related to that?
>>>> 
>>>> Andrew
>>>> 
>>>> -- 
>>>> Andrew DonnellanOzLabs, ADL Canberra
>>>> a...@linux.ibm.com   IBM Australia Limited
>>>> 
> 



Re: Issues with the first PowerPC updates for the kernel 6.1

2022-10-13 Thread Christian Zigotzky
Hi Christophe,

Thanks a lot for your answer. OK, now, I know, that I don’t need to test it. 
After the boot of the latest git kernel, my system was extremely damaged. Some 
config files has a size of several gigabytes for example the resolv.conf. I 
tried to repair this Debian system but without any success.
I copied with dd and Netcat via network another rootfs from another computer to 
the damaged partition.
I don’t have the time to do it always again and again after a bad bisect result.
I will wait some weeks and try it again.

Cheers,
Christian

> On 13. Oct 2022, at 09:28, Christophe Leroy  
> wrote:
> 
> 
> 
>> Le 13/10/2022 à 09:03, Christian Zigotzky a écrit :
>> Hi Andrew,
>> 
>> Does this patch also affect 64-bit kernels?
>> 
>> We use often 32-bit userlands with 64-bit kernels.
> 
> As far as I understand, it was already correct for 32-bit userlands with 
> 64 bit kernels, aka compat.
> 
> The patch applies the same approach for 32 bit kernels, as explained in 
> the commit message : "Fix this by having 32-bit kernels share those 
> syscall definitions with compat."
> 
> Christophe
> 
>> 
>> Cheers,
>> Christian
>> 
>>>> On 12. Oct 2022, at 09:56, Andrew Donnellan  wrote:
>>> 
>>> On Wed, 2022-10-12 at 08:51 +0200, Christian Zigotzky wrote:
>>>> Hi All,
>>>> 
>>>> I use the Nemo board with a PASemi PA6T CPU and have some issues
>>>> since the first PowerPC updates for the kernel 6.1.
>>>> 
>>>> I successfully compiled the git kernel with the first PowerPC updates
>>>> two days ago.
>>>> 
>>>> 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.
>>> 
>>> Could you try with
>>> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20221012035335.866440-1-npig...@gmail.com/
>>> to see if your issues are related to that?
>>> 
>>> Andrew
>>> 
>>> -- 
>>> Andrew DonnellanOzLabs, ADL Canberra
>>> a...@linux.ibm.com   IBM Australia Limited
>>> 



Re: Issues with the first PowerPC updates for the kernel 6.1

2022-10-13 Thread Christian Zigotzky
Hi Andrew,

Does this patch also affect 64-bit kernels?

We use often 32-bit userlands with 64-bit kernels.

Cheers,
Christian

> On 12. Oct 2022, at 09:56, Andrew Donnellan  wrote:
> 
> On Wed, 2022-10-12 at 08:51 +0200, Christian Zigotzky wrote:
>> Hi All,
>> 
>> I use the Nemo board with a PASemi PA6T CPU and have some issues
>> since the first PowerPC updates for the kernel 6.1.
>> 
>> I successfully compiled the git kernel with the first PowerPC updates
>> two days ago.
>> 
>> 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.
> 
> Could you try with
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20221012035335.866440-1-npig...@gmail.com/
> to see if your issues are related to that?
> 
> Andrew
> 
> -- 
> Andrew DonnellanOzLabs, ADL Canberra
> a...@linux.ibm.com   IBM Australia Limited
> 



Issues with the first PowerPC updates for the kernel 6.1

2022-10-12 Thread Christian Zigotzky
Hi All,

I use the Nemo board with a PASemi PA6T CPU and have some issues since the 
first PowerPC updates for the kernel 6.1.

I successfully compiled the git kernel with the first PowerPC updates two days 
ago.

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


Re: [PATCH v2] i2c/pasemi: PASemi I2C controller IRQ enablement

2022-10-02 Thread Christian Zigotzky
 dev_id;
+
+   complete(>irq_completion);
+   return IRQ_HANDLED;
+}
diff --git a/drivers/i2c/busses/i2c-pasemi-core.h 
b/drivers/i2c/busses/i2c-pasemi-core.h
index 4655124a37f3..ba6d6ccf9cdc 100644
--- a/drivers/i2c/busses/i2c-pasemi-core.h
+++ b/drivers/i2c/busses/i2c-pasemi-core.h
@@ -7,6 +7,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #define PASEMI_HW_REV_PCI -1
  
@@ -15,7 +16,11 @@ struct pasemi_smbus {

struct i2c_adapter   adapter;
void __iomem*ioaddr;
unsigned int clk_div;
-   int  hw_rev;
+   int  hw_rev;
+   int  use_irq;
+   struct completionirq_completion;
  };
  
  int pasemi_i2c_common_probe(struct pasemi_smbus *smbus);

+
+irqreturn_t pasemi_irq_handler(int irq, void *dev_id);
diff --git a/drivers/i2c/busses/i2c-pasemi-platform.c 
b/drivers/i2c/busses/i2c-pasemi-platform.c
index 88a54aaf7e3c..e35945a91dbe 100644
--- a/drivers/i2c/busses/i2c-pasemi-platform.c
+++ b/drivers/i2c/busses/i2c-pasemi-platform.c
@@ -49,6 +49,7 @@ static int pasemi_platform_i2c_probe(struct platform_device 
*pdev)
struct pasemi_smbus *smbus;
u32 frequency;
int error;
+   int irq_num;
  
  	data = devm_kzalloc(dev, sizeof(struct pasemi_platform_i2c_data),

GFP_KERNEL);
@@ -82,6 +83,11 @@ static int pasemi_platform_i2c_probe(struct platform_device 
*pdev)
if (error)
goto out_clk_disable;
  
+	irq_num = platform_get_irq(pdev, 0);

+   error = devm_request_irq(smbus->dev, irq_num, pasemi_irq_handler, 0, 
"pasemi_apple_i2c", (void *)smbus);
+
+   if (!error)
+   smbus->use_irq = 1;
    platform_set_drvdata(pdev, data);
  
  	return 0;


Tested-by: Christian Zigotzky 

on an A-EON AmigaOne X1000 with a PASemi PWRficient PA6T-1682 processor.




Bug in the VirtIO GPU driver since the RC7 of kernel 6.0

2022-09-28 Thread Christian Zigotzky
Hi All,

I have found the issue. I cross compiled this kernel with GCC 11.2.0 on Ubuntu 
22.04.1.

I cross compiled the same kernel with GCC 9.4.0 again. This time on Ubuntu 
20.04.5.

KVM with the VirtIO GPU works with the GCC 9.4.0 compiled kernel.

— Christian

I wrote:

Hello,

Xorg doesn't start anymore in a virtual e5500 QEMU KVM HV machine with 
the VirtIO GPU [1] since the RC7 of kernel 6.0. [2]

Please find attached the kernel config.

Thanks,
Christian

[1] qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage-6.0 
-drive format=raw,file=void-live-powerpc-20220129.img,index=0,if=virtio 
-netdev user,id=mynet0 -device virtio-net,netdev=mynet0 -append "rw 
root=/dev/vda2" -device virtio-gpu -device virtio-mouse-pci -device 
virtio-keyboard-pci -device pci-ohci,id=newusb -audiodev 
id=sndbe,driver=pa,server=/run/user/1000/pulse/native -device 
usb-audio,bus=newusb.0 -enable-kvm -smp 4 -fsdev 
local,security_model=passthrough,id=fsdev0,path=/home/amigaone/Music 
-device virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=hostshare

[2] Error messages in a virtual Void PPC machine:
[drm] pci: virtio-gpu-pci detected at :00:02.0
[drm] features: -virgl +edid -resource_blob -host_visible
[drm] features: -context_init
[drm] number of scanouts: 1
[drm] number of cap sets: 0
[drm] Initialized virtio_gpu 0.1.0 0 for virtio1 on minor 0
BUG: Kernel NULL pointer dereference on read at 0x
Faulting instruction address: 0xc00c9934
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=4K SMP NR_CPUS=4 QEMU e500
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc7_A-EON_X5000 #1
NIP:  c00c9934 LR: c00c9f58 CTR: 
REGS: c208ab20 TRAP: 0300   Not tainted (6.0.0-rc7_A-EON_X5000)
MSR:  90029002   CR: 84008242  XER: 
DEAR:  ESR:  IRQMASK: 0
GPR00: c06f0060 c208adc0 c1ac3500 c25f0010
GPR04:    c19908b0
GPR08: 0105   0180
GPR12: 24008242 c0003fff9500 c0001384 
GPR16:    
GPR20:   c169021f c208b088
GPR24:  c2336800  
GPR28: c2a48000 c2336800  c25f0010
NIP [c00c9934] .dma_map_direct+0x8/0x10
LR [c00c9f58] .dma_max_mapping_size+0x24/0x78
Call Trace:
[c208adc0] [c208ae80] 0xc208ae80 (unreliable)
[c208ae40] [c06f0060] .drm_prime_pages_to_sg+0xa0/0xb8
[c208aed0] [c070f96c] .drm_gem_shmem_get_sg_table+0x28/0x3c
[c208af40] [c0808c8c] .virtio_gpu_object_create+0x134/0x3a8
[c208b010] [c0804c34] 
.virtio_gpu_mode_dumb_create+0xe4/0x15c
[c208b110] [c06ff7f4] .drm_mode_create_dumb+0xcc/0xec
[c208b180] [c0707748] 
.drm_client_framebuffer_create+0x98/0x1f0
[c208b260] [c071fb6c] 
.drm_fb_helper_generic_probe+0x78/0x1a0
[c208b320] [c071ef08] 
.__drm_fb_helper_initial_config_and_unlock+0x428/0x54c
[c208b410] [c071f9dc] .drm_fbdev_client_hotplug+0xec/0x128
[c208b4a0] [c071fdec] .drm_fbdev_generic_setup+0x158/0x198
[c208b530] [c0803dc4] .virtio_gpu_probe+0x1ac/0x1e0
[c208b5f0] [c069e11c] .virtio_dev_probe+0x2d0/0x3d4
[c208b690] [c0815f34] .really_probe+0x1a0/0x344
[c208b720] [c08161c8] .__driver_probe_device+0xf0/0x100
[c208b7b0] [c081620c] .driver_probe_device+0x34/0xac
[c208b840] [c0816774] .__driver_attach+0x124/0x134
[c208b8d0] [c0813974] .bus_for_each_dev+0x8c/0xd0
[c208b980] [c08154a4] .driver_attach+0x24/0x38
[c208b9f0] [c0814dd4] .bus_add_driver+0xd8/0x210
[c208baa0] [c0816fd4] .driver_register+0xe0/0x134
[c208bb20] [c069d8a8] .register_virtio_driver+0x40/0x54
hrtimer: interrupt took 4631040 ns
[c208bb90] [c195] .virtio_gpu_driver_init+0x18/0x2c
[c208bc00] [c0001044] .do_one_initcall+0x7c/0x1c0
[c208bce0] [c1925710] .kernel_init_freeable+0x23c/0x240
[c208bd90] [c00013ac] .kernel_init+0x28/0x14c
[c208be10] [c5a0] .ret_from_kernel_thread+0x58/0x60
Instruction dump:
3921 7c23f840 38210080 7d20485e 792307e0 48d551d8 7c9f2378 4bdc
792307e0 4e800020 e92301f8 7c852378  4b7c 7c0802a6 28060003
---[ end trace  ]---

Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
Rebooting in 180 seconds..


Re: PASEMI: Wrong lscpu info since the RC1 of kernel 6.0

2022-09-28 Thread Christian Zigotzky


Just for info:

The values have been fine again since the RC7 of kernel 6.0.

— Christian

> On 7. Sep 2022, at 06:25, Christian Zigotzky  wrote:
> 
> Hi All,
> 
> I use the Nemo board with a PASemi PA6T CPU and some values of lscpu are 
> wrong since the RC1 of kernel 6.0.
> 
> ┌──(mintppc㉿mintppc)-[~]
> └─$ lscpu
> Architecture:ppc64
> CPU op-mode(s):  32-bit, 64-bit
> Byte Order:  Big Endian
> CPU(s):  2
> On-line CPU(s) list: 0,1
> Thread(s) per core:  2
> Core(s) per socket:  1
> Socket(s):   1
> Model:   1.2 (pvr 0090 0102)
> Model name:  PA6T, altivec supported
> L1d cache:   64 KiB
> L1i cache:   64 KiB
> Vulnerability Itlb multihit: Not affected
> Vulnerability L1tf:  Vulnerable
> Vulnerability Mds:   Not affected
> Vulnerability Meltdown:  Vulnerable
> Vulnerability Mmio stale data:   Not affected
> Vulnerability Retbleed:  Not affected
> Vulnerability Spec store bypass: Vulnerable
> Vulnerability Spectre v1:Mitigation; __user pointer sanitization
> Vulnerability Spectre v2:Vulnerable
> Vulnerability Srbds: Not affected
> Vulnerability Tsx async abort:   Not affected
> 
> —-
> 
> One core with 2 threads is wrong. Two cores are correct. Each core has one 
> thread.
> 
> Have you modified the detection of the CPU?
> 
> Thanks,
> Christian



PASEMI: Wrong lscpu info since the RC1 of kernel 6.0

2022-09-06 Thread Christian Zigotzky
Hi All,

I use the Nemo board with a PASemi PA6T CPU and some values of lscpu are wrong 
since the RC1 of kernel 6.0.

┌──(mintppc㉿mintppc)-[~]
└─$ lscpu
Architecture:ppc64
CPU op-mode(s):  32-bit, 64-bit
Byte Order:  Big Endian
CPU(s):  2
On-line CPU(s) list: 0,1
Thread(s) per core:  2
Core(s) per socket:  1
Socket(s):   1
Model:   1.2 (pvr 0090 0102)
Model name:  PA6T, altivec supported
L1d cache:   64 KiB
L1i cache:   64 KiB
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf:  Vulnerable
Vulnerability Mds:   Not affected
Vulnerability Meltdown:  Vulnerable
Vulnerability Mmio stale data:   Not affected
Vulnerability Retbleed:  Not affected
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1:Mitigation; __user pointer sanitization
Vulnerability Spectre v2:Vulnerable
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort:   Not affected

—-

One core with 2 threads is wrong. Two cores are correct. Each core has one 
thread.

Have you modified the detection of the CPU?

Thanks,
Christian


Re: [PATCH] i2c: pasemi: Add IRQ support for Apple Silicon

2022-08-25 Thread Christian Zigotzky

On 23 August 2022 at 03:50 am, Michael Ellerman wrote:

Arminder Singh  writes:

This is the first time I'm interacting with the Linux mailing lists, so
please don't eviscerate me *too much* if I get the formatting wrong.
Of course I'm always willing to take criticism and improve my formatting
in the future.

This patch adds support for IRQs to the PASemi I2C controller driver.
This will allow for faster performing I2C transactions on Apple Silicon
hardware, as previously, the driver was forced to poll the SMSTA register
for a set amount of time.

With this patchset the driver on Apple silicon hardware will instead wait
for an interrupt which will signal the completion of the I2C transaction.
The timeout value for this completion will be the same as the current
amount of time the I2C driver polls for.

This will result in some performance improvement since the driver will be
waiting for less time than it does right now on Apple Silicon hardware.

The patch right now will only enable IRQs for Apple Silicon I2C chips,
and only if it's able to successfully request the IRQ from the kernel.

=== Testing ===

This patch has been tested on both the mainline Linux kernel tree and
the Asahi branch (https://github.com/AsahiLinux/linux.git) on both an
M1 and M2 MacBook Air, and it compiles successfully as both a module and
built-in to the kernel itself. The patch in both trees successfully boots
to userspace without any hitch.

I do not have PASemi hardware on hand unfortunately, so I'm unable to test
the impact of this patch on old PASemi hardware. This is also why I've
elected to do the IRQ request and enablement on the Apple platform driver
and not in the common file, as I'm not sure if PASemi hardware supports
IRQs.

I've added Darren and Christian to Cc, they have helped with PASemi
development and testing in the past, and may be able to help test this
series on PASemi hardware.

cheers


Tested-by: Christian Zigotzky 

on an A-EON AmigaOne X1000 with a PASemi PWRficient PA6T-1682 processor.


Re: [PATCH 2/2] kvm: rename KVM_MAX_VCPU_ID to, KVM_MAX_VCPU_IDS

2022-07-05 Thread Christian Zigotzky

On 14 September 2021 at 05:59 pm, Christian Zigotzky wrote:

Hello Juergen,
Hello All,

Since the RC1 of kernel 5.13, -smp 2 and -smp 4 don't work with a 
virtual e5500 QEMU KVM-HV machine anymore. [1]
I see in the serial console, that the uImage doesn't load. I use the 
following QEMU command for booting:


qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 1024 -kernel 
uImage -drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio 
-netdev user,id=mynet0 -device virtio-net,netdev=mynet0 -append "rw 
root=/dev/vda" -device virtio-vga -device virtio-mouse-pci -device 
virtio-keyboard-pci -device pci-ohci,id=newusb -device 
usb-audio,bus=newusb.0 -smp 4


The kernels boot without KVM-HV.

Summary for KVM-HV:

-smp 1 -> works
-smp 2 -> doesn't work
-smp 3 -> works
-smp 4 -> doesn't work

I used -smp 4 before the RC1 of kernel 5.13 because my FSL P5040 BookE 
machine [2] has 4 cores.


Does this patch solve this issue? [3]

Thanks,
Christian

[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-May/229103.html
[2] http://wiki.amiga.org/index.php?title=X5000
[3] 
https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-September/234152.html

Hello,

Since the RC5 of kernel 5.19, -smp 2 and -smp 4 work again. I don't know 
which patch has solved the issue.


Cheers,
Christian



Re: [PATCH v3] drivers/usb/host/ehci-fsl: Fix interrupt setup in host mode.

2022-07-05 Thread Christian Zigotzky

On 02 July 2022 at 11:03 pm, Darren Stevens wrote:

In patch a1a2b7125e10 (Drop static setup of IRQ resource from DT
core) we stopped platform_get_resource() from returning the IRQ, as all
drivers were supposed to have switched to platform_get_irq()
Unfortunately the Freescale EHCI driver in host mode got missed. Fix
it.

Fixes: a1a2b7125e10 (Drop static setup of IRQ resource from DT core)
Reported-by: Christian Zigotzky 
Suggested-by: Rob Herring 
Signed-off-by: Darren Stevens 
---
  v3 - Corrected resource allocation in fsl-mph-dr-of.c

  v2 - Fixed coding style, removed a couple of unneeded initializations,
   cc'd Layerscape maintainers.

Tested on AmigaOne X5000/20 and X5000/40 Contains code by Rob Herring
(in fsl-mph-dr-of.c)

diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 385be30..896c0d1 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -76,14 +76,9 @@ static int fsl_ehci_drv_probe(struct platform_device *pdev)
return -ENODEV;
}
  
-	res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);

-   if (!res) {
-   dev_err(>dev,
-   "Found HC with no IRQ. Check %s setup!\n",
-   dev_name(>dev));
-   return -ENODEV;
-   }
-   irq = res->start;
+   irq = platform_get_irq(pdev, 0);
+   if (irq < 0)
+   return irq;
  
  	hcd = __usb_create_hcd(_ehci_hc_driver, pdev->dev.parent,

   >dev, dev_name(>dev), NULL);
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 44a7e58..e5df175 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -112,6 +112,9 @@ static struct platform_device *fsl_usb2_device_register(
goto error;
}
  
+	pdev->dev.of_node = ofdev->dev.of_node;

+   pdev->dev.of_node_reused = true;
+
retval = platform_device_add(pdev);
if (retval)
goto error;

Hello,

I patched the RC5 of kernel 5.19 with this patch and I can confirm, that 
my keyboard and mouse work without any problems.


Tested-by: Christian Zigotzky 

Please accept this patch.

Thanks,
Christian


Re: [FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19

2022-06-16 Thread Christian Zigotzky

On 13 June 2022 at 05:57 pm, Rob Herring wrote:

On Thu, Jun 9, 2022 at 12:03 PM Christian Zigotzky
 wrote:

On 06 June 2022 at 07:06 pm, Rob Herring wrote:

On Mon, Jun 6, 2022 at 11:14 AM Christian Zigotzky
 wrote:

On 06 June 2022 at 04:58 pm, Rob Herring wrote:

On Fri, May 27, 2022 at 9:23 AM Rob Herring  wrote:

On Fri, May 27, 2022 at 3:33 AM Christian Zigotzky
 wrote:

On 27 May 2022 at 10:14 am, Prabhakar Mahadev Lad wrote:

Hi,


-Original Message-
From: Christian Zigotzky 

On 27 May 2022 at 09:56 am, Prabhakar Mahadev Lad wrote:

Hi,


-Original Message-
From: Christophe Leroy 

[...]


Looks like the driver which you are using has not been converted to use

platform_get_irq(), could you please check that.

Cheers,
Prabhakar

Do you mean the mouse and keyboard driver?


No it could be your gpio/pinctrl driver assuming the keyboard/mouse are using 
GPIO's. If you are using interrupts then it might be some hierarchal irqc 
driver in drivers/irqchip/.

Cheers,
Prabhakar

Good to know. I only use unmodified drivers from the official Linux
kernel so it's not an issue of the Cyrus+ board.

The issue is in drivers/usb/host/fsl-mph-dr-of.c which copies the
resources to a child platform device. Can you try the following
change:

diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 44a7e58a26e3..47d9b7be60da 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -80,8 +80,6 @@ static struct platform_device *fsl_usb2_device_register(
   const char *name, int id)
{
   struct platform_device *pdev;
-   const struct resource *res = ofdev->resource;
-   unsigned int num = ofdev->num_resources;
   int retval;

   pdev = platform_device_alloc(name, id);
@@ -106,11 +104,7 @@ static struct platform_device *fsl_usb2_device_register(
   if (retval)
   goto error;

-   if (num) {
-   retval = platform_device_add_resources(pdev, res, num);
-   if (retval)
-   goto error;
-   }
+   pdev->dev.of_node = ofdev->dev.of_node;

>From the log, I think you also need to add this line:

pdev->dev.of_node_reused = true;


   retval = platform_device_add(pdev);
   if (retval)

Hello Rob,

Thanks a lot for your answer.

Is the following patch correct?

Yes


--- a/drivers/usb/host/fsl-mph-dr-of.c2022-05-28 09:10:26.797688422
+0200
+++ b/drivers/usb/host/fsl-mph-dr-of.c2022-05-28 09:15:01.668594809
+0200
@@ -80,8 +80,6 @@ static struct platform_device *fsl_usb2_
const char *name, int id)
{
struct platform_device *pdev;
-const struct resource *res = ofdev->resource;
-unsigned int num = ofdev->num_resources;
int retval;

pdev = platform_device_alloc(name, id);
@@ -106,11 +104,7 @@ static struct platform_device *fsl_usb2_
if (retval)
goto error;

-if (num) {
-retval = platform_device_add_resources(pdev, res, num);
-if (retval)
-goto error;
-}
+pdev->dev.of_node = ofdev->dev.of_node;
+pdev->dev.of_node_reused = true;

retval = platform_device_add(pdev);
if (retval)

---

Thanks,
Christian

Hello Rob,

I tested this patch today and unfortunately the issue still exists.

The log is the same?

Rob

Yes, it's the same.

Link: http://www.xenosoft.de/dmesg_FSL_P5040_Void_PPC-2.txt

-- Christian



[FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19

2022-06-09 Thread Christian Zigotzky

On 06 June 2022 at 07:06 pm, Rob Herring wrote:

On Mon, Jun 6, 2022 at 11:14 AM Christian Zigotzky
 wrote:

On 06 June 2022 at 04:58 pm, Rob Herring wrote:

On Fri, May 27, 2022 at 9:23 AM Rob Herring  wrote:

On Fri, May 27, 2022 at 3:33 AM Christian Zigotzky
 wrote:

On 27 May 2022 at 10:14 am, Prabhakar Mahadev Lad wrote:

Hi,


-Original Message-
From: Christian Zigotzky 

On 27 May 2022 at 09:56 am, Prabhakar Mahadev Lad wrote:

Hi,


-Original Message-
From: Christophe Leroy 

[...]


Looks like the driver which you are using has not been converted to use

platform_get_irq(), could you please check that.

Cheers,
Prabhakar

Do you mean the mouse and keyboard driver?


No it could be your gpio/pinctrl driver assuming the keyboard/mouse are using 
GPIO's. If you are using interrupts then it might be some hierarchal irqc 
driver in drivers/irqchip/.

Cheers,
Prabhakar

Good to know. I only use unmodified drivers from the official Linux
kernel so it's not an issue of the Cyrus+ board.

The issue is in drivers/usb/host/fsl-mph-dr-of.c which copies the
resources to a child platform device. Can you try the following
change:

diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 44a7e58a26e3..47d9b7be60da 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -80,8 +80,6 @@ static struct platform_device *fsl_usb2_device_register(
  const char *name, int id)
   {
  struct platform_device *pdev;
-   const struct resource *res = ofdev->resource;
-   unsigned int num = ofdev->num_resources;
  int retval;

  pdev = platform_device_alloc(name, id);
@@ -106,11 +104,7 @@ static struct platform_device *fsl_usb2_device_register(
  if (retval)
  goto error;

-   if (num) {
-   retval = platform_device_add_resources(pdev, res, num);
-   if (retval)
-   goto error;
-   }
+   pdev->dev.of_node = ofdev->dev.of_node;

>From the log, I think you also need to add this line:

pdev->dev.of_node_reused = true;


  retval = platform_device_add(pdev);
  if (retval)

Hello Rob,

Thanks a lot for your answer.

Is the following patch correct?

Yes


--- a/drivers/usb/host/fsl-mph-dr-of.c2022-05-28 09:10:26.797688422
+0200
+++ b/drivers/usb/host/fsl-mph-dr-of.c2022-05-28 09:15:01.668594809
+0200
@@ -80,8 +80,6 @@ static struct platform_device *fsl_usb2_
   const char *name, int id)
   {
   struct platform_device *pdev;
-const struct resource *res = ofdev->resource;
-unsigned int num = ofdev->num_resources;
   int retval;

   pdev = platform_device_alloc(name, id);
@@ -106,11 +104,7 @@ static struct platform_device *fsl_usb2_
   if (retval)
   goto error;

-if (num) {
-retval = platform_device_add_resources(pdev, res, num);
-if (retval)
-goto error;
-}
+pdev->dev.of_node = ofdev->dev.of_node;
+pdev->dev.of_node_reused = true;

   retval = platform_device_add(pdev);
   if (retval)

---

Thanks,
Christian

Hello Rob,

I tested this patch today and unfortunately the issue still exists.

Do you have another idea?

Thanks,
Christian

Updated patch:

--- a/drivers/usb/host/fsl-mph-dr-of.c  2022-06-06 02:18:54.0 +0200
+++ b/drivers/usb/host/fsl-mph-dr-of.c  2022-06-09 19:31:50.135472793 +0200
@@ -80,8 +80,6 @@ static struct platform_device *fsl_usb2_
    const char *name, int id)
 {
    struct platform_device *pdev;
-   const struct resource *res = ofdev->resource;
-   unsigned int num = ofdev->num_resources;
    int retval;

    pdev = platform_device_alloc(name, id);
@@ -105,12 +103,8 @@ static struct platform_device *fsl_usb2_
    retval = platform_device_add_data(pdev, pdata, sizeof(*pdata));
    if (retval)
    goto error;
-
-   if (num) {
-   retval = platform_device_add_resources(pdev, res, num);
-   if (retval)
-   goto error;
-   }
+    pdev->dev.of_node = ofdev->dev.of_node;
+    pdev->dev.of_node_reused = true;

    retval = platform_device_add(pdev);
    if (retval)


[FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19

2022-06-06 Thread Christian Zigotzky

On 06 June 2022 at 04:58 pm, Rob Herring wrote:

On Fri, May 27, 2022 at 9:23 AM Rob Herring  wrote:

On Fri, May 27, 2022 at 3:33 AM Christian Zigotzky
 wrote:

On 27 May 2022 at 10:14 am, Prabhakar Mahadev Lad wrote:

Hi,


-Original Message-
From: Christian Zigotzky 

On 27 May 2022 at 09:56 am, Prabhakar Mahadev Lad wrote:

Hi,


-Original Message-
From: Christophe Leroy 

[...]


Looks like the driver which you are using has not been converted to use

platform_get_irq(), could you please check that.

Cheers,
Prabhakar

Do you mean the mouse and keyboard driver?


No it could be your gpio/pinctrl driver assuming the keyboard/mouse are using 
GPIO's. If you are using interrupts then it might be some hierarchal irqc 
driver in drivers/irqchip/.

Cheers,
Prabhakar

Good to know. I only use unmodified drivers from the official Linux
kernel so it's not an issue of the Cyrus+ board.

The issue is in drivers/usb/host/fsl-mph-dr-of.c which copies the
resources to a child platform device. Can you try the following
change:

diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 44a7e58a26e3..47d9b7be60da 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -80,8 +80,6 @@ static struct platform_device *fsl_usb2_device_register(
 const char *name, int id)
  {
 struct platform_device *pdev;
-   const struct resource *res = ofdev->resource;
-   unsigned int num = ofdev->num_resources;
 int retval;

 pdev = platform_device_alloc(name, id);
@@ -106,11 +104,7 @@ static struct platform_device *fsl_usb2_device_register(
 if (retval)
 goto error;

-   if (num) {
-   retval = platform_device_add_resources(pdev, res, num);
-   if (retval)
-   goto error;
-   }
+   pdev->dev.of_node = ofdev->dev.of_node;

>From the log, I think you also need to add this line:

pdev->dev.of_node_reused = true;


 retval = platform_device_add(pdev);
 if (retval)

Hello Rob,

Thanks a lot for your answer.

Is the following patch correct?

--- a/drivers/usb/host/fsl-mph-dr-of.c    2022-05-28 09:10:26.797688422 
+0200
+++ b/drivers/usb/host/fsl-mph-dr-of.c    2022-05-28 09:15:01.668594809 
+0200

@@ -80,8 +80,6 @@ static struct platform_device *fsl_usb2_
                 const char *name, int id)
 {
 struct platform_device *pdev;
-    const struct resource *res = ofdev->resource;
-    unsigned int num = ofdev->num_resources;
 int retval;

 pdev = platform_device_alloc(name, id);
@@ -106,11 +104,7 @@ static struct platform_device *fsl_usb2_
 if (retval)
     goto error;

-    if (num) {
-        retval = platform_device_add_resources(pdev, res, num);
-        if (retval)
-            goto error;
-    }
+    pdev->dev.of_node = ofdev->dev.of_node;
+    pdev->dev.of_node_reused = true;

 retval = platform_device_add(pdev);
 if (retval)

---

Thanks,
Christian


Re: [FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19

2022-06-04 Thread Christian Zigotzky

On 27 May 2022 at 03:40 pm, Darren Stevens wrote:
> Hi Christian,
>
> Can you send me the full dmesg output from this failed boot? I looked 
but can't seem to find which component is at fault here

>
> Thanks
> Darren

On 01 June 2022 at 02:35 pm, Rob Herring wrote:

On Tue, May 31, 2022 at 06:29:38PM +0200, Christian Zigotzky wrote:



On 31. May 2022, at 15:46, Rob Herring  wrote:

On Mon, May 30, 2022 at 12:26 AM Christian Zigotzky
 wrote:

On 27 May 2022 at 04:23 pm, Rob Herring wrote:
The issue is in drivers/usb/host/fsl-mph-dr-of.c which copies the
resources to a child platform device. Can you try the following
change:

diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 44a7e58a26e3..47d9b7be60da 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -80,8 +80,6 @@ static struct platform_device *fsl_usb2_device_register(
 const char *name, int id)
  {
 struct platform_device *pdev;
-   const struct resource *res = ofdev->resource;
-   unsigned int num = ofdev->num_resources;
 int retval;

 pdev = platform_device_alloc(name, id);
@@ -106,11 +104,7 @@ static struct platform_device *fsl_usb2_device_register(
 if (retval)
 goto error;

-   if (num) {
-   retval = platform_device_add_resources(pdev, res, num);
-   if (retval)
-   goto error;
-   }
+   pdev->dev.of_node = ofdev->dev.of_node;

 retval = platform_device_add(pdev);
 if (retval)

Hello Rob,

Thanks a lot for your patch! Unfortunately, this leads to a boot loop.
Do you have another idea?

Do you have a dmesg log?

 From the boot loop?

Yes.


The other way to fix is creating a IRQ resource and adding it to the
child device resources.

Good idea.

Not really. I'd rather have the child device just point to the DT node,
but that doesn't seem to work for some drivers and I want to understand
why.

Rob


Hello Rob,
Hello Darren,

The keyboard and mouse issue still exists in the latest git kernel.

Here are the logs:

- http://www.xenosoft.de/dmesg_FSL_P5040_Void_PPC.txt
- http://www.xenosoft.de/dmesg_FSL_P5040_MintPPC.txt
- http://www.xenosoft.de/dmesg_FSL_P5040_Void_PPC_with_Robs_patch.txt

Thanks,
Christian


Re: [FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19

2022-05-31 Thread Christian Zigotzky
On 31. May 2022, at 15:46, Rob Herring  wrote:

Do you have a dmesg log?

The other way to fix is creating a IRQ resource and adding it to the
child device resources.

Rob

——

Rob,

Do you mean a dmesg from the boot loop?
The other way is a good idea.

Cheers,
Christian


Re: [FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19

2022-05-31 Thread Christian Zigotzky



> On 31. May 2022, at 15:46, Rob Herring  wrote:
> 
> On Mon, May 30, 2022 at 12:26 AM Christian Zigotzky
>  wrote:
>> 
>>> On 27 May 2022 at 04:23 pm, Rob Herring wrote:
>>> The issue is in drivers/usb/host/fsl-mph-dr-of.c which copies the
>>> resources to a child platform device. Can you try the following
>>> change:
>>> 
>>> diff --git a/drivers/usb/host/fsl-mph-dr-of.c 
>>> b/drivers/usb/host/fsl-mph-dr-of.c
>>> index 44a7e58a26e3..47d9b7be60da 100644
>>> --- a/drivers/usb/host/fsl-mph-dr-of.c
>>> +++ b/drivers/usb/host/fsl-mph-dr-of.c
>>> @@ -80,8 +80,6 @@ static struct platform_device *fsl_usb2_device_register(
>>> const char *name, int id)
>>>  {
>>> struct platform_device *pdev;
>>> -   const struct resource *res = ofdev->resource;
>>> -   unsigned int num = ofdev->num_resources;
>>> int retval;
>>> 
>>> pdev = platform_device_alloc(name, id);
>>> @@ -106,11 +104,7 @@ static struct platform_device 
>>> *fsl_usb2_device_register(
>>> if (retval)
>>> goto error;
>>> 
>>> -   if (num) {
>>> -   retval = platform_device_add_resources(pdev, res, num);
>>> -   if (retval)
>>> -   goto error;
>>> -   }
>>> +   pdev->dev.of_node = ofdev->dev.of_node;
>>> 
>>> retval = platform_device_add(pdev);
>>> if (retval)
>> Hello Rob,
>> 
>> Thanks a lot for your patch! Unfortunately, this leads to a boot loop.
>> Do you have another idea?
> 
> Do you have a dmesg log?

From the boot loop?

> 
> The other way to fix is creating a IRQ resource and adding it to the
> child device resources.

Good idea.
> 
> Rob



Re: [FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19

2022-05-29 Thread Christian Zigotzky

On 27 May 2022 at 04:23 pm, Rob Herring wrote:

The issue is in drivers/usb/host/fsl-mph-dr-of.c which copies the
resources to a child platform device. Can you try the following
change:

diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 44a7e58a26e3..47d9b7be60da 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -80,8 +80,6 @@ static struct platform_device *fsl_usb2_device_register(
 const char *name, int id)
  {
 struct platform_device *pdev;
-   const struct resource *res = ofdev->resource;
-   unsigned int num = ofdev->num_resources;
 int retval;

 pdev = platform_device_alloc(name, id);
@@ -106,11 +104,7 @@ static struct platform_device *fsl_usb2_device_register(
 if (retval)
 goto error;

-   if (num) {
-   retval = platform_device_add_resources(pdev, res, num);
-   if (retval)
-   goto error;
-   }
+   pdev->dev.of_node = ofdev->dev.of_node;

 retval = platform_device_add(pdev);
 if (retval)

Hello Rob,

Thanks a lot for your patch! Unfortunately, this leads to a boot loop. 
Do you have another idea?


Thanks,
Christian


Re: [FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19

2022-05-28 Thread Christian Zigotzky

On 28 May 2022 at 10:05 am, Christian Zigotzky wrote:

On 27 May 2022 at 04:23 am, Rob Herring wrote:

The issue is in drivers/usb/host/fsl-mph-dr-of.c which copies the
resources to a child platform device. Can you try the following
change:

diff --git a/drivers/usb/host/fsl-mph-dr-of.c 
b/drivers/usb/host/fsl-mph-dr-of.c

index 44a7e58a26e3..47d9b7be60da 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -80,8 +80,6 @@ static struct platform_device 
*fsl_usb2_device_register(

 const char *name, int id)
  {
 struct platform_device *pdev;
-   const struct resource *res = ofdev->resource;
-   unsigned int num = ofdev->num_resources;
 int retval;

 pdev = platform_device_alloc(name, id);
@@ -106,11 +104,7 @@ static struct platform_device 
*fsl_usb2_device_register(

 if (retval)
 goto error;

-   if (num) {
-   retval = platform_device_add_resources(pdev, res, num);
-   if (retval)
-   goto error;
-   }
+   pdev->dev.of_node = ofdev->dev.of_node;

 retval = platform_device_add(pdev);
 if (retval)

Hi Rob,

Thanks a lot for your patch! :-)

First attempt with the latest git kernel:

patching file a/drivers/usb/host/fsl-mph-dr-of.c
Hunk #1 FAILED at 80.
Hunk #2 FAILED at 106.
2 out of 2 hunks FAILED -- saving rejects to file 
a/drivers/usb/host/fsl-mph-dr-of.c.rej


I created a new patch with your modifications. (see attachment)

Unfortunately I can't test it. The git kernel doesn't compile currently.

powerpc-linux-gnu-ld: net/rds/tcp_stats.o:(.bss+0x0): multiple 
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): 
first defined here
powerpc-linux-gnu-ld: net/wireless/wext-spy.o:(.bss+0x0): multiple 
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): 
first defined here
powerpc-linux-gnu-ld: net/wireless/wext-priv.o:(.bss+0x0): multiple 
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): 
first defined here
powerpc-linux-gnu-ld: net/tipc/bcast.o:(.bss+0x0): multiple definition 
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/bearer.o:(.bss+0x0): multiple 
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): 
first defined here
powerpc-linux-gnu-ld: net/tipc/core.o:(.bss+0x0): multiple definition 
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/link.o:(.bss+0x0): multiple definition 
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/discover.o:(.bss+0x0): multiple 
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): 
first defined here
powerpc-linux-gnu-ld: net/tipc/msg.o:(.bss+0x0): multiple definition 
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/name_distr.o:(.bss+0x0): multiple 
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): 
first defined here
powerpc-linux-gnu-ld: net/tipc/subscr.o:(.bss+0x0): multiple 
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): 
first defined here
powerpc-linux-gnu-ld: net/tipc/name_table.o:(.bss+0x0): multiple 
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): 
first defined here
powerpc-linux-gnu-ld: net/tipc/net.o:(.bss+0x0): multiple definition 
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/netlink.o:(.bss+0x0): multiple 
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): 
first defined here
powerpc-linux-gnu-ld: net/tipc/netlink_compat.o:(.bss+0x0): multiple 
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): 
first defined here
powerpc-linux-gnu-ld: net/tipc/node.o:(.bss+0x0): multiple definition 
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/eth_media.o:(.bss+0x0): multiple 
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): 
first defined here
powerpc-linux-gnu-ld: net/tipc/topsrv.o:(.bss+0x0): multiple 
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): 
first defined here
powerpc-linux-gnu-ld: net/tipc/group.o:(.bss+0x0): multiple definition 
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/trace.o:(.bss+0x0): multiple definition 
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/udp_media.o:(.bss+0x0): multiple 
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): 
first defined here
powerpc-linux-gnu-ld: net/tipc/sysctl.o:(.bss+0x40): multiple 
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): 
first defined here
powerpc-linux-gnu-ld: net/tipc/crypto.o:(.bss+0x0): multiple

Re: [FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19

2022-05-28 Thread Christian Zigotzky

On 27 May 2022 at 04:23 am, Rob Herring wrote:

The issue is in drivers/usb/host/fsl-mph-dr-of.c which copies the
resources to a child platform device. Can you try the following
change:

diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 44a7e58a26e3..47d9b7be60da 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -80,8 +80,6 @@ static struct platform_device *fsl_usb2_device_register(
 const char *name, int id)
  {
 struct platform_device *pdev;
-   const struct resource *res = ofdev->resource;
-   unsigned int num = ofdev->num_resources;
 int retval;

 pdev = platform_device_alloc(name, id);
@@ -106,11 +104,7 @@ static struct platform_device *fsl_usb2_device_register(
 if (retval)
 goto error;

-   if (num) {
-   retval = platform_device_add_resources(pdev, res, num);
-   if (retval)
-   goto error;
-   }
+   pdev->dev.of_node = ofdev->dev.of_node;

 retval = platform_device_add(pdev);
 if (retval)

Hi Rob,

Thanks a lot for your patch! :-)

First attempt with the latest git kernel:

patching file a/drivers/usb/host/fsl-mph-dr-of.c
Hunk #1 FAILED at 80.
Hunk #2 FAILED at 106.
2 out of 2 hunks FAILED -- saving rejects to file 
a/drivers/usb/host/fsl-mph-dr-of.c.rej


I created a new patch with your modifications. (see attachment)

Unfortunately I can't test it. The git kernel doesn't compile currently.

powerpc-linux-gnu-ld: net/rds/tcp_stats.o:(.bss+0x0): multiple 
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): first 
defined here
powerpc-linux-gnu-ld: net/wireless/wext-spy.o:(.bss+0x0): multiple 
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): first 
defined here
powerpc-linux-gnu-ld: net/wireless/wext-priv.o:(.bss+0x0): multiple 
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): first 
defined here
powerpc-linux-gnu-ld: net/tipc/bcast.o:(.bss+0x0): multiple definition 
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/bearer.o:(.bss+0x0): multiple definition 
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/core.o:(.bss+0x0): multiple definition of 
`cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/link.o:(.bss+0x0): multiple definition of 
`cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/discover.o:(.bss+0x0): multiple 
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): first 
defined here
powerpc-linux-gnu-ld: net/tipc/msg.o:(.bss+0x0): multiple definition of 
`cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/name_distr.o:(.bss+0x0): multiple 
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): first 
defined here
powerpc-linux-gnu-ld: net/tipc/subscr.o:(.bss+0x0): multiple definition 
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/name_table.o:(.bss+0x0): multiple 
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): first 
defined here
powerpc-linux-gnu-ld: net/tipc/net.o:(.bss+0x0): multiple definition of 
`cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/netlink.o:(.bss+0x0): multiple definition 
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/netlink_compat.o:(.bss+0x0): multiple 
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): first 
defined here
powerpc-linux-gnu-ld: net/tipc/node.o:(.bss+0x0): multiple definition of 
`cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/eth_media.o:(.bss+0x0): multiple 
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): first 
defined here
powerpc-linux-gnu-ld: net/tipc/topsrv.o:(.bss+0x0): multiple definition 
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/group.o:(.bss+0x0): multiple definition 
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/trace.o:(.bss+0x0): multiple definition 
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/udp_media.o:(.bss+0x0): multiple 
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): first 
defined here
powerpc-linux-gnu-ld: net/tipc/sysctl.o:(.bss+0x40): multiple definition 
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/crypto.o:(.bss+0x0): multiple definition 
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here

[FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19

2022-05-27 Thread Christian Zigotzky

On 27 May 2022 at 10:14 am, Prabhakar Mahadev Lad wrote:

Hi,


-Original Message-
From: Christian Zigotzky 
Sent: 27 May 2022 09:06
To: Prabhakar Mahadev Lad ;
Christophe Leroy ; Rob Herring

Cc: Darren Stevens ; linuxppc-dev ; mad skateman ; R.T.Dickinson
; Christian Zigotzky 
Subject: [FSL P50x0] Keyboard and mouse don't work anymore after the
devicetree updates for 5.19

On 27 May 2022 at 09:56 am, Prabhakar Mahadev Lad wrote:

Hi,


-Original Message-
From: Christophe Leroy 
Sent: 27 May 2022 08:23
To: Christian Zigotzky ;
rob.herr...@calxeda.com; Prabhakar Mahadev Lad

Cc: Darren Stevens ; linuxppc-dev ; mad skateman ;
R.T.Dickinson ; Christian Zigotzky

Subject: Re: [FSL P50x0] Keyboard and mouse don't work anymore after
the devicetree updates for 5.19

Hi

Le 26/05/2022 à 19:42, Christian Zigotzky a écrit :

Hello,

My keyboard and mouse don't work anymore with my Cyrus+ board with a
FSL
P50x0 PowerPC SoC [1] after the devicetree updates for 5.19 [2].
After reverting the devicetree updates, my keyboard and mouse work
without any problems.
I figured out that the issue is in the patch for the file platform.c
[3].  I created a patch for reverting the problematic code. (see
attachment)
After reverting the changes with the attached patch, the keyboard
and mouse work again.
Please check your changes in the file platform.c [3].

Thanks,
Christian

[1]
https://jpn01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.
amiga.org%2Findex.php%3Ftitle%3DX5000data=05%7C01%7Cprabhakar.m
ah
adev-lad.rj%40bp.renesas.com%7C4e9c08d1e3874a34bd4208da3fb1c007%7C53
d8
2571da1947e49cb4625a166a4a2a%7C0%7C0%7C637892329912063922%7CUnknown%
7C
TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
VC
I6Mn0%3D%7C3000%7C%7C%7Csdata=fSABvBDi%2FYlqU1eydQB6%2F4BzxXkqR
M0
Ln9hdInyTp6w%3Dreserved=0
[2]
https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.
kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git
%2
Fcommit%2F%3Fid%3D86c87bea6b42100c67418af690919c44de6ede6edata=
05
%7C01%7Cprabhakar.mahadev-lad.rj%40bp.renesas.com%7C4e9c08d1e3874a34
bd
4208da3fb1c007%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C63789232
99
12063922%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
iL
CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=ENkjlza0J7xF
iI
aPUwMBxHBIkXJNkT%2BLTZ3xuPz%2B10Q%3Dreserved=0

[3]
https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.
kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git
%2
Fdiff%2Fdrivers%2Fof%2Fplatform.c%3Fid%3D86c87bea6b42100c67418af6909
19
c44de6ede6edata=05%7C01%7Cprabhakar.mahadev-lad.rj%40bp.renesas
.c
om%7C4e9c08d1e3874a34bd4208da3fb1c007%7C53d82571da1947e49cb4625a166a
4a
2a%7C0%7C0%7C637892329912063922%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
Lj
AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C

mp;sdata=yEJUK%2BGK2dzWARC5rfhsSSFSwD%2BLZm8aNNHqQhPYP7Y%3Drese
rv
ed=0

Based on your patch I would say the culprit commit is
https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
hub.c%2Fdata=05%7C01%7Cprabhakar.mahadev-lad.rj%40bp.renesas.com
%7Cbf899ff2084643971c7908da3fb7d4b9%7C53d82571da1947e49cb4625a166a4a2
a%7C0%7C1%7C637892356025845542%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&
amp;sdata=%2FzI4yueF6Pc%2Fpvh7Ax9WilnaYX8ozFTRyQpiVaaacbg%3Drese
rved=0
om%2Ftorvalds%2Flinux%2Fcommit%2Fa1a2b7125e1079cfcc13a116aa3af3df2f9e
002b&
amp;data=05%7C01%7Cprabhakar.mahadev-
lad.rj%40bp.renesas.com%7C4e9c08d1e3874a34bd4208da3fb1c007%7C53d82571
da194
7e49cb4625a166a4a2a%7C0%7C0%7C637892329912063922%7CUnknown%7CTWFpbGZs
b3d8e
yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
000%7
C%7C%7Csdata=ONR1CiaSID6q4%2Fo%2BI6MlPA4ij89BJphQRpEu5tQxvYQ%3D&
amp;r
eserved=0

commit a1a2b7125e1079cfcc13a116aa3af3df2f9e002b
Author: Lad Prabhakar 
Date:   Wed Mar 16 20:06:33 2022 +

   of/platform: Drop static setup of IRQ resource from DT core

   Now that all the DT drivers have switched to platform_get_irq()
we can now
   safely drop the static setup of IRQ resource from DT core code.

   With the above change hierarchical setup of irq domains is no

longer

   bypassed and thus allowing hierarchical interrupt domains to

describe

   interrupts using "interrupts" DT property.

   Signed-off-by: Lad Prabhakar 
   Acked-by: Marc Zyngier 
   Tested-by: Marc Zyngier 
   Signed-off-by: Rob Herring 
   Link:
https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flor
e.ker%2Fdata=05%7C01%7Cprabhakar.mahadev-lad.rj%40bp.renesas.com
%7Cbf899ff2084643971c7908da3fb7d4b9%7C53d82571da1947e49cb4625a166a4a2
a%7C0%7C1%7C637892356025845542%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&
amp;sdata=R%2FhdNkjna6kT31Fy9L3HjrDscWR743O%2BAY8sITu9pVE%3Drese
rved=0
nel.org%2F

[FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19

2022-05-27 Thread Christian Zigotzky

On 27 May 2022 at 09:56 am, Prabhakar Mahadev Lad wrote:

Hi,


-Original Message-
From: Christophe Leroy 
Sent: 27 May 2022 08:23
To: Christian Zigotzky ; rob.herr...@calxeda.com;
Prabhakar Mahadev Lad 
Cc: Darren Stevens ; linuxppc-dev ; mad skateman ; R.T.Dickinson
; Christian Zigotzky 
Subject: Re: [FSL P50x0] Keyboard and mouse don't work anymore after the
devicetree updates for 5.19

Hi

Le 26/05/2022 à 19:42, Christian Zigotzky a écrit :

Hello,

My keyboard and mouse don't work anymore with my Cyrus+ board with a
FSL
P50x0 PowerPC SoC [1] after the devicetree updates for 5.19 [2].
After reverting the devicetree updates, my keyboard and mouse work
without any problems.
I figured out that the issue is in the patch for the file platform.c
[3].  I created a patch for reverting the problematic code. (see
attachment)
After reverting the changes with the attached patch, the keyboard and
mouse work again.
Please check your changes in the file platform.c [3].

Thanks,
Christian

[1]
https://jpn01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.
amiga.org%2Findex.php%3Ftitle%3DX5000data=05%7C01%7Cprabhakar.mah
adev-lad.rj%40bp.renesas.com%7C4e9c08d1e3874a34bd4208da3fb1c007%7C53d8
2571da1947e49cb4625a166a4a2a%7C0%7C0%7C637892329912063922%7CUnknown%7C
TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
I6Mn0%3D%7C3000%7C%7C%7Csdata=fSABvBDi%2FYlqU1eydQB6%2F4BzxXkqRM0
Ln9hdInyTp6w%3Dreserved=0
[2]
https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.
kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2
Fcommit%2F%3Fid%3D86c87bea6b42100c67418af690919c44de6ede6edata=05
%7C01%7Cprabhakar.mahadev-lad.rj%40bp.renesas.com%7C4e9c08d1e3874a34bd
4208da3fb1c007%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C6378923299
12063922%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=ENkjlza0J7xFiI
aPUwMBxHBIkXJNkT%2BLTZ3xuPz%2B10Q%3Dreserved=0

[3]
https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.
kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2
Fdiff%2Fdrivers%2Fof%2Fplatform.c%3Fid%3D86c87bea6b42100c67418af690919
c44de6ede6edata=05%7C01%7Cprabhakar.mahadev-lad.rj%40bp.renesas.c
om%7C4e9c08d1e3874a34bd4208da3fb1c007%7C53d82571da1947e49cb4625a166a4a
2a%7C0%7C0%7C637892329912063922%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
mp;sdata=yEJUK%2BGK2dzWARC5rfhsSSFSwD%2BLZm8aNNHqQhPYP7Y%3Dreserv
ed=0


Based on your patch I would say the culprit commit is
https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c
om%2Ftorvalds%2Flinux%2Fcommit%2Fa1a2b7125e1079cfcc13a116aa3af3df2f9e002b&
amp;data=05%7C01%7Cprabhakar.mahadev-
lad.rj%40bp.renesas.com%7C4e9c08d1e3874a34bd4208da3fb1c007%7C53d82571da194
7e49cb4625a166a4a2a%7C0%7C0%7C637892329912063922%7CUnknown%7CTWFpbGZsb3d8e
yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7
C%7C%7Csdata=ONR1CiaSID6q4%2Fo%2BI6MlPA4ij89BJphQRpEu5tQxvYQ%3Dr
eserved=0

commit a1a2b7125e1079cfcc13a116aa3af3df2f9e002b
Author: Lad Prabhakar 
Date:   Wed Mar 16 20:06:33 2022 +

  of/platform: Drop static setup of IRQ resource from DT core

  Now that all the DT drivers have switched to platform_get_irq() we
can now
  safely drop the static setup of IRQ resource from DT core code.

  With the above change hierarchical setup of irq domains is no longer
  bypassed and thus allowing hierarchical interrupt domains to describe
  interrupts using "interrupts" DT property.

  Signed-off-by: Lad Prabhakar 
  Acked-by: Marc Zyngier 
  Tested-by: Marc Zyngier 
  Signed-off-by: Rob Herring 
  Link:
https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ker
nel.org%2Fr%2F20220316200633.28974-1-prabhakar.mahadev-
lad.rj%40bp.renesas.comdata=05%7C01%7Cprabhakar.mahadev-
lad.rj%40bp.renesas.com%7C4e9c08d1e3874a34bd4208da3fb1c007%7C53d82571da194
7e49cb4625a166a4a2a%7C0%7C0%7C637892329912063922%7CUnknown%7CTWFpbGZsb3d8e
yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7
C%7C%7Csdata=ri76vfLpmxe7vFDAlsBjyrSSkuTMz0ydftu3XObLGLA%3Dreser
ved=0


Looks like the driver which you are using has not been converted to use 
platform_get_irq(), could you please check that.

Cheers,
Prabhakar

Do you mean the mouse and keyboard driver?

-- Christian


Fwd: [FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19

2022-05-27 Thread Christian Zigotzky

Rob's email address corrected.

-- Christian


On 27 May 2022 at 09:23 am, Christophe Leroy wrote:

Hi

Le 26/05/2022 à 19:42, Christian Zigotzky a écrit :

Hello,

My keyboard and mouse don't work anymore with my Cyrus+ board with a FSL
P50x0 PowerPC SoC [1] after the devicetree updates for 5.19 [2].
After reverting the devicetree updates, my keyboard and mouse work
without any problems.
I figured out that the issue is in the patch for the file platform.c
[3].  I created a patch for reverting the problematic code. (see
attachment)
After reverting the changes with the attached patch, the keyboard and
mouse work again.
Please check your changes in the file platform.c [3].

Thanks,
Christian

[1] http://wiki.amiga.org/index.php?title=X5000
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=86c87bea6b42100c67418af690919c44de6ede6e

[3]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/of/platform.c?id=86c87bea6b42100c67418af690919c44de6ede6e


Based on your patch I would say the culprit commit is
https://github.com/torvalds/linux/commit/a1a2b7125e1079cfcc13a116aa3af3df2f9e002b

commit a1a2b7125e1079cfcc13a116aa3af3df2f9e002b
Author: Lad Prabhakar 
Date: Wed Mar 16 20:06:33 2022 +

of/platform: Drop static setup of IRQ resource from DT core

Now that all the DT drivers have switched to platform_get_irq() we
can now
safely drop the static setup of IRQ resource from DT core code.

With the above change hierarchical setup of irq domains is no longer
bypassed and thus allowing hierarchical interrupt domains to describe
interrupts using "interrupts" DT property.

Signed-off-by: Lad Prabhakar 
Acked-by: Marc Zyngier 
Tested-by: Marc Zyngier 
Signed-off-by: Rob Herring 
Link:
https://lore.kernel.org/r/20220316200633.28974-1-prabhakar.mahadev-lad...@bp.renesas.com



Can you please provide you device tree ?

Do you use any out-of-tree drivers ?

Thanks
Christophe

Hi Christophe,

No, I don't use any out-of-tree drivers. Please find attached the dtb, 
dts, and the dtsi file.


Thanks,
Christian/*
 * P5040 Silicon/SoC Device Tree Source (pre include)
 *
 * Copyright 2012 - 2015 Freescale Semiconductor Inc.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions are met:
 * * Redistributions of source code must retain the above copyright
 *   notice, this list of conditions and the following disclaimer.
 * * Redistributions in binary form must reproduce the above copyright
 *   notice, this list of conditions and the following disclaimer in the
 *   documentation and/or other materials provided with the distribution.
 * * Neither the name of Freescale Semiconductor nor the
 *   names of its contributors may be used to endorse or promote products
 *   derived from this software without specific prior written permission.
 *
 *
 * ALTERNATIVELY, this software may be distributed under the terms of the
 * GNU General Public License ("GPL") as published by the Free Software
 * Foundation, either version 2 of that License or (at your option) any
 * later version.
 *
 * This software is provided by Freescale Semiconductor "as is" and any
 * express or implied warranties, including, but not limited to, the implied
 * warranties of merchantability and fitness for a particular purpose are
 * disclaimed. In no event shall Freescale Semiconductor be liable for any
 * direct, indirect, incidental, special, exemplary, or consequential damages
 * (including, but not limited to, procurement of substitute goods or services;
 * loss of use, data, or profits; or business interruption) however caused and
 * on any theory of liability, whether in contract, strict liability, or tort
 * (including negligence or otherwise) arising in any way out of the use of this
 * software, even if advised of the possibility of such damage.
 */

/dts-v1/;

/include/ "e5500_power_isa.dtsi"

/ {
compatible = "fsl,P5040";
#address-cells = <2>;
#size-cells = <2>;
interrupt-parent = <>;

aliases {
ccsr = 
dcsr = 

serial0 = 
serial1 = 
serial2 = 
serial3 = 
pci0 = 
pci1 = 
pci2 = 
usb0 = 
usb1 = 
dma0 = 
dma1 = 
sdhc = 
msi0 = 
msi1 = 
msi2 = 

crypto = 
sec_jr0 = _jr0;
sec_jr1 = _jr1;
sec_jr2 = _jr2;
sec_jr3 = _jr3;
rtic_a = _a;
rtic_b = _b;
rtic_c = _c;
rtic_d = _d;
sec_mon = _mon;

raideng = 
raideng_jr0 = _jr0;
  

[FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19

2022-05-27 Thread Christian Zigotzky

On 27 May 2022 at 09:23 am, Christophe Leroy wrote:

Hi

Le 26/05/2022 à 19:42, Christian Zigotzky a écrit :

Hello,

My keyboard and mouse don't work anymore with my Cyrus+ board with a FSL
P50x0 PowerPC SoC [1] after the devicetree updates for 5.19 [2].
After reverting the devicetree updates, my keyboard and mouse work
without any problems.
I figured out that the issue is in the patch for the file platform.c
[3].  I created a patch for reverting the problematic code. (see
attachment)
After reverting the changes with the attached patch, the keyboard and
mouse work again.
Please check your changes in the file platform.c [3].

Thanks,
Christian

[1] http://wiki.amiga.org/index.php?title=X5000
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=86c87bea6b42100c67418af690919c44de6ede6e

[3]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/of/platform.c?id=86c87bea6b42100c67418af690919c44de6ede6e


Based on your patch I would say the culprit commit is
https://github.com/torvalds/linux/commit/a1a2b7125e1079cfcc13a116aa3af3df2f9e002b

commit a1a2b7125e1079cfcc13a116aa3af3df2f9e002b
Author: Lad Prabhakar 
Date:   Wed Mar 16 20:06:33 2022 +

  of/platform: Drop static setup of IRQ resource from DT core

  Now that all the DT drivers have switched to platform_get_irq() we
can now
  safely drop the static setup of IRQ resource from DT core code.

  With the above change hierarchical setup of irq domains is no longer
  bypassed and thus allowing hierarchical interrupt domains to describe
  interrupts using "interrupts" DT property.

  Signed-off-by: Lad Prabhakar 
  Acked-by: Marc Zyngier 
  Tested-by: Marc Zyngier 
  Signed-off-by: Rob Herring 
  Link:
https://lore.kernel.org/r/20220316200633.28974-1-prabhakar.mahadev-lad...@bp.renesas.com



Can you please provide you device tree ?

Do you use any out-of-tree drivers ?

Thanks
Christophe

Hi Christophe,

No, I don't use any out-of-tree drivers. Please find attached the dtb, 
dts, and the dtsi file.


Thanks,
Christian/*
 * P5040 Silicon/SoC Device Tree Source (pre include)
 *
 * Copyright 2012 - 2015 Freescale Semiconductor Inc.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions are met:
 * * Redistributions of source code must retain the above copyright
 *   notice, this list of conditions and the following disclaimer.
 * * Redistributions in binary form must reproduce the above copyright
 *   notice, this list of conditions and the following disclaimer in the
 *   documentation and/or other materials provided with the distribution.
 * * Neither the name of Freescale Semiconductor nor the
 *   names of its contributors may be used to endorse or promote products
 *   derived from this software without specific prior written permission.
 *
 *
 * ALTERNATIVELY, this software may be distributed under the terms of the
 * GNU General Public License ("GPL") as published by the Free Software
 * Foundation, either version 2 of that License or (at your option) any
 * later version.
 *
 * This software is provided by Freescale Semiconductor "as is" and any
 * express or implied warranties, including, but not limited to, the implied
 * warranties of merchantability and fitness for a particular purpose are
 * disclaimed. In no event shall Freescale Semiconductor be liable for any
 * direct, indirect, incidental, special, exemplary, or consequential damages
 * (including, but not limited to, procurement of substitute goods or services;
 * loss of use, data, or profits; or business interruption) however caused and
 * on any theory of liability, whether in contract, strict liability, or tort
 * (including negligence or otherwise) arising in any way out of the use of this
 * software, even if advised of the possibility of such damage.
 */

/dts-v1/;

/include/ "e5500_power_isa.dtsi"

/ {
compatible = "fsl,P5040";
#address-cells = <2>;
#size-cells = <2>;
interrupt-parent = <>;

aliases {
ccsr = 
dcsr = 

serial0 = 
serial1 = 
serial2 = 
serial3 = 
pci0 = 
pci1 = 
pci2 = 
usb0 = 
usb1 = 
dma0 = 
dma1 = 
sdhc = 
msi0 = 
msi1 = 
msi2 = 

crypto = 
sec_jr0 = _jr0;
sec_jr1 = _jr1;
sec_jr2 = _jr2;
sec_jr3 = _jr3;
rtic_a = _a;
rtic_b = _b;
rtic_c = _c;
rtic_d = _d;
sec_mon = _mon;

raideng = 
  

The PA6T is still vulnerable

2021-12-29 Thread Christian Zigotzky
Hi All,

The P.A. Semi PA6T is still vulnerable.

Architecture:ppc64
CPU op-mode(s):  32-bit, 64-bit
Byte Order:  Big Endian
CPU(s):  2
On-line CPU(s) list: 0,1
Thread(s) per core:  1
Core(s) per socket:  2
Socket(s):   1
Model:   1.2 (pvr 0090 0102)
Model name:  PA6T, altivec supported
L1d cache:   128 KiB
L1i cache:   128 KiB
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf:  Vulnerable
Vulnerability Mds:   Not affected
Vulnerability Meltdown:  Vulnerable
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1:Mitigation; __user pointer sanitization
Vulnerability Spectre v2:Vulnerable
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort:   Not affected

Could you please check this issue?

Thanks,
Christian


Re: [PATCH] powerpc/book3e: Fix TLBCAM preset at boot

2021-11-15 Thread Christian Zigotzky

On 15 November 2021 at 10:05 am, Christophe Leroy wrote:

Commit 52bda69ae8b5 ("powerpc/fsl_booke: Tell map_mem_in_cams() if
init is done") was supposed to just add an additional parameter to
map_mem_in_cams() and always set it to 'true' at that time.

But a few call sites were messed up. Fix them.

Reported-by: Christian Zigotzky 
Fixes: 52bda69ae8b5 ("powerpc/fsl_booke: Tell map_mem_in_cams() if init is 
done")
Signed-off-by: Christophe Leroy 
---
  arch/powerpc/mm/nohash/kaslr_booke.c | 2 +-
  arch/powerpc/mm/nohash/tlb.c | 4 ++--
  2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/mm/nohash/kaslr_booke.c 
b/arch/powerpc/mm/nohash/kaslr_booke.c
index 8fc49b1b4a91..6ec978967da0 100644
--- a/arch/powerpc/mm/nohash/kaslr_booke.c
+++ b/arch/powerpc/mm/nohash/kaslr_booke.c
@@ -314,7 +314,7 @@ static unsigned long __init kaslr_choose_location(void 
*dt_ptr, phys_addr_t size
pr_warn("KASLR: No safe seed for randomizing the kernel 
base.\n");
  
  	ram = min_t(phys_addr_t, __max_low_memory, size);

-   ram = map_mem_in_cams(ram, CONFIG_LOWMEM_CAM_NUM, true, false);
+   ram = map_mem_in_cams(ram, CONFIG_LOWMEM_CAM_NUM, true, true);
linear_sz = min_t(unsigned long, ram, SZ_512M);
  
  	/* If the linear size is smaller than 64M, do not randmize */

diff --git a/arch/powerpc/mm/nohash/tlb.c b/arch/powerpc/mm/nohash/tlb.c
index 89353d4f5604..647bf454a0fa 100644
--- a/arch/powerpc/mm/nohash/tlb.c
+++ b/arch/powerpc/mm/nohash/tlb.c
@@ -645,7 +645,7 @@ static void early_init_this_mmu(void)
  
  		if (map)

linear_map_top = map_mem_in_cams(linear_map_top,
-num_cams, true, true);
+num_cams, false, true);
}
  #endif
  
@@ -766,7 +766,7 @@ void setup_initial_memory_limit(phys_addr_t first_memblock_base,

num_cams = (mfspr(SPRN_TLB1CFG) & TLBnCFG_N_ENTRY) / 4;
  
  		linear_sz = map_mem_in_cams(first_memblock_size, num_cams,

-   false, true);
+   true, true);
  
  		ppc64_rma_size = min_t(u64, linear_sz, 0x4000);

    } else

Tested-by: Christian Zigotzky 

Thanks


Re: [PASEMI] Nemo board doesn't recognize any ATA disks with the pci-v5.16 updates

2021-11-12 Thread Christian Zigotzky

Am 12.11.21 um 16:01 schrieb Christian Zigotzky:

Am 12.11.21 um 15:46 schrieb Marc Zyngier:

On Fri, 12 Nov 2021 14:15:18 +,
Christian Zigotzky  wrote:

On 12 November 2021 at 02:41 pm, Marc Zyngier wrote:

On Fri, 12 Nov 2021 09:40:30 +,
Christian Zigotzky  wrote:

On 11 November 2021 at 06:39 pm, Marc Zyngier wrote:

On Wed, 10 Nov 2021 18:07:24 +,
Christian Zigotzky  wrote:

On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:

Hello,

The Nemo board [1] doesn't recognize any ATA disks with the

pci-v5.16 updates [2].

Error messages:

ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)

I was able to revert the new pci-v5.16 updates [2]. After a new

compiling, the kernel recognize all ATA disks correctly.

Could you please check the pci-v5.16 updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4 



Hi All,

Many thanks for your nice responses.

I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd
(of/irq: Allow matching of an interrupt-map local to an interrupt
controller) [2] is the first bad commit.

Can you please give the following hack a go and post the result
(including the full dmesg)?

Thanks,

M.
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 32be5a03951f..8cf0cc9b7caf 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -156,14 +156,15 @@ int of_irq_parse_raw(const __be32 *addr, 
struct of_phandle_args *out_irq)
  /* Now start the actual "proper" walk of the interrupt 
tree */

    while (ipar != NULL) {
+    bool intc = of_property_read_bool(ipar, 
"interrupt-controller");

+
    /*
 * Now check if cursor is an interrupt-controller and
 * if it is then we are done, unless there is an
 * interrupt-map which takes precedence.
 */
    imap = of_get_property(ipar, "interrupt-map", );
-    if (imap == NULL &&
-    of_property_read_bool(ipar, "interrupt-controller")) {
+    if (imap == NULL && intc) {
    pr_debug(" -> got it !\n");
    return 0;
    }
@@ -244,8 +245,14 @@ int of_irq_parse_raw(const __be32 *addr, 
struct of_phandle_args *out_irq)

  pr_debug(" -> imaplen=%d\n", imaplen);
    }
-    if (!match)
+    if (!match) {
+    if (intc) {
+    pr_info("%pOF interrupt-map failed, using 
interrupt-controller\n", ipar);

+    return 0;
+    }
+
    goto fail;
+    }
  /*
 * Successfully parsed an interrrupt-map translation; 
copy new



The detecting of the ATA disks works with this patch! Well done!
Thanks a lot!

Thanks for testing it. I'll turn that into a proper patch.

M.


Could you please explain your patch?

Please refer to the commit message[1].


I am not a developer. I work for the A-EON Linux FLS.

I have no idea what this is, unfortunately.

M.

[1] https://lore.kernel.org/r/2022143644.434995-1-...@kernel.org


FLS: First Level Support (IT customer support)
SLS: Second Level Support (administrators)
TLS: Third Level Support (developers -> you)

I have to explain our customers why the kernel doesn't detect their 
ATA disks anymore. :-D But it is fixed and I don't need to explain it.


Thanks a lot for your help.

- Christian

Typos


Re: [PASEMI] Nemo board doesn't recognize any ATA disks with the pci-v5.16 updates

2021-11-12 Thread Christian Zigotzky

Am 12.11.21 um 15:46 schrieb Marc Zyngier:

On Fri, 12 Nov 2021 14:15:18 +,
Christian Zigotzky  wrote:

On 12 November 2021 at 02:41 pm, Marc Zyngier wrote:

On Fri, 12 Nov 2021 09:40:30 +,
Christian Zigotzky  wrote:

On 11 November 2021 at 06:39 pm, Marc Zyngier wrote:

On Wed, 10 Nov 2021 18:07:24 +,
Christian Zigotzky  wrote:

On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:

Hello,

The Nemo board [1] doesn't recognize any ATA disks with the

pci-v5.16 updates [2].

Error messages:

ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)

I was able to revert the new pci-v5.16 updates [2]. After a new

compiling, the kernel recognize all ATA disks correctly.

Could you please check the pci-v5.16 updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2]

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4

Hi All,

Many thanks for your nice responses.

I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd
(of/irq: Allow matching of an interrupt-map local to an interrupt
controller) [2] is the first bad commit.

Can you please give the following hack a go and post the result
(including the full dmesg)?

Thanks,

M.
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 32be5a03951f..8cf0cc9b7caf 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -156,14 +156,15 @@ int of_irq_parse_raw(const __be32 *addr, struct 
of_phandle_args *out_irq)
/* Now start the actual "proper" walk of the interrupt tree */
while (ipar != NULL) {
+   bool intc = of_property_read_bool(ipar, "interrupt-controller");
+
/*
 * Now check if cursor is an interrupt-controller and
 * if it is then we are done, unless there is an
 * interrupt-map which takes precedence.
 */
imap = of_get_property(ipar, "interrupt-map", );
-   if (imap == NULL &&
-   of_property_read_bool(ipar, "interrupt-controller")) {
+   if (imap == NULL && intc) {
pr_debug(" -> got it !\n");
return 0;
}
@@ -244,8 +245,14 @@ int of_irq_parse_raw(const __be32 *addr, struct 
of_phandle_args *out_irq)
pr_debug(" -> imaplen=%d\n", imaplen);
}
-   if (!match)
+   if (!match) {
+   if (intc) {
+   pr_info("%pOF interrupt-map failed, using 
interrupt-controller\n", ipar);
+   return 0;
+   }
+
goto fail;
+   }
/*
 * Successfully parsed an interrrupt-map translation; copy new


The detecting of the ATA disks works with this patch! Well done!
Thanks a lot!

Thanks for testing it. I'll turn that into a proper patch.

M.


Could you please explain your patch?

Please refer to the commit message[1].


I am not a developer. I work for the A-EON Linux FLS.

I have no idea what this is, unfortunately.

M.

[1] https://lore.kernel.org/r/2022143644.434995-1-...@kernel.org


FLS: First Level Support (IT customer support)
SLS: Second Level Support (administrators)
TLS: Third Level Support (developers -> you)

I have to explain to our customer why the kernel doesn't their ATA disk 
anymore. :-D But it is fixed and I don't need to explain it.


Thanks a lot for your help.

- Christian


Re: [PASEMI] Nemo board doesn't recognize any ATA disks with the pci-v5.16 updates

2021-11-12 Thread Christian Zigotzky

On 12 November 2021 at 02:41 pm, Marc Zyngier wrote:

On Fri, 12 Nov 2021 09:40:30 +,
Christian Zigotzky  wrote:

On 11 November 2021 at 06:39 pm, Marc Zyngier wrote:

On Wed, 10 Nov 2021 18:07:24 +,
Christian Zigotzky  wrote:

On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:

Hello,

The Nemo board [1] doesn't recognize any ATA disks with the

pci-v5.16 updates [2].

Error messages:

ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)

I was able to revert the new pci-v5.16 updates [2]. After a new

compiling, the kernel recognize all ATA disks correctly.

Could you please check the pci-v5.16 updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2]

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4

Hi All,

Many thanks for your nice responses.

I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd
(of/irq: Allow matching of an interrupt-map local to an interrupt
controller) [2] is the first bad commit.

Can you please give the following hack a go and post the result
(including the full dmesg)?

Thanks,

M.
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 32be5a03951f..8cf0cc9b7caf 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -156,14 +156,15 @@ int of_irq_parse_raw(const __be32 *addr, struct 
of_phandle_args *out_irq)
/* Now start the actual "proper" walk of the interrupt tree */
while (ipar != NULL) {
+   bool intc = of_property_read_bool(ipar, "interrupt-controller");
+
/*
 * Now check if cursor is an interrupt-controller and
 * if it is then we are done, unless there is an
 * interrupt-map which takes precedence.
 */
imap = of_get_property(ipar, "interrupt-map", );
-   if (imap == NULL &&
-   of_property_read_bool(ipar, "interrupt-controller")) {
+   if (imap == NULL && intc) {
pr_debug(" -> got it !\n");
return 0;
}
@@ -244,8 +245,14 @@ int of_irq_parse_raw(const __be32 *addr, struct 
of_phandle_args *out_irq)
pr_debug(" -> imaplen=%d\n", imaplen);
}
-   if (!match)
+   if (!match) {
+   if (intc) {
+   pr_info("%pOF interrupt-map failed, using 
interrupt-controller\n", ipar);
+   return 0;
+   }
+
goto fail;
+   }
/*
 * Successfully parsed an interrrupt-map translation; copy new


The detecting of the ATA disks works with this patch! Well done!
Thanks a lot!

Thanks for testing it. I'll turn that into a proper patch.

M.

Could you please explain your patch? I am not a developer. I work for 
the A-EON Linux FLS.


- Christian


Re: [PASEMI] Nemo board doesn't recognize any ATA disks with the pci-v5.16 updates

2021-11-12 Thread Christian Zigotzky

On 12 November 2021 at 11:11 am, Christian Zigotzky wrote:

On 12 November 2021 at 10:40 am, Christian Zigotzky wrote:

On 11 November 2021 at 06:39 pm, Marc Zyngier wrote:

On Wed, 10 Nov 2021 18:07:24 +,
Christian Zigotzky  wrote:

On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:

Hello,

The Nemo board [1] doesn't recognize any ATA disks with the

pci-v5.16 updates [2].

Error messages:

ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)

I was able to revert the new pci-v5.16 updates [2]. After a new

compiling, the kernel recognize all ATA disks correctly.

Could you please check the pci-v5.16 updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4 



Hi All,

Many thanks for your nice responses.

I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd
(of/irq: Allow matching of an interrupt-map local to an interrupt
controller) [2] is the first bad commit.

Can you please give the following hack a go and post the result
(including the full dmesg)?

Thanks,

M.
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 32be5a03951f..8cf0cc9b7caf 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -156,14 +156,15 @@ int of_irq_parse_raw(const __be32 *addr, 
struct of_phandle_args *out_irq)

    /* Now start the actual "proper" walk of the interrupt tree */
  while (ipar != NULL) {
+    bool intc = of_property_read_bool(ipar, 
"interrupt-controller");

+
  /*
   * Now check if cursor is an interrupt-controller and
   * if it is then we are done, unless there is an
   * interrupt-map which takes precedence.
   */
  imap = of_get_property(ipar, "interrupt-map", );
-    if (imap == NULL &&
-    of_property_read_bool(ipar, "interrupt-controller")) {
+    if (imap == NULL && intc) {
  pr_debug(" -> got it !\n");
  return 0;
  }
@@ -244,8 +245,14 @@ int of_irq_parse_raw(const __be32 *addr, struct 
of_phandle_args *out_irq)

    pr_debug(" -> imaplen=%d\n", imaplen);
  }
-    if (!match)
+    if (!match) {
+    if (intc) {
+    pr_info("%pOF interrupt-map failed, using 
interrupt-controller\n", ipar);

+    return 0;
+    }
+
  goto fail;
+    }
    /*
   * Successfully parsed an interrrupt-map translation; copy 
new


The detecting of the ATA disks works with this patch! Well done! 
Thanks a lot!


Sorry, I have read the patch more carefully and I have seen that it is 
an analyse patch. It's not a fix. I was too quick with my joy.


- Christian

OK, perhaps a fix after all.

if (imap == NULL && intc) // If the return value isn't NULL then there 
isn't an interrupt-map. That means, this part was successfully (&&) and 
"intc" will evaluated (Testing of interrupt-controller). OK, perhaps it 
is a fix after all.


Output:

[    0.072659] OF: /pxp@0,e000 interrupt-map failed, using 
interrupt-controller
[    0.072682] OF: /pxp@0,e000 interrupt-map failed, using 
interrupt-controller
[    0.072701] OF: /pxp@0,e000 interrupt-map failed, using 
interrupt-controller
[    0.072720] OF: /pxp@0,e000 interrupt-map failed, using 
interrupt-controller
[    0.072741] OF: /pxp@0,e000 interrupt-map failed, using 
interrupt-controller
[    0.072762] OF: /pxp@0,e000 interrupt-map failed, using 
interrupt-controller
[    0.072784] OF: /pxp@0,e000 interrupt-map failed, using 
interrupt-controller
[    0.072805] OF: /pxp@0,e000 interrupt-map failed, using 
interrupt-controller
[    0.072824] OF: /pxp@0,e000 interrupt-map failed, using 
interrupt-controller
[    0.072843] OF: /pxp@0,e000 interrupt-map failed, using 
interrupt-controller
[    0.072861] OF: /pxp@0,e000 interrupt-map failed, using 
interrupt-controller
[    0.072929] OF: /pxp@0,e000 interrupt-map failed, using 
interrupt-controller
[    0.073167] OF: /pxp@0,e000 interrupt-map failed, using 
interrupt-controller
[    0.073191] OF: /pxp@0,e000 interrupt-map failed, using 
interrupt-controller
[    0.073211] OF: /pxp@0,e000 interrupt-map failed, using 
interrupt-controller
[    0.073232] OF: /pxp@0,e000 interrupt-map failed, using 
interrupt-controller
[    0.073252] OF: /pxp@0,e000 interrupt-map failed, using 
interrupt-controller
[    0.073272] OF: /pxp@0,e000 interrupt-map failed, using 
interrupt-controller
[    0.073292] OF: /pxp@0,e000 interrupt-map fa

Re: [PASEMI] Nemo board doesn't recognize any ATA disks with the pci-v5.16 updates

2021-11-12 Thread Christian Zigotzky

On 12 November 2021 at 10:40 am, Christian Zigotzky wrote:

On 11 November 2021 at 06:39 pm, Marc Zyngier wrote:

On Wed, 10 Nov 2021 18:07:24 +,
Christian Zigotzky  wrote:

On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:

Hello,

The Nemo board [1] doesn't recognize any ATA disks with the

pci-v5.16 updates [2].

Error messages:

ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)

I was able to revert the new pci-v5.16 updates [2]. After a new

compiling, the kernel recognize all ATA disks correctly.

Could you please check the pci-v5.16 updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4 



Hi All,

Many thanks for your nice responses.

I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd
(of/irq: Allow matching of an interrupt-map local to an interrupt
controller) [2] is the first bad commit.

Can you please give the following hack a go and post the result
(including the full dmesg)?

Thanks,

M.
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 32be5a03951f..8cf0cc9b7caf 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -156,14 +156,15 @@ int of_irq_parse_raw(const __be32 *addr, struct 
of_phandle_args *out_irq)

    /* Now start the actual "proper" walk of the interrupt tree */
  while (ipar != NULL) {
+    bool intc = of_property_read_bool(ipar, 
"interrupt-controller");

+
  /*
   * Now check if cursor is an interrupt-controller and
   * if it is then we are done, unless there is an
   * interrupt-map which takes precedence.
   */
  imap = of_get_property(ipar, "interrupt-map", );
-    if (imap == NULL &&
-    of_property_read_bool(ipar, "interrupt-controller")) {
+    if (imap == NULL && intc) {
  pr_debug(" -> got it !\n");
  return 0;
  }
@@ -244,8 +245,14 @@ int of_irq_parse_raw(const __be32 *addr, struct 
of_phandle_args *out_irq)

    pr_debug(" -> imaplen=%d\n", imaplen);
  }
-    if (!match)
+    if (!match) {
+    if (intc) {
+    pr_info("%pOF interrupt-map failed, using 
interrupt-controller\n", ipar);

+    return 0;
+    }
+
  goto fail;
+    }
    /*
   * Successfully parsed an interrrupt-map translation; copy new

The detecting of the ATA disks works with this patch! Well done! 
Thanks a lot!


Sorry, I have read the patch more carefully and I have seen that it is 
an analyse patch. It's not a fix. I was too quick with my joy.


- Christian


Re: [PASEMI] Nemo board doesn't recognize any ATA disks with the pci-v5.16 updates

2021-11-12 Thread Christian Zigotzky

On 11 November 2021 at 06:39 pm, Marc Zyngier wrote:

On Wed, 10 Nov 2021 18:07:24 +,
Christian Zigotzky  wrote:

On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:

Hello,

The Nemo board [1] doesn't recognize any ATA disks with the

pci-v5.16 updates [2].

Error messages:

ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)

I was able to revert the new pci-v5.16 updates [2]. After a new

compiling, the kernel recognize all ATA disks correctly.

Could you please check the pci-v5.16 updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2]

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4

Hi All,

Many thanks for your nice responses.

I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd
(of/irq: Allow matching of an interrupt-map local to an interrupt
controller) [2] is the first bad commit.

Can you please give the following hack a go and post the result
(including the full dmesg)?

Thanks,

M.
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 32be5a03951f..8cf0cc9b7caf 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -156,14 +156,15 @@ int of_irq_parse_raw(const __be32 *addr, struct 
of_phandle_args *out_irq)
  
  	/* Now start the actual "proper" walk of the interrupt tree */

while (ipar != NULL) {
+   bool intc = of_property_read_bool(ipar, "interrupt-controller");
+
/*
 * Now check if cursor is an interrupt-controller and
 * if it is then we are done, unless there is an
 * interrupt-map which takes precedence.
 */
imap = of_get_property(ipar, "interrupt-map", );
-   if (imap == NULL &&
-   of_property_read_bool(ipar, "interrupt-controller")) {
+   if (imap == NULL && intc) {
pr_debug(" -> got it !\n");
return 0;
}
@@ -244,8 +245,14 @@ int of_irq_parse_raw(const __be32 *addr, struct 
of_phandle_args *out_irq)
  
  			pr_debug(" -> imaplen=%d\n", imaplen);

}
-   if (!match)
+   if (!match) {
+   if (intc) {
+   pr_info("%pOF interrupt-map failed, using 
interrupt-controller\n", ipar);
+   return 0;
+   }
+
goto fail;
+   }
  
  		/*

 * Successfully parsed an interrrupt-map translation; copy new

The detecting of the ATA disks works with this patch! Well done! Thanks 
a lot!


dmesg:

[    0.00] hash-mmu: Page sizes from device-tree:
[    0.00] hash-mmu: base_shift=12: shift=12, sllp=0x, 
avpnm=0x, tlbiel=1, penc=0
[    0.00] hash-mmu: base_shift=16: shift=16, sllp=0x0110, 
avpnm=0x, tlbiel=1, penc=3
[    0.00] hash-mmu: base_shift=20: shift=20, sllp=0x0030, 
avpnm=0x, tlbiel=0, penc=31
[    0.00] hash-mmu: base_shift=24: shift=24, sllp=0x0100, 
avpnm=0x0001, tlbiel=0, penc=0
[    0.00] Page orders: linear mapping = 24, virtual = 12, io = 12, 
vmemmap = 24

[    0.00] Using 1TB segments
[    0.00] hash-mmu: Initializing hash mmu with SLB
[    0.00] Linux version 
5.16.0-a6_A-EON_X1000_Nemo-12267-gdebe436e77c7-dirty 
(christ...@cc-build-machine.a-eon.tld) (powerpc-linux-gnu-gcc (Ubuntu 
7.5.0-3ubuntu1~18.04) 7.5.0, GNU ld (GNU Binutils for Ubuntu) 2.30) #1 
SMP Fri Nov 12 09:30:39 CET 2021

[    0.00] IOBMAP L2 allocated at: (ptrval)
[    0.00] ioremap() called early from 
.iommu_init_early_pasemi+0x10c/0x244. Use early_ioremap() instead

[    0.00] Using A-EON Amigaone X1000 machine description
[    0.00] Found legacy serial port 0 for /pxp@0,e000/serial@1d
[    0.00]   port=7f03f8, taddr=fcff03f8, irq=0, clk=1, 
speed=115200

[    0.00] Found legacy serial port 1 for /pxp@0,e000/serial@1d,1
[    0.00]   port=7f02f8, taddr=fcff02f8, irq=0, clk=1, 
speed=115200

[    0.00] CPU maps initialized for 1 thread per core
[    0.00]  (thread shift is 0)
[    0.00] Allocated 2320 bytes for 2 pacas
[    0.00] -
[    0.00] phys_mem_size = 0x2
[    0.00] dcache_bsize  = 0x40
[    0.00] icache_bsize  = 0x40
[    0.00] cpu_features  = 0x01401182
[    0.00]   possible    = 0x000ffbebb18f
[    0.00]   always  = 0x0180
[    0.00] cpu_user_features = 0xdc0008

Re: [PASEMI] Nemo board doesn't recognize any ATA disks with the pci-v5.16 updates

2021-11-11 Thread Christian Zigotzky

On 11 November 2021 at 12:24 pm, Marc Zyngier wrote:

On Thu, 11 Nov 2021 10:44:30 +,
Christian Zigotzky  wrote:

On 11 November 2021 at 11:20 am, Marc Zyngier wrote:

On Thu, 11 Nov 2021 07:47:08 +,
Christian Zigotzky  wrote:

On 11 November 2021 at 08:13 am, Marc Zyngier wrote:

On Thu, 11 Nov 2021 05:24:52 +,
Christian Zigotzky  wrote:

Hello Marc,

Here you are:
https://forum.hyperion-entertainment.com/viewtopic.php?p=54406#p54406

This is not what I asked. I need the actual source file, or at the
very least the compiled object (the /sys/firmware/fdt file, for
example). Not an interpretation that I can't feed to the kernel.

Without this, I can't debug your problem.


We are very happy to have the patch for reverting the bad commit
because we want to test the new PASEMI i2c driver with support for the
Apple M1 [1] on our Nemo boards.

You can revert the patch on your own. At this stage, we're not blindly
reverting things in the tree, but instead trying to understand what
is happening on your particular system.

Thanks,

M.


I added a download link for the fdt file to the post [1]. Please read
also Darren's comments in this post.

Am I right in understanding that the upstream kernel does not support
the machine out of the box, and that you actually have to apply out of
tree patches to make it work?

No, you aren't right. The upstream kernel supports the Nemo board out
of the box. [1]

That's not the way I interpret Darren's comments, but you surely know
better than I do.

I'll try to come up with something for you to test shortly.

M.


Great! Thanks a lot for your help!

- Christian


Re: [PASEMI] Nemo board doesn't recognize any ATA disks with the pci-v5.16 updates

2021-11-11 Thread Christian Zigotzky

On 11 November 2021 at 11:20 am, Marc Zyngier wrote:

On Thu, 11 Nov 2021 07:47:08 +,
Christian Zigotzky  wrote:

On 11 November 2021 at 08:13 am, Marc Zyngier wrote:

On Thu, 11 Nov 2021 05:24:52 +,
Christian Zigotzky  wrote:

Hello Marc,

Here you are:
https://forum.hyperion-entertainment.com/viewtopic.php?p=54406#p54406

This is not what I asked. I need the actual source file, or at the
very least the compiled object (the /sys/firmware/fdt file, for
example). Not an interpretation that I can't feed to the kernel.

Without this, I can't debug your problem.


We are very happy to have the patch for reverting the bad commit
because we want to test the new PASEMI i2c driver with support for the
Apple M1 [1] on our Nemo boards.

You can revert the patch on your own. At this stage, we're not blindly
reverting things in the tree, but instead trying to understand what
is happening on your particular system.

Thanks,

M.


I added a download link for the fdt file to the post [1]. Please read
also Darren's comments in this post.


Am I right in understanding that the upstream kernel does not support
the machine out of the box, and that you actually have to apply out of
tree patches to make it work?
No, you aren't right. The upstream kernel supports the Nemo board out of 
the box. [1]


- Christian

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep=Darren+Stevens


Re: [PASEMI] Nemo board doesn't recognize any ATA disks with the pci-v5.16 updates

2021-11-10 Thread Christian Zigotzky

On 11 November 2021 at 08:13 am, Marc Zyngier wrote:

On Thu, 11 Nov 2021 05:24:52 +,
Christian Zigotzky  wrote:

On 10 November 2021 at 08:09 pm, Marc Zyngier wrote:

HI all,

On Wed, 10 Nov 2021 18:41:06 +,
Bjorn Helgaas  wrote:

On Wed, Nov 10, 2021 at 07:07:24PM +0100, Christian Zigotzky wrote:

On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:

Hello,

The Nemo board [1] doesn't recognize any ATA disks with the pci-v5.16

updates [2].

Error messages:

ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)

I was able to revert the new pci-v5.16 updates [2]. After a new

compiling, the kernel recognize all ATA disks correctly.

Could you please check the pci-v5.16 updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4

Hi All,

Many thanks for your nice responses.

I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd (of/irq:
Allow matching of an interrupt-map local to an interrupt controller) [2] is
the first bad commit.

I was able to revert the first bad commit [1]. After a new compiling, the
kernel detects all ATA disks without any problems.

I created a patch for an easy reverting the bad commit [1]. With this patch
we can do further our kernel tests.

Could you please check the first bad commit [2]?

Thanks,
Christian

[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=54398#p54398
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0412841812265734c306ba5ef8088bcb64d5d3bd

[+ Marc Zyngier, Alyssa Rosenzweig, Lorenzo Pieralisi, and Rob Herring
because of the first bad commit]

Thank you very much for the bisection and for also testing the revert!

It's easy enough to revert 041284181226 ("of/irq: Allow matching of an
interrupt-map local to an interrupt controller"), and it seems like
that's what we need to do.  I have it tentatively queued up.

That commit was part of the new support for the Apple M1 PCIe
interface, and I don't know what effect a revert will have on that
support.  Marc, Alyssa?

It is going to badly break the M1 support, as we won't be able to take
interrupts to detect that the PCIe link is up.

Before we apply a full blown revert and decide that this isn't
workable (and revert the whole M1 PCIe series, because they are
otherwise somewhat pointless), I'd like to understand *what* breaks
exactly.

Christian, could you point me to the full DT that this machine uses?
This would help understanding what goes wrong, and cook something for
you to test.

Thanks,

M.


Hello Marc,

Here you are:
https://forum.hyperion-entertainment.com/viewtopic.php?p=54406#p54406

This is not what I asked. I need the actual source file, or at the
very least the compiled object (the /sys/firmware/fdt file, for
example). Not an interpretation that I can't feed to the kernel.

Without this, I can't debug your problem.


We are very happy to have the patch for reverting the bad commit
because we want to test the new PASEMI i2c driver with support for the
Apple M1 [1] on our Nemo boards.

You can revert the patch on your own. At this stage, we're not blindly
reverting things in the tree, but instead trying to understand what
is happening on your particular system.

Thanks,

M.

I added a download link for the fdt file to the post [1]. Please read 
also Darren's comments in this post.


Thanks

[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=54406#p54406


Re: [PASEMI] Nemo board doesn't recognize any ATA disks with the pci-v5.16 updates

2021-11-10 Thread Christian Zigotzky

On 10 November 2021 at 08:09 pm, Marc Zyngier wrote:

HI all,

On Wed, 10 Nov 2021 18:41:06 +,
Bjorn Helgaas  wrote:

On Wed, Nov 10, 2021 at 07:07:24PM +0100, Christian Zigotzky wrote:

On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:

Hello,

The Nemo board [1] doesn't recognize any ATA disks with the pci-v5.16

updates [2].

Error messages:

ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)

I was able to revert the new pci-v5.16 updates [2]. After a new

compiling, the kernel recognize all ATA disks correctly.

Could you please check the pci-v5.16 updates [2]?

Please find attached the kernel config.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4

Hi All,

Many thanks for your nice responses.

I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd (of/irq:
Allow matching of an interrupt-map local to an interrupt controller) [2] is
the first bad commit.

I was able to revert the first bad commit [1]. After a new compiling, the
kernel detects all ATA disks without any problems.

I created a patch for an easy reverting the bad commit [1]. With this patch
we can do further our kernel tests.

Could you please check the first bad commit [2]?

Thanks,
Christian

[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=54398#p54398
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0412841812265734c306ba5ef8088bcb64d5d3bd

[+ Marc Zyngier, Alyssa Rosenzweig, Lorenzo Pieralisi, and Rob Herring
because of the first bad commit]

Thank you very much for the bisection and for also testing the revert!

It's easy enough to revert 041284181226 ("of/irq: Allow matching of an
interrupt-map local to an interrupt controller"), and it seems like
that's what we need to do.  I have it tentatively queued up.

That commit was part of the new support for the Apple M1 PCIe
interface, and I don't know what effect a revert will have on that
support.  Marc, Alyssa?

It is going to badly break the M1 support, as we won't be able to take
interrupts to detect that the PCIe link is up.

Before we apply a full blown revert and decide that this isn't
workable (and revert the whole M1 PCIe series, because they are
otherwise somewhat pointless), I'd like to understand *what* breaks
exactly.

Christian, could you point me to the full DT that this machine uses?
This would help understanding what goes wrong, and cook something for
you to test.

Thanks,

M.


Hello Marc,

Here you are: 
https://forum.hyperion-entertainment.com/viewtopic.php?p=54406#p54406


We are very happy to have the patch for reverting the bad commit because 
we want to test the new PASEMI i2c driver with support for the Apple M1 
[1] on our Nemo boards.


Thanks for your help,
Christian

[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=54086#p54086



Re: [PASEMI] Nemo board doesn't recognize any ATA disks with the pci-v5.16 updates

2021-11-10 Thread Christian Zigotzky

On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:
> Hello,
>
> The Nemo board [1] doesn't recognize any ATA disks with the pci-v5.16 
updates [2].

>
> Error messages:
>
> ata4.00: gc timeout cmd 0xec
> ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
> ata1.00: gc timeout cmd 0xec
> ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
> ata3.00: gc timeout cmd 0xec
> ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)
>
> I was able to revert the new pci-v5.16 updates [2]. After a new 
compiling, the kernel recognize all ATA disks correctly.

>
> Could you please check the pci-v5.16 updates [2]?
>
> Please find attached the kernel config.
>
> Thanks,
> Christian
>
> [1] https://en.wikipedia.org/wiki/AmigaOne_X1000
> [2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4


Hi All,

Many thanks for your nice responses.

I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd (of/irq: 
Allow matching of an interrupt-map local to an interrupt controller) [2] 
is the first bad commit.


I was able to revert the first bad commit [1]. After a new compiling, 
the kernel detects all ATA disks without any problems.


I created a patch for an easy reverting the bad commit [1]. With this 
patch we can do further our kernel tests.


Could you please check the first bad commit [2]?

Thanks,
Christian

[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=54398#p54398
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0412841812265734c306ba5ef8088bcb64d5d3bd


[+ Marc Zyngier, Alyssa Rosenzweig, Lorenzo Pieralisi, and Rob Herring 
because of the first bad commit]





Re: [PASEMI] Nemo board doesn't recognize any ATA disks with the pci-v5.16 updates

2021-11-09 Thread Christian Zigotzky

On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:
> Hello,
>
> The Nemo board [1] doesn't recognize any ATA disks with the pci-v5.16 
updates [2].

>
> Error messages:
>
> ata4.00: gc timeout cmd 0xec
> ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
> ata1.00: gc timeout cmd 0xec
> ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
> ata3.00: gc timeout cmd 0xec
> ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)
>
> I was able to revert the new pci-v5.16 updates [2]. After a new 
compiling, the kernel recognize all ATA disks correctly.

>
> Could you please check the pci-v5.16 updates [2]?
>
> Please find attached the kernel config.
>
> Thanks,
> Christian
>
> [1] https://en.wikipedia.org/wiki/AmigaOne_X1000
> [2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4 



+ Olof Johansson
+ linux-...@vger.kernel.org


Re: [PATCH] drm/virtio: Fix NULL dereference error in virtio_gpu_poll

2021-11-05 Thread Christian Zigotzky

On 04 November 2021 at 10:42 pm, Vivek Kasireddy wrote:

> When virgl is not enabled, vfpriv pointer would not be allocated.
> Therefore, check for a valid value before dereferencing.
>
> Reported-by: Christian Zigotzky 
> Cc: Gurchetan Singh 
> Cc: Gerd Hoffmann 
> Signed-off-by: Vivek Kasireddy 
> ---
>  drivers/gpu/drm/virtio/virtgpu_drv.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c 
b/drivers/gpu/drm/virtio/virtgpu_drv.c

> index 749db18dcfa2..d86e1ad4a972 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
> @@ -163,10 +163,11 @@ static __poll_t virtio_gpu_poll(struct file *filp,
>  struct drm_file *drm_file = filp->private_data;
>  struct virtio_gpu_fpriv *vfpriv = drm_file->driver_priv;
>  struct drm_device *dev = drm_file->minor->dev;
> +    struct virtio_gpu_device *vgdev = dev->dev_private;
>  struct drm_pending_event *e = NULL;
>  __poll_t mask = 0;
>
> -    if (!vfpriv->ring_idx_mask)
> +    if (!vgdev->has_virgl_3d || !vfpriv || !vfpriv->ring_idx_mask)
>      return drm_poll(filp, wait);
>
>  poll_wait(filp, _file->event_wait, wait);

Tested-by: Christian Zigotzky  [1]

[1] https://i.ibb.co/N1vL5Kd/Kernel-5-16-alpha3-Power-PC.png


Re: [PATCH v2 00/11] Add Apple M1 support to PASemi i2c driver

2021-10-13 Thread Christian Zigotzky

On 09 October 2021 at 03:57 pm, Christian Zigotzky wrote:
> On 09 October 2021 at 12:10 pm, Wolfram Sang wrote:
>>> I still don't have access to any old PASemi hardware but the 
changes from
>>> v1 are pretty small and I expect them to still work. Would still be 
nice

>>> if someone with access to such hardware could give this a quick test.
>> Looks good to me. I will wait a few more days so that people can report
>> their tests. But it will be in the next merge window.
>>
> Series v2:
>
> Tested-by: Christian Zigotzky  [1]
>
> - Christian
>
> [1] 
https://forum.hyperion-entertainment.com/viewtopic.php?p=54213#p54213


Series v2:

Tested-by: Damien Stewart (Hypex) [1]

- Christian

[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=54217#p54217



Re: [PATCH v2 00/11] Add Apple M1 support to PASemi i2c driver

2021-10-09 Thread Christian Zigotzky

On 09 October 2021 at 12:10 pm, Wolfram Sang wrote:

I still don't have access to any old PASemi hardware but the changes from
v1 are pretty small and I expect them to still work. Would still be nice
if someone with access to such hardware could give this a quick test.

Looks good to me. I will wait a few more days so that people can report
their tests. But it will be in the next merge window.


Series v2:

Tested-by: Christian Zigotzky  [1]

- Christian

[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=54213#p54213


Re: Add Apple M1 support to PASemi i2c driver

2021-10-09 Thread Christian Zigotzky
Olof,

Thank you for the hint.

I think I have found them.

Link: https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=266104

Mbox: https://patchwork.ozlabs.org/series/266104/mbox/

$ wget -O mbox https://patchwork.ozlabs.org/series/266104/mbox/
$ git am mbox

Thanks,
Christian

On 8. Oct 2021, at 22:47, Olof Johansson  wrote:

Christian,

Self-service available on lore:
https://lore.kernel.org/all/20211008163532.75569-1-s...@svenpeter.dev/

There are links on there to download a whole thread as an mbox if needed.


-Olof

On Fri, Oct 8, 2021 at 1:20 PM Christian Zigotzky
 wrote:

Hi Michael,

Do you have a mbox link for the v2 changes?

I would like to test them on my AmigaOne X1000.

Thanks,
Christian

On 27. Sep 2021, at 09:58, Michael Ellerman  wrote:

Christian, the whole series is downloadable as a single mbox here:

https://patchwork.ozlabs.org/series/264134/mbox/

Save that to a file and apply with `git am`.

eg:

$ wget -O mbox https://patchwork.ozlabs.org/series/264134/mbox/
$ git am mbox

It applies cleanly on v5.15-rc3.

cheers


Re: Add Apple M1 support to PASemi i2c driver

2021-10-08 Thread Christian Zigotzky
Hi Michael,

Do you have a mbox link for the v2 changes?

I would like to test them on my AmigaOne X1000.

Thanks,
Christian

On 27. Sep 2021, at 09:58, Michael Ellerman  wrote:

Christian, the whole series is downloadable as a single mbox here:

https://patchwork.ozlabs.org/series/264134/mbox/

Save that to a file and apply with `git am`.

eg:

$ wget -O mbox https://patchwork.ozlabs.org/series/264134/mbox/
$ git am mbox

It applies cleanly on v5.15-rc3.

cheers


Re: Add Apple M1 support to PASemi i2c driver

2021-10-04 Thread Christian Zigotzky


> On 3. Oct 2021, at 16:36, Sven Peter  wrote:
> 
> Hi,
> 
> 
>> On Fri, Oct 1, 2021, at 06:47, Christian Zigotzky wrote:
>>> On 27 September 2021 at 07:39 am, Sven Peter wrote:
>>> Hi Christian,
>>> 
>>> Thanks already for volunteering to test this!
>>> 
>> Hello Sven,
>> 
>> Damien (Hypex) has successfully tested the RC3 of kernel 5.15 with your 
>> modified i2c driver on his Nemo board yesterday. [1]
> 
> Thanks a lot, that's great to hear!
> If he wants to I can credit him with a Tested-by tag in the commit message,
> see e.g. 
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes.
> 
> 
> Best,
> 
> 
> Sven

Hi Sven,

Unfortunately Damien has found an issue. [1]

Output of i2cdetect -l with the default RC3 of kernel 5.15 without your 
modifications:

2c-0i2c Radeon i2c bit bus 0x90 I2C adapter
i2c-1   i2c Radeon i2c bit bus 0x91 I2C adapter
i2c-2   i2c Radeon i2c bit bus 0x92 I2C adapter
i2c-3   i2c Radeon i2c bit bus 0x93 I2C adapter
i2c-4   i2c Radeon i2c bit bus 0x94 I2C adapter
i2c-5   i2c Radeon i2c bit bus 0x95 I2C adapter
i2c-6   i2c Radeon i2c bit bus 0x96 I2C adapter
i2c-7   i2c Radeon i2c bit bus 0x97 I2C adapter
i2c-8   i2c PA Semi SMBus adapter at 0x800200   I2C adapter
i2c-9   i2c PA Semi SMBus adapter at 0x800240   I2C adapter
i2c-10  i2c PA Semi SMBus adapter at 0x800280   I2C adapter

Output of i2cdetect -l with your modifications:

i2c-0   i2c Radeon i2c bit bus 0x90 I2C adapter
i2c-1   i2c Radeon i2c bit bus 0x91 I2C adapter
i2c-2   i2c Radeon i2c bit bus 0x92 I2C adapter
i2c-3   i2c Radeon i2c bit bus 0x93 I2C adapter
i2c-4   i2c Radeon i2c bit bus 0x94 I2C adapter
i2c-5   i2c Radeon i2c bit bus 0x95 I2C adapter
i2c-6   i2c Radeon i2c bit bus 0x96 I2C adapter
i2c-7   i2c Radeon i2c bit bus 0x97 I2C adapter
i2c-8   i2c PA Semi SMBus adapter at 0x(ptrval) I2C 
adapter
i2c-9   i2c PA Semi SMBus adapter at 0x(ptrval) I2C 
adapter
i2c-10  i2c PA Semi SMBus adapter at 0x(ptrval) I2C 
adapter

Please check the outputs.

Thanks,
Christian

[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=54165#p54165

Re: Add Apple M1 support to PASemi i2c driver

2021-10-04 Thread Christian Zigotzky
Hi Sven,

Unfortunately Damien has found an issue. [1]

Output of i2cdetect -l with the default RC3 of kernel 5.15 without your 
modifications:

2c-0i2c Radeon i2c bit bus 0x90 I2C adapter
i2c-1   i2c Radeon i2c bit bus 0x91 I2C adapter
i2c-2   i2c Radeon i2c bit bus 0x92 I2C adapter
i2c-3   i2c Radeon i2c bit bus 0x93 I2C adapter
i2c-4   i2c Radeon i2c bit bus 0x94 I2C adapter
i2c-5   i2c Radeon i2c bit bus 0x95 I2C adapter
i2c-6   i2c Radeon i2c bit bus 0x96 I2C adapter
i2c-7   i2c Radeon i2c bit bus 0x97 I2C adapter
i2c-8   i2c PA Semi SMBus adapter at 0x800200   I2C adapter
i2c-9   i2c PA Semi SMBus adapter at 0x800240   I2C adapter
i2c-10  i2c PA Semi SMBus adapter at 0x800280   I2C adapter

Output of i2cdetect -l with your modifications:

i2c-0   i2c Radeon i2c bit bus 0x90 I2C adapter
i2c-1   i2c Radeon i2c bit bus 0x91 I2C adapter
i2c-2   i2c Radeon i2c bit bus 0x92 I2C adapter
i2c-3   i2c Radeon i2c bit bus 0x93 I2C adapter
i2c-4   i2c Radeon i2c bit bus 0x94 I2C adapter
i2c-5   i2c Radeon i2c bit bus 0x95 I2C adapter
i2c-6   i2c Radeon i2c bit bus 0x96 I2C adapter
i2c-7   i2c Radeon i2c bit bus 0x97 I2C adapter
i2c-8   i2c PA Semi SMBus adapter at 0x(ptrval) I2C 
adapter
i2c-9   i2c PA Semi SMBus adapter at 0x(ptrval) I2C 
adapter
i2c-10  i2c PA Semi SMBus adapter at 0x(ptrval) I2C 
adapter

Please check the outputs.

Thanks,
Christian

[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=54165#p54165


Re: Add Apple M1 support to PASemi i2c driver

2021-10-03 Thread Christian Zigotzky

On 03 October 2021 at 04:36 pm, Sven Peter wrote:
> Hi,
>
>
> On Fri, Oct 1, 2021, at 06:47, Christian Zigotzky wrote:
>> On 27 September 2021 at 07:39 am, Sven Peter wrote:
>>  > Hi Christian,
>>  >
>>  > Thanks already for volunteering to test this!
>>  >
>> Hello Sven,
>>
>> Damian (Hypex) has successfully tested the RC3 of kernel 5.15 with your
>> modified i2c driver on his Nemo board yesterday. [1]
>
> Thanks a lot, that's great to hear!
> If he wants to I can credit him with a Tested-by tag in the commit 
message,
> see e.g. 
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes.

>
>
> Best,
>
>
> Sven

Hello Sven,

We are still testing your i2c modifications. [1]
Please wait a litte bit till we finished our tests.

@Darren
Could you also please check Sven's i2c modifications? He has also 
modified your source code a little bit. [2]


@Olof
Are these i2c modifications OK? Do these work on your P.A. Semi board?

Thanks,
Christian

[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=54138#p54138
[2] https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-January/153195.html


Re: Add Apple M1 support to PASemi i2c driver

2021-09-30 Thread Christian Zigotzky

Typo: Damian

Correct: Damien

On 01 October 2021 at 06:47 am, Christian Zigotzky wrote:

On 27 September 2021 at 07:39 am, Sven Peter wrote:
> Hi Christian,
>
> Thanks already for volunteering to test this!
>
Hello Sven,

Damian (Hypex) has successfully tested the RC3 of kernel 5.15 with 
your modified i2c driver on his Nemo board yesterday. [1]


@Darren
Could you also please check Sven's i2c modifications? He has also 
modified your source code a little bit. [2]


@Olof
Are these i2c modifications OK? Do these work on your P.A. Semi board?

Thanks,
Christian

[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=54098#p54098
[2] 
https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-January/153195.html
[3] Further information about the Nemo board: 
https://en.wikipedia.org/wiki/AmigaOne_X1000
[4] Kernel patches for the Nemo board: 
https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-January/167288.html




Re: Add Apple M1 support to PASemi i2c driver

2021-09-30 Thread Christian Zigotzky

On 27 September 2021 at 07:39 am, Sven Peter wrote:
> Hi Christian,
>
> Thanks already for volunteering to test this!
>
Hello Sven,

Damian (Hypex) has successfully tested the RC3 of kernel 5.15 with your 
modified i2c driver on his Nemo board yesterday. [1]


@Darren
Could you also please check Sven's i2c modifications? He has also 
modified your source code a little bit. [2]


@Olof
Are these i2c modifications OK? Do these work on your P.A. Semi board?

Thanks,
Christian

[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=54098#p54098
[2] https://lists.ozlabs.org/pipermail/linuxppc-dev/2017-January/153195.html
[3] Further information about the Nemo board: 
https://en.wikipedia.org/wiki/AmigaOne_X1000
[4] Kernel patches for the Nemo board: 
https://lists.ozlabs.org/pipermail/linuxppc-dev/2018-January/167288.html


Re: Add Apple M1 support to PASemi i2c driver

2021-09-27 Thread Christian Zigotzky

On 27 September 2021 at 09:58 am, Michael Ellerman wrote:

Wolfram Sang  writes:

Sure, will do that later as well!

But please do it privately. For upstreaming, the patch series you sent
is way better than a single patch.

Christian, the whole series is downloadable as a single mbox here:

https://patchwork.ozlabs.org/series/264134/mbox/

Save that to a file and apply with `git am`.

eg:

  $ wget -O mbox https://patchwork.ozlabs.org/series/264134/mbox/
  $ git am mbox

It applies cleanly on v5.15-rc3.

cheers
I was able to patch it with the instructions above. Thanks! I will 
compile and test the RC3 as soon as possible.


-- Christian


Re: Add Apple M1 support to PASemi i2c driver

2021-09-26 Thread Christian Zigotzky

Hi Sven,

I can't apply your patch 5 (i2c: pasemi: Split pci driver to its own 
file). [1]


Error message:

patching file b/drivers/i2c/busses/i2c-pasemi-core.c (renamed from 
a/drivers/i2c/busses/i2c-pasemi.c)

Hunk #3 FAILED at 344.
1 out of 3 hunks FAILED -- saving rejects to file 
b/drivers/i2c/busses/i2c-pasemi-core.c.rej

patching file b/drivers/i2c/busses/i2c-pasemi-core.h
patching file b/drivers/i2c/busses/i2c-pasemi-pci.c

Please post one patch with all your modifications.

Thanks,
Christian

[1] 
https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-September/234636.html



On 26 September 2021 at 04:55 pm, Christian Zigotzky wrote:

Hi Sven,

Thanks a lot for your nice explanation of the history of the PASemi 
i2c driver.


We are using Nemo boards with 64-bit dual-core PWRficient PA6T-1682M 
CPUs (A-EON AmigaOne X1000). [1]


The RC2 of kernel 5.15 works without any problems on our Nemo boards. [2]

Could you please post all your patches merged in one patch? It's 
easier for me to apply one patch.


Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2] https://forum.hyperion-entertainment.com/viewtopic.php?p=54056#p54056




Add Apple M1 support to PASemi i2c driver

2021-09-26 Thread Christian Zigotzky

Hi Sven,

Thanks a lot for your nice explanation of the history of the PASemi i2c 
driver.


We are using Nemo boards with 64-bit dual-core PWRficient PA6T-1682M 
CPUs (A-EON AmigaOne X1000). [1]


The RC2 of kernel 5.15 works without any problems on our Nemo boards. [2]

Could you please post all your patches merged in one patch? It's easier 
for me to apply one patch.


Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2] https://forum.hyperion-entertainment.com/viewtopic.php?p=54056#p54056


Re: [PATCH 2/2] kvm: rename KVM_MAX_VCPU_ID to, KVM_MAX_VCPU_IDS

2021-09-14 Thread Christian Zigotzky

Hello Juergen,
Hello All,

Since the RC1 of kernel 5.13, -smp 2 and -smp 4 don't work with a 
virtual e5500 QEMU KVM-HV machine anymore. [1]
I see in the serial console, that the uImage doesn't load. I use the 
following QEMU command for booting:


qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 1024 -kernel 
uImage -drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio 
-netdev user,id=mynet0 -device virtio-net,netdev=mynet0 -append "rw 
root=/dev/vda" -device virtio-vga -device virtio-mouse-pci -device 
virtio-keyboard-pci -device pci-ohci,id=newusb -device 
usb-audio,bus=newusb.0 -smp 4


The kernels boot without KVM-HV.

Summary for KVM-HV:

-smp 1 -> works
-smp 2 -> doesn't work
-smp 3 -> works
-smp 4 -> doesn't work

I used -smp 4 before the RC1 of kernel 5.13 because my FSL P5040 BookE 
machine [2] has 4 cores.


Does this patch solve this issue? [3]

Thanks,
Christian

[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-May/229103.html
[2] http://wiki.amiga.org/index.php?title=X5000
[3] 
https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-September/234152.html


Re: [FSL P50x0] lscpu reports wrong values since the RC1 of kernel 5.13

2021-08-27 Thread Christian Zigotzky



> On 26. Aug 2021, at 05:43, Srikar Dronamraju  
> wrote:
> 
> * Christian Zigotzky  [2021-08-16 14:29:21]:
> 
> 
> Hi Christian,
> 
>> I tested the RC6 of kernel 5.14 today and unfortunately the issue still
>> exists. We have figured out that only P5040 SoCs are affected. [1]
>> P5020 SoCs display the correct values.
>> Please check the CPU changes in the PowerPC updates 5.13-1 and 5.13-2.
>> 
> 
> Thanks for reporting the issue.
> Would it be possible to try
> https://lore.kernel.org/linuxppc-dev/20210821092419.167454-3-sri...@linux.vnet.ibm.com/t/#u

Hi Srikar,

This patch works! Thanks a lot!

Cheers,
Christian

> 
> If the above patch is not helping, then can you please collect the output of
> 
> cat /sys/devices/system/cpu/cpu*/topology/core_siblings
> 
> Were all the CPUs online at the time of boot?
> Did we do any CPU online/offline operations post boot?
> 
> If we did CPU online/offline, can you capture the output just after the
> boot along with lscpu output..
> 
> Since this is being seen on few SOCs, can you summarize the difference
> between P5040 and P5020.
>> 
>> [1] https://forum.hyperion-entertainment.com/viewtopic.php?p=53775#p53775
>> 
>> 
>>> On 09 August 2021 um 02:37 pm, Christian Zigotzky wrote:
>>> Hi All,
>>> 
>>> Lscpu reports wrong values [1] since the RC1 of kernel 5.13 on my FSL
>>> P5040 Cyrus+ board (A-EON AmigaOne X5000). [2]
>>> The differences are:
>>> 
>>> Since the RC1 of kernel 5.13 (wrong values):
>>> 
>>> Core(s) per socket: 1
>>> Socket(s): 3
>>> 
> 
> I know that the socket count was off by 1, but I cant explain how its off by
> 2 here.
> 
>>> Before (correct values):
>>> 
>>> Core(s) per socket: 4
>>> Socket(s): 1
>>> 
> 
> -- 
> Thanks and Regards
> Srikar Dronamraju



Re: [FSL P50x0] lscpu reports wrong values since the RC1 of kernel 5.13

2021-08-16 Thread Christian Zigotzky

Hi All,

I tested the RC6 of kernel 5.14 today and unfortunately the issue still 
exists. We have figured out that only P5040 SoCs are affected. [1]

P5020 SoCs display the correct values.
Please check the CPU changes in the PowerPC updates 5.13-1 and 5.13-2.

Thanks,
Christian

[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=53775#p53775


On 09 August 2021 um 02:37 pm, Christian Zigotzky wrote:

Hi All,

Lscpu reports wrong values [1] since the RC1 of kernel 5.13 on my FSL 
P5040 Cyrus+ board (A-EON AmigaOne X5000). [2]

The differences are:

Since the RC1 of kernel 5.13 (wrong values):

Core(s) per socket: 1
Socket(s): 3

Before (correct values):

Core(s) per socket: 4
Socket(s): 1

Through the wrong values, I can't use "-smp 4" with a virtual e5500 
QEMU machine with KVM HV anymore.  [3]

"-smp 3" works with KVM HV.

Maybe the file_load_64 commit from the PowerPC updates 5.13-2 is the 
problem ( powerpc/kexec_file: Use current CPU info while setting up 
FDT). [4]


Or maybe this change (PowerPC updates 5.13-1):

-#ifdef CONFIG_PPC_BOOK3E_64
-    state->ctx_state = exception_enter();
-    if (user_mode(regs))
-    account_cpu_user_entry();
-#endif

---

Or maybe this change (PowerPC updates 5.13-1):

diff --git a/arch/powerpc/include/asm/smp.h 
b/arch/powerpc/include/asm/smp.h

index 7a13bc20f0a0c..03b3d010cbab6 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -31,6 +31,7 @@ extern u32 *cpu_to_phys_id;
 extern bool coregroup_enabled;

 extern int cpu_to_chip_id(int cpu);
+extern int *chip_id_lookup_table;

 #ifdef CONFIG_SMP

@@ -121,6 +122,11 @@ static inline struct cpumask 
*cpu_sibling_mask(int cpu)

 return per_cpu(cpu_sibling_map, cpu);
 }

+static inline struct cpumask *cpu_core_mask(int cpu)
+{
+    return per_cpu(cpu_core_map, cpu);
+}
+
 static inline struct cpumask *cpu_l2_cache_mask(int cpu)
 {
 return per_cpu(cpu_l2_cache_map, cpu);

---

I have found a lot of other changes in the PowerPC updates 5.13-1 
regarding the CPU.


Could you please check the CPU changes in the PowerPC updates 5.13-1 
and 5.13-2?


Please find attached the kernel 5.14-rc5 config.

Thanks,
Christian


[1]

lscpu with the correct values before the RC1 of kernel 5.13:

Architecture: ppc64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Big Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Model: 1.2 (pvr 8024 0012)
Model name: e5500
L1d cache: 128 KiB
L1i cache: 128 KiB
L2 cache: 2 MiB
L3 cache: 2 MiB
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Spec store bypass: Not affected
Vulnerability Spectre v1: Mitigation; __user pointer sanitization
Vulnerability Spectre v2: Mitigation; Branch predictor state flush
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected

---

lscpu with the wrong values since the RC1 of kernel 5.13:

Architecture: ppc64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Big Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 3
Model: 1.2 (pvr 8024 0012)
Model name: e5500
L1d cache: 128 KiB
L1i cache: 128 KiB
L2 cache: 2 MiB
L3 cache: 2 MiB
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Spec store bypass: Not affected
Vulnerability Spectre v1: Mitigation; __user pointer sanitization
Vulnerability Spectre v2: Mitigation; Branch predictor state flush
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected

---

[2] http://wiki.amiga.org/index.php?title=X5000

[3] https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-May/229103.html

[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/arch/powerpc/kexec/file_load_64.c?id=ab159ac569fddf812c0a217d6dbffaa5d93ef88f




Re: FAILED: patch "[PATCH] drm/radeon/ni_dpm: Fix booting bug" failed to apply to 5.13-stable tree

2021-07-19 Thread Christian Zigotzky

On 19 July 2021 04:58 pm, Christian Zigotzky wrote:

On 19 July 2021 at 04:32 pm, Stan Johnson wrote:

On 7/18/21 10:23 PM, Christian Zigotzky wrote:

Hello Stan,

We had the same issue during the 5.14 merge window. Please look in the
following thread:

https://forum.hyperion-entertainment.com/viewtopic.php?p=53511#p53511

There is a patch available. Please try it.

Thanks,
Christian
...

Hello Christian,

Thanks. There were some errors applying the patch, so it wasn't fully
applied (see below). Of course, I'm using 5.13.2, not 5.14, so maybe
that's expected.

The patched 5.13.2 kernel still results in a blank screen while trying
to run wdm. On this attempt, wdm has died (oddly the screen remains
blank; it should display a text login after X dies). The Xorg.0.log
looks reasonable enough.

I tried disabling wdm, then rebooted, logged in at the console and ran
"startx". The screen goes blank, X is running, startx is running:

johnson   1392  0.0  0.2   2572  1452 tty1 S+   08:06   0:00 /bin/sh
/usr/bin/startx
johnson   1414  0.0  0.4   4904  2096 tty1 S+   08:06   0:00 xinit
/etc/X11/xinit/xinitrc -- /etc/X11/xinit/xserverrc :0 vt1 -keeptty -auth
/tmp/serverauth.dJ7lSnzjjo
johnson   1415  1.0  8.2 128436 41924 tty1 Sl   08:06   0:04
/usr/lib/xorg/Xorg -nolisten tcp :0 vt1 -keeptty -auth
/tmp/serverauth.dJ7lSnzjjo

I had to use "kill -KILL" to kill the startx, xinit and Xorg processes.
After those were killed, the screen was still blank, and even though
nothing was running, the load average was still around 1.00 several
minutes later, so something is still taking CPU time:

$ uptime
  08:25:15 up 20 min,  2 users,  load average: 1.00, 1.00, 0.84

I can attempt a git bisect, though that will take some time.

-Stan

--
$ patch -p1
<../v3-drm-radeon-Fix-NULL-dereference-when-updating-memory-stats.patch
patching file drivers/gpu/drm/radeon/radeon_object.c
Hunk #2 FAILED at 76.
Hunk #3 FAILED at 727.
2 out of 3 hunks FAILED -- saving rejects to file
drivers/gpu/drm/radeon/radeon_object.c.rej
patching file drivers/gpu/drm/radeon/radeon_object.h
patching file drivers/gpu/drm/radeon/radeon_ttm.c
Hunk #1 FAILED at 199.
Hunk #2 succeeded at 227 (offset 11 lines).
Hunk #3 succeeded at 275 (offset 11 lines).
Hunk #4 succeeded at 697 (offset 12 lines).
1 out of 4 hunks FAILED -- saving rejects to file
drivers/gpu/drm/radeon/radeon_ttm.c.rej
johnson@mac-server:/data/software/working/linux-5.13.2$ cat
drivers/gpu/drm/radeon/radeon_ttm.c.rej
--- drivers/gpu/drm/radeon/radeon_ttm.c
+++ drivers/gpu/drm/radeon/radeon_ttm.c
@@ -199,7 +199,7 @@ static int radeon_bo_move(struct ttm_buffer_object
*bo, bool evict,
  struct ttm_resource *old_mem = bo->resource;
  struct radeon_device *rdev;
  struct radeon_bo *rbo;
-    int r;
+    int r, old_type;

  if (new_mem->mem_type == TTM_PL_TT) {
  r = radeon_ttm_tt_bind(bo->bdev, bo->ttm, new_mem);

-

Hello Stan,

Greg has the same issue with patching the kernel 5.13 [1]. We have to 
wait for a solution.


- Christian

Stan,

Forget it. It's another issue below.

Sorry,
Christian


[1]

The patch below does not apply to the 5.13-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to .

thanks,

greg k-h

-- original commit in Linus's tree --

>From 293774413a3f519c826d4eb5313ef02e20515700 Mon Sep 17 00:00:00 2001
From: "Gustavo A. R. Silva" 
Date: Sun, 9 May 2021 17:49:26 -0500
Subject: [PATCH] drm/radeon/ni_dpm: Fix booting bug

Create new structure NISLANDS_SMC_SWSTATE_SINGLE, as initialState.levels
and ACPIState.levels are never actually used as flexible arrays. Those
arrays can be used as simple objects of type
NISLANDS_SMC_HW_PERFORMANCE_LEVEL, instead.

Currently, the code fails because flexible array _levels_ in
struct NISLANDS_SMC_SWSTATE doesn't allow for code that access
the first element of initialState.levels and ACPIState.levels
arrays:

drivers/gpu/drm/radeon/ni_dpm.c:
1690 table->initialState.levels[0].mclk.vMPLL_AD_FUNC_CNTL =
1691 cpu_to_be32(ni_pi->clock_registers.mpll_ad_func_cntl);
...
1903:   table->ACPIState.levels[0].mclk.vMPLL_AD_FUNC_CNTL = 
cpu_to_be32(mpll_ad_func_cntl);
1904:   table->ACPIState.levels[0].mclk.vMPLL_AD_FUNC_CNTL_2 = 
cpu_to_be32(mpll_ad_func_cntl_2);


because such element cannot exist without previously allocating
any dynamic memory for it (which never actually happens).

That's why struct NISLANDS_SMC_SWSTATE should only be used as type
for object driverState and new struct SISLANDS_SMC_SWSTATE_SINGLE is
created as type for objects initialState, ACPIState and ULVState.

Also, with the change from one-element array to flexible-array member
in commit 434fb1e7444a ("drm/radeon/nislands_smc.h: Replace one-element
array with flexible-array member in struct NISLANDS_SMC_SWSTATE"), t

FAILED: patch "[PATCH] drm/radeon/ni_dpm: Fix booting bug" failed to apply to 5.13-stable tree

2021-07-19 Thread Christian Zigotzky

On 19 July 2021 at 04:32 pm, Stan Johnson wrote:

On 7/18/21 10:23 PM, Christian Zigotzky wrote:

Hello Stan,

We had the same issue during the 5.14 merge window. Please look in the
following thread:

https://forum.hyperion-entertainment.com/viewtopic.php?p=53511#p53511

There is a patch available. Please try it.

Thanks,
Christian
...

Hello Christian,

Thanks. There were some errors applying the patch, so it wasn't fully
applied (see below). Of course, I'm using 5.13.2, not 5.14, so maybe
that's expected.

The patched 5.13.2 kernel still results in a blank screen while trying
to run wdm. On this attempt, wdm has died (oddly the screen remains
blank; it should display a text login after X dies). The Xorg.0.log
looks reasonable enough.

I tried disabling wdm, then rebooted, logged in at the console and ran
"startx". The screen goes blank, X is running, startx is running:

johnson   1392  0.0  0.2   2572  1452 tty1 S+   08:06   0:00 /bin/sh
/usr/bin/startx
johnson   1414  0.0  0.4   4904  2096 tty1 S+   08:06   0:00 xinit
/etc/X11/xinit/xinitrc -- /etc/X11/xinit/xserverrc :0 vt1 -keeptty -auth
/tmp/serverauth.dJ7lSnzjjo
johnson   1415  1.0  8.2 128436 41924 tty1 Sl   08:06   0:04
/usr/lib/xorg/Xorg -nolisten tcp :0 vt1 -keeptty -auth
/tmp/serverauth.dJ7lSnzjjo

I had to use "kill -KILL" to kill the startx, xinit and Xorg processes.
After those were killed, the screen was still blank, and even though
nothing was running, the load average was still around 1.00 several
minutes later, so something is still taking CPU time:

$ uptime
  08:25:15 up 20 min,  2 users,  load average: 1.00, 1.00, 0.84

I can attempt a git bisect, though that will take some time.

-Stan

--
$ patch -p1
<../v3-drm-radeon-Fix-NULL-dereference-when-updating-memory-stats.patch
patching file drivers/gpu/drm/radeon/radeon_object.c
Hunk #2 FAILED at 76.
Hunk #3 FAILED at 727.
2 out of 3 hunks FAILED -- saving rejects to file
drivers/gpu/drm/radeon/radeon_object.c.rej
patching file drivers/gpu/drm/radeon/radeon_object.h
patching file drivers/gpu/drm/radeon/radeon_ttm.c
Hunk #1 FAILED at 199.
Hunk #2 succeeded at 227 (offset 11 lines).
Hunk #3 succeeded at 275 (offset 11 lines).
Hunk #4 succeeded at 697 (offset 12 lines).
1 out of 4 hunks FAILED -- saving rejects to file
drivers/gpu/drm/radeon/radeon_ttm.c.rej
johnson@mac-server:/data/software/working/linux-5.13.2$ cat
drivers/gpu/drm/radeon/radeon_ttm.c.rej
--- drivers/gpu/drm/radeon/radeon_ttm.c
+++ drivers/gpu/drm/radeon/radeon_ttm.c
@@ -199,7 +199,7 @@ static int radeon_bo_move(struct ttm_buffer_object
*bo, bool evict,
struct ttm_resource *old_mem = bo->resource;
struct radeon_device *rdev;
struct radeon_bo *rbo;
-   int r;
+   int r, old_type;

if (new_mem->mem_type == TTM_PL_TT) {
r = radeon_ttm_tt_bind(bo->bdev, bo->ttm, new_mem);

-

Hello Stan,

Greg has the same issue with patching the kernel 5.13 [1]. We have to 
wait for a solution.


- Christian

[1]

The patch below does not apply to the 5.13-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to .

thanks,

greg k-h

-- original commit in Linus's tree --

>From 293774413a3f519c826d4eb5313ef02e20515700 Mon Sep 17 00:00:00 2001
From: "Gustavo A. R. Silva" 
Date: Sun, 9 May 2021 17:49:26 -0500
Subject: [PATCH] drm/radeon/ni_dpm: Fix booting bug

Create new structure NISLANDS_SMC_SWSTATE_SINGLE, as initialState.levels
and ACPIState.levels are never actually used as flexible arrays. Those
arrays can be used as simple objects of type
NISLANDS_SMC_HW_PERFORMANCE_LEVEL, instead.

Currently, the code fails because flexible array _levels_ in
struct NISLANDS_SMC_SWSTATE doesn't allow for code that access
the first element of initialState.levels and ACPIState.levels
arrays:

drivers/gpu/drm/radeon/ni_dpm.c:
1690 table->initialState.levels[0].mclk.vMPLL_AD_FUNC_CNTL =
1691 cpu_to_be32(ni_pi->clock_registers.mpll_ad_func_cntl);
...
1903:   table->ACPIState.levels[0].mclk.vMPLL_AD_FUNC_CNTL = 
cpu_to_be32(mpll_ad_func_cntl);
1904:   table->ACPIState.levels[0].mclk.vMPLL_AD_FUNC_CNTL_2 = 
cpu_to_be32(mpll_ad_func_cntl_2);


because such element cannot exist without previously allocating
any dynamic memory for it (which never actually happens).

That's why struct NISLANDS_SMC_SWSTATE should only be used as type
for object driverState and new struct SISLANDS_SMC_SWSTATE_SINGLE is
created as type for objects initialState, ACPIState and ULVState.

Also, with the change from one-element array to flexible-array member
in commit 434fb1e7444a ("drm/radeon/nislands_smc.h: Replace one-element
array with flexible-array member in struct NISLANDS_SMC_SWSTATE"), the
size of dpmLevels in struct NISLANDS_SMC_STATETABLE should 

Re: Xorg doesn't work anymore after the latest DRM updates

2021-07-06 Thread Christian Zigotzky

Hi Nirmoy,

This patch works! Thanks a lot! We tested it on an A-EON AmigaOne 
X5000/20 today.


Screenshot: 
http://www.skateman.nl/wp-content/uploads/2021/07/Screenshot-at-2021-07-06-113237.png


Cheers,
Christian

On 05 July 2021 at 06:48 pm, Christian Zigotzky wrote:

Hi Nirmoy,

Many thanks for this information. We will test this patch asap.

Have a nice day,
Christian

On 05 July 2021 at 10:26pm, Nirmoy wrote:
> Hi Christian,
>
>
> This issue looks similar to the one Mikel Rychliski fixed recently  
: https://patchwork.freedesktop.org/patch/440791. Let us know if this 
helps.

>
>
> Regards,
>
> Nirmoy
>
> On 7/3/2021 9:30 AM, Christian Zigotzky wrote:
>> Hi All,
>>
>> Xorg doesn't work anymore after the latest DRM updates. [1]
>>
>> Error messages:
>>
>> Jul 03 08:54:51 Fienix systemd[1]: Starting Light Display Manager...
>> Jul 03 08:54:51 Fienix systemd[1]: Started Light Display Manager.
>> Jul 03 08:54:51 Fienix kernel: BUG: Kernel NULL pointer dereference 
on read at 0x0010
>> Jul 03 08:54:51 Fienix kernel: Faulting instruction address: 
0xc0630750
>> Jul 03 08:54:51 Fienix kernel: Oops: Kernel access of bad area, 
sig: 11 [#1]
>> Jul 03 08:54:51 Fienix kernel: BE PAGE_SIZE=4K PREEMPT SMP 
NR_CPUS=4 CoreNet Generic
>> Jul 03 08:54:51 Fienix kernel: Modules linked in: algif_skcipher 
bnep tuner_simple tuner_types tea5767 tuner tda7432 tvaudio msp3400 
bttv tea575x tveeprom videobuf_dma_sg videobuf_core rc_core videodev 
mc btusb btrtl btbcm btintel bluetooth ecdh_generic ecc 
uio_pdrv_genirq uio
>> Jul 03 08:54:51 Fienix kernel: CPU: 3 PID: 4300 Comm: Xorg.wrap Not 
tainted 5.14.0-a3_A-EON_X5000-07637-g3dbdb38e2869-dirty #1
>> Jul 03 08:54:51 Fienix kernel: NIP:  c0630750 LR: 
c060fedc CTR: c0630728
>> Jul 03 08:54:51 Fienix kernel: REGS: c0008d903470 TRAP: 0300 
Not tainted (5.14.0-a3_A-EON_X5000-07637-g3dbdb38e2869-dirty)
>> Jul 03 08:54:51 Fienix kernel: MSR:  80029002   
CR: 2222  XER: 2000
>> Jul 03 08:54:51 Fienix kernel: DEAR: 0010 ESR: 
 IRQMASK: 0
>>    GPR00: c060fedc 
c0008d903710 c190c400 c00085d59c00
>>    GPR04: c0008d9035b8 
 c000870a4900 c00085b62d00
>>    GPR08: 000f 
 c0630728 0003
>>    GPR12: 2222 
c0003fffeac0 ffe51070 0086007c
>>    GPR16: 00862820 
ffb7ec68  
>>    GPR20: c04064a0 
00450088 ffca79e4 5deadbeef122
>>    GPR24: 5deadbeef100 
 c000876028f0 c00080bd4000
>>    GPR28: c00087603c48 
c00085d59d78 c00085d59c00 c00085d59c78
>> Jul 03 08:54:51 Fienix kernel: NIP [c0630750] 
.radeon_ttm_bo_destroy+0x28/0xc0
>> Jul 03 08:54:51 Fienix kernel: LR [c060fedc] 
.ttm_bo_put+0x2ec/0x344

>> Jul 03 08:54:51 Fienix kernel: Call Trace:
>> Jul 03 08:54:51 Fienix kernel: [c0008d903710] 
[c060fbe4] .ttm_bo_cleanup_memtype_use+0x54/0x60 (unreliable)
>> Jul 03 08:54:51 Fienix kernel: [c0008d903790] 
[c060fedc] .ttm_bo_put+0x2ec/0x344
>> Jul 03 08:54:51 Fienix kernel: [c0008d903820] 
[c0630b50] .radeon_bo_unref+0x28/0x3c
>> Jul 03 08:54:51 Fienix kernel: [c0008d9038a0] 
[c06d1f6c] .radeon_vm_fini+0x1b0/0x1b8
>> Jul 03 08:54:51 Fienix kernel: [c0008d903940] 
[c0618e38] .radeon_driver_postclose_kms+0x128/0x178
>> Jul 03 08:54:51 Fienix kernel: [c0008d9039e0] 
[c05deb14] .drm_file_free+0x1d8/0x278
>> Jul 03 08:54:51 Fienix kernel: [c0008d903aa0] 
[c05def00] .drm_release+0x64/0xc8
>> Jul 03 08:54:51 Fienix kernel: [c0008d903b30] 
[c017636c] .__fput+0x11c/0x25c
>> Jul 03 08:54:51 Fienix kernel: [c0008d903bd0] 
[c008b1e8] .task_work_run+0xa4/0xbc
>> Jul 03 08:54:51 Fienix kernel: [c0008d903c70] 
[c0004bf4] .do_notify_resume+0x144/0x2f0
>> Jul 03 08:54:51 Fienix kernel: [c0008d903d70] 
[c000b380] .syscall_exit_prepare+0x110/0x130
>> Jul 03 08:54:51 Fienix kernel: [c0008d903e10] 
[c688] system_call_common+0x100/0x1fc

>> Jul 03 08:54:51 Fienix kernel: --- interrupt: c00 at 0x3f4f58
>> Jul 03 08:54:51 Fienix kernel: NIP:  003f4f58 LR: 
003f4f2c CTR: 
>> Jul 03 08:54:51 Fienix kernel: REGS: c0008d903e80 TRAP: 0c00 
Not tain

Re: [FSL P50xx] IRQ issues

2021-07-06 Thread Christian Zigotzky

Hi Nick,

Your patch works (see patch below)! Many thanks for your help! We tested 
it on an A-EON AmigaOne X5000/20 and in a virtual e5500 QEMU machine today.


Screenshots:

- 
http://www.skateman.nl/wp-content/uploads/2021/07/Screenshot-at-2021-07-06-113237.png

- https://i.ibb.co/h813RRp/Kernel-5-14-alpha3-Power-PC.png

Thanks,
Christian

On 06 July 2021 at 06:07 am, Christian Zigotzky wrote:

Hi Nick,

Thanks a lot for your patch! We will test it as soon as possible. 
You're right that this issue doesn't exist in a virtual e5500 QEMU 
machine.


Have a nice day,
Christian

On 06 July 2021 at 01:36 am, Nicholas Piggin wrote:

Excerpts from Christian Zigotzky's message of July 6, 2021 4:49 am:

Hi All,

Our FSL P50xx machines don't boot anymore because of IRQ issues. [1]

Please check the IRQ changes in the latest PowerPC updates 5.14-1. [2]

Thanks,
Christian

[1]
https://forum.hyperion-entertainment.com/download/file.php?id=2592=view 


[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=019b3fd94ba73d3ac615f0537440b81f129821f6 


This looks like mtmsrd in the 64e code. I think this should fix it.

QEMU does not seem to trap on this, maybe something to improve.

Thanks,
Nick
--

diff --git a/arch/powerpc/kernel/interrupt_64.S 
b/arch/powerpc/kernel/interrupt_64.S

index 4063e8a3f704..d4212d2ff0b5 100644
--- a/arch/powerpc/kernel/interrupt_64.S
+++ b/arch/powerpc/kernel/interrupt_64.S
@@ -311,9 +311,13 @@ END_BTB_FLUSH_SECTION
   * trace_hardirqs_off().
   */
  li    r11,IRQS_ALL_DISABLED
-    li    r12,-1 /* Set MSR_EE and MSR_RI */
  stb    r11,PACAIRQSOFTMASK(r13)
+#ifdef CONFIG_PPC_BOOK3S
+    li    r12,-1 /* Set MSR_EE and MSR_RI */
  mtmsrd    r12,1
+#else
+    wrteei    1
+#endif
    /* Calling convention has r9 = orig r0, r10 = regs */
  mr    r9,r0






Re: [FSL P50xx] IRQ issues

2021-07-05 Thread Christian Zigotzky

Hi Nick,

Thanks a lot for your patch! We will test it as soon as possible. You're 
right that this issue doesn't exist in a virtual e5500 QEMU machine.


Have a nice day,
Christian

On 06 July 2021 at 01:36 am, Nicholas Piggin wrote:

Excerpts from Christian Zigotzky's message of July 6, 2021 4:49 am:

Hi All,

Our FSL P50xx machines don't boot anymore because of IRQ issues. [1]

Please check the IRQ changes in the latest PowerPC updates 5.14-1. [2]

Thanks,
Christian

[1]
https://forum.hyperion-entertainment.com/download/file.php?id=2592=view
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=019b3fd94ba73d3ac615f0537440b81f129821f6

This looks like mtmsrd in the 64e code. I think this should fix it.

QEMU does not seem to trap on this, maybe something to improve.

Thanks,
Nick
--

diff --git a/arch/powerpc/kernel/interrupt_64.S 
b/arch/powerpc/kernel/interrupt_64.S
index 4063e8a3f704..d4212d2ff0b5 100644
--- a/arch/powerpc/kernel/interrupt_64.S
+++ b/arch/powerpc/kernel/interrupt_64.S
@@ -311,9 +311,13 @@ END_BTB_FLUSH_SECTION
 * trace_hardirqs_off().
 */
li  r11,IRQS_ALL_DISABLED
-   li  r12,-1 /* Set MSR_EE and MSR_RI */
stb r11,PACAIRQSOFTMASK(r13)
+#ifdef CONFIG_PPC_BOOK3S
+   li  r12,-1 /* Set MSR_EE and MSR_RI */
mtmsrd  r12,1
+#else
+   wrteei  1
+#endif
  
  	/* Calling convention has r9 = orig r0, r10 = regs */

mr  r9,r0




[FSL P50xx] IRQ issues

2021-07-05 Thread Christian Zigotzky

Hi All,

Our FSL P50xx machines don't boot anymore because of IRQ issues. [1]

Please check the IRQ changes in the latest PowerPC updates 5.14-1. [2]

Thanks,
Christian

[1] 
https://forum.hyperion-entertainment.com/download/file.php?id=2592=view
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=019b3fd94ba73d3ac615f0537440b81f129821f6



On 03 July 2021 at 09:57am, Christian Zigotzky wrote:
> Oh dear, there is another issue after the latest PowerPC updates. The 
X5000 [1] doesn't boot anymore.

>
> Error messages:
>
> Oops: Exeption in kernel node, sig: 4 [#1]
> ...
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0004
>
> ---
>
> Unfortunately we have two issues at the same time. We are knocked out 
and unfortunately I don't have any time for bisecting.

>
> - Christian
>
>>
>>
>> [1] http://wiki.amiga.org/index.php?title=X5000
>




Re: Xorg doesn't work anymore after the latest DRM updates

2021-07-05 Thread Christian Zigotzky

Hi Nirmoy,

Many thanks for this information. We will test this patch asap.

Have a nice day,
Christian

On 05 July 2021 at 10:26pm, Nirmoy wrote:
> Hi Christian,
>
>
> This issue looks similar to the one Mikel Rychliski fixed recently  : 
https://patchwork.freedesktop.org/patch/440791. Let us know if this helps.

>
>
> Regards,
>
> Nirmoy
>
> On 7/3/2021 9:30 AM, Christian Zigotzky wrote:
>> Hi All,
>>
>> Xorg doesn't work anymore after the latest DRM updates. [1]
>>
>> Error messages:
>>
>> Jul 03 08:54:51 Fienix systemd[1]: Starting Light Display Manager...
>> Jul 03 08:54:51 Fienix systemd[1]: Started Light Display Manager.
>> Jul 03 08:54:51 Fienix kernel: BUG: Kernel NULL pointer dereference 
on read at 0x0010
>> Jul 03 08:54:51 Fienix kernel: Faulting instruction address: 
0xc0630750
>> Jul 03 08:54:51 Fienix kernel: Oops: Kernel access of bad area, sig: 
11 [#1]
>> Jul 03 08:54:51 Fienix kernel: BE PAGE_SIZE=4K PREEMPT SMP NR_CPUS=4 
CoreNet Generic
>> Jul 03 08:54:51 Fienix kernel: Modules linked in: algif_skcipher 
bnep tuner_simple tuner_types tea5767 tuner tda7432 tvaudio msp3400 bttv 
tea575x tveeprom videobuf_dma_sg videobuf_core rc_core videodev mc btusb 
btrtl btbcm btintel bluetooth ecdh_generic ecc uio_pdrv_genirq uio
>> Jul 03 08:54:51 Fienix kernel: CPU: 3 PID: 4300 Comm: Xorg.wrap Not 
tainted 5.14.0-a3_A-EON_X5000-07637-g3dbdb38e2869-dirty #1
>> Jul 03 08:54:51 Fienix kernel: NIP:  c0630750 LR: 
c060fedc CTR: c0630728
>> Jul 03 08:54:51 Fienix kernel: REGS: c0008d903470 TRAP: 0300 Not 
tainted  (5.14.0-a3_A-EON_X5000-07637-g3dbdb38e2869-dirty)
>> Jul 03 08:54:51 Fienix kernel: MSR:  80029002   
CR: 2222  XER: 2000
>> Jul 03 08:54:51 Fienix kernel: DEAR: 0010 ESR: 
 IRQMASK: 0
>>    GPR00: c060fedc 
c0008d903710 c190c400 c00085d59c00
>>    GPR04: c0008d9035b8 
 c000870a4900 c00085b62d00
>>    GPR08: 000f 
 c0630728 0003
>>    GPR12: 2222 
c0003fffeac0 ffe51070 0086007c
>>    GPR16: 00862820 
ffb7ec68  
>>    GPR20: c04064a0 
00450088 ffca79e4 5deadbeef122
>>    GPR24: 5deadbeef100 
 c000876028f0 c00080bd4000
>>    GPR28: c00087603c48 
c00085d59d78 c00085d59c00 c00085d59c78
>> Jul 03 08:54:51 Fienix kernel: NIP [c0630750] 
.radeon_ttm_bo_destroy+0x28/0xc0
>> Jul 03 08:54:51 Fienix kernel: LR [c060fedc] 
.ttm_bo_put+0x2ec/0x344

>> Jul 03 08:54:51 Fienix kernel: Call Trace:
>> Jul 03 08:54:51 Fienix kernel: [c0008d903710] [c060fbe4] 
.ttm_bo_cleanup_memtype_use+0x54/0x60 (unreliable)
>> Jul 03 08:54:51 Fienix kernel: [c0008d903790] [c060fedc] 
.ttm_bo_put+0x2ec/0x344
>> Jul 03 08:54:51 Fienix kernel: [c0008d903820] [c0630b50] 
.radeon_bo_unref+0x28/0x3c
>> Jul 03 08:54:51 Fienix kernel: [c0008d9038a0] [c06d1f6c] 
.radeon_vm_fini+0x1b0/0x1b8
>> Jul 03 08:54:51 Fienix kernel: [c0008d903940] [c0618e38] 
.radeon_driver_postclose_kms+0x128/0x178
>> Jul 03 08:54:51 Fienix kernel: [c0008d9039e0] [c05deb14] 
.drm_file_free+0x1d8/0x278
>> Jul 03 08:54:51 Fienix kernel: [c0008d903aa0] [c05def00] 
.drm_release+0x64/0xc8
>> Jul 03 08:54:51 Fienix kernel: [c0008d903b30] [c017636c] 
.__fput+0x11c/0x25c
>> Jul 03 08:54:51 Fienix kernel: [c0008d903bd0] [c008b1e8] 
.task_work_run+0xa4/0xbc
>> Jul 03 08:54:51 Fienix kernel: [c0008d903c70] [c0004bf4] 
.do_notify_resume+0x144/0x2f0
>> Jul 03 08:54:51 Fienix kernel: [c0008d903d70] [c000b380] 
.syscall_exit_prepare+0x110/0x130
>> Jul 03 08:54:51 Fienix kernel: [c0008d903e10] [c688] 
system_call_common+0x100/0x1fc

>> Jul 03 08:54:51 Fienix kernel: --- interrupt: c00 at 0x3f4f58
>> Jul 03 08:54:51 Fienix kernel: NIP:  003f4f58 LR: 
003f4f2c CTR: 
>> Jul 03 08:54:51 Fienix kernel: REGS: c0008d903e80 TRAP: 0c00 Not 
tainted  (5.14.0-a3_A-EON_X5000-07637-g3dbdb38e2869-dirty)
>> Jul 03 08:54:51 Fienix kernel: MSR:  0002d002   
CR: 2420  XER: 

>> Jul 03 08:54:51 Fienix kernel: IRQMASK: 0
>>    GPR00: 0006 
ffca66a0 f798a3

Re: Xorg doesn't work anymore after the latest DRM updates

2021-07-03 Thread Christian Zigotzky
Oh dear, there is another issue after the latest PowerPC updates. The 
X5000 doesn't boot anymore.


Error messages:

Oops: Exeption in kernel node, sig: 4 [#1]
...
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0004

---

Unfortunately we have two issues at the same time. We are knocked out 
and unfortunately I don't have any time for bisecting.


- Christian


On 03 July 2021 at 09:30 am, Christian Zigotzky wrote:

Hi All,

Xorg doesn't work anymore after the latest DRM updates. [1]

Error messages:

Jul 03 08:54:51 Fienix systemd[1]: Starting Light Display Manager...
Jul 03 08:54:51 Fienix systemd[1]: Started Light Display Manager.
Jul 03 08:54:51 Fienix kernel: BUG: Kernel NULL pointer dereference on 
read at 0x0010
Jul 03 08:54:51 Fienix kernel: Faulting instruction address: 
0xc0630750
Jul 03 08:54:51 Fienix kernel: Oops: Kernel access of bad area, sig: 
11 [#1]
Jul 03 08:54:51 Fienix kernel: BE PAGE_SIZE=4K PREEMPT SMP NR_CPUS=4 
CoreNet Generic
Jul 03 08:54:51 Fienix kernel: Modules linked in: algif_skcipher bnep 
tuner_simple tuner_types tea5767 tuner tda7432 tvaudio msp3400 bttv 
tea575x tveeprom videobuf_dma_sg videobuf_core rc_core videodev mc 
btusb btrtl btbcm btintel bluetooth ecdh_generic ecc uio_pdrv_genirq uio
Jul 03 08:54:51 Fienix kernel: CPU: 3 PID: 4300 Comm: Xorg.wrap Not 
tainted 5.14.0-a3_A-EON_X5000-07637-g3dbdb38e2869-dirty #1
Jul 03 08:54:51 Fienix kernel: NIP:  c0630750 LR: 
c060fedc CTR: c0630728
Jul 03 08:54:51 Fienix kernel: REGS: c0008d903470 TRAP: 0300 Not 
tainted  (5.14.0-a3_A-EON_X5000-07637-g3dbdb38e2869-dirty)
Jul 03 08:54:51 Fienix kernel: MSR:  80029002   CR: 
2222  XER: 2000
Jul 03 08:54:51 Fienix kernel: DEAR: 0010 ESR: 
 IRQMASK: 0
   GPR00: c060fedc 
c0008d903710 c190c400 c00085d59c00
   GPR04: c0008d9035b8 
 c000870a4900 c00085b62d00
   GPR08: 000f 
 c0630728 0003
   GPR12: 2222 
c0003fffeac0 ffe51070 0086007c
   GPR16: 00862820 
ffb7ec68  
   GPR20: c04064a0 
00450088 ffca79e4 5deadbeef122
   GPR24: 5deadbeef100 
 c000876028f0 c00080bd4000
   GPR28: c00087603c48 
c00085d59d78 c00085d59c00 c00085d59c78
Jul 03 08:54:51 Fienix kernel: NIP [c0630750] 
.radeon_ttm_bo_destroy+0x28/0xc0
Jul 03 08:54:51 Fienix kernel: LR [c060fedc] 
.ttm_bo_put+0x2ec/0x344

Jul 03 08:54:51 Fienix kernel: Call Trace:
Jul 03 08:54:51 Fienix kernel: [c0008d903710] [c060fbe4] 
.ttm_bo_cleanup_memtype_use+0x54/0x60 (unreliable)
Jul 03 08:54:51 Fienix kernel: [c0008d903790] [c060fedc] 
.ttm_bo_put+0x2ec/0x344
Jul 03 08:54:51 Fienix kernel: [c0008d903820] [c0630b50] 
.radeon_bo_unref+0x28/0x3c
Jul 03 08:54:51 Fienix kernel: [c0008d9038a0] [c06d1f6c] 
.radeon_vm_fini+0x1b0/0x1b8
Jul 03 08:54:51 Fienix kernel: [c0008d903940] [c0618e38] 
.radeon_driver_postclose_kms+0x128/0x178
Jul 03 08:54:51 Fienix kernel: [c0008d9039e0] [c05deb14] 
.drm_file_free+0x1d8/0x278
Jul 03 08:54:51 Fienix kernel: [c0008d903aa0] [c05def00] 
.drm_release+0x64/0xc8
Jul 03 08:54:51 Fienix kernel: [c0008d903b30] [c017636c] 
.__fput+0x11c/0x25c
Jul 03 08:54:51 Fienix kernel: [c0008d903bd0] [c008b1e8] 
.task_work_run+0xa4/0xbc
Jul 03 08:54:51 Fienix kernel: [c0008d903c70] [c0004bf4] 
.do_notify_resume+0x144/0x2f0
Jul 03 08:54:51 Fienix kernel: [c0008d903d70] [c000b380] 
.syscall_exit_prepare+0x110/0x130
Jul 03 08:54:51 Fienix kernel: [c0008d903e10] [c688] 
system_call_common+0x100/0x1fc

Jul 03 08:54:51 Fienix kernel: --- interrupt: c00 at 0x3f4f58
Jul 03 08:54:51 Fienix kernel: NIP:  003f4f58 LR: 
003f4f2c CTR: 
Jul 03 08:54:51 Fienix kernel: REGS: c0008d903e80 TRAP: 0c00 Not 
tainted  (5.14.0-a3_A-EON_X5000-07637-g3dbdb38e2869-dirty)
Jul 03 08:54:51 Fienix kernel: MSR:  0002d002   
CR: 2420  XER: 

Jul 03 08:54:51 Fienix kernel: IRQMASK: 0
   GPR00: 0006 
ffca66a0 f798a310 
   GPR04:  
  
   GPR08:  
  
   GPR12:  
0044fff4 ffe51070 0086007c
   GPR16: 00862820 
ffb7ec68

Xorg doesn't work anymore after the latest DRM updates

2021-07-03 Thread Christian Zigotzky

Hi All,

Xorg doesn't work anymore after the latest DRM updates. [1]

Error messages:

Jul 03 08:54:51 Fienix systemd[1]: Starting Light Display Manager...
Jul 03 08:54:51 Fienix systemd[1]: Started Light Display Manager.
Jul 03 08:54:51 Fienix kernel: BUG: Kernel NULL pointer dereference on 
read at 0x0010
Jul 03 08:54:51 Fienix kernel: Faulting instruction address: 
0xc0630750

Jul 03 08:54:51 Fienix kernel: Oops: Kernel access of bad area, sig: 11 [#1]
Jul 03 08:54:51 Fienix kernel: BE PAGE_SIZE=4K PREEMPT SMP NR_CPUS=4 
CoreNet Generic
Jul 03 08:54:51 Fienix kernel: Modules linked in: algif_skcipher bnep 
tuner_simple tuner_types tea5767 tuner tda7432 tvaudio msp3400 bttv 
tea575x tveeprom videobuf_dma_sg videobuf_core rc_core videodev mc btusb 
btrtl btbcm btintel bluetooth ecdh_generic ecc uio_pdrv_genirq uio
Jul 03 08:54:51 Fienix kernel: CPU: 3 PID: 4300 Comm: Xorg.wrap Not 
tainted 5.14.0-a3_A-EON_X5000-07637-g3dbdb38e2869-dirty #1
Jul 03 08:54:51 Fienix kernel: NIP:  c0630750 LR: 
c060fedc CTR: c0630728
Jul 03 08:54:51 Fienix kernel: REGS: c0008d903470 TRAP: 0300 Not 
tainted  (5.14.0-a3_A-EON_X5000-07637-g3dbdb38e2869-dirty)
Jul 03 08:54:51 Fienix kernel: MSR:  80029002   CR: 
2222  XER: 2000
Jul 03 08:54:51 Fienix kernel: DEAR: 0010 ESR: 
 IRQMASK: 0
   GPR00: c060fedc c0008d903710 
c190c400 c00085d59c00
   GPR04: c0008d9035b8  
c000870a4900 c00085b62d00
   GPR08: 000f  
c0630728 0003
   GPR12: 2222 c0003fffeac0 
ffe51070 0086007c
   GPR16: 00862820 ffb7ec68 
 
   GPR20: c04064a0 00450088 
ffca79e4 5deadbeef122
   GPR24: 5deadbeef100  
c000876028f0 c00080bd4000
   GPR28: c00087603c48 c00085d59d78 
c00085d59c00 c00085d59c78
Jul 03 08:54:51 Fienix kernel: NIP [c0630750] 
.radeon_ttm_bo_destroy+0x28/0xc0

Jul 03 08:54:51 Fienix kernel: LR [c060fedc] .ttm_bo_put+0x2ec/0x344
Jul 03 08:54:51 Fienix kernel: Call Trace:
Jul 03 08:54:51 Fienix kernel: [c0008d903710] [c060fbe4] 
.ttm_bo_cleanup_memtype_use+0x54/0x60 (unreliable)
Jul 03 08:54:51 Fienix kernel: [c0008d903790] [c060fedc] 
.ttm_bo_put+0x2ec/0x344
Jul 03 08:54:51 Fienix kernel: [c0008d903820] [c0630b50] 
.radeon_bo_unref+0x28/0x3c
Jul 03 08:54:51 Fienix kernel: [c0008d9038a0] [c06d1f6c] 
.radeon_vm_fini+0x1b0/0x1b8
Jul 03 08:54:51 Fienix kernel: [c0008d903940] [c0618e38] 
.radeon_driver_postclose_kms+0x128/0x178
Jul 03 08:54:51 Fienix kernel: [c0008d9039e0] [c05deb14] 
.drm_file_free+0x1d8/0x278
Jul 03 08:54:51 Fienix kernel: [c0008d903aa0] [c05def00] 
.drm_release+0x64/0xc8
Jul 03 08:54:51 Fienix kernel: [c0008d903b30] [c017636c] 
.__fput+0x11c/0x25c
Jul 03 08:54:51 Fienix kernel: [c0008d903bd0] [c008b1e8] 
.task_work_run+0xa4/0xbc
Jul 03 08:54:51 Fienix kernel: [c0008d903c70] [c0004bf4] 
.do_notify_resume+0x144/0x2f0
Jul 03 08:54:51 Fienix kernel: [c0008d903d70] [c000b380] 
.syscall_exit_prepare+0x110/0x130
Jul 03 08:54:51 Fienix kernel: [c0008d903e10] [c688] 
system_call_common+0x100/0x1fc

Jul 03 08:54:51 Fienix kernel: --- interrupt: c00 at 0x3f4f58
Jul 03 08:54:51 Fienix kernel: NIP:  003f4f58 LR: 
003f4f2c CTR: 
Jul 03 08:54:51 Fienix kernel: REGS: c0008d903e80 TRAP: 0c00 Not 
tainted  (5.14.0-a3_A-EON_X5000-07637-g3dbdb38e2869-dirty)
Jul 03 08:54:51 Fienix kernel: MSR:  0002d002   CR: 
2420  XER: 

Jul 03 08:54:51 Fienix kernel: IRQMASK: 0
   GPR00: 0006 ffca66a0 
f798a310 
   GPR04:   
 
   GPR08:   
 
   GPR12:  0044fff4 
ffe51070 0086007c
   GPR16: 00862820 ffb7ec68 
 
   GPR20: c04064a0 00450088 
ffca79e4 004317ac
   GPR24: 004317b8 ffca66d0 
0001 ffca673c
   GPR28: 0001  
0041cff4 0003

Jul 03 08:54:51 Fienix kernel: NIP [003f4f58] 0x3f4f58
Jul 03 08:54:51 Fienix 

Re: [FSL P50x0] KVM HV doesn't work anymore

2021-06-07 Thread Christian Zigotzky

On 02 June 2021 at 01:26pm, Christian Zigotzky wrote:

On 20 May 2021 at 01:07am, Nicholas Piggin wrote:

Hmm, okay that probably rules out those notifier changes then.
Can you remind me were you able to rule these out as suspects?

8f6cc75a97d1 powerpc: move norestart trap flag to bit 0
8dc7f0229b78 powerpc: remove partial register save logic
c45ba4f44f6b powerpc: clean up do_page_fault
d738ee8d56de powerpc/64e/interrupt: handle bad_page_fault in C
ceff77efa4f8 powerpc/64e/interrupt: Use new interrupt context 
tracking scheme

097157e16cf8 powerpc/64e/interrupt: reconcile irq soft-mask state in C
3db8aa10de9a powerpc/64e/interrupt: NMI save irq soft-mask state in C
0c2472de23ae powerpc/64e/interrupt: use new interrupt return
dc6231821a14 powerpc/interrupt: update common interrupt code for
4228b2c3d20e powerpc/64e/interrupt: always save nvgprs on interrupt
5a5a893c4ad8 powerpc/syscall: switch user_exit_irqoff and 
trace_hardirqs_off order


Thanks,
Nick

Hi Nick,

I tested these commits above today and all works with -smp 4. [1]

Smp 4 still doesn't work with the RC4 of kernel 5.13 on quad core 
e5500 CPUs with KVM HV. I use -smp 3 currently.


What shall I test next?

Thanks,
Christian

[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=53367#p53367

Hi All,

I tested the RC5 of kernel 5.13 today. Unfortunately the KVM HV issue 
still exists.

I also figured out, that '-smp 2' doesn't work either.

Summary:

-smp 1 -> works
-smp 2 -> doesn't work
-smp 3 -> works
-smp 4 -> doesn't work

Cheers,
Christian


Re: [FSL P50x0] KVM HV doesn't work anymore

2021-06-02 Thread Christian Zigotzky

On 20 May 2021 at 01:07am, Nicholas Piggin wrote:

Hmm, okay that probably rules out those notifier changes then.
Can you remind me were you able to rule these out as suspects?

8f6cc75a97d1 powerpc: move norestart trap flag to bit 0
8dc7f0229b78 powerpc: remove partial register save logic
c45ba4f44f6b powerpc: clean up do_page_fault
d738ee8d56de powerpc/64e/interrupt: handle bad_page_fault in C
ceff77efa4f8 powerpc/64e/interrupt: Use new interrupt context tracking scheme
097157e16cf8 powerpc/64e/interrupt: reconcile irq soft-mask state in C
3db8aa10de9a powerpc/64e/interrupt: NMI save irq soft-mask state in C
0c2472de23ae powerpc/64e/interrupt: use new interrupt return
dc6231821a14 powerpc/interrupt: update common interrupt code for
4228b2c3d20e powerpc/64e/interrupt: always save nvgprs on interrupt
5a5a893c4ad8 powerpc/syscall: switch user_exit_irqoff and trace_hardirqs_off 
order

Thanks,
Nick

Hi Nick,

I tested these commits above today and all works with -smp 4. [1]

Smp 4 still doesn't work with the RC4 of kernel 5.13 on quad core e5500 
CPUs with KVM HV. I use -smp 3 currently.


What shall I test next?

Thanks,
Christian

[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=53367#p53367


Re: [FSL P50x0] KVM HV doesn't work anymore

2021-05-30 Thread Christian Zigotzky

On 20 May 21 at 01:07am, Nicholas Piggin wrote:

Excerpts from Christian Zigotzky's message of May 19, 2021 9:52 pm:

On 19 May 2021 at 09:57 am, Nicholas Piggin wrote:

Excerpts from Christian Zigotzky's message of May 17, 2021 7:42 pm:

On 17 May 2021 at 09:42am, Nicholas Piggin wrote:

Excerpts from Christian Zigotzky's message of May 15, 2021 11:46 pm:

I tried it but it doesn't solve the issue. The uImage works without
KVM
HV in a virtual e5500 QEMU machine.

Any more progress with this? I would say that bisect might have just
been a bit unstable and maybe by chance some things did not crash so
it's pointing to the wrong patch.

Upstream merge of powerpc-5.13-1 was good and powerpc-5.13-2 was bad?

Between that looks like some KVM MMU rework. You could try the patch
before this one b1c5356e873c ("KVM: PPC: Convert to the gfn-based MMU
notifier callbacks"). That won't revert cleanly so just try run the
tree at that point. If it works, test the patch and see if it fails.

Thanks,
Nick

Hi Nick,

Thanks a lot for your answer. Yes, there is a little bit of progress.
The RC2 of kernel 5.13 successfully boots with -smp 3 in a virtual e5500
QEMU machine.
-smp 4 doesn't work anymore since the PowerPC updates 5.13-2. I used
-smp 4 before 5.13 because my FSL P5040 machine has 4 cores.

Could you please post a patch for reverting the commit before
b1c5356e873c ("KVM: PPC: Convert to the gfn-based MMU notifier callbacks")?

You could `git checkout b1c5356e873c~1`

Thanks,
Nick

Hi Nick,

Thanks for your answer. I checked out the commit b1c5356e873c~1 (HEAD is
now at d923ff258423 KVM: MIPS/MMU: Convert to the gfn-based MMU notifier
callbacks).
The kernel boots with '-smp 4' without any problems.
After that I patched with the probable first bad commit (KVM: PPC:
Convert to the gfn-based MMU notifier callbacks). The kernel also boots
with this patch. That means, this isn't the first bad commit.
Further information:
https://forum.hyperion-entertainment.com/viewtopic.php?p=53267#p53267

Hmm, okay that probably rules out those notifier changes then.

Can you remind me were you able to rule these out as suspects?

8f6cc75a97d1 powerpc: move norestart trap flag to bit 0
8dc7f0229b78 powerpc: remove partial register save logic
c45ba4f44f6b powerpc: clean up do_page_fault
d738ee8d56de powerpc/64e/interrupt: handle bad_page_fault in C
ceff77efa4f8 powerpc/64e/interrupt: Use new interrupt context tracking scheme
097157e16cf8 powerpc/64e/interrupt: reconcile irq soft-mask state in C
3db8aa10de9a powerpc/64e/interrupt: NMI save irq soft-mask state in C
0c2472de23ae powerpc/64e/interrupt: use new interrupt return
dc6231821a14 powerpc/interrupt: update common interrupt code for
4228b2c3d20e powerpc/64e/interrupt: always save nvgprs on interrupt
5a5a893c4ad8 powerpc/syscall: switch user_exit_irqoff and trace_hardirqs_off 
order

Thanks,
Nick

Hi Nick,

Thanks for your answer. Smp 4 still doesn't work on quad core e5500 
CPUs. I use -smp 3 currently. Shall I checkout the commits above (in 
your last answer) and test them? Do you prefer a commit for testing?


Thanks,
Christian


Re: [FSL P50x0] KVM HV doesn't work anymore

2021-05-19 Thread Christian Zigotzky

On 19 May 2021 at 09:57 am, Nicholas Piggin wrote:

Excerpts from Christian Zigotzky's message of May 17, 2021 7:42 pm:

On 17 May 2021 at 09:42am, Nicholas Piggin wrote:

Excerpts from Christian Zigotzky's message of May 15, 2021 11:46 pm:
I tried it but it doesn't solve the issue. The uImage works without 
KVM

HV in a virtual e5500 QEMU machine.

Any more progress with this? I would say that bisect might have just
been a bit unstable and maybe by chance some things did not crash so
it's pointing to the wrong patch.

Upstream merge of powerpc-5.13-1 was good and powerpc-5.13-2 was bad?

Between that looks like some KVM MMU rework. You could try the patch
before this one b1c5356e873c ("KVM: PPC: Convert to the gfn-based MMU
notifier callbacks"). That won't revert cleanly so just try run the
tree at that point. If it works, test the patch and see if it fails.

Thanks,
Nick

Hi Nick,

Thanks a lot for your answer. Yes, there is a little bit of progress.
The RC2 of kernel 5.13 successfully boots with -smp 3 in a virtual e5500
QEMU machine.
-smp 4 doesn't work anymore since the PowerPC updates 5.13-2. I used
-smp 4 before 5.13 because my FSL P5040 machine has 4 cores.

Could you please post a patch for reverting the commit before
b1c5356e873c ("KVM: PPC: Convert to the gfn-based MMU notifier callbacks")?

You could `git checkout b1c5356e873c~1`

Thanks,
Nick

Hi Nick,

Thanks for your answer. I checked out the commit b1c5356e873c~1 (HEAD is 
now at d923ff258423 KVM: MIPS/MMU: Convert to the gfn-based MMU notifier 
callbacks).

The kernel boots with '-smp 4' without any problems.
After that I patched with the probable first bad commit (KVM: PPC: 
Convert to the gfn-based MMU notifier callbacks). The kernel also boots 
with this patch. That means, this isn't the first bad commit.
Further information: 
https://forum.hyperion-entertainment.com/viewtopic.php?p=53267#p53267


Cheers,
Christian


Re: [FSL P50x0] KVM HV doesn't work anymore

2021-05-18 Thread Christian Zigotzky



> On 17. May 2021, at 11:43, Christian Zigotzky  wrote:
> 
> On 17 May 2021 at 09:42am, Nicholas Piggin wrote:
>> Excerpts from Christian Zigotzky's message of May 15, 2021 11:46 pm:
>>> On 15 May 2021 at 12:08pm Christophe Leroy wrote:
>>>> 
>>>>> Le 15/05/2021 à 11:48, Christian Zigotzky a écrit :
>>>>>> Hi All,
>>>>>> 
>>>>>> I bisected today [1] and the bisecting itself was OK but the
>>>>>> reverting of the bad commit doesn't solve the issue. Do you have an
>>>>>> idea which commit could be resposible for this issue? Maybe the
>>>>>> bisecting wasn't successful. I will look in the kernel git log. Maybe
>>>>>> there is a commit that affected KVM HV on FSL P50x0 machines.
>>>>> If the uImage doesn't load, it may be because of the size of uImage.
>>>>> 
>>>>> See https://github.com/linuxppc/issues/issues/208
>>>>> 
>>>>> Is there a significant size difference with and without KVM HV ?
>>>>> 
>>>>> Maybe you can try to remove another option to reduce the size of the
>>>>> uImage.
>>> I tried it but it doesn't solve the issue. The uImage works without KVM
>>> HV in a virtual e5500 QEMU machine.
>> Any more progress with this? I would say that bisect might have just
>> been a bit unstable and maybe by chance some things did not crash so
>> it's pointing to the wrong patch.
>> 
>> Upstream merge of powerpc-5.13-1 was good and powerpc-5.13-2 was bad?
>> 
>> Between that looks like some KVM MMU rework. You could try the patch
>> before this one b1c5356e873c ("KVM: PPC: Convert to the gfn-based MMU
>> notifier callbacks"). That won't revert cleanly so just try run the
>> tree at that point. If it works, test the patch and see if it fails.
>> 
>> Thanks,
>> Nick
> Hi Nick,
> 
> Thanks a lot for your answer. Yes, there is a little bit of progress. The RC2 
> of kernel 5.13 successfully boots with -smp 3 in a virtual e5500 QEMU machine.
> -smp 4 doesn't work anymore since the PowerPC updates 5.13-2. I used -smp 4 
> before 5.13 because my FSL P5040 machine has 4 cores.
> 
> Could you please post a patch for reverting the commit before b1c5356e873c 
> ("KVM: PPC: Convert to the gfn-based MMU notifier callbacks")?
> 
> Thanks in advance,
> 
> Christian
> 
> 
For me it is ok to work with -smp 1, 2, and 3 but I am curious why -smp 4 
doesn’t work.

-Christian


Re: [FSL P50x0] KVM HV doesn't work anymore

2021-05-17 Thread Christian Zigotzky

On 17 May 2021 at 09:42am, Nicholas Piggin wrote:

Excerpts from Christian Zigotzky's message of May 15, 2021 11:46 pm:

On 15 May 2021 at 12:08pm Christophe Leroy wrote:


Le 15/05/2021 à 11:48, Christian Zigotzky a écrit :

Hi All,

I bisected today [1] and the bisecting itself was OK but the
reverting of the bad commit doesn't solve the issue. Do you have an
idea which commit could be resposible for this issue? Maybe the
bisecting wasn't successful. I will look in the kernel git log. Maybe
there is a commit that affected KVM HV on FSL P50x0 machines.

If the uImage doesn't load, it may be because of the size of uImage.

See https://github.com/linuxppc/issues/issues/208

Is there a significant size difference with and without KVM HV ?

Maybe you can try to remove another option to reduce the size of the
uImage.

I tried it but it doesn't solve the issue. The uImage works without KVM
HV in a virtual e5500 QEMU machine.

Any more progress with this? I would say that bisect might have just
been a bit unstable and maybe by chance some things did not crash so
it's pointing to the wrong patch.

Upstream merge of powerpc-5.13-1 was good and powerpc-5.13-2 was bad?

Between that looks like some KVM MMU rework. You could try the patch
before this one b1c5356e873c ("KVM: PPC: Convert to the gfn-based MMU
notifier callbacks"). That won't revert cleanly so just try run the
tree at that point. If it works, test the patch and see if it fails.

Thanks,
Nick

Hi Nick,

Thanks a lot for your answer. Yes, there is a little bit of progress. 
The RC2 of kernel 5.13 successfully boots with -smp 3 in a virtual e5500 
QEMU machine.
-smp 4 doesn't work anymore since the PowerPC updates 5.13-2. I used 
-smp 4 before 5.13 because my FSL P5040 machine has 4 cores.


Could you please post a patch for reverting the commit before 
b1c5356e873c ("KVM: PPC: Convert to the gfn-based MMU notifier callbacks")?


Thanks in advance,

Christian




Re: [FSL P50x0] KVM HV doesn't work anymore

2021-05-15 Thread Christian Zigotzky

On 15 May 2021 at 12:08pm Christophe Leroy wrote:



Le 15/05/2021 à 11:48, Christian Zigotzky a écrit :

Hi All,

I bisected today [1] and the bisecting itself was OK but the 
reverting of the bad commit doesn't solve the issue. Do you have an 
idea which commit could be resposible for this issue? Maybe the 
bisecting wasn't successful. I will look in the kernel git log. Maybe 
there is a commit that affected KVM HV on FSL P50x0 machines.


If the uImage doesn't load, it may be because of the size of uImage.

See https://github.com/linuxppc/issues/issues/208

Is there a significant size difference with and without KVM HV ?

Maybe you can try to remove another option to reduce the size of the 
uImage.
I tried it but it doesn't solve the issue. The uImage works without KVM 
HV in a virtual e5500 QEMU machine.


-Christian


Or if you are using gzipped uImage you can try with an lzma uImage. 
You can find a way to get an lzma uImage here: 
https://github.com/linuxppc/issues/issues/208#issuecomment-477479951


Christophe



Thanks,
Christian

[1] 
https://forum.hyperion-entertainment.com/viewtopic.php?p=53209#p53209


On 14 May 2021 at 10:10 am, Christian Zigotzky wrote:

Hi All,

The RC1 of kernel 5.13 doesn't boot in a virtual e5500 QEMU machine 
with KVM HV anymore. I see in the serial console that the uImage 
doesn't load. I use the following QEMU command for booting:


qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 1024 -kernel 
uImage-5.13 -drive 
format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev 
user,id=mynet0 -device e1000,netdev=mynet0 -append "rw 
root=/dev/vda" -device virtio-vga -device virtio-mouse-pci -device 
virtio-keyboard-pci -device pci-ohci,id=newusb -device 
usb-audio,bus=newusb.0 -smp 4


The kernel boots without KVM HV.

Have you already tested KVM HV with the kernel 5.13?

Thanks,
Christian






Re: [FSL P50x0] KVM HV doesn't work anymore

2021-05-15 Thread Christian Zigotzky

Hi All,

I bisected today [1] and the bisecting itself was OK but the reverting 
of the bad commit doesn't solve the issue. Do you have an idea which 
commit could be resposible for this issue? Maybe the bisecting wasn't 
successful. I will look in the kernel git log. Maybe there is a commit 
that affected KVM HV on FSL P50x0 machines.


Thanks,
Christian

[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=53209#p53209

On 14 May 2021 at 10:10 am, Christian Zigotzky wrote:

Hi All,

The RC1 of kernel 5.13 doesn't boot in a virtual e5500 QEMU machine 
with KVM HV anymore. I see in the serial console that the uImage 
doesn't load. I use the following QEMU command for booting:


qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 1024 -kernel 
uImage-5.13 -drive 
format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev 
user,id=mynet0 -device e1000,netdev=mynet0 -append "rw root=/dev/vda" 
-device virtio-vga -device virtio-mouse-pci -device 
virtio-keyboard-pci -device pci-ohci,id=newusb -device 
usb-audio,bus=newusb.0 -smp 4


The kernel boots without KVM HV.

Have you already tested KVM HV with the kernel 5.13?

Thanks,
Christian






[FSL P50x0] KVM HV doesn't work anymore

2021-05-14 Thread Christian Zigotzky

Hi All,

The RC1 of kernel 5.13 doesn't boot in a virtual e5500 QEMU machine with 
KVM HV anymore. I see in the serial console that the uImage doesn't 
load. I use the following QEMU command for booting:


qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 1024 -kernel 
uImage-5.13 -drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio 
-netdev user,id=mynet0 -device e1000,netdev=mynet0 -append "rw 
root=/dev/vda" -device virtio-vga -device virtio-mouse-pci -device 
virtio-keyboard-pci -device pci-ohci,id=newusb -device 
usb-audio,bus=newusb.0 -smp 4


The kernel boots without KVM HV.

Have you already tested KVM HV with the kernel 5.13?

Thanks,
Christian




Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1

2021-05-13 Thread Christian Zigotzky

On 14 May 2021 at 00:58am, Nicholas Piggin wrote:

Excerpts from Christian Zigotzky's message of May 14, 2021 6:20 am:

On 13 May 2021 at 07:00pm, Christophe Leroy wrote:

Ah yes, I remember this problem.

Can you select CONFIG_VIRT_CPU_ACCOUNTING_GEN in your configuration ?

Otherwise, I can try to fix the branch.

Christophe

I selected this. After that it compiles.

1. git bisect good - Xorg restarts again and again
      Output: [f9aa0ac1e9e82b60401ad567bdabc30598325bc1] Revert
"powerpc/64e/interrupt: use new interrupt return"
2. git bisect good - Xorg restarts again and again
      Output: [cd6d259a14704741bf0cd1dcadb84c0de22d7f77] Revert
"powerpc/64e/interrupt: always save nvgprs on interrupt"
3. git bisect bad - Xorg works
      Output: [9bfa20ef2ae54d3b9088dfbcde4ef97062cf5ef2] Revert
"powerpc/interrupt: update common interrupt code for"
4. git bisect good - Xorg restarts again and again
      Output:

cd6d259a14704741bf0cd1dcadb84c0de22d7f77 is the first bad commit
commit cd6d259a14704741bf0cd1dcadb84c0de22d7f77
Author: Christophe Leroy 
Date:   Thu May 13 09:52:06 2021 +

      Revert "powerpc/64e/interrupt: always save nvgprs on interrupt"

      This reverts commit 4228b2c3d20e9f80b847f809c38e6cf82864fa50.

:04 04 156542c857ad72776b69bb67b2f244afeeb7abd3
92ea86ed097fce16238b0c2f2b343473894e4e8e M    arch

Thank you both very much for chasing this down.

I think I see the problem, it's clobbering r14 and r15 for some
interrupts. Something like this is required, I'll give it more
review and testing though.

Thanks,
Nick

---
diff --git a/arch/powerpc/kernel/exceptions-64e.S 
b/arch/powerpc/kernel/exceptions-64e.S
index 7c3654b0d0f4..b91ef04f1ce2 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -535,6 +535,10 @@ __end_interrupts:
PROLOG_ADDITION_2REGS)
mfspr   r14,SPRN_DEAR
mfspr   r15,SPRN_ESR
+   std r14,_DAR(r1)
+   std r15,_DSISR(r1)
+   ld  r14,PACA_EXGEN+EX_R14(r13)
+   ld  r15,PACA_EXGEN+EX_R15(r13)
EXCEPTION_COMMON(0x300)
b   storage_fault_common
  
@@ -544,6 +548,10 @@ __end_interrupts:

PROLOG_ADDITION_2REGS)
li  r15,0
mr  r14,r10
+   std r14,_DAR(r1)
+   std r15,_DSISR(r1)
+   ld  r14,PACA_EXGEN+EX_R14(r13)
+   ld  r15,PACA_EXGEN+EX_R15(r13)
EXCEPTION_COMMON(0x400)
b   storage_fault_common
  
@@ -557,6 +565,10 @@ __end_interrupts:

PROLOG_ADDITION_2REGS)
mfspr   r14,SPRN_DEAR
mfspr   r15,SPRN_ESR
+   std r14,_DAR(r1)
+   std r15,_DSISR(r1)
+   ld  r14,PACA_EXGEN+EX_R14(r13)
+   ld  r15,PACA_EXGEN+EX_R15(r13)
EXCEPTION_COMMON(0x600)
b   alignment_more  /* no room, go out of line */
  
@@ -565,10 +577,10 @@ __end_interrupts:

NORMAL_EXCEPTION_PROLOG(0x700, BOOKE_INTERRUPT_PROGRAM,
PROLOG_ADDITION_1REG)
mfspr   r14,SPRN_ESR
-   EXCEPTION_COMMON(0x700)
std r14,_DSISR(r1)
-   addir3,r1,STACK_FRAME_OVERHEAD
ld  r14,PACA_EXGEN+EX_R14(r13)
+   EXCEPTION_COMMON(0x700)
+   addir3,r1,STACK_FRAME_OVERHEAD
bl  program_check_exception
REST_NVGPRS(r1)
b   interrupt_return
@@ -725,11 +737,11 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
 * normal exception
 */
mfspr   r14,SPRN_DBSR
-   EXCEPTION_COMMON_CRIT(0xd00)
std r14,_DSISR(r1)
-   addir3,r1,STACK_FRAME_OVERHEAD
ld  r14,PACA_EXCRIT+EX_R14(r13)
ld  r15,PACA_EXCRIT+EX_R15(r13)
+   EXCEPTION_COMMON_CRIT(0xd00)
+   addir3,r1,STACK_FRAME_OVERHEAD
bl  DebugException
REST_NVGPRS(r1)
b   interrupt_return
@@ -796,11 +808,11 @@ kernel_dbg_exc:
 * normal exception
 */
mfspr   r14,SPRN_DBSR
-   EXCEPTION_COMMON_DBG(0xd08)
std r14,_DSISR(r1)
-   addir3,r1,STACK_FRAME_OVERHEAD
ld  r14,PACA_EXDBG+EX_R14(r13)
ld  r15,PACA_EXDBG+EX_R15(r13)
+   EXCEPTION_COMMON_DBG(0xd08)
+   addir3,r1,STACK_FRAME_OVERHEAD
bl  DebugException
REST_NVGPRS(r1)
b   interrupt_return
@@ -931,11 +943,7 @@ masked_interrupt_book3e_0x2c0:
   * original values stashed away in the PACA
   */
  storage_fault_common:
-   std r14,_DAR(r1)
-   std r15,_DSISR(r1)
addir3,r1,STACK_FRAME_OVERHEAD
-   ld  r14,PACA_EXGEN+EX_R14(r13)
-   ld  r15,PACA_EXGEN+EX_R15(r13)
bl  do_page_fault
b   interrupt_return
  
@@ -944,11 +952,7 @@ storage_fault_common:

   * continues here.
   */
  alignment_more:
-   std r14,_DAR(r1)
-   std r15,_DSISR(r1)
addir3,r1,STACK_FRAME_OVERHEAD
-   ld  

Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1

2021-05-13 Thread Christian Zigotzky

On 13 May 2021 at 07:00pm, Christophe Leroy wrote:



Le 13/05/2021 à 18:35, Christian Zigotzky a écrit :

On 13 May 2021 at 5:51pm, Christophe Leroy wrote:



Le 13/05/2021 à 17:19, Christian Zigotzky a écrit :

On 13 May 2021 at 12:01 pm, Christophe Leroy wrote:



Le 13/05/2021 à 08:47, Christian Zigotzky a écrit :

Hi Christophe,

On 9. May 2021, at 19:37, Christophe Leroy 
 wrote:


Did I do an error in my analysis ?


No, you didn’t. On the contrary you have found the issue. ;-) The 
issue is somewhere in the new interrupt code.


I'm not convinced, but let's give it a try.



ZZ | * | ceff77efa4f8 powerpc/64e/interrupt: Use new interrupt 
context tracking scheme


Could you please create a patch for reverting the new interrupt 
code? I would like to confirm your result.


Please fetch https://github.com/chleroy/linux.git and try the 
branch for_christian.


This is a revert of approx a dozen of commits around the changes 
to 64e on top of v5.13-rc1.


If the top of the branch works for you, it would be great if you 
can find out which one of the reverts fixes the problem for real.


Thanks
Christophe
It's working! Great! I can use the RC1 on my FSL P5040. Thank you! 
The issue is definitely somewhere in the interrupt code. Please 
tell me the next steps.




Can you bisect between 5.13-rc1 and the top of the 'for_christian' 
branch to find the first 'good' commit ?


Take care it is an "up side down" bisect, a 'good' is one that does 
_not_ work and a 'bad' is a commit that works.


git bisect start
git bisect bad 1c8f441f1485
git bisect good 6efb943b8616

Christophe

Hi Christophe,

Yes, I can. Shall I use the branch 'for_christian' or the default 
linux git for bisecting? I have tried it already with the branch 
'for_christian' but it doesn't compile.


git bisect start
git bisect bad 1c8f441f1485
git bisect good 6efb943b8616

Output: [d66b1d1aab0c1caad11eca417f515b86ec0bebe9] Revert 
"powerpc/64e/interrupt: Use new interrupt context tracking scheme"


Result:

arch/powerpc/kernel/interrupt.o: In function `.syscall_exit_prepare':
interrupt.c:(.text+0x278): undefined reference to `.schedule_user'
arch/powerpc/kernel/interrupt.o: In function 
`.interrupt_exit_user_prepare':

interrupt.c:(.text+0x340): undefined reference to `.schedule_user'
Makefile:1191: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1



Ah yes, I remember this problem.

Can you select CONFIG_VIRT_CPU_ACCOUNTING_GEN in your configuration ?

Otherwise, I can try to fix the branch.

Christophe

I selected this. After that it compiles.

1. git bisect good - Xorg restarts again and again
    Output: [f9aa0ac1e9e82b60401ad567bdabc30598325bc1] Revert 
"powerpc/64e/interrupt: use new interrupt return"

2. git bisect good - Xorg restarts again and again
    Output: [cd6d259a14704741bf0cd1dcadb84c0de22d7f77] Revert 
"powerpc/64e/interrupt: always save nvgprs on interrupt"

3. git bisect bad - Xorg works
    Output: [9bfa20ef2ae54d3b9088dfbcde4ef97062cf5ef2] Revert 
"powerpc/interrupt: update common interrupt code for"

4. git bisect good - Xorg restarts again and again
    Output:

cd6d259a14704741bf0cd1dcadb84c0de22d7f77 is the first bad commit
commit cd6d259a14704741bf0cd1dcadb84c0de22d7f77
Author: Christophe Leroy 
Date:   Thu May 13 09:52:06 2021 +

    Revert "powerpc/64e/interrupt: always save nvgprs on interrupt"

    This reverts commit 4228b2c3d20e9f80b847f809c38e6cf82864fa50.

:04 04 156542c857ad72776b69bb67b2f244afeeb7abd3 
92ea86ed097fce16238b0c2f2b343473894e4e8e M    arch


- Christian


Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1

2021-05-13 Thread Christian Zigotzky

On 13 May 2021 at 5:51pm, Christophe Leroy wrote:



Le 13/05/2021 à 17:19, Christian Zigotzky a écrit :

On 13 May 2021 at 12:01 pm, Christophe Leroy wrote:



Le 13/05/2021 à 08:47, Christian Zigotzky a écrit :

Hi Christophe,

On 9. May 2021, at 19:37, Christophe Leroy 
 wrote:


Did I do an error in my analysis ?


No, you didn’t. On the contrary you have found the issue. ;-) The 
issue is somewhere in the new interrupt code.


I'm not convinced, but let's give it a try.



ZZ | * | ceff77efa4f8 powerpc/64e/interrupt: Use new interrupt 
context tracking scheme


Could you please create a patch for reverting the new interrupt 
code? I would like to confirm your result.


Please fetch https://github.com/chleroy/linux.git and try the branch 
for_christian.


This is a revert of approx a dozen of commits around the changes to 
64e on top of v5.13-rc1.


If the top of the branch works for you, it would be great if you can 
find out which one of the reverts fixes the problem for real.


Thanks
Christophe
It's working! Great! I can use the RC1 on my FSL P5040. Thank you! 
The issue is definitely somewhere in the interrupt code. Please tell 
me the next steps.




Can you bisect between 5.13-rc1 and the top of the 'for_christian' 
branch to find the first 'good' commit ?


Take care it is an "up side down" bisect, a 'good' is one that does 
_not_ work and a 'bad' is a commit that works.


git bisect start
git bisect bad 1c8f441f1485
git bisect good 6efb943b8616

Christophe

Hi Christophe,

Yes, I can. Shall I use the branch 'for_christian' or the default linux 
git for bisecting? I have tried it already with the branch 
'for_christian' but it doesn't compile.


git bisect start
git bisect bad 1c8f441f1485
git bisect good 6efb943b8616

Output: [d66b1d1aab0c1caad11eca417f515b86ec0bebe9] Revert 
"powerpc/64e/interrupt: Use new interrupt context tracking scheme"


Result:

arch/powerpc/kernel/interrupt.o: In function `.syscall_exit_prepare':
interrupt.c:(.text+0x278): undefined reference to `.schedule_user'
arch/powerpc/kernel/interrupt.o: In function `.interrupt_exit_user_prepare':
interrupt.c:(.text+0x340): undefined reference to `.schedule_user'
Makefile:1191: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1



Thanks,
Christian


Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1

2021-05-13 Thread Christian Zigotzky

On 13 May 2021 at 12:01 pm, Christophe Leroy wrote:



Le 13/05/2021 à 08:47, Christian Zigotzky a écrit :

Hi Christophe,

On 9. May 2021, at 19:37, Christophe Leroy 
 wrote:


Did I do an error in my analysis ?


No, you didn’t. On the contrary you have found the issue. ;-) The 
issue is somewhere in the new interrupt code.


I'm not convinced, but let's give it a try.



ZZ | * | ceff77efa4f8 powerpc/64e/interrupt: Use new interrupt 
context tracking scheme


Could you please create a patch for reverting the new interrupt code? 
I would like to confirm your result.


Please fetch https://github.com/chleroy/linux.git and try the branch 
for_christian.


This is a revert of approx a dozen of commits around the changes to 
64e on top of v5.13-rc1.


If the top of the branch works for you, it would be great if you can 
find out which one of the reverts fixes the problem for real.


Thanks
Christophe
It's working! Great! I can use the RC1 on my FSL P5040. Thank you! The 
issue is definitely somewhere in the interrupt code. Please tell me the 
next steps.


- Christian


Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1

2021-05-13 Thread Christian Zigotzky
Hi Christophe,

> On 9. May 2021, at 19:37, Christophe Leroy  
> wrote:
> 
> Did I do an error in my analysis ?

No, you didn’t. On the contrary you have found the issue. ;-) The issue is 
somewhere in the new interrupt code.

> ZZ | * | ceff77efa4f8 powerpc/64e/interrupt: Use new interrupt context 
> tracking scheme

Could you please create a patch for reverting the new interrupt code? I would 
like to confirm your result.

Thanks for your help,
Christian

> 
> BAD *   c70a4be130de Merge tag 'powerpc-5.13-1' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
> |\
> | * 525642624783 powerpc/signal32: Fix erroneous SIGSEGV on RT signal return
> | * f9cd5f91a897 powerpc: Avoid clang uninitialized warning in 
> __get_user_size_allowed
> | * adb68c38d8d4 powerpc/papr_scm: Mark nvdimm as unarmed if needed during 
> probe
> | * ee1bc694fbae powerpc/kvm: Fix build error when PPC_MEM_KEYS/PPC_PSERIES=n
> | * 30c400886bad powerpc/kasan: Fix shadow start address with modules
> | * fc5590fd56c9 powerpc/kernel/iommu: Use largepool as a last resort when 
> !largealloc
> | * 3c0468d4451e powerpc/kernel/iommu: Align size for IOMMU_PAGE_SIZE() to 
> save TCEs
> | * ee6b25fa7c03 powerpc/44x: fix spelling mistake in Kconfig "varients" -> 
> "variants"
> | * cc7130bf119a powerpc/iommu: Annotate nested lock for lockdep
> | * 4be518d83880 powerpc/iommu: Do not immediately panic when failed IOMMU 
> table allocation
> | * 7f1fa82d7994 powerpc/iommu: Allocate it_map by vmalloc
> | * 0db11461677a selftests/powerpc: remove unneeded semicolon
> | * caea7b833d86 powerpc/64s: remove unneeded semicolon
> | * f3d03fc748d4 powerpc/eeh: remove unneeded semicolon
> | * 290f7d8ce2b1 powerpc/selftests: Add selftest to test concurrent 
> perf/ptrace events
> | * c65c64cc7bbd powerpc/selftests/perf-hwbreak: Add testcases for 2nd DAWR
> | * c9cb0afb4eaa powerpc/selftests/perf-hwbreak: Coalesce event creation code
> | * dae4ff8031b4 powerpc/selftests/ptrace-hwbreak: Add testcases for 2nd DAWR
> | * 421a7483878c powerpc/configs: Add IBMVNIC to some 64-bit configs
> | * da650ada1009 selftests/powerpc: Add uaccess flush test
> | * 8a87a5077143 powerpc/52xx: Fix an invalid ASM expression ('addi' used 
> instead of 'add')
> | * 0f197ddce403 powerpc/64s: Fix mm_cpumask memory ordering comment
> | * 66d9b7492887 powerpc/perf: Fix the threshold event selection for memory 
> events in power10
> | * b4ded42268ee powerpc/perf: Fix sampled instruction type for larx/stcx
> | * 0bd3f9e953bd powerpc/legacy_serial: Use early_ioremap()
> | * 9ccba66d4d2a powerpc/64: Fix the definition of the fixmap area
> | * 389586333c02 powerpc: make ALTIVEC select PPC_FPU
> | * 7d9462765707 powerpc/64s: Add FA_DUMP to defconfig
> | * d936f8182e1b powerpc/powernv: Fix type of opal_mpipl_query_tag() addr 
> argument
> | * 2e341f56a16a powerpc/fadump: Fix sparse warnings
> | * 39352430aaa0 powerpc: Move copy_inst_from_kernel_nofault()
> | * 41d6cf68b5f6 powerpc: Rename probe_kernel_read_inst()
> | * 6449078d5011 powerpc: Make probe_kernel_read_inst() common to PPC32 and 
> PPC64
> | * 6ac7897f08e0 powerpc: Remove probe_user_read_inst()
> | * ee7c3ec3b4b1 powerpc/ebpf32: Use standard function call for functions 
> within 32M distance
> | * e7de0023e123 powerpc/ebpf32: Rework 64 bits shifts to avoid tests and 
> branches
> | * d228cc496966 powerpc/ebpf32: Fix comment on BPF_ALU{64} | BPF_LSH | BPF_K
> | * 867e762480f4 powerpc/32: Use r2 in wrtspr() instead of r0
> | * f56607e85ee3 selftests/timens: Fix gettime_perf to work on powerpc
> | * 92d9d61be519 powerpc/mce: save ignore_event flag unconditionally for UE
> | * eacf4c020265 powerpc: Enable OPTPROBES on PPC32
> | * 693557ebf407 powerpc/inst: ppc_inst_as_u64() becomes ppc_inst_as_ulong()
> | * e522331173ec powerpc/irq: Enhance readability of trap types
> | * 7fab639729ce powerpc/32s: Enhance readability of trap types
> | * 0f5eb28a6ce6 powerpc/8xx: Enhance readability of trap types
> | * a9d2f9bb225f powerpc/pseries/iommu: Fix window size for direct mapping 
> with pmem
> | * e4e8bc1df691 powerpc/kvm: Fix PR KVM with KUAP/MEM_KEYS enabled
> | * ed8029d7b472 powerpc/pseries: Stop calling printk in rtas_stop_self()
> | * 3027a37c06be powerpc: Only define _TASK_CPU for 32-bit
> | * 39d0099f9439 powerpc/pseries: Add shutdown() to vio_driver and vio_bus
> | * af31fd0c9107 powerpc/perf: Expose processor pipeline stage cycles using 
> PERF_SAMPLE_WEIGHT_STRUCT
> | * 2886e2df10be Documentation/powerpc: Add proper links for manual and tests
> | * 29c9a2699e71 powerpc/pseries: Set UNISOLATE on dlpar_cpu_remove() failure
> | * 0e3b3ff83ce2 powerpc/pseries: Introduce dlpar_unisolate_drc()
> | * 864ec4d40c83 powerpc/pseries/mce: Fix a typo in error type assignment
> | * cbd3d5ba46b6 powerpc/fadump: Fix compile error since trap type change
> | * d8a1d6c58986 powerpc/perf: Add platform specific check_attr_config
> | *   a38cb4171928 Merge branch 'topic/ppc-kvm' into next
> | |\
> | | * 732f21a3053c KVM: PPC: Book3S HV: Ensure 

Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1

2021-05-09 Thread Christian Zigotzky

On 09 May 2021 at 07:43 pm, Christophe Leroy wrote:


On my side, book3e (corenet64_smp_defconfig) built with GCC 10.1 works 
well with QEMU 2.11.2


A kernel built with the configuration you provided doesn't boot on 
QEMU, no output at all, even with kernel v5.12.


What versions of GCC and QEMU are you using ?

Thanks
Christophe

Hi Christophe,

I use the following QEMU versions (qemu-system-ppc64):

- QEMU 5.0.0 (Debian 1:5.0-5) ELF 32-bit PowerPC with or without KVM on 
Debian Sid 32-bit userland with some 64-bit kernels [1] [3] [11] [12] 
[13] [14] [15] [16] [17]

- QEMU 5.2.0 ELF 64-bit x86_64 on Ubuntu 18.04 64-bit [2]
- QEMU 5.2.0 Mach-O 64-bit on macOS Catalina 10.15.7
- QEMU 5.2.0 on Windows Server 2016 [4] [5] [6] [7] [8] [9] [10]

The kernels work really well with my kernel configuration in QEMU (see 
screenshots [1] - [17]). You can also see the kernel 5.12 in virtual 
QEMU machines in the screenshots.
I work very often with my kernels in e5500 QEMU machines on Linux, 
macOS, and Windows.


I build my kernels with the GCC 7.5.0. We are testing very intensive all 
kernel builds in our test threads [18] [19] [20] and the kernel 5.12 
works very well on our AmigaOnes and in virtual

e5500 QEMU machines.

Cheers,
Christian

[1] 
https://i.pinimg.com/originals/94/a1/56/94a156481ab469dd6cd0eba97bd88855.png
[2] 
https://i.pinimg.com/originals/93/5a/97/935a9792ca4b76b569eeb40857b2162f.png
[3] 
https://i.pinimg.com/originals/c5/0d/85/c50d85d7e8f20b4caa1a439faf751964.png
[4] 
https://i.pinimg.com/originals/cb/1d/12/cb1d12610c197a5e24f4a549c4dc56fe.png
[5] 
https://i.pinimg.com/originals/46/e0/1a/46e01a5ef174cc65420d760b074e2f23.png
[6] 
https://i.pinimg.com/originals/15/3c/9c/153c9cba276542528721d313812f232a.png
[7] 
https://i.pinimg.com/originals/b7/dc/c0/b7dcc0d04d8a7d8e771c888403aa9f6f.png
[8] 
https://i.pinimg.com/originals/1f/37/0e/1f370e80ec9805c93d3bd30c0c3a6926.png
[9] 
https://i.pinimg.com/originals/7c/4b/1a/7c4b1a602a0760865a1722ef1608cedf.png
[10] 
https://i.pinimg.com/originals/c3/89/19/c3891928d359500ab5e7484357b4ab01.png
[11] 
https://i.pinimg.com/originals/e4/53/00/e4530020d4292b36cd1dd22a20f2ba93.png
[12] 
https://i.pinimg.com/originals/fa/92/5b/fa925bbe132caf6d7f84bdc4090690c6.png
[13] 
https://i.pinimg.com/originals/4f/b0/14/4fb01476edd7abe6be1e1203a8e7e152.png
[14] 
https://i.pinimg.com/originals/f1/23/a4/f123a448743b8039b0b5fba320daee7c.png
[15] 
https://i.pinimg.com/originals/6e/3b/59/6e3b59fe10276c5644b15622a81f43f1.png
[16] 
https://i.pinimg.com/originals/f2/a5/e3/f2a5e34e2015381b0cb87cc51232a8bc.png
[17] 
https://i.pinimg.com/originals/57/d9/83/57d98324cd055b7ae00a87ad5a45a42f.png

[18] https://forum.hyperion-entertainment.com/viewtopic.php?f=58=4612
[19] https://forum.hyperion-entertainment.com/viewtopic.php?f=35=4611
[20] https://forum.hyperion-entertainment.com/viewtopic.php?f=58=4564


Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1

2021-05-09 Thread Christian Zigotzky

On 08 May 2021 at 06:39pm, Christian Zigotzky wrote:

On 06 May 2021 at 03:58 pm, Christian Zigotzky wrote:

I have started bisecting again.

Link: 
https://forum.hyperion-entertainment.com/viewtopic.php?p=53106#p53106 
<https://forum.hyperion-entertainment.com/viewtopic.php?p=53106#p53106>



On 6. May 2021, at 10:09, Christophe Leroy 
 wrote:



- Can you check that 887f3ceb51cd with cherry-picked 525642624783 
has Xorg working ?

git checkout 887f3ceb51cd
git cherry-pick 525642624783

Result: Xorg works.
- Can you bisect between 887f3ceb51cd[good] and 56bec2f9d4d0[bad] to 
identify first bad commit that stops after loading the dtb and uImage ?
- Once that first bad commit is identified, can you check whether 
the preceeding commit with cherry-picked 525642624783 has Xorg 
working or not ?


Thanks
Christophe

git bisect start
git bisect good 887f3ceb51cd
git bisect bad 56bec2f9d4d0
git bisect good -- Xorg restarts again and again but we are looking 
for the first bad commit that stops the boot after loading the dtb and 
uImage.

git bisect good -- Xorg restarts again and again.
git bisect good -- Xorg restarts again and again.
git bisect good -- Xorg restarts again and again.

Result:

56bec2f9d4d05675cada96772a8a93010f4d82bf is the first bad commit
commit 56bec2f9d4d05675cada96772a8a93010f4d82bf
Author: Michael Ellerman 
Date:   Wed Mar 31 11:38:40 2021 +1100

    powerpc/mm/64s: Add _PAGE_KERNEL_ROX

    In the past we had a fallback definition for _PAGE_KERNEL_ROX, but we
    removed that in commit d82fd29c5a8c ("powerpc/mm: Distribute platform
    specific PAGE and PMD flags and definitions") and added definitions
    for each MMU family.

    However we missed adding a definition for 64s, which was not really a
    bug because it's currently not used.

    But we'd like to use PAGE_KERNEL_ROX in a future patch so add a
    definition now.

    Signed-off-by: Michael Ellerman 
    Link: 
https://lore.kernel.org/r/20210331003845.216246-1-...@ellerman.id.au


:04 04 ff8171830c08e4f99852947a5c3b62e784220a26 
85aff144e5219bce4eb6adb2ac32c6459cac22d0 M    arch


---

git cherry-pick 525642624783

Output:

powerpc/signal32: Fix erroneous SIGSEGV on RT signal return
 Author: Christophe Leroy 
 Date: Fri Apr 23 13:52:10 2021 +
 1 file changed, 2 insertions(+), 2 deletions(-)

---

Xorg works after compiling with the cherry-pick of 525642624783.

Hi All,

I compiled and tested the latest git kernel with the new PowerPC updates 
5.13-2 today. Unfortunately the Xorg issue still exists.
If I revert the PowerPC updates 5.13-1 and 5.13-2 then Xorg works 
without any problems.


Please check the BookE changes in the PowerPC updates 5.13-1 because my 
Book3S machines aren't affected by this issue.


Thanks,
Christian


Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1

2021-05-08 Thread Christian Zigotzky

On 06 May 2021 at 03:58 pm, Christian Zigotzky wrote:

I have started bisecting again.

Link: 
https://forum.hyperion-entertainment.com/viewtopic.php?p=53106#p53106 
<https://forum.hyperion-entertainment.com/viewtopic.php?p=53106#p53106>



On 6. May 2021, at 10:09, Christophe Leroy 
 wrote:



- Can you check that 887f3ceb51cd with cherry-picked 525642624783 has 
Xorg working ?

git checkout 887f3ceb51cd
git cherry-pick 525642624783

Result: Xorg works.
- Can you bisect between 887f3ceb51cd[good] and 56bec2f9d4d0[bad] to 
identify first bad commit that stops after loading the dtb and uImage ?
- Once that first bad commit is identified, can you check whether the 
preceeding commit with cherry-picked 525642624783 has Xorg working or 
not ?


Thanks
Christophe

git bisect start
git bisect good 887f3ceb51cd
git bisect bad 56bec2f9d4d0
git bisect good -- Xorg restarts again and again but we are looking for 
the first bad commit that stops the boot after loading the dtb and uImage.

git bisect good -- Xorg restarts again and again.
git bisect good -- Xorg restarts again and again.
git bisect good -- Xorg restarts again and again.

Result:

56bec2f9d4d05675cada96772a8a93010f4d82bf is the first bad commit
commit 56bec2f9d4d05675cada96772a8a93010f4d82bf
Author: Michael Ellerman 
Date:   Wed Mar 31 11:38:40 2021 +1100

    powerpc/mm/64s: Add _PAGE_KERNEL_ROX

    In the past we had a fallback definition for _PAGE_KERNEL_ROX, but we
    removed that in commit d82fd29c5a8c ("powerpc/mm: Distribute platform
    specific PAGE and PMD flags and definitions") and added definitions
    for each MMU family.

    However we missed adding a definition for 64s, which was not really a
    bug because it's currently not used.

    But we'd like to use PAGE_KERNEL_ROX in a future patch so add a
    definition now.

    Signed-off-by: Michael Ellerman 
    Link: 
https://lore.kernel.org/r/20210331003845.216246-1-...@ellerman.id.au


:04 04 ff8171830c08e4f99852947a5c3b62e784220a26 
85aff144e5219bce4eb6adb2ac32c6459cac22d0 M    arch


---

git cherry-pick 525642624783

Output:

powerpc/signal32: Fix erroneous SIGSEGV on RT signal return
 Author: Christophe Leroy 
 Date: Fri Apr 23 13:52:10 2021 +
 1 file changed, 2 insertions(+), 2 deletions(-)

---

Xorg works after compiling with the cherry-pick of 525642624783.


Re: Radeon NI: GIT kernel with the nislands_smc commit doesn't boot on a Freescale P5040 board and P.A.Semi Nemo board

2021-05-08 Thread Christian Zigotzky

Hi Gustavo,

Your patch works! Thanks a lot! I tested it with my Freescale P5040 
board and P.A.Semi Nemo board with a connected AMD Radeon HD6970 NI 
graphics cards (Cayman

XT) today.

Have a nice day,
Christian


On 07 May 2021 at 08:43am, Christian Zigotzky wrote:

Hi Gustavo,

Great! I will test it. Many thanks for your help.

Cheers,
Christian



On 7. May 2021, at 01:55, Gustavo A. R. Silva  wrote:

Hi Christian,


On 4/30/21 06:59, Christian Zigotzky wrote:
Hello,

The Nemo board (A-EON AmigaOne X1000) [1] and the FSL P5040 Cyrus+ board (A-EON 
AmigaOne X5000) [2] with installed AMD Radeon HD6970 NI graphics cards (Cayman
XT) [3] don't boot with the latest git kernel anymore after the commit 
"drm/radeon/nislands_smc.h: Replace one-element array with flexible-array 
member in
struct NISLANDS_SMC_SWSTATE branch" [4].  This git kernel boots in a virtual 
e5500 QEMU machine with a VirtIO-GPU [5].

I bisected today [6].

Result: drm/radeon/nislands_smc.h: Replace one-element array with 
flexible-array member in struct NISLANDS_SMC_SWSTATE branch
(434fb1e7444a2efc3a4ebd950c7f771ebfcffa31) [4] is the first bad commit.

I have a fix ready for this bug:
https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/commit/?h=testing/drm-nislands

I wonder if you could help me to test it with your environment, please.
It should be applied on top of mainline.

Thank you!
--
Gustavo


I was able to revert this commit [7] and after a new compiling, the kernel 
boots without any problems on my AmigaOnes.

After that I created a patch for reverting this commit for new git test 
kernels. [3]

The kernel compiles and boots with this patch on my AmigaOnes. Please find 
attached the kernel config files.

Please check the first bad commit.

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2] http://wiki.amiga.org/index.php?title=X5000
[3] https://forum.hyperion-entertainment.com/viewtopic.php?f=35=4377
[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=434fb1e7444a2efc3a4ebd950c7f771ebfcffa31
[5] qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage -drive 
format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev user,id=mynet0 
-device
virtio-net-pci,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-vga -usb 
-device usb-ehci,id=ehci -device usb-tablet -device virtio-keyboard-pci -smp 4
-vnc :1
[6] https://forum.hyperion-entertainment.com/viewtopic.php?p=53074#p53074
[7] git revert 434fb1e7444a2efc3a4ebd950c7f771ebfcffa3




Re: Radeon NI: GIT kernel with the nislands_smc commit doesn't boot on a Freescale P5040 board and P.A.Semi Nemo board

2021-05-07 Thread Christian Zigotzky
Hi Gustavo,

Great! I will test it. Many thanks for your help.

Cheers,
Christian


> On 7. May 2021, at 01:55, Gustavo A. R. Silva  wrote:
> 
> Hi Christian,
> 
>> On 4/30/21 06:59, Christian Zigotzky wrote:
>> Hello,
>> 
>> The Nemo board (A-EON AmigaOne X1000) [1] and the FSL P5040 Cyrus+ board 
>> (A-EON AmigaOne X5000) [2] with installed AMD Radeon HD6970 NI graphics 
>> cards (Cayman
>> XT) [3] don't boot with the latest git kernel anymore after the commit 
>> "drm/radeon/nislands_smc.h: Replace one-element array with flexible-array 
>> member in
>> struct NISLANDS_SMC_SWSTATE branch" [4].  This git kernel boots in a virtual 
>> e5500 QEMU machine with a VirtIO-GPU [5].
>> 
>> I bisected today [6].
>> 
>> Result: drm/radeon/nislands_smc.h: Replace one-element array with 
>> flexible-array member in struct NISLANDS_SMC_SWSTATE branch
>> (434fb1e7444a2efc3a4ebd950c7f771ebfcffa31) [4] is the first bad commit.
> 
> I have a fix ready for this bug:
> https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/commit/?h=testing/drm-nislands
> 
> I wonder if you could help me to test it with your environment, please.
> It should be applied on top of mainline.
> 
> Thank you!
> --
> Gustavo
> 
>> 
>> I was able to revert this commit [7] and after a new compiling, the kernel 
>> boots without any problems on my AmigaOnes.
>> 
>> After that I created a patch for reverting this commit for new git test 
>> kernels. [3]
>> 
>> The kernel compiles and boots with this patch on my AmigaOnes. Please find 
>> attached the kernel config files.
>> 
>> Please check the first bad commit.
>> 
>> Thanks,
>> Christian
>> 
>> [1] https://en.wikipedia.org/wiki/AmigaOne_X1000
>> [2] http://wiki.amiga.org/index.php?title=X5000
>> [3] https://forum.hyperion-entertainment.com/viewtopic.php?f=35=4377
>> [4] 
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=434fb1e7444a2efc3a4ebd950c7f771ebfcffa31
>> [5] qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage -drive 
>> format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev user,id=mynet0 
>> -device
>> virtio-net-pci,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-vga 
>> -usb -device usb-ehci,id=ehci -device usb-tablet -device virtio-keyboard-pci 
>> -smp 4
>> -vnc :1
>> [6] https://forum.hyperion-entertainment.com/viewtopic.php?p=53074#p53074
>> [7] git revert 434fb1e7444a2efc3a4ebd950c7f771ebfcffa3



Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1

2021-05-06 Thread Christian Zigotzky
I have started bisecting again.

Link: https://forum.hyperion-entertainment.com/viewtopic.php?p=53106#p53106


> On 6. May 2021, at 10:09, Christophe Leroy  
> wrote:
> 
> Hi,
> 
>> Le 06/05/2021 à 09:56, Christian Zigotzky a écrit :
>> Hi Christophe,
>> Ok, so let's summarise from my side.
>> The issue is in the PowerPC updates 5.13-1. I reverted these and after that 
>> the issue is gone.
>> We know that only BookE machines are affected. Book3S machines are working 
>> with the PowerPC updates.
>> I think it’s not directly an Xorg issue. It’s more a symptom that Xorg 
>> restarts again and again. In my point of view the changes for BookE machines 
>> in the PowerPC updates are responsible for this issue.
>> Bisecting costs a lot of time and I don’t have time for my main work anymore.
>> Bisecting is good but sometime you have to check your code yourself. We know 
>> all facts and now it’s time to check the code because of BookE compatibility.
>> @All
>> You can test it with QEMU as well. I provide some virtual machines and 
>> kernels for testing. Guys, it is really important that you test your changes 
>> before you release them.
> 
> 
> So, summary from my side:
> 
> You popped up telling that commit 887f3ceb51cd was the reason of your 
> problem. As I am the one who released that commit, I took a look, and 
> identified that 525642624783 should have fixed it.
> 
> You are working with a 64 bits kernel. My domain is 32 bits kernels.
> 
> I have no problem at all with corenet64_smp_defconfig booting QEMU with any 
> of the commits you pointed.
> 
> On my side QEMU doesn't work at all with the configuration you provided, I 
> don't get any output at all on the screen.
> 
> 
> So how can we progress ?
> 
> I know bisecting is not always easy, and for sure you must have spend a lot 
> of time with all those skipped steps. But it provided us good information 
> anyway and I'm sure we could progress quickly if you can do the few tests I 
> suggested in my last email:
> 
> - Can you check that 887f3ceb51cd with cherry-picked 525642624783 has Xorg 
> working ?
> - Can you bisect between 887f3ceb51cd[good] and 56bec2f9d4d0[bad] to identify 
> first bad commit that stops after loading the dtb and uImage ?
> - Once that first bad commit is identified, can you check whether the 
> preceeding commit with cherry-picked 525642624783 has Xorg working or not ?
> 
> Thanks
> Christophe


Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1

2021-05-06 Thread Christian Zigotzky
Hi Christophe,

Ok, so let's summarise from my side.

The issue is in the PowerPC updates 5.13-1. I reverted these and after that the 
issue is gone.
We know that only BookE machines are affected. Book3S machines are working with 
the PowerPC updates.
I think it’s not directly an Xorg issue. It’s more a symptom that Xorg restarts 
again and again. In my point of view the changes for BookE machines in the 
PowerPC updates are responsible for this issue.
Bisecting costs a lot of time and I don’t have time for my main work anymore.
Bisecting is good but sometime you have to check your code yourself. We know 
all facts and now it’s time to check the code because of BookE compatibility.

@All
You can test it with QEMU as well. I provide some virtual machines and kernels 
for testing. Guys, it is really important that you test your changes before you 
release them.

Thanks,
Christian

> On 6. May 2021, at 08:13, Christophe Leroy  
> wrote:
> 
> 
> 
>> Le 05/05/2021 à 14:43, Christian Zigotzky a écrit :
>>> On 04 May 2021 at 05:17pm, Christophe Leroy wrote:
>>> Le 04/05/2021 à 16:59, Christian Zigotzky a écrit :
>>>> On 04 May 2021 at 04:41pm Christophe Leroy wrote:
>>>>> Le 04/05/2021 à 13:02, Christian Zigotzky a écrit :
>>>>>> On 04 May 2021 at 12:07pm, Christian Zigotzky wrote:
>>>>>>> On 04 May 2021 at 11:49am, Christophe Leroy wrote:
>>>>>>> 
>>>>>>> I am bisecting currently.
>>>>>>> 
>>>>>>> $ git bisect start -- arch/powerpc
>>>>>>> $ git bisect good 887f3ceb51cd3~
>>>>>>> $ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
>>>>>> OK, there is another issue after the second bisecting step. The boot 
>>>>>> stops after loading the dtb and uImage file. I can't solve 2 issues with 
>>>>>> bisecting at the same time.
>>>>> 
>>>>> In that case, you can use 'git bisect skip' to skip the one that is not 
>>>>> booting at all.
>>>> In my point of view 'git bisect skip' isn't a good idea because I will not 
>>>> find out if the skipped commit is good or bad and maybe the first bad 
>>>> commit.
>>> 
>>> The second problem may be completely unrelated to the first one so it could 
>>> work.
>>> 
>>> In any case, if 'git bisect' finds out that the bad commit is in the middle 
>>> of a skipped area, it will tell you. So I think it is worth it.
>>> 
>>> The second solution could be to first focus on that 'boot stops after 
>>> loading problem' and try to find out which commit introduces the bug, then 
>>> which one fixes it. But it may not be necessary.
>>> 
>>> Other solution, as you were thinking that the conversion of 'booke' to C 
>>> interrupt entry/exit, you can also try around that: See if d738ee8 has the 
>>> problem and 2e2a441 doesn't have the problem.
>>> 
>>> If so, you can bisect between those two commits (There are 8 commits 
>>> inbetween).
>> Hi Christophe,
>> I am bisecting with skipping the boot issue currently. Unfortunately it 
>> seems there is another bug. I had to skip two times because the kernel 
>> didn't compile.
> 
>> Should I continue bisecting?
>> You can find the other steps (21 and higher) here: 
>> https://forum.hyperion-entertainment.com/viewtopic.php?p=53103#p53103
> 
> Ok, so let's summarise:
> 
> 887f3ceb51cd = Xorg doesn't work
> 887f3ceb51cd is the "first bad commit" identified by your first "bisect"
> 887f3ceb51cd~ = 627b72bee84d works ok
> c70a4be130de = Xorg doesn't work
> 
> Can you check that 887f3ceb51cd with cherry-picked 525642624783 has Xorg 
> working ?
> 
> Can you provide 'git bisect log' ?
> 
> It seems there is some mismatch between the commit and the description. For 
> instance, you say fd6db2892eba and 14b3c9d24a7a don't build. I see no reason 
> for that, I agree there is that build failure but with dc6231821a14, 
> 0c2472de23ae, 3db8aa10de9a and 097157e16cf8. That is fixed by ceff77efa4f8. 
> Note that that build failure should not occur if you have 
> CONFIG_CONTEXT_TRACKING, but it is not our problem for the time being.
> 
> Anyway, what I learn from your details is:
> 
> 56bec2f9d4d0 is the first one you tested which stops after loading the dtb 
> and uImage.
> 
> Can you bisect between 887f3ceb51cd[good] and 56bec2f9d4d0[bad] to identify 
> first bad commit that stops after loading the dtb and uImage ?
> 
> Once that first bad commit is identified, can you check whether the 
> preceeding commit with cherry-picked 525642624783 has Xorg working or not ?
> 
> 
> ceff77efa4f8 is the last one you tested which stops after loading the dtb and 
> uImage.
> 49c1d07fd04f is bad (Xorg not working)
> 
> Can you bisect between ceff77efa4f8[good] and 49c1d07fd04f[bad] to identify 
> first commit that doesn't stop after loading the dtb and uImage ? (Here you 
> have to make a mental exercice:
> the ones that stop after loading dtb/uImage are the 'good' and the ones 
> booting OK are the 'bad')
> 
> Once you have found out what breaks booting and what makes it work again, 
> then we should be able to progress on the investigation.
> 
> Thanks
> Christophe



Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1

2021-05-05 Thread Christian Zigotzky

On 04 May 2021 at 05:17pm, Christophe Leroy wrote:

Le 04/05/2021 à 16:59, Christian Zigotzky a écrit :

On 04 May 2021 at 04:41pm Christophe Leroy wrote:

Le 04/05/2021 à 13:02, Christian Zigotzky a écrit :

On 04 May 2021 at 12:07pm, Christian Zigotzky wrote:

On 04 May 2021 at 11:49am, Christophe Leroy wrote:

I am bisecting currently.

$ git bisect start -- arch/powerpc
$ git bisect good 887f3ceb51cd3~
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
OK, there is another issue after the second bisecting step. The 
boot stops after loading the dtb and uImage file. I can't solve 2 
issues with bisecting at the same time.


In that case, you can use 'git bisect skip' to skip the one that is 
not booting at all.
In my point of view 'git bisect skip' isn't a good idea because I 
will not find out if the skipped commit is good or bad and maybe the 
first bad commit.


The second problem may be completely unrelated to the first one so it 
could work.


In any case, if 'git bisect' finds out that the bad commit is in the 
middle of a skipped area, it will tell you. So I think it is worth it.


The second solution could be to first focus on that 'boot stops after 
loading problem' and try to find out which commit introduces the bug, 
then which one fixes it. But it may not be necessary.


Other solution, as you were thinking that the conversion of 'booke' to 
C interrupt entry/exit, you can also try around that: See if d738ee8 
has the problem and 2e2a441 doesn't have the problem.


If so, you can bisect between those two commits (There are 8 commits 
inbetween).

Hi Christophe,

I am bisecting with skipping the boot issue currently. Unfortunately it 
seems there is another bug. I had to skip two times because the kernel 
didn't compile.


Bisecting log:

1) git bisect start -- arch/powerpc

2) git bisect good 887f3ceb51cd3~

3) git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

4) git bisect bad
5) git bisect skip It stopped after loading the dtb and uImage. Maybe a 
third bug.

6) git bisect skip It stopped after loading the dtb and uImage.
7) git bisect skip It stopped after loading the dtb and uImage.
8) git bisect skip It stopped after loading the dtb and uImage.
9) git bisect skip It stopped after loading the dtb and uImage. 
([472724111f0f72042deb6a9dcee9578e5398a1a1] powerpc/iommu: Enable 
remaining IOMMU Pagesizes present in LoPAR)
10) git bisect skip It stopped after loading the dtb and uImage. 
([ceff77efa4f8d9f02d8442171b325d3b7068fe5e] powerpc/64e/interrupt: Use 
new interrupt context tracking scheme)
11) git bisect skip It stopped after loading the dtb and uImage. 
([7dcc37b3eff97379b194adb17eb9a8270512dd1d] powerpc/xive: Map one IPI 
interrupt per node)
12) git bisect skip It stopped after loading the dtb and uImage. 
([097157e16cf8bf91b9cf6fbda05d234d3599c01f] powerpc/64e/interrupt: 
reconcile irq soft-mask state in C)

13) git bisect skip It didn't compile.
Error messages:

arch/powerpc/kernel/interrupt.o: In function `.syscall_exit_prepare':
interrupt.c:(.text+0x278): undefined reference to `.schedule_user'
arch/powerpc/kernel/interrupt.o: In function `.interrupt_exit_user_prepare':
interrupt.c:(.text+0x340): undefined reference to `.schedule_user'
Makefile:1199: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1

([fd6db2892ebaa1383a93b4a609c65b96e615510a] powerpc/xive: Modernize 
XIVE-IPI domain with an 'alloc' handler)


14) git bisect skip It stopped after loading the dtb and uImage. 
([0c2472de23aea5ce9139a3e887191925759d1259] powerpc/64e/interrupt: use 
new interrupt return)
15) git bisect skip It stopped after loading the dtb and uImage. 
([097157e16cf8bf91b9cf6fbda05d234d3599c01f] powerpc/64e/interrupt: 
reconcile irq soft-mask state in C)

16) git bisect skip It didn't compile.
Error messages:

arch/powerpc/kernel/interrupt.o: In function `.syscall_exit_prepare':
interrupt.c:(.text+0x278): undefined reference to `.schedule_user'
arch/powerpc/kernel/interrupt.o: In function `.interrupt_exit_user_prepare':
interrupt.c:(.text+0x340): undefined reference to `.schedule_user'
Makefile:1199: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1

([14b3c9d24a7a5c274a9df27d245516f466d3bc5f] powerpc/syscalls: switch to 
generic syscalltbl.sh)


17) git bisect skip It stopped after loading the dtb and uImage. 
([08a022ad3dfafc7e33d4529015e14bb75179cacc] powerpc/powernv/memtrace: 
Allow mmaping trace buffers)
18) git bisect skip It stopped after loading the dtb and uImage. 
([e5d56763525e65417dad0d46572b234fa0008e40] powerpc/rtas: rename 
RTAS_RMOBUF_MAX to RTAS_USER_REGION_SIZE)
19) git bisect skip It stopped after loading the dtb and uImage. 
([98db179a78dd8379e9d2cbfc3f00224168a9344c] powerpc/64s: power4 nap 
fixup in C)
20) git bisect skip It stopped after loading the dtb and uImage. 
([c13ff6f3251318f5e1ff5b1a6d05f76996db672a] powerpc/rtas: improve 
ppc_rtas_rmo_buf_show documentation)


Should I continue bisecting?

You can find the other steps (21

Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1

2021-05-04 Thread Christian Zigotzky

Am 04.05.21 um 16:41 schrieb Christophe Leroy:



Le 04/05/2021 à 13:02, Christian Zigotzky a écrit :

Am 04.05.21 um 12:07 schrieb Christian Zigotzky:

Am 04.05.21 um 11:49 schrieb Christophe Leroy:



Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :

Am 04.05.21 um 11:11 schrieb Christophe Leroy:



Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

Am 04.05.21 um 10:58 schrieb Christophe Leroy:



Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

Hi Christophe,

Thanks for your answer but I think I don't know how it works 
with the cherry-pick.


$ git bisect start


As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc



$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c


You said that powerpc-5.13-1 is bad so you can narrow the 
search I think:


git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1


I don't understand, on my side it works. Maybe a difference 
between your version of git and mine.


In that case, just use the SHA corresponding to the merge:

git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Christophe

Do you use a BookE machine?


No I don't unfortunately, and I have tried booting in QEMU a 
kernel built with your config, but it freezes before any output.

You can use my kernels and distributions.



Ok, I'll see if I can do something with them.

In the meantime, have you been able to bisect ?

Thanks
Christophe

I am bisecting currently.

$ git bisect start -- arch/powerpc
$ git bisect good 887f3ceb51cd3~
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
OK, there is another issue after the second bisecting step. The boot 
stops after loading the dtb and uImage file. I can't solve 2 issues 
with bisecting at the same time.


In that case, you can use 'git bisect skip' to skip the one that is 
not booting at all.
In my point of view 'git bisect skip' isn't a good idea because I will 
not find out if the skipped commit is good or bad and maybe the first 
bad commit.


Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1

2021-05-04 Thread Christian Zigotzky

Am 04.05.21 um 16:48 schrieb Christophe Leroy:



Le 04/05/2021 à 15:48, Christian Zigotzky a écrit :

Am 04.05.21 um 13:02 schrieb Christian Zigotzky:

Am 04.05.21 um 12:07 schrieb Christian Zigotzky:

Am 04.05.21 um 11:49 schrieb Christophe Leroy:



Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :

Am 04.05.21 um 11:11 schrieb Christophe Leroy:



Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

Am 04.05.21 um 10:58 schrieb Christophe Leroy:



Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

Hi Christophe,

Thanks for your answer but I think I don't know how it 
works with the cherry-pick.


$ git bisect start


As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc



$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c


You said that powerpc-5.13-1 is bad so you can narrow the 
search I think:


git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1


I don't understand, on my side it works. Maybe a difference 
between your version of git and mine.


In that case, just use the SHA corresponding to the merge:

git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Christophe

Do you use a BookE machine?


No I don't unfortunately, and I have tried booting in QEMU a 
kernel built with your config, but it freezes before any output.

You can use my kernels and distributions.



Ok, I'll see if I can do something with them.

In the meantime, have you been able to bisect ?

Thanks
Christophe

I am bisecting currently.

$ git bisect start -- arch/powerpc
$ git bisect good 887f3ceb51cd3~
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
OK, there is another issue after the second bisecting step. The boot 
stops after loading the dtb and uImage file. I can't solve 2 issues 
with bisecting at the same time.

Xorg restarts again and again.

Here are some interesting error messages:

May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: segfault (11) 
at 80 nip ff6a770 lr ff6a760 code 1 in 
libglib-2.0.so.0.4800.2[feaf000+11f000]
May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: code: 4bfc9401 
3920 91210054 8061005c 2f83 419c0014 3880 4bfc93e5
May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: code: 3920 
9121005c 2f8f 419e0008 <93ef> 418e000c 81210040 913b


May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: segfault 
(11) at 8 nip 92dbc8 lr 92dae8 code 1 in packagekitd[92+51000]
May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: code: 
38800080 3be001f4 4cc63182 4802c8ad 4b64 6000 81210018 80be8048
May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: code: 
7fa6eb78 38800010 807e801c 3be0 <80e90008> 4cc63182 4802c881 
4b38


Yes it shows you get a segfault for some reason.
So yes, 887f3ceb51cd3 could have been the reason but 525642624783 
fixes it already.


Therefore I think a proper bisect is needed to identify the culprit 
commit to understand the reason and fix it.


You are running a 32 bits userspace on a 64 bits kernel ?

I use 32-bit and 64-bit userlands with 64-bit kernels. Both userlands 
are affected by the Xorg issue.


Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1

2021-05-04 Thread Christian Zigotzky

Am 04.05.21 um 13:02 schrieb Christian Zigotzky:

Am 04.05.21 um 12:07 schrieb Christian Zigotzky:

Am 04.05.21 um 11:49 schrieb Christophe Leroy:



Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :

Am 04.05.21 um 11:11 schrieb Christophe Leroy:



Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

Am 04.05.21 um 10:58 schrieb Christophe Leroy:



Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

Hi Christophe,

Thanks for your answer but I think I don't know how it works 
with the cherry-pick.


$ git bisect start


As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc



$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c


You said that powerpc-5.13-1 is bad so you can narrow the 
search I think:


git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1


I don't understand, on my side it works. Maybe a difference 
between your version of git and mine.


In that case, just use the SHA corresponding to the merge:

git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Christophe

Do you use a BookE machine?


No I don't unfortunately, and I have tried booting in QEMU a 
kernel built with your config, but it freezes before any output.

You can use my kernels and distributions.



Ok, I'll see if I can do something with them.

In the meantime, have you been able to bisect ?

Thanks
Christophe

I am bisecting currently.

$ git bisect start -- arch/powerpc
$ git bisect good 887f3ceb51cd3~
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
OK, there is another issue after the second bisecting step. The boot 
stops after loading the dtb and uImage file. I can't solve 2 issues 
with bisecting at the same time.

Xorg restarts again and again.

Here are some interesting error messages:

May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: segfault (11) at 
80 nip ff6a770 lr ff6a760 code 1 in 
libglib-2.0.so.0.4800.2[feaf000+11f000]
May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: code: 4bfc9401 
3920 91210054 8061005c 2f83 419c0014 3880 4bfc93e5
May 04 15:24:53 dc1.a-eon.tld kernel: lxsession[7255]: code: 3920 
9121005c 2f8f 419e0008 <93ef> 418e000c 81210040 913b


May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: segfault 
(11) at 8 nip 92dbc8 lr 92dae8 code 1 in packagekitd[92+51000]
May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: code: 
38800080 3be001f4 4cc63182 4802c8ad 4b64 6000 81210018 80be8048
May 04 15:37:40 mintppc.a-eon.tld kernel: packagekitd[4290]: code: 
7fa6eb78 38800010 807e801c 3be0 <80e90008> 4cc63182 4802c881 4b38


Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1

2021-05-04 Thread Christian Zigotzky

Am 04.05.21 um 12:07 schrieb Christian Zigotzky:

Am 04.05.21 um 11:49 schrieb Christophe Leroy:



Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :

Am 04.05.21 um 11:11 schrieb Christophe Leroy:



Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

Am 04.05.21 um 10:58 schrieb Christophe Leroy:



Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

Hi Christophe,

Thanks for your answer but I think I don't know how it works 
with the cherry-pick.


$ git bisect start


As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc



$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c


You said that powerpc-5.13-1 is bad so you can narrow the 
search I think:


git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1


I don't understand, on my side it works. Maybe a difference 
between your version of git and mine.


In that case, just use the SHA corresponding to the merge:

git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Christophe

Do you use a BookE machine?


No I don't unfortunately, and I have tried booting in QEMU a kernel 
built with your config, but it freezes before any output.

You can use my kernels and distributions.



Ok, I'll see if I can do something with them.

In the meantime, have you been able to bisect ?

Thanks
Christophe

I am bisecting currently.

$ git bisect start -- arch/powerpc
$ git bisect good 887f3ceb51cd3~
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c
OK, there is another issue after the second bisecting step. The boot 
stops after loading the dtb and uImage file. I can't solve 2 issues with 
bisecting at the same time.


Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1

2021-05-04 Thread Christian Zigotzky

Am 04.05.21 um 11:49 schrieb Christophe Leroy:



Le 04/05/2021 à 11:46, Christian Zigotzky a écrit :

Am 04.05.21 um 11:11 schrieb Christophe Leroy:



Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

Am 04.05.21 um 10:58 schrieb Christophe Leroy:



Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

Hi Christophe,

Thanks for your answer but I think I don't know how it works 
with the cherry-pick.


$ git bisect start


As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc



$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c


You said that powerpc-5.13-1 is bad so you can narrow the search 
I think:


git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1


I don't understand, on my side it works. Maybe a difference 
between your version of git and mine.


In that case, just use the SHA corresponding to the merge:

git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Christophe

Do you use a BookE machine?


No I don't unfortunately, and I have tried booting in QEMU a kernel 
built with your config, but it freezes before any output.

You can use my kernels and distributions.



Ok, I'll see if I can do something with them.

In the meantime, have you been able to bisect ?

Thanks
Christophe

I am bisecting currently.

$ git bisect start -- arch/powerpc
$ git bisect good 887f3ceb51cd3~
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c


Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1

2021-05-04 Thread Christian Zigotzky

Am 04.05.21 um 11:11 schrieb Christophe Leroy:



Le 04/05/2021 à 11:09, Christian Zigotzky a écrit :

Am 04.05.21 um 10:58 schrieb Christophe Leroy:



Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

Hi Christophe,

Thanks for your answer but I think I don't know how it works with 
the cherry-pick.


$ git bisect start


As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc



$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c


You said that powerpc-5.13-1 is bad so you can narrow the search I 
think:


git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1


I don't understand, on my side it works. Maybe a difference between 
your version of git and mine.


In that case, just use the SHA corresponding to the merge:

git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Christophe

Do you use a BookE machine?


No I don't unfortunately, and I have tried booting in QEMU a kernel 
built with your config, but it freezes before any output.

You can use my kernels and distributions.

Download Fedora 28 PPC64: http://www.xenosoft.de/fedora28-2.img.tar.gz
Download size: 4.1 GB
MD5 checksum: 1784ca69651531522161498720a89414

Default username and password:
Username: amigaone
Password: amigaone
Root Password: amigaone

You can start the MATE desktop with "startx".

Download MintPPC (Debian Sid) PPC32: 
http://www.xenosoft.de/MintPPC32-X5000.tar.gz

MD5 checksum: b31c1c1ca1fcf5d4cdf110c4bce11654

The password for both 'root' and 'mintppc' is 'mintppc'.

Download kernel 5.12.0 for the AmigaOne X5000 and for the virtual e5500 
QEMU machine without the bad commit: 
http://www.xenosoft.de/linux-image-5.12-X1000_X5000.tar.gz
Download git kernel for the AmigaOne X5000 and for the virtual e5500 
QEMU machine with the bad commit: 
http://www.xenosoft.de/linux-image-5.13-alpha3-X1000_X5000.tar.gz


QEMU command with KVM on the X5000: qemu-system-ppc64 -M ppce500 -cpu 
e5500 -enable-kvm -m 1024 -kernel uImage -drive 
format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev 
user,id=mynet0 -device e1000,netdev=mynet0 -append "rw root=/dev/vda" 
-device virtio-vga -device virtio-mouse-pci -device virtio-keyboard-pci 
-device pci-ohci,id=newusb -device usb-audio,bus=newusb.0 -smp 4


QEMU command for Fedora 28 without KVM and with VNC connect: 
qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage -drive 
format=raw,file=fedora28-2.img,index=0,if=virtio -netdev user,id=mynet0 
-device virtio-net-pci,netdev=mynet0 -append "rw root=/dev/vda" -device 
virtio-vga -usb -device usb-ehci,id=ehci -device usb-tablet -device 
virtio-keyboard-pci -smp 4 -vnc :1


QEMU command for MintPPC without KVM and with VNC connect: 
qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage -drive 
format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev 
user,id=mynet0 -device virtio-net-pci,netdev=mynet0 -append "rw 
root=/dev/vda" -device virtio-vga -usb -device usb-ehci,id=ehci -device 
usb-tablet -device virtio-keyboard-pci -smp 4 -vnc :1




Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1

2021-05-04 Thread Christian Zigotzky

Am 04.05.21 um 10:58 schrieb Christophe Leroy:



Le 04/05/2021 à 10:29, Christian Zigotzky a écrit :

On 04 May 2021 at 09:47am, Christophe Leroy wrote:

Hi

Le 04/05/2021 à 09:21, Christian Zigotzky a écrit :

Hi Christophe,

Thanks for your answer but I think I don't know how it works with 
the cherry-pick.


$ git bisect start


As you suspect the problem to be specific to powerpc, I can do

git bisect start -- arch/powerpc



$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c


You said that powerpc-5.13-1 is bad so you can narrow the search I 
think:


git bisect bad powerpc-5.13-1
git bisect good 887f3ceb51cd3~

I tried it but without any success.

git bisect bad powerpc-5.13-1

Output:
fatal: Needed a single revision
Bad rev input: powerpc-5.13-1


I don't understand, on my side it works. Maybe a difference between 
your version of git and mine.


In that case, just use the SHA corresponding to the merge:

git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Christophe

Do you use a BookE machine?


  1   2   3   4   5   >