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

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

Everything is current git from Oibaf PPA using Mint 17 Cinnamon, although I'm about to move to Arch Linux so I don't know how long I'll be able to provide logs as

Better attach them here ASAP then. :) Xorg.0.log, dmesg and glxinfo.

the problem doesn't exist in Arch's currents AFAIK.

What version of Mesa does that use?

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

--- Comment #3 from Aaron B aaronbottegal@gmail.com --- Created attachment 103415 --> https://bugs.freedesktop.org/attachment.cgi?id=103415&action=edit GLXInfo

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

--- Comment #5 from Aaron B aaronbottegal@gmail.com --- Created attachment 103417 --> https://bugs.freedesktop.org/attachment.cgi?id=103417&action=edit Hardware report.

Important hardware:

R9 270X - 2GB GDDR5 - ASUS. FX-8350 - AMD. M5A99FX PRO 2.0 - ASUS.

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

--- Comment #7 from Aaron B aaronbottegal@gmail.com --- Created attachment 103504 --> https://bugs.freedesktop.org/attachment.cgi?id=103504&action=edit Crash+recover

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

Aaron B aaronbottegal@gmail.com changed:

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

--- Comment #9 from Aaron B aaronbottegal@gmail.com --- Created attachment 103522 --> https://bugs.freedesktop.org/attachment.cgi?id=103522&action=edit Two crashes+recovers. Xorg.

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

--- Comment #11 from Aaron B aaronbottegal@gmail.com --- (In reply to comment #1)

(In reply to comment #1)

...

Everything is current git from Oibaf PPA using Mint 17 Cinnamon, although I'm about to move to Arch Linux so I don't know how long I'll be able to provide logs as

Better attach them here ASAP then. :) Xorg.0.log, dmesg and glxinfo.

...

the problem doesn't exist in Arch's currents AFAIK.

What version of Mesa does that use?

I'm guessing as of this patch this can be closed? http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=20...

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

--- Comment #13 from Michel Dänzer michel@daenzer.net --- (In reply to comment #6)

Chromium randomly crashes with RadeonSI driver when using Chromium. Most usually with Youtube videos.

Using Flash or HTML5 video? Fullscreen or windowed? ...

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

--- Comment #15 from Michel Dänzer michel@daenzer.net --- (In reply to comment #14)

I use HTML5 video. But it's a Chromium issue in general, flash video just helps it happen faster.

Is it HTML5 or Flash now? :)

Think it'd be useful to try to attach a gdb session to Chromium? In the dmesg log, every time the problem happens, Chromium does receive a segfault.

Yes, backtraces of those crashes might be interesting.

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

--- Comment #17 from Aaron B aaronbottegal@gmail.com --- I just got a crash while trying to get some debugging output...but all Chromium would output, and it was just through the terminal, was "GPU process stalled after 10000ms." and that was basically all the information I got from it. I'll try again tomorrow, maybe try valgrind or some different CL arguments this time around. We'll see. Now it's time for sleep, though.

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

--- Comment #19 from Aaron B aaronbottegal@gmail.com --- It sounds like the same bug, but I'm not 1000% sure. But I had a few crashes in Chromium, the only out of place log message is:

ATTENTION: default value of option force_s3tc_enable overridden by environment. [8923:8923:0731/125646:ERROR:sandbox_linux.cc(302)] InitializeSandbox() called with multiple threads in process gpu-process

Not what to make of it, but it's something more.

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

--- Comment #21 from Aaron B aaronbottegal@gmail.com --- I'm getting the glitch a lot more, but trying to remember what sets it off most:

1. Youtube. Often, but not as often as #2.

2. Clicking on an element that brings up another element onto the page, basically over it with a higher z-index, like I said facebook does this a LOT.

3. Adding elements to the page at all can also trigger this bug. Like loading ANY comments, from disqus to yahoo, they all have triggered it.

4. Slideshows where the objects slide against each other, like in PCWorld slideshows, just had a crash there.

All of these have in common is moving pixels, but also adding pixels to the screen. Is there special code for that, those dirty rectangles being glitchy or something? I have, well, only bare minimal knowledge of how these drivers work from looking at lots of Git commits, but I bet that is a pretty good clue to people who know what they're looking at with what could be wrong. :)

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

--- Comment #23 from jackdachef@gmail.com --- @Aaron:

try reading into Magic SYSRQ key: http://en.wikipedia.org/wiki/Magic_SysRq_key

next time when X seems to freeze - first do a Magic SYSRQ + R, then try to imitate a "secure attention key" == Magic SYSRQ + k

whether that unlocks it

or if X doesn't show any change anymore but the system still seems to be alive:

Magic SYSRQ Key + r

then Magic SYSRQ Key + w (what tasks or kernel threads, etc. is stuck)

then the rest of "REISUB" (Magic SYSRQ Key + e, i, s, u, b)

after the next start you can look through the contents of the kernel messages in

/var/log/kern.log

via

tail -n 3500 /var/log/kern.log | less

(keyboard cursor up & down, quit via "q")

if the messages are too much

try via

tail -n 7500 /var/log/kern.log | less

or higher

sudo may be needed, if not using root privileges

