Bug 194664 - [vt] radeonkms_load="YES" in loader.conf.local halts system, "Failed to load firmware!"
Summary: [vt] radeonkms_load="YES" in loader.conf.local halts system, "Failed to load ...
Status: Closed Not A Bug
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.1-STABLE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-28 17:10 UTC by crum.zach
Modified: 2015-03-12 08:30 UTC (History)
3 users (show)

See Also:


Attachments
dmesg output from system (15.71 KB, text/plain)
2014-10-28 17:10 UTC, crum.zach
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description crum.zach 2014-10-28 17:10:41 UTC
Created attachment 148741 [details]
dmesg output from system

When enabled, the radeon kms driver appears to halt the kernel. The only way to rescue the system is to use a different boot drive and remove the offending line from /boot/loader.conf.local 

This is the only part of the trace I can capture

info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM...
info: [drm] radeon_read_bios: Map address: 0xffff800000c0000 (131072 bytes)
info: [drm] ATOM BIOS: CAYMAN
drmn0: info: VRAM: 2048M 0x0000000000000000 - 0x000000007FFFFFFF (2048M used)
drmn0: info: GTT: 512M 0x0000000000000000 - 0x000000009FFFFFFF
info: [drm] Detected VRAM RAM=2048M, BAR=256M
info: [drm] RAM width 256bits DDR
[TTM] Zone kernel: Available graphics memory: 8374848 kiB
[TTM] Zone  dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
info: [drm] radeon: 2048M of VRAM memory ready
info: [drm] radeon: 512M of GTT memory ready.
info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
info: [drm] Driver supports precise vblank timestamp query.
info: [drm] radeon: irq initialized.
info: [drm] GART: num cpu pages 131072, num gpu pages 131072
info: [drm] probinggen 2 caps for device 1022:9603 = 2/0
info: [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
info: [drm] Loading CAYMn Microcode
error: [drm:pid0:ni_init_microcode] *ERROR* ni_cp: Failed to load firmware "radeonkmsfw_CAYMAN_pfp"
error: [drm:pid0:cayman_startup] *ERROR* Failed to load firmware!
drmn0: error: disabling GPU acceleration
drmn0: warning: 0xffffff800075f6800 unpin not necessary
drmn0: warning: 0xffffff800075f6800 unpin not necessaary
error: [drm:pid0:cayman_init] *ERROR* radeon: MC ucode required for NI+.
drmn0: error: Fatal error during GPU init
info: [drm] radeon: finished device.
[TTM] Finalizing pool allocator
Comment 1 crum.zach 2014-11-04 23:54:06 UTC
Xorg works fine as well.

Both of these scenarios halt the system upon boot:
kern.vty=vt
radeonkms_load="YES"

#kern.vty=vt
radeonkms_load="YES"

However,

  kern.vty=vt 

boots fine, and after signing in, I can kldload the driver without any issues.
Comment 2 Tijl Coosemans freebsd_committer freebsd_triage 2014-11-05 11:33:48 UTC
The firmware is in a separate kernel module so try adding the following to loader.conf:

radeonkmsfw_CAYMAN_pfp_load="YES"
Comment 3 crum.zach 2014-11-06 21:20:50 UTC
still no luck. I noted /boot/modules only had virtualbox kernel modules in it, so I copied the entire /boot/kernel directory into it. Still had the same result.

#vesa_load="YES"
hw.pci.default_vgapci_unit="0"
autoboot_delay="5"
loader_logo="beastie"
module_path="/boot/modules"
kern.vty=vt
#radeonkms_load="YES"
#radeonkmsfw_CAYMAN_pfp_load="YES"

I can still kldload the radeonkms driver after signing in.
Comment 4 Tijl Coosemans freebsd_committer freebsd_triage 2014-11-06 22:07:49 UTC
(In reply to crum.zach from comment #3)
> still no luck. I noted /boot/modules only had virtualbox kernel modules in
> it, so I copied the entire /boot/kernel directory into it. Still had the
> same result.

That should not be necessary.

> #vesa_load="YES"
> hw.pci.default_vgapci_unit="0"
> autoboot_delay="5"
> loader_logo="beastie"
> module_path="/boot/modules"
> kern.vty=vt
> #radeonkms_load="YES"
> #radeonkmsfw_CAYMAN_pfp_load="YES"

There are more CAYMAN firmware modules.  Maybe you need to load all of them:

radeonkms_load="YES"
radeonkmsfw_CAYMAN_mc_load="YES"
radeonkmsfw_CAYMAN_me_load="YES"
radeonkmsfw_CAYMAN_pfp_load="YES"
radeonkmsfw_CAYMAN_rlc_load="YES"
Comment 5 crum.zach 2014-11-09 03:03:41 UTC
How is the boot processing using 'radeonkms_load="YES"'

different from kldload after signing in? It seems to me that they should work the same.
Comment 6 Jean-Sébastien Pédron freebsd_committer freebsd_triage 2015-01-14 23:12:29 UTC
The problem with loading the modules from loader.conf is that the filesystem isn't mounted yet when the card is initialized. Therefore, radeonkms can't find any of the firmwares.

You can find instructions on the wiki to configure loader.conf:
https://wiki.freebsd.org/Graphics#Video_driver_loaded_at_boot_time
Comment 7 Marcus von Appen freebsd_committer freebsd_triage 2015-02-18 11:54:19 UTC
Updated 10.1-BETA and 10.1-RC versioned bugs to 10.1-STABLE.
Comment 8 Jean-Sébastien Pédron freebsd_committer freebsd_triage 2015-03-11 23:42:25 UTC
I want to add more information: module dependencies between the driver and the firmwares are resolved during device initialization. That's why firmwares can't be loaded automatically by the loader. And when the device is initialized, /boot is not mounted yet.

I understand this is inconvenient.
Comment 9 crum.zach 2015-03-12 00:11:22 UTC
Thank you, this makes complete sense. Should Documentation be made aware of the issue?
Comment 10 Jean-Sébastien Pédron freebsd_committer freebsd_triage 2015-03-12 08:30:22 UTC
Currently, the primary source of documentation regarding the graphics stack is the wiki (https://wiki.freebsd.org/Graphics), mainly because this area is moving fast. I'm going to expand a bit the paragraph about this particular problem.

There are plans to update the Handbook section; I don't know what the status is.