Bug 102595 - [clover r600g cayman] segfault when running clpeak --global-bandwidth
Summary: [clover r600g cayman] segfault when running clpeak --global-bandwidth
Status: RESOLVED MOVED
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: 2019-09-18 19:24 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
Comment 4 GitLab Migration User 2019-09-18 19:24:12 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/610.


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.