Comment # 21
on bug 84662
from Alexandre Demers
(In reply to Andy Furniss from comment #18) > (In reply to Andy Furniss from comment #14) > > > With mesa on the commit before > > r600g,radeonsi: Set RADEON_GEM_NO_CPU_ACCESS flag for tiled BOs > > (I don't know yet exactly what mesa commit changed things) > > > > I can with your patch or the stream revert get "good" behavior, this was > > with a kernel on the "bad" HPD kernel commit. > > > > Will test more over time. > > I haven't tried the patch yet. will do but I got some strange results last > thing yesterday which will make me hesitant about declaring any patch good > or bad. > > I started resetting around in mesa and noticed unexpected goods - so I tried > head and got a good noth with and without 1st patch. > > Rebooted into 3.17-rc7 still good. > > Did some recompiling of llvm/mesa as I had changed my normal setup slightly > - got bad. > > Repeated resetting mesa to older + patch got good, reset to head again, bad. > Applied patch on head good, reversed patch on head - still good. > > I am wondering at this time whether card is in some nice state so power > cycle - still good. Boot into 3.18 still good, clean & recompile the same > mesa without doing anything else - bad again. Still bad after power cycles. > > I always make distclean + git clean -dfx when doing anything other than > applying or reversing a patch. > > So it seems that there is some randomness whether I am good or bad between > mesa build/installs. > > This does not however tally with my kernel bisect which seemed to go > flawlessly. > > I assume there is no card state that can survive power off. > > So currently a bit confused - as reported by Christoph in the other bug, it > is possible to have good with vanilla mesa/kernel, but apparently for me the > "same" mesa can also be bad. > > I did try more clean/rebuild cycles including single thread but am currently > still bad. I'm also seeing this behavior while bisecting a different bug on a 7950... Probably related...
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
