Bug 102595 - [clover r600g cayman] segfault when running clpeak --global-bandwidth
Summary: [clover r600g cayman] segfault when running clpeak --global-bandwidth
Status: NEW
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r600 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 99553
  Show dependency treegraph
 
Reported: 2017-09-07 20:22 UTC by Benji Wiebe
Modified: 2017-11-04 22:58 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Stack trace from coredump (1.58 KB, text/plain)
2017-09-07 20:25 UTC, Benji Wiebe
Details
Better stack trace (4.20 KB, text/plain)
2017-09-08 01:02 UTC, Benji Wiebe
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Benji Wiebe 2017-09-07 20:22:00 UTC
When I run 'clpeak --global-bandwidth' I get:

[benji@benji-pc clpeak]$ ./clpeak --global-bandwidth

Platform: Clover
  Device: AMD CAYMAN (DRM 2.50.0 / 4.13.0+, LLVM 6.0.0)
    Driver version  : 17.3.0-devel (Linux x64)
    Compute units   : 12
    Clock frequency : 880 MHz

    Global memory bandwidth (GBPS)
      float   : radeon: Failed to allocate a buffer:
radeon:    size      : 1073741824 bytes
radeon:    alignment : 4096 bytes
radeon:    domains   : 4
radeon:    flags     : 4
radeon: Failed to allocate a buffer:
radeon:    size      : 1073741824 bytes
radeon:    alignment : 4096 bytes
radeon:    domains   : 4
radeon:    flags     : 4
Segmentation fault (core dumped)



And in dmesg:
[55959.960796] clpeak[16731]: segfault at 1c ip 00007f3d77e5a42a sp 00007fff93152570 error 4 in pipe_r600.so[7f3d77d53000+1c2000]


The clpeak compute-* and kernel-latency tests work fine, and transfer-bandwidth fails with a (I believe) unrelated error message, seemingly due to me running Linux-git.
Comment 1 Benji Wiebe 2017-09-07 20:25:13 UTC
Created attachment 134057 [details]
Stack trace from coredump
Comment 2 Benji Wiebe 2017-09-08 01:01:50 UTC
New backtrace with debugging turned on. It appears that the issue is a NULL pointer dereference in r600_resource_copy_region (dst). In compute_memory_promote_item, pool->bo is NULL (which is what 'dst' is for r600_resource_copy_region).
Comment 3 Benji Wiebe 2017-09-08 01:02:03 UTC
Created attachment 134061 [details]
Better stack trace


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.