| Priority | medium |
|---|---|
| Bug ID | 75992 |
| Assignee | dri-devel@lists.freedesktop.org |
| Summary | Display freezes & corruption with an r7 260x on 3.14-rc6 |
| Severity | major |
| Classification | Unclassified |
| OS | Linux (All) |
| Reporter | edt@aei.ca |
| Hardware | x86-64 (AMD64) |
| Status | NEW |
| Version | unspecified |
| Component | DRM/Radeon |
| Product | DRI |
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.
Created attachment 95523 [details]
simple example of corruption (there can be many more rectangles)
| What | Removed | Added |
|---|---|---|
| Attachment #95523 mime type | text/plain | image/png |
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.
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?
I'm building a rc8 with this applied now. Any advise on what to enable and in what order?
(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.
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.
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.
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.
(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?
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
Created attachment 96532 [details] [review] workaround Does this patch fix the stability and performance issues?
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?
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
Created attachment 96568 [details]
pcie 0000:01:00.0 rom
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>.
Ah, and I also get those rectangles. So it's definately the same bug!
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...
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.
Happens to me too. Only radeon.dpm=0 stabilizes the system.