Re: Kernel doesn't boot after DRM updates (drm-next-2024-09-19)
From: Hoi Pok Wu <hidden>
Date: 2024-10-02 13:43:30
Also in:
dri-devel
Possibly related (same subject, not in this thread)
- 2024-10-07 · Kernel doesn't boot after DRM updates (drm-next-2024-09-19) · Christian Zigotzky <hidden>
- 2024-09-30 · Kernel doesn't boot after DRM updates (drm-next-2024-09-19) · Christian Zigotzky <hidden>
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