diff --git a/criu/seize.c b/criu/seize.c
index 9bd1832d9b..c9d23365d4 100644
--- a/criu/seize.c
+++ b/criu/seize.c
@@ -542,7 +542,7 @@ static int freeze_processes(void)
 	enum freezer_state state = THAWED;
 
 	static const unsigned long step_ms = 100;
-	unsigned long nr_attempts = (opts.timeout * 1000000) / step_ms;
+	unsigned long nr_attempts = (opts.timeout * 1000) / step_ms;
 	unsigned long i = 0;
 
 	const struct timespec req = {
@@ -555,7 +555,7 @@ static int freeze_processes(void)
 		 * If timeout is turned off, lets
 		 * wait for at least 10 seconds.
 		 */
-		nr_attempts = (10 * 1000000) / step_ms;
+		nr_attempts = (10 * 1000) / step_ms;
 	}
 
 	pr_debug("freezing processes: %lu attempts with %lu ms steps\n", nr_attempts, step_ms);
@@ -594,9 +594,39 @@ static int freeze_processes(void)
 
 			if (state == FROZEN)
 				break;
-			if (alarm_timeouted())
+			if (alarm_timeouted()) {
+				pr_err("Unable to freeze cgroup %s (timed out)\n", opts.freeze_cgroup);
 				goto err;
+			}
 			nanosleep(&req, NULL);
+
+			if (cgroup_v2)
+				continue;
+
+			/* As per older kernel docs (freezer-subsystem.txt before
+			 * the kernel commit ef9fe980c6fcc1821), if FREEZING is seen,
+			 * userspace should either retry or thaw. While current
+			 * kernel cgroup v1 docs no longer mention a need to retry,
+			 * even recent kernels can't reliably freeze a cgroup v1.
+			 *
+			 * Let's keep asking the kernel to freeze from time to time.
+			 * In addition, do occasional thaw/sleep/freeze.
+			 *
+			 * This is still a game of chances (the real fix belongs to the kernel)
+			 * but these kludges might improve the probability of success.
+			 *
+			 * Cgroup v2 does not have this problem.
+			 */
+			switch (i%32) {
+				case 30:
+					freezer_write_state(fd, THAWED);
+					break;
+				case 9:
+				case 20:
+				case 31:
+					freezer_write_state(fd, FROZEN);
+					break;
+			}
 		}
 
 		if (i > nr_attempts) {