Bug 40221 - NI / Cayman: Frequent pixmap corruption on >=3.0 kernels
Summary: NI / Cayman: Frequent pixmap corruption on >=3.0 kernels
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: 7.6 (2010.12)
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
: 44382 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-08-19 03:35 UTC by Nicos Gollan
Modified: 2012-01-21 08:45 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
X.org log (35.32 KB, text/plain)
2011-08-19 03:35 UTC, Nicos Gollan
no flags Details
dmesg output (67.69 KB, text/plain)
2011-08-19 03:35 UTC, Nicos Gollan
no flags Details
xrestop output, after the glitches started (14.97 KB, text/plain)
2011-08-19 03:37 UTC, Nicos Gollan
no flags Details
Try to make radeon.vramlimit parameter work again (683 bytes, patch)
2011-08-19 06:21 UTC, Michel Dänzer
no flags Details | Splinter Review
dmesg (kernel 3.0.3, with vramlimit patch) (67.82 KB, text/plain)
2011-08-19 08:01 UTC, Nicos Gollan
no flags Details
Xorg log with a crash in libexa (36.47 KB, text/plain)
2011-08-20 10:44 UTC, Nicos Gollan
no flags Details
possible fix (2.88 KB, patch)
2011-08-22 10:57 UTC, Alex Deucher
no flags Details | Splinter Review
possible fix (3.60 KB, patch)
2011-10-22 07:10 UTC, Alex Deucher
no flags Details | Splinter Review
"new" corruption (17.37 KB, image/png)
2011-10-22 10:19 UTC, Nicos Gollan
no flags Details
possible fix (1.26 KB, patch)
2011-10-24 06:32 UTC, Alex Deucher
no flags Details | Splinter Review
Force full flush (1.08 KB, patch)
2011-10-24 07:47 UTC, Jerome Glisse
no flags Details | Splinter Review
possible fix (2.69 KB, patch)
2011-10-24 08:48 UTC, Alex Deucher
no flags Details | Splinter Review
possible fix (1.82 KB, patch)
2011-10-24 10:01 UTC, Alex Deucher
no flags Details | Splinter Review
Flush read cache with fence (4.14 KB, patch)
2011-10-25 13:16 UTC, Jerome Glisse
no flags Details | Splinter Review

Description Nicos Gollan 2011-08-19 03:35:04 UTC
Created attachment 50369 [details]
X.org log

This is related to Bug #38530, but deserves its own report.

Basically, after some time, pixmaps show extreme corruption. Mostly they will be blank in the lower half, sometimes more will be corrupt, but it is always a "clean cut" with an unaffected upper portion and a completely garbled lower portion. Sometimes, a portion of an affected pixmap shows uninitialised or old content. This always happens after some time of normal use, and running applications deteriorate over time.

I have also brought it up on the KDE BTS since it mostly affected KDE applications, but right now the first thing to go was something in Firefox. https://bugs.kde.org/show_bug.cgi?id=279855

This happens on all kernels that support blitting on Evergreen hardware. Manually reverting the commit which introduced that functionality "fixes" things, but introduces the freezes from the old bug.

The hardware is very likely fine, since it does not show any corruption under Windows even when running graphically complex games for extended periods of time.

For screenshots illustrating the corruption visit the linked bug reports.

From the logs:

Xorg.0.log shows:
> (II) RADEON(0): VRAM usage limit set to 219499K

but dmesg shows:
> radeon 0000:05:00.0: VRAM: 2048M 0x0000000000000000 - 0x000000007FFFFFFF (2048M used)
> radeon 0000:05:00.0: GTT: 512M 0x0000000080000000 - 0x000000009FFFFFFF
> [drm] Detected VRAM RAM=2048M, BAR=256M
> [drm] RAM width 256bits DDR
> [TTM] Zone  kernel: Available graphics memory: 8235644 kiB.
> [TTM] Zone   dma32: Available graphics memory: 2097152 kiB.
> [TTM] Initializing pool allocator.
> [drm] radeon: 2048M of VRAM memory ready
> [drm] radeon: 512M of GTT memory ready.
Comment 1 Nicos Gollan 2011-08-19 03:35:51 UTC
Created attachment 50370 [details]
dmesg output
Comment 2 Nicos Gollan 2011-08-19 03:37:02 UTC
Created attachment 50371 [details]
xrestop output, after the glitches started
Comment 3 Michel Dänzer 2011-08-19 06:21:54 UTC
Created attachment 50375 [details] [review]
Try to make radeon.vramlimit parameter work again

