Hi All,
Le 01/10/2024 à 14:09, Hoi Pok Wu a écrit :
[Vous ne recevez pas souvent de courriers de wuhoipok@xxxxxxxxx. 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
<chzigotzky@xxxxxxxxxxx> wrote:
On 30 September 2024 3:27pm, Alex Deucher <alexdeucher@xxxxxxxxx> 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
