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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
