Re: drm/amdgpu: use dirty framebuffer helper

CR0: 80050033 [ 458.936342] CR2: 0010 CR3: 00012337c000 CR4: 06e0 [ 458.957983] amdgpu :01:00.0: [drm] fb0: amdgpudrmfb frame buffer device Regards, Arthur Marsh.

Re: [PATCH] drm/amdgpu: use dirty framebuffer helper

Thanks, the patch applied against 6.0-rc6 kernel worked and the amdgpu module loaded and works on my Radeon R7 250 (Cape Verde) GPU. Arthur Marsh. On 20 September 2022 2:03:54 am ACST, Alex Deucher wrote: >On Sun, Sep 18, 2022 at 8:09 AM root wrote: >> >> Hi, I recently exper

[PATCH V4 17/17] drm/amd/pm: unified lock protections in amdgpu_dpm.c

: [drm] fb0: amdgpudrmfb frame buffer device I can supply extra details but found no logging from the sessions that experienced the lock-up. Regards, Arthur Marsh.

[PATCH V4 17/17] drm/amd/pm: unified lock protections in amdgpu_dpm.c

amp;adev->pm.mutex); - return ret; } Regards, Arthur Marsh.

[PATCH V4 17/17] drm/amd/pm: unified lock protections in amdgpu_dpm.c

:33:45 am64 kernel: [ 247.068412] fbcon: amdgpudrmfb (fb0) is primary device The monitor still went blank but the magic sysreq sync and boot worked, allowing capture of the above log but nothing after the line above. Regards, Arthur Marsh.

[PATCH V4 17/17] drm/amd/pm: unified lock protections in amdgpu_dpm.c

Hi, short answer is that with both patches applied, I am successfully running the amdgpu kernel module on radeonsi (plasma desktop on X.org). I confirmed that CONFIG_LOCKDEP_SUPPORT=y is enabled in the kernel. With the first patch applied and remotely connecting to the machine and loading amdgpu

RE: [PATCH V4 17/17] drm/amd/pm: unified lock protections in amdgpu_dpm.c

Thanks Evan, your patch applied to Linus' origin/master source worked for me running amdgpu module with a Radeon SI (Cape Verde) GPU card. Regards, Arthur Marsh. On 8 April 2022 9:54:57 pm ACST, "Quan, Evan" wrote: >[AMD Official Use Only] > >Hi Arthur, > >Pl

radeon ARUBA NULL pointer dereference

bcore libphy usb_common [ 17.220388] CR2: 00a0 [ 17.220390] ---[ end trace ]--- Happy to provide additional information and run tests. Regards, Arthur Marsh.

NULL pointer dereference after ib test on ring 7 succeeded

After rebuilding current Linus git head with: dma-mapping: report unlimited DMA addressing in IOMMU DMA path b348b6d17fd1d5d89b86db602f02bea54a754bd8 applied, the radeon module load gets further before hitting another NULL pointer dereference: [ 17.777472] [drm] radeon kernel modesetting enabl

drm/radeon: remove load callback from kms_driver

back, we have to manually call "radeon_driver_load_kms" instead. This machine reports having: AMD A10-6800K APU with Radeon HD Graphics with the gpu appearing as Advanced Micro Devices [AMD/ATI] Richland [Radeon HD 8670D] 1002:990c Regards, Arthur Marsh.

NULL pointer dereference with kernel 6.12.0-rc1 and ARUBA GPU

[ 13.069630] [drm] radeon kernel modesetting enabled. [ 13.069681] radeon :00:01.0: vgaarb: deactivate vga console [ 13.070435] Console: switching to colour dummy device 80x25 [ 13.070632] [drm] initializing kernel modesetting (ARUBA 0x1002:0x990C 0x1002:0x0123 0x00). [ 13.070718] AT