Bug 76487 - [PIGLIT,radeonsi] spec/{EXT_texture_array/fbo-generatemipmap-array,ARB_framebuffer_object/fbo-generatemipmap-3d} RGB9_E5 crashes
Summary: [PIGLIT,radeonsi] spec/{EXT_texture_array/fbo-generatemipmap-array,ARB_frameb...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-22 18:33 UTC by Kai
Modified: 2015-02-19 15:52 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
GDB backtrace and register info of the crash (11.61 KB, text/plain)
2014-03-22 18:33 UTC, Kai
Details

Description Kai 2014-03-22 18:33:52 UTC
Created attachment 96212 [details]
GDB backtrace and register info of the crash

For the first time ever, since I'm having a PITCAIRN GPU I was able to run a full Piglit quick test without crashing my X (hooray for that). During the test I came across two similar crashes in "spec/EXT_texture_array/fbo-generatemipmap-array RGB9_E5" and "spec/ARB_framebuffer_object/fbo-generatemipmap-3d RGB9_E5" (see the attached GDB backtrace; the backtrace is for spec/EXT_texture_array/fbo-generatemipmap-array RGB9_E5", but the second crashed in the same function on the same line and as it's the same format, that is tested, I guess, these are related, if not, I'm happy to provide a backtrace for the second case as well and split the bugs).
I can't tell whether this is a regression or not, since this was the first time I was able to run Piglit on this machine without getting a corrupted results file, due to the crash of the X server.

My graphics stack is:
GPU: "PITCAIRN" (ChipID = 0x6819)
Linux: 3.13.6
libdrm: 2.4.52-1
LLVM: SVN:trunk/r204517
libclc: Git:master/1e278a7b04
Mesa: Git:master/4c79f088c0
GLAMOR: Git:master/a4fbc7732a (Standalone)
DDX: Git:master/ea6d0affe5
X: 1.15.0-2

Let me know if you need further information.
Comment 1 Marek Olšák 2014-03-22 18:48:53 UTC
This fix is on the mailing list:
http://patchwork.freedesktop.org/patch/22223/
Comment 2 Kai 2014-03-22 19:55:10 UTC
(In reply to comment #1)
> This fix is on the mailing list:
> http://patchwork.freedesktop.org/patch/22223/

Oh, nice to hear! Do I need just that patch or the entire series? And what about Brian's remark regarding memory consumption? Am I about to totally trash my performance, if I apply this patch/series or is this path hit only rarely?
Comment 3 Marek Olšák 2014-03-22 21:26:45 UTC
In theory, yes, you will need more memory. I'm going to rework the patch, but not today.
Comment 4 Kai 2014-03-22 21:51:18 UTC
Ok, then I'll wait. Let me know when there's a reworked version and I gladly test it.
Comment 5 smoki 2015-02-19 15:52:36 UTC
 This seems long time fixed with commit 26c41398cc47c0f72259a34406831443238b7ba9

 Closing.


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.