Bug 75992 - Display freezes & corruption with an r7 260x on 3.14-rc6
Display freezes & corruption with an r7 260x on 3.14-rc6
Status: NEW
Product: DRI
Classification: Unclassified
Component: DRM/Radeon
unspecified
x86-64 (AMD64) Linux (All)
: medium major
Assigned To: Default DRI bug account
:
: 77281 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-03-10 17:25 UTC by Ed Tomlinson
Modified: 2014-09-26 04:22 UTC (History)
5 users (show)

See Also:


Attachments
log of boot (1.86 MB, text/plain)
2014-03-10 17:25 UTC, Ed Tomlinson
no flags Details
xorg log of bug (67.94 KB, text/plain)
2014-03-10 17:25 UTC, Ed Tomlinson
no flags Details
simple example of corruption (there can be many more rectangles) (32.04 KB, image/png)
2014-03-10 17:28 UTC, Ed Tomlinson
no flags Details
testing patch (2.67 KB, patch)
2014-03-24 14:55 UTC, Alex Deucher
no flags Details | Splinter Review
possible fix (788 bytes, patch)
2014-03-27 14:36 UTC, Alex Deucher
no flags Details | Splinter Review
workaround (484 bytes, patch)
2014-03-28 14:12 UTC, Alex Deucher
no flags Details | Splinter Review
pcie 0000:01:00.0 rom (64.00 KB, application/octet-stream)
2014-03-28 20:09 UTC, Ed Tomlinson
no flags Details
lspci -vnn (17.35 KB, text/plain)
2014-04-10 17:35 UTC, dunkelfuerst
no flags Details
disable voltage control (555 bytes, patch)
2014-04-10 19:05 UTC, Alex Deucher
no flags Details | Splinter Review
limit mclk (826 bytes, patch)
2014-04-10 19:10 UTC, Alex Deucher
no flags Details | Splinter Review
lspci (Ashrafinia) (9.03 KB, text/plain)
2014-04-10 20:36 UTC, Egon Ashrafinia
no flags Details
lspci -vnn for me too (9.74 KB, text/plain)
2014-04-10 21:30 UTC, nicolas.laplante
no flags Details
lspci -vnn (just the graphics card details posted) (1.67 KB, text/plain)
2014-04-10 21:50 UTC, Ed Tomlinson
no flags Details
try newer mc ucode (2.89 KB, patch)
2014-04-11 03:02 UTC, Alex Deucher
no flags Details | Splinter Review
Error in dmesg (852 bytes, text/plain)
2014-04-11 11:17 UTC, nicolas.laplante
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Tomlinson 2014-03-10 17:25:10 UTC
Created attachment 95520 [details]
log of boot

I recently added a R7 260X to my system.  While the card works with 3.13 its supposed work much better with 14-rc.  This is not the case.  My system is unstable without radeon.dpm=0 which was the default in .13.  