Can you try applying this kernel patch and booting with radeon.vramlimit=256, and see if that helps? Please attach the resulting dmesg either way.
Comment 4 Alex Deucher 2011-08-19 06:31:29 UTC
Looks like a dupe of 38539.
Comment 5 Michel Dänzer 2011-08-19 06:37:40 UTC
(In reply to comment #4)
> Looks like a dupe of 38539.

Or you could say that one was fixed by the change which introduced this one?
Comment 6 Nicos Gollan 2011-08-19 06:40:51 UTC
(In reply to comment #4)
> Looks like a dupe of 38539.

That was the one I actually wanted to reference in the very first line, but the typo ate it.

Bug #38539 was started because of the pre-3.0 freezes, which were replaced by post-3.0 corruption.
Comment 7 Nicos Gollan 2011-08-19 08:01:13 UTC
Created attachment 50378 [details]
dmesg (kernel 3.0.3, with vramlimit patch)

No, that does not help :-/ It anything, it just happened sooner.
Comment 8 Michel Dänzer 2011-08-19 08:53:13 UTC
(In reply to comment #7)
> No, that does not help :-/ It anything, it just happened sooner.

Bummer.

On the bright side, this confirms the patch makes the vramlimit parameter actually work, and rules out the problem being related to not all of VRAM being mappable by the CPU but further indicates it's generally related to BO migration out of / into VRAM.
Comment 9 Alex Deucher 2011-08-19 08:56:05 UTC
Might be some state that the 3D driver is setting that's not getting reset properly in the drm blit code when it uses the 3D engine.
Comment 10 Nicos Gollan 2011-08-20 10:44:23 UTC
Created attachment 50404 [details]
Xorg log with a crash in libexa

Could this crash be related somehow? I've been getting them every now and then, even before switching to the new graphics card, and they always occured after being away from the system for a longer time (never seen one "live"). I originally wanted to somehow get better debug info, but the X server isn't really helpful there.
Comment 11 Michel Dänzer 2011-08-22 03:39:29 UTC
(In reply to comment #10)
> Could this crash be related somehow?

Possibly... does it also happen with VRAM limited to 256M?

I suspect the fundamental issue for the crashes might be resource leaks in kwin or other clients.
Comment 12 Nicos Gollan 2011-08-22 04:26:46 UTC
(In reply to comment #11)
> Possibly... does it also happen with VRAM limited to 256M?

So far, I've only seen it happen without blitting support; that's all I can say, since the only way I've found to "provoke" that crash is to leave the system unattended for over an hour, and even then it doesn't happen all the time. My dealings with blitting enabled have so far been restricted to checking if the corruption occurs, so the system rarely ran long enough.

One thing I've found is that after being away for some time, when the server doesn't crash, the freezes from Bug #38539 seem to be a lot worse, almost like every graphical change had to be "swapped in". After some time and letting all applications draw, things speed up again.

> I suspect the fundamental issue for the crashes might be resource leaks in kwin
> or other clients.

Any halfway sane means to check that? Is there a way to trace pixmap (de)allocations?
Comment 13 Michel Dänzer 2011-08-22 05:58:17 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > Possibly... does it also happen with VRAM limited to 256M?
> 
> So far, I've only seen it happen without blitting support; [...]

Then I think it's just yet another side effect of not having blit support. With blit support disabled, make sure VRAM is limited to 256M (the BAR size), as the CPU can't access beyond that directly.
Comment 14 Nicos Gollan 2011-08-22 08:12:34 UTC
(In reply to comment #13)
> Then I think it's just yet another side effect of not having blit support. With
> blit support disabled, make sure VRAM is limited to 256M (the BAR size), as the
> CPU can't access beyond that directly.

No matter the kernel side, the X side of the Radeon driver always says "VRAM usage limit set to 219499K"; wouldn't that indicate that the X server doesn't attempt to use memory beyond that anyway?

So my options right now pretty much boil down to hack blitting out of any new kernel that comes along, add the VRAM limit patch, and hope for the best.
Comment 15 Michel Dänzer 2011-08-22 10:00:43 UTC
(In reply to comment #14)
> No matter the kernel side, the X side of the Radeon driver always says "VRAM
> usage limit set to 219499K"; wouldn't that indicate that the X server doesn't
> attempt to use memory beyond that anyway?

No, it just means the X driver won't submit GPU command streams that could require more than that amount of VRAM at a time. The kernel memory manager will still use all the VRAM it can get.
Comment 16 Alex Deucher 2011-08-22 10:57:31 UTC
Created attachment 50461 [details] [review]
possible fix

Most likely, the fix is to find out what state registers the 3D driver is emitting that are not getting properly re-emitted in the drm blit code.  The attached patch may help.  If not, basically compare the registers emitted in cayman_default_state[] in cayman_blit_shaders.c in the drm with the cayman_context_reg_list[] in evergreen_hw_context.c in mesa and see what's different.
Comment 17 Nicos Gollan 2011-08-24 12:33:56 UTC
(In reply to comment #16)
> Created an attachment (id=50461) [details]
> possible fix

That does not seem to help. I tested it on a 3.0.3 kernel.
Comment 18 Harald Judt 2011-08-25 01:00:19 UTC
I have the same problem (see bug #38022), and confirm that the possible fix doesn't help (3.1-rc3).

> Most likely, the fix is to find out what state registers the 3D driver
> is emitting that are not getting properly re-emitted in the drm blit
> code. If not, basically compare the registers emitted in
> cayman_default_state[] in cayman_blit_shaders.c in the drm with
> the cayman_context_reg_list[] in evergreen_hw_context.c in mesa and
> see what's different.

I don't know if this helps, but here are some comparisons:

1) I took cayman_default_state[] (your possible fix patch not applied) and removed all the lines not having any comments, as I don't know what to do with them.
2) Then I marked lines that also appear in mesa cayman_context_reg_list[] with an 'y'.
3) Lines that appear in cayman_default_state[] but not in mesa cayman_context_reg_list[] are marked with an 'n'.
4) I simply copied all the lines that appear in mesa cayman_context_reg_list[] but not in cayman_default_state[] where I think they would appear.

Again, I don't know how useful this is.

const u32 cayman_default_state[] =
{
y	0x00000060, /* DB_RENDER_CONTROL */
y	0x00000000, /* DB_COUNT_CONTROL */
y	0x00000000, /* DB_DEPTH_VIEW */
y	0x0000002a, /* DB_RENDER_OVERRIDE */
y	0x00000000, /* DB_RENDER_OVERRIDE2 */
y	0x00000000, /* DB_HTILE_DATA_BASE */

y	0x00000000, /* DB_STENCIL_CLEAR */
y	0x00000000, /* DB_DEPTH_CLEAR */

	{R_028030_PA_SC_SCREEN_SCISSOR_TL, 0, 0, 0},
	{R_028034_PA_SC_SCREEN_SCISSOR_BR, 0, 0, 0},

y	0x00000000, /* DB_DEPTH_INFO */
y	0x00000000, /* DB_Z_INFO */
n	0x00000000, /* DB_STENCIL_INFO */

	{R_028048_DB_Z_READ_BASE, REG_FLAG_NEED_BO, 0, 0},

	{R_02804C_DB_STENCIL_READ_BASE, REG_FLAG_NEED_BO, 0, 0},

	{R_028050_DB_Z_WRITE_BASE, REG_FLAG_NEED_BO, 0, 0},

	{R_028054_DB_STENCIL_WRITE_BASE, REG_FLAG_NEED_BO, 0, 0},

	{R_028058_DB_DEPTH_SIZE, 0, 0, 0},
	{R_02805C_DB_DEPTH_SLICE, 0, 0, 0},
	{R_028140_ALU_CONST_BUFFER_SIZE_PS_0, REG_FLAG_DIRTY_ALWAYS, 0, 0},
	{R_028180_ALU_CONST_BUFFER_SIZE_VS_0, REG_FLAG_DIRTY_ALWAYS, 0, 0},

y	0x00000000, /* PA_SC_WINDOW_OFFSET */

	{R_028204_PA_SC_WINDOW_SCISSOR_TL, 0, 0, 0},
	{R_028208_PA_SC_WINDOW_SCISSOR_BR, 0, 0, 0},

y	0x0000ffff, /* PA_SC_CLIPRECT_RULE */
y	0x00000000, /* PA_SC_CLIPRECT_0_TL */
y	0x20002000, /* PA_SC_CLIPRECT_0_BR */

	{R_028218_PA_SC_CLIPRECT_1_TL, 0, 0, 0},
	{R_02821C_PA_SC_CLIPRECT_1_BR, 0, 0, 0},
	{R_028220_PA_SC_CLIPRECT_2_TL, 0, 0, 0},
	{R_028224_PA_SC_CLIPRECT_2_BR, 0, 0, 0},
	{R_028228_PA_SC_CLIPRECT_3_TL, 0, 0, 0},
	{R_02822C_PA_SC_CLIPRECT_3_BR, 0, 0, 0},

y	0xaaaaaaaa, /* PA_SC_EDGERULE */
y	0x00000000, /* PA_SU_HARDWARE_SCREEN_OFFSET */
y	0x0000000f, /* CB_TARGET_MASK */
y	0x0000000f, /* CB_SHADER_MASK */

	{R_028240_PA_SC_GENERIC_SCISSOR_TL, 0, 0, 0},
	{R_028244_PA_SC_GENERIC_SCISSOR_BR, 0, 0, 0},

y	0x80000000, /* PA_SC_VPORT_SCISSOR_0_TL */
y	0x20002000, /* PA_SC_VPORT_SCISSOR_0_BR */
y	0x00000000, /* PA_SC_VPORT_ZMIN_0 */
y	0x3f800000, /* PA_SC_VPORT_ZMAX_0 */

y	0x00000000, /* SX_MISC */

	{R_028380_SQ_VTX_SEMANTIC_0, 0, 0, 0},
	{R_028384_SQ_VTX_SEMANTIC_1, 0, 0, 0},
	{R_028388_SQ_VTX_SEMANTIC_2, 0, 0, 0},
	{R_02838C_SQ_VTX_SEMANTIC_3, 0, 0, 0},
	{R_028390_SQ_VTX_SEMANTIC_4, 0, 0, 0},
	{R_028394_SQ_VTX_SEMANTIC_5, 0, 0, 0},
	{R_028398_SQ_VTX_SEMANTIC_6, 0, 0, 0},
	{R_02839C_SQ_VTX_SEMANTIC_7, 0, 0, 0},
	{R_0283A0_SQ_VTX_SEMANTIC_8, 0, 0, 0},
	{R_0283A4_SQ_VTX_SEMANTIC_9, 0, 0, 0},
	{R_0283A8_SQ_VTX_SEMANTIC_10, 0, 0, 0},
	{R_0283AC_SQ_VTX_SEMANTIC_11, 0, 0, 0},
	{R_0283B0_SQ_VTX_SEMANTIC_12, 0, 0, 0},
	{R_0283B4_SQ_VTX_SEMANTIC_13, 0, 0, 0},
	{R_0283B8_SQ_VTX_SEMANTIC_14, 0, 0, 0},
	{R_0283BC_SQ_VTX_SEMANTIC_15, 0, 0, 0},
	{R_0283C0_SQ_VTX_SEMANTIC_16, 0, 0, 0},
	{R_0283C4_SQ_VTX_SEMANTIC_17, 0, 0, 0},
	{R_0283C8_SQ_VTX_SEMANTIC_18, 0, 0, 0},
	{R_0283CC_SQ_VTX_SEMANTIC_19, 0, 0, 0},
	{R_0283D0_SQ_VTX_SEMANTIC_20, 0, 0, 0},
	{R_0283D4_SQ_VTX_SEMANTIC_21, 0, 0, 0},
	{R_0283D8_SQ_VTX_SEMANTIC_22, 0, 0, 0},
	{R_0283DC_SQ_VTX_SEMANTIC_23, 0, 0, 0},
	{R_0283E0_SQ_VTX_SEMANTIC_24, 0, 0, 0},
	{R_0283E4_SQ_VTX_SEMANTIC_25, 0, 0, 0},
	{R_0283E8_SQ_VTX_SEMANTIC_26, 0, 0, 0},
	{R_0283EC_SQ_VTX_SEMANTIC_27, 0, 0, 0},
	{R_0283F0_SQ_VTX_SEMANTIC_28, 0, 0, 0},
	{R_0283F4_SQ_VTX_SEMANTIC_29, 0, 0, 0},
	{R_0283F8_SQ_VTX_SEMANTIC_30, 0, 0, 0},
	{R_0283FC_SQ_VTX_SEMANTIC_31, 0, 0, 0},

n	0x00000000, /* CP_RINGID */
n	0x00000000, /* CP_VMID */

y	0x00ffffff, /* VGT_MAX_VTX_INDX */
y	0x00000000, /* VGT_MIN_VTX_INDX */
y	0x00000000, /* VGT_INDX_OFFSET */
y	0x00000000, /* VGT_MULTI_PRIM_IB_RESET_INDX */

	{R_028A94_VGT_MULTI_PRIM_IB_RESET_EN, 0, 0, 0},

y	0x00000000, /* SX_ALPHA_TEST_CONTROL */
y	0x00000000, /* CB_BLEND_RED */
y	0x00000000, /* CB_BLEND_GREEN */
y	0x00000000, /* CB_BLEND_BLUE */
y	0x00000000, /* CB_BLEND_ALPHA */

	{R_028430_DB_STENCILREFMASK, 0, 0, 0},
	{R_028434_DB_STENCILREFMASK_BF, 0, 0, 0},
	{R_028438_SX_ALPHA_REF, 0, 0, 0},
	{R_02843C_PA_CL_VPORT_XSCALE_0, 0, 0, 0},
	{R_028440_PA_CL_VPORT_XOFFSET_0, 0, 0, 0},
	{R_028444_PA_CL_VPORT_YSCALE_0, 0, 0, 0},
	{R_028448_PA_CL_VPORT_YOFFSET_0, 0, 0, 0},
	{R_02844C_PA_CL_VPORT_ZSCALE_0, 0, 0, 0},
	{R_028450_PA_CL_VPORT_ZOFFSET_0, 0, 0, 0},
	{R_0285BC_PA_CL_UCP0_X, 0, 0, 0},
	{R_0285C0_PA_CL_UCP0_Y, 0, 0, 0},
	{R_0285C4_PA_CL_UCP0_Z, 0, 0, 0},
	{R_0285C8_PA_CL_UCP0_W, 0, 0, 0},
	{R_0285CC_PA_CL_UCP1_X, 0, 0, 0},
	{R_0285D0_PA_CL_UCP1_Y, 0, 0, 0},
	{R_0285D4_PA_CL_UCP1_Z, 0, 0, 0},
	{R_0285D8_PA_CL_UCP1_W, 0, 0, 0},
	{R_0285DC_PA_CL_UCP2_X, 0, 0, 0},
	{R_0285E0_PA_CL_UCP2_Y, 0, 0, 0},
	{R_0285E4_PA_CL_UCP2_Z, 0, 0, 0},
	{R_0285E8_PA_CL_UCP2_W, 0, 0, 0},
	{R_0285EC_PA_CL_UCP3_X, 0, 0, 0},
	{R_0285F0_PA_CL_UCP3_Y, 0, 0, 0},
	{R_0285F4_PA_CL_UCP3_Z, 0, 0, 0},
	{R_0285F8_PA_CL_UCP3_W, 0, 0, 0},
	{R_0285FC_PA_CL_UCP4_X, 0, 0, 0},
	{R_028600_PA_CL_UCP4_Y, 0, 0, 0},
	{R_028604_PA_CL_UCP4_Z, 0, 0, 0},
	{R_028608_PA_CL_UCP4_W, 0, 0, 0},
	{R_02860C_PA_CL_UCP5_X, 0, 0, 0},
	{R_028610_PA_CL_UCP5_Y, 0, 0, 0},
	{R_028614_PA_CL_UCP5_Z, 0, 0, 0},
	{R_028618_PA_CL_UCP5_W, 0, 0, 0},

y	0x00000100, /* SPI_VS_OUT_ID_0 */

	{R_028438_SX_ALPHA_REF, 0, 0, 0},
	{R_02843C_PA_CL_VPORT_XSCALE_0, 0, 0, 0},
	{R_028440_PA_CL_VPORT_XOFFSET_0, 0, 0, 0},
	{R_028444_PA_CL_VPORT_YSCALE_0, 0, 0, 0},
	{R_028448_PA_CL_VPORT_YOFFSET_0, 0, 0, 0},
	{R_02844C_PA_CL_VPORT_ZSCALE_0, 0, 0, 0},
	{R_028450_PA_CL_VPORT_ZOFFSET_0, 0, 0, 0},
	{R_0285BC_PA_CL_UCP0_X, 0, 0, 0},
	{R_0285C0_PA_CL_UCP0_Y, 0, 0, 0},
	{R_0285C4_PA_CL_UCP0_Z, 0, 0, 0},
	{R_0285C8_PA_CL_UCP0_W, 0, 0, 0},
	{R_0285CC_PA_CL_UCP1_X, 0, 0, 0},
	{R_0285D0_PA_CL_UCP1_Y, 0, 0, 0},
	{R_0285D4_PA_CL_UCP1_Z, 0, 0, 0},
	{R_0285D8_PA_CL_UCP1_W, 0, 0, 0},
	{R_0285DC_PA_CL_UCP2_X, 0, 0, 0},
	{R_0285E0_PA_CL_UCP2_Y, 0, 0, 0},
	{R_0285E4_PA_CL_UCP2_Z, 0, 0, 0},
	{R_0285E8_PA_CL_UCP2_W, 0, 0, 0},
	{R_0285EC_PA_CL_UCP3_X, 0, 0, 0},
	{R_0285F0_PA_CL_UCP3_Y, 0, 0, 0},
	{R_0285F4_PA_CL_UCP3_Z, 0, 0, 0},
	{R_0285F8_PA_CL_UCP3_W, 0, 0, 0},
	{R_0285FC_PA_CL_UCP4_X, 0, 0, 0},
	{R_028600_PA_CL_UCP4_Y, 0, 0, 0},
	{R_028604_PA_CL_UCP4_Z, 0, 0, 0},
	{R_028608_PA_CL_UCP4_W, 0, 0, 0},
	{R_02860C_PA_CL_UCP5_X, 0, 0, 0},
	{R_028610_PA_CL_UCP5_Y, 0, 0, 0},
	{R_028614_PA_CL_UCP5_Z, 0, 0, 0},
	{R_028618_PA_CL_UCP5_W, 0, 0, 0},
	{R_028620_SPI_VS_OUT_ID_1, 0, 0, 0},
	{R_028624_SPI_VS_OUT_ID_2, 0, 0, 0},
	{R_028628_SPI_VS_OUT_ID_3, 0, 0, 0},
	{R_02862C_SPI_VS_OUT_ID_4, 0, 0, 0},
	{R_028630_SPI_VS_OUT_ID_5, 0, 0, 0},
	{R_028634_SPI_VS_OUT_ID_6, 0, 0, 0},
	{R_028638_SPI_VS_OUT_ID_7, 0, 0, 0},
	{R_02863C_SPI_VS_OUT_ID_8, 0, 0, 0},
	{R_028640_SPI_VS_OUT_ID_9, 0, 0, 0},

y	0x00000100, /* SPI_PS_INPUT_CNTL_0 */
y	0x00000101, /* SPI_PS_INPUT_CNTL_1 */

	{R_02864C_SPI_PS_INPUT_CNTL_2, 0, 0, 0},
	{R_028650_SPI_PS_INPUT_CNTL_3, 0, 0, 0},
	{R_028654_SPI_PS_INPUT_CNTL_4, 0, 0, 0},
	{R_028658_SPI_PS_INPUT_CNTL_5, 0, 0, 0},
	{R_02865C_SPI_PS_INPUT_CNTL_6, 0, 0, 0},
	{R_028660_SPI_PS_INPUT_CNTL_7, 0, 0, 0},
	{R_028664_SPI_PS_INPUT_CNTL_8, 0, 0, 0},
	{R_028668_SPI_PS_INPUT_CNTL_9, 0, 0, 0},
	{R_02866C_SPI_PS_INPUT_CNTL_10, 0, 0, 0},
	{R_028670_SPI_PS_INPUT_CNTL_11, 0, 0, 0},
	{R_028674_SPI_PS_INPUT_CNTL_12, 0, 0, 0},
	{R_028678_SPI_PS_INPUT_CNTL_13, 0, 0, 0},
	{R_02867C_SPI_PS_INPUT_CNTL_14, 0, 0, 0},
	{R_028680_SPI_PS_INPUT_CNTL_15, 0, 0, 0},
	{R_028684_SPI_PS_INPUT_CNTL_16, 0, 0, 0},
	{R_028688_SPI_PS_INPUT_CNTL_17, 0, 0, 0},
	{R_02868C_SPI_PS_INPUT_CNTL_18, 0, 0, 0},
	{R_028690_SPI_PS_INPUT_CNTL_19, 0, 0, 0},
	{R_028694_SPI_PS_INPUT_CNTL_20, 0, 0, 0},
	{R_028698_SPI_PS_INPUT_CNTL_21, 0, 0, 0},
	{R_02869C_SPI_PS_INPUT_CNTL_22, 0, 0, 0},
	{R_0286A0_SPI_PS_INPUT_CNTL_23, 0, 0, 0},
	{R_0286A4_SPI_PS_INPUT_CNTL_24, 0, 0, 0},
	{R_0286A8_SPI_PS_INPUT_CNTL_25, 0, 0, 0},
	{R_0286AC_SPI_PS_INPUT_CNTL_26, 0, 0, 0},
	{R_0286B0_SPI_PS_INPUT_CNTL_27, 0, 0, 0},
	{R_0286B4_SPI_PS_INPUT_CNTL_28, 0, 0, 0},
	{R_0286B8_SPI_PS_INPUT_CNTL_29, 0, 0, 0},
	{R_0286BC_SPI_PS_INPUT_CNTL_30, 0, 0, 0},
	{R_0286C0_SPI_PS_INPUT_CNTL_31, 0, 0, 0},

y	0x00000000, /* SPI_VS_OUT_CONFIG */

	{R_0286C8_SPI_THREAD_GROUPING, 0, 0, 0},

y	0x20000001, /* SPI_PS_IN_CONTROL_0 */
y	0x00000000, /* SPI_PS_IN_CONTROL_1 */
y	0x00000000, /* SPI_INTERP_CONTROL_0 */
y	0x00000000, /* SPI_INPUT_Z */
y	0x00000000, /* SPI_FOG_CNTL */
y	0x00100000, /* SPI_BARYC_CNTL */
y	0x00000000, /* SPI_PS_IN_CONTROL_2 */
y	0x00000000, /* SPI_COMPUTE_INPUT_CNTL */
n	0x00000000, /* SPI_COMPUTE_NUM_THREAD_X */
n	0x00000000, /* SPI_COMPUTE_NUM_THREAD_Y */
n	0x00000000, /* SPI_COMPUTE_NUM_THREAD_Z */
n	0x00000000, /* SPI_GPR_MGMT */
n	0x00000000, /* SPI_LDS_MGMT */
n	0x00000000, /* SPI_STACK_MGMT */
n	0x00000000, /* SPI_WAVE_MGMT_1 */
n	0x00000000, /* SPI_WAVE_MGMT_2 */

y	0x00000000, /* CB_BLEND0_CONTROL */

	{R_028784_CB_BLEND1_CONTROL, 0, 0, 0},
	{R_028788_CB_BLEND2_CONTROL, 0, 0, 0},
	{R_02878C_CB_BLEND3_CONTROL, 0, 0, 0},
	{R_028790_CB_BLEND4_CONTROL, 0, 0, 0},
	{R_028794_CB_BLEND5_CONTROL, 0, 0, 0},
	{R_028798_CB_BLEND6_CONTROL, 0, 0, 0},
	{R_02879C_CB_BLEND7_CONTROL, 0, 0, 0},

y	0x00000000, /* DB_DEPTH_CONTROL */
y	0x00000000, /* DB_EQAA */
y	0x00cc0010, /* CB_COLOR_CONTROL */
y	0x00000210, /* DB_SHADER_CONTROL */
y	0x00010000, /* PA_CL_CLIP_CNTL */
y	0x00000004, /* PA_SU_SC_MODE_CNTL */
y	0x00000100, /* PA_CL_VTE_CNTL */
y	0x00000000, /* PA_CL_VS_OUT_CNTL */
y	0x00000000, /* PA_CL_NANINF_CNTL */

n	0x00000000, /* PA_SU_LINE_STIPPLE_CNTL */
n	0x00000000, /* PA_SU_LINE_STIPPLE_SCALE */
n	0x00000000, /* PA_SU_PRIM_FILTER_CNTL */

	{R_028838_SQ_DYN_GPR_RESOURCE_LIMIT_1, 0, 0, 0},
	{R_028840_SQ_PGM_START_PS, REG_FLAG_NEED_BO, S_0085F0_SH_ACTION_ENA(1), 0xFFFFFFFF},
	{R_028844_SQ_PGM_RESOURCES_PS, 0, 0, 0},
	{R_028848_SQ_PGM_RESOURCES_2_PS, 0, 0, 0},
	{R_02884C_SQ_PGM_EXPORTS_PS, 0, 0, 0},
	{R_02885C_SQ_PGM_START_VS, REG_FLAG_NEED_BO, S_0085F0_SH_ACTION_ENA(1), 0xFFFFFFFF},
	{R_028860_SQ_PGM_RESOURCES_VS, 0, 0, 0},
	{R_028864_SQ_PGM_RESOURCES_2_VS, 0, 0, 0},

y	0x00000000, /* SQ_PGM_START_FS */

	{R_0288A8_SQ_PGM_RESOURCES_FS, 0, 0, 0},

y	0x00000000, /* SQ_LDS_ALLOC_PS */

y	0x00000000, /* SQ_ESGS_RING_ITEMSIZE */

	{R_028904_SQ_GSVS_RING_ITEMSIZE, 0, 0, 0},
	{R_028908_SQ_ESTMP_RING_ITEMSIZE, 0, 0, 0},
	{R_02890C_SQ_GSTMP_RING_ITEMSIZE, 0, 0, 0},
	{R_028910_SQ_VSTMP_RING_ITEMSIZE, 0, 0, 0},
	{R_028914_SQ_PSTMP_RING_ITEMSIZE, 0, 0, 0},

y	0x00000000, /* SQ_GS_VERT_ITEMSIZE */

	{R_028920_SQ_GS_VERT_ITEMSIZE_1, 0, 0, 0},
	{R_028924_SQ_GS_VERT_ITEMSIZE_2, 0, 0, 0},
	{R_028928_SQ_GS_VERT_ITEMSIZE_3, 0, 0, 0},
	{R_028940_ALU_CONST_CACHE_PS_0, REG_FLAG_NEED_BO, S_0085F0_SH_ACTION_ENA(1), 0xFFFFFFFF},
	{R_028980_ALU_CONST_CACHE_VS_0, REG_FLAG_NEED_BO, S_0085F0_SH_ACTION_ENA(1), 0xFFFFFFFF},

y	0x00000000, /* PA_SU_POINT_SIZE */
y	0x00000000, /* PA_SU_POINT_MINMAX */
y	0x00000008, /* PA_SU_LINE_CNTL */
n	0x00000000, /* PA_SC_LINE_STIPPLE */
y	0x00000000, /* VGT_OUTPUT_PATH_CNTL */
y	0x00000000, /* VGT_HOS_CNTL */

	{R_028A18_VGT_HOS_MAX_TESS_LEVEL, 0, 0, 0},
	{R_028A1C_VGT_HOS_MIN_TESS_LEVEL, 0, 0, 0},
	{R_028A20_VGT_HOS_REUSE_DEPTH, 0, 0, 0},
	{R_028A24_VGT_GROUP_PRIM_TYPE, 0, 0, 0},
	{R_028A28_VGT_GROUP_FIRST_DECR, 0, 0, 0},
	{R_028A2C_VGT_GROUP_DECR, 0, 0, 0},
	{R_028A30_VGT_GROUP_VECT_0_CNTL, 0, 0, 0},
	{R_028A34_VGT_GROUP_VECT_1_CNTL, 0, 0, 0},
	{R_028A38_VGT_GROUP_VECT_0_FMT_CNTL, 0, 0, 0},
	{R_028A3C_VGT_GROUP_VECT_1_FMT_CNTL, 0, 0, 0},

y	0x00000000, /* VGT_GS_MODE */
y	0x00000000, /* PA_SC_MODE_CNTL_0 */
y	0x00000000, /* PA_SC_MODE_CNTL_1 */
n	0x00000000, /* VGT_PRIMITIVEID_EN */
n	0x00000000, /* VGT_MULTI_PRIM_IB_RESET_EN */
n	0x00000000, /* VGT_INSTANCE_STEP_RATE_0 */
y	0x00000000, /* VGT_REUSE_OFF */

	{R_028ABC_DB_HTILE_SURFACE, 0, 0, 0},
	{R_028AC0_DB_SRESULTS_COMPARE_STATE0, 0, 0, 0},
	{R_028AC4_DB_SRESULTS_COMPARE_STATE1, 0, 0, 0},
	{R_028AC8_DB_PRELOAD_CONTROL, 0, 0, 0},

y	0x00000000, /* VGT_SHADER_STAGES_EN */
y	0x0000aa00, /* DB_ALPHA_TO_MASK */
y	0x00000000, /* PA_SU_POLY_OFFSET_DB_FMT_CNTL */

	{R_028B7C_PA_SU_POLY_OFFSET_CLAMP, 0, 0, 0},
	{R_028B80_PA_SU_POLY_OFFSET_FRONT_SCALE, 0, 0, 0},
	{R_028B84_PA_SU_POLY_OFFSET_FRONT_OFFSET, 0, 0, 0},
	{R_028B88_PA_SU_POLY_OFFSET_BACK_SCALE, 0, 0, 0},
	{R_028B8C_PA_SU_POLY_OFFSET_BACK_OFFSET, 0, 0, 0},

y	0x00000000, /* VGT_STRMOUT_CONFIG */

	{R_028B98_VGT_STRMOUT_BUFFER_CONFIG, 0, 0, 0},

y	0x76543210, /* PA_SC_CENTROID_PRIORITY_0 */
y	0xfedcba98, /* PA_SC_CENTROID_PRIORITY_1 */
y	0x00000000, /* PA_SC_LINE_CNTL */
y	0x00000000, /* PA_SC_AA_CONFIG */
y	0x00000005, /* PA_SU_VTX_CNTL */
y	0x3f800000, /* PA_CL_GB_VERT_CLIP_ADJ */
y	0x3f800000, /* PA_CL_GB_VERT_DISC_ADJ */
y	0x3f800000, /* PA_CL_GB_HORZ_CLIP_ADJ */
y	0x3f800000, /* PA_CL_GB_HORZ_DISC_ADJ */
y	0x00000000, /* PA_SC_AA_SAMPLE_LOCS_PIXEL_X0Y0_0 */
y	0xffffffff, /* PA_SC_AA_MASK_X0Y0_X1Y0 */

	{R_028C60_CB_COLOR0_BASE, REG_FLAG_NEED_BO, 0, 0},
	{R_028C64_CB_COLOR0_PITCH, 0, 0, 0},
	{R_028C68_CB_COLOR0_SLICE, 0, 0, 0},
	{R_028C6C_CB_COLOR0_VIEW, 0, 0, 0},
	{R_028C70_CB_COLOR0_INFO, REG_FLAG_NEED_BO, 0, 0xFFFFFFFF},
	{R_028C74_CB_COLOR0_ATTRIB, REG_FLAG_NEED_BO, 0, 0},
	{R_028C78_CB_COLOR0_DIM, 0, 0, 0},
	{GROUP_FORCE_NEW_BLOCK, 0, 0, 0},
	{R_028C9C_CB_COLOR1_BASE, REG_FLAG_NEED_BO, 0, 0},
	{R_028CA0_CB_COLOR1_PITCH, 0, 0, 0},
	{R_028CA4_CB_COLOR1_SLICE, 0, 0, 0},
	{R_028CA8_CB_COLOR1_VIEW, 0, 0, 0},
	{R_028CAC_CB_COLOR1_INFO, REG_FLAG_NEED_BO, 0, 0xFFFFFFFF},
	{R_028CB0_CB_COLOR1_ATTRIB, REG_FLAG_NEED_BO, 0, 0},
	{R_028CB4_CB_COLOR1_DIM, 0, 0, 0},
	{GROUP_FORCE_NEW_BLOCK, 0, 0, 0},
	{R_028CD8_CB_COLOR2_BASE, REG_FLAG_NEED_BO, 0, 0},
	{R_028CDC_CB_COLOR2_PITCH, 0, 0, 0},
	{R_028CE0_CB_COLOR2_SLICE, 0, 0, 0},
	{R_028CE4_CB_COLOR2_VIEW, 0, 0, 0},
	{R_028CE8_CB_COLOR2_INFO, REG_FLAG_NEED_BO, 0, 0xFFFFFFFF},
	{R_028CEC_CB_COLOR2_ATTRIB, REG_FLAG_NEED_BO, 0, 0},
	{R_028CF0_CB_COLOR2_DIM, 0, 0, 0},
	{GROUP_FORCE_NEW_BLOCK, 0, 0, 0},
	{R_028D14_CB_COLOR3_BASE, REG_FLAG_NEED_BO, 0, 0},
	{R_028D18_CB_COLOR3_PITCH, 0, 0, 0},
	{R_028D1C_CB_COLOR3_SLICE, 0, 0, 0},
	{R_028D20_CB_COLOR3_VIEW, 0, 0, 0},
	{R_028D24_CB_COLOR3_INFO, REG_FLAG_NEED_BO, 0, 0xFFFFFFFF},
	{R_028D28_CB_COLOR3_ATTRIB, REG_FLAG_NEED_BO, 0, 0},
	{R_028D2C_CB_COLOR3_DIM, 0, 0, 0},
	{GROUP_FORCE_NEW_BLOCK, 0, 0, 0},
	{R_028D50_CB_COLOR4_BASE, REG_FLAG_NEED_BO, 0, 0},
	{R_028D54_CB_COLOR4_PITCH, 0, 0, 0},
	{R_028D58_CB_COLOR4_SLICE, 0, 0, 0},
	{R_028D5C_CB_COLOR4_VIEW, 0, 0, 0},
	{R_028D60_CB_COLOR4_INFO, REG_FLAG_NEED_BO, 0, 0xFFFFFFFF},
	{R_028D64_CB_COLOR4_ATTRIB, REG_FLAG_NEED_BO, 0, 0},
	{R_028D68_CB_COLOR4_DIM, 0, 0, 0},
	{GROUP_FORCE_NEW_BLOCK, 0, 0, 0},
	{R_028D8C_CB_COLOR5_BASE, REG_FLAG_NEED_BO, 0, 0},
	{R_028D90_CB_COLOR5_PITCH, 0, 0, 0},
	{R_028D94_CB_COLOR5_SLICE, 0, 0, 0},
	{R_028D98_CB_COLOR5_VIEW, 0, 0, 0},
	{R_028D9C_CB_COLOR5_INFO, REG_FLAG_NEED_BO, 0, 0xFFFFFFFF},
	{R_028DA0_CB_COLOR5_ATTRIB, REG_FLAG_NEED_BO, 0, 0},
	{R_028DA4_CB_COLOR5_DIM, 0, 0, 0},
	{GROUP_FORCE_NEW_BLOCK, 0, 0, 0},
	{R_028DC8_CB_COLOR6_BASE, REG_FLAG_NEED_BO, 0, 0},
	{R_028DCC_CB_COLOR6_PITCH, 0, 0, 0},
	{R_028DD0_CB_COLOR6_SLICE, 0, 0, 0},
	{R_028DD4_CB_COLOR6_VIEW, 0, 0, 0},
	{R_028DD8_CB_COLOR6_INFO, REG_FLAG_NEED_BO, 0, 0xFFFFFFFF},
	{R_028DDC_CB_COLOR6_ATTRIB, REG_FLAG_NEED_BO, 0, 0},
	{R_028DE0_CB_COLOR6_DIM, 0, 0, 0},
	{GROUP_FORCE_NEW_BLOCK, 0, 0, 0},
	{R_028E04_CB_COLOR7_BASE, REG_FLAG_NEED_BO, 0, 0},
	{R_028E08_CB_COLOR7_PITCH, 0, 0, 0},
	{R_028E0C_CB_COLOR7_SLICE, 0, 0, 0},
	{R_028E10_CB_COLOR7_VIEW, 0, 0, 0},
	{R_028E14_CB_COLOR7_INFO, REG_FLAG_NEED_BO, 0, 0xFFFFFFFF},
	{R_028E18_CB_COLOR7_ATTRIB, REG_FLAG_NEED_BO, 0, 0},
	{R_028E1C_CB_COLOR7_DIM, 0, 0, 0},
	{GROUP_FORCE_NEW_BLOCK, 0, 0, 0},
	{R_028E40_CB_COLOR8_BASE, REG_FLAG_NEED_BO, 0, 0},
	{R_028E44_CB_COLOR8_PITCH, 0, 0, 0},
	{R_028E48_CB_COLOR8_SLICE, 0, 0, 0},
	{R_028E4C_CB_COLOR8_VIEW, 0, 0, 0},
	{R_028E50_CB_COLOR8_INFO, REG_FLAG_NEED_BO, 0, 0xFFFFFFFF},
	{R_028E54_CB_COLOR8_ATTRIB, REG_FLAG_NEED_BO, 0, 0},
	{R_028E58_CB_COLOR8_DIM, 0, 0, 0},
	{GROUP_FORCE_NEW_BLOCK, 0, 0, 0},
	{R_028E5C_CB_COLOR9_BASE, REG_FLAG_NEED_BO, 0, 0},
	{R_028E60_CB_COLOR9_PITCH, 0, 0, 0},
	{R_028E64_CB_COLOR9_SLICE, 0, 0, 0},
	{R_028E68_CB_COLOR9_VIEW, 0, 0, 0},
	{R_028E6C_CB_COLOR9_INFO, REG_FLAG_NEED_BO, 0, 0xFFFFFFFF},
	{R_028E70_CB_COLOR9_ATTRIB, REG_FLAG_NEED_BO, 0, 0},
	{R_028E74_CB_COLOR9_DIM, 0, 0, 0},
	{GROUP_FORCE_NEW_BLOCK, 0, 0, 0},
	{R_028E78_CB_COLOR10_BASE, REG_FLAG_NEED_BO, 0, 0},
	{R_028E7C_CB_COLOR10_PITCH, 0, 0, 0},
	{R_028E80_CB_COLOR10_SLICE, 0, 0, 0},
	{R_028E84_CB_COLOR10_VIEW, 0, 0, 0},
	{R_028E88_CB_COLOR10_INFO, REG_FLAG_NEED_BO, 0, 0xFFFFFFFF},
	{R_028E8C_CB_COLOR10_ATTRIB, REG_FLAG_NEED_BO, 0, 0},
	{R_028E90_CB_COLOR10_DIM, 0, 0, 0},
	{GROUP_FORCE_NEW_BLOCK, 0, 0, 0},
	{R_028E94_CB_COLOR11_BASE, REG_FLAG_NEED_BO, 0, 0},
	{R_028E98_CB_COLOR11_PITCH, 0, 0, 0},
	{R_028E9C_CB_COLOR11_SLICE, 0, 0, 0},
	{R_028EA0_CB_COLOR11_VIEW, 0, 0, 0},
	{R_028EA4_CB_COLOR11_INFO, REG_FLAG_NEED_BO, 0, 0xFFFFFFFF},
	{R_028EA8_CB_COLOR11_ATTRIB, REG_FLAG_NEED_BO, 0, 0},
	{R_028EAC_CB_COLOR11_DIM, 0, 0, 0},

n	0x0000000e, /* VGT_VERTEX_REUSE_BLOCK_CNTL */
}
Comment 19 Nicos Gollan 2011-09-03 02:29:08 UTC
Could something that is not covered by the blitting mutex clobber GPU state when called at a bad time?
Comment 20 Nicos Gollan 2011-10-08 03:36:19 UTC
Still an issue with 3.1.0-rc7
Comment 21 Nicos Gollan 2011-10-19 10:02:06 UTC
Since right now every on-screen action I do freezes my system for a few seconds, I might as well post here some more.

*Theory.* the freezes in pre-3.0 and the corruption in post-3.0 are actually the same bug: some in-memory action takes forever to finish. Before 3.0, the driver actually does the _correct_ thing and sits it out. The new clipping code is buggy, ignores whatever state would tell it to wait, and happily "finishes" about halfway through a (purely in-hardware?) copy/move/blit/memory-management operation that is still ongoing, leaving the GPU with a bunch of mostly clear, halfway filled-in, and sometimes corrupt surfaces.

TL;DR: Please fix this, I want to use this system!
Comment 22 Alex Deucher 2011-10-19 10:12:33 UTC
(In reply to comment #21)
> Since right now every on-screen action I do freezes my system for a few
> seconds, I might as well post here some more.
> 
> *Theory.* the freezes in pre-3.0 and the corruption in post-3.0 are actually
> the same bug: some in-memory action takes forever to finish. Before 3.0, the
> driver actually does the _correct_ thing and sits it out.

The delays in pre-3.0 kernels are due to memory pressure and migrating buffers out of vram since pre-3.0 the driver was not able to use the full amount of vram on the card due to the lack of blit support.
Comment 23 Marek Hobler 2011-10-21 07:11:41 UTC
I have feeling that this bug is much more intensive when using 6 monitors than 2 or just single output. 

Is there anything I can do to move this bug forward? (as non-developer) test patches, bisect etc ?

Right now I'm stick to 3.0-rc2 with this ugly freeze...
Comment 24 Alex Deucher 2011-10-22 07:10:48 UTC
Created attachment 52630 [details] [review]
possible fix

The patch moves the TC flush before the texture setup to match mesa and the ddx.  The patch is against Dave's drm-next tree:
http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next
Comment 25 Nicos Gollan 2011-10-22 10:16:18 UTC
(In reply to comment #24)
> Created attachment 52630 [details] [review] [review]
> possible fix
> 
> The patch moves the TC flush before the texture setup to match mesa and the
> ddx.  The patch is against Dave's drm-next tree:
> http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-next

Seems that wasn't it, at least not entirely. Things seem to have changed though, now instead of the entire lower part of surfaces missing, there are transparent horizontal streaks through them.
Comment 26 Nicos Gollan 2011-10-22 10:19:47 UTC
Created attachment 52635 [details]
"new" corruption

While I've only seen completely missing lower parts of surfaces so far, it seems that with the latest patch on top of drm-next, just some regions are missing.
Comment 27 Alex Deucher 2011-10-24 06:32:51 UTC
Created attachment 52690 [details] [review]
possible fix

Does this patch help?  Try it on top of the previous one.
Comment 28 Jerome Glisse 2011-10-24 07:47:45 UTC
Created attachment 52697 [details] [review]
Force full flush

If previous patch doesn't help please apply this one on top of previous one and report. This would only be a possible workaround
Comment 29 Alex Deucher 2011-10-24 08:48:19 UTC
Created attachment 52699 [details] [review]
possible fix

Try this patch on top of attachment 52630 [details] [review].
Comment 30 Alex Deucher 2011-10-24 10:01:19 UTC
Created attachment 52700 [details] [review]
possible fix

Please try this patch on top of attachment 52630 [details] [review].
Comment 31 Harald Judt 2011-10-24 12:10:56 UTC
Applying the following patches seems to have fixed this for me (and so 
duplicate bug 38022).

drm/radeon/kms: add some additional cayman blit state
drm/radeon/kms: rework texture cache flush in r6xx+ blit code
drm/radeon/kms/cayman: explicitly program CP_COHER_CNTL2 in blit code
drm/radeon/kms/cayman: use WAIT_REG_MEM for surface_sync in blit code

However, I can no longer start the game naev; It crashes the system so that the screen freezes on the loading screen and restarting gdm doesn't work. I can still ssh into the system and reboot it. Starting the game worked before, though then there were glyph corruptions in the game. I hope these freezes only appear in this game, though.

I haven't tried Jerome Glisse's 'force full flush' patch.

Thanks for making my system usable again.
Comment 32 Alex Deucher 2011-10-24 12:21:14 UTC
(In reply to comment #31)
> Applying the following patches seems to have fixed this for me (and so 
> duplicate bug 38022).
> 
> drm/radeon/kms: add some additional cayman blit state
> drm/radeon/kms: rework texture cache flush in r6xx+ blit code
> drm/radeon/kms/cayman: explicitly program CP_COHER_CNTL2 in blit code
> drm/radeon/kms/cayman: use WAIT_REG_MEM for surface_sync in blit code
> 
> However, I can no longer start the game naev; It crashes the system so that the
> screen freezes on the loading screen and restarting gdm doesn't work. I can
> still ssh into the system and reboot it. Starting the game worked before,
> though then there were glyph corruptions in the game. I hope these freezes only
> appear in this game, though.

Please try attachment 52700 [details] [review] (drm/radeon/kms/cayman/blit: specify CP_COHER_CNTL2 with surface_sync) instead of attachment 52699 [details] [review] (drm/radeon/kms/cayman: use WAIT_REG_MEM for surface_sync in blit code).
Comment 33 Nicos Gollan 2011-10-24 12:34:11 UTC
I tried:

* drm/radeon/kms/cayman/blit: specify CP_COHER_CNTL2 with surface_sync
* drm/radeon/kms: rework texture cache flush in r6xx+ blit code

which sadly didn't help (if anything, the corruption got more fine-grained). In those builds I didn't have the older patch from attachment 50461 [details] [review] though, I'll try that soon without the workaround.

As an aside, I was running attachment 52699 [details] [review] while building that, and it froze the UI solid. The system was still working fine, just the GPU had stopped cold from the looks of it.

Right now, I'm running Jerome Glisse's workaround over those two, and so far it seems to work well enough for what I need.
Comment 34 Nicos Gollan 2011-10-24 13:06:53 UTC
No go with the "3-pack", the only thing that seems to work so far is the workaround.
Comment 35 Harald Judt 2011-10-25 10:38:42 UTC
@Comment 32: Using "drm/radeon/kms/cayman/blit: specify CP_COHER_CNTL2 with surface_sync" instead of "drm/radeon/kms/cayman: use
WAIT_REG_MEM for surface_sync in blit code" causes the corruptions to return. Lower half of the icons are missing, desktop background image is corrupted.

"drm/radeon/kms/cayman: use WAIT_REG_MEM for surface_sync in blit code" caused freezes like those described by Nicos Gollan.

I am now trying Jerome Glisse's "Force full flush" workaround, and after a quick test: No corruptions of icons or background so far, even naev works without issues. Performance seems ok too.
Comment 36 Nicos Gollan 2011-10-25 10:53:15 UTC
(In reply to comment #35)
> @Comment 32: Using "drm/radeon/kms/cayman/blit: specify CP_COHER_CNTL2 with
> surface_sync" instead of "drm/radeon/kms/cayman: use
> WAIT_REG_MEM for surface_sync in blit code" causes the corruptions to return.
> Lower half of the icons are missing, desktop background image is corrupted.

Are you still seeing complete loss of the lower part? With those patches, I'm definitely getting a different failure mode, more of a "windowblinds" effect. Of course that's mostly visible on larger surfaces where it has (time|space) to occur.
Comment 37 Harald Judt 2011-10-25 11:09:20 UTC
Yes, the lower part of the images were missing or black, while the upper part was still intact. Maybe that is because I also applied other patches from the mailing list, or because I did not stress it long enough so that the upper part became corrupted too.

On my machine, the upper parts never got corrupted, only the lower half of the icons was affected (see screenshots in bug 38022), and some background pixmaps.
Comment 38 Jerome Glisse 2011-10-25 13:16:26 UTC
Created attachment 52762 [details] [review]
Flush read cache with fence

Ok here is a possible fix, please test it without any of the previous patches.
Comment 39 Harald Judt 2011-10-25 16:02:46 UTC
I've reverted the previous patches, and yes, it seems this finally fixes this bug and also bug 38022 and maybe bug 38539, though it does not cure bug 42067, and if my assumptions are right, bug 38173 - these two bugs are about texture compression).
Comment 40 Marek Hobler 2011-10-25 16:22:58 UTC
(In reply to comment #38)
> Ok here is a possible fix, please test it without any of the previous patches.
it work's for me. No corruption.

fixes https://bugzilla.kernel.org/show_bug.cgi?id=38622

thanks!
Comment 41 Nicos Gollan 2011-10-27 13:44:35 UTC
Thank you, thank you, thank you!
Comment 42 Valentyn Pavliuchenko 2011-10-29 03:35:46 UTC
Applying attachment 52762 [details] [review] on 3.1 kernel has fixed the issue for me. Thanks!
Comment 43 Marek Hobler 2011-11-12 07:07:45 UTC
Just want to say that current vanilla tree from Linus ( 3.2.0-rc1 ) without patching works perfectly. Thanks!
Comment 44 Nicos Gollan 2011-11-16 11:08:36 UTC
It really seems like the patch fixed things. Recently, I noticed a corrupt mouse pointer, which was fixed the next time it changed shape, but that only happened once in many hours of use and might well have been a glitch in some other part of the system.

It seems though like rendering has become rather expensive. For example, playing video causes high CPU load, and playing sound in audacity when having the waveform display zoomed in (so it changes a lot) drags down the system distinctly.
Comment 45 Michel Dänzer 2011-12-20 03:49:20 UTC
This problem seems fixed. Other problems would need to be tracked separately.
Comment 46 Alex Deucher 2012-01-02 07:30:38 UTC
*** Bug 44382 has been marked as a duplicate of this bug. ***
Comment 47 Florian Mickler 2012-01-21 08:45:33 UTC
A patch referencing this bug report has been merged in Linux v3.2-rc1:

commit 77b1bad423599c9841ea282a82172f039bb2ff92
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Wed Oct 26 11:41:22 2011 -0400

    drm/radeon: flush read cache for gtt with fence on r6xx and newer GPU V3


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.