From nobody Thu Jun 11 18:57:07 2026 X-Original-To: freebsd-current@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 4gbsMc30r1z6j4pB for ; Thu, 11 Jun 2026 18:57:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-20.consmr.mail.gq1.yahoo.com (sonic317-20.consmr.mail.gq1.yahoo.com [98.137.66.146]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4gbsMb6Rc5z3KpX for ; Thu, 11 Jun 2026 18:57:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1781204232; bh=kxhqbrhZIEhZqu/Z+cvPv95v6J9aot8WEAfv9V42As0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From:Subject:Reply-To; b=cV7JRmWVhql74R00prHyYjlH4OiS/L20ORhrEMPDkyjpQ6mBtsSO2Bx9m/OxyEN0NVofNjoFRUzS2yB7M2EVvjdShUxyiHiYly2XlbbrGPkwsVx+xgHbSbvj+xiV83R1QyY5/dbnnpyWdWJeythLaHq+yzilF8FpwfKDVy/LPCBaDH0SeYrA712LBc94H5Ndg2ymdt3WTXEIuusDRH+COzoY7MIFZttS9DvOUz/D9YuaiBfrY9tpcNjCR5Wdfe9XSnHzvIk0yO0ooTDJZADdND49n0qmMShDl8oNS8vUVQXvhUstXFzD9qRxXPP09Jcay9Vy98u+D1eyXuGEsi6FKg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1781204232; bh=icOOhgdtUQR4EeudeMDbszNNRQ2pvHzI8Vm15H8C3bZ=; h=X-Sonic-MF:Date:Subject:To:From:From:Subject; b=lK9FS+4y7jU/fNl9LUVrBod+MXyhTp6PB/9t9WmG8FcHTxbuZ6U2fkNGHikcUvgSq+KQMYov8rx18ZjYO2NeE9EzaD3Cc2kFPxgDOCBVW84eRKh15PeIvZMA5OBpS/iM8g4rTx+jU7T+LQCE/XsdiaGizUpgsiQ8KG0iIhaizFZbn0wlxoMcSB0rSxEOwqjUm1M92FxjnoL6koVuYBj1zZFyuY8Umth89J35B3g4DE4rzGv018MNSLbZi7tSVRSq6B/BVT2gGqWRNSU2olqRAbmgii+Hro6xB3pARfujpksjlkMrMQywOssnjSOFmqYwKP7nsgLc0uBmcB+DKGf6cQ== X-YMail-OSG: ocXFQAcVM1lietJBxVAcH6yW9.e.uXBiaelXKsXXwAGrSvlc9ztWADEG6VxV7C7 HET.eFQ.ZhgsZz9W4wTEynkmYAhDhELry1F3oZGWJvOUa_fu.4GhbxCZIkqwg8Khh6oqO6ArqICq UYPWyysLu3aaFLrfa3atOWSOyWsnaimVwoiLcOLo.qycyoarubOJWmNJ7b8scg_8UDX7ziO63J1R Xh96CWbHuCkVzWTB8XtRqY2pg5cSVXTF9aRJ.gGIjy_MVEHDaUgptk24CKNV8Ph4DWIsZLqD6Z2d ERQltFxCpflpLQ9AABbWA2a6VqwS9dswnAsNUQkpgBi1qza1V7H81sV2_p17bZt2LoiTGXsKSbDq GtNlJCp4voPZDXqZG4hLE4HZJ3uFqznN3QH4Du3bd83EdQ7Iiiyudk5CGQieJOBBwv85fCQNTZbq _FKvl3XZ1Ml0J9SVV7QCX1REoaG5IBOAZIHCwBSLc75ywpadfytLui5mpITIwMyslNTMGj70AM94 nDhds.nxmT2h_gZYtYVoc7k_56WEjmwRJvblWXZkIcX35Cxj7ng2A5UV2JBZ7q9l5BJwvtmTi398 Veiu7Ts9Eg1.NXZLHM.31Huhn0eL1nZePACdVHO6OAcSe2AmT8UPjql8cx846Uz12QUw3Ihz.xZT t1WQc3GjuYPH8LSpBmGzPBQiozisBY.QbPigiwNadgvR_YjOV30ApscnGNJtTHfyrXHWzsn5wZCQ 8hlXgACKtiOEeSbv9Q1PW_ffRhOBofG32oeKk5Sgl0.i4dYucopMaE7XA7QZ_qiR15NpVAxd1o6Z e17qgXer61YeyEk34pqBGMYrHBTpYu3nOy4HxRsUGCp.YXVrInO7U7AHRwRmP0ZGaLVsjgy9s535 ivlLGJ8cFMPEuYXGItnlpijRC.LyPK0vnniSqj.5WxIaLLTJoE9_kazxI.i6L89aXHy3oOR0OFnD VPMkBu5yZwKWnDfFHEjNvlCMEHxG2Xc0.D_Cu5JR1nFn6YRhqmc.J1ho1DTgpbfGY8up5S9ChTn7 cyqi377KhGUeZ67rosglxcHEoKIhccr4vDwnIhEGcfh8cnYcPbgULQsriBFlennvuoRbnlm04k96 WB_wl7zqQVRDFN14BBteUZhOO1xyD.XAApiLgXtSTrnBukp3lXNMEYMTimeR5ORp3.Ci6MJOAa6D pwjho9pAElb0NeIUbd6IMkNJtr4YG8CSX3LZECC3E3FDJ0GvVYJ_gwN9kmT7QjVdjv9EV0CzVtm0 MJKnp0XtfZm_KNz9cguBEXv0SA1VPDvbwVLWc0WmdHihcPveoQRGyvn7TUvD1yBBxMP7zdzsh7si bPaEuxMq8_UWgdThx5mceBpi5rdrToG6yXtlkrjoUKQrYecC86qxHupkVxrWPzWzei.iDgx_oHcV GFg_9GGC_WmQzbCZO8IJEpSZt6KPWAcOjYuLMLSjoEntzdGVrvPc10qkiKDddPz1HwUPgSo_7PBd L6OodxG3EHj42pDpGVbnrNbgw_bAxTYy_nXqa2Y2RqJSNOUJSG3hpu.cH47kKTAPjqpqAqJBYK3u GK1vd7O.243ckRLqmBDzqwkGEEhgBXi5221ELljxxSu5s3HFfUSqteNWBULlt7O7WAVspPHbDVix vTn04p36a3dmUwcfHUyLBbqpfGsLicUMQ2_hMTnvTQnlNCrZkyIFRu5Nc3jcWKSIPmjmnMjHYUSd ZpkNg3Gvu_N90pTmf54OYIEoQek8JmDKDHcCkuVg8_qxBDRziYIJI8WNy8rQB1sPjVgDUq880CcC WGdDHfWl_mVKxjqYzYu5JoDwlm15FyMg5zJQOUWAmSVkHVHqSKysEZm8sWiTPJk3cP3qkET2JqSm E3J.bvi_LxncGEEY_6NiQSpcbR.3tJfyyJBqOB.oliwtPrjkV4wn_yg5KvvhwsvkbzbE1TOKl4B0 sP90NM.1siOb6v4v3GA1OM4euExOeoXAohC2ZTdK28JeFHbOc52H1yCcQy1B9LYmzxGmmIF0kCGi XDRfqqmCMt3WgnFoDRQontJz29sg8mUTJ1AaHihA7oLDNPBF8QGV9gAfcuHHqr9kOYtnwtLKD.4O UokVF3Pga0IPXQ_WKDYIAc84Y80v_PgZ2Bh82aGjRcwDJi4HNJMrOJKN0KjFKTAfGh1U_7XjtvWx r.jh59gMbJKTMT9D7m81uWAflOvmGJQG9axhBs9.JnOqAZUnqwWNunLtDygFTqofOZ_kanQBdBlX PxsVTgml_iECjZ2cPUjKO9yiSG7IL0Y3_B0l8O2hjAVuuOny79Pp_zNqY0rjhHSgXpqJzCFN0mP9 lTw7LoslU9Ln9g5qbhBkQv8pO5lQDbSeLNDNQjjRLP_O0XuEX X-Sonic-MF: X-Sonic-ID: 0bca7e6e-fb03-4036-ae97-c1a825cf60be Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Thu, 11 Jun 2026 18:57:12 +0000 Received: by hermes--production-gq1-7bb7df5c46-qkl2h (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b7d123f394d6a83a11b5ff005468afe8; Thu, 11 Jun 2026 18:57:08 +0000 (UTC) Message-ID: Date: Thu, 11 Jun 2026 11:57:07 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Buildworld finishes despite swap exhaustion To: bob prohaska Cc: freebsd-current@freebsd.org References: <040df279-5f61-4f4f-ae4a-79bd44797b53@yahoo.com> Content-Language: en-US From: Mark Millard In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.25942 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4gbsMb6Rc5z3KpX X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated On 6/11/26 08:51, bob prohaska wrote: > On Tue, Jun 09, 2026 at 08:22:02AM -0700, Mark Millard wrote: >> On 6/8/26 20:48, bob prohaska wrote: >>> Lately a Pi2B running buildworld reported an >>> exhaustion of swap, but buildworld kept running >>> and seemingly finished successfully. >>> >>> The report came on the serial console, I didn't >>> find anything in the buildworld log. >>> >>> This seems a very great improvement. Swap exhaustion >>> differs from other sorts of failure, in that one can >>> simply re-try the job with some hope of success when >>> the workload is lighter. >>> >>> Am I interpreting this correctly? >> >> [Because the actual messages are not reported, I'm making some >> assumptions about the exact messages that you got.] >> >> >> Remember vm.pageout_oom_seq ? >> > > Yes, /boot/loader.conf contains: > vm.pageout_oom_seq="4096" > vm.pfault_oom_attempts="3" > #vm.pfault_oom_attempts="120" > vm.pfault_oom_wait="20" > > I'll admit to not remembering how 4096 was chosen.... > probably just a wild guess. > >> The larger that value used, the longer the system operates with the >> amount of free RAM below the target threshold: in other words, it makes >> more tries at getting to the threshold before giving up and starting to >> kill processes to get the free RAM. >> >> Running out of swap of itself just means that SWAP can not be used to >> gain free RAM when such is not essential. RAM+SWAP can still be >> (marginally) sufficient over such a time if no memory allocations >> actually fail. If sufficient RAM/SWAP ends up being freed before >> vm.pageout_oom_seq related kills happen, no overall failure happens. >> >> >> As for the messages as I understand them: >> >> kernel: swap_pager: out of swap space >> >> does not report a failure, just a limiting condition. >> >> By contrast: >> >> kernel: swp_pager_getswapspace(2): failed >> >> reports a failure: the swap space allocation was necessary. It normally >> nleads to the likes of: >> >> kernel: pid ??? (???), jid ???, uid ???, was killed: failed to reclaim >> memory > > A more recent incident reported in /var/log/messages: > > Jun 4 12:34:39 www kernel: swap_pager: out of swap space > Jun 4 12:34:39 www kernel: swp_pager_getswapspace(12): failed > > but wasn't followed by a "...was killed..." message. Interesting. I've not had that combination as far as I know. Now I know it is possible. Thanks. > > Eventually there appeared what look like repeated disk errors, ending with: > > Jun 11 02:04:59 www kernel: (da0:umass-sim0:0:0:0): Info: 0 > Jun 11 02:04:59 www kernel: (da0:umass-sim0:0:0:0): Retrying command (per sense > data) > Jun 11 02:04:59 www kernel: (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 04 63 3 > 4 50 00 00 18 00 > Jun 11 02:04:59 www kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Erro > r > Jun 11 02:04:59 www kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition > Jun 11 02:04:59 www kernel: (da0:umass-sim0:0:0:0): SCSI sense: MEDIUM ERROR asc > :10,0 (ID CRC or ECC error) The above looks like reporting of a drive problem. Getting to be time for a replacement? > Jun 11 02:04:59 www kernel: (da0:umass-sim0:0:0:0): Info: 0 > Jun 11 02:04:59 www kernel: (da0:umass-sim0:0:0:0): Retrying command (per sense data) > > which ended in a debugger prompt on the console. > > There was considerable network > activity around the same time > which resembled an ssh attack. I'd guess that such was not likely to contribute to a false "MEDIUM ERROR" with "(ID CRC or ECC error)". > > The machine rebooted without incident, buildworld has been resumed with -j3. > > If it happens again I'll save a backtrace if it'll be of interest. > -- === Mark Millard marklmi at yahoo.com