Summary: | [Hawaii XT] 290x reclocking problems | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | Sebastian Parborg <darkdefende> | ||||||||||
Component: | DRM/Radeon | Assignee: | Default DRI bug account <dri-devel> | ||||||||||
Status: | RESOLVED FIXED | QA Contact: | |||||||||||
Severity: | normal | ||||||||||||
Priority: | medium | CC: | bugs.freedesktop, darkdefende | ||||||||||
Version: | unspecified | ||||||||||||
Hardware: | x86-64 (AMD64) | ||||||||||||
OS: | Linux (All) | ||||||||||||
Whiteboard: | |||||||||||||
i915 platform: | i915 features: | ||||||||||||
Attachments: |
|
Description
Sebastian Parborg
2014-12-18 20:26:05 UTC
Created attachment 111008 [details]
dmesg log
Created attachment 111009 [details]
290x vbios
I have the same problem. Output from radeon_pm_info when the state is supposed to be set to high: uvd disabled vce disabled power level avg sclk: 30000 mclk: 126000 Some relevant dmesg output: [ 1.744912] [drm] radeon kernel modesetting enabled. [ 1.746987] checking generic (d0000000 e10000) vs hw (d0000000 10000000) [ 1.746990] fb: switching to radeondrmfb from VESA VGA [ 1.747009] Console: switching to colour dummy device 80x25 [ 1.747325] [drm] initializing kernel modesetting (HAWAII 0x1002:0x67B1 0x1043:0x0470). [ 1.747337] [drm] register mmio base: 0xFBD80000 [ 1.747338] [drm] register mmio size: 262144 [ 1.747342] [drm] doorbell mmio base: 0xCF800000 [ 1.747343] [drm] doorbell mmio size: 8388608 [ 1.747365] radeon 0000:01:00.0: Invalid ROM contents [ 1.747977] ATOM BIOS: 67B1HB.15.41.0.2.AS04L [ 1.748038] radeon 0000:01:00.0: VRAM: 4096M 0x0000000000000000 - 0x00000000FFFFFFFF (4096M used) [ 1.748039] radeon 0000:01:00.0: GTT: 1024M 0x0000000100000000 - 0x000000013FFFFFFF [ 1.748041] [drm] Detected VRAM RAM=4096M, BAR=256M [ 1.748042] [drm] RAM width 512bits DDR [ 1.748115] [TTM] Zone kernel: Available graphics memory: 4087274 kiB [ 1.748116] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [ 1.748117] [TTM] Initializing pool allocator [ 1.748120] [TTM] Initializing DMA pool allocator [ 1.748136] [drm] radeon: 4096M of VRAM memory ready [ 1.748137] [drm] radeon: 1024M of GTT memory ready. [ 1.748147] [drm] Loading hawaii Microcode [ 1.748302] [drm] Internal thermal controller with fan control [ 1.748342] [drm] probing gen 2 caps for device 1022:960b = 1300c82/0 [ 1.763278] [drm:ci_dpm_init [radeon]] *ERROR* Invalid PCC GPIO: 13! [ 1.763282] == power state 0 == [ 1.763283] ui class: none [ 1.763284] internal class: boot [ 1.763285] caps: [ 1.763286] uvd vclk: 0 dclk: 0 [ 1.763287] power level 0 sclk: 30000 mclk: 15000 pcie gen: 2 pcie lanes: 8 [ 1.763288] status: c r b [ 1.763289] == power state 1 == [ 1.763290] ui class: performance [ 1.763290] internal class: none [ 1.763291] caps: [ 1.763292] uvd vclk: 0 dclk: 0 [ 1.763293] power level 0 sclk: 30000 mclk: 15000 pcie gen: 2 pcie lanes: 8 [ 1.763294] power level 1 sclk: 100000 mclk: 126000 pcie gen: 2 pcie lanes: 8 [ 1.763295] status: [ 1.771519] [drm] radeon: dpm initialized Forgot to mention my setup. I'm using an ASUS R9 290, a Linux Mint base system tracking the xorg-edgers PPA, and kernel 3.19-rc3 from here: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19-rc3-vivid/ I have the latest linux-firmware. The mclk began changing after I upgraded from 3.18.1, but the sclk is still stuck at the lowest level. Created attachment 113387 [details] [review] possible fix The attached patch should fix the bug. Seems to have fixed the issue for me. However, I only did some quick tests, so perhaps leave this bug open for a few more days so I can test if there are still some corner cases where it breaks. Thank you so muck Alex! :) (In reply to Alex Deucher from comment #5) > Created attachment 113387 [details] [review] [review] > possible fix > > The attached patch should fix the bug. It works beautifully here on my R9 290. Thanks! I've been using it for a few days now. It seems like the reclocking issue is completely fixed for me. I'll close this bug as it seems to work flawlessly for Brooks too. Thanks again Alex. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.