diff --git a/scst/README b/scst/README
index 4e1b7f644..a5d14625b 100644
--- a/scst/README
+++ b/scst/README
@@ -2202,6 +2202,31 @@ transfers. As the result, those threads won't receive all the processing
 power of those CPUs and perform worse.
 
 
+Commands suspending takes too long
+----------------------------------
+
+SCST is suspending commands during some management activities like
+adding/deleting LUNs or devices. It is done to have lockless LUNs
+translation on the hot commands processing path. This brings significant
+performance advantage. You will see a message like "Waiting for X active
+commands to complete" when this wait started.
+
+But downside of it is that no new commands start executing until older
+ones, which had started before the suspending begun, finished. This
+wait can not be any longer, than the worst command latency any your
+initiator is seeing at this particular time.
+
+So, if this wait takes too long, in majority of cases it means that you
+are overloading your storage. A proper storage should have worst case
+latency below few hundreds of milliseconds. In this case the SCST
+suspending will finish in few hundreds of milliseconds at worse.
+
+Another case, when it can take too long to suspend is a hung user space
+device (i.e. scst_user device) not responding to any command. In this
+case you should kill the corresponding user space program to finish
+suspending.
+
+
 Work if target's backstorage or link is too slow
 ------------------------------------------------
 
diff --git a/scst/README_in-tree b/scst/README_in-tree
index 9b71342de..386eb7c73 100644
--- a/scst/README_in-tree
+++ b/scst/README_in-tree
@@ -1681,6 +1681,31 @@ transfers. As the result, those threads won't receive all the processing
 power of those CPUs and perform worse.
 
 
+Commands suspending takes too long
+----------------------------------
+
+SCST is suspending commands during some management activities like
+adding/deleting LUNs or devices. It is done to have lockless LUNs
+translation on the hot commands processing path. This brings significant
+performance advantage. You will see a message like "Waiting for X active
+commands to complete" when this wait started.
+
+But downside of it is that no new commands start executing until older
+ones, which had started before the suspending begun, finished. This
+wait can not be any longer, than the worst command latency any your
+initiator is seeing at this particular time.
+
+So, if this wait takes too long, in majority of cases it means that you
+are overloading your storage. A proper storage should have worst case
+latency below few hundreds of milliseconds. In this case the SCST
+suspending will finish in few hundreds of milliseconds at worse.
+
+Another case, when it can take too long to suspend is a hung user space
+device (i.e. scst_user device) not responding to any command. In this
+case you should kill the corresponding user space program to finish
+suspending.
+
+
 Work if target's backstorage or link is too slow
 ------------------------------------------------
 
diff --git a/scst/src/scst_main.c b/scst/src/scst_main.c
index 3992b2d50..216a9c1b8 100644
--- a/scst/src/scst_main.c
+++ b/scst/src/scst_main.c
@@ -894,6 +894,8 @@ static int scst_susp_wait(unsigned long timeout)
 		goto out;
 
 	if (res == 0) {
+		PRINT_INFO("%d active commands to still not completed. See "
+			"README for possible reasons.", scst_get_cmd_counter());
 		scst_trace_cmds(scst_to_syslog, &hp);
 		scst_trace_mcmds(scst_to_syslog, &hp);
 	}
@@ -975,15 +977,8 @@ int scst_suspend_activity(unsigned long timeout)
 	 */
 
 	if (scst_get_cmd_counter() != 0) {
-		PRINT_INFO("Waiting for %d active commands to complete... This "
-			"might take few minutes for disks or few hours for "
-			"tapes, if you use long executed commands, like "
-			"REWIND or FORMAT. In case, if you have a hung user "
-			"space device (i.e. made using scst_user module) not "
-			"responding to any commands, if might take virtually "
-			"forever until the corresponding user space "
-			"program recovers and starts responding or gets "
-			"killed.", scst_get_cmd_counter());
+		PRINT_INFO("Waiting for %d active commands to complete...",
+			scst_get_cmd_counter());
 		rep = true;
 
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 29)