-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Linux/arm64] Test Failed: System.Threading.Tests.InterlockedTests.MemoryBarrierProcessWide Failure #11177
Comments
This is most likely caused by |
@kouvel (?) do you expect to have time to work on this relatively soon? If not can you please disable the test in CoreFX for ARM... |
- Temporarily disabling on arm64 due to https://github.com/dotnet/coreclr/issues/20215 - The issue may exist on other architectures, but we have only seen failures on arm64 so far
* Disable failing test InterlockedTests.MemoryBarrierProcessWide - Temporarily disabling on arm64 due to https://github.com/dotnet/coreclr/issues/20215 - The issue may exist on other architectures, but we have only seen failures on arm64 so far * Move property to PlatformDetection * Fix
The issue was marked as fixed in dotnet/coreclr#20949. |
* Enable test for MemoryBarrierProcessWide on ARM64 since corresponding bug is closed. Re:https://github.com/dotnet/coreclr/issues/20215
Same test Message :
Stack Trace :
|
When fixed please un-disable test in linked https://github.com/dotnet/corefx/issues/38400 |
This requires Linux kernel 4.14 or later to run. |
Our lab machines need to be updated to have this version of Linux kernel before we can enable this test. |
Just to mention - the test is actually enabled. It is only disabled for the Linux/ARM64 config. |
Test System.Threading.Tests.InterlockedTests/MemoryBarrierProcessWide failed again in: message:
Stack Trace:
|
Same test failed in pipeline coreclr-corefx-jitstressregs Log:
|
Apologies for the hijack, but can anyone on this thread help me to identify the kernel patches in 4.14 that are required for resolving at least this issue? I am developing a .NET core 3.0 app on ARM64 kernel 4.9. It will be a while before my device can update to 4.14; but backports of specific patch sets may be an option for me. After reviewing the 4.14 changelog I don’t see any obvious ARM64 patches that point to this issue. I would appreciate any advice that can be offered. |
@gkarabin the change was not ARM64 specific. See the related commit here: torvalds/linux@22e4ebb |
Thanks! I appreciate the pointer. |
failed again in job: runtime 20200506.84 failed test: System.Threading.Tests.InterlockedTests.MemoryBarrierProcessWide Error message Stack trace |
This should no longer be failing. |
@VSadov This is failing in our CI in every run. So if the reason is an "outdated" Linux kernel, that doesn't really matter, if our CI machines are running such a kernel. |
I thought the runs use new enough kernel now. It looked so from the logs. |
Reverting- #35974 |
Was the failure actually on Linux? |
Ah, right, looks like Windows: net5.0-Windows_NT-Release-arm64-CoreCLR_release-Windows.10.Arm64.Open |
Are other failures on Windows too? |
Here's another failure, on mono: net5.0-Windows_NT-Release-x64-Mono_release-Windows.81.Amd64.Open |
The arm64 one: net5.0-Windows_NT-Release-arm64-CoreCLR_release-Windows.10.Arm64.Open I take back what I said: it doesn't look like the failure is consistent in every run: it has failed on different platforms/architectures. |
Wow, I really need some coffee or something -- those links I gave are for a whole separate test failure :-( |
However, the issue opened by v-haren is this test, for Windows arm64. |
Yes, the original failure is real, and on Win10, which is a concern |
I wonder if there are more failures to see if there is some pattern. |
Ok, looking at the Kusto data, this test failed only twice in the last 30 days, both on Windows arm64, both this morning. |
@VSadov I've been working to enable JIT stress testing of libraries test assets with checked CoreCLR. This means many, many more runs of the tests, with various stress modes, and also with a checked CoreCLR (which probably changes the timing compared to most runs). I've seen this failure several times. Multiple times last night for Windows arm64:
I'm going to disable this test for JIT stress modes, for now. |
I have an open PR to re-disable the test - #35974 There is clearly an issue. Now on Windows... |
@BruceForstall I have reverted the change that enabled this test |
This just failed in Linux arm (JitStress=2, JitStressRegs=3):
@VSadov Looks like you only disabled it for arm64, not for arm32. |
@BruceForstall - the failure was on Windows ARM64. This is something new. Is there only one hit? |
@VSadov I've only seen one failure of this Linux arm32 case. However, I don't trust the Kusto data because it looks to me like the scripts to upload failures from Linux arm32 to Kusto have been broken. |
@BruceForstall - looked at the test again. I think there is a memory ordering issue in the test code. |
I think this was fixed in #39668 |
This took me a while to reproduce - but I got at least five exact failures.
The text was updated successfully, but these errors were encountered: