FSL P5040 board doesn't boot after DRM updates (drm-next-2024-09-19)

On 28 September 2024 at 09:21am, Christian Zigotzky wrote:
 >
 >> On Sun, Sep 22, 2024 at 12:28 AM Christian Zigotzky
 >> [off-list ref] 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.
------------
 >>
 >> Can you attach your dmesg output?  There was a regression in the dma
 >> subsystem what was fixed by this commit:
 >>
 >> commit b348b6d17fd1d5d89b86db602f02be
 >> a54a754bd8
 >> Author: Leon Romanovsky [off-list ref]
 >> Date:   Sun Sep 22 21:09:48 2024 +0300
 >>
 >>    dma-mapping: report unlimited DMA addressing in IOMMU DMA path
 >>
 >> Alex
 >>

------------
Hi Alex,

I tested the latest Git kernel on my FSL P5040 board today and it 
doesn't boot. Our FSL P5020 boards boot without any problems.

I connected my FSL P5040 board with a serial cable to my PC for getting 
error messages. Unfortunately there aren't any error messages after the 
loading of the uImage.

This means, that the dma-mapping patch doesn't solve the boot issue.

Please check the latest DRM updates.

Thanks

Only a p5020 here so i can't test.
Sorry..

Dave



Op za 28 sep 2024 09:40 schreef Christian Zigotzky [off-list ref]:

On 28 September 2024 at 09:21am, Christian Zigotzky wrote:
 >
 >> On Sun, Sep 22, 2024 at 12:28 AM Christian Zigotzky
 >> [off-list ref] 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.
------------
 >>
 >> Can you attach your dmesg output?  There was a regression in the dma
 >> subsystem what was fixed by this commit:
 >>
 >> commit b348b6d17fd1d5d89b86db602f02be
 >> a54a754bd8
 >> Author: Leon Romanovsky [off-list ref]
 >> Date:   Sun Sep 22 21:09:48 2024 +0300
 >>
 >>    dma-mapping: report unlimited DMA addressing in IOMMU DMA path
 >>
 >> Alex
 >>

------------
Hi Alex,

I tested the latest Git kernel on my FSL P5040 board today and it
doesn't boot. Our FSL P5020 boards boot without any problems.

I connected my FSL P5040 board with a serial cable to my PC for getting
error messages. Unfortunately there aren't any error messages after the
loading of the uImage.

This means, that the dma-mapping patch doesn't solve the boot issue.

Please check the latest DRM updates.

Thanks

Hi Christian,

Le 28/09/2024 à 09:40, Christian Zigotzky a écrit :

On 28 September 2024 at 09:21am, Christian Zigotzky wrote:
 >
 >> On Sun, Sep 22, 2024 at 12:28 AM Christian Zigotzky
 >> [off-list ref] 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.
------------
 >>
 >> Can you attach your dmesg output?  There was a regression in the dma
 >> subsystem what was fixed by this commit:
 >>
 >> commit b348b6d17fd1d5d89b86db602f02be
 >> a54a754bd8
 >> Author: Leon Romanovsky [off-list ref]
 >> Date:   Sun Sep 22 21:09:48 2024 +0300
 >>
 >>    dma-mapping: report unlimited DMA addressing in IOMMU DMA path
 >>
 >> Alex
 >>

------------
Hi Alex,

I tested the latest Git kernel on my FSL P5040 board today and it 
doesn't boot. Our FSL P5020 boards boot without any problems.

I connected my FSL P5040 board with a serial cable to my PC for getting 
error messages. Unfortunately there aren't any error messages after the 
loading of the uImage.

This means, that the dma-mapping patch doesn't solve the boot issue.

Please check the latest DRM updates.

Can you bisect the problem ?

Christophe

Am 28.09.24 um 10:42 schrieb Christophe Leroy:

Hi Christian,

Le 28/09/2024 à 09:40, Christian Zigotzky a écrit :

quoted

On 28 September 2024 at 09:21am, Christian Zigotzky wrote:
 >
 >> On Sun, Sep 22, 2024 at 12:28 AM Christian Zigotzky
 >> [off-list ref] 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.
