From 41f3ffaeeaee488f22b4cd4b5b503bf5c3470c45 Mon Sep 17 00:00:00 2001
From: Erlang/OTP <otp@erlang.org>
Date: Thu, 21 Mar 2019 16:46:47 +0100
Subject: Prepare release

---
 erts/doc/src/notes.xml | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

(limited to 'erts/doc')

diff --git a/erts/doc/src/notes.xml b/erts/doc/src/notes.xml
index 5c45f8d83b..9e5afd57a2 100644
--- a/erts/doc/src/notes.xml
+++ b/erts/doc/src/notes.xml
@@ -31,6 +31,38 @@
   </header>
   <p>This document describes the changes made to the ERTS application.</p>
 
+<section><title>Erts 10.3.1</title>
+
+    <section><title>Fixed Bugs and Malfunctions</title>
+      <list>
+        <item>
+	    <p>If a suspend/resume signal pair was sent to a process
+	    while it was executing dirty, the receiving process could
+	    later end up in a suspended state indefinitely. This bug
+	    was introduced in ERTS version 10.0 (OTP 21.0).</p>
+	    <p>Suspend/resume signals are sent from <seealso
+	    marker="erts:erlang#suspend_process/1"><c>erlang:suspend_process()</c></seealso>/<seealso
+	    marker="erts:erlang#resume_process/1"><c>erlang:resume_process()</c></seealso>.
+	    The <seealso
+	    marker="runtime_tools:dbg"><c>dbg</c></seealso> trace
+	    tool utilize this functionality and could thus trigger
+	    this bug.</p>
+          <p>
+	    Own Id: OTP-15688</p>
+        </item>
+        <item>
+          <p>
+	    Fix a possible deadlock when terminating the ERTS caused
+	    by a dirty scheduler not releasing it's run-queue lock
+	    when terminating.</p>
+          <p>
+	    Own Id: OTP-15690 Aux Id: PR-2172 </p>
+        </item>
+      </list>
+    </section>
+
+</section>
+
 <section><title>Erts 10.3</title>
 
     <section><title>Fixed Bugs and Malfunctions</title>
-- 
cgit v1.2.3