Bug 107880

(In reply to Marvin Damschen from comment #0)
> System hangs after "fb: switching to amdgpudrmfb from EFI VGA".

How long have you waited for? E.g. if a microcode file is missing, the attempt to load it can hang for one or several minutes before timing out.


> I am unable to obtain any logs of the crash (LUKS encryption might be the
> reason?).

One possibility is to prevent the driver from loading by passing

 modprobe.blacklist=amdgpu

on the kernel command line, then you can try manually loading it with

 sudo modprobe amdgpu

and should get the full dmesg output.

(In reply to Michel Dänzer from comment #1)
> (In reply to Marvin Damschen from comment #0)
> > System hangs after "fb: switching to amdgpudrmfb from EFI VGA".
> 
> How long have you waited for? E.g. if a microcode file is missing, the
> attempt to load it can hang for one or several minutes before timing out.
Waited for ~5min now, but nothing changed.

> > I am unable to obtain any logs of the crash (LUKS encryption might be the
> > reason?).
> 
> One possibility is to prevent the driver from loading by passing
> 
>  modprobe.blacklist=amdgpu
> 
> on the kernel command line, then you can try manually loading it with
> 
>  sudo modprobe amdgpu
> 
> and should get the full dmesg output.
Thank you, this worked. Full output is attached, but appears fine. Still, the video output freezes.

Created attachment 141502 [details]
Modprobe amdgpu freezes video output with 4.19-rc3

Looks like there may be an issue with the VCN microcode loading. Does

 amdgpu.ip_block_mask=0xff

on the kernel command line avoid the problem?

Can you bisect?

(In reply to Michel Dänzer from comment #4)
> Looks like there may be an issue with the VCN microcode loading. Does
> 
>  amdgpu.ip_block_mask=0xff
> 
> on the kernel command line avoid the problem?
It does! dmesg contains a lot of call traces though (I will attach).

> Can you bisect?
I can, but will probably find time by the end of the week only.

Thank you
Marvin

Created attachment 141503 [details]
4.19-rc3 with amdgpu.ip_block_mask=0xff

Dmesg shows: Found VCN firmware Version: 1.24 Family ID: 18.
It is really old.
Please update with latest vcn firmware for raven (1.73)
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=bd63ccb9d9dd926aa7072f416363dd8f529b5fca.

I overlooked that the ubuntu kernel builds bring their own firmware for each version. In my case, I had the recent firmware in /lib/firmware/amdgpu, but /lib/firmware/4.19.0-041900rc3-generic/amdgpu/ was actually used. I moved the files accordingly and 4.19-rc3 boots perfectly fine now without any extra parameters.
Thank you and sorry for the trouble.

Hi Marvin,

That is great! I want to check with you where this old VCN firmware came from.

Did you install old AMD ROCm package on this system before?

Best Regards!
James Zhu

(In reply to jamesz@amd.com from comment #9)

> Did you install old AMD ROCm package on this system before?
Yes, I did. I now believe that removing all traces of rocm-dkms eliminated the root of the problem.

Best regards
Marvin

I think latest ROCm package has fixed this issue. You are welcome to try it.

Best Regards!
James zhu

rocm-dkms (http://repo.radeon.com/rocm/apt/debian/pool/main/r/rock-dkms/rock-dkms_1.8-199_all.deb) currently still contains the old firmware. I will open an issue on ROCm's GitHub repo.

Best regards
Marvin