linux 3.14-rc6 (with an up to date arch, stable X and mesa-git (10.2) mesa 10.1 and 10.0 also show very similar problems.

When X started I did notice some corruption.  There are sets of two rectangles about of a height of 2 or 3 mm, width of 25m or so with a second about a cm below.  The often occurs in chomium especially when scrolling.  Runing the  unigine-sanctuary or unigine-tropics demo/benchmark programs also produce the above problems and eventually stall.
Comment 1 Ed Tomlinson 2014-03-10 17:25:55 UTC
Created attachment 95521 [details]
xorg log of bug
Comment 2 Ed Tomlinson 2014-03-10 17:28:01 UTC
Created attachment 95523 [details]
simple example of corruption (there can be many more rectangles)
Comment 3 Ed Tomlinson 2014-03-23 20:04:07 UTC
This problem is still occurring with rc7 too.  Booted with dpm, the system is NOT usable.  X stalls and C+A+D is needed to get the box back.
Comment 4 Alex Deucher 2014-03-24 14:55:04 UTC
Created attachment 96290 [details] [review]
testing patch

Does the attached patch help?  It disables most dpm features.  If so can you narrow down which specific features are problematic?
Comment 5 Ed Tomlinson 2014-03-25 13:00:52 UTC
I'm building a rc8 with this applied now.  Any advise on what to enable and in what order?
Comment 6 Alex Deucher 2014-03-25 14:55:14 UTC
(In reply to comment #5)
> I'm building a rc8 with this applied now.  Any advise on what to enable and
> in what order?

It doesn't really matter in what order you test.  Just start at the top and enable features one by one until you hit a problem.  If you hit a problem, leave the problematic feature disabled and check the rest.  Once you've identified which which feature(s) are problematic on your board let me know.
Comment 7 Ed Tomlinson 2014-03-26 17:33:18 UTC
The only setting I cannot revert in the patch is:

pi->mclk_dpm_key_disabled = 1;

To avoid humdreds of: radeon 0000:01:00.0: GPU fault detected: 146 0x0aa20804
and 147 type errors I had to add: export R600_DEBUG=nohyperz in the X startup
as documented in: https://bugzilla.kernel.org/show_bug.cgi?id=66981

Also found some funny stuff to do with primary and secondary graphic cards.
booting with the primary as the builtin hd4600, with no radeon specific stuff in the kernel command line does NOT enable the dpm on the secondary radeon card and trying to use radeon.dpm=1 causes the X startup to stall.  Note in all cases the a xorg.conf file selects the radeon card to be used.
Comment 8 Alex Deucher 2014-03-27 14:36:38 UTC
Created attachment 96460 [details] [review]
possible fix

(In reply to comment #7)
> The only setting I cannot revert in the patch is:
> 
> pi->mclk_dpm_key_disabled = 1;

Thanks for narrowing it down.  Does the attached patch help?  Remove all previous patches when testing this.
Comment 9 Ed Tomlinson 2014-03-27 18:53:38 UTC
With thest testing patch removed and the possible fix added I am not seeing corruptions; however the tests are running a 6-7fps vs 30...  It is progress though.
Comment 10 Alex Deucher 2014-03-27 22:08:20 UTC
(In reply to comment #9)
> With thest testing patch removed and the possible fix added I am not seeing
> corruptions; however the tests are running a 6-7fps vs 30...  It is progress
> though.

Are you seeing performance issues with pi->mclk_dpm_key_disabled = 1; as well?
Comment 11 Ed Tomlinson 2014-03-28 12:13:21 UTC
Yes.
Comment 12 Ed Tomlinson 2014-03-28 12:19:08 UTC
On Thursday 27 March 2014 22:08:20 you wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=75992
> 
> --- Comment #10 from Alex Deucher <agd5f@yahoo.com> ---
> (In reply to comment #9)
> > With thest testing patch removed and the possible fix added I am not seeing
> > corruptions; however the tests are running a 6-7fps vs 30...  It is progress
> > though.
> 
> Are you seeing performance issues with pi->mclk_dpm_key_disabled = 1; as well?

Yes.

Ed
Comment 13 Alex Deucher 2014-03-28 14:12:49 UTC
Created attachment 96532 [details] [review]
workaround

Does this patch fix the stability and performance issues?
Comment 14 Ed Tomlinson 2014-03-28 17:28:35 UTC
disable_mclk_switching = true; gives 30fps and corruption (and eventually a gpu stall)

disable_mclk_switching = true; and pi->mclk_dpm_key_disabled = 1; no corruptions but speed is slow

with mclk_switching = true; and the patch disabling WREG32 setups, I get 30fps & corruptions and gpu stalls/crashes

Ideas?
Comment 15 Alex Deucher 2014-03-28 18:18:43 UTC
Please attach a copy of your vbios:
(as root)
(use lspci to get the bus id)
cd /sys/bus/pci/devices/<pci bus id>
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom
Comment 16 Ed Tomlinson 2014-03-28 20:09:40 UTC
Created attachment 96568 [details]
pcie 0000:01:00.0 rom
Comment 17 Ed Tomlinson 2014-03-28 23:07:55 UTC
To verify the HW is okay, I installed the catalyst drivers (14.3) and am able to run the same set of tests with no corruption at about 85fps vs 30fps with corruption or 6fps without corruption.

The r7 260x is a fairly new card.  That it works at all with the opensource driver stack is GREAT.  As demonstrated by the fglrx drivers, there is lots of room for improvements though <GRIN>.
Comment 18 nucrap 2014-04-02 16:49:40 UTC
Hi, I can confirm this regression on Kernel 3.14 using the the FOSS driver and r7 260x of course.

I experience artifacts, constanst hangs and - in result of the hangs, "colorfully" filled screens rendering the system unusable.

Can I help somehow? I'm not a developer, just to warn you...
Comment 19 nucrap 2014-04-02 22:31:43 UTC
Ah, and I also get those rectangles. So it's definately the same bug!
Comment 20 nicolas.laplante 2014-04-07 17:18:25 UTC
Just to add my 2c to this issue: if I set radeon.dpm=0 on the command line, the card defaults to the "profile" power method.

If I try to:

echo "high" > /sys/class/drm/card0/device/power_profile

the screen goes black and I have to shut down using the power button (Ctrl+Alt+Del doesn't even work).

This happens both while on the desktop or in another vt.
Comment 21 dunkelfuerst 2014-04-10 15:19:15 UTC
Happens to me too. Only radeon.dpm=0 stabilizes the system.
Comment 22 Alex Deucher 2014-04-10 17:30:49 UTC
Can you post the pci ids and subsystem ids for your cards?  e.g., lspci -vnn
Comment 23 dunkelfuerst 2014-04-10 17:35:52 UTC
Created attachment 97173 [details]
lspci -vnn

Here you go.
Comment 24 Ed Tomlinson 2014-04-10 18:37:18 UTC
Just to see what happens with the latest drm fixes I built linux from git
(last commit 4ba85265790ba3681deeaf73f018c0eb829a7341).  I am still seeing corruptions and eventually get stalls.  Lots of 

Apr 10 14:17:11 localhost kernel: [ 2390.829175] VM fault (0x00, vmid 0) at page 0, read from '' (0x00000000) (0)
Apr 10 14:17:11 localhost kernel: [ 2390.829178] radeon 0000:01:00.0: GPU fault detected: 147 0x049a4408
Apr 10 14:17:11 localhost kernel: [ 2390.829179] radeon 0000:01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x00000000
Apr 10 14:17:11 localhost kernel: [ 2390.829180] radeon 0000:01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000

with a few like (maybe one for every 100 of the one above):

Apr 10 14:17:11 localhost kernel: [ 2390.828639] VM fault (0x08, vmid 13) at page 0, read from 'TC3' (0x54433300) (68)
Apr 10 14:17:11 localhost kernel: [ 2390.828642] radeon 0000:01:00.0: GPU fault detected: 147 0x049a0408
Apr 10 14:17:11 localhost kernel: [ 2390.828643] radeon 0000:01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x00000000
Apr 10 14:17:11 localhost kernel: [ 2390.828644] radeon 0000:01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x1A008008

or

Apr 10 14:17:11 localhost kernel: [ 2390.805747] VM fault (0x08, vmid 13) at page 31524, read from 'TC2' (0x54433200) (72)
Apr 10 14:17:11 localhost kernel: [ 2390.805749] radeon 0000:01:00.0: GPU fault detected: 147 0x049a4808
Apr 10 14:17:11 localhost kernel: [ 2390.805749] radeon 0000:01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x00000000
Apr 10 14:17:11 localhost kernel: [ 2390.805750] radeon 0000:01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000

or

Apr 10 13:42:44 localhost kernel: [  321.759360] VM fault (0x04, vmid 1) at page 29021, read from 'TC3' (0x54433300) (68)
Apr 10 13:42:44 localhost kernel: [  321.759362] radeon 0000:01:00.0: GPU fault detected: 146 0x0ba20404
Apr 10 13:42:44 localhost kernel: [  321.759363] radeon 0000:01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x00000000
Apr 10 13:42:44 localhost kernel: [  321.759363] radeon 0000:01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000

interposed between the much more common message above.

These error happen with and without hyperz enabled
( via the following in .xinitrc
 export R600_HYPERZ=0
 export R600_DEBUG=nohyperz )

This is with ddx, glamor, mesa built from todays git (13:30 or so EDT)

Once I can get xorg rc to build with builtin glamor I'll try with it too.
Comment 25 Ed Tomlinson 2014-04-10 18:44:24 UTC
On the positive side I was able to get a few benchmarks to run to completion and they are up from 30fps on .14 to 40fps with .15-git.

The fglrx drivers are faster (80fps) but eventually crash after a day or so which is not unexpected with the (beta) versions.

There are now four of us reporting this issue in .14
Comment 26 Alex Deucher 2014-04-10 19:05:56 UTC
Created attachment 97175 [details] [review]
disable voltage control

Does this patch help?
Comment 27 Alex Deucher 2014-04-10 19:10:04 UTC
Created attachment 97176 [details] [review]
limit mclk

Another patch to try.
Comment 28 Alex Deucher 2014-04-10 20:26:22 UTC
*** Bug 77281 has been marked as a duplicate of this bug. ***
Comment 29 Egon Ashrafinia 2014-04-10 20:36:35 UTC
Created attachment 97191 [details]
lspci (Ashrafinia)

As my Bug report (77281) is a duplicate of this bug here, I will help you to figure out the issue. I have the same issue as you may knowl

Here is my lspci.

I hope you also got some information from my bug report. Please ask me as much as you want to. I really want to fix this.
Comment 30 Egon Ashrafinia 2014-04-10 21:03:53 UTC
"echo "high" > /sys/class/drm/card0/device/power_profile" crashes me too when I try to set it after "radeon.dpm=0".

Because the default one is really on a low level. No OpenGL animation works smooth.

My hole Display turned black, but the computer was still turned on. ... No reactions anymore. Hard Restart required.
Comment 31 nicolas.laplante 2014-04-10 21:30:45 UTC
Created attachment 97194 [details]
lspci -vnn for me too
Comment 32 Ed Tomlinson 2014-04-10 21:45:54 UTC
Niether patches fixes the issue

disable voltage control - no corruptions, 6.5fps
limit mclk - lots of corruptions (not just the normal one or two) and an almost
 immediate gpu stall/crash
Comment 33 Ed Tomlinson 2014-04-10 21:47:27 UTC
Pressed enter too quickly.  Both patches were tested against linux-git as of about 5pm EDT.
Comment 34 Ed Tomlinson 2014-04-10 21:50:22 UTC
Created attachment 97196 [details]
lspci -vnn (just the graphics card details posted)
Comment 35 Alex Deucher 2014-04-10 22:09:55 UTC
(In reply to comment #32)
> limit mclk - lots of corruptions (not just the normal one or two) and an
> almost
>  immediate gpu stall/crash

Can you try adjusting the mclk value in that patch down?  E.g., change 157500 to:
150000
100000
 80000
 50000
 30000
etc.
Comment 36 Ed Tomlinson 2014-04-10 23:40:50 UTC
I've tried 80000 and 40000 with no luck.  Lots of corruptions and the gpu crashes/stall fairly quickly.  More tomorrow.

Does when the mclk is changed have any importance?  
What about setting it to the max and disabling any other changes?

Thanks
Comment 37 Alex Deucher 2014-04-11 00:59:58 UTC
(In reply to comment #36)
> I've tried 80000 and 40000 with no luck.  Lots of corruptions and the gpu
> crashes/stall fairly quickly.  More tomorrow.
> 
> Does when the mclk is changed have any importance?  
> What about setting it to the max and disabling any other changes?
> 

That is what attachment 96532 [details] [review] did and it didn't work.
Comment 38 Alex Deucher 2014-04-11 03:02:01 UTC
Created attachment 97208 [details] [review]
try newer mc ucode

Try this patch in conjunction with the updated mc firmware here:
http://people.freedesktop.org/~agd5f/BONAIRE_mc.bin
Comment 39 Alex Deucher 2014-04-11 03:11:16 UTC
(In reply to comment #38)
> Created attachment 97208 [details] [review] [review]
> try newer mc ucode
> 
> Try this patch in conjunction with the updated mc firmware here:
> http://people.freedesktop.org/~agd5f/BONAIRE_mc.bin

Make sure the new ucode gets used.  You may have to update your initrd, etc.
Comment 40 Egon Ashrafinia 2014-04-11 07:45:34 UTC
Alex I am using Archlinux and I dont know if my Firmware is allready up to date or not.

When I look up here http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/log/ , the last firmware updates came out in march. And thats exactly the version I have currently installed.

So is the firmware you have postet not released yet? Because I get 2 diffrent MD5SUM between yours and my Firmware binary.

Also,what does "Make sure the new ucode gets used" excatly mean? Could you explain that a bit please? =)

Thank you

Greetings
Comment 41 Egon Ashrafinia 2014-04-11 08:57:39 UTC
Well, I just updated the Firmware (without the patch), rebuild my initram and reactivated dpm and it seems like those flickering and black holes on my display are gone.

I will test it with some opengl applications and yeah. Lets see :)
Comment 42 Egon Ashrafinia 2014-04-11 09:25:51 UTC
It works!!! Hahahaha

I am sorry but I am just happy!

With the new Firmware, all my issues are gone! :D
I did not patch the kernel, I dont know if I should. But anyway the new firmware works perfectly for me. Can you push it upstream pls so the distros can get it?

Thank you Alex!

If you need further help, just contact me! :D
Comment 43 nicolas.laplante 2014-04-11 11:17:32 UTC
Created attachment 97219 [details]
Error in dmesg

There are still errors about switching power profile in dmesg
Comment 44 nicolas.laplante 2014-04-11 11:18:13 UTC
My above comment was made after using the new firmware posted above
Comment 45 Ed Tomlinson 2014-04-11 11:58:25 UTC
Good news.

I rebuilt linux-git with the newer mc ucode patch and manually replaced the BONAIRE_mc.bin firmware file and rebuilt my initrd.

uniengine tropical completes at 33fps (fullscreen 1920x1200)
uniengine sanctuary completes at 45fps (fullscreen 1920x1200)

tropical is the test that usually killed things quickly.  It ran at about 30fps when it worked at all on .14 and about 40fps on .15 with old firmware.  fglrx manages about 80fps.

That being said the new firmware is not as fluid as the older.  There are times that there are hesitations when the camera is panning which I did not notice previously.  However my tests do run without stalling or corruption.

Would you like me to test with and without the patch on .14?

You can add my tested-by to the 'newer mc ucode patch' for linux-git

'Tested-by: Ed Tomlinson <edtoml@gmail.com>'

THANKS!
Comment 46 Ed Tomlinson 2014-04-11 12:15:58 UTC
Tests were run with hyperz disabled as per my comments above.  With hyperz enabled, with the new firmware, I am NOT seeing the gpu faults shown above.  Mesa 10.2 and DDX are from yesterday's git.
Comment 47 Egon Ashrafinia 2014-04-11 22:10:15 UTC
I saw you pushed those fixes upstream, Alex, thats good to see!
But do you also push your new Firmware binarys upstream?

Thats the Main fix.

Thank you for your fixes!

Greetings
Comment 48 Alex Deucher 2014-04-11 22:17:52 UTC
(In reply to comment #47)
> I saw you pushed those fixes upstream, Alex, thats good to see!
> But do you also push your new Firmware binarys upstream?

New binaries are here:
http://people.freedesktop.org/~agd5f/radeon_ucode/

They will make their way into the Linux firmware tree eventually.
Comment 49 Egon Ashrafinia 2014-04-11 22:32:21 UTC
Eventually???

But without the new Firmware, the Bug is Not really fixed is it?

We need the new Firmware to run smooth.
Comment 50 Ed Tomlinson 2014-04-13 05:07:05 UTC
Egon I would say this bug is dead.  Its not smooth here but that could easily be the new kernel - its not reached rc1 yet...  IMHO IF there is too much jitter we  should open a new bug.
Comment 51 nucrap 2014-04-13 13:03:30 UTC
(In reply to comment #50)
> Egon I would say this bug is dead.  Its not smooth here but that could
> easily be the new kernel - its not reached rc1 yet...  IMHO IF there is too
> much jitter we  should open a new bug.

What do you mean, I thought the bug is fixed now, and the fix will be included in future releases..

> Eventually???
"Eventually" means that it *will* reach the kernel firmware. Since you are probalby German (Egon is a German name), you might have misunderstood it for "maybe". "Eventually" has got a completely different meaning in English, see http://www.dict.cc/?s=eventually
Comment 52 Ed Tomlinson 2014-04-14 00:32:02 UTC
Another data point for everyone.  The uniengine tropical benchmark completes at 41fps (20% faster), without problems, using the 1.15.99.902 X (1.66-rc2) build with the new firmware, kernel 3.15-rc1 + patch, and three fixes from: https://bugs.freedesktop.org/show_bug.cgi?id=64297 with llvm 3.4 & mesa-git.
Comment 53 nucrap 2014-05-08 16:23:46 UTC
So in what kernel/-firmware release will it be included?
Comment 54 Alex Deucher 2014-05-08 16:25:34 UTC
(In reply to comment #53)
> So in what kernel/-firmware release will it be included?

3.15
Comment 55 nicolas.laplante 2014-05-14 11:30:54 UTC
Regression on 3.14.3. Screen corruption is back. Using Radeon microcode from 2014-04-30.

dmesg is full of messages like this:

[  658.696174] radeon 0000:01:00.0: GPU fault detected: 147 0x0ee20808
[  658.696175] radeon 0000:01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x00000000
[  658.696177] radeon 0000:01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000
[  658.696178] VM fault (0x00, vmid 0) at page 0, read from '' (0x00000000) (0)
Comment 56 Alexander Tsoy 2014-05-14 11:52:35 UTC
(In reply to comment #55)

Without commit [1] new microcode (BONAIRE_mc2.bin) is not loaded. This commit is currently included only in >=3.15-rc2

[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=277babc374f6ecab6af182554f5d9f35a7768755
Comment 57 nicolas.laplante 2014-05-14 21:36:03 UTC
Ok, tried 3.15_rc5 and I get no corruption. But, booting took a long time (calibrating clocksource TSC) and I got this message:

radeon 0000:01:00.0: Direct firmware load failed with error -2

Here's the dmesg | grep drm:

[    0.703606] [drm] Initialized drm 1.1.0 20060810
[    0.703728] [drm] radeon kernel modesetting enabled.
[    0.704231] [drm] initializing kernel modesetting (BONAIRE 0x1002:0x6658 0x174B:0xE253).
[    0.704390] [drm] register mmio base: 0xFE9C0000
[    0.704477] [drm] register mmio size: 262144
[    0.704565] [drm] doorbell mmio base: 0xCF800000
[    0.704649] [drm] doorbell mmio size: 8388608
[    0.707062] [drm] Detected VRAM RAM=2048M, BAR=256M
[    0.707148] [drm] RAM width 128bits DDR
[    0.707658] [drm] radeon: 2048M of VRAM memory ready
[    0.707744] [drm] radeon: 1024M of GTT memory ready.
[    0.707846] [drm] Loading BONAIRE Microcode
[   60.691462] [drm] radeon/BONAIRE_mc.bin: 31464 bytes
[   60.691551] [drm] Internal thermal controller with fan control
[   60.691679] [drm] probing gen 2 caps for device 1002:5978 = 300d02/0
[   60.699424] [drm] radeon: dpm initialized
[  120.799122] [drm] GART: num cpu pages 262144, num gpu pages 262144
[  120.801322] [drm] probing gen 2 caps for device 1002:5978 = 300d02/0
[  120.801413] [drm] PCIE gen 2 link speeds already enabled
[  120.810251] [drm] PCIE GART of 1024M enabled (table at 0x0000000000277000).
[  120.811879] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[  120.811968] [drm] Driver supports precise vblank timestamp query.
[  120.812206] [drm] radeon: irq initialized.
[  120.814520] [drm] ring test on 0 succeeded in 3 usecs
[  120.814689] [drm] ring test on 1 succeeded in 3 usecs
[  120.814790] [drm] ring test on 2 succeeded in 3 usecs
[  120.815030] [drm] ring test on 3 succeeded in 2 usecs
[  120.815127] [drm] ring test on 4 succeeded in 2 usecs
[  120.871242] [drm] ring test on 5 succeeded in 2 usecs
[  120.891334] [drm] UVD initialized successfully.
[  120.891718] [drm] ib test on ring 0 succeeded in 0 usecs
[  120.891961] [drm] ib test on ring 1 succeeded in 0 usecs
[  120.892205] [drm] ib test on ring 2 succeeded in 0 usecs
[  120.892467] [drm] ib test on ring 3 succeeded in 0 usecs
[  120.892719] [drm] ib test on ring 4 succeeded in 0 usecs
[  120.913684] [drm] ib test on ring 5 succeeded
[  120.934151] [drm] Radeon Display Connectors
[  120.934232] [drm] Connector 0:
[  120.934318] [drm]   DP-1
[  120.934402] [drm]   HPD2
[  120.934488] [drm]   DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c
[  120.934615] [drm]   Encoders:
[  120.934700] [drm]     DFP1: INTERNAL_UNIPHY2
[  120.934786] [drm] Connector 1:
[  120.934864] [drm]   HDMI-A-1
[  120.934948] [drm]   HPD3
[  120.935033] [drm]   DDC: 0x6550 0x6550 0x6554 0x6554 0x6558 0x6558 0x655c 0x655c
[  120.935152] [drm]   Encoders:
[  120.935230] [drm]     DFP2: INTERNAL_UNIPHY2
[  120.935315] [drm] Connector 2:
[  120.935394] [drm]   DVI-D-1
[  120.935479] [drm]   HPD1
[  120.935563] [drm]   DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568 0x656c 0x656c
[  120.935684] [drm]   Encoders:
[  120.935763] [drm]     DFP3: INTERNAL_UNIPHY1
[  120.935850] [drm] Connector 3:
[  120.935928] [drm]   DVI-I-1
[  120.936006] [drm]   HPD6
[  120.936085] [drm]   DDC: 0x6580 0x6580 0x6584 0x6584 0x6588 0x6588 0x658c 0x658c
[  120.936211] [drm]   Encoders:
[  120.936295] [drm]     DFP4: INTERNAL_UNIPHY
[  120.936381] [drm]     CRT1: INTERNAL_KLDSCP_DAC1
[  120.990787] [drm] fb mappable at 0xD047A000
[  120.990873] [drm] vram apper at 0xD0000000
[  120.990952] [drm] size 7299072
[  120.991037] [drm] fb depth is 24
[  120.991116] [drm]    pitch is 6912
[  120.991261] fbcon: radeondrmfb (fb0) is primary device
[  121.025398] radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device
[  121.026375] [drm] Initialized radeon 2.38.0 20080528 for 0000:01:00.0 on minor
Comment 58 nicolas.laplante 2014-05-14 21:39:37 UTC
Just saw that I'm loading the wrong firmware (_mc, not _mc2). Sorry. I'll try this now.
Comment 59 nicolas.laplante 2014-05-14 21:45:42 UTC
Well, same thing with _mc2.bin, except this line (size changed):

radeon/BONAIRE_mc2.bin: 31792 bytes

I still get the Direct firmware load error and calibrating clocksource TSC takes a long time too. Usually I get this slowdown when the drm firmware cannot be loaded correctly.