Hello Rick,
On Fri, Oct 12, 2018 at 11:51:40PM +0000, Rick Stevens wrote:
> >
> > [drm] amdgpu kernel modesetting enabled.
> > [drm] initializing kernel modesetting (RAVEN 0x1002:0x15DD 0x1458:0xD000
> > 0xC6).
> > [drm] register mmio base: 0xFE600000
> > [drm] register mmio size: 524288
> > [drm] add ip block number 0 <soc15_common>
> > [drm] add ip block number 1 <gmc_v9_0>
> > [drm] add ip block number 2 <vega10_ih>
> > [drm] add ip block number 3 <psp>
> > [drm] add ip block number 4 <powerplay>
> > [drm] add ip block number 5 <dm>
> > [drm] add ip block number 6 <gfx_v9_0>
> > [drm] add ip block number 7 <sdma_v4_0>
> > [drm] add ip block number 8 <vcn_v1_0>
> > amdgpu 0000:06:00.0: Direct firmware load for amdgpu/raven_gpu_info.bin
> > failed with error -2
> > amdgpu 0000:06:00.0: Failed to load gpu_info firmware
> > "amdgpu/raven_gpu_info.bin"
> > amdgpu 0000:06:00.0: Fatal error during GPU init
> > [drm] amdgpu: finishing device.
> > amdgpu: probe of 0000:06:00.0 failed with error -2
>
> Well, error "-2" typically is "file not found", so my guess is the code
> isn't looking in the right spot for the firmware files. Yes, you have
> them in the right spot, but it could be a permissions or selinux context
> issue as well.
>
> Have you checked dmesg, journalctl and/or the selinux logs to see what
> they say?
What I quoted above _is_ from the journal. I double checked, there are no
other suspicious messages. The SELinux label for the firmware files is
"system_u:object_r:lib_t:s0". There are also no AVC denials.
My pre-post searching told me "-2" is for "file not found", so I had already
checked the usual. I thought if I could get a more verbose message in the
journal, maybe I get the reason behind the "-2", so I replaced "quiet" by
"verbose" in kernel arguments, that didn't help. I also looked if there are
any udev rules that might try to load the firmware from a different path
(apparently Ubuntu did that at some point), no go.
I also ran `rpm --verify` on the kernel-{core,modules} and linux-firmware
packages, all I got is:
# rpm --verify kernel-core-4.18.12 # picked a few kernels, same for all
.M....... g /boot/System.map-4.18.12-200.fc28.x86_64
.M....... g /boot/initramfs-4.18.12-200.fc28.x86_64.img
The permissions are 600.
My hunch is, as the ROCm installation uses dkms to build the kernel module
(which failed btw, that's why ROCm didn't work for me), the uninstallation
somehow leaves behind some configuration which persists across kernels. Do you
think that's possible?
Thanks a lot for your response.
Cheers,
--
Suvayu
Open source is the future. It sets us free.
_______________________________________________
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