------------
 >>
 >> Can you attach your dmesg output?  There was a regression in the dma
 >> subsystem what was fixed by this commit:
 >>
 >> commit b348b6d17fd1d5d89b86db602f02be
 >> a54a754bd8
 >> Author: Leon Romanovsky [off-list ref]
 >> Date:   Sun Sep 22 21:09:48 2024 +0300
 >>
 >>    dma-mapping: report unlimited DMA addressing in IOMMU DMA path
 >>
 >> Alex
 >>

------------
Hi Alex,

I tested the latest Git kernel on my FSL P5040 board today and it 
doesn't boot. Our FSL P5020 boards boot without any problems.

I connected my FSL P5040 board with a serial cable to my PC for 
getting error messages. Unfortunately there aren't any error messages 
after the loading of the uImage.

This means, that the dma-mapping patch doesn't solve the boot issue.

Please check the latest DRM updates.

Can you bisect the problem ?

Christophe

I would like ... but I don't have time for it. Sorry.

On 28 September 2024 at 01:46pm, Christian Zigotzky wrote:

Am 28.09.24 um 10:42 schrieb Christophe Leroy:

quoted

Hi Christian,

Le 28/09/2024 à 09:40, Christian Zigotzky a écrit :

quoted

On 28 September 2024 at 09:21am, Christian Zigotzky wrote:
 >
 >> On Sun, Sep 22, 2024 at 12:28 AM Christian Zigotzky
 >> [off-list ref] 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.
------------
 >>
 >> Can you attach your dmesg output?  There was a regression in the 
dma
 >> subsystem what was fixed by this commit:
 >>
 >> commit b348b6d17fd1d5d89b86db602f02be
 >> a54a754bd8
 >> Author: Leon Romanovsky [off-list ref]
 >> Date:   Sun Sep 22 21:09:48 2024 +0300
 >>
 >>    dma-mapping: report unlimited DMA addressing in IOMMU DMA path
 >>
 >> Alex
 >>

------------
Hi Alex,

I tested the latest Git kernel on my FSL P5040 board today and it 
doesn't boot. Our FSL P5020 boards boot without any problems.

I connected my FSL P5040 board with a serial cable to my PC for 
getting error messages. Unfortunately there aren't any error 
messages after the loading of the uImage.

This means, that the dma-mapping patch doesn't solve the boot issue.

Please check the latest DRM updates.

Can you bisect the problem ?

Christophe

I would like ... but I don't have time for it. Sorry.

Hi All,

Sorry, I have forgotten to add the boot arguments "console=ttyS0,115200" 
for the connecting of my FSL P5040 board with a serial cable to my PC.

Now, I have a serial log file with Radeon error messages (kernel trace). :-)

Link: https://www.xenosoft.de/PuTTY_P5040_U-Boot.log

I hope, you have an idea. The FSL P5020 boards aren't affected.

Thanks,
Christian

Hello,

I tested the latest Git kernel with my VAPOR-X Radeon HD5870 1GB GDDR5 PCI-E DUAL DVI-I/HDMI/DP on my PASEMI Nemo board today.
Unfortunately it has the same issue like my FSL P5040 board.

I think it depends on which graphics card is used.

It could be, that FSL P5020 boards are also affected.

dmesg (via null modem RS-232 serial cable): https://www.xenosoft.de/PuTTY_P5040_U-Boot.log

Please check the drm-next-2024-09-19 updates: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=de848da12f752170c2ebe114804a985314fd5a6a

Thanks,
Christian

+ Wu Hoi Pok

This is likely related to the drm device rework.

Alex

On Sun, Sep 29, 2024 at 11:33 AM Christian Zigotzky
[off-list ref] wrote:

Hello,

I tested the latest Git kernel with my VAPOR-X Radeon HD5870 1GB GDDR5 PCI-E DUAL DVI-I/HDMI/DP on my PASEMI Nemo board today.
Unfortunately it has the same issue like my FSL P5040 board.

I think it depends on which graphics card is used.

It could be, that FSL P5020 boards are also affected.

dmesg (via null modem RS-232 serial cable): https://www.xenosoft.de/PuTTY_P5040_U-Boot.log

