Bump rocm-systems from `a08170b` to `0eccbf0` by dependabot[bot] · Pull Request #2533 · ROCm/TheRock

dependabot · 2025-12-12T10:35:42Z

Bumps rocm-systems from a08170b to 0eccbf0.

Additional changes

Dropped one patch that is no longer needed since ROCm/rocm-systems@0c4d08f

Commits

0eccbf0 SWDEV-554372 - cuda mappings for GetProcAddress API and flags (#1089)
840301e clr: Minor fixes for error return (#2153)
b106e6f Run pre-commit's whitespace related hooks on projects/rocminfo (#2115)
bfb13f2 Run pre-commit's whitespace related hooks on projects/rocm-smi-lib (#2117)
56fd780 Add 'projects/rccl-tests/' from commit '6405c76e6826663bbb67bd40aeee8c70aa5d3...
42d8431 Add 'projects/rccl/' from commit '1f2f9f33bac3e8ecfd84c69af6063d7352c362fc'
1f2f9f3 Update gfx950 tuner conf to include broadcast (#2065)
3fd8a0d [rocprofiler-compute] Remove hip dependency during analysis (#2276)
8f452d2 [rocprof-compute] Update Docs 7.2 + Dual Issue Detection (#2160)
9de72d4 Updated amd-smi.h documentation (#2031)
Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Bumps [rocm-systems](https://github.com/ROCm/rocm-systems) from `a08170b` to `0eccbf0`. - [Release notes](https://github.com/ROCm/rocm-systems/releases) - [Commits](ROCm/rocm-systems@a08170b...0eccbf0) --- updated-dependencies: - dependency-name: rocm-systems dependency-version: 0eccbf0 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>

See ROCm/rocm-systems@0c4d08f

geomin12

looks good assuming CI passes

ScottTodd · 2025-12-12T22:09:08Z

https://github.com/ROCm/TheRock/actions/runs/20178397152?pr=2533

Linux::gfx110X-all::release / Build Artifacts / Build (xfail false)
The self-hosted runner lost communication with the server. Verify the machine is running and has a healthy network connection. Anything in your workflow that terminates the runner process, starves it for CPU/Memory, or blocks its network access can cause this error.

ScottTodd · 2025-12-13T00:15:02Z

CI results are coming in now. Can someone diff against known preexisting failures? (and we still really need to get those resolved so we have clear signal on these routine PRs)

ScottTodd · 2025-12-13T00:30:00Z

MIOpen errors might be new? https://github.com/ROCm/TheRock/actions/runs/20178397152/job/57947116991?pr=2533#step:10:9651

[ RUN ] Full/GPU_SoftMarginLossForward_FP32.Test/31 /__w/TheRock/TheRock/rocm-libraries/projects/miopen/test/gtest/main_hip.cpp:16: Failure Expected equality of these values: hipError Which is: 709 hipSuccess Which is: 0 hipGetLastError returned error code 709 after test Full/GPU_SoftMarginLossForward_FP32.Test/31. Error string: context is destroyed [ FAILED ] Full/GPU_SoftMarginLossForward_FP32.Test/31, where GetParam() = dims:32x80x870 strides:69600x1x80 reduction_mode:2 (224 ms) [ RUN ] Full/GPU_SoftMarginLossForward_FP32.Test/35 /__w/TheRock/TheRock/rocm-libraries/projects/miopen/test/gtest/main_hip.cpp:16: Failure Expected equality of these values: hipError Which is: 709 hipSuccess Which is: 0 hipGetLastError returned error code 709 after test Full/GPU_SoftMarginLossForward_FP32.Test/35. Error string: context is destroyed [ FAILED ] Full/GPU_SoftMarginLossForward_FP32.Test/35, where GetParam() = dims:16x1x512x512 strides:262144x262144x512x1 reduction_mode:2 (126 ms) [ RUN ] Full/GPU_SoftMarginLossForward_FP32.Test/39 /__w/TheRock/TheRock/rocm-libraries/projects/miopen/test/gtest/main_hip.cpp:16: Failure Expected equality of these values: hipError Which is: 709 hipSuccess Which is: 0 hipGetLastError returned error code 709 after test Full/GPU_SoftMarginLossForward_FP32.Test/39. Error string: context is destroyed [ FAILED ] Full/GPU_SoftMarginLossForward_FP32.Test/39, where GetParam() = dims:64x3x80x80 strides:1632000x544000x6800x85 reduction_mode:2 (779 ms) [ RUN ] Full/GPU_SoftMarginLossForward_FP32.Test/43 /__w/TheRock/TheRock/rocm-libraries/projects/miopen/test/gtest/main_hip.cpp:16: Failure Expected equality of these values: hipError Which is: 709 hipSuccess Which is: 0 hipGetLastError returned error code 709 after test Full/GPU_SoftMarginLossForward_FP32.Test/43. Error string: context is destroyed

I don't see those errors on prior runs like https://github.com/ROCm/TheRock/actions/runs/20161420559/job/57887263645 or https://github.com/ROCm/TheRock/actions/runs/20142068252/job/57828277825

Huh? Each of the 4 MIOpen test shards ran the same tests? Is sharding doing anything there?

hm... it should be sharding: Note: This is test shard 2 of 4. based on the logs...

CC'ing @BradPepersAMD for awareness

We added a check at test end to verify that the hipGetLastError is hipSuccess. We did this a while back and things have been working so it seems like either there was a HIP systems change that broke this last error code or something we were doing before that didn't cause an error, is now actually getting caught. The error being that the context has been destroyed is maybe indicating we're now doing something we shouldn't after the context has been destroyed. we'll investigate but it seems odd it was running fine and then failed on a systems update.

best way to test will be to get this env and run the test and see it fail and then run again with MIOPEN_LOG_LEVEL=7 and MIOPEN_ENABLE_LOGGING=1 to see all the hip calls and find what is failing. I can have someone do that tomorrow.

Docs for reproducing:

https://github.com/ROCm/TheRock/blob/main/docs/development/test_environment_reproduction.md

https://github.com/ROCm/TheRock/blob/main/docs/development/test_debugging.md#miopen-debugging (maybe we should switch that to 7 instead of 6?)

Huh? Each of the 4 MIOpen test shards ran the same tests? Is sharding doing anything there?

For this test suite, it's running different test cases from the suite across different shards. You can see here that the test case number at the end of the full test name is different per shard:

miopen_gtest shard 1:

[ FAILED ] Full/GPU_SoftMarginLossForward_FP32.Test/32, where GetParam() = dims:32x80x870 strides:69600x870x1 reduction_mode:2 [ FAILED ] Full/GPU_SoftMarginLossForward_FP32.Test/36, where GetParam() = dims:2x3x160x160 strides:6528000x2176000x13600x85 reduction_mode:2 [ FAILED ] Full/GPU_SoftMarginLossForward_FP32.Test/40, where GetParam() = dims:64x3x40x40 strides:408000x136000x3400x85 reduction_mode:2 [ FAILED ] Full/GPU_SoftMarginLossForward_FP32.Test/44, where GetParam() = dims:56x4 strides:4x1 reduction_mode:2 ...

miopen_gtest shard 2:

[ FAILED ] Full/GPU_SoftMarginLossForward_FP32.Test/33, where GetParam() = dims:4x182403x91 strides:16598673x91x1 reduction_mode:2 [ FAILED ] Full/GPU_SoftMarginLossForward_FP32.Test/37, where GetParam() = dims:2x3x80x80 strides:1632000x544000x6800x85 reduction_mode:2 [ FAILED ] Full/GPU_SoftMarginLossForward_FP32.Test/41, where GetParam() = dims:22311x80 strides:85x1 reduction_mode:2 [ FAILED ] Full/GPU_SoftMarginLossForward_FP32.Test/45, where GetParam() = dims:131x4 strides:4x1 reduction_mode:2 ...

Shard 1 has cases /32, /36, /40, /44, ... and shard 2 has /33, /37, /41, /45, ...

I've tried to reproduce this, but these tests pass on a gfx942 with the environment recreated according to TheRock documentation you linked so we're still investigating.

dependabot · 2025-12-13T10:36:02Z

A newer version of rocm-systems exists, but since this PR has been edited by someone other than Dependabot I haven't updated it. You'll get a PR for the updated version as normal once this PR is merged.

JonathanLichtnerAMD · 2025-12-16T00:12:01Z

@ScottTodd not sure if you noticed but there's also rocwmma test failures that will need to be investigated. I'll get somebody on MIOpen to look at the MIOpen test failures, but we probably want somebody to look into these other failures

ScottTodd · 2025-12-16T00:15:35Z

@ScottTodd not sure if you noticed but there's also rocwmma test failures that will need to be investigated. I'll get somebody on MIOpen to look at the MIOpen test failures, but we probably want somebody to look into these other failures

Oh, you're right. rocWMMA has been consistently failing with timeouts on runs prior to this PR (e.g. https://github.com/ROCm/TheRock/actions/runs/20161420559/job/57887263748), but there are segfaults on this PR that could be new: https://github.com/ROCm/TheRock/actions/runs/20178397152/job/57947116993?pr=2533#step:10:90

hammmmy · 2025-12-16T00:38:10Z

@bsyrowik for rocwmma

bsyrowik · 2025-12-16T02:24:55Z

@bsyrowik for rocwmma

Sorry about the rocWMMA failures -- it is annoying when tests fail sporadically. Geo has opened a case for me to look into this. #2566 should resolve some of the timesouts, but sadly won't help here. In the meantime, I don't think your PR should be gated by the rocwmma test failures.

jayhawk-commits · 2025-12-16T07:45:26Z

Can we narrow down the commit range from rocm-systems where the MIOpen failures occur, using the daily dependabot submodule updates from last week?

Should we consider XFAIL'ing while the investigation occurs?

idass1990 · 2025-12-18T13:26:12Z

Can we narrow down the commit range from rocm-systems where the MIOpen failures occur, using the daily dependabot submodule updates from last week?

Should we consider XFAIL'ing while the investigation occurs?

so far I have narrowed down the commit range from 43 commits to 6 commits.. I've setup additional builds and should have the offending commit isolated within a few hours

idass1990 · 2025-12-18T22:48:56Z

Can we narrow down the commit range from rocm-systems where the MIOpen failures occur, using the daily dependabot submodule updates from last week?
Should we consider XFAIL'ing while the investigation occurs?

so far I have narrowed down the commit range from 43 commits to 6 commits.. I've setup additional builds and should have the offending commit isolated within a few hours

I've concluded the bisect and found this to be the breaking change...
ROCm/rocm-systems@840301e

Failing workflow run on breaking change (840301e): https://github.com/ROCm/TheRock/actions/runs/20347027429
Passing build/test on the commit just prior (b106e6f): https://github.com/ROCm/TheRock/actions/runs/20347312543

jayhawk-commits · 2025-12-18T23:54:54Z

Replaced by #2643 which includes the revert for the MIOpen issues exposed by this PR. Thanks for the effort, everyone.

dependabot · 2025-12-18T23:54:57Z

OK, I won't notify you again about this release, but will get in touch when a new version is available. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.

dependabot Bot added dependencies Pull requests that update a dependency file submodules Pull requests that update submodules code labels Dec 12, 2025

dependabot Bot mentioned this pull request Dec 12, 2025

Bump rocm-systems from a08170b to 256dd19 #2520

Closed

Delete patch that is no longer needed

765aeaa

See ROCm/rocm-systems@0c4d08f

ScottTodd requested review from a team, ScottTodd and marbre as code owners December 12, 2025 20:01

geomin12 approved these changes Dec 12, 2025

View reviewed changes

ScottTodd reviewed Dec 13, 2025

View reviewed changes

ScottTodd mentioned this pull request Dec 15, 2025

Drop VGPR count patch revert #2505

Closed

ScottTodd mentioned this pull request Dec 17, 2025

Enable hip-tests on TheRock #2001

Merged

1 task done

amd-justchen mentioned this pull request Dec 17, 2025

[CI] Skip failed miopen and rocwmma tests in PR2533 #2612

Closed

1 task done

jayhawk-commits mentioned this pull request Dec 18, 2025

clr: Minor fixes for error return ROCm/rocm-systems#2153

Merged

1 task

jayhawk-commits closed this Dec 18, 2025

dependabot Bot deleted the dependabot/submodules/main/rocm-systems-0eccbf0 branch December 18, 2025 23:55

NolanHannaAMD restored the dependabot/submodules/main/rocm-systems-0eccbf0 branch January 8, 2026 06:16

NolanHannaAMD deleted the dependabot/submodules/main/rocm-systems-0eccbf0 branch January 8, 2026 06:18

Conversation

dependabot Bot commented on behalf of github Dec 12, 2025 • edited by ScottTodd Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Additional changes

Uh oh!

geomin12 left a comment

Choose a reason for hiding this comment

Uh oh!

ScottTodd commented Dec 12, 2025

Uh oh!

ScottTodd commented Dec 13, 2025

Uh oh!

ScottTodd Dec 13, 2025

Choose a reason for hiding this comment

Uh oh!

ScottTodd Dec 13, 2025

Choose a reason for hiding this comment

Uh oh!

geomin12 Dec 13, 2025

Choose a reason for hiding this comment

Uh oh!

jayhawk-commits Dec 15, 2025

Choose a reason for hiding this comment

Uh oh!

BradPepersAMD Dec 16, 2025

Choose a reason for hiding this comment

Uh oh!

BradPepersAMD Dec 16, 2025

Choose a reason for hiding this comment

Uh oh!

ScottTodd Dec 16, 2025

Choose a reason for hiding this comment

Uh oh!

DarylHawkinsAMD Dec 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dependabot Bot commented on behalf of github Dec 13, 2025

Uh oh!

JonathanLichtnerAMD commented Dec 16, 2025

Uh oh!

ScottTodd commented Dec 16, 2025

Uh oh!

hammmmy commented Dec 16, 2025

Uh oh!

bsyrowik commented Dec 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jayhawk-commits commented Dec 16, 2025

Uh oh!

idass1990 commented Dec 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

idass1990 commented Dec 18, 2025

Uh oh!

jayhawk-commits commented Dec 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dependabot Bot commented on behalf of github Dec 18, 2025

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

dependabot Bot commented on behalf of github Dec 12, 2025 •

edited by ScottTodd

Loading

DarylHawkinsAMD Dec 16, 2025 •

edited

Loading

bsyrowik commented Dec 16, 2025 •

edited

Loading

idass1990 commented Dec 18, 2025 •

edited

Loading

jayhawk-commits commented Dec 18, 2025 •

edited

Loading