https://bugs.freedesktop.org/show_bug.cgi?id=84627

--- Comment #1 from smoki smoki00790@gmail.com --- OK bisected kernel fast, by lucky guessing :) So for the kernel it is:

02376d8282b88f07d0716da6155094c8760b1a13

drm/radeon: Allow write-combined CPU mappings of BOs in GTT (v2) v2: fix rebase onto drm-fixes

https://bugs.freedesktop.org/show_bug.cgi?id=84627

--- Comment #3 from smoki smoki00790@gmail.com --- How to say it is some kind of immidiate and raising corruption everywhere. Appear alredy after i login on 32bit machine, basically nearly everything is corrupted. Fonts, images, games... everything.

https://bugs.freedesktop.org/show_bug.cgi?id=84627

--- Comment #5 from smoki smoki00790@gmail.com --- Created attachment 107401 --> https://bugs.freedesktop.org/attachment.cgi?id=107401&action=edit game corruption

(In reply to smoki from comment #4)

Created attachment 107392 [details] corruption

Ok just builded again with stream reverted, if that screenshot can explain something.

That screenshot does not show icons are also corrupted, maouse cursor also dissapear or it is just a point or some kind of mess on screen, etc... One screenshot from games, i don't know how i get there without visible cursor and fonts, etc :D

https://bugs.freedesktop.org/show_bug.cgi?id=84627

--- Comment #7 from smoki smoki00790@gmail.com --- (In reply to Michel Dänzer from comment #6)

And this goes away if RADEON_FLAG_GTT_WC isn't set in r600_buffer_common.c:r600_init_resource()?

No, that does not help for this corruption. That helps only where games stutter when GTT loads.

https://bugs.freedesktop.org/show_bug.cgi?id=84627

--- Comment #9 from smoki smoki00790@gmail.com --- (In reply to Michel Dänzer from comment #8)

(In reply to smoki from comment #7)

...

No, that does not help for this corruption.

Note that I mean disabling *all* uses of RADEON_FLAG_GTT_WC. With those disabled, the behaviour should be basically the same as before the commit you bisected to. If that really doesn't work anymore, can you bisect which other commit in the meantime broke things without RADEON_FLAG_GTT_WC?

I tried only to disable it in default, and also both RADEON_FLAG_GTT_WC together and also tried your patch form here https://bugs.freedesktop.org/show_bug.cgi?id=84662#c12 ... it return to old behavior, so there is no stutter but there is not anymore performance gain... and corruption is still there.

Don't know which other commit to bisect it does not work at mesa 07c65b85eada8dd34019763b6e82ed4257a9b4a6 and kernel commit 02376d8282b88f07d0716da6155094c8760b1a13 ... even with both RADEON_FLAG_GTT_WC disabled and the same disablement does not work with current stack.

https://bugs.freedesktop.org/show_bug.cgi?id=84627

--- Comment #11 from Michel Dänzer michel@daenzer.net --- Created attachment 107452 --> https://bugs.freedesktop.org/attachment.cgi?id=107452&action=edit mesa: Only use two caching buffer managers again

Hmm, but if it's not the GTT_WC flag which triggers the corruption, I'm not sure what it could be...

Here's a shot in the dark, does this patch work around the problem?

https://bugs.freedesktop.org/show_bug.cgi?id=84627

--- Comment #13 from smoki smoki00790@gmail.com --- Maybe to mention here what i playing a little there yesterday, it is not only PIPE_USAGE_STREAM reverted which triggers problem/corruption on 32bit, for example if i only add res->domains = RADEON_DOMAIN_GTT; to default i can't login anymore:

default: /* Not listing GTT here improves performance in some apps. */ res->domains = RADEON_DOMAIN_VRAM; + res->domains = RADEON_DOMAIN_GTT; flags |= RADEON_FLAG_GTT_WC; break;

On 64bit this is also not a problem, after adding just this performance goes up by 25% in games like Torchlight, Dota2, etc... i only found slight decrease in other apps by up to 1-3% (Xonotic, Openarena, etc) and it also remove stutter for me in Unigine Valley. So this seems to be better default now, but...

Then again that is only because 'flags |= RADEON_FLAG_GTT_WC;' is there so that made a difference to not fps go down much. If commented that (with DOMAIN_GTT there) a see even greater boost by 35%-40% performance go up in Torchlight, but it is not actually so good anymore for other apps (Valley suffer). So that seems like some apps very much like, but some not at all :D

Yeah on 32bit i can't play with those, there are various triggered problems with GTT_WC being there.

https://bugs.freedesktop.org/show_bug.cgi?id=84627

Michel Dänzer michel@daenzer.net changed:

What |Removed |Added ---------------------------------------------------------------------------- Attachment #107452|0 |1 is obsolete| |

--- Comment #15 from Michel Dänzer michel@daenzer.net --- Created attachment 107655 --> https://bugs.freedesktop.org/attachment.cgi?id=107655&action=edit drm/radeon: Ignore RADEON_GEM_GTT_WC on Kabini

There seems to be a general problem with write-combined CPU mappings of GTT on Kabini. We previously disabled write-combined mappings of the ring buffers again because other users reported ring test failures on Kabini with that, but from this report it looks like the problem runs deeper.

This kernel patch should work around it for now.

https://bugs.freedesktop.org/show_bug.cgi?id=84627

--- Comment #17 from smoki smoki00790@gmail.com ---

This thing starts to work (on proper 3.17 kernel) but on multiarched 64bit OS. Don't know what what is issue about on pure 32bit OS? tried with 64bit kernel there too and it was still an issues there, so this might not be radeon bug at all...

Seems to me this will be partly invalid bug Michel, not sure how many people even try to run 32bit OS on Kabini, maybe none :)

https://bugs.freedesktop.org/show_bug.cgi?id=84627

--- Comment #19 from Michel Dänzer michel@daenzer.net --- (In reply to smoki from comment #17)

This thing starts to work (on proper 3.17 kernel) but on multiarched 64bit OS. Don't know what what is issue about on pure 32bit OS? tried with 64bit kernel there too and it was still an issues there, so this might not be radeon bug at all...

Running a 64 bit kernel is by definition not a 'pure 32 bit' OS.

So what exactly is the difference between the working and broken cases? It sounds like you're using a different distro installation in each case. Maybe there's a difference between them which isn't directly related to the graphics stack? E.g. one of them updating the CPU (not GPU!) microcode at boot, but the other one not.

(In reply to smoki from comment #18)

Is it something like - glamor 32bit bug?

Seems unlikely.

https://bugs.freedesktop.org/show_bug.cgi?id=84627

--- Comment #21 from smoki smoki00790@gmail.com --- (In reply to Michel Dänzer from comment #19)

E.g. one of them updating the CPU (not GPU!) microcode at boot, but the other one not.

Nope i tried both with/without updating CPU microcode, tried also distro kernel from experimental that is linux-image-3.17-rc5-686-pae currently... in all cases corruption is still there.

Well to reproduce it someone must install 32bit OS :)

https://bugs.freedesktop.org/show_bug.cgi?id=84627

--- Comment #23 from smoki smoki00790@gmail.com --- (In reply to Michel Dänzer from comment #22)

What I meant is that there's no fundamental difference between doing that and running 32 bit apps in a 64-bit distro installation.

I know, should not be any difference but yeah don't know what happens...

To clarify though, for that test did you install a linux-image-*-amd64_*_i386.deb in the 32-bit install, or did you manually copy the kernel from the 64-bit install? If the former, can you also try the latter to rule out any difference between the *_i386.deb and *_amd64.deb?

I run normaly pae kernel there that is default on pure 32bit for me. Yes i tried that one too: amd64 kernel packaged in i386.deb. Those both and my compiled kernel have corruption.

Tried now what you said pure 64bit kernel packaged as amd64.deb and voila no corruption with it! Both are distro kernels from experimental and my kernels behave the same there, 32bit as i386.deb one give corruptions, 64bit and packaged as amd64.deb works fine. But hmmm, how and why those differ both are 64bit in different package or?

https://bugs.freedesktop.org/show_bug.cgi?id=84627

--- Comment #25 from Michel Dänzer michel@daenzer.net --- I think you should work with the Debian kernel maintainers to isolate what exactly makes the difference between the two kernel packages.

https://bugs.freedesktop.org/show_bug.cgi?id=84627

--- Comment #27 from Hamish Wilson hamish@icculus.org --- Not that I suspect this to surprise anyone, but I felt I should mention that this bug now also appears with Mesa 10.3.3 as well.

https://bugs.freedesktop.org/show_bug.cgi?id=84627

--- Comment #29 from Michel Dänzer michel@daenzer.net --- (In reply to Nils Holland from comment #28)

any more help needed in diagnosing this, and if so, anything I can do to help?

See comment 22. From comment 23, it sounds like it might actually be a 32-bit toolchain issue, which somehow leaks into 64-bit kernel builds as well.

If there's any way you can run a 'real' 64-bit kernel on your distro, that's probably the best way to avoid the problem for now.

https://bugs.freedesktop.org/show_bug.cgi?id=84627

--- Comment #31 from Michel Dänzer michel@daenzer.net --- (In reply to Zbigniew Luszpinski from comment #30)

Just apply only one of these solutions. I prefer to add my GPU to exclusion list "drm/radeon: Ignore RADEON_GEM_GTT_WC on Kabini" patch instead of patching mesa.

While that patch works around the problem, it doesn't make much sense conceptually: Since everything is working fine with 64-bit kernels, there doesn't seem to be anything wrong with any particular GPUs.

Also, disabling write-combining decreases performance.

For those reasons, until someone figures out the root cause of this problem, IMHO the preferred workaround is to run a 64-bit kernel. Any particular reason why you can't do that?

https://bugs.freedesktop.org/show_bug.cgi?id=84627

--- Comment #33 from smoki smoki00790@gmail.com --- (In reply to Michel Dänzer from comment #32)

Is there any difference in the /boot/config-3.* file between the two packages?

As i see only one: amd64.amd64 package has CONFIG_DEBUG_INFO=y while amd64.i386 has CONFIG_DEBUG_INFO is not set ... diff says only this:

< CONFIG_DEBUG_INFO=y < # CONFIG_DEBUG_INFO_REDUCED is not set < # CONFIG_DEBUG_INFO_SPLIT is not set < # CONFIG_DEBUG_INFO_DWARF4 is not set ---

# CONFIG_DEBUG_INFO is not set

But also affected 686-pae has CONFIG_DEBUG_INFO=y too, so i guess that config option is not an issue.

https://bugs.freedesktop.org/show_bug.cgi?id=84627

Michel Dänzer michel@daenzer.net changed:

What |Removed |Added ---------------------------------------------------------------------------- Attachment #110024|0 |1 is obsolete| |

--- Comment #35 from Michel Dänzer michel@daenzer.net --- Created attachment 110118 --> https://bugs.freedesktop.org/attachment.cgi?id=110118&action=edit drm/radeon: Ignore RADEON_GEM_GTT_WC on 32-bit x86

Can one of you confirm that this patch works around the problem for a 32-bit kernel build?

https://bugs.freedesktop.org/show_bug.cgi?id=84627

--- Comment #37 from Nils Holland nholland@tisys.org --- (In reply to Michel Dänzer from comment #35)

Created attachment 110118 [details] [review] drm/radeon: Ignore RADEON_GEM_GTT_WC on 32-bit x86

Can one of you confirm that this patch works around the problem for a 32-bit kernel build?

Yes, just like smoki, I can confirm that with this patch, I can run current Mesa builds just fine on my 32 bit kernel.

https://bugs.freedesktop.org/show_bug.cgi?id=84627

--- Comment #39 from Nils Holland nholland@tisys.org --- (In reply to Igor Gnatenko from comment #38)

Any news? Seems patch works ok for people. can you sned it for 10.3 stable also?

The patch that fixed the issue for us is actually a kernel patch and not a Mesa patch and as such should work regardless of what Mesa version you're using.

Regarding the question on why this issue only seems to affect 32 bit kernels and not 64 bit ones, and if the proposes patch can serve as a permanent fix or is coupled with too many undesirable side-effects ... well, Michel can probably give more qualified information about that.

As it stands, the patch disables write-combining and thus will probably have negative effects on performance, although I don't really notice any difference on my own machine compared to the time "when things worked fine without any patching at all" (but I'm not really running very demanding stuff). Just using a 64 bit kernel instead of going down the patch route should fix the problem without these side-effects.

https://bugs.freedesktop.org/show_bug.cgi?id=84627

--- Comment #41 from Alex Deucher alexdeucher@gmail.com --- Yes: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a0...

https://bugs.freedesktop.org/show_bug.cgi?id=84627

--- Comment #43 from sam zain omar8star@gmail.com --- great work. http://www.winmilliongame.com http://www.gtagame100.com http://www.subway-game.com http://www.zumagame100.com