Please check the drm-next-2024-09-19 updates: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=de848da12f752170c2ebe114804a985314fd5a6a

Thanks,
Christian

On 30 September 2024 3:27pm, Alex Deucher [off-list ref] wrote:

+ Wu Hoi Pok

This is likely related to the drm device rework.

Alex

—————-

Hi All,

I was able to revert the drm-next-2024-09-19 updates for the RC1 of kernel 6.12.

This kernel works on all machines without any problems.

This means, the new Radeon DRM driver is unreliable after the DRM rework.

Please fix this issue because we can’t deliver the kernels with the new Radeon DRM driver.

Error log: https://www.xenosoft.de/PuTTY_P5040_U-Boot.log

Thanks,
Christian

Hi Thomas,

Could you help on this issue?
I do not have access to the hardware now.
Thank you.

Regards,
Wu Hoi Pok


On Tue, Oct 1, 2024 at 12:26 PM Christian Zigotzky
[off-list ref] wrote:

On 30 September 2024 3:27pm, Alex Deucher [off-list ref] wrote:

+ Wu Hoi Pok

This is likely related to the drm device rework.

Alex

—————-

Hi All,

I was able to revert the drm-next-2024-09-19 updates for the RC1 of kernel 6.12.

This kernel works on all machines without any problems.

This means, the new Radeon DRM driver is unreliable after the DRM rework.

Please fix this issue because we can’t deliver the kernels with the new Radeon DRM driver.

Error log: https://www.xenosoft.de/PuTTY_P5040_U-Boot.log

Thanks,
Christian

Hi All,

Le 01/10/2024 à 14:09, Hoi Pok Wu a écrit :

[Vous ne recevez pas souvent de courriers de wuhoipok@gmail.com. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]

Hi Thomas,

Could you help on this issue?
I do not have access to the hardware now.
Thank you.

The OOPS is from function drm_dp_aux_register(), exactly here below:

