Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   bugzilla-daemon@kernel.org
To:     linux-ext4@vger.kernel.org
Subject: [Bug 216322] Freezing of tasks failed after 60.004 seconds (1 tasks
 refusing to freeze... task:fstrim  ext4_trim_fs - Dell XPS 13 9310
Date:   Tue, 09 Aug 2022 13:40:36 +0000
Message-ID: <bug-216322-13602-rmOCrl6vUG@https.bugzilla.kernel.org/>
In-Reply-To: <bug-216322-13602@https.bugzilla.kernel.org/>
References: <bug-216322-13602@https.bugzilla.kernel.org/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Auto-Submitted: auto-generated
MIME-Version: 1.0
Precedence: bulk

https://bugzilla.kernel.org/show_bug.cgi?id=3D216322

--- Comment #6 from Len Brown (lenb@kernel.org) ---
Is there an simple recipe to reproduce this failure?

Note that upon this 60-second timeout, the kernel aborts the suspend
and un-freezes user-space.  Well, what is running in user space
is the sleepgraph program with --multi, which saves the record
of the failure and immediately provokes the next suspend -- which works.

Did the act of unfreezing user-space result in progress,
or were we just lucky that the operation completed before the
subsequent suspend request?

Note that Rafael thought that the kernel timeout was 20 seconds,
not 60 seconds, and he's inclined to make it shorter, not longer.
(are we sure that this process is actually making progress,
 and not in some kind of deadlock that would persist no matter
 now long the timeout?)

--=20
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.=