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?


Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1

2021-05-04 Thread Christian Zigotzky

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

Maybe we should look in the PowerPC updates directly. The CPUs of the 
AmigaOne X5000 and virtual e5500 QEMU machine belong to BookE cpu 
family. The AmigaOne X1000 isn't affected by this issue because the PA6T 
belongs to the Book3S cpu family. [1]


I found this in the PowerPC updates 5.13-1:  - Convert 64-bit BookE to 
do interrupt entry/exit in C.


Maybe we should look more in the modified BookE files:

arch/powerpc/kernel/head_booke.h [2]
arch/powerpc/kernel/head_fsl_booke.S [3]

Please check the BookE commits in the PowerPC updates 5.13-1. You don't 
need an AmigaOne X5000 for testing because the virtual e5500 QEMU 
machine is also affected.


Thanks,
Christian

[1] https://www.kernel.org/doc/Documentation/powerpc/cpu_families.txt
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/arch/powerpc/kernel/head_booke.h?id=c70a4be130de333ea079c59da41cc959712bb01c
[3] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/arch/powerpc/kernel/head_fsl_booke.S?id=c70a4be130de333ea079c59da41cc959712bb01c








Bisecting: 2462 revisions left to test after this (roughly 11 steps)
[47a6959fa331fe892a4fc3b48ca08e92045c6bda] netfilter: allow to turn 
off xtables compat layer


$ git cherry-pick 525642624783
error: could not apply 525642624783... powerpc/signal32: Fix 
erroneous SIGSEGV on RT signal return

hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add ' or 'git rm '
hint: and commit the result with 'git commit'

How can I fix this error?


This problably means that the step is at a commit which is prior to 
the first bad commit you identified at previous step. If you narrow 
the bisect as explained above, it shouldn't happen unless git decides 
it needs to descend a branch to a merge point. In that case just do 
'git cherry-pick --abort" and go without the fix.


Note that once you have cherry picked the fix and tested the result, 
you have to apply the result to HEAD~ (the commit before the 
cherry-pick).

- git bisect good HEAD~
- git bisect bad HEAD~

Christophe




Re: [FSL P50x0] Xorg always restarts again and again after the the PowerPC updates 5.13-1

2021-05-04 Thread Christian Zigotzky

Hi Christophe,

Thanks for your answer but I think I don't know how it works with the 
cherry-pick.


$ git bisect start
$ git bisect good 68a32ba14177d4a21c4a9a941cf1d7aea86d436f
$ git bisect bad c70a4be130de333ea079c59da41cc959712bb01c

Bisecting: 2462 revisions left to test after this (roughly 11 steps)
[47a6959fa331fe892a4fc3b48ca08e92045c6bda] netfilter: allow to turn off 
xtables compat layer


$ git cherry-pick 525642624783
error: could not apply 525642624783... powerpc/signal32: Fix erroneous 
SIGSEGV on RT signal return

hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add ' or 'git rm '
hint: and commit the result with 'git commit'

How can I fix this error?

Thanks,
Christian

On 04 May 2021 at 06:56 am, Christophe Leroy wrote:



Le 04/05/2021 à 00:25, Christian Zigotzky a écrit :

Hello,

Xorg always restarts again and again after the the PowerPC updates 
5.13-1 [1] on my FSL P5040 Cyrus+ board (A-EON AmigaOne X5000) [2]. 
Xorg doesn't start anymore in a virtual e5500 QEMU machine [3].


I bisected today [4].

Result: powerpc/signal32: Convert do_setcontext[_tm]() to user access 
block (887f3ceb51cd34109ac17bfc98695162e299e657) [5] is the first bad 
commit.


Please find attached the kernel config.

Please check the first bad commit.