logging may be disabled, so it first might have to be enabled

hope this helps ...

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

--- Comment #25 from jackdachef@gmail.com --- Created attachment 103839 --> https://bugs.freedesktop.org/attachment.cgi?id=103839&action=edit X turning black & crash (30 minutes of HTML5 video on youtube, movie trailers), no successful recovery, recovery with Magic SYSRQ + k

not sure if to post it here or bug #79980

watched movie trailers with chromium (adobe flash player explicitly turned off), after approx. 30 minutes on another trailer (mostly 1080p, 720p) the screen stalled and turned black,

seemingly couldn't recover on its own, sound kept on continuing, so figured that Magic SYSRQ + k could be successful and it was

originally wanted to post the bug info from within chromium but during attempt to surf over to bugs.freedesktop.org the screen turned black again and successfully recovered with a little help of Magic SYSRQ + k (so the trend seems to be that it's getting better but we're not quite there yet) ...

will post full dmesg with info *after* 2nd crash here, too

more looks like it's related to #79980 than being a separate bug (currently posing this from within firefox 31)

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

--- Comment #27 from jackdachef@gmail.com --- Created attachment 103843 --> https://bugs.freedesktop.org/attachment.cgi?id=103843&action=edit Xorg.0.log, after several crashes X can't be opened/used anymore, device seems unavailable

not sure if to post this here or in #79980,