static inline const char *dev_name(const struct device *dev)
{
	/* Use the init name until the kobject becomes available */
	if (dev->init_name)

     1ae0:	e8 89 00 50 	ld      r4,80(r9)


As you see in registers dump, r9 register is NULL. That's dev which is NULL:

GPR00: c0000000005b74f0 c0000000800daf10 c0000000015a3600 c00000008033f7ec
GPR04: 0000000000000000 c000000001908f18 c000000080460c80 ffffffffc0c0c0c0
GPR08: c000000080f74008 0000000000000000 0000000000000003 c000000080f74008
GPR12: 0000000048000828 c00000003fffeac0 0000000000000003 0000000001000000
GPR16: c0000000804eaeca 0000000000000013 0000000000003113 0000000000000000
GPR20: 0000000000000008 c0000000800db208 000000000000000a c0000000014d6868
GPR24: 0000000000000000 0000000000000001 c0000000800db29c c0000000800db250
GPR28: c000000080bd8040 0000000000000001 c000000080f74000 c00000008033f4a0

Full dump below:

0000000000001a5c <drm_dp_aux_register>:
{
     1a5c:	3c 4c 00 00 	addis   r2,r12,0
			1a5e: R_PPC64_REL16_HA	.TOC.+0x2
     1a60:	38 42 00 00 	addi    r2,r2,0
			1a62: R_PPC64_REL16_LO	.TOC.+0x6
     1a64:	7c 08 02 a6 	mflr    r0
     1a68:	fb e1 ff f8 	std     r31,-8(r1)
     1a6c:	f8 01 00 10 	std     r0,16(r1)
     1a70:	7c 7f 1b 78 	mr      r31,r3
     1a74:	f8 21 ff d1 	stdu    r1,-48(r1)
	WARN_ON_ONCE(!aux->drm_dev);
     1a78:	e9 23 03 38 	ld      r9,824(r3)
     1a7c:	2f a9 00 00 	cmpdi   cr7,r9,0
     1a80:	41 de 00 90 	beq-    cr7,1b10 <drm_dp_aux_register+0xb4>
	if (!aux->ddc.algo)
     1a84:	e9 3f 00 18 	ld      r9,24(r31)
     1a88:	2f a9 00 00 	cmpdi   cr7,r9,0
     1a8c:	41 de 00 74 	beq-    cr7,1b00 <drm_dp_aux_register+0xa4>
	strscpy(aux->ddc.name, aux->name ? aux->name : dev_name(aux->dev),
     1a90:	e8 9f 00 00 	ld      r4,0(r31)
	aux->ddc.owner = THIS_MODULE;
     1a94:	39 40 00 00 	li      r10,0
	aux->ddc.dev.parent = aux->dev;
     1a98:	e9 3f 03 30 	ld      r9,816(r31)
	strscpy(aux->ddc.name, aux->name ? aux->name : dev_name(aux->dev),
     1a9c:	38 7f 02 74 	addi    r3,r31,628
	aux->ddc.owner = THIS_MODULE;
     1aa0:	f9 5f 00 08 	std     r10,8(r31)
	strscpy(aux->ddc.name, aux->name ? aux->name : dev_name(aux->dev),
     1aa4:	2f a4 00 00 	cmpdi   cr7,r4,0
	aux->ddc.dev.parent = aux->dev;
     1aa8:	f9 3f 00 b8 	std     r9,184(r31)
	strscpy(aux->ddc.name, aux->name ? aux->name : dev_name(aux->dev),
     1aac:	41 de 00 34 	beq-    cr7,1ae0 <drm_dp_aux_register+0x84>
     1ab0:	38 a0 00 30 	li      r5,48
     1ab4:	48 00 00 01 	bl      1ab4 <drm_dp_aux_register+0x58>
			1ab4: R_PPC64_REL24	sized_strscpy
     1ab8:	60 00 00 00 	nop
	ret = i2c_add_adapter(&aux->ddc);
     1abc:	38 7f 00 08 	addi    r3,r31,8
     1ac0:	48 00 00 01 	bl      1ac0 <drm_dp_aux_register+0x64>
			1ac0: R_PPC64_REL24	i2c_add_adapter
     1ac4:	60 00 00 00 	nop
}
     1ac8:	38 21 00 30 	addi    r1,r1,48
     1acc:	e8 01 00 10 	ld      r0,16(r1)
     1ad0:	eb e1 ff f8 	ld      r31,-8(r1)
     1ad4:	7c 08 03 a6 	mtlr    r0
     1ad8:	4e 80 00 20 	blr
     1adc:	60 00 00 00 	nop
  * Return: The kobject name of the device, or its initial name if 
unavailable.
  */
static inline const char *dev_name(const struct device *dev)
{
	/* Use the init name until the kobject becomes available */
	if (dev->init_name)
     1ae0:	e8 89 00 50 	ld      r4,80(r9)
     1ae4:	2f a4 00 00 	cmpdi   cr7,r4,0
     1ae8:	40 fe ff c8 	bne+    cr7,1ab0 <drm_dp_aux_register+0x54>
		return dev->init_name;

	return kobject_name(&dev->kobj);
     1aec:	e8 89 00 00 	ld      r4,0(r9)
     1af0:	4b ff ff c0 	b       1ab0 <drm_dp_aux_register+0x54>
     1af4:	60 00 00 00 	nop
     1af8:	60 00 00 00 	nop
     1afc:	60 00 00 00 	nop
		drm_dp_aux_init(aux);
     1b00:	7f e3 fb 78 	mr      r3,r31
     1b04:	48 00 00 01 	bl      1b04 <drm_dp_aux_register+0xa8>
			1b04: R_PPC64_REL24	drm_dp_aux_init
     1b08:	4b ff ff 88 	b       1a90 <drm_dp_aux_register+0x34>
     1b0c:	60 00 00 00 	nop
	WARN_ON_ONCE(!aux->drm_dev);
     1b10:	0f e0 00 00 	twui    r0,0
     1b14:	4b ff ff 70 	b       1a84 <drm_dp_aux_register+0x28>

Regards,
Wu Hoi Pok


On Tue, Oct 1, 2024 at 12:26 PM Christian Zigotzky
[off-list ref] wrote:

quoted

On 30 September 2024 3:27pm, Alex Deucher [off-list ref] wrote:

+ Wu Hoi Pok

This is likely related to the drm device rework.

Alex

—————-

Hi All,

I was able to revert the drm-next-2024-09-19 updates for the RC1 of kernel 6.12.

This kernel works on all machines without any problems.

This means, the new Radeon DRM driver is unreliable after the DRM rework.

Please fix this issue because we can’t deliver the kernels with the new Radeon DRM driver.

Error log: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.xenosoft.de%2FPuTTY_P5040_U-Boot.log&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C9b40f906e2f2493cb25908dce211ee23%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638633814783011669%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C60000%7C%7C%7C&sdata=fgAj0osIOyJtNrzUKp%2Bpq0NN1sGW2bqGm8nXYj88Ne0%3D&reserved=0

Thanks,
Christian

I will look into this and get back to you. Thank you.


On Tue, Oct 1, 2024 at 8:23 PM Christophe Leroy
[off-list ref] wrote:

Hi All,

Le 01/10/2024 à 14:09, Hoi Pok Wu a écrit :

quoted

[Vous ne recevez pas souvent de courriers de wuhoipok@gmail.com. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]

Hi Thomas,

Could you help on this issue?
I do not have access to the hardware now.
Thank you.

The OOPS is from function drm_dp_aux_register(), exactly here below:

static inline const char *dev_name(const struct device *dev)
{
        /* Use the init name until the kobject becomes available */
        if (dev->init_name)

     1ae0:      e8 89 00 50     ld      r4,80(r9)


As you see in registers dump, r9 register is NULL. That's dev which is NULL:

GPR00: c0000000005b74f0 c0000000800daf10 c0000000015a3600 c00000008033f7ec
GPR04: 0000000000000000 c000000001908f18 c000000080460c80 ffffffffc0c0c0c0
GPR08: c000000080f74008 0000000000000000 0000000000000003 c000000080f74008
GPR12: 0000000048000828 c00000003fffeac0 0000000000000003 0000000001000000
GPR16: c0000000804eaeca 0000000000000013 0000000000003113 0000000000000000
GPR20: 0000000000000008 c0000000800db208 000000000000000a c0000000014d6868
GPR24: 0000000000000000 0000000000000001 c0000000800db29c c0000000800db250
GPR28: c000000080bd8040 0000000000000001 c000000080f74000 c00000008033f4a0

Full dump below:

0000000000001a5c <drm_dp_aux_register>:
{
     1a5c:      3c 4c 00 00     addis   r2,r12,0
                        1a5e: R_PPC64_REL16_HA  .TOC.+0x2
     1a60:      38 42 00 00     addi    r2,r2,0
                        1a62: R_PPC64_REL16_LO  .TOC.+0x6
     1a64:      7c 08 02 a6     mflr    r0
     1a68:      fb e1 ff f8     std     r31,-8(r1)
     1a6c:      f8 01 00 10     std     r0,16(r1)
     1a70:      7c 7f 1b 78     mr      r31,r3
     1a74:      f8 21 ff d1     stdu    r1,-48(r1)
        WARN_ON_ONCE(!aux->drm_dev);
     1a78:      e9 23 03 38     ld      r9,824(r3)
     1a7c:      2f a9 00 00     cmpdi   cr7,r9,0
     1a80:      41 de 00 90     beq-    cr7,1b10 <drm_dp_aux_register+0xb4>
        if (!aux->ddc.algo)
     1a84:      e9 3f 00 18     ld      r9,24(r31)
     1a88:      2f a9 00 00     cmpdi   cr7,r9,0
     1a8c:      41 de 00 74     beq-    cr7,1b00 <drm_dp_aux_register+0xa4>
        strscpy(aux->ddc.name, aux->name ? aux->name : dev_name(aux->dev),
     1a90:      e8 9f 00 00     ld      r4,0(r31)
        aux->ddc.owner = THIS_MODULE;
     1a94:      39 40 00 00     li      r10,0
        aux->ddc.dev.parent = aux->dev;
     1a98:      e9 3f 03 30     ld      r9,816(r31)
        strscpy(aux->ddc.name, aux->name ? aux->name : dev_name(aux->dev),
     1a9c:      38 7f 02 74     addi    r3,r31,628
        aux->ddc.owner = THIS_MODULE;
     1aa0:      f9 5f 00 08     std     r10,8(r31)
        strscpy(aux->ddc.name, aux->name ? aux->name : dev_name(aux->dev),
     1aa4:      2f a4 00 00     cmpdi   cr7,r4,0
        aux->ddc.dev.parent = aux->dev;
     1aa8:      f9 3f 00 b8     std     r9,184(r31)
        strscpy(aux->ddc.name, aux->name ? aux->name : dev_name(aux->dev),
     1aac:      41 de 00 34     beq-    cr7,1ae0 <drm_dp_aux_register+0x84>
     1ab0:      38 a0 00 30     li      r5,48
     1ab4:      48 00 00 01     bl      1ab4 <drm_dp_aux_register+0x58>
                        1ab4: R_PPC64_REL24     sized_strscpy
     1ab8:      60 00 00 00     nop
        ret = i2c_add_adapter(&aux->ddc);
     1abc:      38 7f 00 08     addi    r3,r31,8
     1ac0:      48 00 00 01     bl      1ac0 <drm_dp_aux_register+0x64>
                        1ac0: R_PPC64_REL24     i2c_add_adapter
     1ac4:      60 00 00 00     nop
}
     1ac8:      38 21 00 30     addi    r1,r1,48
     1acc:      e8 01 00 10     ld      r0,16(r1)
     1ad0:      eb e1 ff f8     ld      r31,-8(r1)
     1ad4:      7c 08 03 a6     mtlr    r0
     1ad8:      4e 80 00 20     blr
     1adc:      60 00 00 00     nop
  * Return: The kobject name of the device, or its initial name if
unavailable.
  */
static inline const char *dev_name(const struct device *dev)
{
        /* Use the init name until the kobject becomes available */
        if (dev->init_name)
     1ae0:      e8 89 00 50     ld      r4,80(r9)
     1ae4:      2f a4 00 00     cmpdi   cr7,r4,0
     1ae8:      40 fe ff c8     bne+    cr7,1ab0 <drm_dp_aux_register+0x54>
                return dev->init_name;

        return kobject_name(&dev->kobj);
     1aec:      e8 89 00 00     ld      r4,0(r9)
     1af0:      4b ff ff c0     b       1ab0 <drm_dp_aux_register+0x54>
     1af4:      60 00 00 00     nop
     1af8:      60 00 00 00     nop
     1afc:      60 00 00 00     nop
                drm_dp_aux_init(aux);
     1b00:      7f e3 fb 78     mr      r3,r31
     1b04:      48 00 00 01     bl      1b04 <drm_dp_aux_register+0xa8>
                        1b04: R_PPC64_REL24     drm_dp_aux_init
     1b08:      4b ff ff 88     b       1a90 <drm_dp_aux_register+0x34>
     1b0c:      60 00 00 00     nop
        WARN_ON_ONCE(!aux->drm_dev);
     1b10:      0f e0 00 00     twui    r0,0
     1b14:      4b ff ff 70     b       1a84 <drm_dp_aux_register+0x28>

quoted

Regards,
Wu Hoi Pok


On Tue, Oct 1, 2024 at 12:26 PM Christian Zigotzky
[off-list ref] wrote:

quoted

On 30 September 2024 3:27pm, Alex Deucher [off-list ref] wrote:

+ Wu Hoi Pok

This is likely related to the drm device rework.

Alex

—————-

Hi All,

I was able to revert the drm-next-2024-09-19 updates for the RC1 of kernel 6.12.

This kernel works on all machines without any problems.

This means, the new Radeon DRM driver is unreliable after the DRM rework.

Please fix this issue because we can’t deliver the kernels with the new Radeon DRM driver.

Error log: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.xenosoft.de%2FPuTTY_P5040_U-Boot.log&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C9b40f906e2f2493cb25908dce211ee23%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638633814783011669%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C60000%7C%7C%7C&sdata=fgAj0osIOyJtNrzUKp%2Bpq0NN1sGW2bqGm8nXYj88Ne0%3D&reserved=0

Thanks,
Christian

Thanks to Christophe.
I have figured out what happened.
The connector is registered before the device,
where drm_connector_register() states that,
drm_dev_register() has to be called before it.

Assuming this is the fix, I will send the patch for testing soon.

On Tue, Oct 1, 2024 at 8:23 PM Christophe Leroy
[off-list ref] wrote:

Hi All,

Le 01/10/2024 à 14:09, Hoi Pok Wu a écrit :

quoted

[Vous ne recevez pas souvent de courriers de wuhoipok@gmail.com. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]

Hi Thomas,

Could you help on this issue?
I do not have access to the hardware now.
Thank you.

The OOPS is from function drm_dp_aux_register(), exactly here below:

static inline const char *dev_name(const struct device *dev)
{
        /* Use the init name until the kobject becomes available */
        if (dev->init_name)

     1ae0:      e8 89 00 50     ld      r4,80(r9)


As you see in registers dump, r9 register is NULL. That's dev which is NULL:

GPR00: c0000000005b74f0 c0000000800daf10 c0000000015a3600 c00000008033f7ec
GPR04: 0000000000000000 c000000001908f18 c000000080460c80 ffffffffc0c0c0c0
GPR08: c000000080f74008 0000000000000000 0000000000000003 c000000080f74008
GPR12: 0000000048000828 c00000003fffeac0 0000000000000003 0000000001000000
GPR16: c0000000804eaeca 0000000000000013 0000000000003113 0000000000000000
GPR20: 0000000000000008 c0000000800db208 000000000000000a c0000000014d6868
GPR24: 0000000000000000 0000000000000001 c0000000800db29c c0000000800db250
GPR28: c000000080bd8040 0000000000000001 c000000080f74000 c00000008033f4a0

Full dump below:

0000000000001a5c <drm_dp_aux_register>:
{
     1a5c:      3c 4c 00 00     addis   r2,r12,0
                        1a5e: R_PPC64_REL16_HA  .TOC.+0x2
     1a60:      38 42 00 00     addi    r2,r2,0
                        1a62: R_PPC64_REL16_LO  .TOC.+0x6
     1a64:      7c 08 02 a6     mflr    r0
     1a68:      fb e1 ff f8     std     r31,-8(r1)
     1a6c:      f8 01 00 10     std     r0,16(r1)
     1a70:      7c 7f 1b 78     mr      r31,r3
     1a74:      f8 21 ff d1     stdu    r1,-48(r1)
        WARN_ON_ONCE(!aux->drm_dev);
     1a78:      e9 23 03 38     ld      r9,824(r3)
     1a7c:      2f a9 00 00     cmpdi   cr7,r9,0
     1a80:      41 de 00 90     beq-    cr7,1b10 <drm_dp_aux_register+0xb4>
        if (!aux->ddc.algo)
     1a84:      e9 3f 00 18     ld      r9,24(r31)
     1a88:      2f a9 00 00     cmpdi   cr7,r9,0
     1a8c:      41 de 00 74     beq-    cr7,1b00 <drm_dp_aux_register+0xa4>
        strscpy(aux->ddc.name, aux->name ? aux->name : dev_name(aux->dev),
     1a90:      e8 9f 00 00     ld      r4,0(r31)
        aux->ddc.owner = THIS_MODULE;
     1a94:      39 40 00 00     li      r10,0
        aux->ddc.dev.parent = aux->dev;
     1a98:      e9 3f 03 30     ld      r9,816(r31)
        strscpy(aux->ddc.name, aux->name ? aux->name : dev_name(aux->dev),
     1a9c:      38 7f 02 74     addi    r3,r31,628
        aux->ddc.owner = THIS_MODULE;
     1aa0:      f9 5f 00 08     std     r10,8(r31)
        strscpy(aux->ddc.name, aux->name ? aux->name : dev_name(aux->dev),
     1aa4:      2f a4 00 00     cmpdi   cr7,r4,0
        aux->ddc.dev.parent = aux->dev;
     1aa8:      f9 3f 00 b8     std     r9,184(r31)
        strscpy(aux->ddc.name, aux->name ? aux->name : dev_name(aux->dev),
     1aac:      41 de 00 34     beq-    cr7,1ae0 <drm_dp_aux_register+0x84>
     1ab0:      38 a0 00 30     li      r5,48
     1ab4:      48 00 00 01     bl      1ab4 <drm_dp_aux_register+0x58>
                        1ab4: R_PPC64_REL24     sized_strscpy
     1ab8:      60 00 00 00     nop
        ret = i2c_add_adapter(&aux->ddc);
     1abc:      38 7f 00 08     addi    r3,r31,8
     1ac0:      48 00 00 01     bl      1ac0 <drm_dp_aux_register+0x64>
                        1ac0: R_PPC64_REL24     i2c_add_adapter
     1ac4:      60 00 00 00     nop
}
     1ac8:      38 21 00 30     addi    r1,r1,48
     1acc:      e8 01 00 10     ld      r0,16(r1)
     1ad0:      eb e1 ff f8     ld      r31,-8(r1)
     1ad4:      7c 08 03 a6     mtlr    r0
     1ad8:      4e 80 00 20     blr
     1adc:      60 00 00 00     nop
  * Return: The kobject name of the device, or its initial name if
unavailable.
  */
static inline const char *dev_name(const struct device *dev)
{
        /* Use the init name until the kobject becomes available */
        if (dev->init_name)
     1ae0:      e8 89 00 50     ld      r4,80(r9)
     1ae4:      2f a4 00 00     cmpdi   cr7,r4,0
     1ae8:      40 fe ff c8     bne+    cr7,1ab0 <drm_dp_aux_register+0x54>
                return dev->init_name;

        return kobject_name(&dev->kobj);
     1aec:      e8 89 00 00     ld      r4,0(r9)
     1af0:      4b ff ff c0     b       1ab0 <drm_dp_aux_register+0x54>
     1af4:      60 00 00 00     nop
     1af8:      60 00 00 00     nop
     1afc:      60 00 00 00     nop
                drm_dp_aux_init(aux);
     1b00:      7f e3 fb 78     mr      r3,r31
     1b04:      48 00 00 01     bl      1b04 <drm_dp_aux_register+0xa8>
                        1b04: R_PPC64_REL24     drm_dp_aux_init
     1b08:      4b ff ff 88     b       1a90 <drm_dp_aux_register+0x34>
     1b0c:      60 00 00 00     nop
        WARN_ON_ONCE(!aux->drm_dev);
     1b10:      0f e0 00 00     twui    r0,0
     1b14:      4b ff ff 70     b       1a84 <drm_dp_aux_register+0x28>

quoted

Regards,
Wu Hoi Pok


On Tue, Oct 1, 2024 at 12:26 PM Christian Zigotzky
[off-list ref] wrote:

quoted

On 30 September 2024 3:27pm, Alex Deucher [off-list ref] wrote:

+ Wu Hoi Pok

This is likely related to the drm device rework.

Alex

—————-

Hi All,

I was able to revert the drm-next-2024-09-19 updates for the RC1 of kernel 6.12.

This kernel works on all machines without any problems.

This means, the new Radeon DRM driver is unreliable after the DRM rework.

Please fix this issue because we can’t deliver the kernels with the new Radeon DRM driver.

Error log: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.xenosoft.de%2FPuTTY_P5040_U-Boot.log&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C9b40f906e2f2493cb25908dce211ee23%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638633814783011669%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C60000%7C%7C%7C&sdata=fgAj0osIOyJtNrzUKp%2Bpq0NN1sGW2bqGm8nXYj88Ne0%3D&reserved=0

Thanks,
Christian

On 02 October 2024 at 3:43pm, Hoi Pok Wu [off-list ref] wrote:

Thanks to Christophe.
I have figured out what happened.
The connector is registered before the device,
where drm_connector_register() states that,
drm_dev_register() has to be called before it.

Assuming this is the fix, I will send the patch for testing soon.

- - -

Hi Hoi Pok Wu,

Many thanks for your help! I am looking forward to your patch.
I could try it out tomorrow.

Thanks,
Christian