diff --git a/lldb/test/API/functionalities/unwind/cortex-m-exception/TestCortexMExceptionUnwind.py b/lldb/test/API/functionalities/unwind/cortex-m-exception/TestCortexMExceptionUnwind.py
index 267f8c805f360..30b2a525eaab1 100644
--- a/lldb/test/API/functionalities/unwind/cortex-m-exception/TestCortexMExceptionUnwind.py
+++ b/lldb/test/API/functionalities/unwind/cortex-m-exception/TestCortexMExceptionUnwind.py
@@ -12,7 +12,24 @@
 class TestCortexMExceptionUnwind(TestBase):
     NO_DEBUG_INFO_TESTCASE = True
 
-    @skipUnlessDarwin  # on the lldb-remote-linux-ubuntu CI, only get 1 stack frame not 6
+    # on the lldb-remote-linux-ubuntu CI, the binary.json's triple of
+    # armv7m-apple is not being set in the Target triple, and we're
+    # picking the wrong ABI plugin, ABISysV_arm.
+    # ABISysV_arm::CreateDefaultUnwindPlan() doesn't have a way to detect
+    # arm/thumb for a stack frame, or even the Target's triple for a
+    # Cortex-M part that is always thumb.  It hardcodes r11 as the frame
+    # pointer register, which is correct for arm code but not thumb.
+    # It is never correct # on a Cortex-M target.
+    # The Darwin ABIMacOSX_arm diverges from AAPCS and always uses r7 for
+    # the frame pointer -- the thumb convention -- whether executing arm or
+    # thumb.  So its CreateDefaultUnwindPlan picks the correct register for
+    # the frame pointer, and we can walk the stack.
+    # ABISysV_arm::CreateDefaultUnwindPlan will only get one frame and
+    # not be able to continue.
+    #
+    # This may only be occuring on a 32-bit Ubuntu bot; need to test
+    # 64-bit Ubuntu and confirm.
+    @skipUnlessDarwin
     def test_no_fpu(self):
         """Test that we can backtrace correctly through an ARM Cortex-M Exception return stack"""