but when continuing usage after the gpu gets unstable with chromium-usage (so using chromium in browsing in complex sites; chromium with adobe flash player [youtube !]; chromium with HTML5 video [youtube] - seems to mostly accelerate & more easily trigger the common issue with #79980 ?)

the following end-result is visible in the attached Xorg.0.log, the gpu isn't accessible anymore and a system reboot is necessary

usage-pattern was following:

- firefox - browsing the web, viewing wallpapers, gmail, google plus - gnote - writing notes - switching between firefox and gnote

desktop environment used was Xfce4 + compiz-fusion; past experience has shown that it doesn't matter whether composited or not (fluxbox, xfce4+compiz-fusion, kde4+kwin, razor-qt + kwin); so no difference since opengl or webgl acceleration is used anyway

(opengl); webgl might be something further to investigate -

the "issue" is, however that all of this works in 99%-100% with 3.14 kernel for me

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

--- Comment #29 from jackdachef@gmail.com --- using the new firmware (http://people.freedesktop.org/~agd5f/radeon_ucode/ucode.tar.gz) didn't seem to make a change in stability:

starting in fluxbox + firefox + gnote

watching videos on youtube (adobe flash player) for several minutes, writing some notes in gnote, exiting; gmail, google+

starting in Xfce4+ compiz-fusion, exiting

starting in fluxbox + firefox + gnote

browsing, watching wallpapers, gmail, google+

text corruption, especially in gmail & google search results occured with:

radeon 0000:01:00.0: Packet0 not allowed!

couldn't pinpoint what triggered it, several occurences in dmesg

starting up chromium, browsing youtube (adobe flash explicitly disabled), wanted to watch a video (HTML5 video), screen doesn't react anymore, turns black

gpu/screen turns black, hardlock

will attach dmesg later, no suspicious content besides

radeon 0000:01:00.0: Packet0 not allowed!

any useful data in connection with chromium -> hardlock, all data lost

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

--- Comment #31 from jackdachef@gmail.com --- related:

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

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

?

so it's more of a userspace issue ?

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

--- Comment #33 from jackdachef@gmail.com --- Created attachment 103895 --> https://bugs.freedesktop.org/attachment.cgi?id=103895&action=edit dmesg: X crashing while playing HTML5 video movie trailers on youtube, LLVM disabled, sb backend

so it at least doesn't seem to be caused by LLVM and/or vdpau,

must be something else in combination with the hardware acceleration

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

--- Comment #35 from Aaron B aaronbottegal@gmail.com --- Created attachment 103896 --> https://bugs.freedesktop.org/attachment.cgi?id=103896&action=edit Steam crash because of Chromium crash.

This is a log of steam trying to play CSS with Chromium open, which crashed, so we got a good and new log. Shows the VM dies.

Also, in dmesg got a new error among the GPU resets attempts:

[63446.944129] radeon 0000:01:00.0: still active bo inside vm

This was after a crash that failed to recover and dropped to a TTY screen. Not much, but it's something new for me.

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

--- Comment #37 from Aaron B aaronbottegal@gmail.com --- VLC also, rarely, has the crashing problem with simple video output acceleration.

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

--- Comment #39 from jackdachef@gmail.com --- (In reply to comment #38)

(In reply to comment #32)

...

R600_DEBUG=sb,sbsafemath,nollvm chromium-browser

Those debugging options only have an effect with the r600g driver, not with radeonsi.

are the other ways to temporarily disable LLVM for debugging in radeonsi ?

gentoo ebuilds force users to compile mesa & radeonsi with llvm - so that seemingly is the only way of operation with these kind of chipsets/cards ?

...

radeonsi isn't the only chipset family affected: intel cards hd2000, hd3000, hd4000; gm45, gm965, i915 (sandybridge, ivybridge, haswell, etc.), or other radeons are also affected in different ways

r600g issues might be related, but most definitely not Intel GPU ones.

so things are implemented *that* differently between intel & radeon drivers ?

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

--- Comment #41 from jackdachef@gmail.com --- Created attachment 104076 --> https://bugs.freedesktop.org/attachment.cgi?id=104076&action=edit dmesg-output after 25 minute hardware-accelerated html5 video crash, no hardlock this time (Magic SYSRQ works), screen corruption (screen subdivided horizontally into ~18 parts)

kernel running with drm-next-3.17-rebased-on-fixes applied on top of 3.16-rc6

latest commit: author Christian König christian.koenig@amd.com 2014-07-28 11:30:12 (GMT) committer Alex Deucher alexander.deucher@amd.com 2014-08-04 21:45:53 (GMT) commit fa783807977da98da35590fd1d5efdfd4f33fd59 (patch) tree 0f1573ae770843228930a0f278a82eb5d482a4c5 parent 5fc6854683aad9ae8b711cbe0d824c11b4aad66c (diff) drm/radeon: allow userptr write access under certain conditions

several hours of pushing and trying to get X/system lockup with firefox (hardware acceleration enabled) and watching & opening up large jpg images - showed that at least that issue was resolved (Bug #81612 )

Then now proceeded to re-test HTML5 video with hardware acceleration (hardware acceleration disabled was seemingly stable so far)

the funny thing: each of the last 3 test attempts after pretty much exactly 25 minutes it tends to lock up X

reproducer: chromium 38.0.2107.3 (previous versions should also work), but this one has more options disabled which should rule out other crash/instability triggers,

youtube.com , keywords: movie trailers 2014

watching random movie trailers with preferrably 1080p (some only available in 720p)

result: screen content locks up, mouse still movable for a short time & sound continuing, the screen turning black - (box locking up/hardlock - this time *not*) - this time: (in total 2) attempts to salvage via Magic SYSRQ + k

screen flickers, another Magic SYSRQ + k

screen turns on again, mentioned screen corruption (screen subdivided horizontally into ~18 parts) with mostly white and green color in the shape of tiles

took a photo, if needed

so we got a *clear* improvement: the box does *not* hardlock anymore, Magic SYSRQ key works again and screen attempts to recover with Magic SYSRQ + k,

but it's not successful yet

hope the information of dmesg helps with further adding some ideas on how to solve this

added the following patchset (patches 2-7) on top of that kernel https://lkml.org/lkml/2014/8/3/120 ([PATCH 0/7] locking/rwsem: enable reader opt-spinning & writer respin ), not sure if that might increase stability

Cheers

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

--- Comment #43 from jackdachef@gmail.com --- (In reply to comment #42)

I've been able to get lucky and not get a hard lock most of the time. You HAVE to wait 10 seconds for the drm to reset the GPU. The patch didn't improve or change anything, I've seen those results for a while.

any special commands you append to the radeon driver ? defaults (no special settings) ?

is it compiled into the kernel ? initramfs ?

thanks, will wait next time for 10+ seconds and crossing fingers

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

--- Comment #45 from Aaron B aaronbottegal@gmail.com --- I'm on Arch, from Mint, and have the issue on both. If you still don't have a crash for a while, lets start comparing chrome/DE settings. I'm on an R9 270X, which is a 7850 reclocked AFAIK.

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

--- Comment #47 from arnej ajanbu@gmx.de --- Created attachment 104430 --> https://bugs.freedesktop.org/attachment.cgi?id=104430&action=edit dmesg

I also have these problems. I attached my dmesg.

Until now (mesa 10.2.5), my system always hung completely and I had to reboot. Now I'm using mesa git and the screen goes blank, sound continues from the youtube video, and after about 10 seconds the screen is back and usable again.

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

--- Comment #49 from TheLetterN bugzilla.20.kamdrimar@spamgourmet.com --- I may have found a way to reliably trigger this bug. However, this is based on the assumption that this bug is also in Drivers/Gallium/r600 (Arch with mesa version 10.2.5-1) which is what I'm using on my sysem with a Radeon HD 5870. I'm posting here because the symptoms and error messages are exactly the same, and it looks like this bug is present in multiple mesa drivers, and I couldn't find a relevant bug posting in /Drivers/Gallium/r600.

So if anyone is willing to test it, I've found that using certain abilities in Tales of Maj'Eyal 64-bit Linux ( http://te4.org/ ) triggers the GPU lockup. Specifically, using the ability "Death Dance" will trigger it, and I believe something being called by the spinningwinds.lua and spinningwinds.frag scripts within t-engine4-linux64-1.2.3/game/modules/tome-1.2.2-gfx.team//data/gfx/shaders/ is causing it.

Unfortunately you'd have to make a berserker character and get to level 8 and 28 strength to unlock "Death Dance", so I've uploaded a gzipped save file you can extract and put in ~/.t-engine/4.0/tome/save/ That should work for testing if it triggers the GPU lock.

http://s000.tinyupload.com/index.php?file_id=67207270324448074311

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

--- Comment #51 from Maciej gutigen@outlook.com --- Any news? Mesa from 10.2 and up is still unusable on 7770.

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

--- Comment #53 from Maciej gutigen@outlook.com --- I upgraded xserver from 1.15 to 1.16 today and it looks like issue is gone. I even tried to reproduce the bug by running multiple flash instances and it didn't hang. Can anyone confirm that this bug doesn't occur on 1.16?

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

--- Comment #55 from Aaron B aaronbottegal@gmail.com --- 1.16* Whoops, not talking the kernel.

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

--- Comment #57 from Maciej gutigen@outlook.com --- Well, after a day the bug is back, so xserver update didn't help. @Clément Guérin - I have this bug on default Chrome, turning on HW just makes it more frequent.

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

--- Comment #59 from Aaron B aaronbottegal@gmail.com --- *Still active OB in VM"* Just had about 3 crashes in 2 hours. This is a joke of a bug that it seems nobody cares, and probably affects all SI, and probably R600 users.

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

--- Comment #61 from Damian Nowak nowaker@geozone.pl --- My story: https://bugs.freedesktop.org/show_bug.cgi?id=65963#c4

tl;dr Mesa 10.1.4 is the last version that doesn't cause the problem.

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

--- Comment #63 from Michel Dänzer michel@daenzer.net --- (In reply to comment #61)

tl;dr Mesa 10.1.4 is the last version that doesn't cause the problem.

If somebody could bisect that regression between Mesa 10.1 and 10.2, that would be very helpful. See https://bugs.freedesktop.org/show_bug.cgi?id=79696#c21 for some hints.

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

--- Comment #65 from Aaron B aaronbottegal@gmail.com --- I don't know what changed, if anything, but I did upgrade Chrome about 3 days ago, and now the past 2 days ever since I saw them mentioning more then 3-4 crashes a day, I'm running into 15-20 crashes a day. I can't do anything with Chrome. Next time I watch a video, we'll see if that went down in stability. LIke I said though, I did upgrade Chrome, but I don't remember any regressions in the first day of use. Maybe I didn't close it so I wasn't running on the new version, but still my crash numbers have gone through the roof now, I can't keep chrome open at all unless it's needed.

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

--- Comment #67 from Aaron B aaronbottegal@gmail.com --- Created attachment 105569 --> https://bugs.freedesktop.org/attachment.cgi?id=105569&action=edit API trace of a crash.

(In reply to comment #65)

...

I don't know what changed, if anything, but I did upgrade Chrome about 3 days ago, and now the past 2 days ever since I saw them mentioning more then 3-4 crashes a day, I'm running into 15-20 crashes a day. I can't do anything with Chrome. Next time I watch a video, we'll see if that went down in stability. LIke I said though, I did upgrade Chrome, but I don't remember any regressions in the first day of use. Maybe I didn't close it so I wasn't running on the new version, but still my crash numbers have gone through the roof now, I can't keep chrome open at all unless it's needed.

Well that at least makes the issue more reproducible. Could you try grabbing an apitrace log what what's going wrong?

That would really help.

This what you're looking for?

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

Aaron B aaronbottegal@gmail.com changed:

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

--- Comment #69 from Aaron B aaronbottegal@gmail.com --- Created attachment 105581 --> https://bugs.freedesktop.org/attachment.cgi?id=105581&action=edit chromiumapitrace

(In reply to comment #68)

(In reply to comment #67)

...

This what you're looking for?

No, we're looking for the /home/aaron/chromium.*.trace file generated by apitrace corresponding to the crash.

BTW, can you try if Mesa 10.1 is stable for you as well? And if so, bisect?

If I get time I'll compile Mesa 10.1 32 and 64 bit and see if they work. No promises, as git always fails either on or right after receiving 99% of objects, so I have to try about 20 times to even attempt compile basically anything.

Still, you're in luck as I started an API Trace and as soon as my browser started to open, it killed it, so it's a nice and pair of traces.

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

--- Comment #70 from Aaron B aaronbottegal@gmail.com --- Wrong file. This is the right file:

https://drive.google.com/file/d/0B1laUfqMuZQBeWpHSDYtV2N3RjQ/edit?usp=sharin...

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

--- Comment #72 from Aaron B aaronbottegal@gmail.com --- (In reply to comment #71)

(In reply to comment #70)

...

https://drive.google.com/file/d/0B1laUfqMuZQBeWpHSDYtV2N3RjQ/edit?usp=sharin...

Can you reproduce the crash by feeding those traces to glretrace?

(In reply to comment #69)

...

If I get time I'll compile Mesa 10.1 32 and 64 bit and see if they work. No promises, as git always fails either on or right after receiving 99% of objects, so I have to try about 20 times to even attempt compile basically anything.

Note that you only really need to clone a Git repository once, after that all the history (including all the commits you might need to test during the bisection) is available locally.

Yeah, but I build it with yaourt, which likes to contain it's gits elsewhere and apparently deletes them every time as you can't keep a clone unless it's in the same session. I would work on getting 2-3 clones and uploading them to my git and copying from that if need be, but it's just tons of work for me. Like I said, I have to try about 20 times to even clone anything, it's a severe pain.

And running glretrace about 10 times on the trace files, no beans on getting another crash.

[aaron@Aaron-Arch Chromiumapitrace]$ glretrace chromium.trace 0 64 glXSwapIntervalMESA(interval = 1) = 0 64: warning: unsupported glXSwapIntervalMESA call Rendered 150 frames in 2.68355 secs, average of 55.8961 fps [aaron@Aaron-Arch Chromiumapitrace]$

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

--- Comment #74 from Michel Dänzer michel@daenzer.net --- (In reply to comment #73)

Could it be I'm using LLVM 3.6 [...]

Yes, only released versions of LLVM can be supported by released versions of Mesa. Even LLVM 3.5 is only being released now, so you might need LLVM 3.4(.y) for Mesa 10.1.

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

--- Comment #76 from Aaron B aaronbottegal@gmail.com --- Ah, okay. Yeah, dropped to LLVM 3.4 and we're good to go. I'll report any results I find interesting or believe may be problematic soon, along with my bisect paths. I have 4 days off, so I'll probably be posting here a lot if I get anything. Also helps I'm currently working on getting my projects to a publishable state so I'll be in the programming-debugging mood to boot.

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

--- Comment #78 from Marek Olšák maraeo@gmail.com --- (In reply to comment #77)

Took a few hours, but only one shot thankfully.

first bad commit: [0e7b0f2a0ad3818d02907746a86568c264c97701] meta: Refactor binding of renderbuffer as texture image

http://cgit.freedesktop.org/mesa/mesa/commit/ ?id=0e7b0f2a0ad3818d02907746a86568c264c97701

I think this is all you guys, now.

That commit doesn't have any effect on radeonsi. Back to square one I guess.

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

--- Comment #80 from Aaron B aaronbottegal@gmail.com --- (In reply to comment #79)

Aaron, most likely the bisection didn't work because you marked commits as good which would have shown the problem after more testing. I'm afraid you'll have to test longer before declaring a commit as good.

Hmm, okay, I'll try again. I'll test for about 8 hours this time. I don't have the best grasp of the Mesa works, but I didn't think I screwed up as it seemed to be something related to multisampler blitting which sounds darn close to what is screwed up.

Starting over.

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

--- Comment #82 from Aaron B aaronbottegal@gmail.com --- I'm still bisecting, but I just want to say I suck at it and I'll probably need at least 2 bisects to the same point, if not more. I'm trying to be patient, but on the old Mesa's the glitch just takes so long to do, even when I set it up to do it.

So, should I skip to bisecting if this DMA patch that was just proposed is the source of our problem, also?

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

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

--- Comment #84 from Clément Guérin geecko.dev@free.fr --- Awesome work Aaron, don't give up!

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

--- Comment #86 from Aaron B aaronbottegal@gmail.com --- 1 day since I compiled mesa with the 2nd patch here, all is well and stable.

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

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

--- Comment #88 from Aaron B aaronbottegal@gmail.com --- (In reply to comment #87)

(In reply to comment #86)

...

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

I think in the meantime Grigori has seen GPU hangs even with that patch though, with 2D tiling.

However, can you avoid the problem if you start Chromium with the environment variable R600_DEBUG=nodma?

I was waiting for someone to comment before I updated my status. I have had one crash, one of the ones where X dies because of 3 quick lock ups+recovers. But, considering that was the only crash in 2 days, it's much better than before. I also didn't know if the crash was Chromium or not, because I was alt+tabing into other windows, but I'd bet it was. Let me recompile mesa fresh and try launching Chromium and let you know the end of today if disabling also fixes it.

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

--- Comment #90 from Aaron B aaronbottegal@gmail.com --- My testing has been delayed since they pushed LLVM 3.5 to stable on Arch, but they changed one of the function's parameters. Then, 3.6 compiles perfectly for 64-bit, yet when compiling 32-bit, it fails to link. So I've been stuck using repro's of 10.2.7 which...seems better, but it still does crash. Maybe it a memory/buffer overrun problem, because the versions are either god-awful, or somewhat usable with only a rare hiccup, which more recent versions just getting worse and worse. But like I said, I can't compile basically anything right now until everyone gets their stuff straight on function names and parameters.

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

--- Comment #92 from Aaron B aaronbottegal@gmail.com --- Like I said, I tried. But, it's too hard to reproduce. Unless you do it over a 2 week time span, it's so difficult to find. Maybe he could do it better since his builds seem to crash more if it's completely unusable. But, if you're on arch and don't want to help, stick to 32 and 64-bit LLVM 3.4.2. I can't help for now.

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

--- Comment #94 from Grigori Goronzy greg@chown.ath.cx --- Maybe the crash actually happens because of glamor rendering - setting R600_DEBUG won't do anything in that case.

Does this patch to Mesa make any difference?

https://bugs.freedesktop.org/attachment.cgi?id=105745

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

--- Comment #96 from Aaron B aaronbottegal@gmail.com --- Just a while ago, I was the same way, sort. The main thing is to get away from the not-as-good package manager in Ubuntu, and go with Arch like I did. Package support is amazing because of the AUR, which build source for you, and when you have to do it yourself like us, most of the time you can just grab the config from the auto-installer, which should have 99% of the config options in-place. Like I said, it's screwed ATM, but usually it's pretty painless to compile anything. You just have to try it out. If you email me, I can get you set up with a Mesa build configure for RadeonSI. Then all you have to do is learn how to clone, pull, and patch in git. It's all not too bad. I mean, most LInux people are devs of some sort, so if you want to have a good time, you should put a little more time in and learn how the back-end of Linux and how programs are compiled to have a good time. I'll keep testing, as soon as I find a way to compile LLVM 3.6.

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

--- Comment #98 from Aaron B aaronbottegal@gmail.com --- I'm giving you details on how to more help us, and if you can run Linux in any way, and understand how the command line works even remotely, and how packages work, going to a better system/learning one little thing like code compiling isn't hard is my point, if you don't want to, that is fine, but at the same time, even I'm a programmer, and the DRM infrastructure and hardware isn't in my league so I can't help that way, but to help, yeah it's good to get confirmation of bugs, but unless we can patch together and such, it's a long shot from finding the actual problem, since, like I said, it's hard to track down, it's so random.

But still, whoever said AMD has the best FOSS drivers was dead wrong, as they're last AFAIK. Intel and Nvidia patches to Mesa even are 10x more. Our guys on here do good work, it's not their fault AMD as a company won't cater to us, though. They don't have much help, it's 4-5 guys, most of them watching this. I mean, if they ditched their Proprietary drivers made in Hong Kong, which aren't bad when they compile on 2 year old kernels, and contributed to Mesa/DRM, we'd of had good drivers years ago. But they don't, so we're here now, and we gotta be patient. You should have known and understood this before you went to a newer technology card. I mean, I'm mad too, I also want to go with a GTX 770ti, but I'm sticking with this to help get it stable, as without users it's also harder to get software into a usable state over all.

If you want complete usability on your hardware, you should just go windows then, FWIW. As bad as that sounds, if you need it to work, use what does for your hardware, as new hardware in Linux takes time, especially since there's always new hardware. It works for me, just a few bugs, I'm sorry yours is worse, but there's not much any of us can do.

Also, I haven't had a crash in 3 or so days now since I went to LLVM 3.6, even though it doesn't build Mesa with it on 32-bit. Maybe it's fixed, just have to wait for LLVM to update.

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

--- Comment #100 from Aaron B aaronbottegal@gmail.com --- I also would like to note that, I just had 2 crashes. Chromium. So it still exists, just seems to happen rarer and rarer for me.

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

--- Comment #102 from Emil Velikov emil.l.velikov@gmail.com --- (In reply to comment #101)

Emil Velikov

Not sure what difference would it make to file a bug at launchpad from where they will point me right here. Aren't all Mesa devs right here anyway? I'm seeking assistance from Mesa developers, which I heard are paid by AMD (those on AMD team) - which makes me their customer.

Please try to settle for a moment and read the whole "development" vs "distribution" note.

I suppose this is wrong place to be a normal person, not a dev, so I'll stay away in the future and meanwhile jump ship to Nvidia camp, fuck You very much (Mesa is great, but Your attitude towards non-developers is terrible).

I never said nor hinted that this is the "wrong place for normal people". I feel that once you realise what I meant with "development vs distribution" you will understand that "our attitude" is not terrible. All developers ask is some clear steps in order to understand and fix the issue.

Thanks

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

--- Comment #104 from Maciej gutigen@outlook.com --- Easy way to reproduce (though takes some time) is watching any video using mplayer with xv. After few minutes (or an hour) it will hang. Same goes for flash videos, fire up 5 or 6 at once and in no time it should hang.

Watching videos in mplayer with vdpau doesn't result in crash (I watch a lot of movies on this machine with smplayer+vdpau, never hanged with it). Also aside from flash, current Firefox (32) from Ubuntu 14.10 works properly, but if I turn on hardware acceleration (OMCT or something) it behaves just like Chrome (hangs).

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

--- Comment #106 from Aaron B aaronbottegal@gmail.com --- LibreOffice triggers the bug much, much more than Chromium and VLC. Trying to make a few work documents and update my resume, and it's just not doable.

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

--- Comment #108 from Aaron B aaronbottegal@gmail.com --- I have seen the comment, once LLVM becomes unbroken, and GCC becomes unbroken, and everything doesn't suck, I'll recompile it all. But right now, LLVM is broken, and even when compiled, doesn't link right with Mesa/Mesa32, so I can't test for certain right now.

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

--- Comment #110 from Aaron B aaronbottegal@gmail.com --- I found this post, stating some of the ASUS hardware comes PRE-OVERCLOCKED from the factory. Good chance this is the cause of my instability?

http://www.tomshardware.com/answers/id-2041324/problem-asus-270x-screen-blan...

My GPU:

http://www.newegg.com/Product/Product.aspx?Item=N82E16814121802&nm_mc=KN...

Core clock is listed at 1120 Mhz, not 1050 Mhz.

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

--- Comment #112 from Aaron B aaronbottegal@gmail.com --- OKay, I'm testing it now. Can't game at any good framerate, but that is fine. If I get no crashes here, does that mean the random crashes are from changes in power state? It would make sense, sense most of the time is on page loading, or most of the screens pixels changing at the same time. I'm on a 1080p screen via hdmi, maybe that could help you try to replicate it some more.

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

--- Comment #114 from Alexandre Demers alexandre.f.demers@gmail.com --- (In reply to comment #113)

I commented out every "return ret;" of si_dpm_set_power_state() in si_dpm.c. After booting this modified kernel, I can confirm this is the only error reported in si_dpm_set_power_state(): every other verification passes OK and it goes down to the very end.

Oops, I had too many bugs opened, I wrote this comment in the wrong one.

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

--- Comment #116 from Alexandre Demers alexandre.f.demers@gmail.com --- I've been reading the comments in fast forward, and I'm sure I'm hitting the same bug.

For info, I'm using a 7950 on Arch 64. I'm running Xorg server 1.16.1. Mesa, drm and ddx are all from the latest git repositories. I was not experiencing this bug yesterday while I was still using a 6950 on Glamor.

Now, I have a log that I can push from just after a hang and reset or from a hang and a badly running Xorg server. There is something about ring 5 not responding. I'll send the file later when I'll get to my desktop.

To trigger the bug in no time, as you, I just have to watch a movie (either flash or html5) on chrome or firefox and wait. Otherwise, going through websites, apps, etc will get you to the same point, but it will take more time.

I must warn you though: chrome/chromium has been hanging with both r600 and readeonsi drivers. It should not be mixed with the current issue, because they are probably two different bugs. Thus, I prefer to use firefox for now to eleminate mixing these two.

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

--- Comment #118 from Alexandre Demers alexandre.f.demers@gmail.com --- (In reply to comment #117)

Well, I'm still on Chromium, and I've forced my GPU from the backlist, because if you don't then it doesn't use all accel so it should be okay. Anyways, I turned off DPM and have no crashing at all, Chromium seems stable, LibreOffice seems stable, and also when you turn off DPM, the "Screen Jumping/corruption" goes away. It seems to be proportional to number of crashes, too. Which I have seen it go away, and no crashes now, so maybe it's related. But without DPM I'd say my GPU is now stable. My R9 270X is ASUS brand from about January, if that would help figure what hardware it has.

Well, it points out a problem with dpm. Maybe the uvd class is problematic?

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

--- Comment #120 from Aaron B aaronbottegal@gmail.com --- I don't know how much it'll help, but I have this running in the background to try to see whatever causes it. It doesn't help much considering I don't have a marker/way to input when the crash starts to happen, but maybe someone has an idea of the best way to do that. Maybe look for messages in dmesg about the rings locking up? Any improvement ideas? You probably will have to adjust the sampling rate and size to fit your computer, my drive is at 50% usage running this, but I can afford it since I have a few drives.

http://ideone.com/V4MkeN

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

--- Comment #122 from José Suárez j.suarez.agapito@gmail.com --- Created attachment 106946 --> https://bugs.freedesktop.org/attachment.cgi?id=106946&action=edit Dmesg log

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

--- Comment #124 from José Suárez j.suarez.agapito@gmail.com --- Just for an easier read:

Radeon HD 7870 GHZ Edition 2 GB FX 8150 @ 3700 MHz 16 GB RAM

Linux 3.17-rc5, with mesa 10.4~git1409200730.4eb2bb compiled with llvm 3.6~svn217413 on Kubuntu 14.04 with all the latest updates (including firefox).

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

--- Comment #126 from Christian König deathsimple@vodafone.de --- (In reply to comment #119)

Small question Alex Deucher or Christian may answer: is it normal ring 5 is completely in a different GPU's memory address area? [ 9.353518] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x00000000c0000c00 and cpu addr 0xffff880411a25c00 [ 9.353519] radeon 0000:01:00.0: fence driver on ring 1 use gpu addr 0x00000000c0000c04 and cpu addr 0xffff880411a25c04 [ 9.353521] radeon 0000:01:00.0: fence driver on ring 2 use gpu addr 0x00000000c0000c08 and cpu addr 0xffff880411a25c08 [ 9.353522] radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x00000000c0000c0c and cpu addr 0xffff880411a25c0c [ 9.353524] radeon 0000:01:00.0: fence driver on ring 4 use gpu addr 0x00000000c0000c10 and cpu addr 0xffff880411a25c10 [ 9.356425] radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x0000000000075a18 and cpu addr 0xffffc90015fb5a18

rings 0 to 4 are all in the same gpu address subset, but not ring 5?

Yes that's perfectly normal. Ring 5 is the UVD ring and that needs to have it's fence in the first 256MB of VRAM.

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

--- Comment #128 from Christian König deathsimple@vodafone.de --- (In reply to comment #127)

Thank you Christian for your quick explanation. Can we suspect the problem to be withing the UVD code then if:

• crashes are mostly happening when watching videos (flash or html5 in

whatever browser);

• logs points to ring 5 not responding for some time?

Well that behavior could actually be completely normal, incorrectly feeding UVD with informations can crash the block.

That can happen for example because of a corrupted video stream, or because the userspace driver doesn't work 100% correctly.

Whatever it is the recommended way to handle it is to just reset the block and that's exactly what we do, the only problem is that it's really hard to get the reset to be 100% reliable.

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

--- Comment #130 from José Suárez j.suarez.agapito@gmail.com --- Oh, by the way, since I see UVD comments, just to be clear, I don't have GPU acceleration enabled in Flash.

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

--- Comment #132 from Alexandre Demers alexandre.f.demers@gmail.com --- (In reply to comment #131)

I have just played a youtube video (coincidentally the youtube message from AMD's John Byrne regarding Catalyst!) and I have just checked that the following messages show up in the dmesg log:

[ 2053.298531] radeon 0000:05:00.0: Packet0 not allowed! [ 2058.548486] radeon 0000:05:00.0: Packet0 not allowed! [ 2166.793537] radeon 0000:05:00.0: Packet0 not allowed!

Given that the video is very short and I haven't played any other youtube video the system hasn't crashed (yet). I presume that if I were to play other videos the system would hang.

I saw that also at at least one time. I'll look in my logs for this when it hangs.

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

--- Comment #134 from Alexandre Demers alexandre.f.demers@gmail.com --- I'd like to test disabling UVD. I'll dig in the kernel to report UVD as disabled for SI for this test. This should narrow where we have to look for this bug.

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

--- Comment #136 from Alex Deucher agd5f@yahoo.com --- (In reply to comment #131)

I have just played a youtube video (coincidentally the youtube message from AMD's John Byrne regarding Catalyst!) and I have just checked that the following messages show up in the dmesg log:

[ 2053.298531] radeon 0000:05:00.0: Packet0 not allowed! [ 2058.548486] radeon 0000:05:00.0: Packet0 not allowed! [ 2166.793537] radeon 0000:05:00.0: Packet0 not allowed!

These indicate that userspace is sending a broken command stream (e.g., a bad count for a packet most likely). The kernel will reject the command stream if a bad one is encountered. There still could be a bug in the command stream setup in userspace that is just masked in other cases due to the layout of the commands.

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

--- Comment #138 from Alexandre Demers alexandre.f.demers@gmail.com --- (In reply to comment #135)

(In reply to comment #134)

...

I'd like to test disabling UVD. I'll dig in the kernel to report UVD as disabled for SI for this test. This should narrow where we have to look for this bug.

Sometimes UVD functions are needed for power management to work correctly, so not enabling UVD at all might not be an option either. But I'm not sure if that applies to your hardware or not.

Easiest way to disable UVD otherwise is to just add an "return -1" to the beginning of radeon_uvd_init in the kernel module.

Well, when disabling UVD as suggested, I had no hang when viewing movies all night long. No ring 5 error either.

I did get some Packet0 errors though, which were "stuttering" the display for short times, but it never crashed.

However, at one point, Xorg just froze (the sound was still playing and the mouse was moving but nothing else was responding) but I think it is a different bug (there is nothing in dmesg, but there is errors in Xorg.0.log). I'll attach the file in a second. If someone is sure this is a different bug, let me know so I'll open a new bug for it.

Overall, I'd be tempted to point at UVD for the current bug.

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

--- Comment #140 from Aaron B aaronbottegal@gmail.com --- I dunno, I've had all those bugs, and when I'm stable, none happen to my knowldge. I think they're all same things, different ways of triggering. Or, maybe we do have multiple bugs.

Chromium/Chrome/VLC/Video/Screen blanks: UVD

What bugs should be classified as a different trigger? We should probably ping what is what now, that we have lots more people with the same problems posting. :)

Also, started watching a movie, crashed in 5 minutes, UVD died. Turned off PM, and UVD is fine , an hour or so in to the movie, and I'm going to watch 2 more after it, so we'll see. If it's stable after 2 more hours, DPM is definitely causing something, maybe both bugs with UVD and GPU faulting/EQ overflow/MSC Numbers unequal.

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

--- Comment #142 from Alexandre Demers alexandre.f.demers@gmail.com --- (In reply to comment #141)

If someone has a way to reliably reproduce the 'Packet0 not allowed!' error, please file a separate report for that. Or, if you know at least which process triggers it, you can run that process with the environment variable RADEON_DUMP_CS=1, and it should print a dump of the failed command stream(s) on stderr.

P.S. I'm afraid this report has turned into a train wreck, it's impossible to keep track of who encountered what issue(s) under what circumstances.

I opened Bug 84500 just for Packet0.

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

--- Comment #144 from Aaron B aaronbottegal@gmail.com --- Is it possible at all that the problem is related to using DDR3-1866 RAM? I mean I'm trying to think of why you guys at AMD can't encounter it, while I can't stay away from it. That is basically the only piece of hardware that would be "overclocked" by any means. But I don't know. You guys still haven't encountered these problems?

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

--- Comment #146 from Aaron B aaronbottegal@gmail.com --- Go figure after saying that, I maximized a youtube video and it died when on radeon.dpm=0. So just...guess this can just die. -_-

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

--- Comment #148 from Gedalya gedalya@gedalya.net --- See https://code.google.com/p/chromium/issues/detail?id=404357

In my case it was definitely crashing with mesa 10.2. In all cases it seemed to be triggered by chromium. Bug 85647 is talking about something that started with mesa 10.3.