[PPC] Kernel doesn't boot after DRM updates (drm-next-2024-09-19)
On 22 September 2024 at 08:48 am, Christian Zigotzky wrote: On 21 September 2024 at 06:15 am, Christian Zigotzky wrote: Hi All, The lastest Git kernel doesn't boot anymore after the latest DRM updates (drm-next-2024-09-19). [1] I tested it with an AMD Radeon HD 6970 (Cayman XT) and with an AMD Radeon HD 5870 (Cypress XT). I reverted the DRM updates and after that the kernel boots without any problems. Please note: Due to a lack of time, I can't do a bisect. Please check the latest DRM updates. Thanks, Christian [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=de848da12f752170c2ebe114804a985314fd5a6a I replaced the new Radeon DRM driver from the Git kernel with the Radeon DRM driver from the kernel 6.11. (cp -R linux-6.11/drivers/gpu/drm/radeon a/drivers/gpu/drm/) It compiles without any problems but unfortunately the kernel doesn't boot either. Have you tested the new Radeon DRM driver with AMD Radeon graphics cards? Maybe this is the issue (included in the latest DRM updates - drm-next-2024-09-19): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/arch/powerpc/kernel/nvram_64.c?id=de848da12f752170c2ebe114804a985314fd5a6a + linuxppc-dev + Christophe Leroy + Michael Ellerman
Re: [PATCH] powerpc/vdso32: Fix use of crtsavres for PPC64
On 19. Sep 2024, at 20:56, Christophe Leroy wrote:
crtsavres.S content is encloded by a #ifndef CONFIG_PPC64
To be used on VDSO32 on PPC64 it's content must available on PPC64 as
well.
Replace #ifndef CONFIG_PPC64 by #ifndef __powerpc64__ as __powerpc64__
is not set when building VDSO32 on PPC64.
Reported-by: Christian Zigotzky
Closed:
https://lore.kernel.org/linuxppc-dev/047b7503-af0c-4bb0-b12a-2f6b1e461...@csgroup.eu/T/
Fixes: b163596a5b6f ("powerpc/vdso32: Add crtsavres")
Signed-off-by: Christophe Leroy
---
arch/powerpc/lib/crtsavres.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/lib/crtsavres.S b/arch/powerpc/lib/crtsavres.S
index 7e5e1c28e56a..8967903c15e9 100644
--- a/arch/powerpc/lib/crtsavres.S
+++ b/arch/powerpc/lib/crtsavres.S
@@ -46,7 +46,7 @@
.section ".text"
-#ifndef CONFIG_PPC64
+#ifndef __powerpc64__
/* Routines for saving integer registers, called by the compiler. */
/* Called with r11 pointing to the stack header word of the caller of the */
--
2.44.0
It works! Thank you.
Tested-by: Christian Zigotzky
[FSL P50x0] [GIT KERNEL] [VDSO] compiling issue
Hi All, The compiling of the latest Git kernel doesn’t work anymore for our FSL P5020/P5040 boards [1] since the random-6.12-rc1 updates [2]. Error messages: arch/powerpc/kernel/vdso/vdso32.so.dbg: dynamic relocations are not supported make[2]: *** [arch/powerpc/kernel/vdso/Makefile:75: arch/powerpc/kernel/vdso/vdso32.so.dbg] Reverting of the vdso updates has solved the compiing issue. Could you please check the random-6.12-rc1 updates? [2] Thanks, Christian [1] http://wiki.amiga.org/index.php?title=X5000 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4a39ac5b7d62679c07a3e3d12b0f6982377d8a7d + Kernel config Link: https://raw.githubusercontent.com/chzigotzky/kernels/refs/heads/main/configs/x5000_defconfig + Christophe Leroy + Michael Ellerman
[FSL P50x0] [GIT KERNEL] [VDSO] compiling issue
On 19 September 2024 at 2:29 pm, Christian Zigotzky wrote: Hi All, The compiling of the latest Git kernel doesn’t work anymore for our FSL P5020/P5040 boards [1] since the random-6.12-rc1 updates [2]. Error messages: arch/powerpc/kernel/vdso/vdso32.so.dbg: dynamic relocations are not supported make[2]: *** [arch/powerpc/kernel/vdso/Makefile:75: arch/powerpc/kernel/vdso/vdso32.so.dbg] Reverting of the vdso updates has solved the compiing issue. Could you please check the random-6.12-rc1 updates? [2] Thanks, Christian [1] http://wiki.amiga.org/index.php?title=X5000 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4a39ac5b7d62679c07a3e3d12b0f6982377d8a7d + Kernel config Link: https://raw.githubusercontent.com/chzigotzky/kernels/refs/heads/main/configs/x5000_defconfig
[FSL P50x0] [GIT KERNEL] [VDSO] compiling issue
Hi All, The compiling of the latest Git kernel doesn’t work anymore for our FSL P5020/P5040 boards [1] since the random-6.12-rc1 updates [2]. Error messages: arch/powerpc/kernel/vdso/vdso32.so.dbg: dynamic relocations are not supported make[2]: *** [arch/powerpc/kernel/vdso/Makefile:75: arch/powerpc/kernel/vdso/vdso32.so.dbg] Reverting of the vdso updates has solved the compiing issue. Could you please check the random-6.12-rc1 updates? [2] Thanks, Christian [1] http://wiki.amiga.org/index.php?title=X5000 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4a39ac5b7d62679c07a3e3d12b0f6982377d8a7d
Re: [PowerPC] [PASEMI] Issue with the identification of ATA drives after the of/irq updates 2024-05-29
On 10.07.24 17:05, Rob Herring wrote: On Tue, Jul 9, 2024 at 9:53 PM Christian Zigotzky wrote: Hi All, The RC7 of kernel 6.10 boots without any problems [1] if we use the second irq patch [2]. Is it possible to add this patch to the mainline kernel? Yes, sent it to Linus yesterday. Rob Great! Thank you very much! :-) Christian
Re: [PowerPC] [PASEMI] Issue with the identification of ATA drives after the of/irq updates 2024-05-29
Hi All, The RC7 of kernel 6.10 boots without any problems [1] if we use the second irq patch [2]. Is it possible to add this patch to the mainline kernel? Thanks, Christian [1] https://forum.hyperion-entertainment.com/viewtopic.php?p=58643#p58643 [2] https://github.com/chzigotzky/kernels/blob/main/patches/X1000/of_irq_v4.patch
Re: [PowerPC] [PASEMI] Issue with the identification of ATA drives after the of/irq updates 2024-05-29
On 6. Jul 2024, at 06:15, Christian Zigotzky wrote:
Our tester has tested the second irq patch again and the kernel boots. We will
test it again to be sure that it really works. ;-)
Second irq patch:
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 462375b293e47..c94203ce65bb3 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -81,7 +81,8 @@ EXPORT_SYMBOL_GPL(of_irq_find_parent);
/*
* These interrupt controllers abuse interrupt-map for unspeakable
* reasons and rely on the core code to *ignore* it (the drivers do
- * their own parsing of the property).
+ * their own parsing of the property). The PAsemi entry covers a
+ * non-sensical interrupt-map that is better left ignored.
*
* If you think of adding to the list for something *new*, think
* again. There is a high chance that you will be sent back to the
@@ -95,6 +96,7 @@ static const char * const of_irq_imap_abusers[] = {
"fsl,ls1043a-extirq",
"fsl,ls1088a-extirq",
"renesas,rza1-irqc",
+"pasemi,rootbus",
NULL,
};
@@ -293,20 +295,8 @@ int of_irq_parse_raw(const __be32 *addr, struct
of_phandle_args *out_irq)
imaplen -= imap - oldimap;
pr_debug(" -> imaplen=%d\n", imaplen);
}
-if (!match) {
-if (intc) {
-/*
- * The PASEMI Nemo is a known offender, so
- * let's only warn for anyone else.
- */
-WARN(!IS_ENABLED(CONFIG_PPC_PASEMI),
- "%pOF interrupt-map failed, using interrupt-controller\n",
- ipar);
-return 0;
-}
-
+if (!match)
goto fail;
-}
/*
* Successfully parsed an interrupt-map translation; copy new
-
Great news! Our tester has tested this second irq patch again and it boots.
Link: https://forum.hyperion-entertainment.com/viewtopic.php?p=58632#p58632
We will use this patch for the kernel 6.10-rc7.
- - Christian
Re: [PowerPC] [PASEMI] Issue with the identification of ATA drives after the of/irq updates 2024-05-29
On 05.07.24 03:19, Michael Ellerman wrote:
Right, I had some debug code that I removed before posting.
This version should compile :}
cheers
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index fbb68fc28ed3..965d58c54fab 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -3123,6 +3123,7 @@ static void __init fixup_device_tree_pasemi(void)
u32 interrupts[2], parent, rval, val = 0;
char *name, *pci_name;
phandle iob, node;
+ int rc;
/* Find the root pci node */
name = "/pxp@0,e000";
@@ -3138,6 +3139,14 @@ static void __init fixup_device_tree_pasemi(void)
prom_setprop(iob, name, "interrupt-controller", &val, 0);
+ prom_printf("nemo: deleting interrupt-map properties\n");
+ rc = call_prom("interpret", 1, 1,
+ " s\" /pxp@0,e000\" find-device"
+ " s\" interrupt-map\" delete-property"
+ " s\" interrupt-map-mask\" delete-property"
+ " device-end");
+ prom_printf("nemo: interpret returned %d\n", rc);
+
pci_name = "/pxp@0,e000/pci@11";
node = call_prom("finddevice", 1, 1, ADDR(pci_name));
parent = ADDR(iob);
Michael,
Thank you for the patch! Unfortunately the kernel doesn't boot.
See: https://forum.hyperion-entertainment.com/viewtopic.php?p=58629#p58629
Our tester has tested the second irq patch again and the kernels boots.
We will test it again to be sure that it really work. ;-)
Second irq patch:
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 462375b293e47..c94203ce65bb3 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -81,7 +81,8 @@ EXPORT_SYMBOL_GPL(of_irq_find_parent);
/*
* These interrupt controllers abuse interrupt-map for unspeakable
* reasons and rely on the core code to *ignore* it (the drivers do
- * their own parsing of the property).
+ * their own parsing of the property). The PAsemi entry covers a
+ * non-sensical interrupt-map that is better left ignored.
*
* If you think of adding to the list for something *new*, think
* again. There is a high chance that you will be sent back to the
@@ -95,6 +96,7 @@ static const char * const of_irq_imap_abusers[] = {
"fsl,ls1043a-extirq",
"fsl,ls1088a-extirq",
"renesas,rza1-irqc",
+ "pasemi,rootbus",
NULL,
};
@@ -293,20 +295,8 @@ int of_irq_parse_raw(const __be32 *addr, struct
of_phandle_args *out_irq)
imaplen -= imap - oldimap;
pr_debug(" -> imaplen=%d\n", imaplen);
}
- if (!match) {
- if (intc) {
- /*
- * The PASEMI Nemo is a known offender, so
- * let's only warn for anyone else.
- */
- WARN(!IS_ENABLED(CONFIG_PPC_PASEMI),
- "%pOF interrupt-map failed, using
interrupt-controller\n",
- ipar);
- return 0;
- }
-
+ if (!match)
goto fail;
- }
/*
* Successfully parsed an interrupt-map translation; copy new
-
dmesg:
[ 0.00] hash-mmu: Page sizes from device-tree:
[ 0.00] hash-mmu: base_shift=12: shift=12, sllp=0x,
avpnm=0x, tlbiel=1, penc=0
[ 0.00] hash-mmu: base_shift=16: shift=16, sllp=0x0110,
avpnm=0x, tlbiel=1, penc=3
[ 0.00] hash-mmu: base_shift=20: shift=20, sllp=0x0030,
avpnm=0x, tlbiel=0, penc=31
[ 0.00] hash-mmu: base_shift=24: shift=24, sllp=0x0100,
avpnm=0x0001, tlbiel=0, penc=0
[ 0.00] Page orders: linear mapping = 24, virtual = 12, io = 12,
vmemmap = 24
[ 0.00] Using 1TB segments
[ 0.00] hash-mmu: Initializing hash mmu with SLB
[ 0.00] Linux version 6.10.0-rc6-powerpc64-smp (christian@lx-cce)
(powerpc-linux-gnu-gcc (Debian 9.5.0-1) 9.5.0, GNU ld (GNU Binutils for
Debian) 2.42) #1 SMP Thu Jul 4 18:40:38 CEST 2024
[ 0.00] IOBMAP L2 allocated at: (ptrval)
[ 0.00] ioremap() called early from
.iommu_init_early_pasemi+0xec/0x260. Use early_ioremap() instead
[ 0.00] Hardware name: pasemi,nemo PA6T 0x900102 A-EON Amigaone X1000
[ 0.00] Found legacy serial port 0 for /pxp@0,e000/serial@1d
[ 0.00] port=7f03f8, taddr=fcff03f8, irq=0, clk=1,
speed=115200
[ 0.00] Found legacy serial port 1 for /pxp@0,e000/serial@1d,1
[ 0.00] port=7f02f8, taddr=fcff02f8, irq=0, clk=1,
speed=115200
[ 0.00] CPU maps initialized for 1 thread per core
[ 0.00] (thread shift is 0)
[ 0.00] Allocated 2320 bytes for 2 pacas
[ 0.00] -
[ 0.00] phys_mem_size = 0x1
[ 0.00] dcache_bsize = 0x40
[ 0.00] icache_bsize = 0x40
[ 0.00] cpu_features = 0x01401182
[ 0.00] possible = 0x001ffbebb18f
[
Re: [PowerPC] [PASEMI] Issue with the identification of ATA drives after the of/irq updates 2024-05-29
Types corrected and html removed
On 05.07.24 03:19, Michael Ellerman wrote:
>
>
> Right, I had some debug code that I removed before posting.
>
> This version should compile :}
>
> cheers
>
> diff --git a/arch/powerpc/kernel/prom_init.c
b/arch/powerpc/kernel/prom_init.c
> index fbb68fc28ed3..965d58c54fab 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -3123,6 +3123,7 @@ static void __init fixup_device_tree_pasemi(void)
> u32 interrupts[2], parent, rval, val = 0;
> char *name, *pci_name;
> phandle iob, node;
> + int rc;
>
> /* Find the root pci node */
> name = "/pxp@0,e000";
> @@ -3138,6 +3139,14 @@ static void __init fixup_device_tree_pasemi(void)
>
> prom_setprop(iob, name, "interrupt-controller", &val, 0);
>
> + prom_printf("nemo: deleting interrupt-map properties\n");
> + rc = call_prom("interpret", 1, 1,
> + " s\" /pxp@0,e000\" find-device"
> + " s\" interrupt-map\" delete-property"
> + " s\" interrupt-map-mask\" delete-property"
> + " device-end");
> + prom_printf("nemo: interpret returned %d\n", rc);
> +
> pci_name = "/pxp@0,e000/pci@11";
> node = call_prom("finddevice", 1, 1, ADDR(pci_name));
> parent = ADDR(iob);
Michael,
Thank you for the patch! Unfortunately the kernel doesn't boot.
See: https://forum.hyperion-entertainment.com/viewtopic.php?p=58629#p58629
Our tester has tested the second irq patch again and the kernel boots.
We will test it again to be sure that it really works. ;-)
Second irq patch:
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 462375b293e47..c94203ce65bb3 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -81,7 +81,8 @@ EXPORT_SYMBOL_GPL(of_irq_find_parent);
/*
* These interrupt controllers abuse interrupt-map for unspeakable
* reasons and rely on the core code to *ignore* it (the drivers do
- * their own parsing of the property).
+ * their own parsing of the property). The PAsemi entry covers a
+ * non-sensical interrupt-map that is better left ignored.
*
* If you think of adding to the list for something *new*, think
* again. There is a high chance that you will be sent back to the
@@ -95,6 +96,7 @@ static const char * const of_irq_imap_abusers[] = {
"fsl,ls1043a-extirq",
"fsl,ls1088a-extirq",
"renesas,rza1-irqc",
+ "pasemi,rootbus",
NULL,
};
@@ -293,20 +295,8 @@ int of_irq_parse_raw(const __be32 *addr, struct
of_phandle_args *out_irq)
imaplen -= imap - oldimap;
pr_debug(" -> imaplen=%d\n", imaplen);
}
- if (!match) {
- if (intc) {
- /*
- * The PASEMI Nemo is a known offender, so
- * let's only warn for anyone else.
- */
- WARN(!IS_ENABLED(CONFIG_PPC_PASEMI),
- "%pOF interrupt-map failed, using
interrupt-controller\n",
- ipar);
- return 0;
- }
-
+ if (!match)
goto fail;
- }
/*
* Successfully parsed an interrupt-map translation; copy new
-
dmesg:
[ 0.00] hash-mmu: Page sizes from device-tree:
[ 0.00] hash-mmu: base_shift=12: shift=12, sllp=0x,
avpnm=0x, tlbiel=1, penc=0
[ 0.00] hash-mmu: base_shift=16: shift=16, sllp=0x0110,
avpnm=0x, tlbiel=1, penc=3
[ 0.00] hash-mmu: base_shift=20: shift=20, sllp=0x0030,
avpnm=0x, tlbiel=0, penc=31
[ 0.00] hash-mmu: base_shift=24: shift=24, sllp=0x0100,
avpnm=0x0001, tlbiel=0, penc=0
[ 0.00] Page orders: linear mapping = 24, virtual = 12, io = 12,
vmemmap = 24
[ 0.00] Using 1TB segments
[ 0.00] hash-mmu: Initializing hash mmu with SLB
[ 0.00] Linux version 6.10.0-rc6-powerpc64-smp (christian@lx-cce)
(powerpc-linux-gnu-gcc (Debian 9.5.0-1) 9.5.0, GNU ld (GNU Binutils for
Debian) 2.42) #1 SMP Thu Jul 4 18:40:38 CEST 2024
[ 0.00] IOBMAP L2 allocated at: (ptrval)
[ 0.00] ioremap() called early from
.iommu_init_early_pasemi+0xec/0x260. Use early_ioremap() instead
[ 0.00] Hardware name: pasemi,nemo PA6T 0x900102 A-EON Amigaone X1000
[ 0.00] Found legacy serial port 0 for /pxp@0,e000/serial@1d
[ 0.00] port=7f03f8, taddr=fcff03f8, irq=0, clk=1,
speed=115200
[ 0.00] Found legacy serial port 1 for /pxp@0,e000/serial@1d,1
[ 0.00] port=7f02f8, taddr=fcff02f8, irq=0, clk=1,
speed=115200
[ 0.00] CPU maps initialized for 1 thread per core
[ 0.00] (thread shift is 0)
[ 0.00] Allocated 2320 bytes for 2 pacas
[ 0.00] -
[ 0.00] phys_mem_size = 0x1
[ 0.00] dcache_bsize = 0x40
[ 0.00] icache_bsize = 0x40
[ 0.00] cpu_features = 0x01401182
[ 0.00]
Re: [PowerPC] [PASEMI] Issue with the identification of ATA drives after the of/irq updates 2024-05-29
On 05.07.24 03:19, Michael Ellerman wrote:
>
>
> Right, I had some debug code that I removed before posting.
>
> This version should compile :}
>
> cheers
>
> diff --git a/arch/powerpc/kernel/prom_init.c
b/arch/powerpc/kernel/prom_init.c
> index fbb68fc28ed3..965d58c54fab 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -3123,6 +3123,7 @@ static void __init fixup_device_tree_pasemi(void)
> u32 interrupts[2], parent, rval, val = 0;
> char *name, *pci_name;
> phandle iob, node;
> + int rc;
>
> /* Find the root pci node */
> name = "/pxp@0,e000";
> @@ -3138,6 +3139,14 @@ static void __init fixup_device_tree_pasemi(void)
>
> prom_setprop(iob, name, "interrupt-controller", &val, 0);
>
> + prom_printf("nemo: deleting interrupt-map properties\n");
> + rc = call_prom("interpret", 1, 1,
> + " s\" /pxp@0,e000\" find-device"
> + " s\" interrupt-map\" delete-property"
> + " s\" interrupt-map-mask\" delete-property"
> + " device-end");
> + prom_printf("nemo: interpret returned %d\n", rc);
> +
> pci_name = "/pxp@0,e000/pci@11";
> node = call_prom("finddevice", 1, 1, ADDR(pci_name));
> parent = ADDR(iob);
Michael,
Thank you for the patch! Unfortunately the kernel doesn't boot.
See: https://forum.hyperion-entertainment.com/viewtopic.php?p=58629#p58629
Our tester has tested the second irq patch again and the kernels boots.
We will test it again to be sure that it really work. ;-)
Second irq patch:
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 462375b293e47..c94203ce65bb3 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -81,7 +81,8 @@ EXPORT_SYMBOL_GPL(of_irq_find_parent);
/*
* These interrupt controllers abuse interrupt-map for unspeakable
* reasons and rely on the core code to *ignore* it (the drivers do
- * their own parsing of the property).
+ * their own parsing of the property). The PAsemi entry covers a
+ * non-sensical interrupt-map that is better left ignored.
*
* If you think of adding to the list for something *new*, think
* again. There is a high chance that you will be sent back to the
@@ -95,6 +96,7 @@ static const char * const of_irq_imap_abusers[] = {
"fsl,ls1043a-extirq",
"fsl,ls1088a-extirq",
"renesas,rza1-irqc",
+ "pasemi,rootbus",
NULL,
};
@@ -293,20 +295,8 @@ int of_irq_parse_raw(const __be32 *addr, struct
of_phandle_args *out_irq)
imaplen -= imap - oldimap;
pr_debug(" -> imaplen=%d\n", imaplen);
}
- if (!match) {
- if (intc) {
- /*
- * The PASEMI Nemo is a known offender, so
- * let's only warn for anyone else.
- */
- WARN(!IS_ENABLED(CONFIG_PPC_PASEMI),
- "%pOF interrupt-map failed, using
interrupt-controller\n",
- ipar);
- return 0;
- }
-
+ if (!match)
goto fail;
- }
/*
* Successfully parsed an interrupt-map translation; copy new
-
dmesg:
[ 0.00] hash-mmu: Page sizes from device-tree:
[ 0.00] hash-mmu: base_shift=12: shift=12, sllp=0x,
avpnm=0x, tlbiel=1, penc=0
[ 0.00] hash-mmu: base_shift=16: shift=16, sllp=0x0110,
avpnm=0x, tlbiel=1, penc=3
[ 0.00] hash-mmu: base_shift=20: shift=20, sllp=0x0030,
avpnm=0x, tlbiel=0, penc=31
[ 0.00] hash-mmu: base_shift=24: shift=24, sllp=0x0100,
avpnm=0x0001, tlbiel=0, penc=0
[ 0.00] Page orders: linear mapping = 24, virtual = 12, io = 12,
vmemmap = 24
[ 0.00] Using 1TB segments
[ 0.00] hash-mmu: Initializing hash mmu with SLB
[ 0.00] Linux version 6.10.0-rc6-powerpc64-smp (christian@lx-cce)
(powerpc-linux-gnu-gcc (Debian 9.5.0-1) 9.5.0, GNU ld (GNU Binutils for
Debian) 2.42) #1 SMP Thu Jul 4 18:40:38 CEST 2024
[ 0.00] IOBMAP L2 allocated at: (ptrval)
[ 0.00] ioremap() called early from
.iommu_init_early_pasemi+0xec/0x260. Use early_ioremap() instead
[ 0.00] Hardware name: pasemi,nemo PA6T 0x900102 A-EON Amigaone X1000
[ 0.00] Found legacy serial port 0 for /pxp@0,e000/serial@1d
[ 0.00] port=7f03f8, taddr=fcff03f8, irq=0, clk=1,
speed=115200
[ 0.00] Found legacy serial port 1 for /pxp@0,e000/serial@1d,1
[ 0.00] port=7f02f8, taddr=fcff02f8, irq=0, clk=1,
speed=115200
[ 0.00] CPU maps initialized for 1 thread per core
[ 0.00] (thread shift is 0)
[ 0.00] Allocated 2320 bytes for 2 pacas
[ 0.00] -
[ 0.00] phys_mem_size = 0x1
[ 0.00] dcache_bsize = 0x40
[ 0.00] icache_bsize = 0x40
[ 0.00] cpu_features = 0x01401182
[ 0.00] possible = 0x001ffbebb1
Re: [PowerPC] [PASEMI] Issue with the identification of ATA drives after the of/irq updates 2024-05-29
How about the other patch[1], which would be far preferable? M. [1] https://lore.kernel.org/all/86ed8ba2sp.wl-...@kernel.org - - - - Marc, We will test the patch as soon as possible. Christian - - - - Our tester has reported, that it doesn’t boot. Link: https://forum.hyperion-entertainment.com/viewtopic.php?p=58627#p58627
Re: [PowerPC] [PASEMI] Issue with the identification of ATA drives after the of/irq updates 2024-05-29
How about the other patch[1], which would be far preferable? M. [1] https://lore.kernel.org/all/86ed8ba2sp.wl-...@kernel.org - - - - Marc, We will test the patch as soon as possible. Christian - - - - Our tester has reported, that it doesn’t boot. Link: https://forum.hyperion-entertainment.com/viewtopic.php?p=58627#p58627
Re: [PowerPC] [PASEMI] Issue with the identification of ATA drives after the of/irq updates 2024-05-29
[snip]
My earlier request for valuable debug information still stands. But
while you're at it, can you please give the following hack a go?
M.
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -282,8 +282,10 @@ int of_irq_parse_raw(const __be32 *addr, struct
of_phandle_args *out_irq)
oldimap = imap;
imap = of_irq_parse_imap_parent(oldimap, imaplen, out_irq);
-if (!imap)
-goto fail;
+if (!imap) {
+match = 0;
+break;
+}
match &= of_device_is_available(out_irq->np);
if (match)
This may not be the final workaround even if it solves your boot
problem, but will at least give us a hint at what is going wrong.
I have the fuzzy feeling that we may be able to lob this broken system
as part of the of_irq_imap_abusers[] array, which would solve things
pretty "neatly".
M.
- - - -
We tested this patch yesterday and it solves the boot problem.
Thanks
- - - -
I am sorry our tester was wrong and has reported, that this kernel doesn’t boot.
Link: https://forum.hyperion-entertainment.com/viewtopic.php?p=58627#p58627
Sorry
Re: [PowerPC] [PASEMI] Issue with the identification of ATA drives after the of/irq updates 2024-05-29
On 04.07.24 20:27, Christian Zigotzky wrote:
On 04.07.24 13:53, Michael Ellerman wrote:
Christian Zigotzky writes:
On 02.07.24 18:54, Marc Zyngier wrote:
On Sun, 30 Jun 2024 11:21:55 +0100,
Christian Zigotzky wrote:
Hello,
There is an issue with the identification of ATA drives with our
P.A. Semi Nemo boards [1] after the
commit "of/irq: Factor out parsing of interrupt-map parent
phandle+args from of_irq_parse_raw()" [2].
...
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -282,8 +282,10 @@ int of_irq_parse_raw(const __be32 *addr,
struct of_phandle_args *out_irq)
oldimap = imap;
imap = of_irq_parse_imap_parent(oldimap, imaplen,
out_irq);
- if (!imap)
- goto fail;
+ if (!imap) {
+ match = 0;
+ break;
+ }
match &= of_device_is_available(out_irq->np);
if (match)
We tested this patch yesterday and it solves the boot problem.
Hi Christian,
Instead of that patch, can you try the one below. AFAICS the device tree
fixups done in early boot mean the interrupt-map is not needed, and also
has the wrong content, so if we can remove it entirely that might avoid
the problems in the parsing code.
I don't know if your firmware actually implements those methods, I
couldn't find anything online to confirm or deny it. Seems the only
option is to test it.
cheers
diff --git a/arch/powerpc/kernel/prom_init.c
b/arch/powerpc/kernel/prom_init.c
index fbb68fc28ed3..28fe082ede57 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -3138,6 +3138,14 @@ static void __init fixup_device_tree_pasemi(void)
prom_setprop(iob, name, "interrupt-controller", &val, 0);
+ prom_printf("nemo: deleting interrupt-map properties\n");
+ rc = call_prom("interpret", 1, 1,
+ " s\" /pxp@0,e000\" find-device"
+ " s\" interrupt-map\" delete-property"
+ " s\" interrupt-map-mask\" delete-property"
+ " device-end");
+ prom_printf("nemo: interpret returned %d\n", rc);
+
pci_name = "/pxp@0,e000/pci@11";
node = call_prom("finddevice", 1, 1, ADDR(pci_name));
parent = ADDR(iob);
Hi Michael,
Many thanks for your patch. We will test it as soon as possible.
Christian
Michael,
Unfortunately, the kernel 6.10-rc6 doesn't compile with your patch. "rc"
is undeclared.
Error messages:
arch/powerpc/kernel/prom_init.c: In function ‘fixup_device_tree_pasemi’:
arch/powerpc/kernel/prom_init.c:3142:2: error: ‘rc’ undeclared (first
use in this function); did you mean ‘rq’?
3142 | rc = call_prom("interpret", 1, 1,
| ^~
| rq
Christian
Re: [PowerPC] [PASEMI] Issue with the identification of ATA drives after the of/irq updates 2024-05-29
On 04.07.24 10:28, Marc Zyngier wrote:
On Thu, 04 Jul 2024 05:10:46 +0100,
Christian Zigotzky wrote:
On 02.07.24 18:54, Marc Zyngier wrote:
On Sun, 30 Jun 2024 11:21:55 +0100,
Christian Zigotzky wrote:
Hello,
There is an issue with the identification of ATA drives with our
P.A. Semi Nemo boards [1] after the
commit "of/irq: Factor out parsing of interrupt-map parent
phandle+args from of_irq_parse_raw()" [2].
[snip]
My earlier request for valuable debug information still stands. But
while you're at it, can you please give the following hack a go?
M.
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -282,8 +282,10 @@ int of_irq_parse_raw(const __be32 *addr, struct
of_phandle_args *out_irq)
oldimap = imap;
imap = of_irq_parse_imap_parent(oldimap, imaplen,
out_irq);
- if (!imap)
- goto fail;
+ if (!imap) {
+ match = 0;
+ break;
+ }
match &= of_device_is_available(out_irq->np);
if (match)
This may not be the final workaround even if it solves your boot
problem, but will at least give us a hint at what is going wrong.
I have the fuzzy feeling that we may be able to lob this broken system
as part of the of_irq_imap_abusers[] array, which would solve things
pretty "neatly".
M.
We tested this patch yesterday and it solves the boot problem.
How about the other patch[1], which would be far preferable?
M.
[1] https://lore.kernel.org/all/86ed8ba2sp.wl-...@kernel.org
Marc,
We will test the patch as soon as possible.
Christian
Re: [PowerPC] [PASEMI] Issue with the identification of ATA drives after the of/irq updates 2024-05-29
On 04.07.24 13:53, Michael Ellerman wrote:
Christian Zigotzky writes:
On 02.07.24 18:54, Marc Zyngier wrote:
On Sun, 30 Jun 2024 11:21:55 +0100,
Christian Zigotzky wrote:
Hello,
There is an issue with the identification of ATA drives with our
P.A. Semi Nemo boards [1] after the
commit "of/irq: Factor out parsing of interrupt-map parent
phandle+args from of_irq_parse_raw()" [2].
...
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -282,8 +282,10 @@ int of_irq_parse_raw(const __be32 *addr, struct
of_phandle_args *out_irq)
oldimap = imap;
imap = of_irq_parse_imap_parent(oldimap, imaplen,
out_irq);
- if (!imap)
- goto fail;
+ if (!imap) {
+ match = 0;
+ break;
+ }
match &= of_device_is_available(out_irq->np);
if (match)
We tested this patch yesterday and it solves the boot problem.
Hi Christian,
Instead of that patch, can you try the one below. AFAICS the device tree
fixups done in early boot mean the interrupt-map is not needed, and also
has the wrong content, so if we can remove it entirely that might avoid
the problems in the parsing code.
I don't know if your firmware actually implements those methods, I
couldn't find anything online to confirm or deny it. Seems the only
option is to test it.
cheers
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index fbb68fc28ed3..28fe082ede57 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -3138,6 +3138,14 @@ static void __init fixup_device_tree_pasemi(void)
prom_setprop(iob, name, "interrupt-controller", &val, 0);
+ prom_printf("nemo: deleting interrupt-map properties\n");
+ rc = call_prom("interpret", 1, 1,
+ " s\" /pxp@0,e000\" find-device"
+ " s\" interrupt-map\" delete-property"
+ " s\" interrupt-map-mask\" delete-property"
+ " device-end");
+ prom_printf("nemo: interpret returned %d\n", rc);
+
pci_name = "/pxp@0,e000/pci@11";
node = call_prom("finddevice", 1, 1, ADDR(pci_name));
parent = ADDR(iob);
Hi Michael,
Many thanks for your patch. We will test it as soon as possible.
Christian
Re: [PowerPC] [PASEMI] Issue with the identification of ATA drives after the of/irq updates 2024-05-29
On 02.07.24 18:54, Marc Zyngier wrote:
On Sun, 30 Jun 2024 11:21:55 +0100,
Christian Zigotzky wrote:
Hello,
There is an issue with the identification of ATA drives with our
P.A. Semi Nemo boards [1] after the
commit "of/irq: Factor out parsing of interrupt-map parent
phandle+args from of_irq_parse_raw()" [2].
[snip]
My earlier request for valuable debug information still stands. But
while you're at it, can you please give the following hack a go?
M.
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -282,8 +282,10 @@ int of_irq_parse_raw(const __be32 *addr, struct
of_phandle_args *out_irq)
oldimap = imap;
imap = of_irq_parse_imap_parent(oldimap, imaplen,
out_irq);
- if (!imap)
- goto fail;
+ if (!imap) {
+ match = 0;
+ break;
+ }
match &= of_device_is_available(out_irq->np);
if (match)
This may not be the final workaround even if it solves your boot
problem, but will at least give us a hint at what is going wrong.
I have the fuzzy feeling that we may be able to lob this broken system
as part of the of_irq_imap_abusers[] array, which would solve things
pretty "neatly".
M.
We tested this patch yesterday and it solves the boot problem.
Thanks
Re: [PowerPC] [PASEMI] Issue with the identification of ATA drives after the of/irq updates 2024-05-29
On 03.07.24 12:41, Marc Zyngier wrote: On Wed, 03 Jul 2024 11:26:17 +0100, Christian Zigotzky wrote: On 3. Jul 2024, at 08:40, Marc Zyngier wrote: This isn't a DTS. This is a listing of all the nodes, not something I can use to feed the kernel. I explained how to generate it. Download the compiled device tree for the Nemo board: http://www.xenosoft.de/fdt-nemo-board.zip No, thank you. You know already the device tree: https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-November/236587.html Do you think I keep this sort of things from almost three years ago? I have better things to do. Now, either you provide the required information in the required form or you don't. Either you test the proposed patches or you don't. If you do, great, and I'll do my best to help you. If you don't, also great, because I can go back to the stuff I'm actually interested in (i.e. not your machine). This is your call, and only yours. M. OK, here is the dts file: https://github.com/chzigotzky/kernels/blob/main/dtb_src/X1000/nemo.dts Thanks for your help.
Re: [PowerPC] [PASEMI] Issue with the identification of ATA drives after the of/irq updates 2024-05-29
On 3. Jul 2024, at 08:40, Marc Zyngier wrote: This isn't a DTS. This is a listing of all the nodes, not something I can use to feed the kernel. I explained how to generate it. Download the compiled device tree for the Nemo board: http://www.xenosoft.de/fdt-nemo-board.zip No, thank you. You know already the device tree: https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-November/236587.html
Re: [PowerPC] [PASEMI] Issue with the identification of ATA drives after the of/irq updates 2024-05-29
Hello Marc,
On 02.07.24 18:54, Marc Zyngier wrote:
On Sun, 30 Jun 2024 11:21:55 +0100,
Christian Zigotzky wrote:
Hello,
There is an issue with the identification of ATA drives with our
P.A. Semi Nemo boards [1] after the
commit "of/irq: Factor out parsing of interrupt-map parent
phandle+args from of_irq_parse_raw()" [2].
[snip]
My earlier request for valuable debug information still stands. But
while you're at it, can you please give the following hack a go?
M.
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -282,8 +282,10 @@ int of_irq_parse_raw(const __be32 *addr, struct
of_phandle_args *out_irq)
oldimap = imap;
imap = of_irq_parse_imap_parent(oldimap, imaplen,
out_irq);
- if (!imap)
- goto fail;
+ if (!imap) {
+ match = 0;
+ break;
+ }
match &= of_device_is_available(out_irq->np);
if (match)
This may not be the final workaround even if it solves your boot
problem, but will at least give us a hint at what is going wrong.
I have the fuzzy feeling that we may be able to lob this broken system
as part of the of_irq_imap_abusers[] array, which would solve things
pretty "neatly".
M.
I saw that you may already have a solution. Do you still need the test
with this patch?
Cheers,
Christian
Re: [PowerPC] [PASEMI] Issue with the identification of ATA drives after the of/irq updates 2024-05-29
Hello Marc, On 02.07.24 21:49, Marc Zyngier wrote: On 2024-07-02 18:55, Christian Zigotzky wrote: Hello Marc, Thank you for your reply. On 02.07.24 17:19, Marc Zyngier wrote: Please provide the device tree for your platform. It isn't possible to debug this without it, no matter how many pictures you provide. If it doesn't exist in source form, you can dump it using: # dtc -I dtb /sys/firmware/fdt and posting the full output. Additionally, a full dmesg of both working and non working boots would be useful. Thanks, M. The device tree of the Nemo board and further information: https://forum.hyperion-entertainment.com/viewtopic.php?p=54406#p54406 Please post these things on the list. I have no interest in fishing things on a random forum, and this information is useful for everyone. Thanks, M. Sorry, here you are: Device tree of the Nemo board (Hardinfo): -Device Tree- Summary Maps / /sdc@fc00 /sdc@fc00/openpic@fc00 /sdc@fc00/mdio@0 /sdc@fc00/mdio@0/ethernet-phy@0 /sdc@fc00/rng@fc105000 /sdc@fc00/gizmo@fc104000 /sdc@fc00/gpio@fc103000 /pxp@0,e000 /pxp@0,e000/i2c@1c,2 /pxp@0,e000/serial@1d /pxp@0,e000/io-bridge@0 /pxp@0,e000/dma-engine@1a /pxp@0,e000/pci@11 /pxp@0,e000/pci@11/pci@13 /pxp@0,e000/pci@11/pci@13,3 /pxp@0,e000/pci@11/pci@13,1 /pxp@0,e000/pci@11/pci@14,4 /pxp@0,e000/pci@11/pci@14,4/pci@6 /pxp@0,e000/pci@11/pci@14,4/pci@6,1 /pxp@0,e000/pci@11/pci@14,4/pci@5 /pxp@0,e000/pci@11/pci@14,2 /pxp@0,e000/pci@11/pci@14 /pxp@0,e000/pci@11/pci@13,4 /pxp@0,e000/pci@11/pci@12 /pxp@0,e000/pci@11/pci@12/atapi0.1 /pxp@0,e000/pci@11/pci@12/ide0.0 /pxp@0,e000/pci@11/pci@13,2 /pxp@0,e000/pci@11/pci@14,3 /pxp@0,e000/pci@11/pci@14,1 /pxp@0,e000/pci@11/pci@13,5 /pxp@0,e000/pci@8 /pxp@0,e000/i2c@1c /pxp@0,e000/pci@11,2 /pxp@0,e000/pci@4 /pxp@0,e000/ethernet@14,3 /pxp@0,e000/pci@1b /pxp@0,e000/i2c@1c,1 /pxp@0,e000/pci@9 /pxp@0,e000/pci@11,3 /pxp@0,e000/pci@10 /pxp@0,e000/pci@10/pci@0,1 /pxp@0,e000/pci@10/pci@0 /pxp@0,e000/pci@11,1 /pxp@0,e000/cache-controller@1 /pxp@0,e000/pci@5 /pxp@0,e000/serial@1d,1 /pxp@0,e000/pci@1e /pxp@0,e000/pci@3 /pxp@0,e000/pci@15 /bootconsole /options /openprom /lpc@fe00 /chosen /cpus /cpus/PowerPC,PA6T@0 /cpus/PowerPC,PA6T@1 /memory /localbus@f000 /localbus@f000/cf@100 Messages lsprop /proc/device-tree: compatible "pasemi,nemo" "pasemi,pa6t-1682m" "PA6T-1682M" "pasemi,pwrficient" "pasemi" device_type "bootrom" model "pasemi,nemo" #interrupt-cells 0002 #address-cells 0002 #size-cells 0002 linux,phandle 7fdff018 (2145382424) platform-open-pic fc00 00041000 name "" /proc/device-tree/sdc@fc00: compatible "1682m-sdc" "pasemi,pwrficient-sdc" "pasemi,sdc" device_type "sdc" #address-cells 0001 #size-cells 0001 reg fc00 0080 linux,phandle 7fe2f458 (2145580120) name "sdc" /proc/device-tree/sdc@fc00/rng@fc105000: compatible "1682m-rng" "pasemi,pwrficient-rng" "pasemi,rng" device_type "rng" reg fc105000 1000 linux,phandle 7fe2fdd0 (2145582544) name "rng" /proc/device-tree/sdc@fc00/mdio@0: compatible "gpio-mdio" mdc-pin 0005 #address-cells 0001 #size-cells reg linux,phandle 7fe3d5a0 (2145637792) mdio-pin 0006 name "mdio" /proc/device-tree/sdc@fc00/mdio@0/ethernet-phy@0: interrupt-parent 7fe2f6e8 (2145580776) interrupts 0007 0001 reg linux,phandle 7fe3d860 (2145638496) name "ethernet-phy" /proc/device-tree/sdc@fc00/openpic@fc00: compatible "pasemi,pwrficient-openpic" "chrp,open-pic" device_type "open-pic" msi-available-ranges 0200 0200 #interrupt-cells 0002 #address-cells reg fc00 0010 linux,phandle 7fe2f6e8 (2145580776) name "openpic" interrupt-controller /proc/device-tree/sdc@fc00/gizmo@fc104000: compatible "1682m-gizmo" "pasemi,pwrficient-gizmo" "pasemi,gizmo" device_type "gizmo" reg fc104000 1000 linux,phandle 7fe2fbf0 (2145582064) name "gizmo" /proc/device-tree/sdc@fc00/gpio@fc103000: compatible "1682m-gpio" "pasemi,pwrfic
Re: [PowerPC] [PASEMI] Issue with the identification of ATA drives after the of/irq updates 2024-05-29
Hello Marc, Thank you for your reply. On 02.07.24 17:19, Marc Zyngier wrote: Christian, On Sun, 30 Jun 2024 11:21:55 +0100, Christian Zigotzky wrote: Hello, There is an issue with the identification of ATA drives with our P.A. Semi Nemo boards [1] after the commit "of/irq: Factor out parsing of interrupt-map parent phandle+args from of_irq_parse_raw()" [2]. Error messages: ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4) ata2.00: qc timeout after 1 mssecs (cmd 0xec) Screenshots [3] I bisected yesterday [4] and "of/irq: Factor out parsing of interrupt-map parent phandle+args from of_irq_parse_raw()" [2] is the first bad commit. Then I created a patch for reverting this first bad commit. I also reverted the changes in drivers/of/property.c. [5] The patched kernel boots with successful detection of the ATA devices. Please check the of/irq updates. It is hard to understand what is going on with so little information. Please provide the device tree for your platform. It isn't possible to debug this without it, no matter how many pictures you provide. If it doesn't exist in source form, you can dump it using: # dtc -I dtb /sys/firmware/fdt and posting the full output. Additionally, a full dmesg of both working and non working boots would be useful. Thanks, M. The device tree of the Nemo board and further information: https://forum.hyperion-entertainment.com/viewtopic.php?p=54406#p54406 Cheers, Christian
[PowerPC] [PASEMI] Issue with the identification of ATA drives after the of/irq updates 2024-05-29
Hello, There is an issue with the identification of ATA drives with our P.A. Semi Nemo boards [1] after the commit "of/irq: Factor out parsing of interrupt-map parent phandle+args from of_irq_parse_raw()" [2]. Error messages: ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4) ata2.00: qc timeout after 1 mssecs (cmd 0xec) Screenshots [3] I bisected yesterday [4] and "of/irq: Factor out parsing of interrupt-map parent phandle+args from of_irq_parse_raw()" [2] is the first bad commit. Then I created a patch for reverting this first bad commit. I also reverted the changes in drivers/of/property.c. [5] The patched kernel boots with successful detection of the ATA devices. Please check the of/irq updates. Thanks, Christian [1] https://en.wikipedia.org/wiki/AmigaOne_X1000 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.10-rc5&id=935df1bd40d43c4ee91838c42a20e9af751885cc [3] - https://i.ibb.co/WcH8g4K/20240626-095132.jpg - https://i.ibb.co/K7KnDxx/panic2.jpg - https://i.ibb.co/frnbJfb/panic3.jpg [4] https://forum.hyperion-entertainment.com/viewtopic.php?p=58585#p58585 [5] https://github.com/chzigotzky/kernels/blob/main/patches/X1000/of_irq_v2.patch
Re: Xorg doesn't start and some other issues with the RC1 of kernel 6.10
On 30.05.24 14:51, Michael Ellerman wrote: Christian Zigotzky writes: On 28.05.24 22:00, Christian Zigotzky wrote: Hi All, Xorg doesn't start anymore since the RC1 of kernel 6.10. We tested it with the VirtIO GPU and with some Radeon cards. Another error message: Failed to start Setup Virtual Console. Maybe this is the issue: + CONFIG_ARCH_HAS_KERNEL_FPU_SUPPORT=y Tested with FSL P5040, FSL P5020, and PASEMI boards. Could you please test Xorg on your PowerPC machines? Thanks, Christian I tested the RC1 in a virtual e5500 QEMU PowerPC machine with Bochs VGA (-device VGA,vgamem_mb=256) and Xorg doesn't start either. Error message: xf86OpenConsole: KDSETMODE KD_GRAPHICS failed Inappropriate ioctl for device. That is presumably because of this: https://lore.kernel.org/all/0da9785e-ba44-4718-9d08-4e96c1ba7...@kernel.org/ cheers Hello Michael, Many thanks for the hint! :-) I was able to revert this commit and Xorg works again. We tested it with a Radeon and a VirtIO-GPU. @Skateman I reduced the uImage. Please test it. Link: https://github.com/chzigotzky/kernels/releases/tag/v6.10.0-rc1-4 Have a nice weekend, Christian
Re: Xorg doesn't start and some other issues with the RC1 of kernel 6.10
On 28.05.24 22:00, Christian Zigotzky wrote: Hi All, Xorg doesn't start anymore since the RC1 of kernel 6.10. We tested it with the VirtIO GPU and with some Radeon cards. Another error message: Failed to start Setup Virtual Console. Maybe this is the issue: + CONFIG_ARCH_HAS_KERNEL_FPU_SUPPORT=y Tested with FSL P5040, FSL P5020, and PASEMI boards. Could you please test Xorg on your PowerPC machines? Thanks, Christian I tested the RC1 in a virtual e5500 QEMU PowerPC machine with Bochs VGA (-device VGA,vgamem_mb=256) and Xorg doesn't start either. Error message: xf86OpenConsole: KDSETMODE KD_GRAPHICS failed Inappropriate ioctl for device. Please test the RC1 with Xorg on your PowerPC machine. Thanks
Xorg doesn't start and some other issues with the RC1 of kernel 6.10
On 28.05.24 22:00, Christian Zigotzky wrote: Hi All, Xorg doesn't start anymore since the RC1 of kernel 6.10. We tested it with the VirtIO GPU and with some Radeon cards. Another error message: Failed to start Setup Virtual Console. Maybe this is the issue: + CONFIG_ARCH_HAS_KERNEL_FPU_SUPPORT=y Tested with FSL P5040, FSL P5020, and PASEMI boards. Could you please test Xorg on your PowerPC machines? Thanks, Christian Another issue: https://www.skateman.nl/wp-content/uploads/2024/05/Kernel6.10-RC1.jpg -- Christian
Xorg doesn't start and some other issues with the RC1 of kernel 6.10
Hi All, Xorg doesn't start anymore since the RC1 of kernel 6.10. We tested it with the VirtIO GPU and with some Radeon cards. Another error message: Failed to start Setup Virtual Console. Maybe this is the issue: + CONFIG_ARCH_HAS_KERNEL_FPU_SUPPORT=y Tested with FSL P5040, FSL P5020, and PASEMI boards. Could you please test Xorg on your PowerPC machines. Thanks, Christian
Re: [FSL P50x0] Kernel 6.9-rc1 compiling issue
Christophe Leroy writes:
Hi Christian, hi Hari,
Le 04/04/2024 à 19:44, Christian Zigotzky a écrit :
Shall we use CONFIG_CRASH_DUMP to get int crashing_cpu = -1;?
Further information:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2024-March/269985.html
<https://lists.ozlabs.org/pipermail/linuxppc-dev/2024-March/269985.html>
Looking at problematic commit 5c4233cc0920 ("powerpc/kdump: Split
KEXEC_CORE and CRASH_DUMP dependency"), my feeling is that the change
should be as follows.
Hari, can you confirm ?
diff --git a/arch/powerpc/platforms/85xx/smp.c
b/arch/powerpc/platforms/85xx/smp.c
index 40aa58206888..3209fc92ac19 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -362,7 +362,7 @@ struct smp_ops_t smp_85xx_ops = {
#endif
};
-#ifdef CONFIG_KEXEC_CORE
+#ifdef CONFIG_CRASH_DUMP
#ifdef CONFIG_PPC32
atomic_t kexec_down_cpus = ATOMIC_INIT(0);
@@ -465,7 +465,7 @@ static void mpc85xx_smp_machine_kexec(struct kimage
*image)
default_machine_kexec(image);
}
-#endif /* CONFIG_KEXEC_CORE */
+#endif /* CONFIG_CRASH_DUMP */
- - - -
On 8. Apr 2024, at 14:20, Michael Ellerman wrote:
That doesn't look right to me.
I think it needs something like below.
cheers
diff --git a/arch/powerpc/platforms/85xx/smp.c
b/arch/powerpc/platforms/85xx/smp.c
index 40aa58206888..276060c993a0 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -398,6 +398,7 @@ static void mpc85xx_smp_kexec_cpu_down(int crash_shutdown,
int secondary)
hard_irq_disable();
mpic_teardown_this_cpu(secondary);
+#ifdef CONFIG_CRASH_DUMP
if (cpu == crashing_cpu && cpu_thread_in_core(cpu) != 0) {
/*
* We enter the crash kernel on whatever cpu crashed,
@@ -406,9 +407,11 @@ static void mpc85xx_smp_kexec_cpu_down(int crash_shutdown,
int secondary)
*/
disable_threadbit = 1;
disable_cpu = cpu_first_thread_sibling(cpu);
-} else if (sibling != crashing_cpu &&
- cpu_thread_in_core(cpu) == 0 &&
- cpu_thread_in_core(sibling) != 0) {
+} else if (sibling == crashing_cpu)
+return;
+#endif
+if (cpu_thread_in_core(cpu) == 0 &&
+cpu_thread_in_core(sibling) != 0) {
disable_threadbit = 2;
disable_cpu = sibling;
}
- - - -
Any news? I still need a patch for compiling the kernel.
- - Christian
Re: [FSL P50x0] Kernel 6.9-rc1 compiling issue
Shall we use CONFIG_CRASH_DUMP to get int crashing_cpu = -1;? Further information: https://lists.ozlabs.org/pipermail/linuxppc-dev/2024-March/269985.html — Christian
[FSL P50x0] Kernel 6.9-rc1 compiling issue
Configured:
CONFIG_VMCORE_INFO=y
# CONFIG_CRASH_DUMP is not set
CONFIG_KEXEC_CORE=y
PowerPC updates 6.9-2:
-#ifdef CONFIG_VMCORE_INFO
+#ifdef CONFIG_CRASH_DUMP
/* This keeps a track of which one is the crashing cpu. */
int crashing_cpu = -1;
#endif
-
int crashing_cpu = -1; was used before.
I continue to use it with the following temporary patch:
--- a/arch/powerpc/platforms/85xx/smp.c 2024-03-25 06:14:02.201209476
+0100
+++ b/arch/powerpc/platforms/85xx/smp.c 2024-03-25 06:10:04.421425931
+0100
@@ -393,6 +393,7 @@ static void mpc85xx_smp_kexec_cpu_down(i
int disable_threadbit = 0;
long start = mftb();
long now;
+ int crashing_cpu = -1;
local_irq_disable();
hard_irq_disable();
-
-- Christian
On 25 March 2024 at 10:14 am, Christian Zigotzky wrote:
We have configured (kernel config):
# CONFIG_CRASH_DUMP is not set
CONFIG_KEXEC_CORE=y
Link:
https://github.com/chzigotzky/kernels/blob/main/configs/x5000_defconfig
Compiling error:
arch/powerpc/platforms/85xx/smp.c: In function
'mpc85xx_smp_kexec_cpu_down':
arch/powerpc/platforms/85xx/smp.c:401:13: error: 'crashing_cpu'
undeclared (first use in this function); did you mean 'crash_save_cpu'?
401 | if (cpu == crashing_cpu && cpu_thread_in_core(cpu) != 0) {
| ^~~~
| crash_save_cpu
arch/powerpc/platforms/85xx/smp.c:401:13: note: each undeclared
identifier is reported only once for each function it appears in
make[5]: *** [scripts/Makefile.build:244:
arch/powerpc/platforms/85xx/smp.o] Error 1
make[4]: *** [scripts/Makefile.build:485: arch/powerpc/platforms/85xx]
Error 2
make[3]: *** [scripts/Makefile.build:485: arch/powerpc/platforms] Error 2
make[2]: *** [scripts/Makefile.build:485: arch/powerpc] Error 2
-
PowerPC updates 6.9-2:
#ifdef CONFIG_KEXEC_CORE
-extern int crashing_cpu;
-
+#if defined(CONFIG_CRASH_DUMP)
...
+extern int crashing_cpu;
+#ifdef CONFIG_CRASH_DUMP
/* This keeps a track of which one is the crashing cpu. */
int crashing_cpu = -1;
#endif
-
-- Christian
On 25 March 2024 at 08:15 am, Christian Zigotzky wrote:
Thanks a lot for the hint.
Could you please add #include to
arch/powerpc/platforms/85xx/smp.c for the next PowerPC fixes?
Christian
On 25 March 2024 at 07:43 am, Christophe Leroy wrote:
Hi,
Le 25/03/2024 à 06:18, Christian Zigotzky a écrit :
I have created a patch:
--- a/arch/powerpc/platforms/85xx/smp.c 2024-03-25
06:14:02.201209476 +0100
+++ b/arch/powerpc/platforms/85xx/smp.c 2024-03-25
06:10:04.421425931 +0100
@@ -393,6 +393,7 @@ static void mpc85xx_smp_kexec_cpu_down(i
int disable_threadbit = 0;
long start = mftb();
long now;
+ int crashing_cpu = -1;
crashing_cpu is a global variable defined in
arch/powerpc/kernel/setup-common.c and declared in
arch/powerpc/include/asm/kexec.h
So you can't redefine crashing_cpu as a local stub.
All you need to do is to add #include just like
arch/powerpc/platforms/powernv/smp.c I guess.
Christophe
local_irq_disable();
hard_irq_disable();
---
-- Christian
On 25 March 2024 at 05:48 am, Christian Zigotzky wrote:
Hi All,
Compiling of the RC1 of kernel 6.9 doesn’t work anymore for our FSL
P5020/P5040 boards [1] since the PowerPC updates 6.9-2 [2].
Error messages:
arch/powerpc/platforms/85xx/smp.c: In function
'mpc85xx_smp_kexec_cpu_down':
arch/powerpc/platforms/85xx/smp.c:401:13: error: 'crashing_cpu'
undeclared (first use in this function); did you mean
'crash_save_cpu'?
401 | if (cpu == crashing_cpu && cpu_thread_in_core(cpu) != 0) {
| ^~~~
| crash_save_cpu
arch/powerpc/platforms/85xx/smp.c:401:13: note: each undeclared
identifier is reported only once for each function it appears in
make[5]: *** [scripts/Makefile.build:244:
arch/powerpc/platforms/85xx/smp.o] Error 1
make[4]: *** [scripts/Makefile.build:485:
arch/powerpc/platforms/85xx]
Error 2
make[3]: *** [scripts/Makefile.build:485: arch/powerpc/platforms]
Error 2
make[2]: *** [scripts/Makefile.build:485: arch/powerpc] Error 2
---
I was able to revert it. After that the compiling works again.
Could you please check the PowerPC updates 6.9-2? [2]
Thanks,
Christian
[1] http://wiki.amiga.org/index.php?title=X5000
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.9-rc1&id=484193fecd2b6349a6fd1554d306aec646ae1a6a
[FSL P50x0] Kernel 6.9-rc1 compiling issue
We have configured (kernel config):
# CONFIG_CRASH_DUMP is not set
CONFIG_KEXEC_CORE=y
Link:
https://github.com/chzigotzky/kernels/blob/main/configs/x5000_defconfig
Compiling error:
arch/powerpc/platforms/85xx/smp.c: In function 'mpc85xx_smp_kexec_cpu_down':
arch/powerpc/platforms/85xx/smp.c:401:13: error: 'crashing_cpu'
undeclared (first use in this function); did you mean 'crash_save_cpu'?
401 | if (cpu == crashing_cpu && cpu_thread_in_core(cpu) != 0) {
| ^~~~
| crash_save_cpu
arch/powerpc/platforms/85xx/smp.c:401:13: note: each undeclared
identifier is reported only once for each function it appears in
make[5]: *** [scripts/Makefile.build:244:
arch/powerpc/platforms/85xx/smp.o] Error 1
make[4]: *** [scripts/Makefile.build:485: arch/powerpc/platforms/85xx]
Error 2
make[3]: *** [scripts/Makefile.build:485: arch/powerpc/platforms] Error 2
make[2]: *** [scripts/Makefile.build:485: arch/powerpc] Error 2
-
PowerPC updates 6.9-2:
#ifdef CONFIG_KEXEC_CORE
-extern int crashing_cpu;
-
+#if defined(CONFIG_CRASH_DUMP)
...
+extern int crashing_cpu;
+#ifdef CONFIG_CRASH_DUMP
/* This keeps a track of which one is the crashing cpu. */
int crashing_cpu = -1;
#endif
-
-- Christian
On 25 March 2024 at 08:15 am, Christian Zigotzky wrote:
Thanks a lot for the hint.
Could you please add #include to
arch/powerpc/platforms/85xx/smp.c for the next PowerPC fixes?
Christian
On 25 March 2024 at 07:43 am, Christophe Leroy wrote:
Hi,
Le 25/03/2024 à 06:18, Christian Zigotzky a écrit :
I have created a patch:
--- a/arch/powerpc/platforms/85xx/smp.c 2024-03-25
06:14:02.201209476 +0100
+++ b/arch/powerpc/platforms/85xx/smp.c 2024-03-25
06:10:04.421425931 +0100
@@ -393,6 +393,7 @@ static void mpc85xx_smp_kexec_cpu_down(i
int disable_threadbit = 0;
long start = mftb();
long now;
+ int crashing_cpu = -1;
crashing_cpu is a global variable defined in
arch/powerpc/kernel/setup-common.c and declared in
arch/powerpc/include/asm/kexec.h
So you can't redefine crashing_cpu as a local stub.
All you need to do is to add #include just like
arch/powerpc/platforms/powernv/smp.c I guess.
Christophe
local_irq_disable();
hard_irq_disable();
---
-- Christian
On 25 March 2024 at 05:48 am, Christian Zigotzky wrote:
Hi All,
Compiling of the RC1 of kernel 6.9 doesn’t work anymore for our FSL
P5020/P5040 boards [1] since the PowerPC updates 6.9-2 [2].
Error messages:
arch/powerpc/platforms/85xx/smp.c: In function
'mpc85xx_smp_kexec_cpu_down':
arch/powerpc/platforms/85xx/smp.c:401:13: error: 'crashing_cpu'
undeclared (first use in this function); did you mean
'crash_save_cpu'?
401 | if (cpu == crashing_cpu && cpu_thread_in_core(cpu) != 0) {
| ^~~~
| crash_save_cpu
arch/powerpc/platforms/85xx/smp.c:401:13: note: each undeclared
identifier is reported only once for each function it appears in
make[5]: *** [scripts/Makefile.build:244:
arch/powerpc/platforms/85xx/smp.o] Error 1
make[4]: *** [scripts/Makefile.build:485: arch/powerpc/platforms/85xx]
Error 2
make[3]: *** [scripts/Makefile.build:485: arch/powerpc/platforms]
Error 2
make[2]: *** [scripts/Makefile.build:485: arch/powerpc] Error 2
---
I was able to revert it. After that the compiling works again.
Could you please check the PowerPC updates 6.9-2? [2]
Thanks,
Christian
[1] http://wiki.amiga.org/index.php?title=X5000
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.9-rc1&id=484193fecd2b6349a6fd1554d306aec646ae1a6a
[FSL P50x0] Kernel 6.9-rc1 compiling issue
Thanks a lot for the hint.
Could you please add #include to
arch/powerpc/platforms/85xx/smp.c for the next PowerPC fixes?
Christian
On 25 March 2024 at 07:43 am, Christophe Leroy wrote:
Hi,
Le 25/03/2024 à 06:18, Christian Zigotzky a écrit :
I have created a patch:
--- a/arch/powerpc/platforms/85xx/smp.c 2024-03-25 06:14:02.201209476 +0100
+++ b/arch/powerpc/platforms/85xx/smp.c 2024-03-25 06:10:04.421425931 +0100
@@ -393,6 +393,7 @@ static void mpc85xx_smp_kexec_cpu_down(i
int disable_threadbit = 0;
long start = mftb();
long now;
+ int crashing_cpu = -1;
crashing_cpu is a global variable defined in
arch/powerpc/kernel/setup-common.c and declared in
arch/powerpc/include/asm/kexec.h
So you can't redefine crashing_cpu as a local stub.
All you need to do is to add #include just like
arch/powerpc/platforms/powernv/smp.c I guess.
Christophe
local_irq_disable();
hard_irq_disable();
---
-- Christian
On 25 March 2024 at 05:48 am, Christian Zigotzky wrote:
Hi All,
Compiling of the RC1 of kernel 6.9 doesn’t work anymore for our FSL
P5020/P5040 boards [1] since the PowerPC updates 6.9-2 [2].
Error messages:
arch/powerpc/platforms/85xx/smp.c: In function
'mpc85xx_smp_kexec_cpu_down':
arch/powerpc/platforms/85xx/smp.c:401:13: error: 'crashing_cpu'
undeclared (first use in this function); did you mean 'crash_save_cpu'?
401 | if (cpu == crashing_cpu && cpu_thread_in_core(cpu) != 0) {
| ^~~~
| crash_save_cpu
arch/powerpc/platforms/85xx/smp.c:401:13: note: each undeclared
identifier is reported only once for each function it appears in
make[5]: *** [scripts/Makefile.build:244:
arch/powerpc/platforms/85xx/smp.o] Error 1
make[4]: *** [scripts/Makefile.build:485: arch/powerpc/platforms/85xx]
Error 2
make[3]: *** [scripts/Makefile.build:485: arch/powerpc/platforms] Error 2
make[2]: *** [scripts/Makefile.build:485: arch/powerpc] Error 2
---
I was able to revert it. After that the compiling works again.
Could you please check the PowerPC updates 6.9-2? [2]
Thanks,
Christian
[1] http://wiki.amiga.org/index.php?title=X5000
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.9-rc1&id=484193fecd2b6349a6fd1554d306aec646ae1a6a
[FSL P50x0] Kernel 6.9-rc1 compiling issue
I have created a patch:
--- a/arch/powerpc/platforms/85xx/smp.c 2024-03-25 06:14:02.201209476 +0100
+++ b/arch/powerpc/platforms/85xx/smp.c 2024-03-25 06:10:04.421425931 +0100
@@ -393,6 +393,7 @@ static void mpc85xx_smp_kexec_cpu_down(i
int disable_threadbit = 0;
long start = mftb();
long now;
+ int crashing_cpu = -1;
local_irq_disable();
hard_irq_disable();
---
-- Christian
On 25 March 2024 at 05:48 am, Christian Zigotzky wrote:
Hi All,
Compiling of the RC1 of kernel 6.9 doesn’t work anymore for our FSL
P5020/P5040 boards [1] since the PowerPC updates 6.9-2 [2].
Error messages:
arch/powerpc/platforms/85xx/smp.c: In function
'mpc85xx_smp_kexec_cpu_down':
arch/powerpc/platforms/85xx/smp.c:401:13: error: 'crashing_cpu'
undeclared (first use in this function); did you mean 'crash_save_cpu'?
401 | if (cpu == crashing_cpu && cpu_thread_in_core(cpu) != 0) {
| ^~~~
| crash_save_cpu
arch/powerpc/platforms/85xx/smp.c:401:13: note: each undeclared
identifier is reported only once for each function it appears in
make[5]: *** [scripts/Makefile.build:244:
arch/powerpc/platforms/85xx/smp.o] Error 1
make[4]: *** [scripts/Makefile.build:485: arch/powerpc/platforms/85xx]
Error 2
make[3]: *** [scripts/Makefile.build:485: arch/powerpc/platforms] Error 2
make[2]: *** [scripts/Makefile.build:485: arch/powerpc] Error 2
---
I was able to revert it. After that the compiling works again.
Could you please check the PowerPC updates 6.9-2? [2]
Thanks,
Christian
[1] http://wiki.amiga.org/index.php?title=X5000
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.9-rc1&id=484193fecd2b6349a6fd1554d306aec646ae1a6a
[FSL P50x0] Kernel 6.9-rc1 compiling issue
Hi All,
The Compiling of the RC1 of kernel 6.9 doesn’t work anymore for our FSL
P5020/P5040 boards [1] since the PowerPC updates 6.9-2 [2].
Error messages:
arch/powerpc/platforms/85xx/smp.c: In function 'mpc85xx_smp_kexec_cpu_down':
arch/powerpc/platforms/85xx/smp.c:401:13: error: 'crashing_cpu'
undeclared (first use in this function); did you mean 'crash_save_cpu'?
401 | if (cpu == crashing_cpu && cpu_thread_in_core(cpu) != 0) {
| ^~~~
| crash_save_cpu
arch/powerpc/platforms/85xx/smp.c:401:13: note: each undeclared
identifier is reported only once for each function it appears in
make[5]: *** [scripts/Makefile.build:244:
arch/powerpc/platforms/85xx/smp.o] Error 1
make[4]: *** [scripts/Makefile.build:485: arch/powerpc/platforms/85xx]
Error 2
make[3]: *** [scripts/Makefile.build:485: arch/powerpc/platforms] Error 2
make[2]: *** [scripts/Makefile.build:485: arch/powerpc] Error 2
---
I was able to revert it. After that the compiling works again.
Could you please check the PowerPC updates 6.9-2? [2]
Thanks,
Christian
[1] http://wiki.amiga.org/index.php?title=X5000
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.9-rc1&id=484193fecd2b6349a6fd1554d306aec646ae1a6a
Re: Fbdev issue after the drm updates 'drm-next-2023-10-31-1'
On 13 November 2023 at 01:48 pm, Geert Uytterhoeven wrote:
Thanks for your report!
I can confirm there is no graphics output with m68k/virt, and
bisected this to my own commit 6ae2ff23aa43a0c4 ("drm/client: Convert
drm_client_buffer_addfb() to drm_mode_addfb2()"), ouch...
It turns out the old call to drm_mode_addfb() caused a translation
from a fourcc to a bpp/depth pair to a _different_ fourcc, due to the
quirk processing in drm_driver_legacy_fb_format().
I.e. on m68k/virt, the original requested format was XR24, which was
translated to BX24. The former doesn't work, the latter works.
The following (gmail-whitespace-damaged) patch fixed the issue for me:
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -400,6 +400,16 @@ static int drm_client_buffer_addfb(struct
drm_client_buffer *buffer,
fb_req.width = width;
fb_req.height = height;
+ if (client->dev->mode_config.quirk_addfb_prefer_host_byte_order) {
+ if (format == DRM_FORMAT_XRGB)
+ format = DRM_FORMAT_HOST_XRGB;
+ if (format == DRM_FORMAT_ARGB)
+ format = DRM_FORMAT_HOST_ARGB;
+ if (format == DRM_FORMAT_RGB565)
+ format = DRM_FORMAT_HOST_RGB565;
+ if (format == DRM_FORMAT_XRGB1555)
+ format = DRM_FORMAT_HOST_XRGB1555;
+ }
fb_req.pixel_format = format;
fb_req.handles[0] = handle;
fb_req.pitches[0] = buffer->pitch;
However, I don't think we want to sprinkle more of these
translations around... So perhaps we should (re)add a call to
drm_driver_legacy_fb_format() to drm_client_buffer_addfb()?
Second, as I doubt you are using a big-endian system, you are probably
running into a slightly different issue.
Oh wait, you did CC linuxppc-dev, so perhaps you are running on a
big-endian machine?
If not, please add
pr_info("%s: format = %p4cc\n", __func__, &format);
to drivers/gpu/drm/drm_client.c:drm_client_buffer_addfb(), and,
after reverting commit 6ae2ff23aa43a0c4, add
pr_info("%s: bpp %u/depth %u => r.pixel_format = %p4cc\n",
__func__, or->bpp, or->depth, &r.pixel_format);
to drivers/gpu/drm/drm_framebuffer.c:drm_mode_addfb(), so we know the
translation in your case?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 --ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Geert,
Your patch works! :-) Thanks a lot!
I tested it with the virtio-vga and with the virtio-gpu-pci device in a
virtual ppce500 QEMU/KVM HV machine with an e5500 CPU today.
Tested-by: Christian Zigotzky
Cheers,
Christian
Re: Fbdev issue after the drm updates 'drm-next-2023-10-31-1'
On 13 November 2023 at 01:48 pm, Geert Uytterhoeven wrote:
Hi Christian,
On Sun, Nov 12, 2023 at 3:23 PM Christian Zigotzky
wrote:
On 07 November 2023 at 09:36 am, Christian Zigotzky wrote:
I have found out that fbdev no longer works with virtio-gpu-pci and
virtio-vga. It is not a problem with the penguin logos.
Could you please check fbdev in QEMU virtual machines with
virtio-gpu-pci and virtio-vga graphics?
On 02 November 2023 at 03:45 pm, Christian Zigotzky wrote:
There is a fbdev issue with the virtio-gpu-pci and virtio-vga. (The
penguins are not displayed at boot time)
Error message: [0.889302] virtio-pci :00:02.0: [drm] *ERROR*
fbdev: Failed to setup generic emulation (ret=-2)
The kernel 6.6 final doesn't have this issue.
Please check the fbdev changes in the drm updates
'drm-next-2023-10-31-1'.
Thanks for your report!
I can confirm there is no graphics output with m68k/virt, and
bisected this to my own commit 6ae2ff23aa43a0c4 ("drm/client: Convert
drm_client_buffer_addfb() to drm_mode_addfb2()"), ouch...
It turns out the old call to drm_mode_addfb() caused a translation
from a fourcc to a bpp/depth pair to a _different_ fourcc, due to the
quirk processing in drm_driver_legacy_fb_format().
I.e. on m68k/virt, the original requested format was XR24, which was
translated to BX24. The former doesn't work, the latter works.
The following (gmail-whitespace-damaged) patch fixed the issue for me:
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -400,6 +400,16 @@ static int drm_client_buffer_addfb(struct
drm_client_buffer *buffer,
fb_req.width = width;
fb_req.height = height;
+ if (client->dev->mode_config.quirk_addfb_prefer_host_byte_order) {
+ if (format == DRM_FORMAT_XRGB)
+ format = DRM_FORMAT_HOST_XRGB;
+ if (format == DRM_FORMAT_ARGB)
+ format = DRM_FORMAT_HOST_ARGB;
+ if (format == DRM_FORMAT_RGB565)
+ format = DRM_FORMAT_HOST_RGB565;
+ if (format == DRM_FORMAT_XRGB1555)
+ format = DRM_FORMAT_HOST_XRGB1555;
+ }
fb_req.pixel_format = format;
fb_req.handles[0] = handle;
fb_req.pitches[0] = buffer->pitch;
However, I don't think we want to sprinkle more of these
translations around... So perhaps we should (re)add a call to
drm_driver_legacy_fb_format() to drm_client_buffer_addfb()?
Second, as I doubt you are using a big-endian system, you are probably
running into a slightly different issue.
Oh wait, you did CC linuxppc-dev, so perhaps you are running on a
big-endian machine?
If not, please add
pr_info("%s: format = %p4cc\n", __func__, &format);
to drivers/gpu/drm/drm_client.c:drm_client_buffer_addfb(), and,
after reverting commit 6ae2ff23aa43a0c4, add
pr_info("%s: bpp %u/depth %u => r.pixel_format = %p4cc\n",
__func__, or->bpp, or->depth, &r.pixel_format);
to drivers/gpu/drm/drm_framebuffer.c:drm_mode_addfb(), so we know the
translation in your case?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi Geert,
Thanks for your answer! I use a big-endian system.
Cheers,
Christian
Re: Fbdev issue after the drm updates 'drm-next-2023-10-31-1'
+ Helge Deller + Gerd Knorr + Geert Uytterhoeven On 07 November 2023 at 09:36 am, Christian Zigotzky wrote: Hello, I have found out that fbdev no longer works with virtio-gpu-pci and virtio-vga. It is not a problem with the penguin logos. Could you please check fbdev in QEMU virtual machines with virtio-gpu-pci and virtio-vga graphics? Many thanks in advance, Christian On 02 November 2023 at 03:45 pm, Christian Zigotzky wrote: Hello, There is a fbdev issue with the virtio-gpu-pci and virtio-vga. (The penguins are not displayed at boot time) Error message: [ 0.889302] virtio-pci :00:02.0: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-2) The kernel 6.6 final doesn't have this issue. Please check the fbdev changes in the drm updates 'drm-next-2023-10-31-1'. Thanks, Christian
Re: Fbdev issue after the drm updates 'drm-next-2023-10-31-1'
Hello, I have found out that fbdev no longer works with virtio-gpu-pci and virtio-vga. It is not a problem with the penguin logos. Could you please check fbdev in QEMU virtual machines with virtio-gpu-pci and virtio-vga graphics? Many thanks in advance, Christian On 02 November 2023 at 03:45 pm, Christian Zigotzky wrote: Hello, There is a fbdev issue with the virtio-gpu-pci and virtio-vga. (The penguins are not displayed at boot time) Error message: [ 0.889302] virtio-pci :00:02.0: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-2) The kernel 6.6 final doesn't have this issue. Please check the fbdev changes in the drm updates 'drm-next-2023-10-31-1'. Thanks, Christian
Fbdev issue after the drm updates 'drm-next-2023-10-31-1'
Hello, There is a fbdev issue with the virtio-gpu-pci and virtio-vga. (The penguins are not displayed at boot time) Error message: [ 0.889302] virtio-pci :00:02.0: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-2) The kernel 6.6 final doesn't have this issue. Please check the fbdev changes in the drm updates 'drm-next-2023-10-31-1'. Thanks, Christian
Re: [PATCH] powerpc: isa-bridge: Fix ISA mmapping when "ranges" is not present
On 03.07.23 07:21, Michael Ellerman wrote:
On Fri, 05 May 2023 12:18:17 -0500, Rob Herring wrote:
Commit e4ab08be5b49 ("powerpc/isa-bridge: Remove open coded "ranges"
parsing") broke PASemi Nemo board booting. The issue is the ISA I/O
range was not getting mapped as the logic to handle no "ranges" was
inverted. If phb_io_base_phys is non-zero, then the ISA range defaults
to the first 64K of the PCI I/O space. phb_io_base_phys should only be 0
when looking for a non-PCI ISA region.
[...]
Applied to powerpc/fixes.
[1/1] powerpc: isa-bridge: Fix ISA mmapping when "ranges" is not present
https://git.kernel.org/powerpc/c/79de36042eecb684e0f748d17ba52f365fde0d65
cheers
Hello Michael,
This patch has already been applied. Link:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4927cb98f0eeaa5dbeac882e8372f4b16dc62624
Thanks,
Christian
Re: [FSL P50x0] [PASEMI] The Access to partitions on disks with an Amiga partition table doesn't work anymore after the block updates 2023-06-23
Hello Adrian, On 29 June 2023 at 12:17 pm, John Paul Adrian Glaubitz wrote: What version of AmigaOS is that? AmigaOS 4.1 Maybe the RDB is corrupted? Did you try on a freshly created RDB? Good idea! I recreated the RDB with the Media Toolbox on the sb600sata.device, 0. (AmigaOne X1000) Unfortunately, it doesn't solve the issue. That can be done with just "git revert ". I know but I prefer my own patch because sometimes I can't revert the commit anymore because of dependencies. Thanks, Christian
[FSL P50x0] [PASEMI] The Access to partitions on disks with an Amiga partition table doesn't work anymore after the block updates 2023-06-23
Hello,
The access to partitions on disks with an Amiga partition table (via
the Rigid Disk Block RDB) doesn't work anymore on my Cyrus+ board with a
FSL P50x0 PowerPC SoC [1] and on my P.A. Semi Nemo board [2] after the
block updates 2023-06-23 [3].
parted -l
Model: ATA ST2000DM001-9YN1 (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: amiga
Disk Flags:
Number Start End Size File system Name Flags
1 1057kB 123MB 122MB affs7 BDH0 hidden
2 123MB 2274MB 2150MB DH0 boot
3 2274MB 691GB 689GB DH2
4 691GB 1992GB 1301GB ext4 dhx boot
dmesg | grep -i sda
[ 4.208905] sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks:
(2.00 TB/1.82 TiB)
[ 4.253995] sd 0:0:0:0: [sda] 4096-byte physical blocks
[ 4.254826] sd 0:0:0:0: [sda] Write Protect is off
[ 4.300069] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 4.486476] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[ 4.580507] sd 0:0:0:0: [sda] Preferred minimum I/O size 4096 bytes
[ 4.712624] Dev sda: unable to read partition block 4294967295
[ 4.761532] sda: RDSK (512) sda1 (DOS^G)(res 2 spb 2) sda2
(SFS^B)(res 2 spb 1) sda3 (SFS^B)(res 2 spb 2) sda4 ((res 2 spb 1)
unable to read partition table
[ 4.761892] sda: partition table beyond EOD,
[ 4.861681] Dev sda: unable to read partition block 4294967295
[ 4.912094] sda: RDSK (512) sda1 (DOS^G)(res 2 spb 2) sda2
(SFS^B)(res 2 spb 1) sda3 (SFS^B)(res 2 spb 2) sda4 ((res 2 spb 1)
unable to read partition table
[ 4.963387] sda: partition table beyond EOD,
[ 5.014769] sd 0:0:0:0: [sda] Attached SCSI disk
I created a patch for reverting the commit. [4]
The access works again with this patch:
[ 0.00] Kernel command line: root=/dev/sda4
[ 3.987717] sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks:
(2.00 TB/1.82 TiB)
[ 4.031349] sd 0:0:0:0: [sda] 4096-byte physical blocks
[ 4.123773] sd 0:0:0:0: [sda] Write Protect is off
[ 4.168682] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 4.279304] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[ 4.463508] sd 0:0:0:0: [sda] Preferred minimum I/O size 4096 bytes
[ 4.519477] sda: RDSK (512) sda1 (DOS^G)(res 2 spb 2) sda2
(SFS^B)(res 2 spb 1) sda3 (SFS^B)(res 2 spb 2) sda4 ((res 2 spb 1)
[ 4.720896] sda: p4 size 18446744071956107760 extends beyond EOD,
[ 4.922550] sda: RDSK (512) sda1 (DOS^G)(res 2 spb 2) sda2
(SFS^B)(res 2 spb 1) sda3 (SFS^B)(res 2 spb 2) sda4 ((res 2 spb 1)
[ 4.948655] sda: p4 size 18446744071956107760 extends beyond EOD,
truncated
[ 4.998956] sd 0:0:0:0: [sda] Attached SCSI disk
[ 8.394695] EXT4-fs (sda4): mounted filesystem
93cb7dd2-ce1b-4bf5-ba47-818cf8e8c9f4 ro with ordered data mode. Quota
mode: none.
[ 18.578020] EXT4-fs (sda4): re-mounted
93cb7dd2-ce1b-4bf5-ba47-818cf8e8c9f4 ro. Quota mode: none.
[ 23.159524] EXT4-fs (sda4): re-mounted
93cb7dd2-ce1b-4bf5-ba47-818cf8e8c9f4 r/w. Quota mode: none.
Could you please check your commit?
Thanks,
Christian
[1] http://wiki.amiga.org/index.php?title=X5000
[2] https://en.wikipedia.org/wiki/AmigaOne_X1000
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a0433f8cae3ac51f59b4b1863032822aaa2d8164
[4] revert_amiga.c.patch:
--- a/block/partitions/amiga.c 2023-06-29 04:29:22.947100347 +0200
+++ b/block/partitions/amiga.c 2023-06-26 01:29:58.0 +0200
@@ -11,18 +11,10 @@
#define pr_fmt(fmt) fmt
#include
-#include
-#include
#include
#include "check.h"
-/* magic offsets in partition DosEnvVec */
-#define NR_HD 3
-#define NR_SECT 5
-#define LO_CYL 9
-#define HI_CYL 10
-
static __inline__ u32
checksum_block(__be32 *m, int size)
{
@@ -39,12 +31,8 @@ int amiga_partition(struct parsed_partit
unsigned char *data;
struct RigidDiskBlock *rdb;
struct PartitionBlock *pb;
- u64 start_sect, nr_sects;
- sector_t blk, end_sect;
- u32 cylblk; /* rdb_CylBlocks = nr_heads*sect_per_track */
- u32 nr_hd, nr_sect, lo_cyl, hi_cyl;
- int part, res = 0;
- unsigned int blksize = 1; /* Multiplier for disk block size */
+ int start_sect, nr_sects, blk, part, res = 0;
+ int blksize = 1; /* Multiplier for disk block size */
int slot = 1;
for (blk = 0; ; blk++, put_dev_sector(sect)) {
@@ -52,7 +40,7 @@ int amiga_partition(struct parsed_partit
goto rdb_done;
data = read_part_sector(state, blk, §);
if (!data) {
- pr_err("Dev %s: unable to read RDB block %llu\n",
+ pr_err("Dev %s: unable to read RDB block %d\n",
state->disk->disk_name, blk);
res = -1;
goto rdb_done;
@@ -69,12 +57,12 @@ int amiga_partition(struct parsed_partit
*(__be32 *)(data+0xdc) = 0;
if (checksum_block((__be3
Re: [PATCH] powerpc: isa-bridge: Fix ISA mmapping when "ranges" is not present
On 05 May 2023 at 07:18 pm, Rob Herring wrote:
Commit e4ab08be5b49 ("powerpc/isa-bridge: Remove open coded "ranges"
parsing") broke PASemi Nemo board booting. The issue is the ISA I/O
range was not getting mapped as the logic to handle no "ranges" was
inverted. If phb_io_base_phys is non-zero, then the ISA range defaults
to the first 64K of the PCI I/O space. phb_io_base_phys should only be 0
when looking for a non-PCI ISA region.
Fixes: e4ab08be5b49 ("powerpc/isa-bridge: Remove open coded "ranges" parsing")
Link:
https://lore.kernel.org/all/301595ad-0edf-2113-b55f-f5b8051ed...@xenosoft.de/
Reported-by: Christian Zigotzky
Signed-off-by: Rob Herring
---
Untested, but I think this should fix the issue.
arch/powerpc/kernel/isa-bridge.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/isa-bridge.c b/arch/powerpc/kernel/isa-bridge.c
index 85bdd7d3652f..48e0eaf1ad61 100644
--- a/arch/powerpc/kernel/isa-bridge.c
+++ b/arch/powerpc/kernel/isa-bridge.c
@@ -93,11 +93,12 @@ static int process_ISA_OF_ranges(struct device_node
*isa_node,
}
inval_range:
- if (!phb_io_base_phys) {
+ if (phb_io_base_phys) {
pr_err("no ISA IO ranges or unexpected isa range, mapping
64k\n");
remap_isa_base(phb_io_base_phys, 0x1);
+ return 0;
}
- return 0;
+ return -EINVAL;
}
The Nemo board boots with this patch. Thanks a lot for your help!
Tested-by: Christian Zigotzky
Re: [PASEMI NEMO] Boot issue with the PowerPC updates 6.4-1
On 03 May 2023 at 08:15 pm, Rob Herring wrote:
On Wed, May 3, 2023 at 12:40 PM Christian Zigotzky
wrote:
On 3. May 2023, at 18:51, Rob Herring wrote:
On Wed, May 3, 2023 at 11:27 AM Christophe Leroy
wrote:
+Rob as he's the commit's Author.
Le 03/05/2023 à 17:46, Christian Zigotzky a écrit :
On 02 May 2023 at 11:28 am, Michael Ellerman wrote:
Christian Zigotzky writes:
Hello,
Our PASEMI Nemo board [1] doesn't boot with the PowerPC updates 6.4-1
[2].
The kernel hangs right after the booting Linux via __start() @
0x ...
I was able to revert the PowerPC updates 6.4-1 [2] with the following
command: git revert 70cc1b5307e8ee3076fdf2ecbeb89eb973aa0ff7 -m 1
After a re-compiling, the kernel boots without any problems without the
PowerPC updates 6.4-1 [2].
Could you please explain me, what you have done in the boot area?
There's a few possibilities, but nothing obvious.
To begin with can you please test the following commits?
77e69ee7ce07
e4ab08be5b49
eeac8ede1755
cheers
git revert e4ab08be5b4902e5b350b0e1e1a3c25eb21d76d4
[master 0086e2cbbec0] Revert "powerpc/isa-bridge: Remove open coded
"ranges" parsing"
1 file changed, 129 insertions(+), 37 deletions(-)
After a recompiling it boots without any problems.
e4ab08be5b49 -- powerpc/isa-bridge: Remove open coded "ranges" parsing
is the bad commit.
Could I get a DT file for this board?
In the meantime, just revert this commit. I don't think I'll be able
to fix it before I'm out on sabbatical.
Rob
FYI:
Darren Stevens wrote:
The dtb passed by the CFE firmware has a number of issues, which up till
now have been fixed by use of patches applied to the mainline kernel.
This occasionally causes problems with changes made to mainline.
Changing the firmware is not the only way to modify the DT. Perhaps a
DT overlay would work better than carrying patches if the patches
aren't upstreamable. It kind of depends on how early you'd need to
apply the overlay and whether you'd need external phandles (aka
__symbols__ node, which the base DTB wouldn't support).
Looking at the DT, I think this change might fix it. Can you test this change:
diff --git a/drivers/of/address.c b/drivers/of/address.c
index e692809ff822..475b74413fdd 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -284,7 +284,7 @@ EXPORT_SYMBOL(of_range_to_resource);
static int of_bus_isa_match(struct device_node *np)
{
- return of_node_name_eq(np, "isa");
+ return of_node_is_type(np, "isa") || of_node_name_eq(np, "isa");
}
static void of_bus_isa_count_cells(struct device_node *child,
I tested this patch today but unfortunately the Nemo board doesn't boot.
- Christian
Re: [PASEMI NEMO] Boot issue with the PowerPC updates 6.4-1
> On 3. May 2023, at 19:28, Christian Zigotzky wrote: > > > >>> On 3. May 2023, at 18:51, Rob Herring wrote: >>> >>> On Wed, May 3, 2023 at 11:27 AM Christophe Leroy >>> wrote: >>> >>> +Rob as he's the commit's Author. >>> >>>> Le 03/05/2023 à 17:46, Christian Zigotzky a écrit : >>>> On 02 May 2023 at 11:28 am, Michael Ellerman wrote: >>>>> Christian Zigotzky writes: >>>>>> Hello, >>>>>> >>>>>> Our PASEMI Nemo board [1] doesn't boot with the PowerPC updates 6.4-1 >>>>>> [2]. >>>>>> >>>>>> The kernel hangs right after the booting Linux via __start() @ >>>>>> 0x ... >>>>>> >>>>>> I was able to revert the PowerPC updates 6.4-1 [2] with the following >>>>>> command: git revert 70cc1b5307e8ee3076fdf2ecbeb89eb973aa0ff7 -m 1 >>>>>> >>>>>> After a re-compiling, the kernel boots without any problems without the >>>>>> PowerPC updates 6.4-1 [2]. >>>>>> >>>>>> Could you please explain me, what you have done in the boot area? >>>>> There's a few possibilities, but nothing obvious. >>>>> >>>>> To begin with can you please test the following commits? >>>>> >>>>> 77e69ee7ce07 >>>>> e4ab08be5b49 >>>>> eeac8ede1755 >>>>> >>>>> cheers >>>> git revert e4ab08be5b4902e5b350b0e1e1a3c25eb21d76d4 >>>> >>>> [master 0086e2cbbec0] Revert "powerpc/isa-bridge: Remove open coded >>>> "ranges" parsing" >>>> 1 file changed, 129 insertions(+), 37 deletions(-) >>>> >>>> After a recompiling it boots without any problems. >>>> >>>> e4ab08be5b49 -- powerpc/isa-bridge: Remove open coded "ranges" parsing >>>> is the bad commit. >> >> Could I get a DT file for this board? >> >> In the meantime, just revert this commit. I don't think I'll be able >> to fix it before I'm out on sabbatical. >> >> Rob > > FYI: > > Darren Stevens wrote: > > The dtb passed by the CFE firmware has a number of issues, which up till > now have been fixed by use of patches applied to the mainline kernel. > This occasionally causes problems with changes made to mainline. > > Patching the firmware to correct the dtb is not an option for the > following reasons: > > It was modified by a 3rd party, and we don't have a copy of the source. > > All versions of CFE used on the X1000 export the same dtb. > > At least one machine suffered damage during a firmware upgrade attempt, > many people will be unwilling to reflash their system if an upgrade is > produced. > > Nemo’s DT: https://forum.hyperion-entertainment.com/viewtopic.php?p=54406#p54406
Re: [PASEMI NEMO] Boot issue with the PowerPC updates 6.4-1
> On 3. May 2023, at 18:51, Rob Herring wrote: > > On Wed, May 3, 2023 at 11:27 AM Christophe Leroy > wrote: >> >> +Rob as he's the commit's Author. >> >>> Le 03/05/2023 à 17:46, Christian Zigotzky a écrit : >>> On 02 May 2023 at 11:28 am, Michael Ellerman wrote: >>>> Christian Zigotzky writes: >>>>> Hello, >>>>> >>>>> Our PASEMI Nemo board [1] doesn't boot with the PowerPC updates 6.4-1 >>>>> [2]. >>>>> >>>>> The kernel hangs right after the booting Linux via __start() @ >>>>> 0x ... >>>>> >>>>> I was able to revert the PowerPC updates 6.4-1 [2] with the following >>>>> command: git revert 70cc1b5307e8ee3076fdf2ecbeb89eb973aa0ff7 -m 1 >>>>> >>>>> After a re-compiling, the kernel boots without any problems without the >>>>> PowerPC updates 6.4-1 [2]. >>>>> >>>>> Could you please explain me, what you have done in the boot area? >>>> There's a few possibilities, but nothing obvious. >>>> >>>> To begin with can you please test the following commits? >>>> >>>> 77e69ee7ce07 >>>> e4ab08be5b49 >>>> eeac8ede1755 >>>> >>>> cheers >>> git revert e4ab08be5b4902e5b350b0e1e1a3c25eb21d76d4 >>> >>> [master 0086e2cbbec0] Revert "powerpc/isa-bridge: Remove open coded >>> "ranges" parsing" >>> 1 file changed, 129 insertions(+), 37 deletions(-) >>> >>> After a recompiling it boots without any problems. >>> >>> e4ab08be5b49 -- powerpc/isa-bridge: Remove open coded "ranges" parsing >>> is the bad commit. > > Could I get a DT file for this board? > > In the meantime, just revert this commit. I don't think I'll be able > to fix it before I'm out on sabbatical. > > Rob FYI: Darren Stevens wrote: The dtb passed by the CFE firmware has a number of issues, which up till now have been fixed by use of patches applied to the mainline kernel. This occasionally causes problems with changes made to mainline. Patching the firmware to correct the dtb is not an option for the following reasons: It was modified by a 3rd party, and we don't have a copy of the source. All versions of CFE used on the X1000 export the same dtb. At least one machine suffered damage during a firmware upgrade attempt, many people will be unwilling to reflash their system if an upgrade is produced.
Re: [PASEMI NEMO] Boot issue with the PowerPC updates 6.4-1
On 02 May 2023 at 11:28 am, Michael Ellerman wrote: Christian Zigotzky writes: Hello, Our PASEMI Nemo board [1] doesn't boot with the PowerPC updates 6.4-1 [2]. The kernel hangs right after the booting Linux via __start() @ 0x ... I was able to revert the PowerPC updates 6.4-1 [2] with the following command: git revert 70cc1b5307e8ee3076fdf2ecbeb89eb973aa0ff7 -m 1 After a re-compiling, the kernel boots without any problems without the PowerPC updates 6.4-1 [2]. Could you please explain me, what you have done in the boot area? There's a few possibilities, but nothing obvious. To begin with can you please test the following commits? 77e69ee7ce07 e4ab08be5b49 eeac8ede1755 cheers git revert e4ab08be5b4902e5b350b0e1e1a3c25eb21d76d4 [master 0086e2cbbec0] Revert "powerpc/isa-bridge: Remove open coded "ranges" parsing" 1 file changed, 129 insertions(+), 37 deletions(-) After a recompiling it boots without any problems. e4ab08be5b49 -- powerpc/isa-bridge: Remove open coded "ranges" parsing is the bad commit. Thanks
Re: [PASEMI] Nemo board doesn't reboot anymore after the commit "HID: usbhid: Add ALWAYS_POLL quirk for some mice"
On 06 January 2023 at 03:41 pm, Jiri Kosina wrote: On Fri, 6 Jan 2023, Christian Zigotzky wrote: Hello, The reboot issue is still present in the RC2 of kernel 6.2. We still need the usbhid.patch. [1] Please check the bad commit. [2] Ankit, have you tested with all the devices that you added the quirk for in your original patch? Unless I hear otherwise, I will just drop the quirk for USB_DEVICE_ID_CHERRY_MOUSE_000C before this gets clarified. Thanks, The issue also affects the RC4. -- Christian
[PASEMI] Nemo board doesn't reboot anymore after the commit "HID: usbhid: Add ALWAYS_POLL quirk for some mice"
Hello,
The reboot issue is still present in the RC2 of kernel 6.2. We still
need the usbhid.patch. [1]
Please check the bad commit. [2]
Thanks,
Christian
[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=56303#p56303
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.1&id=f6d910a89a2391e5ce1f275d205023880a33d3f8
On 22 December 2022 at 11:42 am, Christian Zigotzky wrote:
Hello,
The Nemo board [1] doesn't reboot anymore since the final kernel 6.1.
The reboot works with the RC8 of kernel 6.1.
Actually, a reboot works but the CFE firmware is not loaded. Maybe
there is still something in the memory after the reboot.
I bisected today. [2]
The commit "HID: usbhid: Add ALWAYS_POLL quirk for some mice". [3] is
the problem.
I was able to revert this commit and the reboot works without any
problems again.
I created a patch for reverting the bad commit. [4]
Then I compiled the kernel with this patch. After that, the X1000
reboots without any problems.
I use a Cherry USB mouse. [5]
Please check the bad commit.
Thanks,
Christian
[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2] https://forum.hyperion-entertainment.com/viewtopic.php?p=56303#p56303
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.1&id=f6d910a89a2391e5ce1f275d205023880a33d3f8
[4] usbhid.patch:
diff -rupN a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
--- a/drivers/hid/hid-ids.h 2022-12-22 10:24:06.842881276 +0100
+++ b/drivers/hid/hid-ids.h 2022-12-22 10:23:35.903328869 +0100
@@ -274,7 +274,6 @@
#define USB_DEVICE_ID_CH_AXIS_295 0x001c
#define USB_VENDOR_ID_CHERRY 0x046a
-#define USB_DEVICE_ID_CHERRY_MOUSE_000C 0x000c
#define USB_DEVICE_ID_CHERRY_CYMOTION 0x0023
#define USB_DEVICE_ID_CHERRY_CYMOTION_SOLAR 0x0027
@@ -919,7 +918,6 @@
#define USB_DEVICE_ID_MS_XBOX_ONE_S_CONTROLLER 0x02fd
#define USB_DEVICE_ID_MS_PIXART_MOUSE 0x00cb
#define USB_DEVICE_ID_8BITDO_SN30_PRO_PLUS 0x02e0
-#define USB_DEVICE_ID_MS_MOUSE_0783 0x0783
#define USB_VENDOR_ID_MOJO 0x8282
#define USB_DEVICE_ID_RETRO_ADAPTER 0x3201
@@ -1388,7 +1386,6 @@
#define USB_VENDOR_ID_PRIMAX 0x0461
#define USB_DEVICE_ID_PRIMAX_MOUSE_4D22 0x4d22
-#define USB_DEVICE_ID_PRIMAX_MOUSE_4E2A 0x4e2a
#define USB_DEVICE_ID_PRIMAX_KEYBOARD 0x4e05
#define USB_DEVICE_ID_PRIMAX_REZEL 0x4e72
#define USB_DEVICE_ID_PRIMAX_PIXART_MOUSE_4D0F 0x4d0f
diff -rupN a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
--- a/drivers/hid/hid-quirks.c 2022-12-22 10:24:06.844881247 +0100
+++ b/drivers/hid/hid-quirks.c 2022-12-22 10:23:35.904328855 +0100
@@ -54,7 +54,6 @@ static const struct hid_device_id hid_qu
{ HID_USB_DEVICE(USB_VENDOR_ID_CH,
USB_DEVICE_ID_CH_FLIGHT_SIM_YOKE), HID_QUIRK_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_PRO_PEDALS),
HID_QUIRK_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_CH,
USB_DEVICE_ID_CH_PRO_THROTTLE), HID_QUIRK_NOGET },
- { HID_USB_DEVICE(USB_VENDOR_ID_CHERRY,
USB_DEVICE_ID_CHERRY_MOUSE_000C), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR,
USB_DEVICE_ID_CORSAIR_K65RGB), HID_QUIRK_NO_INIT_REPORTS },
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR,
USB_DEVICE_ID_CORSAIR_K65RGB_RAPIDFIRE), HID_QUIRK_NO_INIT_REPORTS |
HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR,
USB_DEVICE_ID_CORSAIR_K70RGB), HID_QUIRK_NO_INIT_REPORTS },
@@ -123,7 +122,6 @@ static const struct hid_device_id hid_qu
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_MOUSE_C05A), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_MOUSE_C06A), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_MCS,
USB_DEVICE_ID_MCS_GAMEPADBLOCK), HID_QUIRK_MULTI_INPUT },
- { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_MOUSE_0783), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_PIXART_MOUSE), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_POWER_COVER), HID_QUIRK_NO_INIT_REPORTS },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_SURFACE3_COVER), HID_QUIRK_NO_INIT_REPORTS },
@@ -148,7 +146,6 @@ static const struct hid_device_id hid_qu
{ HID_USB_DEVICE(USB_VENDOR_ID_PIXART,
USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN), HID_QUIRK_NO_INIT_REPORTS },
{ HID_USB_DEVICE(USB_VENDOR_ID_PIXART,
USB_DEVICE_ID_PIXART_USB_OPTICAL_MOUSE), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_PRIMAX,
USB_DEVICE_ID_PRIMAX_MOUSE_4D22), HID_QUIRK_ALWAYS_POLL },
- { HID_USB_DEVICE(USB_VENDOR_ID_PRIMAX,
USB_DEVICE_ID_PRIMAX_MOUSE_4E2A), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_PRIMAX,
USB_DEVICE_ID_PRIMAX_PIXART_MOUSE_4D0F), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_PRIMAX,
USB_DEVICE_ID_P
Re: [FSL P50x0] DPAA Ethernet issue
> On 3. Jan 2023, at 05:04, Christian Zigotzky wrote: > > On 02 January 2023 at 04:32 am, Christian Zigotzky wrote: >> On 01 January 2023 at 07:11 pm, Sean Anderson wrote: >> >> Thank you for testing this. Unfortunately, I have no P-series hardware, >> so I was unable to test the 10gec/dtsec parts of this conversion. I had >> hoped that this would get tested by someone with the hardware (at NXP) >> before now, but it seems you get to be the "lucky" first user. >> >> I see you have labeled one of your kernels as supporting QEMU. Do you >> happen to have instructions for running Linux on QEMU? >> >> Can you try the following patch. I think my mail client will mangle it, so >> I have also attached it to this email. >> >> >> >> Hi Sean, >> >> Thanks a lot for your answer. >> >> I use the virtio-net device in a virtual e5500 QEMU/KVM HV machine. [1] [2] >> >> I will test your patch as soon as possible. >> >> Thanks, >> Christian >> >> [1] QEMU command: qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel >> uImage-6.2 -drive >> format=raw,file=void-live-powerpc-20220129.img,index=0,if=virtio -netdev >> user,id=mynet0 -device virtio-net,netdev=mynet0 -append "rw root=/dev/vda2" >> -device virtio-gpu -device virtio-mouse-pci -device virtio-keyboard-pci >> -device pci-ohci,id=newusb -audiodev >> id=sndbe,driver=pa,server=/run/user/1000/pulse/native -device >> usb-audio,bus=newusb.0 -enable-kvm -smp 4 -fsdev >> local,security_model=passthrough,id=fsdev0,path=/home/amigaone/Music -device >> virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=hostshare >> >> [2] https://forum.hyperion-entertainment.com/viewtopic.php?p=46749 > > Hi Sean, > > I tested your patch with the RC2 today but unfortunately the kernel doesn't > link after compiling. > > Error messages: > > LD .tmp_vmlinux.kallsyms1 > `.exit.text' referenced in section `__bug_table' of crypto/algboss.o: defined > in discarded section `.exit.text' of crypto/algboss.o > `.exit.text' referenced in section `__bug_table' of crypto/algif_hash.o: > defined in discarded section `.exit.text' of crypto/algif_hash.o > `.exit.text' referenced in section `__bug_table' of > drivers/char/hw_random/core.o: defined in discarded section `.exit.text' of > drivers/char/hw_random/core.o > make[1]: *** [scripts/Makefile.vmlinux:34: vmlinux] Error 1 > make: *** [Makefile:1252: vmlinux] Error 2 > > Maybe it is not an issue because of the patch because the RC1 compilied and > linked with the patch. > > @Dave > Please test the RC1 with Sean's patch. > > Download: http://www.xenosoft.de/uImage-6.2-dpaa-t1 > > Cheers, > Christian Hi Sean, Dave successfully tested the DPAA Ethernet with the patched RC1 on his P5020 board (X5000) today. Link to the test thread: https://forum.hyperion-entertainment.com/viewtopic.php?p=56360#p56360 Your patch has solved the issue. Thanks for your help. Cheers, Christian
Re: [FSL P50x0] DPAA Ethernet issue
On 02 January 2023 at 04:32 am, Christian Zigotzky wrote: On 01 January 2023 at 07:11 pm, Sean Anderson wrote: Thank you for testing this. Unfortunately, I have no P-series hardware, so I was unable to test the 10gec/dtsec parts of this conversion. I had hoped that this would get tested by someone with the hardware (at NXP) before now, but it seems you get to be the "lucky" first user. I see you have labeled one of your kernels as supporting QEMU. Do you happen to have instructions for running Linux on QEMU? Can you try the following patch. I think my mail client will mangle it, so I have also attached it to this email. Hi Sean, Thanks a lot for your answer. I use the virtio-net device in a virtual e5500 QEMU/KVM HV machine. [1] [2] I will test your patch as soon as possible. Thanks, Christian [1] QEMU command: qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage-6.2 -drive format=raw,file=void-live-powerpc-20220129.img,index=0,if=virtio -netdev user,id=mynet0 -device virtio-net,netdev=mynet0 -append "rw root=/dev/vda2" -device virtio-gpu -device virtio-mouse-pci -device virtio-keyboard-pci -device pci-ohci,id=newusb -audiodev id=sndbe,driver=pa,server=/run/user/1000/pulse/native -device usb-audio,bus=newusb.0 -enable-kvm -smp 4 -fsdev local,security_model=passthrough,id=fsdev0,path=/home/amigaone/Music -device virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=hostshare [2] https://forum.hyperion-entertainment.com/viewtopic.php?p=46749 Hi Sean, I tested your patch with the RC2 today but unfortunately the kernel doesn't link after compiling. Error messages: LD .tmp_vmlinux.kallsyms1 `.exit.text' referenced in section `__bug_table' of crypto/algboss.o: defined in discarded section `.exit.text' of crypto/algboss.o `.exit.text' referenced in section `__bug_table' of crypto/algif_hash.o: defined in discarded section `.exit.text' of crypto/algif_hash.o `.exit.text' referenced in section `__bug_table' of drivers/char/hw_random/core.o: defined in discarded section `.exit.text' of drivers/char/hw_random/core.o make[1]: *** [scripts/Makefile.vmlinux:34: vmlinux] Error 1 make: *** [Makefile:1252: vmlinux] Error 2 Maybe it is not an issue because of the patch because the RC1 compilied and linked with the patch. @Dave Please test the RC1 with Sean's patch. Download: http://www.xenosoft.de/uImage-6.2-dpaa-t1 sudo dmesg | grep -i dpaa [ 3.017121] fsl_dpaa_mac ffe4e8000.ethernet: FMan dTSEC version: 0x08240101 [ 3.017256] fsl_dpaa_mac ffe4e8000.ethernet: FMan MAC address: 00:04:a3:6b:41:65 [ 3.017534] fsl_dpaa_mac ffe4f.ethernet: of_get_mac_address(/soc@ffe00/fman@40/ethernet@f) failed [ 3.017745] fsl_dpaa_mac ffe4f.ethernet: of_get_phy_mode() for /soc@ffe00/fman@40/ethernet@f failed. Defaulting to SGMII [ 3.017975] fsl_dpaa_mac: FMan XGEC version: 0x00010330 [ 3.018293] fsl_dpaa_mac ffe5e8000.ethernet: FMan dTSEC version: 0x08240101 [ 3.018413] fsl_dpaa_mac ffe5e8000.ethernet: FMan MAC address: 00:1e:c0:f8:01:59 [ 3.018656] fsl_dpaa_mac ffe5f.ethernet: of_get_mac_address(/soc@ffe00/fman@50/ethernet@f) failed [ 3.018871] fsl_dpaa_mac ffe5f.ethernet: of_get_phy_mode() for /soc@ffe00/fman@50/ethernet@f failed. Defaulting to SGMII [ 3.019099] fsl_dpaa_mac: FMan XGEC version: 0x00010330 [ 3.021559] fsl_dpaa_mac ffe4e8000.ethernet eth0: Probed interface eth0 [ 3.023358] fsl_dpaa_mac ffe4f.ethernet: Using random MAC address: 5e:d0:6f:2b:29:35 [ 3.024041] fsl_dpaa_mac ffe4f.ethernet eth1: Probed interface eth1 [ 3.026381] fsl_dpaa_mac ffe5e8000.ethernet eth2: Probed interface eth2 [ 3.028199] fsl_dpaa_mac ffe5f.ethernet: Using random MAC address: c2:ec:b7:35:67:37 [ 3.028878] fsl_dpaa_mac ffe5f.ethernet eth3: Probed interface eth3 [ 7.543868] fsl_dpaa_mac ffe4e8000.ethernet eth0: PHY [mdio@ffe4e1120:03] driver [Generic PHY] (irq=POLL) [ 7.549774] fsl_dpaa_mac ffe4e8000.ethernet eth0: configuring for phy/rgmii link mode [ 7.583166] fsl_dpaa_mac ffe5e8000.ethernet eth2: PHY [mdio@ffe4e1120:07] driver [Generic PHY] (irq=POLL) [ 7.589079] fsl_dpaa_mac ffe5e8000.ethernet eth2: configuring for phy/rgmii link mode Cheers, Christian
Re: [FSL P50x0] DPAA Ethernet issue
On 01 January 2023 at 07:11 pm, Sean Anderson wrote: Thank you for testing this. Unfortunately, I have no P-series hardware, so I was unable to test the 10gec/dtsec parts of this conversion. I had hoped that this would get tested by someone with the hardware (at NXP) before now, but it seems you get to be the "lucky" first user. I see you have labeled one of your kernels as supporting QEMU. Do you happen to have instructions for running Linux on QEMU? Can you try the following patch. I think my mail client will mangle it, so I have also attached it to this email. Hi Sean, Thanks a lot for your answer. I use the virtio-net device in a virtual e5500 QEMU/KVM HV machine. [1] [2] I will test your patch as soon as possible. Thanks, Christian [1] QEMU command: qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage-6.2 -drive format=raw,file=void-live-powerpc-20220129.img,index=0,if=virtio -netdev user,id=mynet0 -device virtio-net,netdev=mynet0 -append "rw root=/dev/vda2" -device virtio-gpu -device virtio-mouse-pci -device virtio-keyboard-pci -device pci-ohci,id=newusb -audiodev id=sndbe,driver=pa,server=/run/user/1000/pulse/native -device usb-audio,bus=newusb.0 -enable-kvm -smp 4 -fsdev local,security_model=passthrough,id=fsdev0,path=/home/amigaone/Music -device virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=hostshare [2] https://forum.hyperion-entertainment.com/viewtopic.php?p=46749
[FSL P50x0] DPAA Ethernet issue
Hi All, The DPAA Ethernet doesn’t work anymore on our FSL P5020/P5040 boards [1] since the first updates after the final kernel 6.1 [2]. We bisected yesterday [3] and found the problematic commit [4]. I was able to revert it. After that the DPAA Ethernet works again. I created a patch for reverting the commit [4]. After patching and compiling, the DPAA Ethernet also works again. It seems, that the new driver doesn’t work with our onboard DPAA network interfaces. 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=56326#p56326 [3] https://forum.hyperion-entertainment.com/viewtopic.php?p=56334#p56334 [4] lnet: dpaa: Convert to phylink: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.1&id=5d93cfcf7360eac9903774fe94f626c9ead2049d
[PASEMI] Nemo board doesn't reboot anymore after the commit "HID: usbhid: Add ALWAYS_POLL quirk for some mice"
Hello,
The Nemo board [1] doesn't reboot anymore since the final kernel 6.1.
The reboot works with the RC8 of kernel 6.1.
Actually, a reboot works but the CFE firmware is not loaded. Maybe there
is still something in the memory after the reboot.
I bisected today. [2]
The commit "HID: usbhid: Add ALWAYS_POLL quirk for some mice". [3] is
the problem.
I was able to revert this commit and the reboot works without any
problems again.
I created a patch for reverting the bad commit. [4]
Then compiled the kernel with this patch. After that, the X1000 reboots
without any problems.
I use a Cherry USB mouse. [5]
Please check the bad commit.
Thanks,
Christian
[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2] https://forum.hyperion-entertainment.com/viewtopic.php?p=56303#p56303
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.1&id=f6d910a89a2391e5ce1f275d205023880a33d3f8
[4] usbhid.patch:
diff -rupN a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
--- a/drivers/hid/hid-ids.h 2022-12-22 10:24:06.842881276 +0100
+++ b/drivers/hid/hid-ids.h 2022-12-22 10:23:35.903328869 +0100
@@ -274,7 +274,6 @@
#define USB_DEVICE_ID_CH_AXIS_295 0x001c
#define USB_VENDOR_ID_CHERRY 0x046a
-#define USB_DEVICE_ID_CHERRY_MOUSE_000C 0x000c
#define USB_DEVICE_ID_CHERRY_CYMOTION 0x0023
#define USB_DEVICE_ID_CHERRY_CYMOTION_SOLAR 0x0027
@@ -919,7 +918,6 @@
#define USB_DEVICE_ID_MS_XBOX_ONE_S_CONTROLLER 0x02fd
#define USB_DEVICE_ID_MS_PIXART_MOUSE 0x00cb
#define USB_DEVICE_ID_8BITDO_SN30_PRO_PLUS 0x02e0
-#define USB_DEVICE_ID_MS_MOUSE_0783 0x0783
#define USB_VENDOR_ID_MOJO 0x8282
#define USB_DEVICE_ID_RETRO_ADAPTER 0x3201
@@ -1388,7 +1386,6 @@
#define USB_VENDOR_ID_PRIMAX 0x0461
#define USB_DEVICE_ID_PRIMAX_MOUSE_4D22 0x4d22
-#define USB_DEVICE_ID_PRIMAX_MOUSE_4E2A 0x4e2a
#define USB_DEVICE_ID_PRIMAX_KEYBOARD 0x4e05
#define USB_DEVICE_ID_PRIMAX_REZEL 0x4e72
#define USB_DEVICE_ID_PRIMAX_PIXART_MOUSE_4D0F 0x4d0f
diff -rupN a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
--- a/drivers/hid/hid-quirks.c 2022-12-22 10:24:06.844881247 +0100
+++ b/drivers/hid/hid-quirks.c 2022-12-22 10:23:35.904328855 +0100
@@ -54,7 +54,6 @@ static const struct hid_device_id hid_qu
{ HID_USB_DEVICE(USB_VENDOR_ID_CH,
USB_DEVICE_ID_CH_FLIGHT_SIM_YOKE), HID_QUIRK_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_PRO_PEDALS),
HID_QUIRK_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_PRO_THROTTLE),
HID_QUIRK_NOGET },
- { HID_USB_DEVICE(USB_VENDOR_ID_CHERRY,
USB_DEVICE_ID_CHERRY_MOUSE_000C), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR,
USB_DEVICE_ID_CORSAIR_K65RGB), HID_QUIRK_NO_INIT_REPORTS },
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR,
USB_DEVICE_ID_CORSAIR_K65RGB_RAPIDFIRE), HID_QUIRK_NO_INIT_REPORTS |
HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR,
USB_DEVICE_ID_CORSAIR_K70RGB), HID_QUIRK_NO_INIT_REPORTS },
@@ -123,7 +122,6 @@ static const struct hid_device_id hid_qu
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_MOUSE_C05A), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_MOUSE_C06A), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_MCS,
USB_DEVICE_ID_MCS_GAMEPADBLOCK), HID_QUIRK_MULTI_INPUT },
- { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_MOUSE_0783), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_PIXART_MOUSE), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_POWER_COVER), HID_QUIRK_NO_INIT_REPORTS },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
USB_DEVICE_ID_MS_SURFACE3_COVER), HID_QUIRK_NO_INIT_REPORTS },
@@ -148,7 +146,6 @@ static const struct hid_device_id hid_qu
{ HID_USB_DEVICE(USB_VENDOR_ID_PIXART,
USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN), HID_QUIRK_NO_INIT_REPORTS },
{ HID_USB_DEVICE(USB_VENDOR_ID_PIXART,
USB_DEVICE_ID_PIXART_USB_OPTICAL_MOUSE), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_PRIMAX,
USB_DEVICE_ID_PRIMAX_MOUSE_4D22), HID_QUIRK_ALWAYS_POLL },
- { HID_USB_DEVICE(USB_VENDOR_ID_PRIMAX,
USB_DEVICE_ID_PRIMAX_MOUSE_4E2A), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_PRIMAX,
USB_DEVICE_ID_PRIMAX_PIXART_MOUSE_4D0F), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_PRIMAX,
USB_DEVICE_ID_PRIMAX_PIXART_MOUSE_4D65), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_PRIMAX,
USB_DEVICE_ID_PRIMAX_PIXART_MOUSE_4E22), HID_QUIRK_ALWAYS_POLL },
[5]
Bus 003 Device 002: ID 046a:000c Cherry GmbH
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0
Re: [RFC PATCH] Disable Book-E KVM support?
Further information: https://lists.nongnu.org/archive/html/qemu-ppc/2022-12/msg0.html -- Christian On 04 December 2022 at 12:33 pm, Christian Zigotzky wrote: Hi All, We regularly use QEMU with KVM HV on our A-EON AmigaOne X5000 machines (book3e). It works fast and without any problems. Screenshot tour of QEMU/KVM HV on our AmigaOnes: - https://i.ibb.co/m4vgwNT/Kernel-6-1-rc3-Power-PC.png - https://i.ibb.co/Fwdjf7Z/Kernel-6-0-rc6-Power-PC.png - https://i.ibb.co/LYnJGdF/Kernel-5-19-rc5-Power-PC-2.png - https://i.ibb.co/vz1Wm5z/QEMU-with-9p-and-USB-sound.png - https://i.ibb.co/ScMjtp7/Kernel-5-17-alpha5-Power-PC.png - https://i.ibb.co/LQryFcK/Kernel-5-17-alpha4-Power-PC.png - https://i.ibb.co/kKLx9mf/Kernel-5-10-89-Power-PC.png - https://i.ibb.co/LRG1RDV/Kernel-5-10-89-Power-PC-2.png - https://i.ibb.co/NCFqY0k/QEMU-USB-Audio-on-Void-PPC.png - https://i.ibb.co/N1vL5Kd/Kernel-5-16-alpha3-Power-PC.png - https://i.ibb.co/SwjTyJk/Kernel-5-16-alpha1-Power-PC.png - https://i.ibb.co/LkpWNPx/Kernel-5-15-rc5-Power-PC.png - https://i.ibb.co/F8q1jDR/Kernel-5-15-rc4-Power-PC.png - https://i.ibb.co/zZxrbhV/Kernel-5-15-alpha6-Power-PC.png - https://i.pinimg.com/originals/a8/8b/42/a88b422870201887fc01ef44ddc1a235.png - https://i.pinimg.com/originals/57/d9/83/57d98324cd055b7ae00a87ad5a45a42f.png - https://i.pinimg.com/originals/f2/a5/e3/f2a5e34e2015381b0cb87cc51232a8bc.png - https://i.pinimg.com/originals/c5/0d/85/c50d85d7e8f20b4caa1a439faf751964.png - https://i.pinimg.com/originals/6e/3b/59/6e3b59fe10276c5644b15622a81f43f1.png We solved some issues: - https://forum.hyperion-entertainment.com/viewtopic.php?p=54357#p54357 - https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-November/236307.html - https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-September/249021.html - https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-May/229103.html - https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-January/223342.html - https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-August/216379.html - https://forum.hyperion-entertainment.com/viewtopic.php?f=58&t=4655&p=53393&hilit=KVM#p53393 - https://forum.hyperion-entertainment.com/viewtopic.php?p=53209#p53209 Please, do not remove KVM support from Book3e because it works without any problems and fast. We need it for our work. Thanks, Christian On 12/2/22 12:04, Daniel Henrique Barboza wrote: On 11/30/22 17:45, Crystal Wood wrote: On Mon, 2022-11-28 at 14:36 +1000, Nicholas Piggin wrote: BookE KVM is in a deep maintenance state, I'm not sure how much testing it gets. I don't have a test setup, and it does not look like QEMU has any HV architecture enabled. It hasn't been too painful but there are some cases where it causes a bit of problem not being able to test, e.g., https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-November/251452.html Time to begin removal process, or are there still people using it? I'm happy to to keep making occasional patches to try keep it going if there are people testing upstream. Getting HV support into QEMU would help with long term support, not sure how big of a job that would be. Not sure what you mean about QEMU not having e500 HV support? I don't know if it's bitrotted, but it's there. AFAIK all QEMU ppc boards, aside from pSeries and the Mac ones, are always used in emulated mode in an use case similar to what Bernhard described in his reply (run in x86 due to lack of ppc hardware). I am not aware of e500 KVM support in QEMU since I never attempted it. But yes, it is present, but poorly tested - if tested at all. And the reason why there's no push on our side to removed it from QEMU is because its code is so entwined with pSeries KVM that it would take too much effort. Do not take the presence of e500 KVM support in QEMU as a blocker to disabled it in the kernel. As far as the current QEMU usage goes e500 KVM can be removed without too much drama from our side. Cedric, do you have any opinions about it? I can not tell how much e500 KVM is used. The last report we had on the topic was : https://lore.kernel.org/all/R4OPHT$7f12c66d1107397991e0e4c978fe6...@locati.it/ and the last commit mentioning e500 VMs I could find is cb3778a045, which brings us back to QEMU 2.2 or so. It would be nice to 'quickly' check the state of the KVM stack on such boards and, may be, plan for more cleanups. Thanks, C. Daniel I don't know whether anyone is still using this, but if they are, it's probably e500mc and not e500v2 (which involved a bunch of hacks
Re: [RFC PATCH] Disable Book-E KVM support?
Hi All, We regularly use QEMU with KVM HV on our A-EON AmigaOne X5000 machines (book3e). It works fast and without any problems. Screenshot tour of QEMU/KVM HV on our AmigaOnes: - https://i.ibb.co/m4vgwNT/Kernel-6-1-rc3-Power-PC.png - https://i.ibb.co/Fwdjf7Z/Kernel-6-0-rc6-Power-PC.png - https://i.ibb.co/LYnJGdF/Kernel-5-19-rc5-Power-PC-2.png - https://i.ibb.co/vz1Wm5z/QEMU-with-9p-and-USB-sound.png - https://i.ibb.co/ScMjtp7/Kernel-5-17-alpha5-Power-PC.png - https://i.ibb.co/LQryFcK/Kernel-5-17-alpha4-Power-PC.png - https://i.ibb.co/kKLx9mf/Kernel-5-10-89-Power-PC.png - https://i.ibb.co/LRG1RDV/Kernel-5-10-89-Power-PC-2.png - https://i.ibb.co/NCFqY0k/QEMU-USB-Audio-on-Void-PPC.png - https://i.ibb.co/N1vL5Kd/Kernel-5-16-alpha3-Power-PC.png - https://i.ibb.co/SwjTyJk/Kernel-5-16-alpha1-Power-PC.png - https://i.ibb.co/LkpWNPx/Kernel-5-15-rc5-Power-PC.png - https://i.ibb.co/F8q1jDR/Kernel-5-15-rc4-Power-PC.png - https://i.ibb.co/zZxrbhV/Kernel-5-15-alpha6-Power-PC.png - https://i.pinimg.com/originals/a8/8b/42/a88b422870201887fc01ef44ddc1a235.png - https://i.pinimg.com/originals/57/d9/83/57d98324cd055b7ae00a87ad5a45a42f.png - https://i.pinimg.com/originals/f2/a5/e3/f2a5e34e2015381b0cb87cc51232a8bc.png - https://i.pinimg.com/originals/c5/0d/85/c50d85d7e8f20b4caa1a439faf751964.png - https://i.pinimg.com/originals/6e/3b/59/6e3b59fe10276c5644b15622a81f43f1.png We solved some issues: - https://forum.hyperion-entertainment.com/viewtopic.php?p=54357#p54357 - https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-November/236307.html - https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-September/249021.html - https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-May/229103.html - https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-January/223342.html - https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-August/216379.html - https://forum.hyperion-entertainment.com/viewtopic.php?f=58&t=4655&p=53393&hilit=KVM#p53393 - https://forum.hyperion-entertainment.com/viewtopic.php?p=53209#p53209 Please, do not remove KVM support from Book3e because it works without any problems and fast. We need it for our work. Thanks, Christian On 12/2/22 12:04, Daniel Henrique Barboza wrote: On 11/30/22 17:45, Crystal Wood wrote: On Mon, 2022-11-28 at 14:36 +1000, Nicholas Piggin wrote: BookE KVM is in a deep maintenance state, I'm not sure how much testing it gets. I don't have a test setup, and it does not look like QEMU has any HV architecture enabled. It hasn't been too painful but there are some cases where it causes a bit of problem not being able to test, e.g., https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-November/251452.html Time to begin removal process, or are there still people using it? I'm happy to to keep making occasional patches to try keep it going if there are people testing upstream. Getting HV support into QEMU would help with long term support, not sure how big of a job that would be. Not sure what you mean about QEMU not having e500 HV support? I don't know if it's bitrotted, but it's there. AFAIK all QEMU ppc boards, aside from pSeries and the Mac ones, are always used in emulated mode in an use case similar to what Bernhard described in his reply (run in x86 due to lack of ppc hardware). I am not aware of e500 KVM support in QEMU since I never attempted it. But yes, it is present, but poorly tested - if tested at all. And the reason why there's no push on our side to removed it from QEMU is because its code is so entwined with pSeries KVM that it would take too much effort. Do not take the presence of e500 KVM support in QEMU as a blocker to disabled it in the kernel. As far as the current QEMU usage goes e500 KVM can be removed without too much drama from our side. Cedric, do you have any opinions about it? I can not tell how much e500 KVM is used. The last report we had on the topic was : https://lore.kernel.org/all/R4OPHT$7f12c66d1107397991e0e4c978fe6...@locati.it/ and the last commit mentioning e500 VMs I could find is cb3778a045, which brings us back to QEMU 2.2 or so. It would be nice to 'quickly' check the state of the KVM stack on such boards and, may be, plan for more cleanups. Thanks, C. Daniel I don't know whether anyone is still using this, but if they are, it's probably e500mc and not e500v2 (which involved a bunch of hacks to get almost- sorta-usable performance out of hardware not designed for virtualization). I do see that there have been a few recent patches on QEMU e500 (beyond the treewide cleanup type stuff), though I don
Issues with the first PowerPC updates for the kernel 6.1
On 30 October 2022 at 02:30 pm, Christian Zigotzky wrote:
On 29 October 2022 at 01:44 pm, Christian Zigotzky wrote:
On 17 October 2022 at 09:53 am, Christian Zigotzky wrote:
On 17. Oct 2022, at 02:43, Michael Ellerman
wrote:
Previously BIG_ENDIAN && GENERIC_CPU would use -mcpu=power5, now it
uses
-mcpu=power4.
Maybe this is the issue. We will wait and not release the RC1 for
testing because it is a risk for our testers to test these new
kernels because of this issue.
cheers
I compiled the RC2 of kernel 6.1 today.
After the first boot of the RC2, the file system was immediately to
100% used. This is the same issue we have seen with the git kernel 3
weeks ago.
The Cyrus+ and Nemo boards are affected.
I wrote 3 weeks ago:
Hi All,
I successfully compiled the latest git kernel with the first PowerPC
updates yesterday.
Unfortunately this kernel is really dangerous. Many things for
example Network Manager and LightDM don't work anymore and produced
several gigabyte of config files till the partition has been filled.
I deleted some files like the resolv.conf that had a size over 200 GB!
Unfortunately, MintPPC was still damaged. For example LightDM doesn't
work anymore and the MATE desktop doesn't display any icons anymore
because Caja wasn't able to reserve memory anymore.
In this case, bisecting isn't an option and I have to wait some
weeks. It is really difficult to find the issue if the userland will
damaged again and again.
Cheers,
Christian
---
Maybe there is an issue in my kernel configs. Could you please check
the configs? Please find attached the configs. Could you please test
the RC2 on your FSL and pasemi machines?
Thanks,
Christian
Hi All,
I bisected today because Void PPC is recovering after a reboot. Memory
space is released again. [1]
Result: c2e7a19827eec443a7cbe85e8d959052412d6dc3 (powerpc: Use generic
fallocate compatibility syscall) is the first bad commit. [2]
I was able to create a patch for reverting this bad commit. [3]
I compiled the kernel with this patch. After that the kernel works
without any problems.
Please check the first bad commit. [2]
Thanks,
Christian
[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=56099#p56099
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c2e7a19827eec443a7cbe85e8d959052412d6dc3
[3] syscall.patch:
diff -rupN a/arch/powerpc/include/asm/syscalls.h
b/arch/powerpc/include/asm/syscalls.h
--- a/arch/powerpc/include/asm/syscalls.h 2022-10-30
13:53:28.956001116 +0100
+++ b/arch/powerpc/include/asm/syscalls.h 2022-10-30
13:55:39.166300756 +0100
@@ -15,6 +15,7 @@
#include
#include
+long compat_sys_fallocate(int fd, int mode, u32 offset1, u32 offset2,
u32 len1, u32 len2);
#ifndef CONFIG_ARCH_HAS_SYSCALL_WRAPPER
long sys_ni_syscall(void);
#else
diff -rupN a/arch/powerpc/include/asm/unistd.h
b/arch/powerpc/include/asm/unistd.h
--- a/arch/powerpc/include/asm/unistd.h 2022-10-30 13:53:28.957001103
+0100
+++ b/arch/powerpc/include/asm/unistd.h 2022-10-30 13:56:44.851441888
+0100
@@ -45,7 +45,6 @@
#define __ARCH_WANT_SYS_UTIME
#define __ARCH_WANT_SYS_NEWFSTATAT
#define __ARCH_WANT_COMPAT_STAT
-#define __ARCH_WANT_COMPAT_FALLOCATE
#define __ARCH_WANT_COMPAT_SYS_SENDFILE
#endif
#define __ARCH_WANT_SYS_FORK
diff -rupN a/arch/powerpc/kernel/sys_ppc32.c
b/arch/powerpc/kernel/sys_ppc32.c
--- a/arch/powerpc/kernel/sys_ppc32.c 2022-10-30 13:53:28.967000972
+0100
+++ b/arch/powerpc/kernel/sys_ppc32.c 2022-10-30 13:58:28.993078689
+0100
@@ -97,6 +97,13 @@ PPC32_SYSCALL_DEFINE4(ppc_truncate64,
return ksys_truncate(path, merge_64(len1, len2));
}
+long compat_sys_fallocate(int fd, int mode, u32 offset1, u32 offset2,
+ u32 len1, u32 len2)
+{
+ return ksys_fallocate(fd, mode, merge_64(offset1, offset2),
+ merge_64(len1, len2));
+}
+
PPC32_SYSCALL_DEFINE4(ppc_ftruncate64,
unsigned int, fd, u32, reg4,
unsigned long, len1, unsigned long, len2)
Hello,
I compiled the RC3 of kernel 6.1 today. Unfortunately the issue still
exists. I still need the patch above for a working kernel.
Cheers,
Christian
Re: Issues with the first PowerPC updates for the kernel 6.1
On 29 October 2022 at 01:44 pm, Christian Zigotzky wrote:
On 17 October 2022 at 09:53 am, Christian Zigotzky wrote:
On 17. Oct 2022, at 02:43, Michael Ellerman wrote:
Previously BIG_ENDIAN && GENERIC_CPU would use -mcpu=power5, now it
uses
-mcpu=power4.
Maybe this is the issue. We will wait and not release the RC1 for
testing because it is a risk for our testers to test these new
kernels because of this issue.
cheers
I compiled the RC2 of kernel 6.1 today.
After the first boot of the RC2, the file system was immediately to
100% used. This is the same issue we have seen with the git kernel 3
weeks ago.
The Cyrus+ and Nemo boards are affected.
I wrote 3 weeks ago:
Hi All,
I successfully compiled the latest git kernel with the first PowerPC
updates yesterday.
Unfortunately this kernel is really dangerous. Many things for example
Network Manager and LightDM don't work anymore and produced several
gigabyte of config files till the partition has been filled.
I deleted some files like the resolv.conf that had a size over 200 GB!
Unfortunately, MintPPC was still damaged. For example LightDM doesn't
work anymore and the MATE desktop doesn't display any icons anymore
because Caja wasn't able to reserve memory anymore.
In this case, bisecting isn't an option and I have to wait some weeks.
It is really difficult to find the issue if the userland will damaged
again and again.
Cheers,
Christian
---
Maybe there is an issue in my kernel configs. Could you please check
the configs? Please find attached the configs. Could you please test
the RC2 on your FSL and pasemi machines?
Thanks,
Christian
Hi All,
I bisected today because Void PPC is recovering after a reboot. Memory
space is released again. [1]
Result: c2e7a19827eec443a7cbe85e8d959052412d6dc3 (powerpc: Use generic
fallocate compatibility syscall) is the first bad commit. [2]
I was able to create a patch for reverting this bad commit. [3]
I compiled the kernel with this patch. After that the kernel works
without any problems.
Please check the first bad commit. [2]
Thanks,
Christian
[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=56099#p56099
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c2e7a19827eec443a7cbe85e8d959052412d6dc3
[3] syscall.patch:
diff -rupN a/arch/powerpc/include/asm/syscalls.h
b/arch/powerpc/include/asm/syscalls.h
--- a/arch/powerpc/include/asm/syscalls.h 2022-10-30
13:53:28.956001116 +0100
+++ b/arch/powerpc/include/asm/syscalls.h 2022-10-30
13:55:39.166300756 +0100
@@ -15,6 +15,7 @@
#include
#include
+long compat_sys_fallocate(int fd, int mode, u32 offset1, u32 offset2,
u32 len1, u32 len2);
#ifndef CONFIG_ARCH_HAS_SYSCALL_WRAPPER
long sys_ni_syscall(void);
#else
diff -rupN a/arch/powerpc/include/asm/unistd.h
b/arch/powerpc/include/asm/unistd.h
--- a/arch/powerpc/include/asm/unistd.h 2022-10-30 13:53:28.957001103 +0100
+++ b/arch/powerpc/include/asm/unistd.h 2022-10-30 13:56:44.851441888 +0100
@@ -45,7 +45,6 @@
#define __ARCH_WANT_SYS_UTIME
#define __ARCH_WANT_SYS_NEWFSTATAT
#define __ARCH_WANT_COMPAT_STAT
-#define __ARCH_WANT_COMPAT_FALLOCATE
#define __ARCH_WANT_COMPAT_SYS_SENDFILE
#endif
#define __ARCH_WANT_SYS_FORK
diff -rupN a/arch/powerpc/kernel/sys_ppc32.c
b/arch/powerpc/kernel/sys_ppc32.c
--- a/arch/powerpc/kernel/sys_ppc32.c 2022-10-30 13:53:28.967000972 +0100
+++ b/arch/powerpc/kernel/sys_ppc32.c 2022-10-30 13:58:28.993078689 +0100
@@ -97,6 +97,13 @@ PPC32_SYSCALL_DEFINE4(ppc_truncate64,
return ksys_truncate(path, merge_64(len1, len2));
}
+long compat_sys_fallocate(int fd, int mode, u32 offset1, u32 offset2,
+ u32 len1, u32 len2)
+{
+ return ksys_fallocate(fd, mode, merge_64(offset1, offset2),
+ merge_64(len1, len2));
+}
+
PPC32_SYSCALL_DEFINE4(ppc_ftruncate64,
unsigned int, fd, u32, reg4,
unsigned long, len1, unsigned long, len2)
Re: Issues with the first PowerPC updates for the kernel 6.1
On 29 October 2022 at 5:33 pm, Segher Boessenkool wrote: On Mon, Oct 17, 2022 at 09:53:04AM +0200, Christian Zigotzky wrote: On 17. Oct 2022, at 02:43, Michael Ellerman wrote: Previously BIG_ENDIAN && GENERIC_CPU would use -mcpu=power5, now it uses -mcpu=power4. Maybe this is the issue. We will wait and not release the RC1 for testing because it is a risk for our testers to test these new kernels because of this issue. It is really important do not to rewrite code, that is well worked before. Bugfixing and adding some new features is ok but rewriting of good code is expensive and doesn’t make any sense. It was just a bugfix, and a (partial) revert. 471d7ff8b51b says it removed ISA 2.00 support (original power4, "GP"). Support for ISA 2.01 was retained it says. That is power4+, "GQ", but also 970 (Apple G5). That patch actually switched to ISA 2.02 though, unintendedly, and code generated for ISA 2.02 will not run on systems like 970, in principle. It is just one uncommon instruction that is problematical, namely popcntb, because the kernel does not use floating point at all, so that is why we got away with it for so long (most code that does use fp will fall flat on its face in no time). It still is a bug fix though! PA6T is ISA 2.04, it's not clear how this (bugfix, and revert!) change made code not run on PA6T anymore. Smells a lot like something indirect (or triply indirect), a separate bug, something that was introduced in the last two years maybe, but I'll even bet it is something *exposed* in that time, a bug that has been here for longer! Segher Unfortunately my FSL P5040 system is also affected. -- Christian
Re: Issues with the first PowerPC updates for the kernel 6.1
On 29 October 2022 at 01:44 pm, Christian Zigotzky wrote: On 17 October 2022 at 09:53 am, Christian Zigotzky wrote: On 17. Oct 2022, at 02:43, Michael Ellerman wrote: Previously BIG_ENDIAN && GENERIC_CPU would use -mcpu=power5, now it uses -mcpu=power4. Maybe this is the issue. We will wait and not release the RC1 for testing because it is a risk for our testers to test these new kernels because of this issue. cheers I compiled the RC2 of kernel 6.0 today. Typo: I mean the RC2 of kernel 6.1. After the first boot of the RC2, the file system was immediately to 100% used. This is the same issue we have seen with the git kernel 3 weeks ago. The Cyrus+ and Nemo boards are affected. I wrote 3 weeks ago: Hi All, I successfully compiled the latest git kernel with the first PowerPC updates yesterday. Unfortunately this kernel is really dangerous. Many things for example Network Manager and LightDM don't work anymore and produced several gigabyte of config files till the partition has been filled. I deleted some files like the resolv.conf that had a size over 200 GB! Unfortunately, MintPPC was still damaged. For example LightDM doesn't work anymore and the MATE desktop doesn't display any icons anymore because Caja wasn't able to reserve memory anymore. In this case, bisecting isn't an option and I have to wait some weeks. It is really difficult to find the issue if the userland will damaged again and again. Cheers, Christian --- Maybe there is an issue in my kernel configs. Could you please check the configs? Please find attached the configs. Could you please test the RC2 on your FSL and pasemi machines? Thanks, Christian
Re: Issues with the first PowerPC updates for the kernel 6.1
> On 17. Oct 2022, at 02:43, Michael Ellerman wrote: > Previously BIG_ENDIAN && GENERIC_CPU would use -mcpu=power5, now it uses > -mcpu=power4. Maybe this is the issue. We will wait and not release the RC1 for testing because it is a risk for our testers to test these new kernels because of this issue. It is really important do not to rewrite code, that is well worked before. Bugfixing and adding some new features is ok but rewriting of good code is expensive and doesn’t make any sense. — Christian > > > cheers > >>>> On 16. Oct 2022, at 18:51, Segher Boessenkool >>>> wrote: >>> >>> On Fri, Oct 14, 2022 at 06:11:21PM +0200, Christian Zigotzky wrote: >>>> make oldconfig has asked because of the CPU family. I choosed GENERIC for >>>> my P.A. Semi PWRficient PA6T-1682M. Is this correct? Maybe this is the >>>> problem. >>>> >>>> config GENERIC_CPU >>>> -bool "Generic (POWER4 and above)" >>>> +bool "Generic (POWER5 and PowerPC 970 and above)" >>>> depends on PPC_BOOK3S_64 && !CPU_LITTLE_ENDIAN >>>> select PPC_64S_HASH_MMU >>>> >>>> There isn’t a POWER4 anymore and I used it via CONFIG_GENERIC_CPU=y before. >>> >>> PA6T is ISA 2.04, just like POWER5+. It should be fine. >>> >>> >>> Segher
Re: Issues with the first PowerPC updates for the kernel 6.1
No, it’s not fine. We used the POWER4 CPU config before. — Christian > On 16. Oct 2022, at 18:51, Segher Boessenkool > wrote: > > On Fri, Oct 14, 2022 at 06:11:21PM +0200, Christian Zigotzky wrote: >> make oldconfig has asked because of the CPU family. I choosed GENERIC for my >> P.A. Semi PWRficient PA6T-1682M. Is this correct? Maybe this is the problem. >> >> config GENERIC_CPU >> -bool "Generic (POWER4 and above)" >> +bool "Generic (POWER5 and PowerPC 970 and above)" >>depends on PPC_BOOK3S_64 && !CPU_LITTLE_ENDIAN >>select PPC_64S_HASH_MMU >> >> There isn’t a POWER4 anymore and I used it via CONFIG_GENERIC_CPU=y before. > > PA6T is ISA 2.04, just like POWER5+. It should be fine. > > > Segher
Re: Issues with the first PowerPC updates for the kernel 6.1
Hi All, make oldconfig has asked because of the CPU family. I choosed GENERIC for my P.A. Semi PWRficient PA6T-1682M. Is this correct? Maybe this is the problem. config GENERIC_CPU - bool "Generic (POWER4 and above)" + bool "Generic (POWER5 and PowerPC 970 and above)" depends on PPC_BOOK3S_64 && !CPU_LITTLE_ENDIAN select PPC_64S_HASH_MMU There isn’t a POWER4 anymore and I used it via CONFIG_GENERIC_CPU=y before. Before the first PowerPC updates: CONFIG_GENERIC_CPU=y # CONFIG_POWER5_CPU is not set Link: https://github.com/torvalds/linux/blob/master/arch/powerpc/platforms/Kconfig.cputype — Christian > On 13. Oct 2022, at 11:42, Christian Zigotzky wrote: > > Hi Christophe, > > Thanks a lot for your answer. OK, now, I know, that I don’t need to test it. > After the boot of the latest git kernel, my system was extremely damaged. > Some config files have a size of several gigabytes for example the > resolv.conf. I tried to repair this Debian system but without any success. > I copied with dd and Netcat via network another rootfs from another computer > to the damaged partition. > I don’t have the time to do it always again and again after a bad bisect > result. > I will wait some weeks and try it again. > > Cheers, > Christian > >> On 13. Oct 2022, at 09:28, Christophe Leroy >> wrote: >> >> >> >>>> Le 13/10/2022 à 09:03, Christian Zigotzky a écrit : >>> Hi Andrew, >>> >>> Does this patch also affect 64-bit kernels? >>> >>> We use often 32-bit userlands with 64-bit kernels. >> >> As far as I understand, it was already correct for 32-bit userlands with >> 64 bit kernels, aka compat. >> >> The patch applies the same approach for 32 bit kernels, as explained in >> the commit message : "Fix this by having 32-bit kernels share those >> syscall definitions with compat." >> >> Christophe >> >>> >>> Cheers, >>> Christian >>> >>>>> On 12. Oct 2022, at 09:56, Andrew Donnellan wrote: >>>> >>>> On Wed, 2022-10-12 at 08:51 +0200, Christian Zigotzky wrote: >>>>> Hi All, >>>>> >>>>> I use the Nemo board with a PASemi PA6T CPU and have some issues >>>>> since the first PowerPC updates for the kernel 6.1. >>>>> >>>>> I successfully compiled the git kernel with the first PowerPC updates >>>>> two days ago. >>>>> >>>>> Unfortunately this kernel is really dangerous. Many things for >>>>> example Network Manager and LightDM don't work anymore and produced >>>>> several gigabyte of config files till the partition has been filled. >>>>> >>>>> I deleted some files like the resolv.conf that had a size over 200 >>>>> GB! >>>>> >>>>> Unfortunately, MintPPC was still damaged. For example LightDM doesn't >>>>> work anymore and the MATE desktop doesn't display any icons anymore >>>>> because Caja wasn't able to reserve memory anymore. >>>>> >>>>> In this case, bisecting isn't an option and I have to wait some >>>>> weeks. It is really difficult to find the issue if the userland will >>>>> damaged again and again. >>>> >>>> Could you try with >>>> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20221012035335.866440-1-npig...@gmail.com/ >>>> to see if your issues are related to that? >>>> >>>> Andrew >>>> >>>> -- >>>> Andrew DonnellanOzLabs, ADL Canberra >>>> a...@linux.ibm.com IBM Australia Limited >>>> >
Re: Issues with the first PowerPC updates for the kernel 6.1
> On 15. Oct 2022, at 11:51, Andrew Donnellan wrote: > > On Thu, 2022-10-13 at 11:42 +0200, Christian Zigotzky wrote: >> Hi Christophe, >> >> Thanks a lot for your answer. OK, now, I know, that I don’t need to >> test it. After the boot of the latest git kernel, my system was >> extremely damaged. Some config files has a size of several gigabytes >> for example the resolv.conf. I tried to repair this Debian system but >> without any success. >> I copied with dd and Netcat via network another rootfs from another >> computer to the damaged partition. >> I don’t have the time to do it always again and again after a bad >> bisect result. >> I will wait some weeks and try it again. > > You're right, I was in a rush, saw a processor that wasn't IBM and > assumed it was 32-bit without thinking too much! > > > Andrew Hi Andrew, Thanks for your answer. Is it possible to fix it? Thanks, Christian > > >> >> Cheers, >> Christian >> >>> On 13. Oct 2022, at 09:28, Christophe Leroy < >>> christophe.le...@csgroup.eu> wrote: >>> >>> >>> >>>>> Le 13/10/2022 à 09:03, Christian Zigotzky a écrit : >>>>> Hi Andrew, >>>>> >>>>> Does this patch also affect 64-bit kernels? >>>>> >>>>> We use often 32-bit userlands with 64-bit kernels. >>> >>> As far as I understand, it was already correct for 32-bit userlands >>> with >>> 64 bit kernels, aka compat. >>> >>> The patch applies the same approach for 32 bit kernels, as >>> explained in >>> the commit message : "Fix this by having 32-bit kernels share those >>> syscall definitions with compat." >>> >>> Christophe >>> >>>> >>>> Cheers, >>>> Christian >>>> >>>>>> On 12. Oct 2022, at 09:56, Andrew Donnellan < >>>>>> a...@linux.ibm.com> wrote: >>>>> >>>>> On Wed, 2022-10-12 at 08:51 +0200, Christian Zigotzky wrote: >>>>>> Hi All, >>>>>> >>>>>> I use the Nemo board with a PASemi PA6T CPU and have some >>>>>> issues >>>>>> since the first PowerPC updates for the kernel 6.1. >>>>>> >>>>>> I successfully compiled the git kernel with the first PowerPC >>>>>> updates >>>>>> two days ago. >>>>>> >>>>>> Unfortunately this kernel is really dangerous. Many things >>>>>> for >>>>>> example Network Manager and LightDM don't work anymore and >>>>>> produced >>>>>> several gigabyte of config files till the partition has been >>>>>> filled. >>>>>> >>>>>> I deleted some files like the resolv.conf that had a size >>>>>> over 200 >>>>>> GB! >>>>>> >>>>>> Unfortunately, MintPPC was still damaged. For example LightDM >>>>>> doesn't >>>>>> work anymore and the MATE desktop doesn't display any icons >>>>>> anymore >>>>>> because Caja wasn't able to reserve memory anymore. >>>>>> >>>>>> In this case, bisecting isn't an option and I have to wait >>>>>> some >>>>>> weeks. It is really difficult to find the issue if the >>>>>> userland will >>>>>> damaged again and again. >>>>> >>>>> Could you try with >>>>> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20221012035335.866440-1-npig...@gmail.com/ >>>>> to see if your issues are related to that? >>>>> >>>>> Andrew >>>>> >>>>> -- >>>>> Andrew DonnellanOzLabs, ADL Canberra >>>>> a...@linux.ibm.com IBM Australia Limited >>>>> >> > > -- > Andrew DonnellanOzLabs, ADL Canberra > a...@linux.ibm.com IBM Australia Limited >
Re: Issues with the first PowerPC updates for the kernel 6.1
Edit: fixed typos. > On 13. Oct 2022, at 11:42, Christian Zigotzky wrote: > > Hi Christophe, > > Thanks a lot for your answer. OK, now, I know, that I don’t need to test it. > After the boot of the latest git kernel, my system was extremely damaged. > Some config files have a size of several gigabytes for example the > resolv.conf. I tried to repair this Debian system but without any success. > I copied with dd and Netcat via network another rootfs from another computer > to the damaged partition. > I don’t have the time to do it always again and again after a bad bisect > result. > I will wait some weeks and try it again. > > Cheers, > Christian > >> On 13. Oct 2022, at 09:28, Christophe Leroy >> wrote: >> >> >> >>>> Le 13/10/2022 à 09:03, Christian Zigotzky a écrit : >>> Hi Andrew, >>> >>> Does this patch also affect 64-bit kernels? >>> >>> We use often 32-bit userlands with 64-bit kernels. >> >> As far as I understand, it was already correct for 32-bit userlands with >> 64 bit kernels, aka compat. >> >> The patch applies the same approach for 32 bit kernels, as explained in >> the commit message : "Fix this by having 32-bit kernels share those >> syscall definitions with compat." >> >> Christophe >> >>> >>> Cheers, >>> Christian >>> >>>>> On 12. Oct 2022, at 09:56, Andrew Donnellan wrote: >>>> >>>> On Wed, 2022-10-12 at 08:51 +0200, Christian Zigotzky wrote: >>>>> Hi All, >>>>> >>>>> I use the Nemo board with a PASemi PA6T CPU and have some issues >>>>> since the first PowerPC updates for the kernel 6.1. >>>>> >>>>> I successfully compiled the git kernel with the first PowerPC updates >>>>> two days ago. >>>>> >>>>> Unfortunately this kernel is really dangerous. Many things for >>>>> example Network Manager and LightDM don't work anymore and produced >>>>> several gigabyte of config files till the partition has been filled. >>>>> >>>>> I deleted some files like the resolv.conf that had a size over 200 >>>>> GB! >>>>> >>>>> Unfortunately, MintPPC was still damaged. For example LightDM doesn't >>>>> work anymore and the MATE desktop doesn't display any icons anymore >>>>> because Caja wasn't able to reserve memory anymore. >>>>> >>>>> In this case, bisecting isn't an option and I have to wait some >>>>> weeks. It is really difficult to find the issue if the userland will >>>>> damaged again and again. >>>> >>>> Could you try with >>>> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20221012035335.866440-1-npig...@gmail.com/ >>>> to see if your issues are related to that? >>>> >>>> Andrew >>>> >>>> -- >>>> Andrew DonnellanOzLabs, ADL Canberra >>>> a...@linux.ibm.com IBM Australia Limited >>>> >
Re: Issues with the first PowerPC updates for the kernel 6.1
Hi Christophe, Thanks a lot for your answer. OK, now, I know, that I don’t need to test it. After the boot of the latest git kernel, my system was extremely damaged. Some config files has a size of several gigabytes for example the resolv.conf. I tried to repair this Debian system but without any success. I copied with dd and Netcat via network another rootfs from another computer to the damaged partition. I don’t have the time to do it always again and again after a bad bisect result. I will wait some weeks and try it again. Cheers, Christian > On 13. Oct 2022, at 09:28, Christophe Leroy > wrote: > > > >> Le 13/10/2022 à 09:03, Christian Zigotzky a écrit : >> Hi Andrew, >> >> Does this patch also affect 64-bit kernels? >> >> We use often 32-bit userlands with 64-bit kernels. > > As far as I understand, it was already correct for 32-bit userlands with > 64 bit kernels, aka compat. > > The patch applies the same approach for 32 bit kernels, as explained in > the commit message : "Fix this by having 32-bit kernels share those > syscall definitions with compat." > > Christophe > >> >> Cheers, >> Christian >> >>>> On 12. Oct 2022, at 09:56, Andrew Donnellan wrote: >>> >>> On Wed, 2022-10-12 at 08:51 +0200, Christian Zigotzky wrote: >>>> Hi All, >>>> >>>> I use the Nemo board with a PASemi PA6T CPU and have some issues >>>> since the first PowerPC updates for the kernel 6.1. >>>> >>>> I successfully compiled the git kernel with the first PowerPC updates >>>> two days ago. >>>> >>>> Unfortunately this kernel is really dangerous. Many things for >>>> example Network Manager and LightDM don't work anymore and produced >>>> several gigabyte of config files till the partition has been filled. >>>> >>>> I deleted some files like the resolv.conf that had a size over 200 >>>> GB! >>>> >>>> Unfortunately, MintPPC was still damaged. For example LightDM doesn't >>>> work anymore and the MATE desktop doesn't display any icons anymore >>>> because Caja wasn't able to reserve memory anymore. >>>> >>>> In this case, bisecting isn't an option and I have to wait some >>>> weeks. It is really difficult to find the issue if the userland will >>>> damaged again and again. >>> >>> Could you try with >>> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20221012035335.866440-1-npig...@gmail.com/ >>> to see if your issues are related to that? >>> >>> Andrew >>> >>> -- >>> Andrew DonnellanOzLabs, ADL Canberra >>> a...@linux.ibm.com IBM Australia Limited >>>
Re: Issues with the first PowerPC updates for the kernel 6.1
Hi Andrew, Does this patch also affect 64-bit kernels? We use often 32-bit userlands with 64-bit kernels. Cheers, Christian > On 12. Oct 2022, at 09:56, Andrew Donnellan wrote: > > On Wed, 2022-10-12 at 08:51 +0200, Christian Zigotzky wrote: >> Hi All, >> >> I use the Nemo board with a PASemi PA6T CPU and have some issues >> since the first PowerPC updates for the kernel 6.1. >> >> I successfully compiled the git kernel with the first PowerPC updates >> two days ago. >> >> Unfortunately this kernel is really dangerous. Many things for >> example Network Manager and LightDM don't work anymore and produced >> several gigabyte of config files till the partition has been filled. >> >> I deleted some files like the resolv.conf that had a size over 200 >> GB! >> >> Unfortunately, MintPPC was still damaged. For example LightDM doesn't >> work anymore and the MATE desktop doesn't display any icons anymore >> because Caja wasn't able to reserve memory anymore. >> >> In this case, bisecting isn't an option and I have to wait some >> weeks. It is really difficult to find the issue if the userland will >> damaged again and again. > > Could you try with > https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20221012035335.866440-1-npig...@gmail.com/ > to see if your issues are related to that? > > Andrew > > -- > Andrew DonnellanOzLabs, ADL Canberra > a...@linux.ibm.com IBM Australia Limited >
Issues with the first PowerPC updates for the kernel 6.1
Hi All, I use the Nemo board with a PASemi PA6T CPU and have some issues since the first PowerPC updates for the kernel 6.1. I successfully compiled the git kernel with the first PowerPC updates two days ago. Unfortunately this kernel is really dangerous. Many things for example Network Manager and LightDM don't work anymore and produced several gigabyte of config files till the partition has been filled. I deleted some files like the resolv.conf that had a size over 200 GB! Unfortunately, MintPPC was still damaged. For example LightDM doesn't work anymore and the MATE desktop doesn't display any icons anymore because Caja wasn't able to reserve memory anymore. In this case, bisecting isn't an option and I have to wait some weeks. It is really difficult to find the issue if the userland will damaged again and again. Cheers, Christian
Re: [PATCH v2] i2c/pasemi: PASemi I2C controller IRQ enablement
mbus)
return 0;
}
+
+irqreturn_t pasemi_irq_handler(int irq, void *dev_id)
+{
+ struct pasemi_smbus *smbus = dev_id;
+
+ complete(&smbus->irq_completion);
+ return IRQ_HANDLED;
+}
diff --git a/drivers/i2c/busses/i2c-pasemi-core.h
b/drivers/i2c/busses/i2c-pasemi-core.h
index 4655124a37f3..ba6d6ccf9cdc 100644
--- a/drivers/i2c/busses/i2c-pasemi-core.h
+++ b/drivers/i2c/busses/i2c-pasemi-core.h
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#define PASEMI_HW_REV_PCI -1
@@ -15,7 +16,11 @@ struct pasemi_smbus {
struct i2c_adapter adapter;
void __iomem*ioaddr;
unsigned int clk_div;
- int hw_rev;
+ int hw_rev;
+ int use_irq;
+ struct completionirq_completion;
};
int pasemi_i2c_common_probe(struct pasemi_smbus *smbus);
+
+irqreturn_t pasemi_irq_handler(int irq, void *dev_id);
diff --git a/drivers/i2c/busses/i2c-pasemi-platform.c
b/drivers/i2c/busses/i2c-pasemi-platform.c
index 88a54aaf7e3c..e35945a91dbe 100644
--- a/drivers/i2c/busses/i2c-pasemi-platform.c
+++ b/drivers/i2c/busses/i2c-pasemi-platform.c
@@ -49,6 +49,7 @@ static int pasemi_platform_i2c_probe(struct platform_device
*pdev)
struct pasemi_smbus *smbus;
u32 frequency;
int error;
+ int irq_num;
data = devm_kzalloc(dev, sizeof(struct pasemi_platform_i2c_data),
GFP_KERNEL);
@@ -82,6 +83,11 @@ static int pasemi_platform_i2c_probe(struct platform_device
*pdev)
if (error)
goto out_clk_disable;
+ irq_num = platform_get_irq(pdev, 0);
+ error = devm_request_irq(smbus->dev, irq_num, pasemi_irq_handler, 0,
"pasemi_apple_i2c", (void *)smbus);
+
+ if (!error)
+ smbus->use_irq = 1;
platform_set_drvdata(pdev, data);
return 0;
Tested-by: Christian Zigotzky
on an A-EON AmigaOne X1000 with a PASemi PWRficient PA6T-1682 processor.
Bug in the VirtIO GPU driver since the RC7 of kernel 6.0
Hi All, I have found the issue. I cross compiled this kernel with GCC 11.2.0 on Ubuntu 22.04.1. I cross compiled the same kernel with GCC 9.4.0 again. This time on Ubuntu 20.04.5. KVM with the VirtIO GPU works with the GCC 9.4.0 compiled kernel. — Christian I wrote: Hello, Xorg doesn't start anymore in a virtual e5500 QEMU KVM HV machine with the VirtIO GPU [1] since the RC7 of kernel 6.0. [2] Please find attached the kernel config. Thanks, Christian [1] qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage-6.0 -drive format=raw,file=void-live-powerpc-20220129.img,index=0,if=virtio -netdev user,id=mynet0 -device virtio-net,netdev=mynet0 -append "rw root=/dev/vda2" -device virtio-gpu -device virtio-mouse-pci -device virtio-keyboard-pci -device pci-ohci,id=newusb -audiodev id=sndbe,driver=pa,server=/run/user/1000/pulse/native -device usb-audio,bus=newusb.0 -enable-kvm -smp 4 -fsdev local,security_model=passthrough,id=fsdev0,path=/home/amigaone/Music -device virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=hostshare [2] Error messages in a virtual Void PPC machine: [drm] pci: virtio-gpu-pci detected at :00:02.0 [drm] features: -virgl +edid -resource_blob -host_visible [drm] features: -context_init [drm] number of scanouts: 1 [drm] number of cap sets: 0 [drm] Initialized virtio_gpu 0.1.0 0 for virtio1 on minor 0 BUG: Kernel NULL pointer dereference on read at 0x Faulting instruction address: 0xc00c9934 Oops: Kernel access of bad area, sig: 11 [#1] BE PAGE_SIZE=4K SMP NR_CPUS=4 QEMU e500 Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc7_A-EON_X5000 #1 NIP: c00c9934 LR: c00c9f58 CTR: REGS: c208ab20 TRAP: 0300 Not tainted (6.0.0-rc7_A-EON_X5000) MSR: 90029002 CR: 84008242 XER: DEAR: ESR: IRQMASK: 0 GPR00: c06f0060 c208adc0 c1ac3500 c25f0010 GPR04: c19908b0 GPR08: 0105 0180 GPR12: 24008242 c0003fff9500 c0001384 GPR16: GPR20: c169021f c208b088 GPR24: c2336800 GPR28: c2a48000 c2336800 c25f0010 NIP [c00c9934] .dma_map_direct+0x8/0x10 LR [c00c9f58] .dma_max_mapping_size+0x24/0x78 Call Trace: [c208adc0] [c208ae80] 0xc208ae80 (unreliable) [c208ae40] [c06f0060] .drm_prime_pages_to_sg+0xa0/0xb8 [c208aed0] [c070f96c] .drm_gem_shmem_get_sg_table+0x28/0x3c [c208af40] [c0808c8c] .virtio_gpu_object_create+0x134/0x3a8 [c208b010] [c0804c34] .virtio_gpu_mode_dumb_create+0xe4/0x15c [c208b110] [c06ff7f4] .drm_mode_create_dumb+0xcc/0xec [c208b180] [c0707748] .drm_client_framebuffer_create+0x98/0x1f0 [c208b260] [c071fb6c] .drm_fb_helper_generic_probe+0x78/0x1a0 [c208b320] [c071ef08] .__drm_fb_helper_initial_config_and_unlock+0x428/0x54c [c208b410] [c071f9dc] .drm_fbdev_client_hotplug+0xec/0x128 [c208b4a0] [c071fdec] .drm_fbdev_generic_setup+0x158/0x198 [c208b530] [c0803dc4] .virtio_gpu_probe+0x1ac/0x1e0 [c208b5f0] [c069e11c] .virtio_dev_probe+0x2d0/0x3d4 [c208b690] [c0815f34] .really_probe+0x1a0/0x344 [c208b720] [c08161c8] .__driver_probe_device+0xf0/0x100 [c208b7b0] [c081620c] .driver_probe_device+0x34/0xac [c208b840] [c0816774] .__driver_attach+0x124/0x134 [c208b8d0] [c0813974] .bus_for_each_dev+0x8c/0xd0 [c208b980] [c08154a4] .driver_attach+0x24/0x38 [c208b9f0] [c0814dd4] .bus_add_driver+0xd8/0x210 [c208baa0] [c0816fd4] .driver_register+0xe0/0x134 [c208bb20] [c069d8a8] .register_virtio_driver+0x40/0x54 hrtimer: interrupt took 4631040 ns [c208bb90] [c195] .virtio_gpu_driver_init+0x18/0x2c [c208bc00] [c0001044] .do_one_initcall+0x7c/0x1c0 [c208bce0] [c1925710] .kernel_init_freeable+0x23c/0x240 [c208bd90] [c00013ac] .kernel_init+0x28/0x14c [c208be10] [c5a0] .ret_from_kernel_thread+0x58/0x60 Instruction dump: 3921 7c23f840 38210080 7d20485e 792307e0 48d551d8 7c9f2378 4bdc 792307e0 4e800020 e92301f8 7c852378 4b7c 7c0802a6 28060003 ---[ end trace ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b Rebooting in 180 seconds..
Re: PASEMI: Wrong lscpu info since the RC1 of kernel 6.0
Just for info: The values have been fine again since the RC7 of kernel 6.0. — Christian > On 7. Sep 2022, at 06:25, Christian Zigotzky wrote: > > Hi All, > > I use the Nemo board with a PASemi PA6T CPU and some values of lscpu are > wrong since the RC1 of kernel 6.0. > > ┌──(mintppc㉿mintppc)-[~] > └─$ lscpu > Architecture:ppc64 > CPU op-mode(s): 32-bit, 64-bit > Byte Order: Big Endian > CPU(s): 2 > On-line CPU(s) list: 0,1 > Thread(s) per core: 2 > Core(s) per socket: 1 > Socket(s): 1 > Model: 1.2 (pvr 0090 0102) > Model name: PA6T, altivec supported > L1d cache: 64 KiB > L1i cache: 64 KiB > Vulnerability Itlb multihit: Not affected > Vulnerability L1tf: Vulnerable > Vulnerability Mds: Not affected > Vulnerability Meltdown: Vulnerable > Vulnerability Mmio stale data: Not affected > Vulnerability Retbleed: Not affected > Vulnerability Spec store bypass: Vulnerable > Vulnerability Spectre v1:Mitigation; __user pointer sanitization > Vulnerability Spectre v2:Vulnerable > Vulnerability Srbds: Not affected > Vulnerability Tsx async abort: Not affected > > —- > > One core with 2 threads is wrong. Two cores are correct. Each core has one > thread. > > Have you modified the detection of the CPU? > > Thanks, > Christian
PASEMI: Wrong lscpu info since the RC1 of kernel 6.0
Hi All, I use the Nemo board with a PASemi PA6T CPU and some values of lscpu are wrong since the RC1 of kernel 6.0. ┌──(mintppc㉿mintppc)-[~] └─$ lscpu Architecture:ppc64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Big Endian CPU(s): 2 On-line CPU(s) list: 0,1 Thread(s) per core: 2 Core(s) per socket: 1 Socket(s): 1 Model: 1.2 (pvr 0090 0102) Model name: PA6T, altivec supported L1d cache: 64 KiB L1i cache: 64 KiB Vulnerability Itlb multihit: Not affected Vulnerability L1tf: Vulnerable Vulnerability Mds: Not affected Vulnerability Meltdown: Vulnerable Vulnerability Mmio stale data: Not affected Vulnerability Retbleed: Not affected Vulnerability Spec store bypass: Vulnerable Vulnerability Spectre v1:Mitigation; __user pointer sanitization Vulnerability Spectre v2:Vulnerable Vulnerability Srbds: Not affected Vulnerability Tsx async abort: Not affected —- One core with 2 threads is wrong. Two cores are correct. Each core has one thread. Have you modified the detection of the CPU? Thanks, Christian
Re: [PATCH] i2c: pasemi: Add IRQ support for Apple Silicon
On 23 August 2022 at 03:50 am, Michael Ellerman wrote: Arminder Singh writes: This is the first time I'm interacting with the Linux mailing lists, so please don't eviscerate me *too much* if I get the formatting wrong. Of course I'm always willing to take criticism and improve my formatting in the future. This patch adds support for IRQs to the PASemi I2C controller driver. This will allow for faster performing I2C transactions on Apple Silicon hardware, as previously, the driver was forced to poll the SMSTA register for a set amount of time. With this patchset the driver on Apple silicon hardware will instead wait for an interrupt which will signal the completion of the I2C transaction. The timeout value for this completion will be the same as the current amount of time the I2C driver polls for. This will result in some performance improvement since the driver will be waiting for less time than it does right now on Apple Silicon hardware. The patch right now will only enable IRQs for Apple Silicon I2C chips, and only if it's able to successfully request the IRQ from the kernel. === Testing === This patch has been tested on both the mainline Linux kernel tree and the Asahi branch (https://github.com/AsahiLinux/linux.git) on both an M1 and M2 MacBook Air, and it compiles successfully as both a module and built-in to the kernel itself. The patch in both trees successfully boots to userspace without any hitch. I do not have PASemi hardware on hand unfortunately, so I'm unable to test the impact of this patch on old PASemi hardware. This is also why I've elected to do the IRQ request and enablement on the Apple platform driver and not in the common file, as I'm not sure if PASemi hardware supports IRQs. I've added Darren and Christian to Cc, they have helped with PASemi development and testing in the past, and may be able to help test this series on PASemi hardware. cheers Tested-by: Christian Zigotzky on an A-EON AmigaOne X1000 with a PASemi PWRficient PA6T-1682 processor.
Re: [PATCH 2/2] kvm: rename KVM_MAX_VCPU_ID to, KVM_MAX_VCPU_IDS
On 14 September 2021 at 05:59 pm, Christian Zigotzky wrote: Hello Juergen, Hello All, Since the RC1 of kernel 5.13, -smp 2 and -smp 4 don't work with a virtual e5500 QEMU KVM-HV machine anymore. [1] I see in the serial console, that the uImage doesn't load. I use the following QEMU command for booting: qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 1024 -kernel uImage -drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev user,id=mynet0 -device virtio-net,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-vga -device virtio-mouse-pci -device virtio-keyboard-pci -device pci-ohci,id=newusb -device usb-audio,bus=newusb.0 -smp 4 The kernels boot without KVM-HV. Summary for KVM-HV: -smp 1 -> works -smp 2 -> doesn't work -smp 3 -> works -smp 4 -> doesn't work I used -smp 4 before the RC1 of kernel 5.13 because my FSL P5040 BookE machine [2] has 4 cores. Does this patch solve this issue? [3] Thanks, Christian [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-May/229103.html [2] http://wiki.amiga.org/index.php?title=X5000 [3] https://lists.ozlabs.org/pipermail/linuxppc-dev/2021-September/234152.html Hello, Since the RC5 of kernel 5.19, -smp 2 and -smp 4 work again. I don't know which patch has solved the issue. Cheers, Christian
Re: [PATCH v3] drivers/usb/host/ehci-fsl: Fix interrupt setup in host mode.
On 02 July 2022 at 11:03 pm, Darren Stevens wrote:
In patch a1a2b7125e10 (Drop static setup of IRQ resource from DT
core) we stopped platform_get_resource() from returning the IRQ, as all
drivers were supposed to have switched to platform_get_irq()
Unfortunately the Freescale EHCI driver in host mode got missed. Fix
it.
Fixes: a1a2b7125e10 (Drop static setup of IRQ resource from DT core)
Reported-by: Christian Zigotzky
Suggested-by: Rob Herring
Signed-off-by: Darren Stevens
---
v3 - Corrected resource allocation in fsl-mph-dr-of.c
v2 - Fixed coding style, removed a couple of unneeded initializations,
cc'd Layerscape maintainers.
Tested on AmigaOne X5000/20 and X5000/40 Contains code by Rob Herring
(in fsl-mph-dr-of.c)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 385be30..896c0d1 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -76,14 +76,9 @@ static int fsl_ehci_drv_probe(struct platform_device *pdev)
return -ENODEV;
}
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (!res) {
- dev_err(&pdev->dev,
- "Found HC with no IRQ. Check %s setup!\n",
- dev_name(&pdev->dev));
- return -ENODEV;
- }
- irq = res->start;
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0)
+ return irq;
hcd = __usb_create_hcd(&fsl_ehci_hc_driver, pdev->dev.parent,
&pdev->dev, dev_name(&pdev->dev), NULL);
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 44a7e58..e5df175 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -112,6 +112,9 @@ static struct platform_device *fsl_usb2_device_register(
goto error;
}
+ pdev->dev.of_node = ofdev->dev.of_node;
+ pdev->dev.of_node_reused = true;
+
retval = platform_device_add(pdev);
if (retval)
goto error;
Hello,
I patched the RC5 of kernel 5.19 with this patch and I can confirm, that
my keyboard and mouse work without any problems.
Tested-by: Christian Zigotzky
Please accept this patch.
Thanks,
Christian
Re: [FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19
On 13 June 2022 at 05:57 pm, Rob Herring wrote:
On Thu, Jun 9, 2022 at 12:03 PM Christian Zigotzky
wrote:
On 06 June 2022 at 07:06 pm, Rob Herring wrote:
On Mon, Jun 6, 2022 at 11:14 AM Christian Zigotzky
wrote:
On 06 June 2022 at 04:58 pm, Rob Herring wrote:
On Fri, May 27, 2022 at 9:23 AM Rob Herring wrote:
On Fri, May 27, 2022 at 3:33 AM Christian Zigotzky
wrote:
On 27 May 2022 at 10:14 am, Prabhakar Mahadev Lad wrote:
Hi,
-Original Message-
From: Christian Zigotzky
On 27 May 2022 at 09:56 am, Prabhakar Mahadev Lad wrote:
Hi,
-Original Message-
From: Christophe Leroy
[...]
Looks like the driver which you are using has not been converted to use
platform_get_irq(), could you please check that.
Cheers,
Prabhakar
Do you mean the mouse and keyboard driver?
No it could be your gpio/pinctrl driver assuming the keyboard/mouse are using
GPIO's. If you are using interrupts then it might be some hierarchal irqc
driver in drivers/irqchip/.
Cheers,
Prabhakar
Good to know. I only use unmodified drivers from the official Linux
kernel so it's not an issue of the Cyrus+ board.
The issue is in drivers/usb/host/fsl-mph-dr-of.c which copies the
resources to a child platform device. Can you try the following
change:
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 44a7e58a26e3..47d9b7be60da 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -80,8 +80,6 @@ static struct platform_device *fsl_usb2_device_register(
const char *name, int id)
{
struct platform_device *pdev;
- const struct resource *res = ofdev->resource;
- unsigned int num = ofdev->num_resources;
int retval;
pdev = platform_device_alloc(name, id);
@@ -106,11 +104,7 @@ static struct platform_device *fsl_usb2_device_register(
if (retval)
goto error;
- if (num) {
- retval = platform_device_add_resources(pdev, res, num);
- if (retval)
- goto error;
- }
+ pdev->dev.of_node = ofdev->dev.of_node;
>From the log, I think you also need to add this line:
pdev->dev.of_node_reused = true;
retval = platform_device_add(pdev);
if (retval)
Hello Rob,
Thanks a lot for your answer.
Is the following patch correct?
Yes
--- a/drivers/usb/host/fsl-mph-dr-of.c2022-05-28 09:10:26.797688422
+0200
+++ b/drivers/usb/host/fsl-mph-dr-of.c2022-05-28 09:15:01.668594809
+0200
@@ -80,8 +80,6 @@ static struct platform_device *fsl_usb2_
const char *name, int id)
{
struct platform_device *pdev;
-const struct resource *res = ofdev->resource;
-unsigned int num = ofdev->num_resources;
int retval;
pdev = platform_device_alloc(name, id);
@@ -106,11 +104,7 @@ static struct platform_device *fsl_usb2_
if (retval)
goto error;
-if (num) {
-retval = platform_device_add_resources(pdev, res, num);
-if (retval)
-goto error;
-}
+pdev->dev.of_node = ofdev->dev.of_node;
+pdev->dev.of_node_reused = true;
retval = platform_device_add(pdev);
if (retval)
---
Thanks,
Christian
Hello Rob,
I tested this patch today and unfortunately the issue still exists.
The log is the same?
Rob
Yes, it's the same.
Link: http://www.xenosoft.de/dmesg_FSL_P5040_Void_PPC-2.txt
-- Christian
[FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19
On 06 June 2022 at 07:06 pm, Rob Herring wrote:
On Mon, Jun 6, 2022 at 11:14 AM Christian Zigotzky
wrote:
On 06 June 2022 at 04:58 pm, Rob Herring wrote:
On Fri, May 27, 2022 at 9:23 AM Rob Herring wrote:
On Fri, May 27, 2022 at 3:33 AM Christian Zigotzky
wrote:
On 27 May 2022 at 10:14 am, Prabhakar Mahadev Lad wrote:
Hi,
-Original Message-
From: Christian Zigotzky
On 27 May 2022 at 09:56 am, Prabhakar Mahadev Lad wrote:
Hi,
-Original Message-
From: Christophe Leroy
[...]
Looks like the driver which you are using has not been converted to use
platform_get_irq(), could you please check that.
Cheers,
Prabhakar
Do you mean the mouse and keyboard driver?
No it could be your gpio/pinctrl driver assuming the keyboard/mouse are using
GPIO's. If you are using interrupts then it might be some hierarchal irqc
driver in drivers/irqchip/.
Cheers,
Prabhakar
Good to know. I only use unmodified drivers from the official Linux
kernel so it's not an issue of the Cyrus+ board.
The issue is in drivers/usb/host/fsl-mph-dr-of.c which copies the
resources to a child platform device. Can you try the following
change:
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 44a7e58a26e3..47d9b7be60da 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -80,8 +80,6 @@ static struct platform_device *fsl_usb2_device_register(
const char *name, int id)
{
struct platform_device *pdev;
- const struct resource *res = ofdev->resource;
- unsigned int num = ofdev->num_resources;
int retval;
pdev = platform_device_alloc(name, id);
@@ -106,11 +104,7 @@ static struct platform_device *fsl_usb2_device_register(
if (retval)
goto error;
- if (num) {
- retval = platform_device_add_resources(pdev, res, num);
- if (retval)
- goto error;
- }
+ pdev->dev.of_node = ofdev->dev.of_node;
>From the log, I think you also need to add this line:
pdev->dev.of_node_reused = true;
retval = platform_device_add(pdev);
if (retval)
Hello Rob,
Thanks a lot for your answer.
Is the following patch correct?
Yes
--- a/drivers/usb/host/fsl-mph-dr-of.c2022-05-28 09:10:26.797688422
+0200
+++ b/drivers/usb/host/fsl-mph-dr-of.c2022-05-28 09:15:01.668594809
+0200
@@ -80,8 +80,6 @@ static struct platform_device *fsl_usb2_
const char *name, int id)
{
struct platform_device *pdev;
-const struct resource *res = ofdev->resource;
-unsigned int num = ofdev->num_resources;
int retval;
pdev = platform_device_alloc(name, id);
@@ -106,11 +104,7 @@ static struct platform_device *fsl_usb2_
if (retval)
goto error;
-if (num) {
-retval = platform_device_add_resources(pdev, res, num);
-if (retval)
-goto error;
-}
+pdev->dev.of_node = ofdev->dev.of_node;
+pdev->dev.of_node_reused = true;
retval = platform_device_add(pdev);
if (retval)
---
Thanks,
Christian
Hello Rob,
I tested this patch today and unfortunately the issue still exists.
Do you have another idea?
Thanks,
Christian
Updated patch:
--- a/drivers/usb/host/fsl-mph-dr-of.c 2022-06-06 02:18:54.0 +0200
+++ b/drivers/usb/host/fsl-mph-dr-of.c 2022-06-09 19:31:50.135472793 +0200
@@ -80,8 +80,6 @@ static struct platform_device *fsl_usb2_
const char *name, int id)
{
struct platform_device *pdev;
- const struct resource *res = ofdev->resource;
- unsigned int num = ofdev->num_resources;
int retval;
pdev = platform_device_alloc(name, id);
@@ -105,12 +103,8 @@ static struct platform_device *fsl_usb2_
retval = platform_device_add_data(pdev, pdata, sizeof(*pdata));
if (retval)
goto error;
-
- if (num) {
- retval = platform_device_add_resources(pdev, res, num);
- if (retval)
- goto error;
- }
+ pdev->dev.of_node = ofdev->dev.of_node;
+ pdev->dev.of_node_reused = true;
retval = platform_device_add(pdev);
if (retval)
[FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19
On 06 June 2022 at 04:58 pm, Rob Herring wrote:
On Fri, May 27, 2022 at 9:23 AM Rob Herring wrote:
On Fri, May 27, 2022 at 3:33 AM Christian Zigotzky
wrote:
On 27 May 2022 at 10:14 am, Prabhakar Mahadev Lad wrote:
Hi,
-Original Message-
From: Christian Zigotzky
On 27 May 2022 at 09:56 am, Prabhakar Mahadev Lad wrote:
Hi,
-Original Message-
From: Christophe Leroy
[...]
Looks like the driver which you are using has not been converted to use
platform_get_irq(), could you please check that.
Cheers,
Prabhakar
Do you mean the mouse and keyboard driver?
No it could be your gpio/pinctrl driver assuming the keyboard/mouse are using
GPIO's. If you are using interrupts then it might be some hierarchal irqc
driver in drivers/irqchip/.
Cheers,
Prabhakar
Good to know. I only use unmodified drivers from the official Linux
kernel so it's not an issue of the Cyrus+ board.
The issue is in drivers/usb/host/fsl-mph-dr-of.c which copies the
resources to a child platform device. Can you try the following
change:
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 44a7e58a26e3..47d9b7be60da 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -80,8 +80,6 @@ static struct platform_device *fsl_usb2_device_register(
const char *name, int id)
{
struct platform_device *pdev;
- const struct resource *res = ofdev->resource;
- unsigned int num = ofdev->num_resources;
int retval;
pdev = platform_device_alloc(name, id);
@@ -106,11 +104,7 @@ static struct platform_device *fsl_usb2_device_register(
if (retval)
goto error;
- if (num) {
- retval = platform_device_add_resources(pdev, res, num);
- if (retval)
- goto error;
- }
+ pdev->dev.of_node = ofdev->dev.of_node;
>From the log, I think you also need to add this line:
pdev->dev.of_node_reused = true;
retval = platform_device_add(pdev);
if (retval)
Hello Rob,
Thanks a lot for your answer.
Is the following patch correct?
--- a/drivers/usb/host/fsl-mph-dr-of.c 2022-05-28 09:10:26.797688422
+0200
+++ b/drivers/usb/host/fsl-mph-dr-of.c 2022-05-28 09:15:01.668594809
+0200
@@ -80,8 +80,6 @@ static struct platform_device *fsl_usb2_
const char *name, int id)
{
struct platform_device *pdev;
- const struct resource *res = ofdev->resource;
- unsigned int num = ofdev->num_resources;
int retval;
pdev = platform_device_alloc(name, id);
@@ -106,11 +104,7 @@ static struct platform_device *fsl_usb2_
if (retval)
goto error;
- if (num) {
- retval = platform_device_add_resources(pdev, res, num);
- if (retval)
- goto error;
- }
+ pdev->dev.of_node = ofdev->dev.of_node;
+ pdev->dev.of_node_reused = true;
retval = platform_device_add(pdev);
if (retval)
---
Thanks,
Christian
Re: [FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19
On 27 May 2022 at 03:40 pm, Darren Stevens wrote:
> Hi Christian,
>
> Can you send me the full dmesg output from this failed boot? I looked
but can't seem to find which component is at fault here
>
> Thanks
> Darren
On 01 June 2022 at 02:35 pm, Rob Herring wrote:
On Tue, May 31, 2022 at 06:29:38PM +0200, Christian Zigotzky wrote:
On 31. May 2022, at 15:46, Rob Herring wrote:
On Mon, May 30, 2022 at 12:26 AM Christian Zigotzky
wrote:
On 27 May 2022 at 04:23 pm, Rob Herring wrote:
The issue is in drivers/usb/host/fsl-mph-dr-of.c which copies the
resources to a child platform device. Can you try the following
change:
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 44a7e58a26e3..47d9b7be60da 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -80,8 +80,6 @@ static struct platform_device *fsl_usb2_device_register(
const char *name, int id)
{
struct platform_device *pdev;
- const struct resource *res = ofdev->resource;
- unsigned int num = ofdev->num_resources;
int retval;
pdev = platform_device_alloc(name, id);
@@ -106,11 +104,7 @@ static struct platform_device *fsl_usb2_device_register(
if (retval)
goto error;
- if (num) {
- retval = platform_device_add_resources(pdev, res, num);
- if (retval)
- goto error;
- }
+ pdev->dev.of_node = ofdev->dev.of_node;
retval = platform_device_add(pdev);
if (retval)
Hello Rob,
Thanks a lot for your patch! Unfortunately, this leads to a boot loop.
Do you have another idea?
Do you have a dmesg log?
From the boot loop?
Yes.
The other way to fix is creating a IRQ resource and adding it to the
child device resources.
Good idea.
Not really. I'd rather have the child device just point to the DT node,
but that doesn't seem to work for some drivers and I want to understand
why.
Rob
Hello Rob,
Hello Darren,
The keyboard and mouse issue still exists in the latest git kernel.
Here are the logs:
- http://www.xenosoft.de/dmesg_FSL_P5040_Void_PPC.txt
- http://www.xenosoft.de/dmesg_FSL_P5040_MintPPC.txt
- http://www.xenosoft.de/dmesg_FSL_P5040_Void_PPC_with_Robs_patch.txt
Thanks,
Christian
Re: [FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19
On 31. May 2022, at 15:46, Rob Herring wrote: Do you have a dmesg log? The other way to fix is creating a IRQ resource and adding it to the child device resources. Rob —— Rob, Do you mean a dmesg from the boot loop? The other way is a good idea. Cheers, Christian
Re: [FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19
> On 31. May 2022, at 15:46, Rob Herring wrote:
>
> On Mon, May 30, 2022 at 12:26 AM Christian Zigotzky
> wrote:
>>
>>> On 27 May 2022 at 04:23 pm, Rob Herring wrote:
>>> The issue is in drivers/usb/host/fsl-mph-dr-of.c which copies the
>>> resources to a child platform device. Can you try the following
>>> change:
>>>
>>> diff --git a/drivers/usb/host/fsl-mph-dr-of.c
>>> b/drivers/usb/host/fsl-mph-dr-of.c
>>> index 44a7e58a26e3..47d9b7be60da 100644
>>> --- a/drivers/usb/host/fsl-mph-dr-of.c
>>> +++ b/drivers/usb/host/fsl-mph-dr-of.c
>>> @@ -80,8 +80,6 @@ static struct platform_device *fsl_usb2_device_register(
>>> const char *name, int id)
>>> {
>>> struct platform_device *pdev;
>>> - const struct resource *res = ofdev->resource;
>>> - unsigned int num = ofdev->num_resources;
>>> int retval;
>>>
>>> pdev = platform_device_alloc(name, id);
>>> @@ -106,11 +104,7 @@ static struct platform_device
>>> *fsl_usb2_device_register(
>>> if (retval)
>>> goto error;
>>>
>>> - if (num) {
>>> - retval = platform_device_add_resources(pdev, res, num);
>>> - if (retval)
>>> - goto error;
>>> - }
>>> + pdev->dev.of_node = ofdev->dev.of_node;
>>>
>>> retval = platform_device_add(pdev);
>>> if (retval)
>> Hello Rob,
>>
>> Thanks a lot for your patch! Unfortunately, this leads to a boot loop.
>> Do you have another idea?
>
> Do you have a dmesg log?
From the boot loop?
>
> The other way to fix is creating a IRQ resource and adding it to the
> child device resources.
Good idea.
>
> Rob
Re: [FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19
On 27 May 2022 at 04:23 pm, Rob Herring wrote:
The issue is in drivers/usb/host/fsl-mph-dr-of.c which copies the
resources to a child platform device. Can you try the following
change:
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 44a7e58a26e3..47d9b7be60da 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -80,8 +80,6 @@ static struct platform_device *fsl_usb2_device_register(
const char *name, int id)
{
struct platform_device *pdev;
- const struct resource *res = ofdev->resource;
- unsigned int num = ofdev->num_resources;
int retval;
pdev = platform_device_alloc(name, id);
@@ -106,11 +104,7 @@ static struct platform_device *fsl_usb2_device_register(
if (retval)
goto error;
- if (num) {
- retval = platform_device_add_resources(pdev, res, num);
- if (retval)
- goto error;
- }
+ pdev->dev.of_node = ofdev->dev.of_node;
retval = platform_device_add(pdev);
if (retval)
Hello Rob,
Thanks a lot for your patch! Unfortunately, this leads to a boot loop.
Do you have another idea?
Thanks,
Christian
Re: [FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19
On 28 May 2022 at 10:05 am, Christian Zigotzky wrote:
On 27 May 2022 at 04:23 am, Rob Herring wrote:
The issue is in drivers/usb/host/fsl-mph-dr-of.c which copies the
resources to a child platform device. Can you try the following
change:
diff --git a/drivers/usb/host/fsl-mph-dr-of.c
b/drivers/usb/host/fsl-mph-dr-of.c
index 44a7e58a26e3..47d9b7be60da 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -80,8 +80,6 @@ static struct platform_device
*fsl_usb2_device_register(
const char *name, int id)
{
struct platform_device *pdev;
- const struct resource *res = ofdev->resource;
- unsigned int num = ofdev->num_resources;
int retval;
pdev = platform_device_alloc(name, id);
@@ -106,11 +104,7 @@ static struct platform_device
*fsl_usb2_device_register(
if (retval)
goto error;
- if (num) {
- retval = platform_device_add_resources(pdev, res, num);
- if (retval)
- goto error;
- }
+ pdev->dev.of_node = ofdev->dev.of_node;
retval = platform_device_add(pdev);
if (retval)
Hi Rob,
Thanks a lot for your patch! :-)
First attempt with the latest git kernel:
patching file a/drivers/usb/host/fsl-mph-dr-of.c
Hunk #1 FAILED at 80.
Hunk #2 FAILED at 106.
2 out of 2 hunks FAILED -- saving rejects to file
a/drivers/usb/host/fsl-mph-dr-of.c.rej
I created a new patch with your modifications. (see attachment)
Unfortunately I can't test it. The git kernel doesn't compile currently.
powerpc-linux-gnu-ld: net/rds/tcp_stats.o:(.bss+0x0): multiple
definition of `cacheline_aligned'; init/version.o:(.bss+0x0):
first defined here
powerpc-linux-gnu-ld: net/wireless/wext-spy.o:(.bss+0x0): multiple
definition of `cacheline_aligned'; init/version.o:(.bss+0x0):
first defined here
powerpc-linux-gnu-ld: net/wireless/wext-priv.o:(.bss+0x0): multiple
definition of `cacheline_aligned'; init/version.o:(.bss+0x0):
first defined here
powerpc-linux-gnu-ld: net/tipc/bcast.o:(.bss+0x0): multiple definition
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/bearer.o:(.bss+0x0): multiple
definition of `cacheline_aligned'; init/version.o:(.bss+0x0):
first defined here
powerpc-linux-gnu-ld: net/tipc/core.o:(.bss+0x0): multiple definition
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/link.o:(.bss+0x0): multiple definition
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/discover.o:(.bss+0x0): multiple
definition of `cacheline_aligned'; init/version.o:(.bss+0x0):
first defined here
powerpc-linux-gnu-ld: net/tipc/msg.o:(.bss+0x0): multiple definition
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/name_distr.o:(.bss+0x0): multiple
definition of `cacheline_aligned'; init/version.o:(.bss+0x0):
first defined here
powerpc-linux-gnu-ld: net/tipc/subscr.o:(.bss+0x0): multiple
definition of `cacheline_aligned'; init/version.o:(.bss+0x0):
first defined here
powerpc-linux-gnu-ld: net/tipc/name_table.o:(.bss+0x0): multiple
definition of `cacheline_aligned'; init/version.o:(.bss+0x0):
first defined here
powerpc-linux-gnu-ld: net/tipc/net.o:(.bss+0x0): multiple definition
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/netlink.o:(.bss+0x0): multiple
definition of `cacheline_aligned'; init/version.o:(.bss+0x0):
first defined here
powerpc-linux-gnu-ld: net/tipc/netlink_compat.o:(.bss+0x0): multiple
definition of `cacheline_aligned'; init/version.o:(.bss+0x0):
first defined here
powerpc-linux-gnu-ld: net/tipc/node.o:(.bss+0x0): multiple definition
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/eth_media.o:(.bss+0x0): multiple
definition of `cacheline_aligned'; init/version.o:(.bss+0x0):
first defined here
powerpc-linux-gnu-ld: net/tipc/topsrv.o:(.bss+0x0): multiple
definition of `cacheline_aligned'; init/version.o:(.bss+0x0):
first defined here
powerpc-linux-gnu-ld: net/tipc/group.o:(.bss+0x0): multiple definition
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/trace.o:(.bss+0x0): multiple definition
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/udp_media.o:(.bss+0x0): multiple
definition of `cacheline_aligned'; init/version.o:(.bss+0x0):
first defined here
powerpc-linux-gnu-ld: net/tipc/sysctl.o:(.bss+0x40): multiple
definition of `cacheline_align
Re: [FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19
On 27 May 2022 at 04:23 am, Rob Herring wrote:
The issue is in drivers/usb/host/fsl-mph-dr-of.c which copies the
resources to a child platform device. Can you try the following
change:
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 44a7e58a26e3..47d9b7be60da 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -80,8 +80,6 @@ static struct platform_device *fsl_usb2_device_register(
const char *name, int id)
{
struct platform_device *pdev;
- const struct resource *res = ofdev->resource;
- unsigned int num = ofdev->num_resources;
int retval;
pdev = platform_device_alloc(name, id);
@@ -106,11 +104,7 @@ static struct platform_device *fsl_usb2_device_register(
if (retval)
goto error;
- if (num) {
- retval = platform_device_add_resources(pdev, res, num);
- if (retval)
- goto error;
- }
+ pdev->dev.of_node = ofdev->dev.of_node;
retval = platform_device_add(pdev);
if (retval)
Hi Rob,
Thanks a lot for your patch! :-)
First attempt with the latest git kernel:
patching file a/drivers/usb/host/fsl-mph-dr-of.c
Hunk #1 FAILED at 80.
Hunk #2 FAILED at 106.
2 out of 2 hunks FAILED -- saving rejects to file
a/drivers/usb/host/fsl-mph-dr-of.c.rej
I created a new patch with your modifications. (see attachment)
Unfortunately I can't test it. The git kernel doesn't compile currently.
powerpc-linux-gnu-ld: net/rds/tcp_stats.o:(.bss+0x0): multiple
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): first
defined here
powerpc-linux-gnu-ld: net/wireless/wext-spy.o:(.bss+0x0): multiple
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): first
defined here
powerpc-linux-gnu-ld: net/wireless/wext-priv.o:(.bss+0x0): multiple
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): first
defined here
powerpc-linux-gnu-ld: net/tipc/bcast.o:(.bss+0x0): multiple definition
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/bearer.o:(.bss+0x0): multiple definition
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/core.o:(.bss+0x0): multiple definition of
`cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/link.o:(.bss+0x0): multiple definition of
`cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/discover.o:(.bss+0x0): multiple
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): first
defined here
powerpc-linux-gnu-ld: net/tipc/msg.o:(.bss+0x0): multiple definition of
`cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/name_distr.o:(.bss+0x0): multiple
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): first
defined here
powerpc-linux-gnu-ld: net/tipc/subscr.o:(.bss+0x0): multiple definition
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/name_table.o:(.bss+0x0): multiple
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): first
defined here
powerpc-linux-gnu-ld: net/tipc/net.o:(.bss+0x0): multiple definition of
`cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/netlink.o:(.bss+0x0): multiple definition
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/netlink_compat.o:(.bss+0x0): multiple
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): first
defined here
powerpc-linux-gnu-ld: net/tipc/node.o:(.bss+0x0): multiple definition of
`cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/eth_media.o:(.bss+0x0): multiple
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): first
defined here
powerpc-linux-gnu-ld: net/tipc/topsrv.o:(.bss+0x0): multiple definition
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/group.o:(.bss+0x0): multiple definition
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/trace.o:(.bss+0x0): multiple definition
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/udp_media.o:(.bss+0x0): multiple
definition of `cacheline_aligned'; init/version.o:(.bss+0x0): first
defined here
powerpc-linux-gnu-ld: net/tipc/sysctl.o:(.bss+0x40): multiple definition
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gnu-ld: net/tipc/crypto.o:(.bss+0x0): multiple definition
of `cacheline_aligned'; init/version.o:(.bss+0x0): first defined here
powerpc-linux-gn
[FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19
On 27 May 2022 at 10:14 am, Prabhakar Mahadev Lad wrote: Hi, -Original Message- From: Christian Zigotzky Sent: 27 May 2022 09:06 To: Prabhakar Mahadev Lad ; Christophe Leroy ; Rob Herring Cc: Darren Stevens ; linuxppc-dev ; mad skateman ; R.T.Dickinson ; Christian Zigotzky Subject: [FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19 On 27 May 2022 at 09:56 am, Prabhakar Mahadev Lad wrote: Hi, -Original Message- From: Christophe Leroy Sent: 27 May 2022 08:23 To: Christian Zigotzky ; rob.herr...@calxeda.com; Prabhakar Mahadev Lad Cc: Darren Stevens ; linuxppc-dev ; mad skateman ; R.T.Dickinson ; Christian Zigotzky Subject: Re: [FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19 Hi Le 26/05/2022 à 19:42, Christian Zigotzky a écrit : Hello, My keyboard and mouse don't work anymore with my Cyrus+ board with a FSL P50x0 PowerPC SoC [1] after the devicetree updates for 5.19 [2]. After reverting the devicetree updates, my keyboard and mouse work without any problems. I figured out that the issue is in the patch for the file platform.c [3]. I created a patch for reverting the problematic code. (see attachment) After reverting the changes with the attached patch, the keyboard and mouse work again. Please check your changes in the file platform.c [3]. Thanks, Christian [1] https://jpn01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki. amiga.org%2Findex.php%3Ftitle%3DX5000&data=05%7C01%7Cprabhakar.m ah adev-lad.rj%40bp.renesas.com%7C4e9c08d1e3874a34bd4208da3fb1c007%7C53 d8 2571da1947e49cb4625a166a4a2a%7C0%7C0%7C637892329912063922%7CUnknown% 7C TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX VC I6Mn0%3D%7C3000%7C%7C%7C&sdata=fSABvBDi%2FYlqU1eydQB6%2F4BzxXkqR M0 Ln9hdInyTp6w%3D&reserved=0 [2] https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit. kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git %2 Fcommit%2F%3Fid%3D86c87bea6b42100c67418af690919c44de6ede6e&data= 05 %7C01%7Cprabhakar.mahadev-lad.rj%40bp.renesas.com%7C4e9c08d1e3874a34 bd 4208da3fb1c007%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C63789232 99 12063922%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI iL CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ENkjlza0J7xF iI aPUwMBxHBIkXJNkT%2BLTZ3xuPz%2B10Q%3D&reserved=0 [3] https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit. kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git %2 Fdiff%2Fdrivers%2Fof%2Fplatform.c%3Fid%3D86c87bea6b42100c67418af6909 19 c44de6ede6e&data=05%7C01%7Cprabhakar.mahadev-lad.rj%40bp.renesas .c om%7C4e9c08d1e3874a34bd4208da3fb1c007%7C53d82571da1947e49cb4625a166a 4a 2a%7C0%7C0%7C637892329912063922%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w Lj AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C &a mp;sdata=yEJUK%2BGK2dzWARC5rfhsSSFSwD%2BLZm8aNNHqQhPYP7Y%3D&rese rv ed=0 Based on your patch I would say the culprit commit is https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit hub.c%2F&data=05%7C01%7Cprabhakar.mahadev-lad.rj%40bp.renesas.com %7Cbf899ff2084643971c7908da3fb7d4b9%7C53d82571da1947e49cb4625a166a4a2 a%7C0%7C1%7C637892356025845542%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C& amp;sdata=%2FzI4yueF6Pc%2Fpvh7Ax9WilnaYX8ozFTRyQpiVaaacbg%3D&rese rved=0 om%2Ftorvalds%2Flinux%2Fcommit%2Fa1a2b7125e1079cfcc13a116aa3af3df2f9e 002b& amp;data=05%7C01%7Cprabhakar.mahadev- lad.rj%40bp.renesas.com%7C4e9c08d1e3874a34bd4208da3fb1c007%7C53d82571 da194 7e49cb4625a166a4a2a%7C0%7C0%7C637892329912063922%7CUnknown%7CTWFpbGZs b3d8e yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3 000%7 C%7C%7C&sdata=ONR1CiaSID6q4%2Fo%2BI6MlPA4ij89BJphQRpEu5tQxvYQ%3D& amp;r eserved=0 commit a1a2b7125e1079cfcc13a116aa3af3df2f9e002b Author: Lad Prabhakar Date: Wed Mar 16 20:06:33 2022 + of/platform: Drop static setup of IRQ resource from DT core Now that all the DT drivers have switched to platform_get_irq() we can now safely drop the static setup of IRQ resource from DT core code. With the above change hierarchical setup of irq domains is no longer bypassed and thus allowing hierarchical interrupt domains to describe interrupts using "interrupts" DT property. Signed-off-by: Lad Prabhakar Acked-by: Marc Zyngier Tested-by: Marc Zyngier Signed-off-by: Rob Herring Link: https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flor e.ker%2F&data=05%7C01%7Cprabhakar.mahadev-lad.rj%40bp.renesas.com %7Cbf899ff2084643971c7908da3fb7d4b9%7C53d82571da1947e49cb4625a166a4a2 a%7C0%7C1%7C637892356025845542%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C
[FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19
On 27 May 2022 at 09:56 am, Prabhakar Mahadev Lad wrote: Hi, -Original Message- From: Christophe Leroy Sent: 27 May 2022 08:23 To: Christian Zigotzky ; rob.herr...@calxeda.com; Prabhakar Mahadev Lad Cc: Darren Stevens ; linuxppc-dev ; mad skateman ; R.T.Dickinson ; Christian Zigotzky Subject: Re: [FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19 Hi Le 26/05/2022 à 19:42, Christian Zigotzky a écrit : Hello, My keyboard and mouse don't work anymore with my Cyrus+ board with a FSL P50x0 PowerPC SoC [1] after the devicetree updates for 5.19 [2]. After reverting the devicetree updates, my keyboard and mouse work without any problems. I figured out that the issue is in the patch for the file platform.c [3]. I created a patch for reverting the problematic code. (see attachment) After reverting the changes with the attached patch, the keyboard and mouse work again. Please check your changes in the file platform.c [3]. Thanks, Christian [1] https://jpn01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki. amiga.org%2Findex.php%3Ftitle%3DX5000&data=05%7C01%7Cprabhakar.mah adev-lad.rj%40bp.renesas.com%7C4e9c08d1e3874a34bd4208da3fb1c007%7C53d8 2571da1947e49cb4625a166a4a2a%7C0%7C0%7C637892329912063922%7CUnknown%7C TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC I6Mn0%3D%7C3000%7C%7C%7C&sdata=fSABvBDi%2FYlqU1eydQB6%2F4BzxXkqRM0 Ln9hdInyTp6w%3D&reserved=0 [2] https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit. kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2 Fcommit%2F%3Fid%3D86c87bea6b42100c67418af690919c44de6ede6e&data=05 %7C01%7Cprabhakar.mahadev-lad.rj%40bp.renesas.com%7C4e9c08d1e3874a34bd 4208da3fb1c007%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C6378923299 12063922%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ENkjlza0J7xFiI aPUwMBxHBIkXJNkT%2BLTZ3xuPz%2B10Q%3D&reserved=0 [3] https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit. kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2 Fdiff%2Fdrivers%2Fof%2Fplatform.c%3Fid%3D86c87bea6b42100c67418af690919 c44de6ede6e&data=05%7C01%7Cprabhakar.mahadev-lad.rj%40bp.renesas.c om%7C4e9c08d1e3874a34bd4208da3fb1c007%7C53d82571da1947e49cb4625a166a4a 2a%7C0%7C0%7C637892329912063922%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&a mp;sdata=yEJUK%2BGK2dzWARC5rfhsSSFSwD%2BLZm8aNNHqQhPYP7Y%3D&reserv ed=0 Based on your patch I would say the culprit commit is https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c om%2Ftorvalds%2Flinux%2Fcommit%2Fa1a2b7125e1079cfcc13a116aa3af3df2f9e002b& amp;data=05%7C01%7Cprabhakar.mahadev- lad.rj%40bp.renesas.com%7C4e9c08d1e3874a34bd4208da3fb1c007%7C53d82571da194 7e49cb4625a166a4a2a%7C0%7C0%7C637892329912063922%7CUnknown%7CTWFpbGZsb3d8e yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7 C%7C%7C&sdata=ONR1CiaSID6q4%2Fo%2BI6MlPA4ij89BJphQRpEu5tQxvYQ%3D&r eserved=0 commit a1a2b7125e1079cfcc13a116aa3af3df2f9e002b Author: Lad Prabhakar Date: Wed Mar 16 20:06:33 2022 + of/platform: Drop static setup of IRQ resource from DT core Now that all the DT drivers have switched to platform_get_irq() we can now safely drop the static setup of IRQ resource from DT core code. With the above change hierarchical setup of irq domains is no longer bypassed and thus allowing hierarchical interrupt domains to describe interrupts using "interrupts" DT property. Signed-off-by: Lad Prabhakar Acked-by: Marc Zyngier Tested-by: Marc Zyngier Signed-off-by: Rob Herring Link: https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ker nel.org%2Fr%2F20220316200633.28974-1-prabhakar.mahadev- lad.rj%40bp.renesas.com&data=05%7C01%7Cprabhakar.mahadev- lad.rj%40bp.renesas.com%7C4e9c08d1e3874a34bd4208da3fb1c007%7C53d82571da194 7e49cb4625a166a4a2a%7C0%7C0%7C637892329912063922%7CUnknown%7CTWFpbGZsb3d8e yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7 C%7C%7C&sdata=ri76vfLpmxe7vFDAlsBjyrSSkuTMz0ydftu3XObLGLA%3D&reser ved=0 Looks like the driver which you are using has not been converted to use platform_get_irq(), could you please check that. Cheers, Prabhakar Do you mean the mouse and keyboard driver? -- Christian
Fwd: [FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19
Rob's email address corrected.
-- Christian
On 27 May 2022 at 09:23 am, Christophe Leroy wrote:
Hi
Le 26/05/2022 à 19:42, Christian Zigotzky a écrit :
Hello,
My keyboard and mouse don't work anymore with my Cyrus+ board with a FSL
P50x0 PowerPC SoC [1] after the devicetree updates for 5.19 [2].
After reverting the devicetree updates, my keyboard and mouse work
without any problems.
I figured out that the issue is in the patch for the file platform.c
[3]. I created a patch for reverting the problematic code. (see
attachment)
After reverting the changes with the attached patch, the keyboard and
mouse work again.
Please check your changes in the file platform.c [3].
Thanks,
Christian
[1] http://wiki.amiga.org/index.php?title=X5000
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=86c87bea6b42100c67418af690919c44de6ede6e
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/of/platform.c?id=86c87bea6b42100c67418af690919c44de6ede6e
Based on your patch I would say the culprit commit is
https://github.com/torvalds/linux/commit/a1a2b7125e1079cfcc13a116aa3af3df2f9e002b
commit a1a2b7125e1079cfcc13a116aa3af3df2f9e002b
Author: Lad Prabhakar
Date: Wed Mar 16 20:06:33 2022 +
of/platform: Drop static setup of IRQ resource from DT core
Now that all the DT drivers have switched to platform_get_irq() we
can now
safely drop the static setup of IRQ resource from DT core code.
With the above change hierarchical setup of irq domains is no longer
bypassed and thus allowing hierarchical interrupt domains to describe
interrupts using "interrupts" DT property.
Signed-off-by: Lad Prabhakar
Acked-by: Marc Zyngier
Tested-by: Marc Zyngier
Signed-off-by: Rob Herring
Link:
https://lore.kernel.org/r/20220316200633.28974-1-prabhakar.mahadev-lad...@bp.renesas.com
Can you please provide you device tree ?
Do you use any out-of-tree drivers ?
Thanks
Christophe
Hi Christophe,
No, I don't use any out-of-tree drivers. Please find attached the dtb,
dts, and the dtsi file.
Thanks,
Christian/*
* P5040 Silicon/SoC Device Tree Source (pre include)
*
* Copyright 2012 - 2015 Freescale Semiconductor Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
* * Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* * Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* * Neither the name of Freescale Semiconductor nor the
* names of its contributors may be used to endorse or promote products
* derived from this software without specific prior written permission.
*
*
* ALTERNATIVELY, this software may be distributed under the terms of the
* GNU General Public License ("GPL") as published by the Free Software
* Foundation, either version 2 of that License or (at your option) any
* later version.
*
* This software is provided by Freescale Semiconductor "as is" and any
* express or implied warranties, including, but not limited to, the implied
* warranties of merchantability and fitness for a particular purpose are
* disclaimed. In no event shall Freescale Semiconductor be liable for any
* direct, indirect, incidental, special, exemplary, or consequential damages
* (including, but not limited to, procurement of substitute goods or services;
* loss of use, data, or profits; or business interruption) however caused and
* on any theory of liability, whether in contract, strict liability, or tort
* (including negligence or otherwise) arising in any way out of the use of this
* software, even if advised of the possibility of such damage.
*/
/dts-v1/;
/include/ "e5500_power_isa.dtsi"
/ {
compatible = "fsl,P5040";
#address-cells = <2>;
#size-cells = <2>;
interrupt-parent = <&mpic>;
aliases {
ccsr = &soc;
dcsr = &dcsr;
serial0 = &serial0;
serial1 = &serial1;
serial2 = &serial2;
serial3 = &serial3;
pci0 = &pci0;
pci1 = &pci1;
pci2 = &pci2;
usb0 = &usb0;
usb1 = &usb1;
dma0 = &dma0;
dma1 = &dma1;
sdhc = &sdhc;
msi0 = &msi0;
msi1 = &msi1;
msi2 = &msi2;
crypto = &crypto;
sec_jr0 = &sec_jr0;
sec_jr1 = &sec_jr1;
sec_jr2 = &sec_jr2;
[FSL P50x0] Keyboard and mouse don't work anymore after the devicetree updates for 5.19
On 27 May 2022 at 09:23 am, Christophe Leroy wrote:
Hi
Le 26/05/2022 à 19:42, Christian Zigotzky a écrit :
Hello,
My keyboard and mouse don't work anymore with my Cyrus+ board with a FSL
P50x0 PowerPC SoC [1] after the devicetree updates for 5.19 [2].
After reverting the devicetree updates, my keyboard and mouse work
without any problems.
I figured out that the issue is in the patch for the file platform.c
[3]. I created a patch for reverting the problematic code. (see
attachment)
After reverting the changes with the attached patch, the keyboard and
mouse work again.
Please check your changes in the file platform.c [3].
Thanks,
Christian
[1] http://wiki.amiga.org/index.php?title=X5000
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=86c87bea6b42100c67418af690919c44de6ede6e
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/of/platform.c?id=86c87bea6b42100c67418af690919c44de6ede6e
Based on your patch I would say the culprit commit is
https://github.com/torvalds/linux/commit/a1a2b7125e1079cfcc13a116aa3af3df2f9e002b
commit a1a2b7125e1079cfcc13a116aa3af3df2f9e002b
Author: Lad Prabhakar
Date: Wed Mar 16 20:06:33 2022 +
of/platform: Drop static setup of IRQ resource from DT core
Now that all the DT drivers have switched to platform_get_irq() we
can now
safely drop the static setup of IRQ resource from DT core code.
With the above change hierarchical setup of irq domains is no longer
bypassed and thus allowing hierarchical interrupt domains to describe
interrupts using "interrupts" DT property.
Signed-off-by: Lad Prabhakar
Acked-by: Marc Zyngier
Tested-by: Marc Zyngier
Signed-off-by: Rob Herring
Link:
https://lore.kernel.org/r/20220316200633.28974-1-prabhakar.mahadev-lad...@bp.renesas.com
Can you please provide you device tree ?
Do you use any out-of-tree drivers ?
Thanks
Christophe
Hi Christophe,
No, I don't use any out-of-tree drivers. Please find attached the dtb,
dts, and the dtsi file.
Thanks,
Christian/*
* P5040 Silicon/SoC Device Tree Source (pre include)
*
* Copyright 2012 - 2015 Freescale Semiconductor Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
* * Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* * Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* * Neither the name of Freescale Semiconductor nor the
* names of its contributors may be used to endorse or promote products
* derived from this software without specific prior written permission.
*
*
* ALTERNATIVELY, this software may be distributed under the terms of the
* GNU General Public License ("GPL") as published by the Free Software
* Foundation, either version 2 of that License or (at your option) any
* later version.
*
* This software is provided by Freescale Semiconductor "as is" and any
* express or implied warranties, including, but not limited to, the implied
* warranties of merchantability and fitness for a particular purpose are
* disclaimed. In no event shall Freescale Semiconductor be liable for any
* direct, indirect, incidental, special, exemplary, or consequential damages
* (including, but not limited to, procurement of substitute goods or services;
* loss of use, data, or profits; or business interruption) however caused and
* on any theory of liability, whether in contract, strict liability, or tort
* (including negligence or otherwise) arising in any way out of the use of this
* software, even if advised of the possibility of such damage.
*/
/dts-v1/;
/include/ "e5500_power_isa.dtsi"
/ {
compatible = "fsl,P5040";
#address-cells = <2>;
#size-cells = <2>;
interrupt-parent = <&mpic>;
aliases {
ccsr = &soc;
dcsr = &dcsr;
serial0 = &serial0;
serial1 = &serial1;
serial2 = &serial2;
serial3 = &serial3;
pci0 = &pci0;
pci1 = &pci1;
pci2 = &pci2;
usb0 = &usb0;
usb1 = &usb1;
dma0 = &dma0;
dma1 = &dma1;
sdhc = &sdhc;
msi0 = &msi0;
msi1 = &msi1;
msi2 = &msi2;
crypto = &crypto;
sec_jr0 = &sec_jr0;
sec_jr1 = &sec_jr1;
The PA6T is still vulnerable
Hi All, The P.A. Semi PA6T is still vulnerable. Architecture:ppc64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Big Endian CPU(s): 2 On-line CPU(s) list: 0,1 Thread(s) per core: 1 Core(s) per socket: 2 Socket(s): 1 Model: 1.2 (pvr 0090 0102) Model name: PA6T, altivec supported L1d cache: 128 KiB L1i cache: 128 KiB Vulnerability Itlb multihit: Not affected Vulnerability L1tf: Vulnerable Vulnerability Mds: Not affected Vulnerability Meltdown: Vulnerable Vulnerability Spec store bypass: Vulnerable Vulnerability Spectre v1:Mitigation; __user pointer sanitization Vulnerability Spectre v2:Vulnerable Vulnerability Srbds: Not affected Vulnerability Tsx async abort: Not affected Could you please check this issue? Thanks, Christian
Re: [PATCH] powerpc/book3e: Fix TLBCAM preset at boot
On 15 November 2021 at 10:05 am, Christophe Leroy wrote:
Commit 52bda69ae8b5 ("powerpc/fsl_booke: Tell map_mem_in_cams() if
init is done") was supposed to just add an additional parameter to
map_mem_in_cams() and always set it to 'true' at that time.
But a few call sites were messed up. Fix them.
Reported-by: Christian Zigotzky
Fixes: 52bda69ae8b5 ("powerpc/fsl_booke: Tell map_mem_in_cams() if init is
done")
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/nohash/kaslr_booke.c | 2 +-
arch/powerpc/mm/nohash/tlb.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/nohash/kaslr_booke.c
b/arch/powerpc/mm/nohash/kaslr_booke.c
index 8fc49b1b4a91..6ec978967da0 100644
--- a/arch/powerpc/mm/nohash/kaslr_booke.c
+++ b/arch/powerpc/mm/nohash/kaslr_booke.c
@@ -314,7 +314,7 @@ static unsigned long __init kaslr_choose_location(void
*dt_ptr, phys_addr_t size
pr_warn("KASLR: No safe seed for randomizing the kernel
base.\n");
ram = min_t(phys_addr_t, __max_low_memory, size);
- ram = map_mem_in_cams(ram, CONFIG_LOWMEM_CAM_NUM, true, false);
+ ram = map_mem_in_cams(ram, CONFIG_LOWMEM_CAM_NUM, true, true);
linear_sz = min_t(unsigned long, ram, SZ_512M);
/* If the linear size is smaller than 64M, do not randmize */
diff --git a/arch/powerpc/mm/nohash/tlb.c b/arch/powerpc/mm/nohash/tlb.c
index 89353d4f5604..647bf454a0fa 100644
--- a/arch/powerpc/mm/nohash/tlb.c
+++ b/arch/powerpc/mm/nohash/tlb.c
@@ -645,7 +645,7 @@ static void early_init_this_mmu(void)
if (map)
linear_map_top = map_mem_in_cams(linear_map_top,
-num_cams, true, true);
+num_cams, false, true);
}
#endif
@@ -766,7 +766,7 @@ void setup_initial_memory_limit(phys_addr_t first_memblock_base,
num_cams = (mfspr(SPRN_TLB1CFG) & TLBnCFG_N_ENTRY) / 4;
linear_sz = map_mem_in_cams(first_memblock_size, num_cams,
- false, true);
+ true, true);
ppc64_rma_size = min_t(u64, linear_sz, 0x40000000);
} else
Tested-by: Christian Zigotzky
Thanks
Re: [PASEMI] Nemo board doesn't recognize any ATA disks with the pci-v5.16 updates
Am 12.11.21 um 16:01 schrieb Christian Zigotzky:
Am 12.11.21 um 15:46 schrieb Marc Zyngier:
On Fri, 12 Nov 2021 14:15:18 +,
Christian Zigotzky wrote:
On 12 November 2021 at 02:41 pm, Marc Zyngier wrote:
On Fri, 12 Nov 2021 09:40:30 +,
Christian Zigotzky wrote:
On 11 November 2021 at 06:39 pm, Marc Zyngier wrote:
On Wed, 10 Nov 2021 18:07:24 +,
Christian Zigotzky wrote:
On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:
Hello,
The Nemo board [1] doesn't recognize any ATA disks with the
pci-v5.16 updates [2].
Error messages:
ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)
I was able to revert the new pci-v5.16 updates [2]. After a new
compiling, the kernel recognize all ATA disks correctly.
Could you please check the pci-v5.16 updates [2]?
Please find attached the kernel config.
Thanks,
Christian
[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4
Hi All,
Many thanks for your nice responses.
I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd
(of/irq: Allow matching of an interrupt-map local to an interrupt
controller) [2] is the first bad commit.
Can you please give the following hack a go and post the result
(including the full dmesg)?
Thanks,
M.
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 32be5a03951f..8cf0cc9b7caf 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -156,14 +156,15 @@ int of_irq_parse_raw(const __be32 *addr,
struct of_phandle_args *out_irq)
/* Now start the actual "proper" walk of the interrupt
tree */
while (ipar != NULL) {
+ bool intc = of_property_read_bool(ipar,
"interrupt-controller");
+
/*
* Now check if cursor is an interrupt-controller and
* if it is then we are done, unless there is an
* interrupt-map which takes precedence.
*/
imap = of_get_property(ipar, "interrupt-map", &imaplen);
- if (imap == NULL &&
- of_property_read_bool(ipar, "interrupt-controller")) {
+ if (imap == NULL && intc) {
pr_debug(" -> got it !\n");
return 0;
}
@@ -244,8 +245,14 @@ int of_irq_parse_raw(const __be32 *addr,
struct of_phandle_args *out_irq)
pr_debug(" -> imaplen=%d\n", imaplen);
}
- if (!match)
+ if (!match) {
+ if (intc) {
+ pr_info("%pOF interrupt-map failed, using
interrupt-controller\n", ipar);
+ return 0;
+ }
+
goto fail;
+ }
/*
* Successfully parsed an interrrupt-map translation;
copy new
The detecting of the ATA disks works with this patch! Well done!
Thanks a lot!
Thanks for testing it. I'll turn that into a proper patch.
M.
Could you please explain your patch?
Please refer to the commit message[1].
I am not a developer. I work for the A-EON Linux FLS.
I have no idea what this is, unfortunately.
M.
[1] https://lore.kernel.org/r/2022143644.434995-1-...@kernel.org
FLS: First Level Support (IT customer support)
SLS: Second Level Support (administrators)
TLS: Third Level Support (developers -> you)
I have to explain our customers why the kernel doesn't detect their
ATA disks anymore. :-D But it is fixed and I don't need to explain it.
Thanks a lot for your help.
- Christian
Typos
Re: [PASEMI] Nemo board doesn't recognize any ATA disks with the pci-v5.16 updates
Am 12.11.21 um 15:46 schrieb Marc Zyngier:
On Fri, 12 Nov 2021 14:15:18 +,
Christian Zigotzky wrote:
On 12 November 2021 at 02:41 pm, Marc Zyngier wrote:
On Fri, 12 Nov 2021 09:40:30 +,
Christian Zigotzky wrote:
On 11 November 2021 at 06:39 pm, Marc Zyngier wrote:
On Wed, 10 Nov 2021 18:07:24 +,
Christian Zigotzky wrote:
On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:
Hello,
The Nemo board [1] doesn't recognize any ATA disks with the
pci-v5.16 updates [2].
Error messages:
ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)
I was able to revert the new pci-v5.16 updates [2]. After a new
compiling, the kernel recognize all ATA disks correctly.
Could you please check the pci-v5.16 updates [2]?
Please find attached the kernel config.
Thanks,
Christian
[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4
Hi All,
Many thanks for your nice responses.
I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd
(of/irq: Allow matching of an interrupt-map local to an interrupt
controller) [2] is the first bad commit.
Can you please give the following hack a go and post the result
(including the full dmesg)?
Thanks,
M.
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 32be5a03951f..8cf0cc9b7caf 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -156,14 +156,15 @@ int of_irq_parse_raw(const __be32 *addr, struct
of_phandle_args *out_irq)
/* Now start the actual "proper" walk of the interrupt tree */
while (ipar != NULL) {
+ bool intc = of_property_read_bool(ipar, "interrupt-controller");
+
/*
* Now check if cursor is an interrupt-controller and
* if it is then we are done, unless there is an
* interrupt-map which takes precedence.
*/
imap = of_get_property(ipar, "interrupt-map", &imaplen);
- if (imap == NULL &&
- of_property_read_bool(ipar, "interrupt-controller")) {
+ if (imap == NULL && intc) {
pr_debug(" -> got it !\n");
return 0;
}
@@ -244,8 +245,14 @@ int of_irq_parse_raw(const __be32 *addr, struct
of_phandle_args *out_irq)
pr_debug(" -> imaplen=%d\n", imaplen);
}
- if (!match)
+ if (!match) {
+ if (intc) {
+ pr_info("%pOF interrupt-map failed, using
interrupt-controller\n", ipar);
+ return 0;
+ }
+
goto fail;
+ }
/*
* Successfully parsed an interrrupt-map translation; copy new
The detecting of the ATA disks works with this patch! Well done!
Thanks a lot!
Thanks for testing it. I'll turn that into a proper patch.
M.
Could you please explain your patch?
Please refer to the commit message[1].
I am not a developer. I work for the A-EON Linux FLS.
I have no idea what this is, unfortunately.
M.
[1] https://lore.kernel.org/r/2022143644.434995-1-...@kernel.org
FLS: First Level Support (IT customer support)
SLS: Second Level Support (administrators)
TLS: Third Level Support (developers -> you)
I have to explain to our customer why the kernel doesn't their ATA disk
anymore. :-D But it is fixed and I don't need to explain it.
Thanks a lot for your help.
- Christian
Re: [PASEMI] Nemo board doesn't recognize any ATA disks with the pci-v5.16 updates
On 12 November 2021 at 02:41 pm, Marc Zyngier wrote:
On Fri, 12 Nov 2021 09:40:30 +,
Christian Zigotzky wrote:
On 11 November 2021 at 06:39 pm, Marc Zyngier wrote:
On Wed, 10 Nov 2021 18:07:24 +,
Christian Zigotzky wrote:
On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:
Hello,
The Nemo board [1] doesn't recognize any ATA disks with the
pci-v5.16 updates [2].
Error messages:
ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)
I was able to revert the new pci-v5.16 updates [2]. After a new
compiling, the kernel recognize all ATA disks correctly.
Could you please check the pci-v5.16 updates [2]?
Please find attached the kernel config.
Thanks,
Christian
[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4
Hi All,
Many thanks for your nice responses.
I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd
(of/irq: Allow matching of an interrupt-map local to an interrupt
controller) [2] is the first bad commit.
Can you please give the following hack a go and post the result
(including the full dmesg)?
Thanks,
M.
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 32be5a03951f..8cf0cc9b7caf 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -156,14 +156,15 @@ int of_irq_parse_raw(const __be32 *addr, struct
of_phandle_args *out_irq)
/* Now start the actual "proper" walk of the interrupt tree */
while (ipar != NULL) {
+ bool intc = of_property_read_bool(ipar, "interrupt-controller");
+
/*
* Now check if cursor is an interrupt-controller and
* if it is then we are done, unless there is an
* interrupt-map which takes precedence.
*/
imap = of_get_property(ipar, "interrupt-map", &imaplen);
- if (imap == NULL &&
- of_property_read_bool(ipar, "interrupt-controller")) {
+ if (imap == NULL && intc) {
pr_debug(" -> got it !\n");
return 0;
}
@@ -244,8 +245,14 @@ int of_irq_parse_raw(const __be32 *addr, struct
of_phandle_args *out_irq)
pr_debug(" -> imaplen=%d\n", imaplen);
}
- if (!match)
+ if (!match) {
+ if (intc) {
+ pr_info("%pOF interrupt-map failed, using
interrupt-controller\n", ipar);
+ return 0;
+ }
+
goto fail;
+ }
/*
* Successfully parsed an interrrupt-map translation; copy new
The detecting of the ATA disks works with this patch! Well done!
Thanks a lot!
Thanks for testing it. I'll turn that into a proper patch.
M.
Could you please explain your patch? I am not a developer. I work for
the A-EON Linux FLS.
- Christian
Re: [PASEMI] Nemo board doesn't recognize any ATA disks with the pci-v5.16 updates
On 12 November 2021 at 11:11 am, Christian Zigotzky wrote:
On 12 November 2021 at 10:40 am, Christian Zigotzky wrote:
On 11 November 2021 at 06:39 pm, Marc Zyngier wrote:
On Wed, 10 Nov 2021 18:07:24 +,
Christian Zigotzky wrote:
On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:
Hello,
The Nemo board [1] doesn't recognize any ATA disks with the
pci-v5.16 updates [2].
Error messages:
ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)
I was able to revert the new pci-v5.16 updates [2]. After a new
compiling, the kernel recognize all ATA disks correctly.
Could you please check the pci-v5.16 updates [2]?
Please find attached the kernel config.
Thanks,
Christian
[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4
Hi All,
Many thanks for your nice responses.
I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd
(of/irq: Allow matching of an interrupt-map local to an interrupt
controller) [2] is the first bad commit.
Can you please give the following hack a go and post the result
(including the full dmesg)?
Thanks,
M.
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 32be5a03951f..8cf0cc9b7caf 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -156,14 +156,15 @@ int of_irq_parse_raw(const __be32 *addr,
struct of_phandle_args *out_irq)
/* Now start the actual "proper" walk of the interrupt tree */
while (ipar != NULL) {
+ bool intc = of_property_read_bool(ipar,
"interrupt-controller");
+
/*
* Now check if cursor is an interrupt-controller and
* if it is then we are done, unless there is an
* interrupt-map which takes precedence.
*/
imap = of_get_property(ipar, "interrupt-map", &imaplen);
- if (imap == NULL &&
- of_property_read_bool(ipar, "interrupt-controller")) {
+ if (imap == NULL && intc) {
pr_debug(" -> got it !\n");
return 0;
}
@@ -244,8 +245,14 @@ int of_irq_parse_raw(const __be32 *addr, struct
of_phandle_args *out_irq)
pr_debug(" -> imaplen=%d\n", imaplen);
}
- if (!match)
+ if (!match) {
+ if (intc) {
+ pr_info("%pOF interrupt-map failed, using
interrupt-controller\n", ipar);
+ return 0;
+ }
+
goto fail;
+ }
/*
* Successfully parsed an interrrupt-map translation; copy
new
The detecting of the ATA disks works with this patch! Well done!
Thanks a lot!
Sorry, I have read the patch more carefully and I have seen that it is
an analyse patch. It's not a fix. I was too quick with my joy.
- Christian
OK, perhaps a fix after all.
if (imap == NULL && intc) // If the return value isn't NULL then there
isn't an interrupt-map. That means, this part was successfully (&&) and
"intc" will evaluated (Testing of interrupt-controller). OK, perhaps it
is a fix after all.
Output:
[ 0.072659] OF: /pxp@0,e000 interrupt-map failed, using
interrupt-controller
[ 0.072682] OF: /pxp@0,e000 interrupt-map failed, using
interrupt-controller
[ 0.072701] OF: /pxp@0,e000 interrupt-map failed, using
interrupt-controller
[ 0.072720] OF: /pxp@0,e000 interrupt-map failed, using
interrupt-controller
[ 0.072741] OF: /pxp@0,e000 interrupt-map failed, using
interrupt-controller
[ 0.072762] OF: /pxp@0,e000 interrupt-map failed, using
interrupt-controller
[ 0.072784] OF: /pxp@0,e000 interrupt-map failed, using
interrupt-controller
[ 0.072805] OF: /pxp@0,e000 interrupt-map failed, using
interrupt-controller
[ 0.072824] OF: /pxp@0,e000 interrupt-map failed, using
interrupt-controller
[ 0.072843] OF: /pxp@0,e000 interrupt-map failed, using
interrupt-controller
[ 0.072861] OF: /pxp@0,e000 interrupt-map failed, using
interrupt-controller
[ 0.072929] OF: /pxp@0,e000 interrupt-map failed, using
interrupt-controller
[ 0.073167] OF: /pxp@0,e000 interrupt-map failed, using
interrupt-controller
[ 0.073191] OF: /pxp@0,e000 interrupt-map failed, using
interrupt-controller
[ 0.073211] OF: /pxp@0,e000 interrupt-map failed, using
interrupt-controller
[ 0.073232] OF: /pxp@0,e000 interrupt-map failed, using
interrupt-controller
[ 0.073252] OF: /pxp@0,e000 interrupt-map failed, using
interrupt-controller
[ 0.073272] OF: /pxp@0,e000 interrupt-map failed, using
interrupt-controller
[ 0.073292] O
Re: [PASEMI] Nemo board doesn't recognize any ATA disks with the pci-v5.16 updates
On 12 November 2021 at 10:40 am, Christian Zigotzky wrote:
On 11 November 2021 at 06:39 pm, Marc Zyngier wrote:
On Wed, 10 Nov 2021 18:07:24 +,
Christian Zigotzky wrote:
On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:
Hello,
The Nemo board [1] doesn't recognize any ATA disks with the
pci-v5.16 updates [2].
Error messages:
ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)
I was able to revert the new pci-v5.16 updates [2]. After a new
compiling, the kernel recognize all ATA disks correctly.
Could you please check the pci-v5.16 updates [2]?
Please find attached the kernel config.
Thanks,
Christian
[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4
Hi All,
Many thanks for your nice responses.
I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd
(of/irq: Allow matching of an interrupt-map local to an interrupt
controller) [2] is the first bad commit.
Can you please give the following hack a go and post the result
(including the full dmesg)?
Thanks,
M.
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 32be5a03951f..8cf0cc9b7caf 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -156,14 +156,15 @@ int of_irq_parse_raw(const __be32 *addr, struct
of_phandle_args *out_irq)
/* Now start the actual "proper" walk of the interrupt tree */
while (ipar != NULL) {
+ bool intc = of_property_read_bool(ipar,
"interrupt-controller");
+
/*
* Now check if cursor is an interrupt-controller and
* if it is then we are done, unless there is an
* interrupt-map which takes precedence.
*/
imap = of_get_property(ipar, "interrupt-map", &imaplen);
- if (imap == NULL &&
- of_property_read_bool(ipar, "interrupt-controller")) {
+ if (imap == NULL && intc) {
pr_debug(" -> got it !\n");
return 0;
}
@@ -244,8 +245,14 @@ int of_irq_parse_raw(const __be32 *addr, struct
of_phandle_args *out_irq)
pr_debug(" -> imaplen=%d\n", imaplen);
}
- if (!match)
+ if (!match) {
+ if (intc) {
+ pr_info("%pOF interrupt-map failed, using
interrupt-controller\n", ipar);
+ return 0;
+ }
+
goto fail;
+ }
/*
* Successfully parsed an interrrupt-map translation; copy new
The detecting of the ATA disks works with this patch! Well done!
Thanks a lot!
Sorry, I have read the patch more carefully and I have seen that it is
an analyse patch. It's not a fix. I was too quick with my joy.
- Christian
Re: [PASEMI] Nemo board doesn't recognize any ATA disks with the pci-v5.16 updates
On 11 November 2021 at 06:39 pm, Marc Zyngier wrote:
On Wed, 10 Nov 2021 18:07:24 +,
Christian Zigotzky wrote:
On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:
Hello,
The Nemo board [1] doesn't recognize any ATA disks with the
pci-v5.16 updates [2].
Error messages:
ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)
I was able to revert the new pci-v5.16 updates [2]. After a new
compiling, the kernel recognize all ATA disks correctly.
Could you please check the pci-v5.16 updates [2]?
Please find attached the kernel config.
Thanks,
Christian
[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4
Hi All,
Many thanks for your nice responses.
I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd
(of/irq: Allow matching of an interrupt-map local to an interrupt
controller) [2] is the first bad commit.
Can you please give the following hack a go and post the result
(including the full dmesg)?
Thanks,
M.
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 32be5a03951f..8cf0cc9b7caf 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -156,14 +156,15 @@ int of_irq_parse_raw(const __be32 *addr, struct
of_phandle_args *out_irq)
/* Now start the actual "proper" walk of the interrupt tree */
while (ipar != NULL) {
+ bool intc = of_property_read_bool(ipar, "interrupt-controller");
+
/*
* Now check if cursor is an interrupt-controller and
* if it is then we are done, unless there is an
* interrupt-map which takes precedence.
*/
imap = of_get_property(ipar, "interrupt-map", &imaplen);
- if (imap == NULL &&
- of_property_read_bool(ipar, "interrupt-controller")) {
+ if (imap == NULL && intc) {
pr_debug(" -> got it !\n");
return 0;
}
@@ -244,8 +245,14 @@ int of_irq_parse_raw(const __be32 *addr, struct
of_phandle_args *out_irq)
pr_debug(" -> imaplen=%d\n", imaplen);
}
- if (!match)
+ if (!match) {
+ if (intc) {
+ pr_info("%pOF interrupt-map failed, using
interrupt-controller\n", ipar);
+ return 0;
+ }
+
goto fail;
+ }
/*
* Successfully parsed an interrrupt-map translation; copy new
The detecting of the ATA disks works with this patch! Well done! Thanks
a lot!
dmesg:
[ 0.00] hash-mmu: Page sizes from device-tree:
[ 0.00] hash-mmu: base_shift=12: shift=12, sllp=0x,
avpnm=0x, tlbiel=1, penc=0
[ 0.00] hash-mmu: base_shift=16: shift=16, sllp=0x0110,
avpnm=0x, tlbiel=1, penc=3
[ 0.00] hash-mmu: base_shift=20: shift=20, sllp=0x0030,
avpnm=0x, tlbiel=0, penc=31
[ 0.00] hash-mmu: base_shift=24: shift=24, sllp=0x0100,
avpnm=0x0001, tlbiel=0, penc=0
[ 0.00] Page orders: linear mapping = 24, virtual = 12, io = 12,
vmemmap = 24
[ 0.00] Using 1TB segments
[ 0.00] hash-mmu: Initializing hash mmu with SLB
[ 0.00] Linux version
5.16.0-a6_A-EON_X1000_Nemo-12267-gdebe436e77c7-dirty
(christ...@cc-build-machine.a-eon.tld) (powerpc-linux-gnu-gcc (Ubuntu
7.5.0-3ubuntu1~18.04) 7.5.0, GNU ld (GNU Binutils for Ubuntu) 2.30) #1
SMP Fri Nov 12 09:30:39 CET 2021
[ 0.00] IOBMAP L2 allocated at: (ptrval)
[ 0.00] ioremap() called early from
.iommu_init_early_pasemi+0x10c/0x244. Use early_ioremap() instead
[ 0.00] Using A-EON Amigaone X1000 machine description
[ 0.00] Found legacy serial port 0 for /pxp@0,e000/serial@1d
[ 0.00] port=7f03f8, taddr=fcff03f8, irq=0, clk=1,
speed=115200
[ 0.00] Found legacy serial port 1 for /pxp@0,e000/serial@1d,1
[ 0.00] port=7f02f8, taddr=fcff02f8, irq=0, clk=1,
speed=115200
[ 0.00] CPU maps initialized for 1 thread per core
[ 0.00] (thread shift is 0)
[ 0.00] Allocated 2320 bytes for 2 pacas
[ 0.00] -
[ 0.00] phys_mem_size = 0x2
[ 0.00] dcache_bsize = 0x40
[ 0.00] icache_bsize = 0x40
[ 0.00] cpu_features = 0x01401182
[ 0.00] possible = 0x000ffbebb18f
[ 0.00] always = 0x0180
[ 0.00] cpu_user_features =
Re: [PASEMI] Nemo board doesn't recognize any ATA disks with the pci-v5.16 updates
On 11 November 2021 at 12:24 pm, Marc Zyngier wrote: On Thu, 11 Nov 2021 10:44:30 +, Christian Zigotzky wrote: On 11 November 2021 at 11:20 am, Marc Zyngier wrote: On Thu, 11 Nov 2021 07:47:08 +, Christian Zigotzky wrote: On 11 November 2021 at 08:13 am, Marc Zyngier wrote: On Thu, 11 Nov 2021 05:24:52 +, Christian Zigotzky wrote: Hello Marc, Here you are: https://forum.hyperion-entertainment.com/viewtopic.php?p=54406#p54406 This is not what I asked. I need the actual source file, or at the very least the compiled object (the /sys/firmware/fdt file, for example). Not an interpretation that I can't feed to the kernel. Without this, I can't debug your problem. We are very happy to have the patch for reverting the bad commit because we want to test the new PASEMI i2c driver with support for the Apple M1 [1] on our Nemo boards. You can revert the patch on your own. At this stage, we're not blindly reverting things in the tree, but instead trying to understand what is happening on your particular system. Thanks, M. I added a download link for the fdt file to the post [1]. Please read also Darren's comments in this post. Am I right in understanding that the upstream kernel does not support the machine out of the box, and that you actually have to apply out of tree patches to make it work? No, you aren't right. The upstream kernel supports the Nemo board out of the box. [1] That's not the way I interpret Darren's comments, but you surely know better than I do. I'll try to come up with something for you to test shortly. M. Great! Thanks a lot for your help! - Christian
Re: [PASEMI] Nemo board doesn't recognize any ATA disks with the pci-v5.16 updates
On 11 November 2021 at 11:20 am, Marc Zyngier wrote: On Thu, 11 Nov 2021 07:47:08 +, Christian Zigotzky wrote: On 11 November 2021 at 08:13 am, Marc Zyngier wrote: On Thu, 11 Nov 2021 05:24:52 +, Christian Zigotzky wrote: Hello Marc, Here you are: https://forum.hyperion-entertainment.com/viewtopic.php?p=54406#p54406 This is not what I asked. I need the actual source file, or at the very least the compiled object (the /sys/firmware/fdt file, for example). Not an interpretation that I can't feed to the kernel. Without this, I can't debug your problem. We are very happy to have the patch for reverting the bad commit because we want to test the new PASEMI i2c driver with support for the Apple M1 [1] on our Nemo boards. You can revert the patch on your own. At this stage, we're not blindly reverting things in the tree, but instead trying to understand what is happening on your particular system. Thanks, M. I added a download link for the fdt file to the post [1]. Please read also Darren's comments in this post. Am I right in understanding that the upstream kernel does not support the machine out of the box, and that you actually have to apply out of tree patches to make it work? No, you aren't right. The upstream kernel supports the Nemo board out of the box. [1] - Christian [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=Darren+Stevens
Re: [PASEMI] Nemo board doesn't recognize any ATA disks with the pci-v5.16 updates
On 11 November 2021 at 08:13 am, Marc Zyngier wrote:
On Thu, 11 Nov 2021 05:24:52 +,
Christian Zigotzky wrote:
On 10 November 2021 at 08:09 pm, Marc Zyngier wrote:
HI all,
On Wed, 10 Nov 2021 18:41:06 +,
Bjorn Helgaas wrote:
On Wed, Nov 10, 2021 at 07:07:24PM +0100, Christian Zigotzky wrote:
On 09 November 2021 at 03:45 pm, Christian Zigotzky wrote:
Hello,
The Nemo board [1] doesn't recognize any ATA disks with the pci-v5.16
updates [2].
Error messages:
ata4.00: gc timeout cmd 0xec
ata4.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata1.00: gc timeout cmd 0xec
ata1.00: failed to IDENTIFY (I/O error, error_mask=0x4)
ata3.00: gc timeout cmd 0xec
ata3.00: failed to IDENTIFY (I/O error, error_mask=0x4)
I was able to revert the new pci-v5.16 updates [2]. After a new
compiling, the kernel recognize all ATA disks correctly.
Could you please check the pci-v5.16 updates [2]?
Please find attached the kernel config.
Thanks,
Christian
[1] https://en.wikipedia.org/wiki/AmigaOne_X1000
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c5c62ddf88c34bc83b66e4ac9beb2bb0e1887d4
Hi All,
Many thanks for your nice responses.
I bisected today [1]. 0412841812265734c306ba5ef8088bcb64d5d3bd (of/irq:
Allow matching of an interrupt-map local to an interrupt controller) [2] is
the first bad commit.
I was able to revert the first bad commit [1]. After a new compiling, the
kernel detects all ATA disks without any problems.
I created a patch for an easy reverting the bad commit [1]. With this patch
we can do further our kernel tests.
Could you please check the first bad commit [2]?
Thanks,
Christian
[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=54398#p54398
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0412841812265734c306ba5ef8088bcb64d5d3bd
[+ Marc Zyngier, Alyssa Rosenzweig, Lorenzo Pieralisi, and Rob Herring
because of the first bad commit]
Thank you very much for the bisection and for also testing the revert!
It's easy enough to revert 041284181226 ("of/irq: Allow matching of an
interrupt-map local to an interrupt controller"), and it seems like
that's what we need to do. I have it tentatively queued up.
That commit was part of the new support for the Apple M1 PCIe
interface, and I don't know what effect a revert will have on that
support. Marc, Alyssa?
It is going to badly break the M1 support, as we won't be able to take
interrupts to detect that the PCIe link is up.
Before we apply a full blown revert and decide that this isn't
workable (and revert the whole M1 PCIe series, because they are
otherwise somewhat pointless), I'd like to understand *what* breaks
exactly.
Christian, could you point me to the full DT that this machine uses?
This would help understanding what goes wrong, and cook something for
you to test.
Thanks,
M.
Hello Marc,
Here you are:
https://forum.hyperion-entertainment.com/viewtopic.php?p=54406#p54406
This is not what I asked. I need the actual source file, or at the
very least the compiled object (the /sys/firmware/fdt file, for
example). Not an interpretation that I can't feed to the kernel.
Without this, I can't debug your problem.
We are very happy to have the patch for reverting the bad commit
because we want to test the new PASEMI i2c driver with support for the
Apple M1 [1] on our Nemo boards.
You can revert the patch on your own. At this stage, we're not blindly
reverting things in the tree, but instead trying to understand what
is happening on your particular system.
Thanks,
M.
I added a download link for the fdt file to the post [1]. Please read
also Darren's comments in this post.
Thanks
[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=54406#p54406
