[PATCH] drm/radeon: always set GEM function pointer

[PATCH] drm/radeon: always set GEM function pointer

[Christian König]

Make sure to always set the GEM function pointer even for in kernel
allocations. This fixes a NULL pointer deref caused by switching to GEM
references.

Signed-off-by: Christian König <christian.koenig@amd.com>
Fixes: fd69ef05029f ("drm/radeon: use GEM references instead of TTMs")
---
 drivers/gpu/drm/radeon/radeon_gem.c    | 3 ---
 drivers/gpu/drm/radeon/radeon_object.c | 1 +
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c
index 9735f4968b86..bf2d4b16dc2a 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -44,8 +44,6 @@ struct sg_table *radeon_gem_prime_get_sg_table(struct drm_gem_object *obj);
 int radeon_gem_prime_pin(struct drm_gem_object *obj);
 void radeon_gem_prime_unpin(struct drm_gem_object *obj);
 
-const struct drm_gem_object_funcs radeon_gem_object_funcs;
-
 static vm_fault_t radeon_gem_fault(struct vm_fault *vmf)
 {
 	struct ttm_buffer_object *bo = vmf->vma->vm_private_data;
@@ -132,7 +130,6 @@ int radeon_gem_object_create(struct radeon_device *rdev, unsigned long size,
 		return r;
 	}
 	*obj = &robj->tbo.base;
-	(*obj)->funcs = &radeon_gem_object_funcs;
 	robj->pid = task_pid_nr(current);
 
 	mutex_lock(&rdev->gem.mutex);
diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c
index d0e4b43d155c..7672404fdb29 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -151,6 +151,7 @@ int radeon_bo_create(struct radeon_device *rdev,
 	if (bo == NULL)
 		return -ENOMEM;
 	drm_gem_private_object_init(rdev_to_drm(rdev), &bo->tbo.base, size);
+	bo->tbo.base.funcs = &radeon_gem_object_funcs;
 	bo->rdev = rdev;
 	bo->surface_reg = -1;
 	INIT_LIST_HEAD(&bo->list);
-- 
2.34.1

Re: [PATCH] drm/radeon: always set GEM function pointer

[Alex Deucher]

Add a few people.

This should fix the radeon ttm gem conversion.

Alex



On Mon, Oct 7, 2024 at 2:33 PM Christian König
<ckoenig.leichtzumerken@gmail.com> wrote:
>
> Make sure to always set the GEM function pointer even for in kernel
> allocations. This fixes a NULL pointer deref caused by switching to GEM
> references.
>
> Signed-off-by: Christian König <christian.koenig@amd.com>
> Fixes: fd69ef05029f ("drm/radeon: use GEM references instead of TTMs")
> ---
>  drivers/gpu/drm/radeon/radeon_gem.c    | 3 ---
>  drivers/gpu/drm/radeon/radeon_object.c | 1 +
>  2 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c
> index 9735f4968b86..bf2d4b16dc2a 100644
> --- a/drivers/gpu/drm/radeon/radeon_gem.c
> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
> @@ -44,8 +44,6 @@ struct sg_table *radeon_gem_prime_get_sg_table(struct drm_gem_object *obj);
>  int radeon_gem_prime_pin(struct drm_gem_object *obj);
>  void radeon_gem_prime_unpin(struct drm_gem_object *obj);
>
> -const struct drm_gem_object_funcs radeon_gem_object_funcs;
> -
>  static vm_fault_t radeon_gem_fault(struct vm_fault *vmf)
>  {
>         struct ttm_buffer_object *bo = vmf->vma->vm_private_data;
> @@ -132,7 +130,6 @@ int radeon_gem_object_create(struct radeon_device *rdev, unsigned long size,
>                 return r;
>         }
>         *obj = &robj->tbo.base;
> -       (*obj)->funcs = &radeon_gem_object_funcs;
>         robj->pid = task_pid_nr(current);
>
>         mutex_lock(&rdev->gem.mutex);
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c
> index d0e4b43d155c..7672404fdb29 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -151,6 +151,7 @@ int radeon_bo_create(struct radeon_device *rdev,
>         if (bo == NULL)
>                 return -ENOMEM;
>         drm_gem_private_object_init(rdev_to_drm(rdev), &bo->tbo.base, size);
> +       bo->tbo.base.funcs = &radeon_gem_object_funcs;
>         bo->rdev = rdev;
>         bo->surface_reg = -1;
>         INIT_LIST_HEAD(&bo->list);
> --
> 2.34.1
>

Re: [PATCH] drm/radeon: always set GEM function pointer

[Alex Deucher]

On Mon, Oct 7, 2024 at 2:33 PM Christian König
<ckoenig.leichtzumerken@gmail.com> wrote:
>
> Make sure to always set the GEM function pointer even for in kernel
> allocations. This fixes a NULL pointer deref caused by switching to GEM
> references.
>
> Signed-off-by: Christian König <christian.koenig@amd.com>
> Fixes: fd69ef05029f ("drm/radeon: use GEM references instead of TTMs")

Acked-by: Alex Deucher <alexander.deucher@amd.com>

> ---
>  drivers/gpu/drm/radeon/radeon_gem.c    | 3 ---
>  drivers/gpu/drm/radeon/radeon_object.c | 1 +
>  2 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c
> index 9735f4968b86..bf2d4b16dc2a 100644
> --- a/drivers/gpu/drm/radeon/radeon_gem.c
> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
> @@ -44,8 +44,6 @@ struct sg_table *radeon_gem_prime_get_sg_table(struct drm_gem_object *obj);
>  int radeon_gem_prime_pin(struct drm_gem_object *obj);
>  void radeon_gem_prime_unpin(struct drm_gem_object *obj);
>
> -const struct drm_gem_object_funcs radeon_gem_object_funcs;
> -
>  static vm_fault_t radeon_gem_fault(struct vm_fault *vmf)
>  {
>         struct ttm_buffer_object *bo = vmf->vma->vm_private_data;
> @@ -132,7 +130,6 @@ int radeon_gem_object_create(struct radeon_device *rdev, unsigned long size,
>                 return r;
>         }
>         *obj = &robj->tbo.base;
> -       (*obj)->funcs = &radeon_gem_object_funcs;
>         robj->pid = task_pid_nr(current);
>
>         mutex_lock(&rdev->gem.mutex);
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c
> index d0e4b43d155c..7672404fdb29 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -151,6 +151,7 @@ int radeon_bo_create(struct radeon_device *rdev,
>         if (bo == NULL)
>                 return -ENOMEM;
>         drm_gem_private_object_init(rdev_to_drm(rdev), &bo->tbo.base, size);
> +       bo->tbo.base.funcs = &radeon_gem_object_funcs;
>         bo->rdev = rdev;
>         bo->surface_reg = -1;
>         INIT_LIST_HEAD(&bo->list);
> --
> 2.34.1
>

[PATCH] drm/radeon: always set GEM function pointer

[Christian Zigotzky]

Hi All,

I have released the RC2 of kernel 6.12 with Christian Koenig’s patch for the X1000 and X5000.

Download and further information: https://github.com/chzigotzky/kernels/releases/tag/v6.12.0-rc2

Please test the kernels because of the second Radeon DRM driver issue.

Thanks,
Christian

> Am 07.10.2024 um 20:36 schrieb Alex Deucher <alexdeucher@gmail.com>:
> 
> Add a few people.
> 
> This should fix the radeon ttm gem conversion.
> 
> Alex
> 
> 
> 
>> On Mon, Oct 7, 2024 at 2:33 PM Christian König
>> <ckoenig.leichtzumerken@gmail.com> wrote:
>> 
>> Make sure to always set the GEM function pointer even for in kernel
>> allocations. This fixes a NULL pointer deref caused by switching to GEM
>> references.
>> 
>> Signed-off-by: Christian König <christian.koenig@amd.com>
>> Fixes: fd69ef05029f ("drm/radeon: use GEM references instead of TTMs")
>> ---
>> drivers/gpu/drm/radeon/radeon_gem.c    | 3 ---
>> drivers/gpu/drm/radeon/radeon_object.c | 1 +
>> 2 files changed, 1 insertion(+), 3 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c
>> index 9735f4968b86..bf2d4b16dc2a 100644
>> --- a/drivers/gpu/drm/radeon/radeon_gem.c
>> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
>> @@ -44,8 +44,6 @@ struct sg_table *radeon_gem_prime_get_sg_table(struct drm_gem_object *obj);
>> int radeon_gem_prime_pin(struct drm_gem_object *obj);
>> void radeon_gem_prime_unpin(struct drm_gem_object *obj);
>> 
>> -const struct drm_gem_object_funcs radeon_gem_object_funcs;
>> -
>> static vm_fault_t radeon_gem_fault(struct vm_fault *vmf)
>> {
>>        struct ttm_buffer_object *bo = vmf->vma->vm_private_data;
>> @@ -132,7 +130,6 @@ int radeon_gem_object_create(struct radeon_device *rdev, unsigned long size,
>>                return r;
>>        }
>>        *obj = &robj->tbo.base;
>> -       (*obj)->funcs = &radeon_gem_object_funcs;
>>        robj->pid = task_pid_nr(current);
>> 
>>        mutex_lock(&rdev->gem.mutex);
>> diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c
>> index d0e4b43d155c..7672404fdb29 100644
>> --- a/drivers/gpu/drm/radeon/radeon_object.c
>> +++ b/drivers/gpu/drm/radeon/radeon_object.c
>> @@ -151,6 +151,7 @@ int radeon_bo_create(struct radeon_device *rdev,
>>        if (bo == NULL)
>>                return -ENOMEM;
>>        drm_gem_private_object_init(rdev_to_drm(rdev), &bo->tbo.base, size);
>> +       bo->tbo.base.funcs = &radeon_gem_object_funcs;
>>        bo->rdev = rdev;
>>        bo->surface_reg = -1;
>>        INIT_LIST_HEAD(&bo->list);
>> --
>> 2.34.1
>> 

Re: [PATCH] drm/radeon: always set GEM function pointer

[Hans de Goede]

Hi,

On 7-Oct-24 8:36 PM, Alex Deucher wrote:
> Add a few people.

Thank you.

> This should fix the radeon ttm gem conversion.
>
> On Mon, Oct 7, 2024 at 2:33 PM Christian König
> <ckoenig.leichtzumerken@gmail.com> wrote:
>>
>> Make sure to always set the GEM function pointer even for in kernel
>> allocations. This fixes a NULL pointer deref caused by switching to GEM
>> references.
>>
>> Signed-off-by: Christian König <christian.koenig@amd.com>
>> Fixes: fd69ef05029f ("drm/radeon: use GEM references instead of TTMs")

I can confirm that this fixes gdm not showing with 6.12-rc1
(after the "drm/radeon: add late_register for connector" fix):

Tested-by: Hans de Goede <hdegoede@redhat.com>

Regards,

Hans



>> ---
>>  drivers/gpu/drm/radeon/radeon_gem.c    | 3 ---
>>  drivers/gpu/drm/radeon/radeon_object.c | 1 +
>>  2 files changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c
>> index 9735f4968b86..bf2d4b16dc2a 100644
>> --- a/drivers/gpu/drm/radeon/radeon_gem.c
>> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
>> @@ -44,8 +44,6 @@ struct sg_table *radeon_gem_prime_get_sg_table(struct drm_gem_object *obj);
>>  int radeon_gem_prime_pin(struct drm_gem_object *obj);
>>  void radeon_gem_prime_unpin(struct drm_gem_object *obj);
>>
>> -const struct drm_gem_object_funcs radeon_gem_object_funcs;
>> -
>>  static vm_fault_t radeon_gem_fault(struct vm_fault *vmf)
>>  {
>>         struct ttm_buffer_object *bo = vmf->vma->vm_private_data;
>> @@ -132,7 +130,6 @@ int radeon_gem_object_create(struct radeon_device *rdev, unsigned long size,
>>                 return r;
>>         }
>>         *obj = &robj->tbo.base;
>> -       (*obj)->funcs = &radeon_gem_object_funcs;
>>         robj->pid = task_pid_nr(current);
>>
>>         mutex_lock(&rdev->gem.mutex);
>> diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c
>> index d0e4b43d155c..7672404fdb29 100644
>> --- a/drivers/gpu/drm/radeon/radeon_object.c
>> +++ b/drivers/gpu/drm/radeon/radeon_object.c
>> @@ -151,6 +151,7 @@ int radeon_bo_create(struct radeon_device *rdev,
>>         if (bo == NULL)
>>                 return -ENOMEM;
>>         drm_gem_private_object_init(rdev_to_drm(rdev), &bo->tbo.base, size);
>> +       bo->tbo.base.funcs = &radeon_gem_object_funcs;
>>         bo->rdev = rdev;
>>         bo->surface_reg = -1;
>>         INIT_LIST_HEAD(&bo->list);
>> --
>> 2.34.1
>>
> 

[PATCHES] drm/radeon issues

[Christian Zigotzky]

Hi All,

There is another issue with the Radeon DRM driver but there is already a patch available for this issue.

Link: https://lists.freedesktop.org/archives/dri-devel/2024-October/473314.html

I compiled a new RC2 of kernel 6.12 with this patch for the X1000 and X5000 today.

Download: https://github.com/chzigotzky/kernels/releases/tag/v6.12.0-rc2-2

We need 3 patches for the Radeon DRM driver currently.

Please test it.

Thanks,
Christian


> On 08 October 2024 at 11:00am, Christian Zigotzky <chzigotzky@xenosoft.de> wrote:
> 
> Hi All,
> 
> I have released the RC2 of kernel 6.12 with Christian Koenig’s patch for the X1000 and X5000.
> 
> Download and further information: https://github.com/chzigotzky/kernels/releases/tag/v6.12.0-rc2
> 
> Please test the kernels because of the second Radeon DRM driver issue.
> 
> Thanks,
> Christian
> 
>> Am 07.10.2024 um 20:36 schrieb Alex Deucher <alexdeucher@gmail.com>:
>> 
>> Add a few people.
>> 
>> This should fix the radeon ttm gem conversion.
>> 
>> Alex
>> 
>> 
>> 
>>> On Mon, Oct 7, 2024 at 2:33 PM Christian König
>>> <ckoenig.leichtzumerken@gmail.com> wrote:
>>> 
>>> Make sure to always set the GEM function pointer even for in kernel
>>> allocations. This fixes a NULL pointer deref caused by switching to GEM
>>> references.
>>> 
>>> Signed-off-by: Christian König <christian.koenig@amd.com>
>>> Fixes: fd69ef05029f ("drm/radeon: use GEM references instead of TTMs")
>>> ---
>>> drivers/gpu/drm/radeon/radeon_gem.c    | 3 ---
>>> drivers/gpu/drm/radeon/radeon_object.c | 1 +
>>> 2 files changed, 1 insertion(+), 3 deletions(-)
>>> 
>>> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c
>>> index 9735f4968b86..bf2d4b16dc2a 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_gem.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
>>> @@ -44,8 +44,6 @@ struct sg_table *radeon_gem_prime_get_sg_table(struct drm_gem_object *obj);
>>> int radeon_gem_prime_pin(struct drm_gem_object *obj);
>>> void radeon_gem_prime_unpin(struct drm_gem_object *obj);
>>> 
>>> -const struct drm_gem_object_funcs radeon_gem_object_funcs;
>>> -
>>> static vm_fault_t radeon_gem_fault(struct vm_fault *vmf)
>>> {
>>>       struct ttm_buffer_object *bo = vmf->vma->vm_private_data;
>>> @@ -132,7 +130,6 @@ int radeon_gem_object_create(struct radeon_device *rdev, unsigned long size,
>>>               return r;
>>>       }
>>>       *obj = &robj->tbo.base;
>>> -       (*obj)->funcs = &radeon_gem_object_funcs;
>>>       robj->pid = task_pid_nr(current);
>>> 
>>>       mutex_lock(&rdev->gem.mutex);
>>> diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c
>>> index d0e4b43d155c..7672404fdb29 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_object.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_object.c
>>> @@ -151,6 +151,7 @@ int radeon_bo_create(struct radeon_device *rdev,
>>>       if (bo == NULL)
>>>               return -ENOMEM;
>>>       drm_gem_private_object_init(rdev_to_drm(rdev), &bo->tbo.base, size);
>>> +       bo->tbo.base.funcs = &radeon_gem_object_funcs;
>>>       bo->rdev = rdev;
>>>       bo->surface_reg = -1;
>>>       INIT_LIST_HEAD(&bo->list);
>>> --
>>> 2.34.1
>>> 

Re: [PATCHES] drm/radeon issues

[Jeff Johnson]

On 10/10/24 06:57, Christian Zigotzky wrote:
> Hi All,
> 
> There is another issue with the Radeon DRM driver but there is already a patch available for this issue.
> 
> Link: https://lists.freedesktop.org/archives/dri-devel/2024-October/473314.html
> 
> I compiled a new RC2 of kernel 6.12 with this patch for the X1000 and X5000 today.
> 
> Download: https://github.com/chzigotzky/kernels/releases/tag/v6.12.0-rc2-2
> 
> We need 3 patches for the Radeon DRM driver currently.

Can you provide links to all 3 patches?

6.12-rc2 was back merged to my ath.git project, but then my laptop
stopped booting correctly and I discovered a few Radeon KASAN reports.
Based upon my search of lore I found:

20241003060650.18454-1-wuhoipok@gmail.com
[PATCH] drm/radeon: add late_register for connector

20241007183241.1584-1-christian.koenig@amd.com
[PATCH] drm/radeon: always set GEM function pointer

But that is only 2 patches.

[PATCHES] drm/radeon issues

[Christian Zigotzky]

On 11 October 2024 at 01:49am, Jeff Johnson <quic_jjohnson@quicinc.com> wrote:

Can you provide links to all 3 patches?

6.12-rc2 was back merged to my ath.git project, but then my laptop
stopped booting correctly and I discovered a few Radeon KASAN reports.
Based upon my search of lore I found:

20241003060650.18454-1-wuhoipok@gmail.com
[PATCH] drm/radeon: add late_register for connector

20241007183241.1584-1-christian.koenig@amd.com
[PATCH] drm/radeon: always set GEM function pointer

But that is only 2 patches.

- - -

The third patch: https://github.com/chzigotzky/kernels/blob/main/patches/X1000/radeon_encoders.patch

Re: [PATCHES] drm/radeon issues

[Alex Deucher]

On Thu, Oct 10, 2024 at 11:54 PM Christian Zigotzky
<chzigotzky@xenosoft.de> wrote:
>
> On 11 October 2024 at 01:49am, Jeff Johnson <quic_jjohnson@quicinc.com> wrote:
>
> Can you provide links to all 3 patches?
>
> 6.12-rc2 was back merged to my ath.git project, but then my laptop
> stopped booting correctly and I discovered a few Radeon KASAN reports.
> Based upon my search of lore I found:
>
> 20241003060650.18454-1-wuhoipok@gmail.com
> [PATCH] drm/radeon: add late_register for connector
>
> 20241007183241.1584-1-christian.koenig@amd.com
> [PATCH] drm/radeon: always set GEM function pointer
>
> But that is only 2 patches.
>
> - - -
>
> The third patch: https://github.com/chzigotzky/kernels/blob/main/patches/X1000/radeon_encoders.patch

Can whoever wrote this send it out as a proper patch?

Alex

[PATCHES] drm/radeon issues

[Christian Zigotzky]

On 14 October 2024 at 3:00pm, Alex Deucher <alexdeucher@gmail.com> wrote:

Can whoever wrote this send it out as a proper patch?

Alex

Patch source: https://lists.freedesktop.org/archives/dri-devel/2024-October/473314.html

[PATCHES] drm/radeon issues

[Christian Zigotzky]

On 14 October 2024 at 3:11pm, Christian Zigotzky wrote:

 >> On 14 October 2024 at 3:00pm, Alex Deucher <alexdeucher@gmail.com> 
wrote:
 >>
 >> Can whoever wrote this send it out as a proper patch?
 >>
 >> Alex
 >>


 > Patch source: 
https://lists.freedesktop.org/archives/dri-devel/2024-October/473314.html

+ ville.syrjala

radeon_fbdev_river_fbdev: failed to initialize framebuffer and setup emulaton

[Christian Zigotzky]

Hello,

Xorg doesn't work after the DRM updates drm-next-2025-07-30.

Error messages:

[dr:.radeon_fbdev_river_fbdev_proe] *ERROR* failed to initialize 
framebuffer -22
radeon 0000:01:0.0: [drm] *ERRO* fbdev: Failedto setup emulaton (ret=-22)
brd module loadedm
lop: module loadd
mpt3ss version 52.10.00.00 loaded
nve nvme0: pci fuction 0002:04:0.0
fsl-sata ffe20000.sata: SataFSL Platform/CS Driver init
scs host0: sata_fs
ta1: SATA max DMA/133 irq 68 pm-pol 0
;21;39mfsl-sat ffe221000.sata Sata FSL Platfrm/CSB Driver iit
ata1: Signatue Update detectd @ 0 msecs
scsihost1: sata_fsl[0m
ta2: SATA max UMA/133 irq 69 lm-pol 0
nvme nvm0: 4/0/0 defaul/read/poll queus
nvme0n1: p1 p p3 p4 p5 p6 p7[0m
drm:.radeon_fbdv_driver_fbdev_robe] *ERROR* filed to initialze 
framebuffer 22
fsl_dpaa_mac fe4e6000.ethernt: 
of_get_mac_adress(/soc@ffe00000/fman@40000/ethernet@e6000 failed
radeon 000:01:00.0: [dr] *ERROR* fbdev Failed to setu emulation (ret-22)
fsl_dpaa_ma ffe4e6000.ethenet: FMan MEMAC[0m
sl_dpaa_mac ffee6000.ethernet:Using random MA address: 0e

Could you please check the latest DRM updates?

Thanks,
Christian

radeon_fbdev_river_fbdev: failed to initialize framebuffer and setup emulaton

[Christian Zigotzky]

Hello,

I have the same issue on another machine either. Blank screen during the 
boot. The Radeon graphics framebuffer device doesn't work anymore.

Here is the modifed code from the DRM updates (drm-next-2025-07-30):

- 
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/radeon/radeon_fbdev.c?id=260f6f4fda93c8485c8037865c941b42b9cba5d2
- 
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/radeon/radeon_drv.c?id=260f6f4fda93c8485c8037865c941b42b9cba5d2
- 
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/radeon/radeon_display.c?id=260f6f4fda93c8485c8037865c941b42b9cba5d2
- 
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/radeon/evergreen_cs.c?id=260f6f4fda93c8485c8037865c941b42b9cba5d2

Do you have a patch for reverting these modifications? I would like to 
revert these modifications for testing.

Thanks in advance,
Christian

On 03 August 2025 at 1:35 pm, Christian Zigotzky wrote:
> Hello,
> 
> Xorg doesn't work after the DRM updates drm-next-2025-07-30.
> 
> Error messages:
> 
> [dr:.radeon_fbdev_river_fbdev_proe] *ERROR* failed to initialize 
> framebuffer -22
> radeon 0000:01:0.0: [drm] *ERRO* fbdev: Failedto setup emulaton (ret=-22)
> brd module loadedm
> lop: module loadd
> mpt3ss version 52.10.00.00 loaded
> nve nvme0: pci fuction 0002:04:0.0
> fsl-sata ffe20000.sata: SataFSL Platform/CS Driver init
> scs host0: sata_fs
> ta1: SATA max DMA/133 irq 68 pm-pol 0
> ;21;39mfsl-sat ffe221000.sata Sata FSL Platfrm/CSB Driver iit
> ata1: Signatue Update detectd @ 0 msecs
> scsihost1: sata_fsl[0m
> ta2: SATA max UMA/133 irq 69 lm-pol 0
> nvme nvm0: 4/0/0 defaul/read/poll queus
> nvme0n1: p1 p p3 p4 p5 p6 p7[0m
> drm:.radeon_fbdv_driver_fbdev_robe] *ERROR* filed to initialze 
> framebuffer 22
> fsl_dpaa_mac fe4e6000.ethernt: of_get_mac_adress(/soc@ffe00000/ 
> fman@40000/ethernet@e6000 failed
> radeon 000:01:00.0: [dr] *ERROR* fbdev Failed to setu emulation (ret-22)
> fsl_dpaa_ma ffe4e6000.ethenet: FMan MEMAC[0m
> sl_dpaa_mac ffee6000.ethernet:Using random MA address: 0e
> 
> Could you please check the latest DRM updates?
> 
> Thanks,
> Christian
> 

radeon_fbdev_river_fbdev: failed to initialize framebuffer and setup emulation

[Christian Zigotzky]

FYI: We are using PowerPC machines.

+ dri-devel

> On 03 August 2025 at 05:28 pm, Christian Zigotzky <chzigotzky@xenosoft.de> wrote:
> 
> Hello,
> 
> I have the same issue on another machine either. Blank screen during the boot. The Radeon graphics framebuffer device doesn't work anymore.
> 
> Here is the modifed code from the DRM updates (drm-next-2025-07-30):
> 
> - https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/radeon/radeon_fbdev.c?id=260f6f4fda93c8485c8037865c941b42b9cba5d2
> - https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/radeon/radeon_drv.c?id=260f6f4fda93c8485c8037865c941b42b9cba5d2
> - https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/radeon/radeon_display.c?id=260f6f4fda93c8485c8037865c941b42b9cba5d2
> - https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/radeon/evergreen_cs.c?id=260f6f4fda93c8485c8037865c941b42b9cba5d2
> 
> Do you have a patch for reverting these modifications? I would like to revert these modifications for testing.
> 
> Thanks in advance,
> Christian
> 
>> On 03 August 2025 at 1:35 pm, Christian Zigotzky wrote:
>> Hello,
>> Xorg doesn't work after the DRM updates drm-next-2025-07-30.
>> Error messages:
>> [dr:.radeon_fbdev_river_fbdev_proe] *ERROR* failed to initialize framebuffer -22
>> radeon 0000:01:0.0: [drm] *ERRO* fbdev: Failedto setup emulaton (ret=-22)
>> brd module loadedm
>> lop: module loadd
>> mpt3ss version 52.10.00.00 loaded
>> nve nvme0: pci fuction 0002:04:0.0
>> fsl-sata ffe20000.sata: SataFSL Platform/CS Driver init
>> scs host0: sata_fs
>> ta1: SATA max DMA/133 irq 68 pm-pol 0
>> ;21;39mfsl-sat ffe221000.sata Sata FSL Platfrm/CSB Driver iit
>> ata1: Signatue Update detectd @ 0 msecs
>> scsihost1: sata_fsl[0m
>> ta2: SATA max UMA/133 irq 69 lm-pol 0
>> nvme nvm0: 4/0/0 defaul/read/poll queus
>> nvme0n1: p1 p p3 p4 p5 p6 p7[0m
>> drm:.radeon_fbdv_driver_fbdev_robe] *ERROR* filed to initialze framebuffer 22
>> fsl_dpaa_mac fe4e6000.ethernt: of_get_mac_adress(/soc@ffe00000/ fman@40000/ethernet@e6000 failed
>> radeon 000:01:00.0: [dr] *ERROR* fbdev Failed to setu emulation (ret-22)
>> fsl_dpaa_ma ffe4e6000.ethenet: FMan MEMAC[0m
>> sl_dpaa_mac ffee6000.ethernet:Using random MA address: 0e
>> Could you please check the latest DRM updates?
>> Thanks,
>> Christian
> 

Re: radeon_fbdev_river_fbdev: failed to initialize framebuffer and setup emulaton

[Alex Deucher]

On Sun, Aug 3, 2025 at 11:28 AM Christian Zigotzky
<chzigotzky@xenosoft.de> wrote:
>
> Hello,
>
> I have the same issue on another machine either. Blank screen during the
> boot. The Radeon graphics framebuffer device doesn't work anymore.
>
> Here is the modifed code from the DRM updates (drm-next-2025-07-30):
>
> -
> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/radeon/radeon_fbdev.c?id=260f6f4fda93c8485c8037865c941b42b9cba5d2
> -
> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/radeon/radeon_drv.c?id=260f6f4fda93c8485c8037865c941b42b9cba5d2

This change just bumps the driver version it shouldn't affect the fbdev.

> -
> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/radeon/radeon_display.c?id=260f6f4fda93c8485c8037865c941b42b9cba5d2
> -
> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/radeon/evergreen_cs.c?id=260f6f4fda93c8485c8037865c941b42b9cba5d2

This only affects acceleration, it should not affect fbdev.

What chip are you using?  Can you attach your full dmesg output?  Can
you bisect?  This cultrit could be a core drm change.

Alex

>
> Do you have a patch for reverting these modifications? I would like to
> revert these modifications for testing.
>
> Thanks in advance,
> Christian
>
> On 03 August 2025 at 1:35 pm, Christian Zigotzky wrote:
> > Hello,
> >
> > Xorg doesn't work after the DRM updates drm-next-2025-07-30.
> >
> > Error messages:
> >
> > [dr:.radeon_fbdev_river_fbdev_proe] *ERROR* failed to initialize
> > framebuffer -22
> > radeon 0000:01:0.0: [drm] *ERRO* fbdev: Failedto setup emulaton (ret=-22)
> > brd module loadedm
> > lop: module loadd
> > mpt3ss version 52.10.00.00 loaded
> > nve nvme0: pci fuction 0002:04:0.0
> > fsl-sata ffe20000.sata: SataFSL Platform/CS Driver init
> > scs host0: sata_fs
> > ta1: SATA max DMA/133 irq 68 pm-pol 0
> > ;21;39mfsl-sat ffe221000.sata Sata FSL Platfrm/CSB Driver iit
> > ata1: Signatue Update detectd @ 0 msecs
> > scsihost1: sata_fsl[0m
> > ta2: SATA max UMA/133 irq 69 lm-pol 0
> > nvme nvm0: 4/0/0 defaul/read/poll queus
> > nvme0n1: p1 p p3 p4 p5 p6 p7[0m
> > drm:.radeon_fbdv_driver_fbdev_robe] *ERROR* filed to initialze
> > framebuffer 22
> > fsl_dpaa_mac fe4e6000.ethernt: of_get_mac_adress(/soc@ffe00000/
> > fman@40000/ethernet@e6000 failed
> > radeon 000:01:00.0: [dr] *ERROR* fbdev Failed to setu emulation (ret-22)
> > fsl_dpaa_ma ffe4e6000.ethenet: FMan MEMAC[0m
> > sl_dpaa_mac ffee6000.ethernet:Using random MA address: 0e
> >
> > Could you please check the latest DRM updates?
> >
> > Thanks,
> > Christian
> >
>

radeon_fbdev_river_fbdev: failed to initialize framebuffer and setup emulation

[Christian Zigotzky]

On 04 August 2025 at 04:42 pm, Alex Deucher wrote:
> On Sun, Aug 3, 2025 at 11:28 AM Christian Zigotzky
> <chzigotzky@xenosoft.de> wrote:
>>
>> Hello,
>>
>> I have the same issue on another machine either. Blank screen during the
>> boot. The Radeon graphics framebuffer device doesn't work anymore.
>>
>> Here is the modifed code from the DRM updates (drm-next-2025-07-30):
>>
>> -
>> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/radeon/radeon_fbdev.c?id=260f6f4fda93c8485c8037865c941b42b9cba5d2
>> -
>> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/radeon/radeon_drv.c?id=260f6f4fda93c8485c8037865c941b42b9cba5d2
> 
> This change just bumps the driver version it shouldn't affect the fbdev.
> 
>> -
>> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/radeon/radeon_display.c?id=260f6f4fda93c8485c8037865c941b42b9cba5d2
>> -
>> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/radeon/evergreen_cs.c?id=260f6f4fda93c8485c8037865c941b42b9cba5d2
> 
> This only affects acceleration, it should not affect fbdev.
> 
> What chip are you using?  Can you attach your full dmesg output?  Can
> you bisect?  This cultrit could be a core drm change.
> 
> Alex
> 
>>
>> Do you have a patch for reverting these modifications? I would like to
>> revert these modifications for testing.
>>
>> Thanks in advance,
>> Christian
>>
>> On 03 August 2025 at 1:35 pm, Christian Zigotzky wrote:
>>> Hello,
>>>
>>> Xorg doesn't work after the DRM updates drm-next-2025-07-30.
>>>
>>> Error messages:
>>>
>>> [dr:.radeon_fbdev_river_fbdev_proe] *ERROR* failed to initialize
>>> framebuffer -22
>>> radeon 0000:01:0.0: [drm] *ERRO* fbdev: Failedto setup emulaton (ret=-22)
>>> brd module loadedm
>>> lop: module loadd
>>> mpt3ss version 52.10.00.00 loaded
>>> nve nvme0: pci fuction 0002:04:0.0
>>> fsl-sata ffe20000.sata: SataFSL Platform/CS Driver init
>>> scs host0: sata_fs
>>> ta1: SATA max DMA/133 irq 68 pm-pol 0
>>> ;21;39mfsl-sat ffe221000.sata Sata FSL Platfrm/CSB Driver iit
>>> ata1: Signatue Update detectd @ 0 msecs
>>> scsihost1: sata_fsl[0m
>>> ta2: SATA max UMA/133 irq 69 lm-pol 0
>>> nvme nvm0: 4/0/0 defaul/read/poll queus
>>> nvme0n1: p1 p p3 p4 p5 p6 p7[0m
>>> drm:.radeon_fbdv_driver_fbdev_robe] *ERROR* filed to initialze
>>> framebuffer 22
>>> fsl_dpaa_mac fe4e6000.ethernt: of_get_mac_adress(/soc@ffe00000/
>>> fman@40000/ethernet@e6000 failed
>>> radeon 000:01:00.0: [dr] *ERROR* fbdev Failed to setu emulation (ret-22)
>>> fsl_dpaa_ma ffe4e6000.ethenet: FMan MEMAC[0m
>>> sl_dpaa_mac ffee6000.ethernet:Using random MA address: 0e
>>>
>>> Could you please check the latest DRM updates?
>>>
>>> Thanks,
>>> Christian
>>>
>>

Hello Alex,

Thanks for your answer.

I use a BARTS chip (Radeon HD6870). I would like to bisect but I don't 
have time for it currently. Sorry

There are some other user reports:

- https://forum.hyperion-entertainment.com/viewtopic.php?p=60606#p60606
- https://forum.hyperion-entertainment.com/viewtopic.php?p=60595#p60595

They use other Radeon graphics chips.

Bug report: https://github.com/chzigotzky/kernels/issues/15

What do you think about the following commit?

Link: 
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0e7d5874fb6b80c44be3cfbcf1cf356e81d91232

@Hypex
Could you please attach your full dmesg output?

Thanks,
Christian

Re: radeon_fbdev_river_fbdev: failed to initialize framebuffer and setup emulation

[mad skateman]

[-- Attachment #1: Type: text/plain, Size: 4096 bytes --]

I am using the R580 chip which is the Radeon X1950 XT.

The board i am using is a T1042 PowerPC based one with e5500 core.

I also lost the ability to start Xorg and therefore just a blank screen.

Dave





Op ma 4 aug 2025, 18:04 schreef Christian Zigotzky <chzigotzky@xenosoft.de>:

>
> On 04 August 2025 at 04:42 pm, Alex Deucher wrote:
> > On Sun, Aug 3, 2025 at 11:28 AM Christian Zigotzky
> > <chzigotzky@xenosoft.de> wrote:
> >>
> >> Hello,
> >>
> >> I have the same issue on another machine either. Blank screen during the
> >> boot. The Radeon graphics framebuffer device doesn't work anymore.
> >>
> >> Here is the modifed code from the DRM updates (drm-next-2025-07-30):
> >>
> >> -
> >>
> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/radeon/radeon_fbdev.c?id=260f6f4fda93c8485c8037865c941b42b9cba5d2
> >> -
> >>
> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/radeon/radeon_drv.c?id=260f6f4fda93c8485c8037865c941b42b9cba5d2
> >
> > This change just bumps the driver version it shouldn't affect the fbdev.
> >
> >> -
> >>
> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/radeon/radeon_display.c?id=260f6f4fda93c8485c8037865c941b42b9cba5d2
> >> -
> >>
> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/gpu/drm/radeon/evergreen_cs.c?id=260f6f4fda93c8485c8037865c941b42b9cba5d2
> >
> > This only affects acceleration, it should not affect fbdev.
> >
> > What chip are you using?  Can you attach your full dmesg output?  Can
> > you bisect?  This cultrit could be a core drm change.
> >
> > Alex
> >
> >>
> >> Do you have a patch for reverting these modifications? I would like to
> >> revert these modifications for testing.
> >>
> >> Thanks in advance,
> >> Christian
> >>
> >> On 03 August 2025 at 1:35 pm, Christian Zigotzky wrote:
> >>> Hello,
> >>>
> >>> Xorg doesn't work after the DRM updates drm-next-2025-07-30.
> >>>
> >>> Error messages:
> >>>
> >>> [dr:.radeon_fbdev_river_fbdev_proe] *ERROR* failed to initialize
> >>> framebuffer -22
> >>> radeon 0000:01:0.0: [drm] *ERRO* fbdev: Failedto setup emulaton
> (ret=-22)
> >>> brd module loadedm
> >>> lop: module loadd
> >>> mpt3ss version 52.10.00.00 loaded
> >>> nve nvme0: pci fuction 0002:04:0.0
> >>> fsl-sata ffe20000.sata: SataFSL Platform/CS Driver init
> >>> scs host0: sata_fs
> >>> ta1: SATA max DMA/133 irq 68 pm-pol 0
> >>> ;21;39mfsl-sat ffe221000.sata Sata FSL Platfrm/CSB Driver iit
> >>> ata1: Signatue Update detectd @ 0 msecs
> >>> scsihost1: sata_fsl[0m
> >>> ta2: SATA max UMA/133 irq 69 lm-pol 0
> >>> nvme nvm0: 4/0/0 defaul/read/poll queus
> >>> nvme0n1: p1 p p3 p4 p5 p6 p7[0m
> >>> drm:.radeon_fbdv_driver_fbdev_robe] *ERROR* filed to initialze
> >>> framebuffer 22
> >>> fsl_dpaa_mac fe4e6000.ethernt: of_get_mac_adress(/soc@ffe00000/
> >>> fman@40000/ethernet@e6000 failed
> >>> radeon 000:01:00.0: [dr] *ERROR* fbdev Failed to setu emulation
> (ret-22)
> >>> fsl_dpaa_ma ffe4e6000.ethenet: FMan MEMAC[0m
> >>> sl_dpaa_mac ffee6000.ethernet:Using random MA address: 0e
> >>>
> >>> Could you please check the latest DRM updates?
> >>>
> >>> Thanks,
> >>> Christian
> >>>
> >>
>
> Hello Alex,
>
> Thanks for your answer.
>
> I use a BARTS chip (Radeon HD6870). I would like to bisect but I don't
> have time for it currently. Sorry
>
> There are some other user reports:
>
> - https://forum.hyperion-entertainment.com/viewtopic.php?p=60606#p60606
> - https://forum.hyperion-entertainment.com/viewtopic.php?p=60595#p60595
>
> They use other Radeon graphics chips.
>
> Bug report: https://github.com/chzigotzky/kernels/issues/15
>
> What do you think about the following commit?
>
> Link:
>
> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0e7d5874fb6b80c44be3cfbcf1cf356e81d91232
>
> @Hypex
> Could you please attach your full dmesg output?
>
> Thanks,
> Christian
>

[-- Attachment #2: Type: text/html, Size: 6819 bytes --]

radeon_fbdev_river_fbdev: failed to initialize framebuffer and setup emulation

[Christian Zigotzky]

[-- Attachment #1: Type: text/html, Size: 10505 bytes --]

Re: radeon_fbdev_river_fbdev: failed to initialize framebuffer and setup emulation

[Limonciello, Mario]

On 8/7/25 9:10 AM, Christian Zigotzky wrote:
> I bisected today.
> 
> git clone https://gitlab.freedesktop.org/drm/kernel a
> 
> git bisect start
> 
> git bisect good 2f29b5c231011b94007d2c8a6d793992f2275db1
> (Good: video: screen_info: Relocate framebuffers behind PCI bridges)
> 
> git bisect bad f62408efc8669b82541295a4611494c8c8c52684
> (Bad: drm/xe/vf: Disable CSC support on VF)
> 
> 4d4c10f763d7808fbade28d83d237411603bca05 is the first bad commit
> commit 4d4c10f763d7808fbade28d83d237411603bca05
> Author: Mario Limonciello <mario.limonciello@amd.com>
> Date:   Wed Apr 23 23:31:32 2025 -0500
> 
>      PCI: Explicitly put devices into D0 when initializing
> 
>      AMD BIOS team has root caused an issue that NVMe storage failed to come
>      back from suspend to a lack of a call to _REG when NVMe device was 
> probed.
> 
>      112a7f9c8edbf ("PCI/ACPI: Call _REG when transitioning D-states") added
>      support for calling _REG when transitioning D-states, but this only 
> works
>      if the device actually "transitions" D-states.
> 
>      967577b062417 ("PCI/PM: Keep runtime PM enabled for unbound PCI 
> devices")
>      added support for runtime PM on PCI devices, but never actually
>      'explicitly' sets the device to D0.
> 
>      To make sure that devices are in D0 and that platform methods such as
>      _REG are called, explicitly set all devices into D0 during 
> initialization.
> 
>      Fixes: 967577b062417 ("PCI/PM: Keep runtime PM enabled for unbound 
> PCI devices")
>      Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
>      Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>      Tested-by: Denis Benato <benato.denis96@gmail.com>
>      Tested-By: Yijun Shen <Yijun_Shen@Dell.com>
>      Tested-By: David Perry <david.perry@amd.com>
>      Reviewed-by: Rafael J. Wysocki <rafael@kernel.org>
>      Link: https://patch.msgid.link/20250424043232.1848107-1- 
> superm1@kernel.org
> 
>   drivers/pci/pci-driver.c |  6 ------
>   drivers/pci/pci.c        | 13 ++++++++++---
>   drivers/pci/pci.h        |  1 +
>   3 files changed, 11 insertions(+), 9 deletions(-)
> 
> I bisected with a ATi Radeon 7000 / VE (-device ati-vga,model=rv100) :-)
> 
>> On 04 August 2025 at 06:26 pm, mad skateman <madskateman@gmail.com> wrote:
>>
>> 
>> I am using the R580 chip which is the Radeon X1950 XT.
>>
>> The board i am using is a T1042 PowerPC based one with e5500 core.
>>
>> I also lost the ability to start Xorg and therefore just a blank screen.
>>
>> Dave
>>
>>
>>
>>
>>
>> Op ma 4 aug 2025, 18:04 schreef Christian Zigotzky 
>> <chzigotzky@xenosoft.de <mailto:chzigotzky@xenosoft.de>>:
>>
>>
>>     On 04 August 2025 at 04:42 pm, Alex Deucher wrote:
>>     > On Sun, Aug 3, 2025 at 11:28 AM Christian Zigotzky
>>     > <chzigotzky@xenosoft.de <mailto:chzigotzky@xenosoft.de>> wrote:
>>     >>
>>     >> Hello,
>>     >>
>>     >> I have the same issue on another machine either. Blank screen
>>     during the
>>     >> boot. The Radeon graphics framebuffer device doesn't work anymore.
>>     >>
>>     >> Here is the modifed code from the DRM updates (drm-
>>     next-2025-07-30):
>>     >>
>>     >> -
>>     >> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/
>>     linux.git/diff/drivers/gpu/drm/radeon/radeon_fbdev.c?
>>     id=260f6f4fda93c8485c8037865c941b42b9cba5d2 <https://
>>     web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
>>     diff/drivers/gpu/drm/radeon/radeon_fbdev.c?
>>     id=260f6f4fda93c8485c8037865c941b42b9cba5d2>
>>     >> -
>>     >> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/
>>     linux.git/diff/drivers/gpu/drm/radeon/radeon_drv.c?
>>     id=260f6f4fda93c8485c8037865c941b42b9cba5d2 <https://
>>     web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
>>     diff/drivers/gpu/drm/radeon/radeon_drv.c?
>>     id=260f6f4fda93c8485c8037865c941b42b9cba5d2>
>>     >
>>     > This change just bumps the driver version it shouldn't affect
>>     the fbdev.
>>     >
>>     >> -
>>     >> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/
>>     linux.git/diff/drivers/gpu/drm/radeon/radeon_display.c?
>>     id=260f6f4fda93c8485c8037865c941b42b9cba5d2 <https://
>>     web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
>>     diff/drivers/gpu/drm/radeon/radeon_display.c?
>>     id=260f6f4fda93c8485c8037865c941b42b9cba5d2>
>>     >> -
>>     >> https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/
>>     linux.git/diff/drivers/gpu/drm/radeon/evergreen_cs.c?
>>     id=260f6f4fda93c8485c8037865c941b42b9cba5d2 <https://
>>     web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
>>     diff/drivers/gpu/drm/radeon/evergreen_cs.c?
>>     id=260f6f4fda93c8485c8037865c941b42b9cba5d2>
>>     >
>>     > This only affects acceleration, it should not affect fbdev.
>>     >
>>     > What chip are you using?  Can you attach your full dmesg
>>     output?  Can
>>     > you bisect?  This cultrit could be a core drm change.
>>     >
>>     > Alex
>>     >
>>     >>
>>     >> Do you have a patch for reverting these modifications? I would
>>     like to
>>     >> revert these modifications for testing.
>>     >>
>>     >> Thanks in advance,
>>     >> Christian
>>     >>
>>     >> On 03 August 2025 at 1:35 pm, Christian Zigotzky wrote:
>>     >>> Hello,
>>     >>>
>>     >>> Xorg doesn't work after the DRM updates drm-next-2025-07-30.
>>     >>>
>>     >>> Error messages:
>>     >>>
>>     >>> [dr:.radeon_fbdev_river_fbdev_proe] *ERROR* failed to initialize
>>     >>> framebuffer -22
>>     >>> radeon 0000:01:0.0: [drm] *ERRO* fbdev: Failedto setup
>>     emulaton (ret=-22)
>>     >>> brd module loadedm
>>     >>> lop: module loadd
>>     >>> mpt3ss version 52.10.00.00 loaded
>>     >>> nve nvme0: pci fuction 0002:04:0.0
>>     >>> fsl-sata ffe20000.sata: SataFSL Platform/CS Driver init
>>     >>> scs host0: sata_fs
>>     >>> ta1: SATA max DMA/133 irq 68 pm-pol 0
>>     >>> ;21;39mfsl-sat ffe221000.sata Sata FSL Platfrm/CSB Driver iit
>>     >>> ata1: Signatue Update detectd @ 0 msecs
>>     >>> scsihost1: sata_fsl[0m
>>     >>> ta2: SATA max UMA/133 irq 69 lm-pol 0
>>     >>> nvme nvm0: 4/0/0 defaul/read/poll queus
>>     >>> nvme0n1: p1 p p3 p4 p5 p6 p7[0m
>>     >>> drm:.radeon_fbdv_driver_fbdev_robe] *ERROR* filed to initialze
>>     >>> framebuffer 22
>>     >>> fsl_dpaa_mac fe4e6000.ethernt: of_get_mac_adress(/soc@ffe00000/
>>     >>> fman@40000/ethernet@e6000 failed
>>     >>> radeon 000:01:00.0: [dr] *ERROR* fbdev Failed to setu
>>     emulation (ret-22)
>>     >>> fsl_dpaa_ma ffe4e6000.ethenet: FMan MEMAC[0m
>>     >>> sl_dpaa_mac ffee6000.ethernet:Using random MA address: 0e
>>     >>>
>>     >>> Could you please check the latest DRM updates?
>>     >>>
>>     >>> Thanks,
>>     >>> Christian
>>     >>>
>>     >>
>>
>>     Hello Alex,
>>
>>     Thanks for your answer.
>>
>>     I use a BARTS chip (Radeon HD6870). I would like to bisect but I
>>     don't
>>     have time for it currently. Sorry
>>
>>     There are some other user reports:
>>
>>     - https://forum.hyperion-entertainment.com/viewtopic.php?
>>     p=60606#p60606 <https://forum.hyperion-entertainment.com/
>>     viewtopic.php?p=60606#p60606>
>>     - https://forum.hyperion-entertainment.com/viewtopic.php?
>>     p=60595#p60595 <https://forum.hyperion-entertainment.com/
>>     viewtopic.php?p=60595#p60595>
>>
>>     They use other Radeon graphics chips.
>>
>>     Bug report: https://github.com/chzigotzky/kernels/issues/15
>>     <https://github.com/chzigotzky/kernels/issues/15>
>>
>>     What do you think about the following commit?
>>
>>     Link:
>>     https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/
>>     linux.git/commit/?id=0e7d5874fb6b80c44be3cfbcf1cf356e81d91232
>>     <https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/
>>     linux.git/commit/?id=0e7d5874fb6b80c44be3cfbcf1cf356e81d91232>
>>
>>     @Hypex
>>     Could you please attach your full dmesg output?
>>
>>     Thanks,
>>     Christian
>>

Does applying 
https://github.com/torvalds/linux/commit/907a7a2e5bf40c6a359b2f6cc53d6fdca04009e0 
help?

radeon_fbdev_river_fbdev: failed to initialize framebuffer and setup emulation

[Christian Zigotzky]

On 07 August 2025 at 04:21 pm, Limonciello, Mario <Mario.Limonciello@amd.com> wrote:

Does applying
https://github.com/torvalds/linux/commit/907a7a2e5bf40c6a359b2f6cc53d6fdca04009e0
help?

- - -

Hello Mario,

Thanks a lot for your patch.

I tested it today but unfortunately it doesn’t solve the issue with the Radeon framebuffer.

I have created two kernels with and without the drm-next-2025-07-30 updates [1] because of the issue with the Radeon graphics framebuffer device #15. [2]

Download and further information: https://github.com/chzigotzky/kernels/releases/tag/v6.17.0-alpha5

I have tested both kernels this week and I can definitely confirm, that the issue is somewhere in the commit drm-next-2025-07-30 updates [1].

The Radeon graphics framebuffer doesn't work with the kernel with the drm-next-2025-07-30 updates [1]. Without these updates, the framebuffer works.

I bisected yesterday. [2]

There are some other user reports:

- https://forum.hyperion-entertainment.com/viewtopic.php?p=60606#p60606
- https://forum.hyperion-entertainment.com/viewtopic.php?p=60595#p60595

They use other Radeon graphics chips.

@All
Please check the drm-next-2025-07-30 updates [1]

Thanks,
Christian

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

[2] https://github.com/chzigotzky/kernels/issues/15

Re: radeon_fbdev_river_fbdev: failed to initialize framebuffer and setup emulation

[Mario Limonciello]

On 8/8/25 2:36 AM, Christian Zigotzky wrote:
> 
> On 07 August 2025 at 04:21 pm, Limonciello, Mario <Mario.Limonciello@amd.com> wrote:
> 
> Does applying
> https://github.com/torvalds/linux/commit/907a7a2e5bf40c6a359b2f6cc53d6fdca04009e0
> help?
> 
> - - -
> 
> Hello Mario,
> 
> Thanks a lot for your patch.
> 
> I tested it today but unfortunately it doesn’t solve the issue with the Radeon framebuffer.
> 
> I have created two kernels with and without the drm-next-2025-07-30 updates [1] because of the issue with the Radeon graphics framebuffer device #15. [2]
> 
> Download and further information: https://github.com/chzigotzky/kernels/releases/tag/v6.17.0-alpha5
> 
> I have tested both kernels this week and I can definitely confirm, that the issue is somewhere in the commit drm-next-2025-07-30 updates [1].
> 
> The Radeon graphics framebuffer doesn't work with the kernel with the drm-next-2025-07-30 updates [1]. Without these updates, the framebuffer works.
> 
> I bisected yesterday. [2]
> 
> There are some other user reports:
> 
> - https://forum.hyperion-entertainment.com/viewtopic.php?p=60606#p60606
> - https://forum.hyperion-entertainment.com/viewtopic.php?p=60595#p60595
> 
> They use other Radeon graphics chips.
> 
> @All
> Please check the drm-next-2025-07-30 updates [1]
> 
> Thanks,
> Christian
> 
> [1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=260f6f4fda93c8485c8037865c941b42b9cba5d2
> 
> [2] https://github.com/chzigotzky/kernels/issues/15
> 

I think there is a mistake in your bisect, which I notice from looking 
at your other user reports.

The original commit you identified in your bisect and thus CC'ed me came 
in 6.16-rc1.

❯ git describe --contains 4d4c10f763d7808fbade28d83d237411603bca05
v6.16-rc1~50^2~19^2

There absolutely was a regression for that was raised, but this was 
fixed in 6.16-rc3.

❯ git describe --contains 907a7a2e5bf40c6a359b2f6cc53d6fdca04009e0
v6.16-rc3~13^2~1

Users in your forums posts talk about 6.16 final working fine.  So I 
think that when you bisected you ran into multiple confounding issues 
and replicated in a similar fashion.  You should check every single 
bisect step to see if 4d4c10f763d7808fbade28d83d237411603bca05 is 
applied.  If it's applied but 907a7a2e5bf40c6a359b2f6cc53d6fdca04009e0 
is not applied in that step you should apply 
907a7a2e5bf40c6a359b2f6cc53d6fdca04009e0.

Hopefully that will get you down to the real cause.

Re: radeon_fbdev_river_fbdev: failed to initialize framebuffer and setup emulation

[Christian Zigotzky]

> On 08 August 2025 um 01:23 pm, Mario Limonciello <superm1@kernel.org> wrote:
> 
> 
> 
>> On 8/8/25 2:36 AM, Christian Zigotzky wrote:
>> On 07 August 2025 at 04:21 pm, Limonciello, Mario <Mario.Limonciello@amd.com> wrote:
>> Does applying
>> https://github.com/torvalds/linux/commit/907a7a2e5bf40c6a359b2f6cc53d6fdca04009e0
>> help?
>> - - -
>> Hello Mario,
>> Thanks a lot for your patch.
>> I tested it today but unfortunately it doesn’t solve the issue with the Radeon framebuffer.
>> I have created two kernels with and without the drm-next-2025-07-30 updates [1] because of the issue with the Radeon graphics framebuffer device #15. [2]
>> Download and further information: https://github.com/chzigotzky/kernels/releases/tag/v6.17.0-alpha5
>> I have tested both kernels this week and I can definitely confirm, that the issue is somewhere in the commit drm-next-2025-07-30 updates [1].
>> The Radeon graphics framebuffer doesn't work with the kernel with the drm-next-2025-07-30 updates [1]. Without these updates, the framebuffer works.
>> I bisected yesterday. [2]
>> There are some other user reports:
>> - https://forum.hyperion-entertainment.com/viewtopic.php?p=60606#p60606
>> - https://forum.hyperion-entertainment.com/viewtopic.php?p=60595#p60595
>> They use other Radeon graphics chips.
>> @All
>> Please check the drm-next-2025-07-30 updates [1]
>> Thanks,
>> Christian
>> [1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=260f6f4fda93c8485c8037865c941b42b9cba5d2
>> [2] https://github.com/chzigotzky/kernels/issues/15
> 
> I think there is a mistake in your bisect, which I notice from looking at your other user reports.
> 
> The original commit you identified in your bisect and thus CC'ed me came in 6.16-rc1.
> 
> ❯ git describe --contains 4d4c10f763d7808fbade28d83d237411603bca05
> v6.16-rc1~50^2~19^2
> 
> There absolutely was a regression for that was raised, but this was fixed in 6.16-rc3.
> 
> ❯ git describe --contains 907a7a2e5bf40c6a359b2f6cc53d6fdca04009e0
> v6.16-rc3~13^2~1
> 
> Users in your forums posts talk about 6.16 final working fine.  So I think that when you bisected you ran into multiple confounding issues and replicated in a similar fashion.  You should check every single bisect step to see if 4d4c10f763d7808fbade28d83d237411603bca05 is applied.  If it's applied but 907a7a2e5bf40c6a359b2f6cc53d6fdca04009e0 is not applied in that step you should apply 907a7a2e5bf40c6a359b2f6cc53d6fdca04009e0.
> 
> Hopefully that will get you down to the real cause.

Thanks for the hint. Unfortunately I don’t have more time for figuring out the issue.

Two facts:

- The Radeon driver can no longer be used.
The Radeon driver is broken for us.

- The issue is somewhere in the commit drm-next-2025-07-30 updates [1].

I cannot provide any more due to time constraints.

I've already spent time that I didn't actually have.

Thanks for your help.

Christian

Re: radeon_fbdev_river_fbdev: failed to initialize framebuffer and setup emulation

[Mario Limonciello]

On 8/8/25 6:47 AM, Christian Zigotzky wrote:
> 
> 
>> On 08 August 2025 um 01:23 pm, Mario Limonciello <superm1@kernel.org> wrote:
>>
>> 
>>
>>> On 8/8/25 2:36 AM, Christian Zigotzky wrote:
>>> On 07 August 2025 at 04:21 pm, Limonciello, Mario <Mario.Limonciello@amd.com> wrote:
>>> Does applying
>>> https://github.com/torvalds/linux/commit/907a7a2e5bf40c6a359b2f6cc53d6fdca04009e0
>>> help?
>>> - - -
>>> Hello Mario,
>>> Thanks a lot for your patch.
>>> I tested it today but unfortunately it doesn’t solve the issue with the Radeon framebuffer.
>>> I have created two kernels with and without the drm-next-2025-07-30 updates [1] because of the issue with the Radeon graphics framebuffer device #15. [2]
>>> Download and further information: https://github.com/chzigotzky/kernels/releases/tag/v6.17.0-alpha5
>>> I have tested both kernels this week and I can definitely confirm, that the issue is somewhere in the commit drm-next-2025-07-30 updates [1].
>>> The Radeon graphics framebuffer doesn't work with the kernel with the drm-next-2025-07-30 updates [1]. Without these updates, the framebuffer works.
>>> I bisected yesterday. [2]
>>> There are some other user reports:
>>> - https://forum.hyperion-entertainment.com/viewtopic.php?p=60606#p60606
>>> - https://forum.hyperion-entertainment.com/viewtopic.php?p=60595#p60595
>>> They use other Radeon graphics chips.
>>> @All
>>> Please check the drm-next-2025-07-30 updates [1]
>>> Thanks,
>>> Christian
>>> [1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=260f6f4fda93c8485c8037865c941b42b9cba5d2
>>> [2] https://github.com/chzigotzky/kernels/issues/15
>>
>> I think there is a mistake in your bisect, which I notice from looking at your other user reports.
>>
>> The original commit you identified in your bisect and thus CC'ed me came in 6.16-rc1.
>>
>> ❯ git describe --contains 4d4c10f763d7808fbade28d83d237411603bca05
>> v6.16-rc1~50^2~19^2
>>
>> There absolutely was a regression for that was raised, but this was fixed in 6.16-rc3.
>>
>> ❯ git describe --contains 907a7a2e5bf40c6a359b2f6cc53d6fdca04009e0
>> v6.16-rc3~13^2~1
>>
>> Users in your forums posts talk about 6.16 final working fine.  So I think that when you bisected you ran into multiple confounding issues and replicated in a similar fashion.  You should check every single bisect step to see if 4d4c10f763d7808fbade28d83d237411603bca05 is applied.  If it's applied but 907a7a2e5bf40c6a359b2f6cc53d6fdca04009e0 is not applied in that step you should apply 907a7a2e5bf40c6a359b2f6cc53d6fdca04009e0.
>>
>> Hopefully that will get you down to the real cause.
> 
> Thanks for the hint. Unfortunately I don’t have more time for figuring out the issue.
> 
> Two facts:
> 
> - The Radeon driver can no longer be used.
> The Radeon driver is broken for us.
> 
> - The issue is somewhere in the commit drm-next-2025-07-30 updates [1].
> 
> I cannot provide any more due to time constraints.
> 
> I've already spent time that I didn't actually have.
> 
> Thanks for your help.
> 
> Christian
> 
> 

If you're sure that the issue was raised in that merge commit, I suggest 
you (or someone else affected by this issue) do the bisect using the drm 
kernel tree [1] and bisect between the problematic tag [2] and previous 
tag [3].

[1] https://gitlab.freedesktop.org/drm/kernel
[2] https://gitlab.freedesktop.org/drm/kernel/-/tags/drm-next-2025-07-30
[3] https://gitlab.freedesktop.org/drm/kernel/-/tags/drm-next-2025-06-06

Re: radeon_fbdev_river_fbdev: failed to initialize framebuffer and setup emulation

[Alex Deucher]

On Fri, Aug 8, 2025 at 7:48 AM Christian Zigotzky
<chzigotzky@xenosoft.de> wrote:
>
>
>
> > On 08 August 2025 um 01:23 pm, Mario Limonciello <superm1@kernel.org> wrote:
> >
> > 
> >
> >> On 8/8/25 2:36 AM, Christian Zigotzky wrote:
> >> On 07 August 2025 at 04:21 pm, Limonciello, Mario <Mario.Limonciello@amd.com> wrote:
> >> Does applying
> >> https://github.com/torvalds/linux/commit/907a7a2e5bf40c6a359b2f6cc53d6fdca04009e0
> >> help?
> >> - - -
> >> Hello Mario,
> >> Thanks a lot for your patch.
> >> I tested it today but unfortunately it doesn’t solve the issue with the Radeon framebuffer.
> >> I have created two kernels with and without the drm-next-2025-07-30 updates [1] because of the issue with the Radeon graphics framebuffer device #15. [2]
> >> Download and further information: https://github.com/chzigotzky/kernels/releases/tag/v6.17.0-alpha5
> >> I have tested both kernels this week and I can definitely confirm, that the issue is somewhere in the commit drm-next-2025-07-30 updates [1].
> >> The Radeon graphics framebuffer doesn't work with the kernel with the drm-next-2025-07-30 updates [1]. Without these updates, the framebuffer works.
> >> I bisected yesterday. [2]
> >> There are some other user reports:
> >> - https://forum.hyperion-entertainment.com/viewtopic.php?p=60606#p60606
> >> - https://forum.hyperion-entertainment.com/viewtopic.php?p=60595#p60595
> >> They use other Radeon graphics chips.
> >> @All
> >> Please check the drm-next-2025-07-30 updates [1]
> >> Thanks,
> >> Christian
> >> [1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=260f6f4fda93c8485c8037865c941b42b9cba5d2
> >> [2] https://github.com/chzigotzky/kernels/issues/15
> >
> > I think there is a mistake in your bisect, which I notice from looking at your other user reports.
> >
> > The original commit you identified in your bisect and thus CC'ed me came in 6.16-rc1.
> >
> > ❯ git describe --contains 4d4c10f763d7808fbade28d83d237411603bca05
> > v6.16-rc1~50^2~19^2
> >
> > There absolutely was a regression for that was raised, but this was fixed in 6.16-rc3.
> >
> > ❯ git describe --contains 907a7a2e5bf40c6a359b2f6cc53d6fdca04009e0
> > v6.16-rc3~13^2~1
> >
> > Users in your forums posts talk about 6.16 final working fine.  So I think that when you bisected you ran into multiple confounding issues and replicated in a similar fashion.  You should check every single bisect step to see if 4d4c10f763d7808fbade28d83d237411603bca05 is applied.  If it's applied but 907a7a2e5bf40c6a359b2f6cc53d6fdca04009e0 is not applied in that step you should apply 907a7a2e5bf40c6a359b2f6cc53d6fdca04009e0.
> >
> > Hopefully that will get you down to the real cause.
>
> Thanks for the hint. Unfortunately I don’t have more time for figuring out the issue.

Does this patch help?
https://patchwork.kernel.org/project/dri-devel/patch/20250805175752.690504-4-imre.deak@intel.com/

Alex

>
> Two facts:
>
> - The Radeon driver can no longer be used.
> The Radeon driver is broken for us.
>
> - The issue is somewhere in the commit drm-next-2025-07-30 updates [1].
>
> I cannot provide any more due to time constraints.
>
> I've already spent time that I didn't actually have.
>
> Thanks for your help.
>
> Christian
>
>

Re: radeon_fbdev_river_fbdev: failed to initialize framebuffer and setup emulation

[Christian Zigotzky]

> On 08 August 2025 at 02:56 pm, Alex Deucher <alexdeucher@gmail.com> wrote :
> 
> On Fri, Aug 8, 2025 at 7:48 AM Christian Zigotzky
> <chzigotzky@xenosoft.de> wrote:
>> 
>> 
>> 
>>>> On 08 August 2025 um 01:23 pm, Mario Limonciello <superm1@kernel.org> wrote:
>>> 
>>> 
>>> 
>>>> On 8/8/25 2:36 AM, Christian Zigotzky wrote:
>>>> On 07 August 2025 at 04:21 pm, Limonciello, Mario <Mario.Limonciello@amd.com> wrote:
>>>> Does applying
>>>> https://github.com/torvalds/linux/commit/907a7a2e5bf40c6a359b2f6cc53d6fdca04009e0
>>>> help?
>>>> - - -
>>>> Hello Mario,
>>>> Thanks a lot for your patch.
>>>> I tested it today but unfortunately it doesn’t solve the issue with the Radeon framebuffer.
>>>> I have created two kernels with and without the drm-next-2025-07-30 updates [1] because of the issue with the Radeon graphics framebuffer device #15. [2]
>>>> Download and further information: https://github.com/chzigotzky/kernels/releases/tag/v6.17.0-alpha5
>>>> I have tested both kernels this week and I can definitely confirm, that the issue is somewhere in the commit drm-next-2025-07-30 updates [1].
>>>> The Radeon graphics framebuffer doesn't work with the kernel with the drm-next-2025-07-30 updates [1]. Without these updates, the framebuffer works.
>>>> I bisected yesterday. [2]
>>>> There are some other user reports:
>>>> - https://forum.hyperion-entertainment.com/viewtopic.php?p=60606#p60606
>>>> - https://forum.hyperion-entertainment.com/viewtopic.php?p=60595#p60595
>>>> They use other Radeon graphics chips.
>>>> @All
>>>> Please check the drm-next-2025-07-30 updates [1]
>>>> Thanks,
>>>> Christian
>>>> [1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=260f6f4fda93c8485c8037865c941b42b9cba5d2
>>>> [2] https://github.com/chzigotzky/kernels/issues/15
>>> 
>>> I think there is a mistake in your bisect, which I notice from looking at your other user reports.
>>> 
>>> The original commit you identified in your bisect and thus CC'ed me came in 6.16-rc1.
>>> 
>>> ❯ git describe --contains 4d4c10f763d7808fbade28d83d237411603bca05
>>> v6.16-rc1~50^2~19^2
>>> 
>>> There absolutely was a regression for that was raised, but this was fixed in 6.16-rc3.
>>> 
>>> ❯ git describe --contains 907a7a2e5bf40c6a359b2f6cc53d6fdca04009e0
>>> v6.16-rc3~13^2~1
>>> 
>>> Users in your forums posts talk about 6.16 final working fine.  So I think that when you bisected you ran into multiple confounding issues and replicated in a similar fashion.  You should check every single bisect step to see if 4d4c10f763d7808fbade28d83d237411603bca05 is applied.  If it's applied but 907a7a2e5bf40c6a359b2f6cc53d6fdca04009e0 is not applied in that step you should apply 907a7a2e5bf40c6a359b2f6cc53d6fdca04009e0.
>>> 
>>> Hopefully that will get you down to the real cause.
>> 
>> Thanks for the hint. Unfortunately I don’t have more time for figuring out the issue.
> 
> Does this patch help?
> https://patchwork.kernel.org/project/dri-devel/patch/20250805175752.690504-4-imre.deak@intel.com/
> 
> Alex

Yes, it helps. The Radeon framebuffer works again.

Thank you

Re: radeon_fbdev_river_fbdev: failed to initialize framebuffer and setup emulation

[Damien Stewart]

On 5/8/25 2:05 am, Christian Zigotzky wrote:
>
> @Hypex
> Could you please attach your full dmesg output? 

Hi. Sorry just found this. Do you still need a dmesg? I collected a few 
and can provide one for any broken version.


-- 
My regards,

Damien Stewart.

Re: radeon_fbdev_river_fbdev: failed to initialize framebuffer and setup emulation

[Christian Zigotzky]

On 08 August 2025 at 06:01 pm, Damien Stewart wrote:
> On 5/8/25 2:05 am, Christian Zigotzky wrote:
>>
>> @Hypex
>> Could you please attach your full dmesg output? 
> 
> Hi. Sorry just found this. Do you still need a dmesg? I collected a few 
> and can provide one for any broken version.
> 
> 

Hi Damien,

Never mind. There is a patch [1]. The issue is solved. (Thanks to Alex)

Cheers,
Christian

[1] 
https://github.com/chzigotzky/kernels/blob/main/patches/v2-3-3-drm-radeon-Pass-along-the-format-info-from-.fb_create-to-drm_helper_mode_fill_fb_struct.diff

Re: radeon_fbdev_river_fbdev: failed to initialize framebuffer and setup emulation

[Damien Stewart]

On 9/8/25 5:38 am, Christian Zigotzky wrote:
> Hi Damien,
>
> Never mind. There is a patch [1]. The issue is solved. (Thanks to Alex)
>
> Cheers,
> Christian
>
> [1] 
> https://github.com/chzigotzky/kernels/blob/main/patches/v2-3-3-drm-radeon-Pass-along-the-format-info-from-.fb_create-to-drm_helper_mode_fill_fb_struct.diff

Okay that's good. Patch looks simple given the trouble this issue 
caused. I actually found the email on the forums when following the 
links and noticed an at me. I do obviously receive the emails. But don't 
always read them all and tend to check the forum for updates.


-- 
My regards,

Damien Stewart.