I'm not sure you can conclude anything here. There is a problem in 
that commit, but it is fixed by 525642624783 ("powerpc/signal32: Fix 
erroneous SIGSEGV on RT signal return") which is the last commit of 
powerpc-5.13-1.


So any bisect from there will for sure point to 887f3ceb51cd 
("powerpc/signal32: Convert do_setcontext[_tm]() to user access 
block") but that's unconclusive. If the problem is still there at the 
HEAD of powerpc-5.13-1, the problem is likely somewhere else.


I think you need to do the bisect again with a cherry-pick of 
525642624783 at each step.


Thanks
Christophe




Thanks,
Christian

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c70a4be130de333ea079c59da41cc959712bb01c 


[2] http://wiki.amiga.org/index.php?title=X5000
[3] 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
[4] 
https://forum.hyperion-entertainment.com/viewtopic.php?p=53101#p53101
[5] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=887f3ceb51cd34109ac17bfc98695162e299e657 





Re: Latest Git kernel doesn't compile because of the LINUX_VERSION_CODE issue

2021-02-26 Thread Christian Zigotzky

Hello Christophe,

Thanks a lot for compiling the latest git kernel.

I have solved the compiling issue through setting up a value for the 
SUBLEVEL variable in "a/Makefile". Before it wasn't necessary to set up 
a value for the SUBLEVEL variable.


Cheers,
Christian

On 26 February 21 at 5:10 pm, Christophe Leroy wrote:



Le 26/02/2021 à 13:34, Christian Zigotzky a écrit :

Hello,

I tried to compile the latest Git kernel today. Unfortunately it 
doesn't compile.


I have no such problem with latest git kernel.

Christophe



Error messages:

   CC  arch/powerpc/kernel/udbg_16550.o
In file included from ./include/linux/stackprotector.h:10:0,
  from arch/powerpc/kernel/smp.c:35:
./arch/powerpc/include/asm/stackprotector.h: In function 
‘boot_init_stack_canary’:
./arch/powerpc/include/asm/stackprotector.h:29:30: error: expected 
expression before ‘;’ token

   canary ^= LINUX_VERSION_CODE;
   ^
scripts/Makefile.build:271: recipe for target 
'arch/powerpc/kernel/smp.o' failed

make[2]: *** [arch/powerpc/kernel/smp.o] Error 1



drivers/media/cec/core/cec-api.c: In function ‘cec_adap_g_caps’:
drivers/media/cec/core/cec-api.c:85:35: error: expected expression 
before ‘;’ token

   caps.version = LINUX_VERSION_CODE;



I have found the bad commit. It's "Merge tag 'kbuild-v5.12' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild" 
[1]


The changes in the Makefile (a/Makefile) are responsible for the 
compiling errors. [2]


I was able to revert this bad commit. After that it compiled without 
any problems.


Could you please compile the latest Git kernel and confirm this issue?

Thanks,
Christian

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6fbd6cf85a3be127454a1ad58525a3adcf8612ab 

[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/Makefile?id=6fbd6cf85a3be127454a1ad58525a3adcf8612ab 





Latest Git kernel doesn't compile because of the LINUX_VERSION_CODE issue

2021-02-26 Thread Christian Zigotzky

Hello,

I tried to compile the latest Git kernel today. Unfortunately it doesn't 
compile.


Error messages:

  CC  arch/powerpc/kernel/udbg_16550.o
In file included from ./include/linux/stackprotector.h:10:0,
 from arch/powerpc/kernel/smp.c:35:
./arch/powerpc/include/asm/stackprotector.h: In function 
‘boot_init_stack_canary’:
./arch/powerpc/include/asm/stackprotector.h:29:30: error: expected 
expression before ‘;’ token

  canary ^= LINUX_VERSION_CODE;
  ^
scripts/Makefile.build:271: recipe for target 
'arch/powerpc/kernel/smp.o' failed

make[2]: *** [arch/powerpc/kernel/smp.o] Error 1



drivers/media/cec/core/cec-api.c: In function ‘cec_adap_g_caps’:
drivers/media/cec/core/cec-api.c:85:35: error: expected expression 
before ‘;’ token

  caps.version = LINUX_VERSION_CODE;



I have found the bad commit. It's "Merge tag 'kbuild-v5.12' of 
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild" [1]


The changes in the Makefile (a/Makefile) are responsible for the 
compiling errors. [2]


I was able to revert this bad commit. After that it compiled without any 
problems.


Could you please compile the latest Git kernel and confirm this issue?

Thanks,
Christian

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6fbd6cf85a3be127454a1ad58525a3adcf8612ab
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/Makefile?id=6fbd6cf85a3be127454a1ad58525a3adcf8612ab


Re: [PASEMI] Nemo board doesn't boot anymore because of moving pas_pci_init

2021-02-24 Thread Christian Zigotzky

On 24 February 21 at 03:17am, Oliver O'Halloran wrote:

On Wed, Feb 24, 2021 at 11:55 AM Michael Ellerman  wrote:

Olof Johansson  writes:

Hi,

On Tue, Feb 23, 2021 at 1:43 PM Christian Zigotzky
 wrote:

Hello,

The Nemo board [1] with a P.A. Semi PA6T SoC doesn't boot anymore
because of moving "pas_pci_init" to the device tree adoption [2] in the
latest PowerPC updates 5.12-1 [3].

Unfortunately the Nemo board doesn't have it in its device tree. I
reverted this commit and after that the Nemo board boots without any
problems.

What do you think about this ifdef?

#ifdef CONFIG_PPC_PASEMI_NEMO
  /*
   * Check for the Nemo motherboard here, if we are running on one
   * then pas_pci_init()
   */
  if (of_machine_is_compatible("pasemi,nemo")) {
  pas_pci_init();
  }
#endif

This is not a proper fix for the problem. Someone will need to debug
what on the pas_pci_init() codepath still needs to happen early in the
boot, even if the main PCI setup happens later.

I looked but don't see anything 100% obvious.

Possibly it's the call to isa_bridge_find_early()?

Looks like it. I think the problem stems from the use of the PIO
helpers (mainly outb()) in i8259_init() which is called from
nemo_init_IRQ(). The PIO helpers require the ISA space to be mapped
and io_isa_base to be set since they take a PIO register address
rather than an MMIO address. It looks like there's a few other legacy
embedded platforms that might have the same problem.

I guess the real fix would be to decouple the ISA base address
discovery from the PHB discovery. That should be doable since it's all
discovered via DT anyway and we only support one ISA address range,
but it's a bit of work.
Sorry because of the false statement of the boot issue. It was too late 
yesterday. If I understand it correctly then the position of the PCIE 
devices scan is at a new place. Therefore it doesn't work anymore. It 
hasn't nothing to do with the device tree adoption. We will use the 
following patch for reverting this commit for further testing the new 
kernels.


--- a/arch/powerpc/platforms/pasemi/setup.c 2021-02-23 
21:40:04.835999708 +0100
+++ b/arch/powerpc/platforms/pasemi/setup.c 2021-02-23 
21:46:04.560667045 +0100

@@ -144,6 +144,7 @@ static void __init pas_setup_arch(void)
    /* Setup SMP callback */
    smp_ops = _smp_ops;
 #endif
+   pas_pci_init();

    /* Remap SDC register for doing reset */
    /* XXXOJN This should maybe come out of the device tree */
@@ -444,7 +445,6 @@ define_machine(pasemi) {
    .name   = "PA Semi PWRficient",
    .probe  = pas_probe,
    .setup_arch = pas_setup_arch,
-   .discover_phbs  = pas_pci_init,
    .init_IRQ   = pas_init_IRQ,
    .get_irq    = mpic_get_irq,
    .restart    = pas_restart,


[PASEMI] Nemo board doesn't boot anymore because of moving pas_pci_init

2021-02-23 Thread Christian Zigotzky

Hello,

The Nemo board [1] with a P.A. Semi PA6T SoC doesn't boot anymore 
because of moving "pas_pci_init" to the device tree adoption [2] in the 
latest PowerPC updates 5.12-1 [3].


Unfortunately the Nemo board doesn't have it in its device tree. I 
reverted this commit and after that the Nemo board boots without any 
problems.


What do you think about this ifdef?

#ifdef CONFIG_PPC_PASEMI_NEMO
    /*
 * Check for the Nemo motherboard here, if we are running on one
 * then pas_pci_init()
 */
    if (of_machine_is_compatible("pasemi,nemo")) {
    pas_pci_init();
    }
#endif

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/arch/powerpc/platforms/pasemi/setup.c?id=b12b47249688915e987a9a2a393b522f86f6b7ab
[3] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b12b47249688915e987a9a2a393b522f86f6b7ab


Re: FSL P5040: KVM HV doesn't work with the RC5 of kernel 5.11

2021-02-01 Thread Christian Zigotzky

Hello,

I compiled the RC6 of kernel 5.11 today and KVM HV works again. 
Therefore I don't need the patch below anymore.


Many thanks for solving the issue,
Christian


On 27 January 2021 at 05:07pm, Christian Zigotzky wrote:

Hello,

I compiled the RC5 of kernel 5.11 today. Unfortunately KVM HV doesn't 
work anymore on my FSL P5040 board [1]. I tested it with QEMU 5.0.0 
today [2]. The virtual e5500 QEMU machine works with the "RC4 with KVM 
HV" and with the "RC5 without KVM HV". The complete system freezes if 
I use KVM HV with the RC5.


I have bisected and 785025820a6a565185ce9d47fdd8d23dbf91dee8 
(powerpc/mm/highmem: use __set_pte_at() for kmap_local()) [3] is the 
first bad commit.


I was able to revert this bad commit and after a new compiling, KVM HV 
works again.  I created a patch for reverting the commit. [4] Please 
find attached the kernel config. I use one uImage for the virtual 
machine and for the P5040 board.


Please check the first bad commit.

Thanks,
Christian


[1] http://wiki.amiga.org/index.php?title=X5000
[2] qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 1024 
-kernel uImage-5.11 -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
[3] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.11-rc5=785025820a6a565185ce9d47fdd8d23dbf91dee8

[4]
diff -rupN a/arch/powerpc/include/asm/highmem.h 
b/arch/powerpc/include/asm/highmem.h
--- a/arch/powerpc/include/asm/highmem.h    2021-01-27 
16:12:40.382164118 +0100
+++ b/arch/powerpc/include/asm/highmem.h    2021-01-27 
16:10:54.055249957 +0100

@@ -58,8 +58,6 @@ extern pte_t *pkmap_page_table;

 #define flush_cache_kmaps()    flush_cache_all()

-#define arch_kmap_local_set_pte(mm, vaddr, ptep, ptev) \
-   __set_pte_at(mm, vaddr, ptep, ptev, 1)
 #define arch_kmap_local_post_map(vaddr, pteval)    \
    local_flush_tlb_page(NULL, vaddr)
 #define arch_kmap_local_post_unmap(vaddr)  \




Re: GIT kernel with the PowerPC updates 5.11-1 doesn't boot on a FSL P5040 board and in a virtual e5500 QEMU machine

2020-12-24 Thread Christian Zigotzky

On 22 December 2020 at 02:14pm, Michael Ellerman wrote:

Christian Zigotzky  writes:
...

Download: http://www.xenosoft.de/MintPPC32-X5000.tar.gz (md5sum:
b31c1c1ca1fcf5d4cdf110c4bce11654) The password for both 'root' and
'mintppc' is 'mintppc'.

...

QEMU command without KVM on macOS Intel: 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

I was able to boot the above (on powerpc, but not using KVM), using my
fixes branch.

Please give that branch a test:
   
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/log/?h=fixes


cheers

Hello Michael,

I tested your fixes branch today and the kernel boots without any problems.

Thanks a lot for fixing the issue.

Merry Christmas,

Christian


Re: GIT kernel with the PowerPC updates 5.11-1 doesn't boot on a FSL P5040 board and in a virtual e5500 QEMU machine

2020-12-22 Thread Christian Zigotzky

Hello,

I compiled the latest Git kernel today and unfortunately the boot issue 
still exists.


I was able to reduce the patch for reverting the changes. In this way we 
know the problematic code now.


vdso-v2.patch:

diff -rupN a/arch/powerpc/kernel/vdso32/vgettimeofday.c 
b/arch/powerpc/kernel/vdso32/vgettimeofday.c
--- a/arch/powerpc/kernel/vdso32/vgettimeofday.c    2020-12-19 
00:01:16.829846652 +0100
+++ b/arch/powerpc/kernel/vdso32/vgettimeofday.c    2020-12-19 
00:00:37.817369691 +0100

@@ -10,12 +10,6 @@ int __c_kernel_clock_gettime(clockid_t c
 return __cvdso_clock_gettime32_data(vd, clock, ts);
 }

-int __c_kernel_clock_gettime64(clockid_t clock, struct 
__kernel_timespec *ts,

-               const struct vdso_data *vd)
-{
-    return __cvdso_clock_gettime_data(vd, clock, ts);
-}
-
 int __c_kernel_gettimeofday(struct __kernel_old_timeval *tv, struct 
timezone *tz,

             const struct vdso_data *vd)
 {



With this patch, the uImage boots without any problems on my FSL P5040 
board and in a virtual e5500 QEMU machine. Please check the problematic 
code.


Thanks,
Christian



On 19 December 2020 at 01:33pm, Christian Zigotzky wrote:

On 19 December 2020 at 07:49am, Christophe Leroy wrote:



Le 18/12/2020 à 23:49, Christian Zigotzky a écrit :

On 18 December 2020 at 10:25pm, Denis Kirjanov wrote:
 >
 >
 > On Friday, December 18, 2020, Christian Zigotzky 
 wrote:

 >
 > Hello,
 >
 > I compiled the latest Git kernel with the new PowerPC updates 
5.11-1 [1] today. Unfortunately this kernel doesn't boot on my FSL 
P5040 board [2] and in a virtual e5500 QEMU machine [3].

 >
 > I was able to revert the new PowerPC updates 5.11-1 [4] and 
after a new compiling, the kernel boots without any problems on my 
FSL P5040 board.

 >
 > Please check the new PowerPC updates 5.11-1.
 >
 >
 > Can you bisect the bad commit?
 >
Hello Denis,

I have bisected [5] and d0e3fc69d00d1f50d22d6b6acfc555ccda80ad1e 
(powerpc/vdso: Provide __kernel_clock_gettime64() on vdso32) [6] is 
the first bad commit.


I was able to revert this bad commit and after a new compiling, the 
kernel boots without any problems.


That's puzzling.

Can you describe the symptoms exactly ? What do you mean by "the 
kernel doesn't boot" ? Where and how does it stops booting ?

It stops during the disk initialisation.


This commit only adds a new VDSO call, for getting y2038 compliant 
time. At the time I implemented it there was no libc using it yet. Is 
your libc using it ?
I tested it with ubuntu MATE 16.04.7 LTS (32-bit userland + 64-bit 
kernel) and with Debian Sid (MintPPC and Fienix 32-bit userland + 
64-bit kernel) on my FSL P5040 board and in a virtual e5500 QEMU 
machine. How can I figure out if the libc use it?


Where can I find all the elements you are using to boot with QEMU ? 
Especially the file MintPPC32-X5000.img
Download: http://www.xenosoft.de/MintPPC32-X5000.tar.gz (md5sum: 
b31c1c1ca1fcf5d4cdf110c4bce11654) The password for both 'root' and 
'mintppc' is 'mintppc'.


QEMU command with KVM on my P5040 board: 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 without KVM on macOS Intel: 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


Can you also share you kernel config

See attachment.


Thanks
Christophe

Thanks
Christian





Re: GIT kernel with the PowerPC updates 5.11-1 doesn't boot on a FSL P5040 board and in a virtual e5500 QEMU machine

2020-12-18 Thread Christian Zigotzky

On 18 December 2020 at 11:49pm, Christian Zigotzky wrote:

On 18 December 2020 at 10:25pm, Denis Kirjanov wrote:
>
>
> On Friday, December 18, 2020, Christian Zigotzky 
 wrote:

>
> Hello,
>
> I compiled the latest Git kernel with the new PowerPC updates 
5.11-1 [1] today. Unfortunately this kernel doesn't boot on my FSL 
P5040 board [2] and in a virtual e5500 QEMU machine [3].

>
> I was able to revert the new PowerPC updates 5.11-1 [4] and 
after a new compiling, the kernel boots without any problems on my FSL 
P5040 board.

>
> Please check the new PowerPC updates 5.11-1.
>
>
> Can you bisect the bad commit?
>
Hello Denis,

I have bisected [5] and d0e3fc69d00d1f50d22d6b6acfc555ccda80ad1e 
(powerpc/vdso: Provide __kernel_clock_gettime64() on vdso32) [6] is 
the first bad commit.


I was able to revert this bad commit and after a new compiling, the 
kernel boots without any problems.


Thanks,
Christian

[5] https://forum.hyperion-entertainment.com/viewtopic.php?p=52077#p52077
[6] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d0e3fc69d00d1f50d22d6b6acfc555ccda80ad1e


>
>
>
> Thanks,
> Christian
>
>
> [1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8a5be36b9303ae167468d4f5e1b3c090b9981396

> [2] http://wiki.amiga.org/index.php?title=X5000
> [3] 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

> [4] git revert 8a5be36b9303ae167468d4f5e1b3c090b9981396 -m 1
>


Hello,

I created a patch for reverting the bad commit. I can boot the latest 
Git kernel compiled with this patch on my FSL P5040 board and in a 
virtual e5500 QEMU machine.


--
diff -rupN a/arch/powerpc/include/asm/vdso/gettimeofday.h 
b/arch/powerpc/include/asm/vdso/gettimeofday.h
--- a/arch/powerpc/include/asm/vdso/gettimeofday.h    2020-12-19 
00:01:16.825846606 +0100
+++ b/arch/powerpc/include/asm/vdso/gettimeofday.h    2020-12-19 
00:00:38.213374736 +0100

@@ -187,8 +187,6 @@ int __c_kernel_clock_getres(clockid_t cl
 #else
 int __c_kernel_clock_gettime(clockid_t clock, struct old_timespec32 *ts,
          const struct vdso_data *vd);
-int __c_kernel_clock_gettime64(clockid_t clock, struct 
__kernel_timespec *ts,

-               const struct vdso_data *vd);
 int __c_kernel_clock_getres(clockid_t clock_id, struct old_timespec32 
*res,

             const struct vdso_data *vd);
 #endif
diff -rupN a/arch/powerpc/kernel/vdso32/gettimeofday.S 
b/arch/powerpc/kernel/vdso32/gettimeofday.S
--- a/arch/powerpc/kernel/vdso32/gettimeofday.S    2020-12-19 
00:01:16.829846652 +0100
+++ b/arch/powerpc/kernel/vdso32/gettimeofday.S    2020-12-19 
00:00:37.817369691 +0100

@@ -35,15 +35,6 @@ V_FUNCTION_BEGIN(__kernel_clock_gettime)
 cvdso_call __c_kernel_clock_gettime
 V_FUNCTION_END(__kernel_clock_gettime)

-/*
- * Exact prototype of clock_gettime64()
- *
- * int __kernel_clock_gettime64(clockid_t clock_id, struct __timespec64 
*ts);

- *
- */
-V_FUNCTION_BEGIN(__kernel_clock_gettime64)
-    cvdso_call __c_kernel_clock_gettime64
-V_FUNCTION_END(__kernel_clock_gettime64)

 /*
  * Exact prototype of clock_getres()
diff -rupN a/arch/powerpc/kernel/vdso32/vdso32.lds.S 
b/arch/powerpc/kernel/vdso32/vdso32.lds.S
--- a/arch/powerpc/kernel/vdso32/vdso32.lds.S    2020-12-19 
00:01:16.829846652 +0100
+++ b/arch/powerpc/kernel/vdso32/vdso32.lds.S    2020-12-19 
00:00:38.209374686 +0100

@@ -118,7 +118,6 @@ VERSION
     __kernel_get_syscall_map;
     __kernel_gettimeofday;
     __kernel_clock_gettime;
-        __kernel_clock_gettime64;
     __kernel_clock_getres;
     __kernel_time;
     __kernel_get_tbfreq;
diff -rupN a/arch/powerpc/kernel/vdso32/vgettimeofday.c 
b/arch/powerpc/kernel/vdso32/vgettimeofday.c
--- a/arch/powerpc/kernel/vdso32/vgettimeofday.c    2020-12-19 
00:01:16.829846652 +0100
+++ b/arch/powerpc/kernel/vdso32/vgettimeofday.c    2020-12-19 
00:00:37.817369691 +0100

@@ -10,12 +10,6 @@ int __c_kernel_clock_gettime(clockid_t c
 return __cvdso_clock_gettime32_data(vd, clock, ts);
 }

-int __c_kernel_clock_gettime64(clockid_t clock, struct 
__kernel_timespec *ts,

-               const struct vdso_data *vd)
-{
-    return __cvdso_clock_gettime_data(vd, clock, ts);
-}
-
 int __c_kernel_gettimeofday(struct __kernel_old_timeval *tv, struct 
timezone *tz,

             const struct vdso_data *vd)
 {

--


Re: GIT kernel with the PowerPC updates 5.11-1 doesn't boot on a FSL P5040 board and in a virtual e5500 QEMU machine

2020-12-18 Thread Christian Zigotzky

On 18 December 2020 at 10:25pm, Denis Kirjanov wrote:
>
>
> On Friday, December 18, 2020, Christian Zigotzky 
 wrote:

>
> Hello,
>
> I compiled the latest Git kernel with the new PowerPC updates 
5.11-1 [1] today. Unfortunately this kernel doesn't boot on my FSL P5040 
board [2] and in a virtual e5500 QEMU machine [3].

>
> I was able to revert the new PowerPC updates 5.11-1 [4] and after 
a new compiling, the kernel boots without any problems on my FSL P5040 
board.

>
> Please check the new PowerPC updates 5.11-1.
>
>
> Can you bisect the bad commit?
>
Hello Denis,

I have bisected [5] and d0e3fc69d00d1f50d22d6b6acfc555ccda80ad1e 
(powerpc/vdso: Provide __kernel_clock_gettime64() on vdso32) [6] is the 
first bad commit.


I was able to revert this bad commit and after a new compiling, the 
kernel boots without any problems.


Thanks,
Christian

[5] https://forum.hyperion-entertainment.com/viewtopic.php?p=52077#p52077
[6] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d0e3fc69d00d1f50d22d6b6acfc555ccda80ad1e


>
>
>
> Thanks,
> Christian
>
>
> [1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8a5be36b9303ae167468d4f5e1b3c090b9981396

> [2] http://wiki.amiga.org/index.php?title=X5000
> [3] 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

> [4] git revert 8a5be36b9303ae167468d4f5e1b3c090b9981396 -m 1
>



GIT kernel with the PowerPC updates 5.11-1 doesn't boot on a FSL P5040 board and in a virtual e5500 QEMU machine

2020-12-18 Thread Christian Zigotzky

Hello,

I compiled the latest Git kernel with the new PowerPC updates 5.11-1 [1] 
today. Unfortunately this kernel doesn't boot on my FSL P5040 board [2] 
and in a virtual e5500 QEMU machine [3].


I was able to revert the new PowerPC updates 5.11-1 [4] and after a new 
compiling, the kernel boots without any problems on my FSL P5040 board.


Please check the new PowerPC updates 5.11-1.

Thanks,
Christian


[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8a5be36b9303ae167468d4f5e1b3c090b9981396

[2] http://wiki.amiga.org/index.php?title=X5000
[3] 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

[4] git revert 8a5be36b9303ae167468d4f5e1b3c090b9981396 -m 1


Re: [Virtual ppce500] virtio_gpu virtio0: swiotlb buffer is full

2020-08-19 Thread Christian Zigotzky

On 19 August 2020 at 06:35 am, Gerd Hoffmann wrote:

On Tue, Aug 18, 2020 at 04:41:38PM +0200, Christian Zigotzky wrote:

Hello Gerd,

I compiled a new kernel with the latest DRM misc updates today. The patch is
included in these updates.

This kernel works with the VirtIO-GPU in a virtual e5500 QEMU/KVM HV machine
on my X5000.

Unfortunately I can only use the VirtIO-GPU (Monitor: Red Hat, Inc. 8") with
a resolution of 640x480. If I set a higher resolution then the guest
disables the monitor.
I can use higher resolutions with the stable kernel 5.8 and the VirtIO-GPU.

Please check the latest DRM updates.

https://patchwork.freedesktop.org/patch/385980/

(tests & reviews & acks are welcome)

HTH,
   Gerd


Hello Gerd,

I compiled a new RC1 with our patches today. With these patches, the 
VirtIO-GPU works without any problems. I can use higher resolutions again.


Screenshot of the RC1-3 with the VirtIO-GPU in a virtual e5500 QEMU/KVM 
HV machine on my X5000: 
https://i.pinimg.com/originals/4f/b0/14/4fb01476edd7abe6be1e1203a8e7e152.png


Thanks a lot for your help!

Cheers,
Christian


Re: [Virtual ppce500] virtio_gpu virtio0: swiotlb buffer is full

2020-08-18 Thread Christian Zigotzky

On 18 August 2020 at 10:18 am, Gerd Hoffmann wrote:

On Mon, Aug 17, 2020 at 11:19:58AM +0200, Christian Zigotzky wrote:

Hello

I compiled the RC1 of kernel 5.9 today. Unfortunately the issue with the
VirtIO-GPU (see below) still exists. Therefore we still need the patch (see
below) for using the VirtIO-GPU in a virtual e5500 PPC64 QEMU machine.

It is fixed in drm-misc-next (commit 51c3b0cc32d2e17581fce5b487ee95bbe9e8270a).

Will cherry-pick into drm-misc-fixes once the branch is 5.9-based, which
in turn should bring it to 5.9-rc2 or -rc3.

take care,
   Gerd


Hello Gerd,

I compiled a new kernel with the latest DRM misc updates today. The 
patch is included in these updates.


This kernel works with the VirtIO-GPU in a virtual e5500 QEMU/KVM HV 
machine on my X5000.


Unfortunately I can only use the VirtIO-GPU (Monitor: Red Hat, Inc. 8") 
with a resolution of 640x480. If I set a higher resolution then the 
guest disables the monitor.

I can use higher resolutions with the stable kernel 5.8 and the VirtIO-GPU.

Please check the latest DRM updates.

Thanks,
Christian


Re: [Virtual ppce500] virtio_gpu virtio0: swiotlb buffer is full

2020-08-18 Thread Christian Zigotzky

On 18 August 2020 at 10:18 am, Gerd Hoffmann wrote:

On Mon, Aug 17, 2020 at 11:19:58AM +0200, Christian Zigotzky wrote:

Hello

I compiled the RC1 of kernel 5.9 today. Unfortunately the issue with the
VirtIO-GPU (see below) still exists. Therefore we still need the patch (see
below) for using the VirtIO-GPU in a virtual e5500 PPC64 QEMU machine.

It is fixed in drm-misc-next (commit 51c3b0cc32d2e17581fce5b487ee95bbe9e8270a).

Will cherry-pick into drm-misc-fixes once the branch is 5.9-based, which
in turn should bring it to 5.9-rc2 or -rc3.

take care,
   Gerd


Thank you!


Re: [Virtual ppce500] virtio_gpu virtio0: swiotlb buffer is full

2020-08-17 Thread Christian Zigotzky

Hello

I compiled the RC1 of kernel 5.9 today. Unfortunately the issue with the 
VirtIO-GPU (see below) still exists. Therefore we still need the patch 
(see below) for using the VirtIO-GPU in a virtual e5500 PPC64 QEMU machine.


Could you please check the first bad commit?

Thanks
Christian


On 12 August 2020 at 3:09 pm, Christian Zigotzky wrote:

Hello Daniel,

The VirtIO-GPU doesn't work anymore with the latest Git kernel in a 
virtual e5500 PPC64 QEMU machine [1,2] after the commit "drm/virtio: 
Call the right shmem helpers". [3]

The kernel 5.8 works with the VirtIO-GPU in this virtual machine.

I bisected today [4].

Result: drm/virtio: Call the right shmem helpers ( 
d323bb44e4d23802eb25d13de1f93f2335bd60d0) [3] is the first bad commit.


I was able to revert the first bad commit. [5] After that I compiled a 
new kernel again. Then I was able to boot Linux with this kernel in a 
virtual e5500 PPC64 QEMU machine with the VirtIO-GPU.


I created a patch. [6] With this patch I can use the VirtIO-GPU again.

Could you please check the first bad commit?

Thanks,
Christian

[1] QEMU command: qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm 
-m 1024 -kernel uImage -drive 
format=raw,file=fienix-soar_3.0-2020608-net.img,index=0,if=virtio -nic 
user,model=e1000 -append "rw root=/dev/vda2" -device virtio-vga 
-device virtio-mouse-pci -device virtio-keyboard-pci -device 
pci-ohci,id=newusb -device usb-audio,bus=newusb.0 -smp 4


[2] Error messages:

virtio_gpu virtio0: swiotlb buffer is full (sz: 4096 bytes), total 0 
(slots), used 0 (slots)

BUG: Kernel NULL pointer dereference on read at 0x0010
Faulting instruction address: 0xc00c7324
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=4K PREEMPT SMP NR_CPUS=4 QEMU e500
Modules linked in:
CPU: 2 PID: 1678 Comm: kworker/2:2 Not tainted 
5.9-a3_A-EON_X5000-11735-g06a81c1c7db9-dirty #1

Workqueue: events .virtio_gpu_dequeue_ctrl_func
NIP:  c00c7324 LR: c00c72e4 CTR: c0462930
REGS: c0003dba75e0 TRAP: 0300   Not tainted 
(5.9-a3_A-EON_X5000-11735-g06a81c1c7db9-dirty)

MSR:  90029000   CR: 24002288  XER: 
DEAR: 0010 ESR:  IRQMASK: 0
GPR00: c00c6188 c0003dba7870 c17f2300 
c0003d893010
GPR04:  0001  

GPR08:    
7f7f7f7f7f7f7f7f
GPR12: 24002284 c0003fff9200 c008c3a0 
c61566c0
GPR16:    

GPR20:    

GPR24: 0001 0011  

GPR28: c0003d893010   
c0003d893010

NIP [c00c7324] .dma_direct_unmap_sg+0x4c/0xd8
LR [c00c72e4] .dma_direct_unmap_sg+0xc/0xd8
Call Trace:
[c0003dba7870] [c0003dba7950] 0xc0003dba7950 (unreliable)
[c0003dba7920] [c00c6188] .dma_unmap_sg_attrs+0x5c/0x98
[c0003dba79d0] [c05cd438] 
.drm_gem_shmem_free_object+0x98/0xcc
[c0003dba7a50] [c06af5b4] 
.virtio_gpu_cleanup_object+0xc8/0xd4

[c0003dba7ad0] [c06ad3bc] .virtio_gpu_cmd_unref_cb+0x1c/0x30
[c0003dba7b40] [c06adab8] 
.virtio_gpu_dequeue_ctrl_func+0x208/0x28c

[c0003dba7c10] [c0086b70] .process_one_work+0x1a4/0x258
[c0003dba7cb0] [c00870f4] .worker_thread+0x214/0x284
[c0003dba7d70] [c008c4f0] .kthread+0x150/0x158
[c0003dba7e20] [c82c] .ret_from_kernel_thread+0x58/0x60
Instruction dump:
f821ff51 7cb82b78 7cdb3378 4e00 7cfa3b78 3bc0 7f9ec000 41fc0014
382100b0 81810008 7d808120 48bc1ba8  ebfc0248 833d0018 7fff4850
---[ end trace f28d194d9f0955a8 ]---

virtio_gpu virtio0: swiotlb buffer is full (sz: 4096 bytes), total 0 
(slots), used 0 (slots)
virtio_gpu virtio0: swiotlb buffer is full (sz: 16384 bytes), total 0 
(slots), used 0 (slots)


---

[3] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d323bb44e4d23802eb25d13de1f93f2335bd60d0


[4] https://forum.hyperion-entertainment.com/viewtopic.php?p=51377#p51377

[5] git revert d323bb44e4d23802eb25d13de1f93f2335bd60d0 //Output: 
[master 966950f724e4] Revert "drm/virtio: Call the right shmem 
helpers" 1 file changed, 1 insertion(+), 1 deletion(-)


[6]
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c 
b/drivers/gpu/drm/virtio/virtgpu_object.c

index 6ccbd01cd888..346cef5ce251 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -150,7 +150,7 @@ static int virtio_gpu_object_shmem_init(struct 
virtio_gpu_device *vgdev,

 if (ret < 0)
 return -EINVAL;

-    shmem->pages = drm_gem_shmem_get_pages_sgt(>base.base);
+    shmem->pages = drm_gem_shmem_get_sg_table(>base.base);
 if (!shmem->

[Virtual ppce500] virtio_gpu virtio0: swiotlb buffer is full

2020-08-12 Thread Christian Zigotzky

Hello Daniel,

The VirtIO-GPU doesn't work anymore with the latest Git kernel in a 
virtual e5500 PPC64 QEMU machine [1,2] after the commit "drm/virtio: 
Call the right shmem helpers". [3]

The kernel 5.8 works with the VirtIO-GPU in this virtual machine.

I bisected today [4].

Result: drm/virtio: Call the right shmem helpers ( 
d323bb44e4d23802eb25d13de1f93f2335bd60d0) [3] is the first bad commit.


I was able to revert the first bad commit. [5] After that I compiled a 
new kernel again. Then I was able to boot Linux with this kernel in a 
virtual e5500 PPC64 QEMU machine with the VirtIO-GPU.


I created a patch. [6] With this patch I can use the VirtIO-GPU again.

Could you please check the first bad commit?

Thanks,
Christian

[1] QEMU command: qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 
1024 -kernel uImage -drive 
format=raw,file=fienix-soar_3.0-2020608-net.img,index=0,if=virtio -nic 
user,model=e1000 -append "rw root=/dev/vda2" -device virtio-vga -device 
virtio-mouse-pci -device virtio-keyboard-pci -device pci-ohci,id=newusb 
-device usb-audio,bus=newusb.0 -smp 4


[2] Error messages:

virtio_gpu virtio0: swiotlb buffer is full (sz: 4096 bytes), total 0 
(slots), used 0 (slots)

BUG: Kernel NULL pointer dereference on read at 0x0010
Faulting instruction address: 0xc00c7324
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=4K PREEMPT SMP NR_CPUS=4 QEMU e500
Modules linked in:
CPU: 2 PID: 1678 Comm: kworker/2:2 Not tainted 
5.9-a3_A-EON_X5000-11735-g06a81c1c7db9-dirty #1

Workqueue: events .virtio_gpu_dequeue_ctrl_func
NIP:  c00c7324 LR: c00c72e4 CTR: c0462930
REGS: c0003dba75e0 TRAP: 0300   Not tainted 
(5.9-a3_A-EON_X5000-11735-g06a81c1c7db9-dirty)

MSR:  90029000   CR: 24002288  XER: 
DEAR: 0010 ESR:  IRQMASK: 0
GPR00: c00c6188 c0003dba7870 c17f2300 c0003d893010
GPR04:  0001  
GPR08:    7f7f7f7f7f7f7f7f
GPR12: 24002284 c0003fff9200 c008c3a0 c61566c0
GPR16:    
GPR20:    
GPR24: 0001 0011  
GPR28: c0003d893010   c0003d893010
NIP [c00c7324] .dma_direct_unmap_sg+0x4c/0xd8
LR [c00c72e4] .dma_direct_unmap_sg+0xc/0xd8
Call Trace:
[c0003dba7870] [c0003dba7950] 0xc0003dba7950 (unreliable)
[c0003dba7920] [c00c6188] .dma_unmap_sg_attrs+0x5c/0x98
[c0003dba79d0] [c05cd438] .drm_gem_shmem_free_object+0x98/0xcc
[c0003dba7a50] [c06af5b4] .virtio_gpu_cleanup_object+0xc8/0xd4
[c0003dba7ad0] [c06ad3bc] .virtio_gpu_cmd_unref_cb+0x1c/0x30
[c0003dba7b40] [c06adab8] 
.virtio_gpu_dequeue_ctrl_func+0x208/0x28c

[c0003dba7c10] [c0086b70] .process_one_work+0x1a4/0x258
[c0003dba7cb0] [c00870f4] .worker_thread+0x214/0x284
[c0003dba7d70] [c008c4f0] .kthread+0x150/0x158
[c0003dba7e20] [c82c] .ret_from_kernel_thread+0x58/0x60
Instruction dump:
f821ff51 7cb82b78 7cdb3378 4e00 7cfa3b78 3bc0 7f9ec000 41fc0014
382100b0 81810008 7d808120 48bc1ba8  ebfc0248 833d0018 7fff4850
---[ end trace f28d194d9f0955a8 ]---

virtio_gpu virtio0: swiotlb buffer is full (sz: 4096 bytes), total 0 
(slots), used 0 (slots)
virtio_gpu virtio0: swiotlb buffer is full (sz: 16384 bytes), total 0 
(slots), used 0 (slots)


---

[3] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d323bb44e4d23802eb25d13de1f93f2335bd60d0


[4] https://forum.hyperion-entertainment.com/viewtopic.php?p=51377#p51377

[5] git revert d323bb44e4d23802eb25d13de1f93f2335bd60d0 //Output: 
[master 966950f724e4] Revert "drm/virtio: Call the right shmem helpers" 
1 file changed, 1 insertion(+), 1 deletion(-)


[6]
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c 
b/drivers/gpu/drm/virtio/virtgpu_object.c

index 6ccbd01cd888..346cef5ce251 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -150,7 +150,7 @@ static int virtio_gpu_object_shmem_init(struct 
virtio_gpu_device *vgdev,

 if (ret < 0)
 return -EINVAL;

-    shmem->pages = drm_gem_shmem_get_pages_sgt(>base.base);
+    shmem->pages = drm_gem_shmem_get_sg_table(>base.base);
 if (!shmem->pages) {
 drm_gem_shmem_unpin(>base.base);
 return -EINVAL;
---


[Virtual ppce500] virtio_gpu virtio0: swiotlb buffer is full

2020-08-10 Thread Christian Zigotzky

Hello,

Just for info. The latest git kernel doesn't work with a virtio_gpu anymore.

QEMU command: qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 
1024 -kernel uImage -drive 
format=raw,file=fienix-soar_3.0-2020608-net.img,index=0,if=virtio -nic 
user,model=e1000 -append "rw root=/dev/vda2" -device virtio-vga -device 
virtio-mouse-pci -device virtio-keyboard-pci -device pci-ohci,id=newusb 
-device usb-audio,bus=newusb.0 -smp 4


Error messages:

virtio_gpu virtio0: swiotlb buffer is full (sz: 4096 bytes), total 0 
(slots), used 0 (slots)

BUG: Kernel NULL pointer dereference on read at 0x0010
Faulting instruction address: 0xc00c7324
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=4K PREEMPT SMP NR_CPUS=4 QEMU e500
Modules linked in:
CPU: 2 PID: 1678 Comm: kworker/2:2 Not tainted 
5.9-a3_A-EON_X5000-11735-g06a81c1c7db9-dirty #1

Workqueue: events .virtio_gpu_dequeue_ctrl_func
NIP:  c00c7324 LR: c00c72e4 CTR: c0462930
REGS: c0003dba75e0 TRAP: 0300   Not tainted 
(5.9-a3_A-EON_X5000-11735-g06a81c1c7db9-dirty)

MSR:  90029000   CR: 24002288  XER: 
DEAR: 0010 ESR:  IRQMASK: 0
GPR00: c00c6188 c0003dba7870 c17f2300 c0003d893010
GPR04:  0001  
GPR08:    7f7f7f7f7f7f7f7f
GPR12: 24002284 c0003fff9200 c008c3a0 c61566c0
GPR16:    
GPR20:    
GPR24: 0001 0011  
GPR28: c0003d893010   c0003d893010
NIP [c00c7324] .dma_direct_unmap_sg+0x4c/0xd8
LR [c00c72e4] .dma_direct_unmap_sg+0xc/0xd8
Call Trace:
[c0003dba7870] [c0003dba7950] 0xc0003dba7950 (unreliable)
[c0003dba7920] [c00c6188] .dma_unmap_sg_attrs+0x5c/0x98
[c0003dba79d0] [c05cd438] .drm_gem_shmem_free_object+0x98/0xcc
[c0003dba7a50] [c06af5b4] .virtio_gpu_cleanup_object+0xc8/0xd4
[c0003dba7ad0] [c06ad3bc] .virtio_gpu_cmd_unref_cb+0x1c/0x30
[c0003dba7b40] [c06adab8] 
.virtio_gpu_dequeue_ctrl_func+0x208/0x28c

[c0003dba7c10] [c0086b70] .process_one_work+0x1a4/0x258
[c0003dba7cb0] [c00870f4] .worker_thread+0x214/0x284
[c0003dba7d70] [c008c4f0] .kthread+0x150/0x158
[c0003dba7e20] [c82c] .ret_from_kernel_thread+0x58/0x60
Instruction dump:
f821ff51 7cb82b78 7cdb3378 4e00 7cfa3b78 3bc0 7f9ec000 41fc0014
382100b0 81810008 7d808120 48bc1ba8  ebfc0248 833d0018 7fff4850
---[ end trace f28d194d9f0955a8 ]---

virtio_gpu virtio0: swiotlb buffer is full (sz: 4096 bytes), total 0 
(slots), used 0 (slots)
virtio_gpu virtio0: swiotlb buffer is full (sz: 16384 bytes), total 0 
(slots), used 0 (slots)




The kernel 5.8 works without any problems in this virtual machine.

Could you please check the latest updates?

Thanks,
Christian


Re: [PASEMI] Nemo board doesn't boot anymore after the commit "powerpc/book3s64/pkeys: Simplify pkey disable branch"

2020-08-10 Thread Christian Zigotzky

Am 10.08.20 um 10:58 schrieb Aneesh Kumar K.V:

On 8/10/20 2:15 PM, Christian Zigotzky wrote:

Hello Aneesh,

I tested the new kernel today and unfortunately it doesn't run very 
well.


I have only one core (1 physical processor; 1 core; 2 threads) 
instead of two cores (1 physical processor; 2 cores; 2 threads) so 
the system is slower.


Boot log: http://www.xenosoft.de/dmesg_nemo_board_kernel_5.9.txt

Could you please check the updates?



modified   arch/powerpc/mm/book3s64/hash_utils.c
@@ -1116,7 +1116,8 @@ void hash__early_init_mmu_secondary(void)
 tlbiel_all();

 #ifdef CONFIG_PPC_MEM_KEYS
-    mtspr(SPRN_UAMOR, default_uamor);
+    if (mmu_has_feature(MMU_FTR_PKEY))
+    mtspr(SPRN_UAMOR, default_uamor);
 #endif
 }
 #endif /* CONFIG_SMP */



-aneesh

Hello Aneesh,

Your modifications work! I have 2 cores again and I can see the boot 
messages.


Thanks a lot!

Cheers,
Christian


Re: [PASEMI] Nemo board doesn't boot anymore after the commit "powerpc/book3s64/pkeys: Simplify pkey disable branch"

2020-08-10 Thread Christian Zigotzky

Hello Aneesh,

I tested the new kernel today and unfortunately it doesn't run very well.

I have only one core (1 physical processor; 1 core; 2 threads) instead 
of two cores (1 physical processor; 2 cores; 2 threads) so the system is 
slower.


Boot log: http://www.xenosoft.de/dmesg_nemo_board_kernel_5.9.txt

Could you please check the updates?

Thanks,
Christian


On 10 August 2020 at 09:56 am, Christian Zigotzky wrote:

Hello Aneesh,

The Nemo board boots with your patch but unfortunately I don't see any 
boot messages anymore.


Please find attached the kernel config.

Thanks,
Christian


On 09 August 2020 at 5:49 pm, Christian Zigotzky wrote:

Hello Aneesh,

Many thanks for your fast response and thanks a lot for your patch!
I will patch and compile a new git kernel tomorrow. I am looking 
forward to the result.


Have a nice day!

Cheers,
Christian

On 9. Aug 2020, at 17:11, Aneesh Kumar K.V 
 wrote:


"Aneesh Kumar K.V"  writes:


On 8/9/20 8:04 PM, Aneesh Kumar K.V wrote:
On 8/9/20 7:42 PM, Christian Zigotzky wrote:

Hello,

The Nemo board (A-EON AmigaOne X1000) [1] doesn't start with the
latest Git kernel anymore after the commit "powerpc/book3s64/pkeys:
Simplify pkey disable branch" [2].

I bisected today [3].

Result: powerpc/book3s64/pkeys: Simplify pkey disable branch
(a4678d4b477c3d2901f101986ca01406f3b7eaea) [2] is the first bad 
commit.


Unfortunately I wasn't able to revert the first bad commit. The 
first
bad commit depends on many other commits, which unfortunately I 
don't
know. I tried to remove the modifications of the files from the 
first
bad commit but without any success. There are just too many 
dependencies.


Additionally I reverted the commit "selftests/powerpc: Fix pkey
syscall redefinitions" [4] and compiled a new kernel but without any
success.

Could you please check the first bad commit?

Thanks,
Christian



Can you share a successful boot log of the system so that i can 
double

check the cpu_feature and mmu_feature reported ? I am looking for
details similar to below.

[    0.00] cpu_features  = 0x0001c07f8f5f91a7
[    0.00]   possible    = 0x0001fbffcf5fb1a7
[    0.00]   always  = 0x0003800081a1
[    0.00] cpu_user_features = 0xdc0065c2 0xefe0
[    0.00] mmu_features  = 0x7c006001
[    0.00] firmware_features = 0x001fc45bfc57
[    0.00] vmalloc start = 0xc008
[    0.00] IO start  = 0xc00a
[    0.00] vmemmap start = 0xc00c


IIUC this is P5+? (ISA 2.04). On that pkey should be marked 
disabled via


static int scan_pkey_feature(void)
{
 int ret;
 int pkeys_total = 0;

 

 /*
  * Only P7 and above supports SPRN_AMR update with MSR[PR] = 1
  */
 if (!early_cpu_has_feature(CPU_FTR_ARCH_206))
 return 0;


}

Can you boot with CONFIG_PPC_MEM_KEYS=n ?


Can you try this change on top of master?


modified   arch/powerpc/mm/book3s64/pkeys.c
@@ -215,10 +215,6 @@ void __init pkey_early_init_devtree(void)

  pr_info("Enabling pkeys with max key count %d\n", num_pkey);
  out:
-    /*
- * Setup uamor on boot cpu
- */
-    mtspr(SPRN_UAMOR, default_uamor);

  return;
  }


Full patch with better description.

commit 919a177bcdaf1eaeaeecc0d0f50a688629d7b5df
Author: Aneesh Kumar K.V 
Date:   Sun Aug 9 20:37:38 2020 +0530

    powerpc/pkeys: Fix boot failures with Nemo board (A-EON AmigaOne 
X1000)


    On p6 and before we should avoid updating UAMOR SPRN. This resulted
    in boot failure on Nemo board.

    Fixes: 269e829f48a0 ("powerpc/book3s64/pkey: Disable pkey on 
POWER6 and before")

    Reported-by: Christian Zigotzky 
    Signed-off-by: Aneesh Kumar K.V 

diff --git a/arch/powerpc/mm/book3s64/pkeys.c 
b/arch/powerpc/mm/book3s64/pkeys.c

index 69a6b87f2bb4..b1d091a97611 100644
--- a/arch/powerpc/mm/book3s64/pkeys.c
+++ b/arch/powerpc/mm/book3s64/pkeys.c
@@ -73,12 +73,6 @@ static int scan_pkey_feature(void)
    if (early_radix_enabled())
    return 0;

-    /*
- * Only P7 and above supports SPRN_AMR update with MSR[PR] = 1
- */
-    if (!early_cpu_has_feature(CPU_FTR_ARCH_206))
-    return 0;
-
    ret = of_scan_flat_dt(dt_scan_storage_keys, _total);
    if (ret == 0) {
    /*
@@ -124,6 +118,12 @@ void __init pkey_early_init_devtree(void)
 __builtin_popcountl(ARCH_VM_PKEY_FLAGS >> VM_PKEY_SHIFT)
    != (sizeof(u64) * BITS_PER_BYTE));

+    /*
+ * Only P7 and above supports SPRN_AMR update with MSR[PR] = 1
+ */
+    if (!early_cpu_has_feature(CPU_FTR_ARCH_206))
+    return;
+
    /* scan the device tree for pkey feature */
    pkeys_total = scan_pkey_feature();
    if (!pkeys_total)






[PASEMI] Nemo board doesn't boot anymore after the commit "powerpc/book3s64/pkeys: Simplify pkey disable branch"

2020-08-09 Thread Christian Zigotzky

Hello,

The Nemo board (A-EON AmigaOne X1000) [1] doesn't start with the latest 
Git kernel anymore after the commit "powerpc/book3s64/pkeys: Simplify 
pkey disable branch" [2].


I bisected today [3].

Result: powerpc/book3s64/pkeys: Simplify pkey disable branch 
(a4678d4b477c3d2901f101986ca01406f3b7eaea) [2] is the first bad commit.


Unfortunately I wasn't able to revert the first bad commit. The first 
bad commit depends on many other commits, which unfortunately I don't 
know. I tried to remove the modifications of the files from the first 
bad commit but without any success. There are just too many dependencies.


Additionally I reverted the commit "selftests/powerpc: Fix pkey syscall 
redefinitions" [4] and compiled a new kernel but without any success.


Could you please check the first bad commit?

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=a4678d4b477c3d2901f101986ca01406f3b7eaea

[3] https://forum.hyperion-entertainment.com/viewtopic.php?p=51340#p51340
[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a7aaa2f26bfd932a654706b19859e7adf802bee2


Re: [Latest Git kernel/Linux-next kernel] Xorg doesn't start after the seccomp updates v5.9-rc1

2020-08-07 Thread Christian Zigotzky
Hi Kees,

Thanks a lot for your patch! I think your patch works because I can patch the 
Git source code but the kernel doesn’t boot. In my point of view your 
modifications aren’t responsible for this second issue. The kernel can’t 
initialize the graphics card anymore. I think the latest DRM updates are 
responsible for the second issue. Because of this second issue I can’t test 
your patch.

Please test the latest Git kernel.

Thanks,
Christian

> On 7. Aug 2020, at 19:45, Kees Cook  wrote:
> 
> On Fri, Aug 07, 2020 at 04:45:14PM +0200, Christian Zigotzky wrote:
>> But Xorg works on Ubuntu 10.04.4 (PowerPC 32-bit), openSUSE Tumbleweed
>> 20190722 PPC64 and on Fedora 27 PPC64 with the latest Git kernel.
>> 
>> I bisected today [4].
>> 
>> Result: net/scm: Regularize compat handling of scm_detach_fds()
>> (c0029de50982c1fb215330a5f9d433cec0cfd8cc) [5] is the first bad commit.
>> 
>> This commit has been merged with the seccomp updates v5.9-rc1 on 2020-08-04
>> 14:11:08 -0700 [1]. Since these updates, Xorg doesn't start anymore on some
>> Linux distributions.
> 
> Hi! Thanks for bisecting; yes, sorry for the trouble (I'm still trying
> to understand why my compat tests _passed_...). Regardless, can you try
> this patch:
> 
> https://lore.kernel.org/lkml/20200807173609.GJ4402@mussarela/
> 
> -- 
> Kees Cook


[Latest Git kernel/Linux-next kernel] Xorg doesn't start after the seccomp updates v5.9-rc1

2020-08-07 Thread Christian Zigotzky

Hello,

Xorg doesn't start with the latest Git kernel anymore on some Linux 
distributions after the seccomp updates v5.9-rc1 [1]. For example on 
Fienix (Debian Sid PowerPC 32-bit) and on ubuntu MATE 16.04.6 (PowerPC 
32-bit). I tested these distributions on the A-EON AmigaOne X1000 [2], 
A-EON AmigaOne X5000 [3], and in a virtual e5500 QEMU machine with a 
virtio_gpu.


Error messages:

systemd-journald[2238]: Failed to send WATCHDOG-1 notification message: 
Connection refused
systemd-journald[2238]: Failed to send WATCHDOG-1 notification message: 
Transport endpoint is not connected
systemd-journald[2238]: Failed to send WATCHDOG-1 notification message: 
Transport endpoint is not connected
systemd-journald[2238]: Failed to send WATCHDOG-1 notification message: 
Transport endpoint is not connected
systemd-journald[2238]: Failed to send WATCHDOG-1 notification message: 
Transport endpoint is not connected
systemd-journald[2238]: Failed to send WATCHDOG-1 notification message: 
Transport endpoint is not connected


---

But Xorg works on Ubuntu 10.04.4 (PowerPC 32-bit), openSUSE Tumbleweed 
20190722 PPC64 and on Fedora 27 PPC64 with the latest Git kernel.


I bisected today [4].

Result: net/scm: Regularize compat handling of scm_detach_fds() 
(c0029de50982c1fb215330a5f9d433cec0cfd8cc) [5] is the first bad commit.


This commit has been merged with the seccomp updates v5.9-rc1 on 
2020-08-04 14:11:08 -0700 [1]. Since these updates, Xorg doesn't start 
anymore on some Linux distributions.


Unfortunately I wasn't able to revert the first bad commit. The first 
bad commit depends on many other commits, which unfortunately I don't 
know. I tried to remove the modifications of the files from the first 
bad commit but without any success. There are just too many dependencies.


Additionally I compiled a linux-next kernel because of the issue with 
the lastest Git kernel. Unfortunately this kernel doesn't boot. It can't 
initialize the graphics card.


Could you please test Xorg with the latest Git kernel on some Linux 
distributions?


Thanks,
Christian


[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9ecc6ea491f0c0531ad81ef9466284df260b2227

[2] https://en.wikipedia.org/wiki/AmigaOne_X1000
[3] http://wiki.amiga.org/index.php?title=X5000
[4] https://forum.hyperion-entertainment.com/viewtopic.php?p=51317#p51317
[5] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c0029de50982c1fb215330a5f9d433cec0cfd8cc





Re: FSL P5020/P5040: DPAA Ethernet issue with the latest Git kernel

2020-07-08 Thread Christian Zigotzky

On 08 July 2020 at 08:03 am, Madalin Bucur (OSS) wrote:

From: Christian Zigotzky 
Sent: Tuesday, July 7, 2020 9:26 PM
To: Madalin Bucur (OSS) 
Cc: mad skateman ; Camelia Alexandra Groza 
;
linuxppc-...@ozlabs.org; net...@vger.kernel.org; R.T.Dickinson 
;
Darren Stevens 
Subject: Re: FSL P5020/P5040: DPAA Ethernet issue with the latest Git kernel


On 7. Jul 2020, at 17:53, Madalin Bucur (OSS) 
<mailto:madalin.bu...@oss.nxp.com> wrote:
Was DPAA functional before commit A?
How about after commit A and before commit B?
The DPAA Ethernet works from  the kernel 5.6-rc4 [1] till the Git kernel from 
the
11 of June [2]. It doesn’t work since the commit “fix bitmap_parse” [3].
[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=49936#p49936
[2] https://forum.hyperion-entertainment.com/viewtopic.php?p=50848#p50848
[3] https://forum.hyperion-entertainment.com/viewtopic.php?p=50980#p50980

Hi,

can you please try to disable the network manager (see [1]), then boot with
the latest kernel, that does not work, and setup the interfaces manually?

Madalin

[1] 
https://help.ubuntu.com/community/NetworkManager#Stopping_and_Disabling_NetworkManager


@Skateman
I will compile the latest Git kernel after the 17th. Could you please 
test it without the NetworkManager?


Thanks


Re: FSL P5020/P5040: DPAA Ethernet issue with the latest Git kernel

2020-07-07 Thread Christian Zigotzky

> On 7. Jul 2020, at 17:53, Madalin Bucur (OSS)  
> wrote:
> 
> Was DPAA functional before commit A?
> How about after commit A and before commit B?

The DPAA Ethernet works from  the kernel 5.6-rc4 [1] till the Git kernel from 
the 11 of June [2]. It doesn’t work since the commit “fix bitmap_parse” [3].

[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=49936#p49936
[2] https://forum.hyperion-entertainment.com/viewtopic.php?p=50848#p50848
[3] https://forum.hyperion-entertainment.com/viewtopic.php?p=50980#p50980



Re: FSL P5020/P5040: DPAA Ethernet issue with the latest Git kernel

2020-07-07 Thread Christian Zigotzky

On 25 June 2020 at 12:22 pm, Alexander Gordeev wrote:

On Thu, Jun 25, 2020 at 01:01:52AM +0200, Christian Zigotzky wrote:
[...]

I compiled a test kernel with the option "CONFIG_TEST_BITMAP=y"
yesterday. After that Skateman and I booted it and looked for the
bitmap tests with "dmesg | grep -i bitmap".

Results:

FSL P5020:

[    0.297756] test_bitmap: loaded.
[    0.298113] test_bitmap: parselist: 14: input is '0-2047:128/256'
OK, Time: 562
[    0.298142] test_bitmap: parselist_user: 14: input is
'0-2047:128/256' OK, Time: 761
[    0.301553] test_bitmap: all 1663 tests passed

FSL P5040:

[    0.296563] test_bitmap: loaded.
[    0.296894] test_bitmap: parselist: 14: input is '0-2047:128/256'
OK, Time: 540
[    0.296920] test_bitmap: parselist_user: 14: input is
'0-2047:128/256' OK, Time: 680
[    0.24] test_bitmap: all 1663 tests passed

Thanks for the test! So it works as expected.

I would suggest to compare what is going on on the device probing
with and without the bisected commit.

There seems to be MAC and PHY mode initialization issue that might
resulted from the bitmap format change.

I put Madalin and Sascha on CC as they have done some works on
this part recently.

Thanks!



Hi All,

The issue still exists [1] so we still need the dpaa patch [2]. Could 
you please check the problematic commit [3]?


Thanks,
Christian

[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=50885#p50885
[2] https://forum.hyperion-entertainment.com/viewtopic.php?p=50982#p50982
[3] https://forum.hyperion-entertainment.com/viewtopic.php?p=50980#p50980


Re: PowerPC KVM-PR issue

2020-06-25 Thread Christian Zigotzky

On 15 June 2020 at 01:39 pm, Christian Zigotzky wrote:

On 14 June 2020 at 04:52 pm, Christian Zigotzky wrote:

On 14 June 2020 at 02:53 pm, Nicholas Piggin wrote:

Excerpts from Christian Zigotzky's message of June 12, 2020 11:01 pm:

On 11 June 2020 at 04:47 pm, Christian Zigotzky wrote:

On 10 June 2020 at 01:23 pm, Christian Zigotzky wrote:

On 10 June 2020 at 11:06 am, Christian Zigotzky wrote:

On 10 June 2020 at 00:18 am, Christian Zigotzky wrote:

Hello,

KVM-PR doesn't work anymore on my Nemo board [1]. I figured out
that the Git kernels and the kernel 5.7 are affected.

Error message: Fienix kernel: kvmppc_exit_pr_progint: emulation at
700 failed ()

I can boot virtual QEMU PowerPC machines with KVM-PR with the
kernel 5.6 without any problems on my Nemo board.

I tested it with QEMU 2.5.0 and QEMU 5.0.0 today.

Could you please check KVM-PR on your PowerPC machine?

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
I figured out that the PowerPC updates 5.7-1 [1] are responsible 
for

the KVM-PR issue. Please test KVM-PR on your PowerPC machines and
check the PowerPC updates 5.7-1 [1].

Thanks

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d38c07afc356ddebaa3ed8ecb3f553340e05c969 





I tested the latest Git kernel with Mac-on-Linux/KVM-PR today.
Unfortunately I can't use KVM-PR with MoL anymore because of this
issue (see screenshots [1]). Please check the PowerPC updates 5.7-1.

Thanks

[1]
-
https://i.pinimg.com/originals/0c/b3/64/0cb364a40241fa2b7f297d4272bbb8b7.png 


-
https://i.pinimg.com/originals/9a/61/d1/9a61d170b1c9f514f7a78a3014ffd18f.png 




Hi All,

I bisected today because of the KVM-PR issue.

Result:

9600f261acaaabd476d7833cec2dd20f2919f1a0 is the first bad commit
commit 9600f261acaaabd476d7833cec2dd20f2919f1a0
Author: Nicholas Piggin 
Date:   Wed Feb 26 03:35:21 2020 +1000

 powerpc/64s/exception: Move KVM test to common code

 This allows more code to be moved out of unrelocated regions. 
The
 system call KVMTEST is changed to be open-coded and remain in 
the

 tramp area to avoid having to move it to entry_64.S. The custom
nature
 of the system call entry code means the hcall case can be 
made more

 streamlined than regular interrupt handlers.

 mpe: Incorporate fix from Nick:

 Moving KVM test to the common entry code missed the case of 
HMI and
 MCE, which do not do __GEN_COMMON_ENTRY (because they don't 
want to

 switch to virt mode).

 This means a MCE or HMI exception that is taken while KVM is
running a
 guest context will not be switched out of that context, and 
KVM won't
 be notified. Found by running sigfuz in guest with patched 
host on
 POWER9 DD2.3, which causes some TM related HMI interrupts 
(which are

 expected and supposed to be handled by KVM).

 This fix adds a __GEN_REALMODE_COMMON_ENTRY for those 
handlers to add
 the KVM test. This makes them look a little more like other 
handlers

 that all use __GEN_COMMON_ENTRY.

 Signed-off-by: Nicholas Piggin 
 Signed-off-by: Michael Ellerman 
 Link:
https://lore.kernel.org/r/20200225173541.1549955-13-npig...@gmail.com

:04 04 ec21cec22d165f8696d69532734cb2985d532cb0
87dd49a9cd7202ec79350e8ca26cea01f1dbd93d M    arch

-

The following commit is the problem: powerpc/64s/exception: Move KVM
test to common code [1]

These changes were included in the PowerPC updates 5.7-1. [2]

Another test:

git checkout d38c07afc356ddebaa3ed8ecb3f553340e05c969 (PowerPC 
updates

5.7-1 [2] ) -> KVM-PR doesn't work.

After that: git revert d38c07afc356ddebaa3ed8ecb3f553340e05c969 -m 1
-> KVM-PR works.

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

Thanks,
Christian


[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9600f261acaaabd476d7833cec2dd20f2919f1a0 


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


Hi All,

I tried to revert the __GEN_REALMODE_COMMON_ENTRY fix for the 
latest Git

kernel and for the stable kernel 5.7.2 but without any success. There
was lot of restructuring work during the kernel 5.7 development 
time in

the PowerPC area so it isn't possible reactivate the old code. That
means we have lost the whole KVM-PR support. I also reported this 
issue

to Alexander Graf two days ago. He wrote: "Howdy :). It looks pretty
broken. Have you ever made a bisect to see where the problem comes 
from?"


Please check the KVM-PR code.

Does this patch fix it for you?

The CTR register reload in the KVM interrupt path used the wrong save
area for SLB (and NMI) interrupts.

Fixes: 9600f261acaaa ("powerpc/64s/exception: Move KVM test to 
common code")

Reported-by: Christian Zigotzky 
Signed-off-by: Nicholas Piggin 
---
  arch/powerpc/kernel/exceptions-64s.S | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff -

FSL P5020/P5040: DPAA Ethernet issue with the latest Git kernel

2020-06-21 Thread Christian Zigotzky
Hello Alexander,

The DPAA Ethernet doesn’t work anymore on our FSL P5020/P5040 boards [1] since 
the RC1 of kernel 5.8 [2].
We bisected last days [3] and found the problematic commit [4]. I was able to 
revert it [5]. After that the DPAA Ethernet works again. I created a patch for 
reverting the commit [5]. This patch works and I will use it for the RC2.
Could you please check your commit? [4]

Thanks,
Christian

[1] http://wiki.amiga.org/index.php?title=X5000
[2] https://forum.hyperion-entertainment.com/viewtopic.php?p=50885#p50885
[3] https://forum.hyperion-entertainment.com/viewtopic.php?p=50892#p50892
[4] lib: fix bitmap_parse() on 64-bit big endian archs: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=81c4f4d924d5d009b5ed785a3e22b18d0f7b831f
[5] https://forum.hyperion-entertainment.com/viewtopic.php?p=50982#p50982




Re: PowerPC KVM-PR issue

2020-06-15 Thread Christian Zigotzky

On 15 June 2020 at 01:39 am, Christian Zigotzky wrote:

On 14 June 2020 at 04:52 pm, Christian Zigotzky wrote:

On 14 June 2020 at 02:53 pm, Nicholas Piggin wrote:

Excerpts from Christian Zigotzky's message of June 12, 2020 11:01 pm:

On 11 June 2020 at 04:47 pm, Christian Zigotzky wrote:

On 10 June 2020 at 01:23 pm, Christian Zigotzky wrote:

On 10 June 2020 at 11:06 am, Christian Zigotzky wrote:

On 10 June 2020 at 00:18 am, Christian Zigotzky wrote:

Hello,

KVM-PR doesn't work anymore on my Nemo board [1]. I figured out
that the Git kernels and the kernel 5.7 are affected.

Error message: Fienix kernel: kvmppc_exit_pr_progint: emulation at
700 failed ()

I can boot virtual QEMU PowerPC machines with KVM-PR with the
kernel 5.6 without any problems on my Nemo board.

I tested it with QEMU 2.5.0 and QEMU 5.0.0 today.

Could you please check KVM-PR on your PowerPC machine?

Thanks,
Christian

[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
I figured out that the PowerPC updates 5.7-1 [1] are responsible 
for

the KVM-PR issue. Please test KVM-PR on your PowerPC machines and
check the PowerPC updates 5.7-1 [1].

Thanks

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d38c07afc356ddebaa3ed8ecb3f553340e05c969 





I tested the latest Git kernel with Mac-on-Linux/KVM-PR today.
Unfortunately I can't use KVM-PR with MoL anymore because of this
issue (see screenshots [1]). Please check the PowerPC updates 5.7-1.

Thanks

[1]
-
https://i.pinimg.com/originals/0c/b3/64/0cb364a40241fa2b7f297d4272bbb8b7.png 


-
https://i.pinimg.com/originals/9a/61/d1/9a61d170b1c9f514f7a78a3014ffd18f.png 




Hi All,

I bisected today because of the KVM-PR issue.

Result:

9600f261acaaabd476d7833cec2dd20f2919f1a0 is the first bad commit
commit 9600f261acaaabd476d7833cec2dd20f2919f1a0
Author: Nicholas Piggin 
Date:   Wed Feb 26 03:35:21 2020 +1000

 powerpc/64s/exception: Move KVM test to common code

 This allows more code to be moved out of unrelocated regions. 
The
 system call KVMTEST is changed to be open-coded and remain in 
the

 tramp area to avoid having to move it to entry_64.S. The custom
nature
 of the system call entry code means the hcall case can be 
made more

 streamlined than regular interrupt handlers.

 mpe: Incorporate fix from Nick:

 Moving KVM test to the common entry code missed the case of 
HMI and
 MCE, which do not do __GEN_COMMON_ENTRY (because they don't 
want to

 switch to virt mode).

 This means a MCE or HMI exception that is taken while KVM is
running a
 guest context will not be switched out of that context, and 
KVM won't
 be notified. Found by running sigfuz in guest with patched 
host on
 POWER9 DD2.3, which causes some TM related HMI interrupts 
(which are

 expected and supposed to be handled by KVM).

 This fix adds a __GEN_REALMODE_COMMON_ENTRY for those 
handlers to add
 the KVM test. This makes them look a little more like other 
handlers

 that all use __GEN_COMMON_ENTRY.

 Signed-off-by: Nicholas Piggin 
 Signed-off-by: Michael Ellerman 
 Link:
https://lore.kernel.org/r/20200225173541.1549955-13-npig...@gmail.com

:04 04 ec21cec22d165f8696d69532734cb2985d532cb0
87dd49a9cd7202ec79350e8ca26cea01f1dbd93d M    arch

-

The following commit is the problem: powerpc/64s/exception: Move KVM
test to common code [1]

These changes were included in the PowerPC updates 5.7-1. [2]

Another test:

git checkout d38c07afc356ddebaa3ed8ecb3f553340e05c969 (PowerPC 
updates

5.7-1 [2] ) -> KVM-PR doesn't work.

After that: git revert d38c07afc356ddebaa3ed8ecb3f553340e05c969 -m 1
-> KVM-PR works.

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

Thanks,
Christian


[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9600f261acaaabd476d7833cec2dd20f2919f1a0 


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


Hi All,

I tried to revert the __GEN_REALMODE_COMMON_ENTRY fix for the 
latest Git

kernel and for the stable kernel 5.7.2 but without any success. There
was a lot of restructuring work during the kernel 5.7 development 
time in

the PowerPC area so it isn't possible to reactivate the old code. That
means we have lost the whole KVM-PR support. I also reported this 
issue

to Alexander Graf two days ago. He wrote: "Howdy :). It looks pretty
broken. Have you ever made a bisect to see where the problem comes 
from?"


Please check the KVM-PR code.

Does this patch fix it for you?

The CTR register reload in the KVM interrupt path used the wrong save
area for SLB (and NMI) interrupts.

Fixes: 9600f261acaaa ("powerpc/64s/exception: Move KVM test to 
common code")

Reported-by: Christian Zigotzky 
Signed-off-by: Nicholas Piggin 
---
  arch/powerpc/kernel/exceptions-64s.S | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff -

Re: PowerPC KVM-PR issue

2020-06-14 Thread Christian Zigotzky

On 14 June 2020 at 04:52 pm, Christian Zigotzky wrote:

On 14 June 2020 at 02:53 pm, Nicholas Piggin wrote:

Excerpts from Christian Zigotzky's message of June 12, 2020 11:01 pm:

On 11 June 2020 at 04:47 pm, Christian Zigotzky wrote:

On 10 June 2020 at 01:23 pm, Christian Zigotzky wrote:

On 10 June 2020 at 11:06 am, Christian Zigotzky wrote:

On 10 June 2020 at 00:18 am, Christian Zigotzky wrote:

Hello,

KVM-PR doesn't work anymore on my Nemo board [1]. I figured out
that the Git kernels and the kernel 5.7 are affected.

Error message: Fienix kernel: kvmppc_exit_pr_progint: emulation at
700 failed ()

I can boot virtual QEMU PowerPC machines with KVM-PR with the
kernel 5.6 without any problems on my Nemo board.

I tested it with QEMU 2.5.0 and QEMU 5.0.0 today.

Could you please check KVM-PR on your PowerPC machine?

Thanks,
Christian

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

I figured out that the PowerPC updates 5.7-1 [1] are responsible for
the KVM-PR issue. Please test KVM-PR on your PowerPC machines and
check the PowerPC updates 5.7-1 [1].

Thanks

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d38c07afc356ddebaa3ed8ecb3f553340e05c969 





I tested the latest Git kernel with Mac-on-Linux/KVM-PR today.
Unfortunately I can't use KVM-PR with MoL anymore because of this
issue (see screenshots [1]). Please check the PowerPC updates 5.7-1.

Thanks

[1]
-
https://i.pinimg.com/originals/0c/b3/64/0cb364a40241fa2b7f297d4272bbb8b7.png 


-
https://i.pinimg.com/originals/9a/61/d1/9a61d170b1c9f514f7a78a3014ffd18f.png 




Hi All,

I bisected today because of the KVM-PR issue.

Result:

9600f261acaaabd476d7833cec2dd20f2919f1a0 is the first bad commit
commit 9600f261acaaabd476d7833cec2dd20f2919f1a0
Author: Nicholas Piggin 
Date:   Wed Feb 26 03:35:21 2020 +1000

 powerpc/64s/exception: Move KVM test to common code

 This allows more code to be moved out of unrelocated regions. The
 system call KVMTEST is changed to be open-coded and remain in the
 tramp area to avoid having to move it to entry_64.S. The custom
nature
 of the system call entry code means the hcall case can be made 
more

 streamlined than regular interrupt handlers.

 mpe: Incorporate fix from Nick:

 Moving KVM test to the common entry code missed the case of 
HMI and
 MCE, which do not do __GEN_COMMON_ENTRY (because they don't 
want to

 switch to virt mode).

 This means a MCE or HMI exception that is taken while KVM is
running a
 guest context will not be switched out of that context, and 
KVM won't
 be notified. Found by running sigfuz in guest with patched 
host on
 POWER9 DD2.3, which causes some TM related HMI interrupts 
(which are

 expected and supposed to be handled by KVM).

 This fix adds a __GEN_REALMODE_COMMON_ENTRY for those handlers 
to add
 the KVM test. This makes them look a little more like other 
handlers

 that all use __GEN_COMMON_ENTRY.

 Signed-off-by: Nicholas Piggin 
 Signed-off-by: Michael Ellerman 
 Link:
https://lore.kernel.org/r/20200225173541.1549955-13-npig...@gmail.com

:04 04 ec21cec22d165f8696d69532734cb2985d532cb0
87dd49a9cd7202ec79350e8ca26cea01f1dbd93d M    arch

-

The following commit is the problem: powerpc/64s/exception: Move KVM
test to common code [1]

These changes were included in the PowerPC updates 5.7-1. [2]

Another test:

git checkout d38c07afc356ddebaa3ed8ecb3f553340e05c969 (PowerPC updates
5.7-1 [2] ) -> KVM-PR doesn't work.

After that: git revert d38c07afc356ddebaa3ed8ecb3f553340e05c969 -m 1
-> KVM-PR works.

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

Thanks,
Christian


[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9600f261acaaabd476d7833cec2dd20f2919f1a0 


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


Hi All,

I tried to revert the __GEN_REALMODE_COMMON_ENTRY fix for the latest 
Git

kernel and for the stable kernel 5.7.2 but without any success. There
was lot of restructuring work during the kernel 5.7 development time in
the PowerPC area so it isn't possible reactivate the old code. That
means we have lost the whole KVM-PR support. I also reported this issue
to Alexander Graf two days ago. He wrote: "Howdy :). It looks pretty
broken. Have you ever made a bisect to see where the problem comes 
from?"


Please check the KVM-PR code.

Does this patch fix it for you?

The CTR register reload in the KVM interrupt path used the wrong save
area for SLB (and NMI) interrupts.

Fixes: 9600f261acaaa ("powerpc/64s/exception: Move KVM test to common 
code")

Reported-by: Christian Zigotzky 
Signed-off-by: Nicholas Piggin 
---
  arch/powerpc/kernel/exceptions-64s.S | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/exceptions-64s.S 
b/arch/powerpc/kern

Re: PowerPC KVM-PR issue

2020-06-14 Thread Christian Zigotzky

On 14 June 2020 at 02:53 pm, Nicholas Piggin wrote:

Excerpts from Christian Zigotzky's message of June 12, 2020 11:01 pm:

On 11 June 2020 at 04:47 pm, Christian Zigotzky wrote:

On 10 June 2020 at 01:23 pm, Christian Zigotzky wrote:

On 10 June 2020 at 11:06 am, Christian Zigotzky wrote:

On 10 June 2020 at 00:18 am, Christian Zigotzky wrote:

Hello,

KVM-PR doesn't work anymore on my Nemo board [1]. I figured out
that the Git kernels and the kernel 5.7 are affected.

Error message: Fienix kernel: kvmppc_exit_pr_progint: emulation at
700 failed ()

I can boot virtual QEMU PowerPC machines with KVM-PR with the
kernel 5.6 without any problems on my Nemo board.

I tested it with QEMU 2.5.0 and QEMU 5.0.0 today.

Could you please check KVM-PR on your PowerPC machine?

Thanks,
Christian

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

I figured out that the PowerPC updates 5.7-1 [1] are responsible for
the KVM-PR issue. Please test KVM-PR on your PowerPC machines and
check the PowerPC updates 5.7-1 [1].

Thanks

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d38c07afc356ddebaa3ed8ecb3f553340e05c969



I tested the latest Git kernel with Mac-on-Linux/KVM-PR today.
Unfortunately I can't use KVM-PR with MoL anymore because of this
issue (see screenshots [1]). Please check the PowerPC updates 5.7-1.

Thanks

[1]
-
https://i.pinimg.com/originals/0c/b3/64/0cb364a40241fa2b7f297d4272bbb8b7.png
-
https://i.pinimg.com/originals/9a/61/d1/9a61d170b1c9f514f7a78a3014ffd18f.png


Hi All,

I bisected today because of the KVM-PR issue.

Result:

9600f261acaaabd476d7833cec2dd20f2919f1a0 is the first bad commit
commit 9600f261acaaabd476d7833cec2dd20f2919f1a0
Author: Nicholas Piggin 
Date:   Wed Feb 26 03:35:21 2020 +1000

     powerpc/64s/exception: Move KVM test to common code

     This allows more code to be moved out of unrelocated regions. The
     system call KVMTEST is changed to be open-coded and remain in the
     tramp area to avoid having to move it to entry_64.S. The custom
nature
     of the system call entry code means the hcall case can be made more
     streamlined than regular interrupt handlers.

     mpe: Incorporate fix from Nick:

     Moving KVM test to the common entry code missed the case of HMI and
     MCE, which do not do __GEN_COMMON_ENTRY (because they don't want to
     switch to virt mode).

     This means a MCE or HMI exception that is taken while KVM is
running a
     guest context will not be switched out of that context, and KVM won't
     be notified. Found by running sigfuz in guest with patched host on
     POWER9 DD2.3, which causes some TM related HMI interrupts (which are
     expected and supposed to be handled by KVM).

     This fix adds a __GEN_REALMODE_COMMON_ENTRY for those handlers to add
     the KVM test. This makes them look a little more like other handlers
     that all use __GEN_COMMON_ENTRY.

     Signed-off-by: Nicholas Piggin 
     Signed-off-by: Michael Ellerman 
     Link:
https://lore.kernel.org/r/20200225173541.1549955-13-npig...@gmail.com

:04 04 ec21cec22d165f8696d69532734cb2985d532cb0
87dd49a9cd7202ec79350e8ca26cea01f1dbd93d M    arch

-

The following commit is the problem: powerpc/64s/exception: Move KVM
test to common code [1]

These changes were included in the PowerPC updates 5.7-1. [2]

Another test:

git checkout d38c07afc356ddebaa3ed8ecb3f553340e05c969 (PowerPC updates
5.7-1 [2] ) -> KVM-PR doesn't work.

After that: git revert d38c07afc356ddebaa3ed8ecb3f553340e05c969 -m 1
-> KVM-PR works.

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

Thanks,
Christian


[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9600f261acaaabd476d7833cec2dd20f2919f1a0
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d38c07afc356ddebaa3ed8ecb3f553340e05c969

Hi All,

I tried to revert the __GEN_REALMODE_COMMON_ENTRY fix for the latest Git
kernel and for the stable kernel 5.7.2 but without any success. There
was lot of restructuring work during the kernel 5.7 development time in
the PowerPC area so it isn't possible reactivate the old code. That
means we have lost the whole KVM-PR support. I also reported this issue
to Alexander Graf two days ago. He wrote: "Howdy :). It looks pretty
broken. Have you ever made a bisect to see where the problem comes from?"

Please check the KVM-PR code.

Does this patch fix it for you?

The CTR register reload in the KVM interrupt path used the wrong save
area for SLB (and NMI) interrupts.

Fixes: 9600f261acaaa ("powerpc/64s/exception: Move KVM test to common code")
Reported-by: Christian Zigotzky 
Signed-off-by: Nicholas Piggin 
---
  arch/powerpc/kernel/exceptions-64s.S | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/exceptions-64s.S 
b/arch/powerpc/kernel/exceptions-64s.S
index e70ebb5c318c..fa080694e581 100644
--- a/arch/powerpc/kernel/exception

Re: PowerPC KVM-PR issue

2020-06-12 Thread Christian Zigotzky

On 11 June 2020 at 04:47 pm, Christian Zigotzky wrote:

On 10 June 2020 at 01:23 pm, Christian Zigotzky wrote:

On 10 June 2020 at 11:06 am, Christian Zigotzky wrote:

On 10 June 2020 at 00:18 am, Christian Zigotzky wrote:

Hello,

KVM-PR doesn't work anymore on my Nemo board [1]. I figured out 
that the Git kernels and the kernel 5.7 are affected.


Error message: Fienix kernel: kvmppc_exit_pr_progint: emulation at 
700 failed ()


I can boot virtual QEMU PowerPC machines with KVM-PR with the 
kernel 5.6 without any problems on my Nemo board.


I tested it with QEMU 2.5.0 and QEMU 5.0.0 today.

Could you please check KVM-PR on your PowerPC machine?

Thanks,
Christian

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


I figured out that the PowerPC updates 5.7-1 [1] are responsible for 
the KVM-PR issue. Please test KVM-PR on your PowerPC machines and 
check the PowerPC updates 5.7-1 [1].


Thanks

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d38c07afc356ddebaa3ed8ecb3f553340e05c969



I tested the latest Git kernel with Mac-on-Linux/KVM-PR today. 
Unfortunately I can't use KVM-PR with MoL anymore because of this 
issue (see screenshots [1]). Please check the PowerPC updates 5.7-1.


Thanks

[1]
- 
https://i.pinimg.com/originals/0c/b3/64/0cb364a40241fa2b7f297d4272bbb8b7.png
- 
https://i.pinimg.com/originals/9a/61/d1/9a61d170b1c9f514f7a78a3014ffd18f.png



Hi All,

I bisected today because of the KVM-PR issue.

Result:

9600f261acaaabd476d7833cec2dd20f2919f1a0 is the first bad commit
commit 9600f261acaaabd476d7833cec2dd20f2919f1a0
Author: Nicholas Piggin 
Date:   Wed Feb 26 03:35:21 2020 +1000

    powerpc/64s/exception: Move KVM test to common code

    This allows more code to be moved out of unrelocated regions. The
    system call KVMTEST is changed to be open-coded and remain in the
    tramp area to avoid having to move it to entry_64.S. The custom 
nature

    of the system call entry code means the hcall case can be made more
    streamlined than regular interrupt handlers.

    mpe: Incorporate fix from Nick:

    Moving KVM test to the common entry code missed the case of HMI and
    MCE, which do not do __GEN_COMMON_ENTRY (because they don't want to
    switch to virt mode).

    This means a MCE or HMI exception that is taken while KVM is 
running a

    guest context will not be switched out of that context, and KVM won't
    be notified. Found by running sigfuz in guest with patched host on
    POWER9 DD2.3, which causes some TM related HMI interrupts (which are
    expected and supposed to be handled by KVM).

    This fix adds a __GEN_REALMODE_COMMON_ENTRY for those handlers to add
    the KVM test. This makes them look a little more like other handlers
    that all use __GEN_COMMON_ENTRY.

    Signed-off-by: Nicholas Piggin 
    Signed-off-by: Michael Ellerman 
    Link: 
https://lore.kernel.org/r/20200225173541.1549955-13-npig...@gmail.com


:04 04 ec21cec22d165f8696d69532734cb2985d532cb0 
87dd49a9cd7202ec79350e8ca26cea01f1dbd93d M    arch


-

The following commit is the problem: powerpc/64s/exception: Move KVM 
test to common code [1]


These changes were included in the PowerPC updates 5.7-1. [2]

Another test:

git checkout d38c07afc356ddebaa3ed8ecb3f553340e05c969 (PowerPC updates 
5.7-1 [2] ) -> KVM-PR doesn't work.


After that: git revert d38c07afc356ddebaa3ed8ecb3f553340e05c969 -m 1 
-> KVM-PR works.


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

Thanks,
Christian


[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9600f261acaaabd476d7833cec2dd20f2919f1a0
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d38c07afc356ddebaa3ed8ecb3f553340e05c969


Hi All,

I tried to revert the __GEN_REALMODE_COMMON_ENTRY fix for the latest Git 
kernel and for the stable kernel 5.7.2 but without any success. There 
was lot of restructuring work during the kernel 5.7 development time in 
the PowerPC area so it isn't possible reactivate the old code. That 
means we have lost the whole KVM-PR support. I also reported this issue 
to Alexander Graf two days ago. He wrote: "Howdy :). It looks pretty 
broken. Have you ever made a bisect to see where the problem comes from?"


Please check the KVM-PR code.

Thanks,
Christian




Re: PowerPC KVM-PR issue

2020-06-11 Thread Christian Zigotzky

On 10 June 2020 at 01:23 pm, Christian Zigotzky wrote:

On 10 June 2020 at 11:06 am, Christian Zigotzky wrote:

On 10 June 2020 at 00:18 am, Christian Zigotzky wrote:

Hello,

KVM-PR doesn't work anymore on my Nemo board [1]. I figured out that 
the Git kernels and the kernel 5.7 are affected.


Error message: Fienix kernel: kvmppc_exit_pr_progint: emulation at 
700 failed ()


I can boot virtual QEMU PowerPC machines with KVM-PR with the kernel 
5.6 without any problems on my Nemo board.


I tested it with QEMU 2.5.0 and QEMU 5.0.0 today.

Could you please check KVM-PR on your PowerPC machine?

Thanks,
Christian

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


I figured out that the PowerPC updates 5.7-1 [1] are responsible for 
the KVM-PR issue. Please test KVM-PR on your PowerPC machines and 
check the PowerPC updates 5.7-1 [1].


Thanks

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d38c07afc356ddebaa3ed8ecb3f553340e05c969



I tested the latest Git kernel with Mac-on-Linux/KVM-PR today. 
Unfortunately I can't use KVM-PR with MoL anymore because of this 
issue (see screenshots [1]). Please check the PowerPC updates 5.7-1.


Thanks

[1]
- 
https://i.pinimg.com/originals/0c/b3/64/0cb364a40241fa2b7f297d4272bbb8b7.png
- 
https://i.pinimg.com/originals/9a/61/d1/9a61d170b1c9f514f7a78a3014ffd18f.png



Hi All,

I bisected today because of the KVM-PR issue.

Result:

9600f261acaaabd476d7833cec2dd20f2919f1a0 is the first bad commit
commit 9600f261acaaabd476d7833cec2dd20f2919f1a0
Author: Nicholas Piggin 
Date:   Wed Feb 26 03:35:21 2020 +1000

    powerpc/64s/exception: Move KVM test to common code

    This allows more code to be moved out of unrelocated regions. The
    system call KVMTEST is changed to be open-coded and remain in the
    tramp area to avoid having to move it to entry_64.S. The custom nature
    of the system call entry code means the hcall case can be made more
    streamlined than regular interrupt handlers.

    mpe: Incorporate fix from Nick:

    Moving KVM test to the common entry code missed the case of HMI and
    MCE, which do not do __GEN_COMMON_ENTRY (because they don't want to
    switch to virt mode).

    This means a MCE or HMI exception that is taken while KVM is running a
    guest context will not be switched out of that context, and KVM won't
    be notified. Found by running sigfuz in guest with patched host on
    POWER9 DD2.3, which causes some TM related HMI interrupts (which are
    expected and supposed to be handled by KVM).

    This fix adds a __GEN_REALMODE_COMMON_ENTRY for those handlers to add
    the KVM test. This makes them look a little more like other handlers
    that all use __GEN_COMMON_ENTRY.

    Signed-off-by: Nicholas Piggin 
    Signed-off-by: Michael Ellerman 
    Link: 
https://lore.kernel.org/r/20200225173541.1549955-13-npig...@gmail.com


:04 04 ec21cec22d165f8696d69532734cb2985d532cb0 
87dd49a9cd7202ec79350e8ca26cea01f1dbd93d M    arch


-

The following commit is the problem: powerpc/64s/exception: Move KVM 
test to common code [1]


These changes were included in the PowerPC updates 5.7-1. [2]

Another test:

git checkout d38c07afc356ddebaa3ed8ecb3f553340e05c969 (PowerPC updates 
5.7-1 [2] ) -> KVM-PR doesn't work.


After that: git revert d38c07afc356ddebaa3ed8ecb3f553340e05c969 -m 1 -> 
KVM-PR works.


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

Thanks,
Christian


[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9600f261acaaabd476d7833cec2dd20f2919f1a0
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d38c07afc356ddebaa3ed8ecb3f553340e05c969


Re: PowerPC KVM-PR issue

2020-06-10 Thread Christian Zigotzky

On 10 June 2020 at 11:06 am, Christian Zigotzky wrote:

On 10 June 2020 at 00:18 am, Christian Zigotzky wrote:

Hello,

KVM-PR doesn't work anymore on my Nemo board [1]. I figured out that 
the Git kernels and the kernel 5.7 are affected.


Error message: Fienix kernel: kvmppc_exit_pr_progint: emulation at 
700 failed ()


I can boot virtual QEMU PowerPC machines with KVM-PR with the kernel 
5.6 without any problems on my Nemo board.


I tested it with QEMU 2.5.0 and QEMU 5.0.0 today.

Could you please check KVM-PR on your PowerPC machine?

Thanks,
Christian

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


I figured out that the PowerPC updates 5.7-1 [1] are responsible for 
the KVM-PR issue. Please test KVM-PR on your PowerPC machines and 
check the PowerPC updates 5.7-1 [1].


Thanks

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d38c07afc356ddebaa3ed8ecb3f553340e05c969



I tested the latest Git kernel with Mac-on-Linux/KVM-PR today. 
Unfortunately I can't use KVM-PR with MoL anymore because of this issue 
(see screenshots [1]). Please check the PowerPC updates 5.7-1.


Thanks

[1]
- 
https://i.pinimg.com/originals/0c/b3/64/0cb364a40241fa2b7f297d4272bbb8b7.png
- 
https://i.pinimg.com/originals/9a/61/d1/9a61d170b1c9f514f7a78a3014ffd18f.png




Re: PowerPC KVM-PR issue

2020-06-10 Thread Christian Zigotzky

On 10 June 2020 at 00:18 am, Christian Zigotzky wrote:

Hello,

KVM-PR doesn't work anymore on my Nemo board [1]. I figured out that 
the Git kernels and the kernel 5.7 are affected.


Error message: Fienix kernel: kvmppc_exit_pr_progint: emulation at 700 
failed ()


I can boot virtual QEMU PowerPC machines with KVM-PR with the kernel 
5.6 without any problems on my Nemo board.


I tested it with QEMU 2.5.0 and QEMU 5.0.0 today.

Could you please check KVM-PR on your PowerPC machine?

Thanks,
Christian

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


I figured out that the PowerPC updates 5.7-1 [1] are responsible for the 
KVM-PR issue. Please test KVM-PR on your PowerPC machines and check the 
PowerPC updates 5.7-1 [1].


Thanks

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d38c07afc356ddebaa3ed8ecb3f553340e05c969






PowerPC KVM-PR issue

2020-06-09 Thread Christian Zigotzky

Hello,

KVM-PR doesn't work anymore on my Nemo board [1]. I figured out that the 
Git kernels and the kernel 5.7 are affected.


Error message: Fienix kernel: kvmppc_exit_pr_progint: emulation at 700 
failed ()


I can boot virtual QEMU PowerPC machines with KVM-PR with the kernel 5.6 
without any problems on my Nemo board.


I tested it with QEMU 2.5.0 and QEMU 5.0.0 today.

Could you please check KVM-PR on your PowerPC machine?

Thanks,
Christian

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


Re: Boot issue with the latest Git kernel

2020-06-07 Thread Christian Zigotzky

Hi All,

It seems, someone has fixed the boot issue. The latest Git kernel boots 
on my PowerPC machines.


Thanks,
Christian


On 05 June 2020 at 6:23 pm, Christian Zigotzky wrote:

On 04 June 2020 at 7:15 pm, Christophe Leroy wrote:

Yes today's linux-next boots on my powerpc 8xx board.

Christophe

Hello Christophe,

Thanks for testing.

I was able to perform a 'git bisect' [1] and identified the bad 
commit. [2] I reverted this commit and after that the kernel boots and 
works without any problems.


Could you please check this commit?

Thanks,
Christian


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




Re: Boot issue with the latest Git kernel

2020-06-05 Thread Christian Zigotzky

On 04 June 2020 at 7:15 pm, Christophe Leroy wrote:

Yes today's linux-next boots on my powerpc 8xx board.

Christophe

Hello Christophe,

Thanks for testing.

I was able to perform a 'git bisect' [1] and identified the bad commit. 
[2] I reverted this commit and after that the kernel boots and works 
without any problems.


Could you please check this commit?

Thanks,
Christian


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


Re: Boot issue with the latest Git kernel

2020-06-04 Thread Christian Zigotzky
Hello Christophe,

I tested it on my Nemo board with a P.A. Semi PA6T CPU [1], on my Cyrus+ board 
with a FSL P5040 CPU [2] and in a virtual e5500 QEMU machine. You can find the 
kernel configs in the following package.

Link: http://www.xenosoft.de/linux-image-5.8-alpha1-X1000_X5000.tar.gz

Cheers,
Christian

[1] https://en.m.wikipedia.org/wiki/AmigaOne_X1000
[2] https://www.amigaos.net/hardware/133/amigaone-x5000


> On 4. Jun 2020, at 16:29, Christophe Leroy  
> wrote:
> 
> 
> 
>> Le 04/06/2020 à 16:26, Christophe Leroy a écrit :
>> Hi,
>>> Le 04/06/2020 à 16:16, Christian Zigotzky a écrit :
>>> Hi All,
>>> 
>>> I tested the latest Git kernel today. [1]. Unfortunately it doesn't boot on 
>>> my PowerPC machines.
>>> 
>>> Could you please test the latest Git kernel with your PowerPC machine?
>>> 
>>> BTW, it doesn't boot in a virtual QEMU PowerPC machine either.
>>> 
>> Which machine/platform ? Which defconfig are you using ?
> 
> 
> And are you able to perform a 'git bisect' to identify the guilty commit ?
> 
> Thanks
> Christophe


Re: Boot issue with the latest Git kernel

2020-06-04 Thread Christian Zigotzky



> On 4. Jun 2020, at 16:29, Christophe Leroy  
> wrote:
> 
> And are you able to perform a 'git bisect' to identify the guilty commit ?
> 
> Thanks
> Christophe

Hello Christophe,

Unfortunately I haven’t had time to bisect the latest Git kernel. Does it boot 
on your PowerPC machine?

Thanks,
Christian

Boot issue with the latest Git kernel

2020-06-04 Thread Christian Zigotzky

Hi All,

I tested the latest Git kernel today. [1]. Unfortunately it doesn't boot 
on my PowerPC machines.


Could you please test the latest Git kernel with your PowerPC machine?

BTW, it doesn't boot in a virtual QEMU PowerPC machine either.

Thanks,
Christian

[1] 
https://forum.hyperion-entertainment.com/viewtopic.php?f=58=50758=3f816f078869510dea9fe4baca3605db#p50758


Re: [PATCH] powerpc/64s: Fix early_init_mmu section mismatch

2020-05-18 Thread Christian Zigotzky


OK, thanks.

> On 18. May 2020, at 04:40, Michael Ellerman  wrote:
> 
> Christian Zigotzky  writes:
>> Hi All,
>> 
>> This patch wasn't included in the PowerPC fixes 5.7-4. Please add it.
> 
> It's not an important bug. I'll take the patch for v5.8
> 
> cheers
> 
>>> On 29 April 2020 at 09:02 am, Nicholas Piggin wrote:
>>> Christian reports:
>>> 
>>>   MODPOST vmlinux.o
>>>   WARNING: modpost: vmlinux.o(.text.unlikely+0x1a0): Section mismatch in
>>>   reference from the function .early_init_mmu() to the function
>>>   .init.text:.radix__early_init_mmu()
>>>   The function .early_init_mmu() references
>>>   the function __init .radix__early_init_mmu().
>>>   This is often because .early_init_mmu lacks a __init
>>>   annotation or the annotation of .radix__early_init_mmu is wrong.
>>> 
>>>   WARNING: modpost: vmlinux.o(.text.unlikely+0x1ac): Section mismatch in
>>>   reference from the function .early_init_mmu() to the function
>>>   .init.text:.hash__early_init_mmu()
>>>   The function .early_init_mmu() references
>>>   the function __init .hash__early_init_mmu().
>>>   This is often because .early_init_mmu lacks a __init
>>>   annotation or the annotation of .hash__early_init_mmu is wrong.
>>> 
>>> The compiler is uninlining early_init_mmu and not putting it in an init
>>> section because there is no annotation. Add it.
>>> 
>>> Reported-by: Christian Zigotzky 
>>> Tested-by: Christian Zigotzky 
>>> Signed-off-by: Nicholas Piggin 
>>> ---
>>>  arch/powerpc/include/asm/book3s/64/mmu.h | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>> 
>>> diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h 
>>> b/arch/powerpc/include/asm/book3s/64/mmu.h
>>> index bb3deb76c951..3ffe5f967483 100644
>>> --- a/arch/powerpc/include/asm/book3s/64/mmu.h
>>> +++ b/arch/powerpc/include/asm/book3s/64/mmu.h
>>> @@ -208,7 +208,7 @@ void hash__early_init_devtree(void);
>>>  void radix__early_init_devtree(void);
>>>  extern void hash__early_init_mmu(void);
>>>  extern void radix__early_init_mmu(void);
>>> -static inline void early_init_mmu(void)
>>> +static inline void __init early_init_mmu(void)
>>>  {
>>>  if (radix_enabled())
>>>  return radix__early_init_mmu();


Re: [PATCH] powerpc/64s: Fix early_init_mmu section mismatch

2020-05-17 Thread Christian Zigotzky

Hi All,

This patch wasn't included in the PowerPC fixes 5.7-4. Please add it.

Thanks,
Christian


On 29 April 2020 at 09:02 am, Nicholas Piggin wrote:

Christian reports:

   MODPOST vmlinux.o
   WARNING: modpost: vmlinux.o(.text.unlikely+0x1a0): Section mismatch in
   reference from the function .early_init_mmu() to the function
   .init.text:.radix__early_init_mmu()
   The function .early_init_mmu() references
   the function __init .radix__early_init_mmu().
   This is often because .early_init_mmu lacks a __init
   annotation or the annotation of .radix__early_init_mmu is wrong.

   WARNING: modpost: vmlinux.o(.text.unlikely+0x1ac): Section mismatch in
   reference from the function .early_init_mmu() to the function
   .init.text:.hash__early_init_mmu()
   The function .early_init_mmu() references
   the function __init .hash__early_init_mmu().
   This is often because .early_init_mmu lacks a __init
   annotation or the annotation of .hash__early_init_mmu is wrong.

The compiler is uninlining early_init_mmu and not putting it in an init
section because there is no annotation. Add it.

Reported-by: Christian Zigotzky 
Tested-by: Christian Zigotzky 
Signed-off-by: Nicholas Piggin 
---
  arch/powerpc/include/asm/book3s/64/mmu.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h 
b/arch/powerpc/include/asm/book3s/64/mmu.h
index bb3deb76c951..3ffe5f967483 100644
--- a/arch/powerpc/include/asm/book3s/64/mmu.h
+++ b/arch/powerpc/include/asm/book3s/64/mmu.h
@@ -208,7 +208,7 @@ void hash__early_init_devtree(void);
  void radix__early_init_devtree(void);
  extern void hash__early_init_mmu(void);
  extern void radix__early_init_mmu(void);
-static inline void early_init_mmu(void)
+static inline void __init early_init_mmu(void)
  {
if (radix_enabled())
return radix__early_init_mmu();




Re: Don't initialise ports with no PHY

2020-04-30 Thread Christian Zigotzky


> On 30. Apr 2020, at 23:36, Darren Stevens  wrote:
> 
> Hello Christian
> 
>> On 29/04/2020, Christian Zigotzky wrote:
>> 
>> 
>>>> On 29. Apr 2020, at 17:22, Andrew Lunn  wrote:
>>> 
>>> ?On Wed, Apr 29, 2020 at 03:55:28PM +0200, Christian Zigotzky wrote:
>>>> Hi Andrew,
>>>> 
>>>> You can find some dtb and source files in our kernel package.
>>>> 
>>>> Download: http://www.xenosoft.de/linux-image-5.7-rc3-X1000_X5000.tar.gz
>>> 
>>> I have the tarball. Are we talking about
>>> 
>>> 
> linux-image-5.7-rc3-X1000_X5000/X5000_and_QEMU_e5500/dtbs/X5000_20/cyrus.eth.dtb
>> 
>>> I don't see any status = "disabled"; in the blob. So i would expect
>>> the driver to probe.
> 
> No, the vendor never added that to them.
> 
>> Yes, that's correct but maybe Darren uses another dtb file.
>> 
>> @Darren
>> Which dtb file do you use?
> 
> My current one attached, including updated cyrus_p5020.dts & p5020si-pre.dtsi
> which I'm preparing patches for.
> 
> Christian, build an unmodified kernel, select board level reset or power off,
> then both the GPIO drivers.
> Then under LED Support: GPIO connected LED's and triggers -> disk activity
> 
> I think you still have a 5020 don't you? I'll look at 5040 later (I'll need
> someone to test)
> 
> Regards
> Darren
> 

Darren

I use a 5040 currently.

Thanks
Christian




Re: [RFC PATCH dpss_eth] Don't initialise ports with no PHY

2020-04-29 Thread Christian Zigotzky
Hi Andrew,

You can find some dtb and source files in our kernel package.

Download: http://www.xenosoft.de/linux-image-5.7-rc3-X1000_X5000.tar.gz

Thanks,
Christian

> On 29. Apr 2020, at 15:13, Andrew Lunn  wrote:
> 
> 
>> 
>> Maybe we have to modify the dtb file.
> 
> Hi Christian
> 
> Could you point me at the DT file.
> 
>  Thanks
>Andrew


Re: [RFC PATCH dpss_eth] Don't initialise ports with no PHY

2020-04-29 Thread Christian Zigotzky



> On 29. Apr 2020, at 17:22, Andrew Lunn  wrote:
> 
> On Wed, Apr 29, 2020 at 03:55:28PM +0200, Christian Zigotzky wrote:
>> Hi Andrew,
>> 
>> You can find some dtb and source files in our kernel package.
>> 
>> Download: http://www.xenosoft.de/linux-image-5.7-rc3-X1000_X5000.tar.gz
> 
> I have the tarball. Are we talking about
> linux-image-5.7-rc3-X1000_X5000/X5000_and_QEMU_e5500/dtbs/X5000_20/cyrus.eth.dtb
> 
> I don't see any status = "disabled"; in the blob. So i would expect
> the driver to probe.
> 
>Andrew
> 
> 

Yes, that’s correct but maybe Darren uses another dtb file.

@Darren
Which dtb file do you use?

Re: [RFC PATCH dpss_eth] Don't initialise ports with no PHY

2020-04-29 Thread Christian Zigotzky

Hi Darren,

Thanks a lot for your patch!

I tested it with the RC3 today.

Unfortunately it doesn't compile because a bracket is missing in the 
following line:


+    if (prop && !strncmp(prop, "disabled", 8) {

And a semicolon is missing in the following line:

+        goto _return

I added the bracket and the semicolon and after that it compiled without 
any problems. (New patch attached)


Unfortunately I see more than 2 ethernet ports with the RC3 and your 
patch on my Cyrus P5040. Maybe Skateman has an other result on his Cyrus 
P5020.


Maybe we have to modify the dtb file.

Thanks,
Christian


On 25 April 2020 at 00:29 am, Darren Stevens wrote:

Since cbb961ca271e ("Use random MAC address when none is given")
Varisys Cyrus P5020 boards have been listing 5 ethernet ports instead of
the 2 the board has.This is because we were preventing the adding of the
unused ports by not suppling them a MAC address, which this patch now
supplies.

Prevent them from appearing in the net devices list by checking for a
'status="disabled"' entry during probe and skipping the port if we find
it.

Signed-off-by: Darren Stevens 

---

  drivers/net/ethernet/freescale/fman/mac.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/drivers/net/ethernet/freescale/fman/mac.c 
b/drivers/net/ethernet/freescale/fman/mac.c
index 43427c5..c9ed411 100644
--- a/drivers/net/ethernet/freescale/fman/mac.c
+++ b/drivers/net/ethernet/freescale/fman/mac.c
@@ -606,6 +606,7 @@ static int mac_probe(struct platform_device *_of_dev)
struct resource  res;
struct mac_priv_s   *priv;
const u8*mac_addr;
+   const char  *prop;
u32  val;
u8  fman_id;
phy_interface_t  phy_if;
@@ -628,6 +629,16 @@ static int mac_probe(struct platform_device *_of_dev)
mac_dev->priv = priv;
priv->dev = dev;
  
+	/* check for disabled devices and skip them, as now a missing

+* MAC address will be replaced with a Random one rather than
+* disabling the port
+*/
+   prop = of_get_property(mac_node, "status", NULL);
+   if (prop && !strncmp(prop, "disabled", 8) {
+   err = -ENODEV;
+   goto _return
+   }
+
if (of_device_is_compatible(mac_node, "fsl,fman-dtsec")) {
setup_dtsec(mac_dev);
priv->internal_phy_node = of_parse_phandle(mac_node,


diff --git a/drivers/net/ethernet/freescale/fman/mac.c b/drivers/net/ethernet/freescale/fman/mac.c
index 43427c5..c9ed411 100644
--- a/drivers/net/ethernet/freescale/fman/mac.c
+++ b/drivers/net/ethernet/freescale/fman/mac.c
@@ -606,6 +606,7 @@ static int mac_probe(struct platform_device *_of_dev)
 	struct resource		 res;
 	struct mac_priv_s	*priv;
 	const u8		*mac_addr;
+	const char 		*prop;
 	u32			 val;
 	u8			fman_id;
 	phy_interface_t  phy_if;
@@ -628,6 +629,16 @@ static int mac_probe(struct platform_device *_of_dev)
 	mac_dev->priv = priv;
 	priv->dev = dev;
 
+	/* check for disabled devices and skip them, as now a missing
+	 * MAC address will be replaced with a Random one rather than
+	 * disabling the port
+	 */
+	prop = of_get_property(mac_node, "status", NULL);
+	if (prop && !strncmp(prop, "disabled", 8)) {
+		err = -ENODEV;
+		goto _return;
+	}
+
 	if (of_device_is_compatible(mac_node, "fsl,fman-dtsec")) {
 		setup_dtsec(mac_dev);
 		priv->internal_phy_node = of_parse_phandle(mac_node,


Re: Section mismatch in reference from the function .early_init_mmu() to the function .init.text:.radix__early_init_mmu() after PowerPC updates 5.7-1

2020-04-29 Thread Christian Zigotzky

On 29 April 2020 at 07:13 am, Nicholas Piggin wrote:

Excerpts from Christian Zigotzky's message of April 29, 2020 2:53 pm:

Hi All,

The issue still exists in the RC3. (kernel config attached)

Please help me to fix this issue.

Huh, looks like maybe early_init_mmu() got uninlined because the
compiler decided it was unlikely.

Does this fix it?

Thanks,
Nick
--


Hi Nick,

Many thanks for your patch! It solved the issue.

Have a nice day!

Cheers,
Christian



diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h 
b/arch/powerpc/include/asm/book3s/64/mmu.h
index bb3deb76c951..3ffe5f967483 100644
--- a/arch/powerpc/include/asm/book3s/64/mmu.h
+++ b/arch/powerpc/include/asm/book3s/64/mmu.h
@@ -208,7 +208,7 @@ void hash__early_init_devtree(void);
  void radix__early_init_devtree(void);
  extern void hash__early_init_mmu(void);
  extern void radix__early_init_mmu(void);
-static inline void early_init_mmu(void)
+static inline void __init early_init_mmu(void)
  {
if (radix_enabled())
return radix__early_init_mmu();





Section mismatch in reference from the function .early_init_mmu() to the function .init.text:.radix__early_init_mmu() after PowerPC updates 5.7-1

2020-04-10 Thread Christian Zigotzky

Hello,

The issue still exists after the new PowerPC updates 5.7-2.

Please check the PowerPC updates 5.7-1.

Thanks,
Christian

On 08 April 2020 at 6:32 pm, Christian Zigotzky wrote:

Hello,

Since the PowerPC updates 5.7-1 we have the following issue during the 
linking of vmlinux:


MODPOST vmlinux.o
WARNING: modpost: vmlinux.o(.text.unlikely+0x1a0): Section mismatch in 
reference from the function .early_init_mmu() to the function 
.init.text:.radix__early_init_mmu()

The function .early_init_mmu() references
the function __init .radix__early_init_mmu().
This is often because .early_init_mmu lacks a __init
annotation or the annotation of .radix__early_init_mmu is wrong.

WARNING: modpost: vmlinux.o(.text.unlikely+0x1ac): Section mismatch in 
reference from the function .early_init_mmu() to the function 
.init.text:.hash__early_init_mmu()

The function .early_init_mmu() references
the function __init .hash__early_init_mmu().
This is often because .early_init_mmu lacks a __init
annotation or the annotation of .hash__early_init_mmu is wrong.

---

But the kernel works without any problems after the linking.

I reverted the following commits:

70fbdfef4ba63eeef83b2c94eac9a5a9f913e442 -- sysfs: remove redundant 
__compat_only_sysfs_link_entry_to_kobj fn


d38c07afc356ddebaa3ed8ecb3f553340e05c969 -- Merge tag 'powerpc-5.7-1' 
of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux


And after that the linking of vmlinux works again.

Please check the PowerPC updates 5.7-1.

Thanks,
Christian




Section mismatch in reference from the function .early_init_mmu() to the function .init.text:.radix__early_init_mmu() after PowerPC updates 5.7-1

2020-04-08 Thread Christian Zigotzky

Hello,

Since the PowerPC updates 5.7-1 we have the following issue during the 
linking of vmlinux:


MODPOST vmlinux.o
WARNING: modpost: vmlinux.o(.text.unlikely+0x1a0): Section mismatch in 
reference from the function .early_init_mmu() to the function 
.init.text:.radix__early_init_mmu()

The function .early_init_mmu() references
the function __init .radix__early_init_mmu().
This is often because .early_init_mmu lacks a __init
annotation or the annotation of .radix__early_init_mmu is wrong.

WARNING: modpost: vmlinux.o(.text.unlikely+0x1ac): Section mismatch in 
reference from the function .early_init_mmu() to the function 
.init.text:.hash__early_init_mmu()

The function .early_init_mmu() references
the function __init .hash__early_init_mmu().
This is often because .early_init_mmu lacks a __init
annotation or the annotation of .hash__early_init_mmu is wrong.

---

But the kernel works without any problems after the linking.

I reverted the following commits:

70fbdfef4ba63eeef83b2c94eac9a5a9f913e442 -- sysfs: remove redundant 
__compat_only_sysfs_link_entry_to_kobj fn


d38c07afc356ddebaa3ed8ecb3f553340e05c969 -- Merge tag 'powerpc-5.7-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux


And after that the linking of vmlinux works again.

Please check the PowerPC updates 5.7-1.

Thanks,
Christian


Re: [PATCH 1/2] dma-mapping: add a dma_ops_bypass flag to, struct device

2020-03-24 Thread Christian Zigotzky

Hi All,

The DMA mapping works great on our PowerPC machines currently. It was a 
long way to get the new DMA mapping code to work successfully on our 
PowerPC machines.


P L E A S E  don't modify the good working DMA mapping code. There are 
many other topics which needs improvements. For us (first level + second 
level support) it is really laborious to find your problematic code and 
patch it. It takes a long time to find the problematic code because we 
have to do it besides our main work.


P L E A S E test your code on PowerPC machines before you add it to the 
mainline vanilla kernel.


Thanks,
Christian


On Tue, Mar 24, 2020 at 12:00:09PM +0530, Aneesh Kumar K.V wrote:
> dma_addr_t dma_direct_map_page(struct device *dev, struct page *page,
>         unsigned long offset, size_t size, enum dma_data_direction dir,
>         unsigned long attrs)
> {
>     phys_addr_t phys = page_to_phys(page) + offset;
>     dma_addr_t dma_addr = phys_to_dma(dev, phys);
>
>     if (unlikely(!dma_capable(dev, dma_addr, size, true))) {
>             return iommu_map(dev, phys, size, dir, attrs);
>
>         return DMA_MAPPING_ERROR;

If powerpc hardware / firmware people really come up with crap that
stupid you'll have to handle it yourself and will always pay the
indirect call penality.


FSL P5020/Cyrus+ Board: Poweroff and Restart Support

2020-03-21 Thread Christian Zigotzky

Hello,

We would like to add poweroff and restart support for the Cyrus+ board 
[1] [2] to the mainline vanilla kernel.

There is a patch for adding poweroff and restart support. (attached)
It works but I am not sure if it is good enough for the mainline vanilla 
kernel.

Please post some suggestions and comments about this patch.

Thanks,
Christian


[1] http://wiki.amiga.org/index.php?title=X5000
[2] https://www.amigaos.net/hardware/133/amigaone-x5000
diff -rupN a/arch/powerpc/boot/dts/fsl/cyrus_p5020.dts 
b/arch/powerpc/boot/dts/fsl/cyrus_p5020.dts
--- a/arch/powerpc/boot/dts/fsl/cyrus_p5020.dts 2020-02-10 01:08:48.0 
+0100
+++ b/arch/powerpc/boot/dts/fsl/cyrus_p5020.dts 2020-02-10 08:49:47.953680947 
+0100
@@ -146,6 +146,25 @@
  0 0x0001>;
};
};
+
+   gpio-poweroff {
+   compatible = "gpio-poweroff";
+   gpios = < 3 1>;
+   };
+
+   gpio-restart {
+   compatible = "gpio-restart";
+   gpios = < 2 1>;
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   hdd {
+   label = "Disk activity";
+   gpios = < 5 0>;
+   linux,default-trigger = "disk-activity";
+   };
+   };
 };
 
 /include/ "p5020si-post.dtsi"
diff -rupN a/arch/powerpc/platforms/85xx/corenet_generic.c 
b/arch/powerpc/platforms/85xx/corenet_generic.c
--- a/arch/powerpc/platforms/85xx/corenet_generic.c 2020-02-10 
01:08:48.0 +0100
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c 2020-02-10 
08:49:47.953680947 +0100
@@ -46,6 +46,16 @@ void __init corenet_gen_pic_init(void)
mpic_init(mpic);
 }
 
+/* If someone has registered a poweroff callback, invoke it */
+static void __noreturn corenet_generic_halt(void)
+{
+   if (pm_power_off)
+   pm_power_off();
+
+   /* Should not return */
+   for(;;);
+}
+
 /*
  * Setup the architecture
  */
@@ -99,6 +109,15 @@ static const struct of_device_id of_devi
{
.name   = "handles",
},
+   {
+   .name   = "gpio-poweroff",
+   },
+   {
+   .name   = "gpio-restart",
+   },
+   {
+   .name   = "leds",
+   },
{}
 };
 
@@ -149,6 +168,8 @@ static int __init corenet_generic_probe(
extern struct smp_ops_t smp_85xx_ops;
 #endif
 
+   ppc_md.halt = corenet_generic_halt;
+
if (of_device_compatible_match(of_root, boards))
return 1;
 


Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device

2020-02-08 Thread Christian Zigotzky

On 08 February 2020 at 07:59 am, Christian Zigotzky wrote:



On 7. Feb 2020, at 18:08, Arnd Bergmann  wrote:

On Fri, Feb 7, 2020 at 3:34 PM Christian Zigotzky
 wrote:

Hello Arnd,

We regularly compile and test Linux kernels every day during the merge
window. Since Thursday last week we have very high CPU usage because of
the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). The
avahi daemon produces a lot of the following log message. This generates
high CPU usage.

Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device

strace /usr/sbin/avahi-daemon:


Thanks a lot for the detailed analysis, with this I immediately saw
what went wrong in my
original commit and I sent you a fix. Please test to ensure that this
correctly addresses
the problem.

Arnd

Hi Arnd,

Thanks a lot for your patch! I will test it as soon as possible.

Cheers,
Christian


Hi Arnd,

I successfully compiled the latest Git kernel with your patch today. The 
avahi daemon works fine now. That means your patch has solved the avahi 
issue.


Thanks for your patch and have a nice weekend!

Cheers,
Christian


Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device

2020-02-07 Thread Christian Zigotzky



> On 7. Feb 2020, at 18:08, Arnd Bergmann  wrote:
> 
> On Fri, Feb 7, 2020 at 3:34 PM Christian Zigotzky
>  wrote:
>> 
>> Hello Arnd,
>> 
>> We regularly compile and test Linux kernels every day during the merge
>> window. Since Thursday last week we have very high CPU usage because of
>> the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). The
>> avahi daemon produces a lot of the following log message. This generates
>> high CPU usage.
>> 
>> Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device
>> 
>> strace /usr/sbin/avahi-daemon:
>> 
> 
> Thanks a lot for the detailed analysis, with this I immediately saw
> what went wrong in my
> original commit and I sent you a fix. Please test to ensure that this
> correctly addresses
> the problem.
> 
>Arnd

Hi Arnd,

Thanks a lot for your patch! I will test it as soon as possible.

Cheers,
Christian

Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device

2020-02-07 Thread Christian Zigotzky

Hello Arnd,

We regularly compile and test Linux kernels every day during the merge 
window. Since Thursday last week we have very high CPU usage because of 
the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc). The 
avahi daemon produces a lot of the following log message. This generates 
high CPU usage.


Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device

strace /usr/sbin/avahi-daemon:

poll([{fd=4, events=POLLIN}, {fd=16, events=POLLIN}, {fd=15, 
events=POLLIN}, {fd=14, events=POLLIN}, {fd=13, events=POLLIN}, {fd=12, 
events=POLLIN}, {fd=11, events=POLLIN}, {fd=10, events=POLLIN}, {fd=9, 
events=POLLIN}, {fd=8, events=POLLIN}, {fd=6, events=POLLIN}], 11, 65) = 
2 ([{fd=12, revents=POLLIN}, {fd=9, revents=POLLIN}])
ioctl(12, FIONREAD, 0xffba6f24) = -1 ENOTTY (Inappropriate ioctl 
for device)
write(2, "ioctl(): Inappropriate ioctl for"..., 39ioctl(): Inappropriate 
ioctl for device) = 39

write(2, "\n", 1
)   = 1

--

I bisected the latest kernel source code today.

Result:

77b9040195dea3fcddf19e136c9e99a501351778 is the first bad commit
commit 77b9040195dea3fcddf19e136c9e99a501351778
Author: Arnd Bergmann 
Date:   Wed Nov 27 21:25:36 2019 +0100

    compat_ioctl: simplify the implementation

    Now that both native and compat ioctl syscalls are
    in the same file, a couple of simplifications can
    be made, bringing the implementation closer together:

    - do_vfs_ioctl(), ioctl_preallocate(), and compat_ioctl_preallocate()
  can become static, allowing the compiler to optimize better

    - slightly update the coding style for consistency between
  the functions.

    - rather than listing each command in two switch statements
  for the compat case, just call a single function that has
  all the common commands.

    As a side-effect, FS_IOC_RESVSP/FS_IOC_RESVSP64 are now available
    to x86 compat tasks, along with FS_IOC_RESVSP_32/FS_IOC_RESVSP64_32.
    This is harmless for i386 emulation, and can be considered a bugfix
    for x32 emulation, which never supported these in the past.

    Reviewed-by: Ben Hutchings 
    Signed-off-by: Arnd Bergmann 

:04 04 5c4b62f4d1bfe643d3bbf9d9a3b50ee50ae0f159 
5ca610e3197df96adfcae4f94fceeb496756609b M    fs
:04 04 086f2e2ac49384988733cbb706243943748c4ce7 
b906926e53dfa2e8927629e77a0708dda6f49d31 M    include


--

Link to the first bad commit: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=77b9040195dea3fcddf19e136c9e99a501351778


I was able to revert the first bad commit.

git revert 77b9040195dea3fcddf19e136c9e99a501351778

[master a91dcf9dc14c] Revert "compat_ioctl: simplify the implementation"
 4 files changed, 105 insertions(+), 64 deletions(-)

After that the avahi daemon works without any problems again.

I created a patch today. (attached)

It is also possible to deactivate the avahi daemon with the following lines
in the file "/etc/avahi/avahi-daemon.conf":

use-ipv4=no
use-ipv6=no

Could you please check your commit?

Thanks,
Christian
diff -rupN a/fs/internal.h b/fs/internal.h
--- a/fs/internal.h	2020-02-07 13:20:46.294317088 +0100
+++ b/fs/internal.h	2020-02-07 13:16:06.731416797 +0100
@@ -182,6 +182,12 @@ extern void mnt_pin_kill(struct mount *m
  */
 extern const struct dentry_operations ns_dentry_operations;
 
+/*
+ * fs/ioctl.c
+ */
+extern int do_vfs_ioctl(struct file *file, unsigned int fd, unsigned int cmd,
+		unsigned long arg);
+
 /* direct-io.c: */
 int sb_init_dio_done_wq(struct super_block *sb);
 
diff -rupN a/fs/ioctl.c b/fs/ioctl.c
--- a/fs/ioctl.c	2020-02-07 13:20:46.294317088 +0100
+++ b/fs/ioctl.c	2020-02-07 13:16:06.331418365 +0100
@@ -467,7 +467,7 @@ EXPORT_SYMBOL(generic_block_fiemap);
  * Only the l_start, l_len and l_whence fields of the 'struct space_resv'
  * are used here, rest are ignored.
  */
-static int ioctl_preallocate(struct file *filp, int mode, void __user *argp)
+int ioctl_preallocate(struct file *filp, int mode, void __user *argp)
 {
 	struct inode *inode = file_inode(filp);
 	struct space_resv sr;
@@ -495,8 +495,8 @@ static int ioctl_preallocate(struct file
 /* on ia32 l_start is on a 32-bit boundary */
 #if defined CONFIG_COMPAT && defined(CONFIG_X86_64)
 /* just account for different alignment */
-static int compat_ioctl_preallocate(struct file *file, int mode,
-struct space_resv_32 __user *argp)
+int compat_ioctl_preallocate(struct file *file, int mode,
+struct space_resv_32 __user *argp)
 {
 	struct inode *inode = file_inode(file);
 	struct space_resv_32 sr;
@@ -521,9 +521,11 @@ static int compat_ioctl_preallocate(stru
 }
 #endif
 
-static int file_ioctl(struct file *filp, unsigned int cmd, int __user *p)
+static int file_ioctl(struct file *filp, unsigned int cmd,
+		unsigned long arg)
 {
 	struct inode *inode = file_inode(filp);
+	int __user *p = (int __user *)arg;
 
 	switch (cmd) {
 	case FIBMAP:
@@ -540,7 +542,7 

Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device

2020-02-06 Thread Christian Zigotzky

On 06 February 2020 at 05:35 am, Michael Ellerman wrote:

Christian Zigotzky  writes:

Kernel 5.5 PowerPC is also affected.

I don't know what you mean by that. What sha are you talking about?

I have a system with avahi running and everything's fine.

   # grep use- /etc/avahi/avahi-daemon.conf
   use-ipv4=yes
   use-ipv6=yes
   
   # systemctl status -l --no-pager avahi-daemon

   ● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
  Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; vendor 
preset: enabled)
  Active: active (running) since Thu 2020-02-06 14:55:34 AEDT; 38min ago
Main PID: 1884 (avahi-daemon)
  Status: "avahi-daemon 0.7 starting up."
  CGroup: /system.slice/avahi-daemon.service
  ├─1884 avahi-daemon: running [mpe-ubuntu-le.local]
  └─1888 avahi-daemon: chroot helper
   
   Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address record for fe80::5054:ff:fe66:2a19 on eth0.*.

   Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address 
record for 10.61.141.81 on eth0.IPv4.
   Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address 
record for ::1 on lo.*.
   Feb 06 14:55:34 mpe-ubuntu-le avahi-daemon[1884]: Registering new address 
record for 127.0.0.1 on lo.IPv4.
   Feb 06 14:55:34 mpe-ubuntu-le systemd[1]: Started Avahi mDNS/DNS-SD Stack.
   Feb 06 14:55:35 mpe-ubuntu-le avahi-daemon[1884]: Server startup complete. 
Host name is mpe-ubuntu-le.local. Local service cookie is 3972418141.
   Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Leaving mDNS multicast 
group on interface eth0.IPv6 with address fe80::5054:ff:fe66:2a19.
   Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Joining mDNS multicast 
group on interface eth0.IPv6 with address fd69:d75f:b8b5:61:5054:ff:fe66:2a19.
   Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Registering new address 
record for fd69:d75f:b8b5:61:5054:ff:fe66:2a19 on eth0.*.
   Feb 06 14:55:38 mpe-ubuntu-le avahi-daemon[1884]: Withdrawing address record 
for fe80::5054:ff:fe66:2a19 on eth0.
   
   # uname -r

   5.5.0-gcc-8.2.0


The key question is what ioctl is it complaining about. You should be
able to find that via strace.

cheers


Hello Michael,

Sorry it isn't true that the kernel 5.5 is also affected. A Power Mac G5 
user told me that but this isn't correct. I compiled and tested the 
stable kernel 5.5.1 and 5.5.2 today and both kernels don't have the 
issue with the avahi daemon.

Could you please also test the latest Git kernel?

strace /usr/sbin/avahi-daemon

...
poll([{fd=4, events=POLLIN}, {fd=16, events=POLLIN}, {fd=15, 
events=POLLIN}, {fd=14, events=POLLIN}, {fd=13, events=POLLIN}, {fd=12, 
events=POLLIN}, {fd=11, events=POLLIN}, {fd=10, events=POLLIN}, {fd=9, 
events=POLLIN}, {fd=8, events=POLLIN}, {fd=6, events=POLLIN}], 11, 65) = 
2 ([{fd=12, revents=POLLIN}, {fd=9, revents=POLLIN}])
ioctl(12, FIONREAD, 0xffba6f24) = -1 ENOTTY (Inappropriate ioctl 
for device)
write(2, "ioctl(): Inappropriate ioctl for"..., 39ioctl(): Inappropriate 
ioctl for device) = 39

write(2, "\n", 1
)   = 1
...

Thanks,
Christian


Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device

2020-02-05 Thread Christian Zigotzky
Kernel 5.5 PowerPC is also affected.

— Christian

Christian Zigotzky wrote:

Hi All,

The issue with the avahi-daemon still exist in the latest Git kernel. It's a 
PowerPC issue. I compiled the latest Git kernel on a PC today and there aren't 
any issues with the avahi daemon. Another Power Mac user reported the same 
issue on his G5. I tested with the AmigaOne X1000 and X5000 in the last days.

I bisected today but I think the result isn't correct because it found the 
other problem with ordering of PCSCSI definition in esp_rev enum. I don't know 
how to bisect if there is another issue at the same time. Maybe "git bisect 
skip"?

2086faae3c55a652cfbd369e18ecdb703aacc493 is the first bad commit
commit 2086faae3c55a652cfbd369e18ecdb703aacc493
Author: Kars de Jong 
Date:   Tue Nov 19 21:20:20 2019 +0100

scsi: esp_scsi: Correct ordering of PCSCSI definition in esp_rev enum

The order of the definitions in the esp_rev enum is important. The values
are used in comparisons for chip features.

Add a comment to the enum explaining this.

Also, the actual values for the enum fields are irrelevant, so remove the
explicit values (suggested by Geert Uytterhoeven). This makes adding a new
field in the middle of the enum easier.

Finally, move the PCSCSI definition to the right place in the enum. In its
previous location, at the end of the enum, the wrong values are written to
the CONFIG3 register when used with FAST-SCSI targets.

Link: https://lore.kernel.org/r/20191119202021.28720-2-jo...@linux-m68k.org
Signed-off-by: Kars de Jong 
Signed-off-by: Martin K. Petersen 

:04 04 cdc128596e33fb60406b5de9b17b79623c187c1a 
48ceab06439f95285e8b30181e75f9a68c25fcb5 Mdrivers

Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device

2020-02-05 Thread Christian Zigotzky

On 03 February 2020 at 6:53 pm, Jakub Kicinski wrote:

On Sun, 2 Feb 2020 16:02:18 +0100, Christian Zigotzky wrote:

On 02 February 2020 at 09:19 am, Christophe Leroy wrote:

Hello,

Le 02/02/2020 à 01:08, Christian Zigotzky a écrit :

Hello,

We regularly compile and test Linux kernels every day during the
merge window. Since Thursday we have very high CPU loads because of
the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc).

Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for
device

Do you know which ioctl, on which device ?
Can you take a trace of running avahi-daemon with 'strace' ?

Can you bisect ?

Christophe

Hi Christophe,
Hi All,

I figured out that the avahi-daemon has a problem with the IPv6 address
of a network interface since the Git kernel from Thursday. (Log attached)
This generates high CPU usage because the avahi-daemon tries to access
the IPv6 address again and again and thereby it produces a lot of log
messages.

We figured out that the networking updates aren't responsible for this
issue because we created a test kernel on Wednesday. The issue is
somewhere in the commits from Wednesday night to Thursday (CET).

FWIW Thursday is when the latest networking pull came in, so could well
be networking related..


Please compile the latest Git kernel and test it with a desktop linux
distribution for example Ubuntu. In my point of view there are many
desktop machines affected. Many server systems don't use the avahi
daemon so they aren't affected.

It's possible to deactivate the access to the IPv6 address with the
following line in the file "/etc/avahi/avahi-daemon.conf":

use-ipv6=no

After a reboot the CPU usage is normal again. This is only a temporary
solution.

Unfortunately I don't have the time for bisecting next week. I have a
lot of other work to do. In my point of view it is very important that
you also compile the latest Git kernels. Then you will see the issue and
then you have a better possibility to fix the issue.

Hi All,

The issue still exist in the latest Git kernel. It's a PowerPC issue. I 
compiled the latest Git kernel on a PC today and there aren't any issues 
with the avahi daemon. Another Power Mac user reported the same issue on 
his G5. I tested with the AmigaOne X1000 and X5000 in the last days.


I bisected today but I think the result isn't correct because it founds 
the other problem with ordering of PCSCSI definition in esp_rev enum. I 
don't know how to bisect if there is another issue at the same time. 
Maybe "git bisect skip"?


2086faae3c55a652cfbd369e18ecdb703aacc493 is the first bad commit
commit 2086faae3c55a652cfbd369e18ecdb703aacc493
Author: Kars de Jong 
Date:   Tue Nov 19 21:20:20 2019 +0100

    scsi: esp_scsi: Correct ordering of PCSCSI definition in esp_rev enum

    The order of the definitions in the esp_rev enum is important. The 
values

    are used in comparisons for chip features.

    Add a comment to the enum explaining this.

    Also, the actual values for the enum fields are irrelevant, so 
remove the
    explicit values (suggested by Geert Uytterhoeven). This makes 
adding a new

    field in the middle of the enum easier.

    Finally, move the PCSCSI definition to the right place in the enum. 
In its
    previous location, at the end of the enum, the wrong values are 
written to

    the CONFIG3 register when used with FAST-SCSI targets.

    Link: 
https://lore.kernel.org/r/20191119202021.28720-2-jo...@linux-m68k.org

    Signed-off-by: Kars de Jong 
    Signed-off-by: Martin K. Petersen 

:04 04 cdc128596e33fb60406b5de9b17b79623c187c1a 
48ceab06439f95285e8b30181e75f9a68c25fcb5 M    drivers


Cheers,
Christian




Re: Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device

2020-02-02 Thread Christian Zigotzky

On 02 February 2020 at 09:19 am, Christophe Leroy wrote:

Hello,

Le 02/02/2020 à 01:08, Christian Zigotzky a écrit :

Hello,

We regularly compile and test Linux kernels every day during the 
merge window. Since Thuesday we have very high CPU loads because of 
the avahi daemon on our desktop Linux systems (Ubuntu, Debian etc).


Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for 
device


Do you know which ioctl, on which device ?
Can you take a trace of running avahi-daemon with 'strace' ?

Can you bisect ?

Christophe

Hi Christophe,
Hi All,

I figured out that the avahi-daemon has a problem with the IPv6 address 
of a network interface since the Git kernel from Thursday. (Log attached)
This generates high CPU usage because the avahi-daemon tries to access 
the IPv6 address again and again and thereby it produces a lot of log 
messages.


We figured out that the networking updates aren't responsible for this 
issue because we created a test kernel on Wednesday. The issue is 
somewhere in the commits from Wednesday night to Thursday (CET).


Please compile the latest Git kernel and test it with a desktop linux 
distribution for example Ubuntu. In my point of view there are many 
desktop machines affected. Many server systems don't use the avahi 
daemon so they aren't affected.


It's possible to deactivate the access to the IPv6 address with the 
following line in the file "/etc/avahi/avahi-daemon.conf":


use-ipv6=no

After a reboot the CPU usage is normal again. This is only a temporary 
solution.


Unfortunately I don't have the time for bisecting next week. I have a 
lot of other work to do. In my point of view it is very important that 
you also compile the latest Git kernels. Then you will see the issue and 
then you have a better possibility to fix the issue.


Thanks,
Christian
Kernel 5.5.0: journalctl | grep -i avahi
Feb 02 13:57:05 DC1 systemd[1]: Listening on Avahi mDNS/DNS-SD Stack Activation 
Socket.
Feb 02 13:57:05 DC1 systemd[1]: Starting Avahi mDNS/DNS-SD Stack...
Feb 02 13:57:05 DC1 avahi-daemon[4314]: Found user 'avahi' (UID 112) and group 
'avahi' (GID 122).
Feb 02 13:57:05 DC1 avahi-daemon[4314]: Successfully dropped root privileges.
Feb 02 13:57:05 DC1 avahi-daemon[4314]: avahi-daemon 0.6.32-rc starting up.
Feb 02 13:57:06 DC1 systemd[1]: Started Avahi DNS Configuration Daemon.
Feb 02 13:57:06 DC1 avahi-daemon[4314]: Successfully called chroot().
Feb 02 13:57:06 DC1 avahi-daemon[4314]: Successfully dropped remaining 
capabilities.
Feb 02 13:57:06 DC1 avahi-daemon[4314]: No service file found in 
/etc/avahi/services.
Feb 02 13:57:06 DC1 avahi-daemon[4314]: Network interface enumeration completed.
Feb 02 13:57:06 DC1 avahi-daemon[4314]: Server startup complete. Host name is 
DC1.local. Local service cookie is 3202921551.
Feb 02 13:57:06 DC1 avahi-daemon[4314]: Failed to parse address 'localhost', 
ignoring.
Feb 02 13:57:06 DC1 avahi-dnsconfd[4487]: Successfully connected to Avahi 
daemon.
Feb 02 13:57:06 DC1 systemd[1]: Started Avahi mDNS/DNS-SD Stack.
Feb 02 13:57:07 DC1 root[4749]: /etc/dhcp/dhclient-enter-hooks.d/avahi-autoipd 
returned non-zero exit status 1
Feb 02 13:57:07 DC1 avahi-daemon[4314]: Joining mDNS multicast group on 
interface enP4096p4s4.IPv4 with address 192.168.178.47.
Feb 02 13:57:07 DC1 avahi-daemon[4314]: New relevant interface enP4096p4s4.IPv4 
for mDNS.
Feb 02 13:57:07 DC1 avahi-daemon[4314]: Registering new address record for 
192.168.178.47 on enP4096p4s4.IPv4.
Feb 02 13:57:09 DC1 avahi-daemon[4314]: Joining mDNS multicast group on 
interface enP4096p4s4.IPv6 with address fe80::250:fcff:fecb:5181.
Feb 02 13:57:09 DC1 avahi-daemon[4314]: New relevant interface enP4096p4s4.IPv6 
for mDNS.
Feb 02 13:57:09 DC1 avahi-daemon[4314]: Registering new address record for 
fe80::250:fcff:fecb:5181 on enP4096p4s4.*.
Feb 02 13:57:10 DC1 avahi-daemon[4314]: Leaving mDNS multicast group on 
interface enP4096p4s4.IPv6 with address fe80::250:fcff:fecb:5181.
Feb 02 13:57:10 DC1 avahi-daemon[4314]: Joining mDNS multicast group on 
interface enP4096p4s4.IPv6 with address 2a02:8109:89c0:ebfc:250:fcff:fecb:5181.
Feb 02 13:57:10 DC1 avahi-daemon[4314]: Registering new address record for 
2a02:8109:89c0:ebfc:250:fcff:fecb:5181 on enP4096p4s4.*.
Feb 02 13:57:10 DC1 avahi-daemon[4314]: Withdrawing address record for 
fe80::250:fcff:fecb:5181 on enP4096p4s4.


--


Latest Git kernel (5.6): journalctl | grep -i avahi

Feb 02 14:04:04 DC1 systemd[1]: Listening on Avahi mDNS/DNS-SD Stack Activation 
Socket.
Feb 02 14:04:05 DC1 systemd[1]: Started Avahi DNS Configuration Daemon.
Feb 02 14:04:05 DC1 systemd[1]: Starting Avahi mDNS/DNS-SD Stack...
Feb 02 14:04:05 DC1 avahi-daemon[4573]: Found user 'avahi' (UID 112) and group 
'avahi' (GID 122).
Feb 02 14:04:05 DC1 avahi-daemon[4573]: Successfully dropped root privileges.
Feb 02 14:04:05 DC1 avahi-daemon[4573]: avahi-daemon 0.6.32-rc starting up.
Feb 02 14:04:05 DC1 avahi-daemon[4573]: Successfully called chr

Latest Git kernel: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device

2020-02-01 Thread Christian Zigotzky

Hello,

We regularly compile and test Linux kernels every day during the merge 
window. Since Thuesday we have very high CPU loads because of the avahi 
daemon on our desktop Linux systems (Ubuntu, Debian etc).


Error message: avahi-daemon[2410]: ioctl(): Inappropriate ioctl for device

Could you please test the latest Git kernel?

It is possible to deactivate the avahi daemon with the following lines 
in the file "/etc/avahi/avahi-daemon.conf":


use-ipv4=no
use-ipv6=no

But this is only a temporary solution.

Thanks,
Christian


Re: [PASEMI PA6T PPC] Onboard CF card device with new SanDisk High (>8G) CF cards

2020-01-28 Thread Christian Zigotzky

On 28 January 2020 at 3:16 pm, Rob Herring wrote:

On Tue, Jan 28, 2020 at 2:01 AM Christian Zigotzky
 wrote:

Hi All,

Which mailing list is responsible for the pata_pcmcia driver? We are
using new SanDisk High (>8G) CF cards with this driver [1] and we need
the following line in the file "drivers/ata/pata_pcmcia.c".

+PCMCIA_DEVICE_MANF_CARD(0x00f1, 0x0101),/* SanDisk High
(>8G) CFA */

Run get_maintainers.pl and it will answer that for you:

$ scripts/get_maintainer.pl -f drivers/ata/pata_pcmcia.c
Bartlomiej Zolnierkiewicz 
(maintainer:LIBATA PATA DRIVERS)
Jens Axboe  (maintainer:LIBATA PATA DRIVERS)
linux-...@vger.kernel.org (open list:LIBATA PATA DRIVERS)
linux-ker...@vger.kernel.org (open list)

Thank you!


[PASEMI PA6T PPC] Onboard CF card device with new SanDisk High (>8G) CF cards

2020-01-28 Thread Christian Zigotzky

Hi All,

Which mailing list is responsible for the pata_pcmcia driver? We are 
using new SanDisk High (>8G) CF cards with this driver [1] and we need 
the following line in the file "drivers/ata/pata_pcmcia.c".


+    PCMCIA_DEVICE_MANF_CARD(0x00f1, 0x0101),        /* SanDisk High 
(>8G) CFA */


Thanks,
Christian

[1] https://forum.hyperion-entertainment.com/viewtopic.php?f=35=4282


  1   2   3   4   >