Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1517489 - radeon module not loading on boot for 4.13.13-200.fc26.x86_64
Summary: radeon module not loading on boot for 4.13.13-200.fc26.x86_64
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati
Version: 26
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-26 06:16 UTC by nic
Modified: 2018-05-29 12:39 UTC (History)
27 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-29 12:39:20 UTC


Attachments (Terms of Use)

Description nic 2017-11-26 06:16:16 UTC
Description of problem:
radeon module not loaded so multi-monitor will only work as mirror

Version-Release number of selected component (if applicable):
4.13.13-200.fc26.x86_64

How reproducible:
everytime

Steps to Reproduce:
1.boot 4.13.13-200.fc26.x86_64
2.Both screens mirrored rather than extended
3.

Actual results:

xrandr: Failed to get size of gamma for output default
Screen 0: minimum 640 x 400, current 1400 x 1050, maximum 1400 x 1050
default connected 1400x1050+0+0 0mm x 0mm
   1400x1050      0.00* 
   1280x1024      0.00  
   1152x864       0.00  
   1024x768       0.00  
   800x600        0.00  
   640x480        0.00  
   720x400        0.00  
[nic@localhost ~]$ lshw -C display
WARNING: you should run this program as super-user.
  *-display UNCLAIMED       
       description: VGA compatible controller
       product: Juniper XT [Radeon HD 6770]
       vendor: Advanced Micro Devices, Inc. [AMD/ATI]
       physical id: 0
       bus info: pci@0000:01:00.0
       version: 00
       width: 64 bits
       clock: 33MHz
       capabilities: vga_controller cap_list
       configuration: latency=0
       resources: memory:d0000000-dfffffff memory:fea20000-fea3ffff ioport:e000(size=256) memory:c0000-dffff
WARNING: output may be incomplete or inaccurate, you should run this program as super-user.
[nic@localhost ~]$ lsmod | grep radeon
radeon               1470464  0
i2c_algo_bit           16384  1 radeon
drm_kms_helper        159744  1 radeon
ttm                    94208  1 radeon
drm                   352256  3 radeon,ttm,drm_kms_helper

So rmmod radeon

then modprobe radeon

display returns to light-dm and I need to login again

lsmod | grep radeon
radeon               1470464  3
i2c_algo_bit           16384  1 radeon
drm_kms_helper        159744  1 radeon
ttm                    94208  1 radeon
drm                   352256  6 radeon,ttm,drm_kms_helper
[root@localhost nic]# 

Extract from journal explains

journalctl -b | grep radeon
Nov 26 16:46:58 localhost.localdomain kernel: [drm] radeon kernel modesetting enabled.
Nov 26 16:46:58 localhost.localdomain kernel: fb: switching to radeondrmfb from EFI VGA
Nov 26 16:46:58 localhost.localdomain kernel: radeon 0000:01:00.0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used)
Nov 26 16:46:58 localhost.localdomain kernel: radeon 0000:01:00.0: GTT: 1024M 0x0000000040000000 - 0x000000007FFFFFFF
Nov 26 16:46:58 localhost.localdomain kernel: [drm] radeon: 1024M of VRAM memory ready
Nov 26 16:46:58 localhost.localdomain kernel: [drm] radeon: 1024M of GTT memory ready.
Nov 26 16:46:58 localhost.localdomain kernel: radeon 0000:01:00.0: Direct firmware load for radeon/JUNIPER_pfp.bin failed with error -2
Nov 26 16:46:58 localhost.localdomain kernel: r600_cp: Failed to load firmware "radeon/JUNIPER_pfp.bin"
Nov 26 16:46:58 localhost.localdomain kernel: [drm:evergreen_init [radeon]] *ERROR* Failed to load firmware!
Nov 26 16:46:58 localhost.localdomain kernel: radeon 0000:01:00.0: Fatal error during GPU init
Nov 26 16:46:58 localhost.localdomain kernel: [drm] radeon: finishing device.
Nov 26 16:46:58 localhost.localdomain kernel: [drm] radeon: ttm finalized
Nov 26 16:46:58 localhost.localdomain kernel: radeon: probe of 0000:01:00.0 failed with error -2
Nov 26 16:53:24 localhost.localdomain kernel: [drm] radeon kernel modesetting enabled.
Nov 26 16:53:24 localhost.localdomain kernel: radeon 0000:01:00.0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used)
Nov 26 16:53:24 localhost.localdomain kernel: radeon 0000:01:00.0: GTT: 1024M 0x0000000040000000 - 0x000000007FFFFFFF
Nov 26 16:53:24 localhost.localdomain kernel: [drm] radeon: 1024M of VRAM memory ready
Nov 26 16:53:24 localhost.localdomain kernel: [drm] radeon: 1024M of GTT memory ready.
Nov 26 16:53:25 localhost.localdomain kernel: [drm] radeon: dpm initialized
Nov 26 16:53:25 localhost.localdomain kernel: [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
Nov 26 16:53:25 localhost.localdomain kernel: radeon 0000:01:00.0: WB enabled
Nov 26 16:53:25 localhost.localdomain kernel: radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0xffff897f88326c00
Nov 26 16:53:25 localhost.localdomain kernel: radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000040000c0c and cpu addr 0xffff897f88326c0c
Nov 26 16:53:25 localhost.localdomain kernel: radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x000000000005c418 and cpu addr 0xffffa69f0481c418
Nov 26 16:53:25 localhost.localdomain kernel: radeon 0000:01:00.0: radeon: MSI limited to 32-bit
Nov 26 16:53:25 localhost.localdomain kernel: radeon 0000:01:00.0: radeon: using MSI.
Nov 26 16:53:25 localhost.localdomain kernel: [drm] radeon: irq initialized.
Nov 26 16:53:25 localhost.localdomain kernel: fbcon: radeondrmfb (fb0) is primary device
Nov 26 16:53:25 localhost.localdomain kernel: radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device
Nov 26 16:53:25 localhost.localdomain kernel: [drm] Initialized radeon 2.50.0 20080528 for 0000:01:00.0 on minor 0

Comment 1 nic 2017-12-09 00:47:53 UTC
This behaviour continues with changes to the kernel to 4.13.16-202.fc26.x86_64. I searched through other bugs to see if anyone else was having a similar problem and I found https://bugzilla.redhat.com/show_bug.cgi?id=1520682 which was similar. I tried Isaac's idea and it worked for me.

Rebuilding my initramfs with 'dracut --regenerate-all --force --install "/usr/lib/firmware/amdgpu/*"' worked, so I guess either the firmware needs to go into the initramfs by default or the module load should be delayed until after root is mounted.
There appears to either be a change in module loading or initramfs that causes problems with some modules

Comment 2 Fedora End Of Life 2018-05-03 08:22:21 UTC
This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 3 Fedora End Of Life 2018-05-29 12:39:20 UTC
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26
is no longer maintained, which means that it will not receive any
further security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.