| Bug ID | 89034 |
|---|---|
| Summary | Firefox crashing xserver and some major rendering bugs |
| Product | Mesa |
| Version | git |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | critical |
| Priority | medium |
| Component | Drivers/Gallium/radeonsi |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | smoki00790@gmail.com |
| QA Contact | dri-devel@lists.freedesktop.org |
Created attachment 113269 [details]
valley_artifacts
Well i put this as radeosi bug as i am not sure if happens elsewhere. It is
LLVM bug actually which happens once subreg liveness is enabled, so svn 228228
is bisected as bad. I running current llvm with subreg liveness disabled, as
this is major/grave one bug for me.
Same issue was present in Tom's perf branches last month once subreg liveness
is enabled too.
Hardware is kabini (Athlon 5350), current Debian Sid 64bit, kernel 3.19.0,
xserver git, mesa git, etc...
Attached is screenshot from Unigine Valley for example, there are major
rendering issues in many other GL apps.
For Firefox crashing xserver not sure how to debug that (btw it crashed X
immidiate at starting FF) , if i build llvm with debug and assertations
screen/monitor somehow looks like it goes sleep mode (without any messages in
logs) and only hard reset helps. If i build llvm without those it just crashing
xserver, but there is not enough info in Xorg.0.log :(
| What | Removed | Added |
|---|---|---|
| Attachment #113269 mime type | text/plain | image/png |
(In reply to smoki from comment #0) > Attached is screenshot from Unigine Valley for = example, there are major > rendering issues in many other GL apps. Haven't seen such artifacts on Kaveri. Can you attach the stderr output of running Valley or another affected app with R600_DEBUG=3Dvs,ps with and wit= hout the bisected commit? > For Firefox crashing xserver not sure how to de= bug that [...] Is there something about it in the Xorg stderr output? It should be capture= d in a gdm log file.
Well i can but i need first to make a bottle of coffee because one llvm build takes 30 minutes on Kabini :D. but OK will do something... later... I don't have gdm.log as i don't use it, plain startx is used. I can only attach Xorg.0.log without debug build... but well, later...
(In reply to smoki from comment #2) > Well i can but i need first to make a bottle of= coffee because one llvm > build takes 30 minutes on Kabini :D. It shouldn't take that long after switching between the bisected commit and= the one before it (or just re-applying/reverting it on top of whatever later co= mmit you may have built last). If you're not using ccache yet, that might help a little as well. > I don't have gdm.log as i don't use it, plain s= tartx is used. Then something like startx [...] 2>stderr.txt should capture the stderr output in a file.
Created attachment 113272 [details]
xcrash
Using wihout patched llvm to post this as i can't use proper llvm with browser
to post this :D
This is with debug llvm, but without asserts enabled likely there are
assertation there holding something to not logging, but dunno anyway might be
useful.
Please get a backtrace of the crash with gdb by attaching gdb = to the Xorg process via ssh before starting Firefox.
(In reply to Michel D=C3=A4nzer from comment #3) >=20 > Then something like >=20 > startx [...] 2>stderr.txt >=20 > should capture the stderr output in a file. Actually that one drop something, this is with debug+assertion enabled llvm when monitor just gooes to "sleep" after starting firefox... seem= s like usefull :) ? X: TargetRegisterInfo.cpp:189: virtual const llvm::TargetRegisterClass* llvm::TargetRegisterInfo::getMatchingSuperRegClass(const llvm::TargetRegisterClass*, const llvm::TargetRegisterClass*, unsigned int) const: Assertion `A && B && "Missing register class&qu= ot;' failed.
Please get a gdb backtrace (bt full) for the assertion failure= then. Bonus points for running Xorg with R600_DEBUG=3Dvs,ps and grabbing its stderr out= put leading up to the assertion failure as well.
Well i think i can't do that, because i don't have another machine right now.
Alternatively, you can try using a script for gdb's --command = option, something like: set logging on set logging redirect handle SIGPIPE nostop noprint continue bt full continue quit That should capture the backtrace in a file called gdb.txt. See http://wiki.x.org/wiki/Development/Documentation/ServerDebuggin= g/#index6h2 for more background.
Created attachment 113309 [details]
gdb.txt
Hopefully i did it fine :) gdb.txt attached...
Created attachment 113310 [details]
stderr.txt
...and stderr.txt
Those seems interesting: err = 0x7f6cbf5538f0 <error: Cannot access memory at address 0x7f6cbf5538f0> buffer_data = 0x25 <error: Cannot access memory at address 0x25>
I'm getting this issue also. I thought it was my own fault because it was so strange. I'm on Linux Mint, Kernel 3.19 and the crash happens when using LLVM 3.7 on Xserver 1.16 and git.
I'm using llvm from debian/ubuntu nightly build and I'm experiencing quite the same problem. I've builded mesa against llvm3.7svn228689 yesterday evening. KDE starts ok, with startx, but as soon as I open a window (terminal, dolphin, firefox or what ever) X crash. You can see my xserver crash log. (attachment 1 [details] [review]) The last good build was on llvm3.7~svn227765 which is around the 2nd of February (nightly builds struggled since then in 32bit build, until yesterday afternoon). Also I'm facing many corruptions on 227765 build in Dota2. (attachment 2 [details] [review]) Switched back to llvm3.6rc2-2 and it's ok now, X doesn't crash and Dota2 corruptions are gone. Sorry but I can't bisect using nigthly packages (I'm not able to build a .deb from svn).
Sorry, I forget some infos: mesa/xserver/ddx/drm from git kernel drm-fixes-3.19 GPU: R7-265
I have just committed a change to llvm svn that disables sub-reg liveness and filed an LLVM bug for this: http://www.llvm.org/bugs/show_bug.cgi?id=22548
Thank you Tom, with latest changes crashes and Valley rendering issue are gone for me. BTW I'm still facing rendering issue in Dota2. Performances with LLVM-3.7 are great, about 30FPS in Valley. Nice.
(In reply to Lorenzo Bona from comment #19) > BTW I'm still facing rendering issue in Dota2. That looks a lot like bug #88978. You could try the trace posted there to see if you are experiencing the same issue.