From nobody Fri Jul 23 18:48:16 2021 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 367DA12B03A1 for ; Fri, 23 Jul 2021 18:48:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GWdcc0dbHz4VG2 for ; Fri, 23 Jul 2021 18:48:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id E7FE12A090 for ; Fri, 23 Jul 2021 18:48:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 16NImFGW006567 for ; Fri, 23 Jul 2021 18:48:15 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 16NImFwt006566 for bugs@FreeBSD.org; Fri, 23 Jul 2021 18:48:15 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 257314] FBSD 13 crash after some KDE parts crash supposing out of swap space Date: Fri, 23 Jul 2021 18:48:16 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257314 --- Comment #14 from Mark Millard --- (In reply to Michael from comment #11) What I've been told in the past about each message like: swap_pager: indefinite wait buffer: bufobj: ???, blkno: ???, size: ??? is "It took more than 30s for the IO to complete." Also: "The swap pager is complaining. It is used for things other than pure swapping to a swap partition...". (Both are from Warner L.) (It is not certain that the kill is driven by those messages.) Was your top output from before the: pid 1954 (gimp-2.10), jid 0, uid 1000, was killed: out of swap space showed up? Or after? After need not reflect the failing conditions that drive the kill any more. You might have to record the sequence of top outputs over the time frame and look back before various outputs from before the message. Since this happened with: vm.pfault_oom_attempts=3D-1 one thing I know to do to investigate is to use a kernel that produces messages similar to what my builds would produce so we know exactly which of the 4 conditions happened for sure. (I wish such was standard in FreeBSD.) Another might be to be watching or recording gstat -spod output over the time frame to get a better handle on what the I/O is like. (If the "indefinite wait buffer" status is driving the kills, anyway.) I will say that, even if "indefinite wait buffer" is not driving the kills, if your I/O system takes that long to do the I/O that of itself could be considered a significant usability problem. --=20 You are receiving this mail because: You are the assignee for the bug.=