From nobody Fri Dec 20 17:10:08 2024 X-Original-To: freebsd-arm@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 4YFDS52tDyz5X0rR for ; Fri, 20 Dec 2024 17:09:57 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (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 (2048 bits) client-digest SHA256) (Client CN "generic", Issuer "generic" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YFDS35MWsz470q for ; Fri, 20 Dec 2024 17:09:55 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net; dmarc=none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 4BKHA9ve092870 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 20 Dec 2024 09:10:09 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 4BKHA8Qi092869; Fri, 20 Dec 2024 09:10:08 -0800 (PST) (envelope-from fbsd) Date: Fri, 20 Dec 2024 09:10:08 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Cc: bob prohaska Subject: armv7, silent hang, low swap, high priorities Message-ID: List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spamd-Result: default: False [-1.10 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_WWW(0.50)[]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; DMARC_NA(0.00)[zefox.net]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; R_SPF_NA(0.00)[no SPF record]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_DKIM_NA(0.00)[]; TO_DN_SOME(0.00)[] X-Rspamd-Queue-Id: 4YFDS35MWsz470q X-Spamd-Bar: - An old (v 1.1) Pi2 running armv7 -current often hangs during buildworld. It doesn't respond to enter-tilda-control-B and has to be powercycled. Once rebooted, buildworld can be restarted and makes further progress, sometimes to completion. Swap was configured in two partitions, one on microSD and one on mechanical hard disk, thus both over-provisioned and wildly unequal in speed. Root is on the mechanical disk. An orphan top window surprised me by reporting very high priorities in the 130 range but swap usage was relatively low, less than 100MB. That seemed an odd combination. Usually priorities that high are associated with severe memory pressure. Could the mismatched swap speeds have confused the scheduler? There were no console warnings. The machine was fully loaded with a -j4 buildworld, so the fact of the hang isn't hugely surprising. The top display, at http://www.zefox.net/~fbsd/rpi2/crashes/20241219/top_display seemed internally inconsitent. Does it surprise anybody else? I've since removed the microSD swap, leaving only the mechanical disk swap, to see if that changes the hang behavior. Thanks for reading, bob prohaska