From nobody Sat Feb 11 22:40:57 2023 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 4PDltb3B6xz3qZwT for ; Sat, 11 Feb 2023 22:40:39 +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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PDltZ1xpBz3mCK for ; Sat, 11 Feb 2023 22:40:38 +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.16.1/8.15.2) with ESMTPS id 31BMewkC018048 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sat, 11 Feb 2023 14:40:58 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 31BMevtQ018047 for freebsd-arm@freebsd.org; Sat, 11 Feb 2023 14:40:57 -0800 (PST) (envelope-from fbsd) Date: Sat, 11 Feb 2023 14:40:57 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: fsck segfaults on rpi3 running 13-stable Message-ID: <20230211224057.GA17805@www.zefox.net> 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]; NEURAL_HAM_LONG(-1.00)[-1.000]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[zefox.net]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PDltZ1xpBz3mCK X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N While running buildworld on a Pi3 running 13-stable the machine panic'd. On restart using the previous kernel fsck failed with a segfault, which repeated when the disk was moved to a -current Pi3. In single user mode on -current the segfault message is .... 7912408300994173476 BAD I=74682090 4313599915630302063 BAD I=74682090 -4473632163892877928 BAD I=74682090 8068741989830080453 BAD I=74682090 3857159125896022134 BAD I=74682090 -4354179704011695453 BAD I=74682090 7611175298055105740 BAD I=74682090 3985638883347136889 BAD I=74682090 -2495754894521232470 BAD I=74682090 7739654885841380823 BAD I=74682090 INODE CHECK-HASH FAILED I=74999808 OWNER=1842251117 MODE=15044 fsck: /dev/da1s2d: Segmentation fault I gather this like unlikely to be recoverable, but it would be nice to understand what went wrong if possible. Thanks for reading, bob prohaska From nobody Sun Feb 12 00:04:40 2023 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 4PDnlX5HGXz3rG5T for ; Sun, 12 Feb 2023 00:04:40 +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 4PDnlX3Dr6z3tmt for ; Sun, 12 Feb 2023 00:04:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1676160280; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jM/scILwvuPd5PnQBpbT+JvH66vlx/aJIDYA4P/e7HU=; b=KEUiXFQcv6tlvoIMczhrUTbND/WPqip5MjHODA0Aup/LfFPYLKgop6ROGIQvQwa/sfgrBl lhTz7FEclgjb3sEJVjK8UoGn+IjByx5JIlRF4RgEb5eX5kdu50wrEgI1fhhB6LJ4IjUzzY fXqyIrrRSUgZABHIkVzovVoOMKBNU+Hm/n4F83EW0kCqyiZi82J8WSoPt2yF8PBRZ+NPLr cVXcKYo9ludwPbQJuStdgXpzW4/zIzVuRDIrLTxSmU3i62gtcVVGydl3P6WVp1GSXiJI5Z st7ekKCjykafndE1qhoRK++49dpT24V8HVWBejI8PiNhfIF0c6YoX90WIii3zw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1676160280; a=rsa-sha256; cv=none; b=viuS0icn/myq44UonsqaGH7s1/Qs9iwSQHq1nJUbCLGQccvlpHOvBeJ2S3s9tupsgLobJS 4EfdSxR7KXBhQfMwIHoGRgYoDWgQN7RI/OpxkpWIkDsB9df7zkOpHLlP6AcwuUlAY7QRIN NzhIP3WzoDA+/iiRQtyEQcFe9HgxuUKiDg3T53WRJZC+l6VF1D5rOrlm4u5tSP0CzEEseF KsQgw0n7ACc/xxrOAR4djrMI7fw/wJ0z7edmNv0CYlrBRXfvtYAorcGeuzQN+hfoeMgrt/ mee59xjzt3LVnvBIAKRbY7P2zkDUlb22WppTjJ2uhXoufRq5nF+h5z6bKoYLfw== 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 4PDnlX2JP5zJGk for ; Sun, 12 Feb 2023 00:04:40 +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 31C04enI086949 for ; Sun, 12 Feb 2023 00:04:40 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 31C04eqT086948 for freebsd-arm@FreeBSD.org; Sun, 12 Feb 2023 00:04:40 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: freebsd-arm@FreeBSD.org Subject: [Bug 269487] 13.2-PRERELEASE csh dumps core Date: Sun, 12 Feb 2023 00:04:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 13.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: joerg@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status 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: 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 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D269487 Joerg Wunsch changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |Not A Bug Status|New |Closed --- Comment #7 from Joerg Wunsch --- I'd say it was the SD card. It was a brand new one taken out of the blister, but apparently suspicous. I replaced it by another one, and now all seems to work =E2=80=93 even much faster than the other card. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Feb 12 02:57:41 2023 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 4PDsbS6MBzz3p8QQ for ; Sun, 12 Feb 2023 02:57:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84]) (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 4PDsbS2YFZz48m2 for ; Sun, 12 Feb 2023 02:57:56 +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=1676170673; bh=UbW3LGBsJ6+W++/nuRRFHSR9dR3PAX1w5qyaPXrdSs4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=sy1tYtFOxBkFsijs9CdTGOODIQXmbCX/s/vxoRIMUSoeOFDhpWTWeh31C/DV5zMdPVFfWB8A6db2wbLqOqgMOTyiykWzsUfQM4cWFjhpp6rTxyZv81JLjN5wDEHmhAoMGMbG3gAQ6Ih41/5F1Cj6QrOE8j91pI3giSAeDNYI5REietjNfziZXtrZxjk9TCRZFQQrRQDP2nVzEBBuDLdywlyTV0vvpGc6NISM2ybczNPV1sEAIlfiS8zR5auH5Ab3La2GT2vbsxuodHtQPuSOUAJznGuOElWaDNkV3DJDkuYIJMU/CIIzPYyyxaEPKqdQZYpWJCh1GxuK3rwgaQcNlQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676170673; bh=uq4yJ9C+JL8G6ExIDkxryOMVZRskEZ1EAXOXN8e6YVX=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=Iz3m71ipW9ncCoaM/aZfm2ZOmjVfRriSw+bmm4uWP6T2Mj6rcqEF5tNSnjue6/LaetSBQfr03Aym7JBg/a1WEa+H9eioHO3yhLd97WKH2YOQbC5PItIKoxmoDsPNZZUFISzE4c1NiqiAIKS+jAjJLvlsKOCiy9KGfJoOTJmniEEbDNfrnupNB33yx9R7T9is8R/4qAdi3cPQ51Lj1CDDCQmgeJ0mndQ3aejtK5iUtofMrT1vv03uZik8yw8O91+jrJdc3pXt1OTr/DSert9myyoo6oUUd80aN100fJVioC1Ox0+VnYKTMeW5+kJV/J511bE3jILd3ZVF59X2nsDayQ== X-YMail-OSG: _YgaD8IVM1lIuPwVS3UbGGv6c4RsPvh3JmbsziqQi310jRoR8MCQVFQibSUNUHi _oWbzM_qMi6icdT24rUXF__jSdxhsWxxpmOdQJbAn1vlw3j79DqhV1S3l4b5CBDxFoGbpFERIVFP GIYyt9MKcqKsmxOv2DsX10sySNEDvvHpmjBiR.M5zthxdiZXnQgG907P97gAEm82z9Xa8MOdwYBz wYQvAhB0PxMh7Ri7VBh8xwKHrLhiMjYEg7nAF8QX4JaXJWS6jVDfTmzI7AyvyNovDQ985cWRPAdK hmRfzewPYiMQxhYR.6x0eH4Ix6U0NOhi2wuQLSw3nK0YvWWAPQgQ2HwzZWPozAci6kx.CLtBnCVi .OKK3PcZpbQZSq8rgyD3Q7lmAPq.Rbs5Ip.dSVI4quOeN.onhFoGmz.4KL8zroUXE3yErM7LjJZY tZVszcNZW70WpgFwKr.Q8OBSRstHI0VZEtf9H0hQKggLgmaUR6xuOrYxiVc8VEjxWy.aRvfEsFB_ D5hX7iY0HeuU2KnWTXW1kNndVK1ctobloO73u70CszXzI6WtFQE8YsYewLEIPgz8QNntSP_s5uaA ugjcryXdgKv5eo4aE64aw4XEhOBV7mWg98oEfIXqQX5ae8NM6hlSKR6p_Tz1M1.Auydla5CKHgiw n2xr4jSvKfakJjBmphfrqNfWnf0CAApDbryyPr51PUnIMwejnCdKmetgy3P0eflzavCL.U_AOgY_ pqHPrRs3sw62hUT8BbttuydujY6F6rB9LwUiJGAPYBgeBwh13nFSCgzZfiSt0hqLM795BGlTB0T4 f.y291l5bLq6JvzjyDSkez7vedmwU_rNOVEyN_WOb17NbMjbbl_dVNOWJDGhBvYI8648u4gFPH.D RRGVSey4kicJnZ_tR5qr3Dk2KLo3EHIHmFtd5u6TioPXiRSBIJOXnn.YgYcHKT_CCRLWYSdRlpYJ d8sNS_M3.EHAUU0fefkxnyPZ93sKd3C4vJcPNx47wQ4mL8TrxFA0sw_jssPx6lAofJVHgjQH.u.9 p9vGDNmdKc8SEpgS0YmZUANJDQnowSegQDBKdURnLaGRWmPLVn6Bed081AY6O8DAmKKWEtWQ7oq7 V45t2Ro_5tbzgVPibMvxJxFZqv6WmJWE1HfJPvV1SrTDYc4DnlBcZ1IkrDPcYBCckl4PK6m5Jlq4 TZ36j_5SgVkTI6UZZl3epehAiix8dQWI8An2hdaL_pMYT5sdKeswZUxr2C8HE8U3PezhIKlNjob3 b21KxRQLsBHXYjDq7XEQmWOUAwjmZMQFPqckyAbAsbfLJ6niLnIr__MQR1pqW9a0UFpt1zBiSwDe V2Xfq7UfFvvuscpKXAZ_0_dzcdBR.i0CZY9B.YjYNC528favmKJIDs8acLsTxNsxXLmjjmCF64J_ 10Y21JTY5WJYrZyMOJt0pbvc_q9v.kNmT_7gi0y1hfkm71S.VuN20be1HqOFUnSR_2r8ThDCOAw3 wgdmJNtKRmcedO4SeVUWbh706Rc3TFaHGik5sxmqOxMK..koWKbfk9FXuyEUe.SklpTGCmqDVWxz zcVkBC8QkeI5ZLF78ZHT7xwHpAs0dgLWU5FfrZXqIidWz84DSDXbDaOw3052DhbVsMuhP6AnTIPe A3wqcm49cvmCETAMTcn3Xuv7Hq4CknkNtfkw1izLO_EbwxIE6cGj61vydSt6Z1qiINK7qlqwr4dK GevGX8Ii0DY.5rO0.7nSZSnF1cWs8Vt3BuDywH41qBvqalJLabA1_UA.RNP_Mqz73nhi8KgCAwOt 0VpLjnwl4coPS67wqKrRCB6S91pukfGCsv2d2E8sk9ENEG1yvlPWk8S96shek7Vb5bAGv0WVps4C DqQNGVw_yUopO6BHSFuOOP4BLUcMLNnGqtRRGKKGkNDnOIoZjdryEMDvMdXxd5YrOSfqrn887jja 0F1sonNCUdC4IT1fvvwutZ0yONq3TVVQ7yeCc57n2PME482h2ZqKvcc8PwYDO0.1s06YWlXLAH_A 4VVHb._8Mu26rHXAd0JhkTin..uTA8f3kpfBV.QDVcEvJe.KqklJRBP1F4DPT9w5ieD36RjggHoG 0vu4bv60wXA2Np7ZL9shd0jYLktfkVKDYBqK3c4IWrFvaB73LM_QK7maz._AnyoI6L00Eb88r64_ bbQzLvbKTTP8RyADbw4hc8PVj.WxdcT_LMOh31YV74MuYIMHFyNleYnojEiEgmLA_HeytyIuqPDD v2uBWvQYif50Xb5TR_98.lnottBj1zXa.1Is47tHvQKLmgySb996.Rsv8ASgwlGgHxABBBfveVXg UvZw- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sun, 12 Feb 2023 02:57:53 +0000 Received: by hermes--production-ne1-746bc6c6c4-b6fc9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 79ab39cbb4349293027616484439a78a; Sun, 12 Feb 2023 02:57:52 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: fsck segfaults on rpi3 running 13-stable From: Mark Millard In-Reply-To: <20230211224057.GA17805@www.zefox.net> Date: Sat, 11 Feb 2023 18:57:41 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <9DC74DD9-9AA1-4822-B425-217AAC7DB3F5@yahoo.com> References: <20230211224057.GA17805@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4PDsbS2YFZz48m2 X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 11, 2023, at 14:40, bob prohaska wrote: > While running buildworld on a Pi3 running 13-stable the machine > panic'd. On restart using the previous kernel fsck failed with a > segfault, which repeated when the disk was moved to a -current Pi3. > > In single user mode on -current the segfault message is > > .... > 7912408300994173476 BAD I=74682090 > 4313599915630302063 BAD I=74682090 > -4473632163892877928 BAD I=74682090 > 8068741989830080453 BAD I=74682090 > 3857159125896022134 BAD I=74682090 > -4354179704011695453 BAD I=74682090 > 7611175298055105740 BAD I=74682090 > 3985638883347136889 BAD I=74682090 > -2495754894521232470 BAD I=74682090 > 7739654885841380823 BAD I=74682090 > INODE CHECK-HASH FAILED I=74999808 OWNER=1842251117 MODE=15044 > fsck: /dev/da1s2d: Segmentation fault > > I gather this like unlikely to be recoverable, but it would be > nice to understand what went wrong if possible. Did it produce a *.core file? I expect that getting a backtrace for the failure would be desired. So use of a debugger and the *.core --if you are lucky enough that the backtrace produced ends up being useful to someone. I do not know if your builds leave symbols around or not. (I keep symbols around, even for non-debug builds. But the symbols are only highly useful some of time for optimized code.) === Mark Millard marklmi at yahoo.com From nobody Sun Feb 12 04:35:24 2023 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 4PDvlT5s79z3pM7k for ; Sun, 12 Feb 2023 04:35:01 +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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PDvlS5DJdz4JNn for ; Sun, 12 Feb 2023 04:35:00 +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.16.1/8.15.2) with ESMTPS id 31C4ZPv7019455 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 11 Feb 2023 20:35:25 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 31C4ZPbg019454; Sat, 11 Feb 2023 20:35:25 -0800 (PST) (envelope-from fbsd) Date: Sat, 11 Feb 2023 20:35:24 -0800 From: bob prohaska To: bob prohaska Cc: freebsd-arm@freebsd.org Subject: Re: fsck segfaults on rpi3 running 13-stable Message-ID: <20230212043524.GA19401@www.zefox.net> References: <20230211224057.GA17805@www.zefox.net> <9DC74DD9-9AA1-4822-B425-217AAC7DB3F5@yahoo.com> 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 In-Reply-To: <9DC74DD9-9AA1-4822-B425-217AAC7DB3F5@yahoo.com> 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.997]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; R_DKIM_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[zefox.net]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PDvlS5DJdz4JNn X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N On Sat, Feb 11, 2023 at 06:57:41PM -0800, Mark Millard wrote: > On Feb 11, 2023, at 14:40, bob prohaska wrote: > > > While running buildworld on a Pi3 running 13-stable the machine > > panic'd. On restart using the previous kernel fsck failed with a > > segfault, which repeated when the disk was moved to a -current Pi3. > > > > In single user mode on -current the segfault message is > > > > .... > > 7912408300994173476 BAD I=74682090 > > 4313599915630302063 BAD I=74682090 > > -4473632163892877928 BAD I=74682090 > > 8068741989830080453 BAD I=74682090 > > 3857159125896022134 BAD I=74682090 > > -4354179704011695453 BAD I=74682090 > > 7611175298055105740 BAD I=74682090 > > 3985638883347136889 BAD I=74682090 > > -2495754894521232470 BAD I=74682090 > > 7739654885841380823 BAD I=74682090 > > INODE CHECK-HASH FAILED I=74999808 OWNER=1842251117 MODE=15044 > > fsck: /dev/da1s2d: Segmentation fault > > > > I gather this like unlikely to be recoverable, but it would be > > nice to understand what went wrong if possible. > > Did it produce a *.core file? > The 13-current host, looking at the 13-stable disk, reports root@www:~ # savecore -C -v /dev/da1s2b checking for kernel dump on device /dev/da1s2b mediasize = 2147483648 bytes sectorsize = 512 bytes magic mismatch on last dump header on /dev/da1s2b No dump exists Seemingly no file was made, or it got erased amid my fumbling. The corruption of the ailing disk is almost certainly in some part of /usr/obj or /usr/src. Is there any subterfuge that might allow me to simply delete, say, /usr/obj and then let the buildworld process re-populate it? Something along the lines of mount -o force /dev/da1s2d /mnt and then run rm -rf /mnt/obj then unmount and try fsck again. At this stage there's not much to be lost.... Thanks for replying! bob prohaska From nobody Sun Feb 12 05:21:29 2023 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 4PDwnT0mNdz3phfH for ; Sun, 12 Feb 2023 05:21:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (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 4PDwnS4yBzz4MZ1 for ; Sun, 12 Feb 2023 05:21:48 +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=1676179306; bh=y146pKUmM9u3zL81VMdU5htyghaQkv2b8npfQ4oC2C0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=bQb2g0oOCtvS0mMGGuwprWWCXXgJuKTwSmE2c1YiE3In60dLHZwzQxCxEubaV79aS/FwVTTgZmyiAK1KYOqnU6l0hf1HHumgbJNWU01XmkcsNfZs6lr85WaHJ4NPRsntsF1rUNdC9Vwuovuhisw3/ThYcaZrzJfQR8E+j9PffMsn+ky+7LJT0VcLbNkniacyBreIcG4PIMHNtFC7SHes4LqX52FrKz1DOYhHs2TpSkLUfCOthVASXW18533m6SpsBIwlulZoZikFliKepkI+cMOe6tuV6R11fcTs1bHY6QeZ8stGAVezDoc6XUYKZFEvD/NXzpVrSBDcfV0QjEQecQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676179306; bh=XNOKd06w4aoeJwP/gh/rPnCWm5rgF8OTTtOaZTeCoZM=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=iZyk4xX3uGyArMlY3ZJfGooRUWFwxt7eq5COdOfm995TGWF0u/h5KyOXhBvgSQc13rLpKhq7vfbbV9agnP5ipP9r07KgfODfLj0tfpTj1uRqF3wlj6ieW1kAVq1snUAIJvsIdxMSb8XjIxZSjFWtscq8l9D1KEeWUutY/z4KrFZhQqwECKdE0gzo7mUmoyUw7nOtwBR30hmwAXXfHPHFNUiGi9E67A1hJdsLZSyNnOL0OiS7Z88iWLFjz9PrKQM4JX8ny/kWKtjtrYO6T7q17AH/qz+hbfHXMJruqb+OpC/fmR0DXvysOWP26g4brWtQcUwn1LSyII9OlJOTsZPPPQ== X-YMail-OSG: RHycH9sVM1lnoCm1RsUxDmESDtXAmZvclP3FmeUcWNYnE_gQ0VlirQlzwmEAj_u EakyIwMCTPAgwqgReXGU5oKuKOZOdLscD1Lybm9JyVyxShym4sLRCe2wtkGiNnus2Ske6pOaVPIf T3KPA5cQbsWHFR5Z.9CsM84.bCOpu4mrGtrGwTzp03vp0BODApHzSE0DtblgCE1T5nMLJ9OSTkI. nJeWD3Sl72XafUFCyMT0AxZ.S_1kKgNhKfljkqn8.QmbU.waJlO2hwR7j9Tjb3fy4dVC8wRblV_D E1BHtv0KJHcz2cqL2WKi8dUDXxPlVeGElps5U1Gz_unZGNoYtmAOQQylMfhOqQoEAGABMMwglNWz veysL81JD6QvclLZ_L7sbd2MA.PjTuKuAMjYGIKhmXLlD0ajq2vNdkv8t7dONHmdJrHogv2qoW38 r1tKK7ISUtPQ6vyZ4qf11L59bGcCGvAS5NS_3KnxkBFjTVDI6HqGMGU8Wv3oKLepXiGQyGou4gky Ha4Yi1SGWfpcj9.acUFX2XxQtSQu94IT_lydTls_FNirwrkuVnuVAg0jb02MvyT6gETNb.zOuh67 FRXzwntfISfmXKH_BTMjFFL5EanE5k9TsEcmdx9PVGHCvJEiGHetd4Wdmda90Jz1FZm.PZNbPsAk b_2x_O7htrb67SlZVoPCaqXR_Zvz5PiyqMuJF17CoEzUjnxsBkC_cGopu9u6G3XIOUZjxdRkSGk8 Q_tFiBTT17AZrGFJUBQ8ubmiUGui5oQXx7kKagELjR10ZQmfQNsd_4YsqEu_U.DnhIn5FiIk8NFg 5mwHs59RIqhj79iSR4lgpzRvLZ94kufsJPfAIZbk_gUpzmIj6bKHBlu2idi6Eyzf1JB0ONz_9aEh b3TerJErzNApJwakFFAFkd271lrGeNz9Oln9xBOSo3t3ZT70Xh.DGUJQypAchSbRh58ECbpa_kvS mYnApxv7fmAx.PKb5MpCtO4akL1OkTPdP0Pzm5z4Ds.6gQ_V5Px0mSrS8VLUiSWF2OKZemiIw1XZ .mVM3d66LorVm.OqOVuFKVJ1KcvVsAcuIIghN04VXg39NtrVzwxlfVqqBSbrR_OvW0McRERrSOYw B.pj5dl0f0FKIeFZs8J3VqrAr.scQTfIrsgAmjNL8Ri0qDBe.TPJEjs0mOiigak652NWDi0CGriN gWmn54JUOUCQDegjcQwpHSiQffNhWb0FWq.B.oXDP0IKGInDrWAU18lQ6_d1ROGLDDk_M03hARNg moJq72LRqqJSZQzpJ4NNdWQP6BYaxJqX3kWa2.vAtUn9CVqDzH14co3cnUnkbMvTMYkop7QopAt. lzq.szhRS_7__fahS7UgAo2uukc1dlmkBq8hdgWKkYvhq.lybFa7tyO3IBSCOx8ouZ31J8qUzAPI VkLWNVvy63DGBJd6RgdjtgfCxbUWgYieXCvizQB9ChPc4S8eR1vCVXVrSEoZubMB4xJ_bxdIOlPf umBk98NCDfO2tsa1W0dD6wpmofI1gLSY9V7E.u9VJ7dKNei4LUvF25d7R0GsMppt_zIyHfQk1roE .jrJYPa5ayvrszMkV6t.u_xgojb5w_76Np13BIGd48XBKtq7m.ir3inONDPyz3benVkqqkjgnb.W _lsJn0.fh_3eMAEK0FyNphbJaYv_9eYqQRN3HGEMOMltCOC.leJYl_D0tlw5jB3CNpFu64fPwL6_ 6fimevH_8sSExoKlqb4DWS7Uf_7a0HJPEWh2D9fk9rPcmyeennOkDLlMHBjmUNAqGI.4SYNKDzCq .8ZYWUYROygt2hZk.zfuCkAgLkR8fc9m9pUHv6E7MKVT7DjLaJprRQ0kMMUgzBzpMGA16fDe3u8w T9WpE0n0umGr69rj_POM0nqGLAkJkR4SrmXTyKoSgOy9RhADYYCT2gEuQSSoCZkQdEm9iOXTID5h hyeDy0XWaJNpOIvtCvdypy5L4aExPokJP.a2IYrl0.ab1Yhu3joOrpiwsFwKapT1gDRPxPZF7K1I ECGhaZF9KpVvH8wlXZAaCF.SYOyLQYAOcMzFgFgTUelC6sLn6fCErmrjUYXwwaqiiGtcd3ptxUIr 6h0DY.3iXUOp87DlFG_QPlpT.kj9oJDFWUWqmh6KOKgFSAUFsCED2.cnKksou9RS_6tlLJTulFp5 lePjyrwRDfORyk12EFKH0xfdQlra02g_ABiuhTlgoG2VT2hToLRzdQGZF4Qt0zMr9ErayOd9PNWE FrifhZXrXIOBuWTeHlJUZFWKjhitRBjFlk9O_9Xz.W3Ptf0aPUwGE2fmAaLugwJeogFBd31KURpA - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sun, 12 Feb 2023 05:21:46 +0000 Received: by hermes--production-ne1-746bc6c6c4-vvpbb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9289c65b4ba8d77297a4853a2cb78656; Sun, 12 Feb 2023 05:21:41 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: fsck segfaults on rpi3 running 13-stable From: Mark Millard In-Reply-To: <20230212043524.GA19401@www.zefox.net> Date: Sat, 11 Feb 2023 21:21:29 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <984314A1-FF42-4F92-A212-6BC0D85CB630@yahoo.com> References: <20230211224057.GA17805@www.zefox.net> <9DC74DD9-9AA1-4822-B425-217AAC7DB3F5@yahoo.com> <20230212043524.GA19401@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4PDwnS4yBzz4MZ1 X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 11, 2023, at 20:35, bob prohaska wrote: > On Sat, Feb 11, 2023 at 06:57:41PM -0800, Mark Millard wrote: >> On Feb 11, 2023, at 14:40, bob prohaska wrote: >> >>> While running buildworld on a Pi3 running 13-stable the machine >>> panic'd. On restart using the previous kernel fsck failed with a >>> segfault, which repeated when the disk was moved to a -current Pi3. >>> >>> In single user mode on -current the segfault message is >>> >>> .... >>> 7912408300994173476 BAD I=74682090 >>> 4313599915630302063 BAD I=74682090 >>> -4473632163892877928 BAD I=74682090 >>> 8068741989830080453 BAD I=74682090 >>> 3857159125896022134 BAD I=74682090 >>> -4354179704011695453 BAD I=74682090 >>> 7611175298055105740 BAD I=74682090 >>> 3985638883347136889 BAD I=74682090 >>> -2495754894521232470 BAD I=74682090 >>> 7739654885841380823 BAD I=74682090 >>> INODE CHECK-HASH FAILED I=74999808 OWNER=1842251117 MODE=15044 >>> fsck: /dev/da1s2d: Segmentation fault >>> >>> I gather this like unlikely to be recoverable, but it would be >>> nice to understand what went wrong if possible. >> >> Did it produce a *.core file? >> > > The 13-current host, looking at the 13-stable disk, reports > root@www:~ # savecore -C -v /dev/da1s2b > checking for kernel dump on device /dev/da1s2b > mediasize = 2147483648 bytes > sectorsize = 512 bytes > magic mismatch on last dump header on /dev/da1s2b 14-CURRENT? For system crash dumps, they may need to be handled by the same type of system that produced them. (Thus the "magic mismatch"?) However, I was not actually after that in my question. I was after fsck crash file(s), not system crash information. (Also useful, just for different purposes.) > No dump exists > > Seemingly no file was made, or it got erased amid my fumbling. I was not after the original system crash information in my question. I was after what might have been recorded when fsck was run and failed. So, since you ran a fsck under 14(?)-CURRENT, the file system for 14(?)-CURRENT might have a *.core file from the fsck run. (Unsure for fsck.core vs. fsck_ffs.core as the file name.) This is on a non-corrupted file system. I was avoiding trying to look at files from a corrupted file system. If the fsck failure can be fixed, you might be able to use fsck after it was fixed to repair the file system. The more things done with/to the corrupted file system, the worse its status for analysis or repair after those changes. > The corruption of the ailing disk is almost certainly in some > part of /usr/obj or /usr/src. Is there any subterfuge that > might allow me to simply delete, say, /usr/obj and then let > the buildworld process re-populate it? Something along the > lines of > mount -o force /dev/da1s2d /mnt > and then run > rm -rf /mnt/obj > > then unmount and try fsck again. At this stage there's not much > to be lost.... I'd go for having fsck fixed if you can provide enough context for someone to identify the failure and make a fix. (So: an update to 14(?)-CURRENT.) This presumes that you have the time to wait vs. having to quickly just start over after quickly taking a riskier route if it fails. === Mark Millard marklmi at yahoo.com From nobody Sun Feb 12 08:02:58 2023 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 4PF0Mm626Yz3q24t for ; Sun, 12 Feb 2023 08:03:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-54.consmr.mail.gq1.yahoo.com (sonic307-54.consmr.mail.gq1.yahoo.com [98.137.64.30]) (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 4PF0Ml2NXcz3LQ6 for ; Sun, 12 Feb 2023 08:03:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=omAv6kKZ; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.30 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676188993; bh=KJxr+5anVU4oameMZwFuD8+girNiWl0Bi9PBjg8zqGE=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=omAv6kKZ3NhHMCjJ0KPY1YCaMHrAMQQd1fM3Ot6G6v0a3AWmdWAmpUUEyFls9xjzqID/GGGl8QVK17mWBWP73xbv4N0z57vwUcYNq2C0ccoBu6XHsZh79watbK4NkrIWzvTrVZWzWPsCfNxTQqSPpq5stjvnBfdOS+81Ms9qczMXYHbqY6Mz9G4VmRzS55BYhtiZS6zCukwq28V2P73S+ghbKlnu+p8auuc2Y+jgVD4XdUQn4bEiglzblHiTuIBWzpdsgCjihjRQ8X6MpgftD6meoz6HRKQEVFe9krmNtUq+gPa/xKs63QSaaapjeR5j60zDpCWk9Yeu5yNBOYO+LA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676188993; bh=AETNyEoVVJekr1U2JO0U1Xnrkw79oQDhcZHXwmyOmdR=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=TG4je1KTw5HvyjbZKwBKkqALNPUfORmovFHStNCyLoaHIoGU+rIk9F9gwkhefQm1CSFaLaH3t9OseM0KROpXvc33T5BfeprimNlwZx7l/4ussHhnLlF74WxIvjEKQRMGOFoj/VYGmsHJZP6ki1raVvBCzHJtFFjSghbRPGPUUzBBMcv9n23cLh6HUEhCXw1582NUzvyNsAD3H7QkrajH8xVkR2Ft5CxpK5hGokJrfekbeHLp+0+G87aEP8am+udMLLFSt1ChfjjLpi5iBW+mKtClUd3t6vHjfSHZu1gEqWZZfCqET7Oq0Rl6Nb13JVd4PQL/K65WYdR1iWy5snZ/Mw== X-YMail-OSG: ibhEaIQVM1nZYWufyueB51OMNFEFeKXnXygDDvuR3K8wXCEOknjYA7k.THCBLLA PIQp3wUMbe9DJLKSSSvhj3rQFj3nactO.EuPAGDfTddd3Dl7pdEGn4S22KmiqiTrdJk5a2iXp.0T k61bwmdPx.odtyD3RxWKmCrrgy6YK42wBKvjXyVr2Y5DUEmTb9VB_FZTrJo_44Vc9ZHo9wChvhCG sa6T75shPNJvrTx3tJ3CFK6UuNZxGgrVrEbhRBD8Y7T0fY07L4_KWP0uHRdrLPwFy._3MOEwTeSG AyjhZoUxWEROace_EXjcZOM6seb_hEVYAIcLbThYzxF9Kk69uJpRCe7WKw3ck48XxM0cFpcceHqk vk41eljdDC1JG2mjsoPh9xUPLExvy3e5uC5Hn0DKt.3hSLw5EJosOoNOhBqhNFDGlHo_gNZCicVh LaxM3J24QrJyi0v_7HmejzAprG47fZy0ZZz.8553DBCKND.gf2CrIoGKIxE6rlttbhKhL1sJfJ4p yct9lTjzT5Ia6VVQ9PEO4SDM1KTobrnqlsL7mxxfldBNEbHR1Ex1Po_AYI7My2hvuEtMUphXQJVD mmdQFYLnBc3WTLzzSoawvagKKTul29y9pprl7JqPnyEXiChQxqZqZ2ox17860d9daiQ3BSuFsy46 SZvCz.jtp4FqxS9yvvW7I0xZ3R0ZyCpTrjzr65EKHhg_gpvgmSuMixlgvs7qvLCDP_cKu48ATFKT B1Xo7cZkTrKzYjDGV0EtjckwBNex2b3jVibBHtVONBr2sgEbaa4EyGFe8kXy.LKi.m9qk2_VRkrO HsMV79zEYJm6fyKe0.eUSH3vmcnMhB9YE2APhvtYzqiC5cWYr2w3T6ThXsYKxmJUR1gETpefg1Dj QN1AtGg25xEXx._P054GUHMOX1es7704bO68JnLBgCcv5QBRLr3mbg.3FpQHLmERA3QDKoVijTEj peJWPVTk_YMEnXBxQSEwwVxXOlP6.lmDGF.Zc03xKaVyEu.ao5SQBo4MMlgIt.vbx0ojsnGrtMfT kufGZK_eVcM9SKFRefYzZTxV.HZ9AML4XfXEG6dNV4rmd2RU0FYZ5PAZcYdMl83kIXF7RRUf19Tw Vi._T.sQEle3m11sm2obE7pqDe4.ZjZ7E8Lck0xH4bebp95Mhzvweo6SSR_s9Pl8zue1.ciO1srz 9QXDFFQ9W9yIcOPNYSph0Pa.nsIpjTc2LylpZlX6aaid3LjP0Tku4Y_Nrifwl2gAJuFWSqn4WMpt YYh7zmUq5VpZl5e9QrI.WG23o5fyEJ8.V3er6ACzbrzCew23ZSzdHNa5FDhGvO1iI7dIAlmDpBwR ZpdDSw2fyLOrw_gdj6sFwcC66vHog.gEdQeWyFrQ3Pi076dJZUiNfvO6UduKyJCa2OkToKcCR7NS GLudzNdwdCGxIWUO3ckIQQThXuW0_SS4A6uqT5WDaBiU5.PjpOsV565knUoL8CjBGshT1Ko6TAcN .uhkcPQ_i_0wpg28D0tyvleTBFThd.B4qwBe.KwqCDN8WU4SdmVUuPeB.SCEiBBHM_4bg8dp5Agc Adwwvs2pyQf__rup9YjW9xxTxNX3t.ZrV6ZBezW9GsTr0XMeLuKLthcZaoJqA5OgxGOas7kBmHrZ OeVjUQg8.LoUrWD6eSe6Y9Rhqvde62OK1UVE6m_PPpSsV10ljrF9W2Yoq6ZyKCcKwKov2QcbYQhg m8wt4XtI3N163fuqqQk02esEb229t4O2546gnFIO8W5QKojVs78rcE_JDaLxElNJ0k.V2Ki5mM67 na2SeRTU3dfHjZAKqCoJ3UI05NkcFESLnqSeomHvD_RNvC5FysmN8Tzl2CXh8LWuMmqj4vAgpTl8 BG0ofgTkjgKz8ZFVraGHdD_Y1ElhDY3.qwJQfzC0ykq3LjscWSzm0uV0SEpdYAxlkU02GxIE6g5I HlswC1Hr1auYdd7p0MEK0UNloc72OEHYZvyqi3iHxHVH3kbpF8DfdwlERII05dCL2bJgoAeIQH6Q j4IGVW_SAPXH5JQ58..1Js9RUkX_ytSSISBhtB9mP8bP.Xr9SuM80WgPs5XDnRt.IuMBVhu5txCZ CeCYseeeTcY24RaVqmoSemFhggRkjEU.jEZBem_Gl4XKuXZHogiWncEJuh2Emlg.ay1EzJHvUVLY o_yX6jFO474801rueOk5yAcKwSYPCi.HhJxLNWTEoP2PNhF7AvsVAVDcj1owYTzn7OfxfzpwSmxk xyAsctuHIIXwhONkUm1zMAhAoPJFNWrKF__SLTmqSKBn_Dt31teM38152hP4Loc4. X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Sun, 12 Feb 2023 08:03:13 +0000 Received: by hermes--production-bf1-57c96c66f6-hmvtp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3d6d794be695bcca6d4b3fb2cff9e4d4; Sun, 12 Feb 2023 08:03:11 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Anyone willing to commit the tiny patches from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268835 ? Message-Id: Date: Sun, 12 Feb 2023 00:02:58 -0800 To: freebsd-arm X-Mailer: Apple Mail (2.3731.300.101.1.3) References: X-Spamd-Result: default: False [-2.50 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.30:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4PF0Ml2NXcz3LQ6 X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268835 is titled: "Use BUS_PASS_INTERRUPT+BUS_PASS_ORDER_LATE for bcm_dma (for RPi* contexts)" It allows for being able to experiment with more modern RPi* firmware than FreeBSD currently uses. (Helpful for getting technical support from outside FreeBSD, such as for U-Boot and from RPi* itself.) As stands the FreeBSD kernel crashes for firmware that is much newer than what FreeBSD has in the ports tree. This is because it attempts a use-before-defined operation for Device Tree material, not getting a resource ready before its first use. Note: I'm not proposing updating the port to have more recent firmware. I'm just trying to simplify experimenting with newer firmware by automatically avoiding the crashes: getting the resource initialized sufficiently early. === Mark Millard marklmi at yahoo.com From nobody Sun Feb 12 16:53:33 2023 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 4PFD794qlWz3q52Q for ; Sun, 12 Feb 2023 16:53:09 +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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PFD791Kgkz3N5N for ; Sun, 12 Feb 2023 16:53:08 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 31CGrXw0021359 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 12 Feb 2023 08:53:33 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 31CGrXk1021358; Sun, 12 Feb 2023 08:53:33 -0800 (PST) (envelope-from fbsd) Date: Sun, 12 Feb 2023 08:53:33 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: fsck segfaults on rpi3 running 13-stable Message-ID: <20230212165333.GB19401@www.zefox.net> References: <20230211224057.GA17805@www.zefox.net> <9DC74DD9-9AA1-4822-B425-217AAC7DB3F5@yahoo.com> <20230212043524.GA19401@www.zefox.net> <984314A1-FF42-4F92-A212-6BC0D85CB630@yahoo.com> 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 In-Reply-To: <984314A1-FF42-4F92-A212-6BC0D85CB630@yahoo.com> X-Rspamd-Queue-Id: 4PFD791Kgkz3N5N X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Sat, Feb 11, 2023 at 09:21:29PM -0800, Mark Millard wrote: > On Feb 11, 2023, at 20:35, bob prohaska wrote: > > > On Sat, Feb 11, 2023 at 06:57:41PM -0800, Mark Millard wrote: > >> On Feb 11, 2023, at 14:40, bob prohaska wrote: > >> > >>> While running buildworld on a Pi3 running 13-stable the machine > >>> panic'd. On restart using the previous kernel fsck failed with a > >>> segfault, which repeated when the disk was moved to a -current Pi3. > >>> > >> > >> Did it produce a *.core file? > >> > > > > The 13-current host, looking at the 13-stable disk, reports > > root@www:~ # savecore -C -v /dev/da1s2b > > checking for kernel dump on device /dev/da1s2b > > mediasize = 2147483648 bytes > > sectorsize = 512 bytes > > magic mismatch on last dump header on /dev/da1s2b > > 14-CURRENT? > Yes. > For system crash dumps, they may need to be handled by the same > type of system that produced them. (Thus the "magic mismatch"?) > > However, I was not actually after that in my question. I > was after fsck crash file(s), not system crash information. > (Also useful, just for different purposes.) > > > I was not after the original system crash information > in my question. I was after what might have been recorded > when fsck was run and failed. > > So, since you ran a fsck under 14(?)-CURRENT, the file > system for 14(?)-CURRENT might have a *.core file from > the fsck run. (Unsure for fsck.core vs. fsck_ffs.core > as the file name.) This is on a non-corrupted file > system. I was avoiding trying to look at files from > a corrupted file system. > Ahh! found it. -rw------- 1 root wheel 119074816 Feb 11 20:02 fsck_ffs.core It's been placed in http://www.zefox.net/~fbsd/rpi3/ > > This presumes that you have the time to wait vs. having > to quickly just start over after quickly taking a > riskier route if it fails. Time isn't an issue at all, in fact the system is expendable. Mostly I brought the problem up out of surprise that what looked like a routine panic on 13-stable could result in seemingly un-fixable file system damage. In the meantime I'll try updating the 14-current system to see if that makes a difference. Thanks for your help! bob prohaska From nobody Sun Feb 12 17:21:20 2023 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 4PFDm022xbz3qNmB for ; Sun, 12 Feb 2023 17:21:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.83]) (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 4PFDlz6gm1z3QfD for ; Sun, 12 Feb 2023 17:21:35 +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=1676222494; bh=EZ/EhhmI8gtzFbX1gwz/spW0yEF90xZTLeU5cvK0LTc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=FxdBVzRwzJ0gdeVVbXS10oPFfTLbsXZAAmfB3ly6HaxprOm4qL7FLOVoy3DC6zCyY3tS0IrBpJO4ROBXIyRGUTkmqALnBX4pWs9cLtUndegUviUce1PQu/XIb9LTPMM7rOMveestLMDb7rQbHq2/bQKvnOfRxYUIB22AvU8j/wri6PYQwtO+gEJ3PEDBdRb24M1vNlcQ2joc8GUWUc/DcZiGj+8Tcexyh9Qk13TqM/HKYBM0fOXI0f04Ay6CcGqR4FxColY44K3FHKTfXNGklkrZb5zNOCmmcZGUjqHISe2/3QD2uWqVLbq8wYJH2hU/P1SCqkBTbEU8kOml9ng0iA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676222494; bh=JQ2RrBEJdPLwnAjm+PR5wSnkCnSc6Iu4NZCCtbakbN3=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ddrG/RI0xoHrLV6jua/S0+vmKy3fuQKjFHhWyoBLKzSr9rMiUFq6rnqrAomjuzP8jrTcgIYCdPCOwsjobHaI3b5/0+1c7rbBLQFdK0bLjqZa/k66L5bohUlLm2Srd/BAO+vCEtORxR+5z2yuVwYNQFMzj3IqSY2XOaBHFpkYYgQuVYnN3YUz1A/L5NlcALt2EbOQom/xZQdBQIN9gsFUHxibAoz/shmcLv15itnfZSy9svow2Rhmxg84vu+LLthtU5Yg8shtGLDV6Fra5AJqS26O8OsC4Iio8e1LvWsW1Ckl+MjSHBLGW/ReVUMKRYQ8p40131IdKS94uhqAx8tVyA== X-YMail-OSG: FWjClXcVM1kPhFXTT3JCZlVe_wgkExZYMe8Oj07JbbzFPZi60gccHUz.NsI_VNM LyfptcyBAWyVrfgEZ2ayPmtvSLUixvn..Tue08ls0mJ7LE8.TpWTqI2O6IuoLVvsnuyT8xf88FGm nUdpmafhDCC8BpS4YcSemNoJXEXjhDtNJbR7nHRWv6Q6Ja9067YSG8pKW3nN7Vw3awqyBXMtREaU w4S376rTvG2nqUEEQvesZww5UFiBpVgT0nSNZOo5KBMNSkQmy5.RGYJnVNNaPsC8y8yZCW8i3LJc nvsZYjcUJ1OmDtFVypmxvOX_ORDn_H3_1ShtGSs5ODtQUSJo2FIc5gOH3X6PpRQ19ljQyDNS_bZw cEK2UhO6hi45q4U2DATWFvKGEaPby2_SEwXX2YzBg3m9.2yffomCCTn4TC.Sg9iMRwedrDAQvs8T _6jOQDmfr_gVs0tXYgnkPEQX4RbZGzR5V4rgF724.eJsEmCMXgCHxZIjBqAq22HGTBHHbj5dIlBE s8GpzRSMZW.JMCZpiRxDYbcjR.GKadXHokDslTOY1BLDfzUhFq3Px0BjY_ncYOb3RrVy__jfzJ4l Qqu4O7JLVoJ4HA0PbtV8JtGpCBKinfSotIRB_W32IhJIz2uk8yBM6iSYhjmg7drHp3l2s0GhB5dY qGTmLU7ek7PgldEbhkl5wY9O_MOJqgVmmDrouSuHJF9LvaW1MF7rgHuweB8uQZBdq7jrBual_CPs A9wyXk9EpqoyE6jVid5DZes8.vWsj6jkyiX8fxsS3062z8Yu26GG9Gwb4jJ6dfv4M.DpEjl8txRO vTg4GY6B8GTRx0jEzMj.C6FE4_AD_O4ivVMvXQAY2tQQnhjwdOR7KlxHjmxrP6V9Yrd9DOdnMJgs J.84kVkChzlSQwXECqXg1qwQ_MgFv6dgPXOmlqzhpq8oINI77AaT_CLrUerJI8Nslv7DWwZUxH1G FoP2r8z00s4CAnD_I4z08hnuCH_PUhDmLe3Xm14CPdugY9zfvyJSaalmow9jAz6_pmjnaVy.XlNY _NQlpaYHpmgtqA2rw.nuB58OPKZXyMDhgKt1Y4Rg3tP2TB1eMfOckjdM7TNgLD4YlGAtsS4oDwib JAX37HyO5FitxR91_gH4_M2rIVOLoUZNtT8ZmuCVFSZlxgcPSRS7QU0hfm7eyzimI.QQyeNP2fZ1 ZdpZkFapxQkkUYbeEonJJHGlxWI50LhMjjXREiT_51lhONJinpiq6BkBqS5ECppa3fwVR_BOYoBe dXZ1LFt_hSEavwkFW5aOkK14k3T0heZ1na8nDoeLgRZmWx1DayO.n7fN3vqNmTDPP7Qev1vsqFQR aFhk2FeqR8rx8jqQXJMPPQmkZ1Gak36lRwOT39_0QAbm8S3m.e.HA7F2Ynn_S9CPnr1sUL2AdYy0 EyTYWLIYY1Nhf0gquivcUrYzTJXcOECmTJo7GboLdQAWAr9Las0r1sqIiGYt89D1Di7CdGJPpuVQ dSFtT4ZQ.CclDMkT4dIpYnRWoley6ZWUo41j4bJW3IZTTLxrbVZ8pwQbNfOMWLRwj13FzvTejHsH JBqN6r0PKnRDX.RheSlZxU11FbHNg5sQ9RL8net.tc3ZNfyW9pOnlGOvzBRdYVAWVMhWRjaHGLXJ TjW.c.ylUOgGdVvgrJ0OkcxTzqqSDSRo_I8GCPcsAnQnegXVVPaw1JeeMPtrYzSwsp6jrj.FQVwU 1Lkv1h2XPQeU6CK9Q031z07.XNcvQXzgJNGouI..D38vUpuMd_ZNX5QIulgYZ7Mci21RVE79XaW7 zQ3Q4wr0I_lf2OgRntNNVydo080KrSjOhdNNnuIaGRsQeQnInv09Ugqa2ASj.ubj9pD5GOKGua2M CQLIYE4HTegH7RmnyW.axBhsAcbJubW5F8kaLMUHAKOjCciu1FnvN.fHaO9eQL8fbFeb0EWwJBX4 xAPimNIqIZ3gz9_UuhoJ_F3zk7m1PWfh5Igdb5EbKQxjYkMjV4L20OZUiDV6xml7zubx92RdJr7w 6Vz_KA9PAFY57R84hLpoCwWi_8K0SSUEzGhKpjkk4vwutbMvm5T7Hng11XlfLlRzOZ6E5iIgacZo 1bYnD6qeMf3WQvJhwlyMR6FQnpkgZCcu8Qk.LdU0OtzsLfflOzXtlF89uhh4Ph57sIl2wRoOj5EX KRj.sGHwLj5Iq8GnIxJDr4gM1Z7qTzeD0379JqVTRfcYEha1vVHGfb4hXbAh6z071M9nXAZ3KtkF c_7NOHK2fUCzNmCG0KkLimvSabLd2sAw3Y6Ms1eKWRoqNwccDtfOqBgcTacGRlRAnl4WPZiqNRrn JNlPE X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sun, 12 Feb 2023 17:21:34 +0000 Received: by hermes--production-ne1-746bc6c6c4-z5pmw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a008a17e8db1b90ce4b12b04234ec420; Sun, 12 Feb 2023 17:21:31 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: fsck segfaults on rpi3 running 13-stable From: Mark Millard In-Reply-To: <20230212165333.GB19401@www.zefox.net> Date: Sun, 12 Feb 2023 09:21:20 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <20230211224057.GA17805@www.zefox.net> <9DC74DD9-9AA1-4822-B425-217AAC7DB3F5@yahoo.com> <20230212043524.GA19401@www.zefox.net> <984314A1-FF42-4F92-A212-6BC0D85CB630@yahoo.com> <20230212165333.GB19401@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4PFDlz6gm1z3QfD X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 12, 2023, at 08:53, bob prohaska wrote: > > On Sat, Feb 11, 2023 at 09:21:29PM -0800, Mark Millard wrote: >> On Feb 11, 2023, at 20:35, bob prohaska wrote: >> >>> On Sat, Feb 11, 2023 at 06:57:41PM -0800, Mark Millard wrote: >>>> On Feb 11, 2023, at 14:40, bob prohaska wrote: >>>> >>>>> While running buildworld on a Pi3 running 13-stable the machine >>>>> panic'd. On restart using the previous kernel fsck failed with a >>>>> segfault, which repeated when the disk was moved to a -current Pi3. >>>>> >>>> >>>> Did it produce a *.core file? >>>> >>> >>> The 13-current host, looking at the 13-stable disk, reports >>> root@www:~ # savecore -C -v /dev/da1s2b >>> checking for kernel dump on device /dev/da1s2b >>> mediasize = 2147483648 bytes >>> sectorsize = 512 bytes >>> magic mismatch on last dump header on /dev/da1s2b >> >> 14-CURRENT? >> > Yes. > >> For system crash dumps, they may need to be handled by the same >> type of system that produced them. (Thus the "magic mismatch"?) >> >> However, I was not actually after that in my question. I >> was after fsck crash file(s), not system crash information. >> (Also useful, just for different purposes.) >> >> >> I was not after the original system crash information >> in my question. I was after what might have been recorded >> when fsck was run and failed. >> >> So, since you ran a fsck under 14(?)-CURRENT, the file >> system for 14(?)-CURRENT might have a *.core file from >> the fsck run. (Unsure for fsck.core vs. fsck_ffs.core >> as the file name.) This is on a non-corrupted file >> system. I was avoiding trying to look at files from >> a corrupted file system. >> > > Ahh! found it. > -rw------- 1 root wheel 119074816 Feb 11 20:02 fsck_ffs.core > > It's been placed in > http://www.zefox.net/~fbsd/rpi3/ But the debugger inforation/symbols from your system are needed to get symbolic results from that file. My instance of main is not going to be a match. You need to be the one getting the backtrace from your system. >> >> This presumes that you have the time to wait vs. having >> to quickly just start over after quickly taking a >> riskier route if it fails. > > Time isn't an issue at all, in fact the system is expendable. > Mostly I brought the problem up out of surprise that what looked > like a routine panic on 13-stable could result in seemingly > un-fixable file system damage. > > In the meantime I'll try updating the 14-current system to see if > that makes a difference. If you already did, it is too late to use the fsck_ffs.core file unless you can revert and accurately reproduce the original 14-CURRENT so its symbols/debugger information can be used. === Mark Millard marklmi at yahoo.com From nobody Sun Feb 12 18:30:43 2023 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 4PFGJ541ZJz3qWYd for ; Sun, 12 Feb 2023 18:31:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (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 4PFGJ43xpJz3pbk for ; Sun, 12 Feb 2023 18:31:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=a7wPcOdP; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676226657; bh=D0MUEyJk5alMjE7Wy/b5VDQA+duYLKLM0HRljkwOvSA=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=a7wPcOdPUXwiMb47iwjAkSiXo+l/DhCiOHTnbbng5kE2MLhU7ozcSuFTYc1vEKSAJbi66YTctwiBr6bKGKhTVBADUyqo8I2IVI/Yi4Wm0WlmKgqTlbAPfyDfPxiAmqYAGXybr31XZyZgNu+P1hybC6NcbOlBCcpDZYI9o5tet/xm2O5pAs1H1e7qniDBXkfu34nCkVjJB+Z9/+SG7PJkRZHGU3ktoZSw1JGvyZCQY4QyhuXHwrWyobwo82+/peGqfu/AsDIyK8cPjii9mVhZ7BwFT08RyCJBjQBfle0KbWTBTQ8cIFw9zi1XpVDdQR9/HUMLva7UZXgZvTxHUYWn+g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676226657; bh=nGzRswPgOFOjht7AJapW0z35v4upo+PkHRm1Bu1pIbi=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=PAEUeB0c2kp/lJEhTWaLTHaAFNRCkOZAnwzz2P27q9+KBGOXL8k3GQTsHPhY2x9s1ybKE/ySt8rGIkMdCV6GmezJvi6Lvrs1eirA4gei9fI1pX//3XuhCtFP7xLSku+Q2XbuQ34nwky5wMpLJ2k5c+XzUaw1ULyIht6sIeCw2fv55wf/jWR1lX5VXwou+AE3hMBdQhA0nNomjxNw9rVGi5V3JBqVkKKmvbSnk2Eu0s3Rj0PDbRGhdmGXnSswPv8ujOcSJluPaVbREXTzI3+7oRlHYHXvsmtAjuRqIRkjP3VMdLAypwW/kSbJoghYzqKNqPHLvtfXDK3KsUHgU7LGuQ== X-YMail-OSG: SMElcI8VM1mwy5nDIYDWZoQvLs989yTckv0DevbrkhqOcfVbLLlm56YYWJt.mcA bE1L1bEBDX8XrW51NlI4rM7MFpH_HomrWxj3U5TKzTk.lnZMXcqylIGbtO6hwDxlWr8XQDdWsPkO LZo0tyjyd32rwxAV.fH7vsJt_PxiYeEUxm_9h05CfXd99C9ReJGhu.1ud1LJ7n4BKVHiJZQBci0M eLFTsu1yeXcoV_MT86pntTNG9RJIpCWqRYELWjRBXEp2z5fRvMKAQVdkmi_B6f76_S4c0rxUVnxs _gSYTjJsLZwR3J1yZ4VAewIa9ylwA4MInsMS1Pyv.XvINCSor_lFMNSV1tEe0OLOGaaKQV7T8xzq Q9U0Xg23I1oPwmeiMMTW_u4H1LfTUQfH3G9TnH2TUCxFwmIn_1XK9w.maW0AzyYozPM2XUcKnGKO gqE9Jqslm7wkzP06u6ZivwVMvlsxJ1f15HE8lJm7Gb5qEXA6kqT_dyZrFc687z4lYRQfg9Gc1HfR m_4YMheLD9P0h_APor061HS9pybaFaCoAMdyyfg0o5QjjM4FsEqavZpikR1N.CcJ9ng1j.dTu.xK Mkx_Ooh87sDSE5pHhnrzdwqJMfoRo..5eQsB42m7sO2lvYIscnDHTi7xGRYHfFL2Vg.Fv_lO0APV QQOEQ0J3g9yRXEdWPiUwiuQnnmFImvzY.njHekjD1aAAF2ssWJt0rnsMWnqpNCg24.Rjs.mlQgWh gtLWs.1HQ1T8QqZe0B9UZZEO1sUxicxwpVxFNV_YycGBL2jfF4v4SdhtQNgElPBwWuNwX1bl5FVS 211G3LhcvoHtT1Y5cB6dNqu12ih_S91TeD4Hk9T3ds4EhiscLHCDkvMkX..AocgE.6F6oxnuRRfc Ixz4LteF.bA24SrtQUsgmu7KUv1AE2LjBNoDqJQ.TWmCvRdKxXcP7qqTLXwR58L1vLzxK7W0zHQN lh707qPD0Olyw_WYxRcxh6iYZ2RDUOf3EnQgeVXXXVVz3f6tTiAsUMJJLrzHSLfLYvSfq54X0n8e 0_ypMoSHvBxBYvnCCkiycBY6Pdk_BdOvZDZLLjtC0Cb.cqf6b6uf57nyfbR0bAcMo1kq78706KTj UNWU58ANBYj7AFVAf2SwKGR2dTibap29pmrLoZ1HyO06vxzAqlJy4Wg2A5tnF2F.wJmlJL0BC4EK 1pgY.LOgokotRs.BObKTobhesRDoflUvkeamOrAFVM98VC3tpLrHpkenvOZJDU_4dISpMGcY3j22 sf7YmM9PPsgoTxm9r0.CwhrGpcWnfUkAMo183Dlx8zD0A_t8YyuyVHPb56ej3lhLrNbSDXax0ubW UMEB2UGDm5yMGKhCB46GHTfauJ.6BSXCT_qOmyz9uLUCroDvvrd25I4s7UtcUoHf2EzsOU9uVXzA uK0n7UqF6dEaKcLl_iCYNiLuB2Da7Hp9dbGge4Q71Uho0cvS6c2Q77CEmVyhaWhdGpxqpbWmYEmp nAZOcDmjjRUl8zvcpexDi6aK34OORv83dpz2jwxhr38cJzlrY5o4c8geOCMVEhDe7DTAlryPxARf 4e.0Kg.AwEgC5z5fdmCVybERIAHgv6vcV4cnFXNPmJPvHOWsmp6yfKAbFVxJ4Mq9873EYte86RYx SmLGW8I1tp2kjJZFOxLvrxSV0iWX0n27T3Rq2eWbdLY2r2gVUrXR76yDyB.O9dNThFjgY2fHtk0d OdCnMMbr7MUBibw9pwnVGzmusBJfwQpHDS37.sSerBLhdV3pWuDHPVdN.LzxuradPoaCJnVB84.2 pIAbRj6DZtwSC2rg15NBhHiHohDo1NU9xJqyC3boXSjjtMbUV0cMiffcCiwwMU0P9ChKA5FmxAd2 qFTWTnfOx0Sy7.vVr.VDHs8Md1HtPnK7w04vA8RccwzCOq5g3Q32QAYIMX2w8qQ0x4PT8IfLNly3 ubhLIToZnd1DD3cwHAE5HX9ieChqk39.xiAO2xL772wfDNoTcrcW4Z8pE6wLBU515dA29ObRBFTt 6oPACHKja6ZlayJ.Rr_n1kXQi1LzR_SXMvy9vW9RGKLaP52i3vCDhGnHsPauXsgYNekPlPbZ5wvN K4TU4gYsK7zR7fYOXIEw8l1evq_aIAZJvJMWiwXsTC8ZGGr89AhlN4k8GfnZim.WNiHhUROGl8gQ 6uWC3cZukObzPJZiLFQv4se5SDplH4jpQvZYtpCAHgt7jSzFRv4qokocqqyvBYIweJje8tbr0_Ra YiLT_u5AVB7dJJTt6fhifWCRIOuINCQViMCgOYp5kj3xO1eADGEdI0MXcJyfY1qOhzLVns3amRRb K7w-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sun, 12 Feb 2023 18:30:57 +0000 Received: by hermes--production-bf1-57c96c66f6-76kbw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bcd734e14547388b65776b667d7c00b6; Sun, 12 Feb 2023 18:30:55 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: fsck segfaults on rpi3 running 13-stable From: Mark Millard In-Reply-To: Date: Sun, 12 Feb 2023 10:30:43 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <9A93D530-1AC4-455F-B8C9-FD1C83E04D30@yahoo.com> References: <20230211224057.GA17805@www.zefox.net> <9DC74DD9-9AA1-4822-B425-217AAC7DB3F5@yahoo.com> <20230212043524.GA19401@www.zefox.net> <984314A1-FF42-4F92-A212-6BC0D85CB630@yahoo.com> <20230212165333.GB19401@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Spamd-Result: default: False [-3.32 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.82)[-0.821]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from] X-Rspamd-Queue-Id: 4PFGJ43xpJz3pbk X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Feb 12, 2023, at 09:21, Mark Millard wrote: > On Feb 12, 2023, at 08:53, bob prohaska wrote: >> >> On Sat, Feb 11, 2023 at 09:21:29PM -0800, Mark Millard wrote: >>> On Feb 11, 2023, at 20:35, bob prohaska wrote: >>> >>>> On Sat, Feb 11, 2023 at 06:57:41PM -0800, Mark Millard wrote: >>>>> On Feb 11, 2023, at 14:40, bob prohaska wrote: >>>>> >>>>>> While running buildworld on a Pi3 running 13-stable the machine >>>>>> panic'd. On restart using the previous kernel fsck failed with a >>>>>> segfault, which repeated when the disk was moved to a -current Pi3. >>>>>> >>>>> >>>>> Did it produce a *.core file? >>>>> >>>> >>>> The 13-current host, looking at the 13-stable disk, reports >>>> root@www:~ # savecore -C -v /dev/da1s2b >>>> checking for kernel dump on device /dev/da1s2b >>>> mediasize = 2147483648 bytes >>>> sectorsize = 512 bytes >>>> magic mismatch on last dump header on /dev/da1s2b >>> >>> 14-CURRENT? >>> >> Yes. >> >>> For system crash dumps, they may need to be handled by the same >>> type of system that produced them. (Thus the "magic mismatch"?) >>> >>> However, I was not actually after that in my question. I >>> was after fsck crash file(s), not system crash information. >>> (Also useful, just for different purposes.) >>> >>> >>> I was not after the original system crash information >>> in my question. I was after what might have been recorded >>> when fsck was run and failed. >>> >>> So, since you ran a fsck under 14(?)-CURRENT, the file >>> system for 14(?)-CURRENT might have a *.core file from >>> the fsck run. (Unsure for fsck.core vs. fsck_ffs.core >>> as the file name.) This is on a non-corrupted file >>> system. I was avoiding trying to look at files from >>> a corrupted file system. >>> >> >> Ahh! found it. >> -rw------- 1 root wheel 119074816 Feb 11 20:02 fsck_ffs.core >> >> It's been placed in >> http://www.zefox.net/~fbsd/rpi3/ > > But the debugger inforation/symbols from your system are > needed to get symbolic results from that file. My instance > of main is not going to be a match. > > You need to be the one getting the backtrace from your > system. > >>> >>> This presumes that you have the time to wait vs. having >>> to quickly just start over after quickly taking a >>> riskier route if it fails. >> >> Time isn't an issue at all, in fact the system is expendable. >> Mostly I brought the problem up out of surprise that what looked >> like a routine panic on 13-stable could result in seemingly >> un-fixable file system damage. >> >> In the meantime I'll try updating the 14-current system to see if >> that makes a difference. > > If you already did, it is too late to use the fsck_ffs.core > file unless you can revert and accurately reproduce the > original 14-CURRENT so its symbols/debugger information > can be used. > I was too focused on the specific, already existing fsck_ffs.core file. If you update 14-CURRENT and it produces a new fsck_ffs.core file, you can just use that new one under the new 14-CURRENT to try to get a backtrace. No need to revert in that case. Sorry for the earlier noise. === Mark Millard marklmi at yahoo.com From nobody Sun Feb 12 19:13:08 2023 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 4PFHDD1W8Rz3qblj for ; Sun, 12 Feb 2023 19:12:44 +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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PFHDC4TH5z3vWd for ; Sun, 12 Feb 2023 19:12:43 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 31CJD8Cn021736 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 12 Feb 2023 11:13:08 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 31CJD8wa021735; Sun, 12 Feb 2023 11:13:08 -0800 (PST) (envelope-from fbsd) Date: Sun, 12 Feb 2023 11:13:08 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: fsck segfaults on rpi3 running 13-stable Message-ID: <20230212191308.GA21535@www.zefox.net> References: <20230211224057.GA17805@www.zefox.net> <9DC74DD9-9AA1-4822-B425-217AAC7DB3F5@yahoo.com> <20230212043524.GA19401@www.zefox.net> <984314A1-FF42-4F92-A212-6BC0D85CB630@yahoo.com> <20230212165333.GB19401@www.zefox.net> 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 In-Reply-To: X-Rspamd-Queue-Id: 4PFHDC4TH5z3vWd X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Sun, Feb 12, 2023 at 09:21:20AM -0800, Mark Millard wrote: > > But the debugger inforation/symbols from your system are > needed to get symbolic results from that file. My instance > of main is not going to be a match. > > You need to be the one getting the backtrace from your > system. > The -current system isn't updated yet, just running buildworld. There's no problem regenerating the core dump. I've gotten as far as root@www:~ # lldb --core ./fsck_ffs.core (lldb) target create --core "./fsck_ffs.core" Core file '/root/fsck_ffs.core' (aarch64) was loaded. (lldb) Typing "gui" brings up a curses window, but I've no idea what to do next. Some guidance will be needed to make further progress. Is there a beginners's tutorial somewhere? Apologies for the naive questions! bob prohaska From nobody Sun Feb 12 19:31:59 2023 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 4PFHfm680Gz3r8SW for ; Sun, 12 Feb 2023 19:32:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (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 4PFHfm3kxXz3x7Z for ; Sun, 12 Feb 2023 19:32:16 +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=1676230333; bh=gChyrj1/3fvCHNHV9Zc4v+GP5ONtmJm1CQQaQO5L+Zs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=Ef40Wp+M6uWjhlZQNS35AVutm7vxuYLRu5MwfLq80drTbA5NOJh1i/OCVPAF5/wnhMOjbSbVksBxhmXXi3+uTjgaX/qVESM56JgvFg3s23w1FzEFBl+h9LHXFexdsptr+NfDKmNDsK0uvmYBiI5QLIPuLmMvjET9Lns3PZOZqvfuo8ouNE8JM3OnN8FXJIVTk1q5LaxpnYN3Dvd1fMSEoeyhnzNSQH4O5Vp14yEf+TI2R3HXaUM5UP34cuThrPZkMOQhZ/nGEeXba2EN2xKMaeHt1EKGP5DIcDh0EA2s9QlQT+JMeQStyXPmNomfJvsxKO4uxs7aHEGcFDNW43RBHw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676230334; bh=XuHYwcccSzLEJNXbiF2WsynIE1L3XJZP3oJQY/2V/Jh=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=ZT3FIM5WWykSR0ahWYqrOKo/3BC/mFYH3s0fmmfkCI1GTExu2/gK//JEhW6ESv72QjSOu17aL1QZOkg7DhIVHDvZwVy1Yp2+Zk2gSOkNQUSUMRVJ843ZEvlA3hD5AcdV0j0UktfpvZScfdYMY9WnuGojAm37XD13c4O7LibDmPCh1l+r9NM/V43qQSf0HbZ9DvGtjJcx62d6rSD5M8Y459J3n+jZqNd3iIa7AEm+3j5psl9+JaV+IOm2mSwuWV+p+DN3b9JQdTrWeh+EXeafDX736E338nClGLE5qn1Strd+LduWC4Q5lRR40XCye85i6ZYEi+DWAPh9tIKe4Sl0Kg== X-YMail-OSG: vD_FO4QVM1nJcu6kudSfUezGg39rN1XNs2DU9uXesSUXTzKktWccfHFwWigps_K Yimgwz7jAOcmZEaMMGq3ow6TdO87Bk3t1CpKl4kkh_OYHk1DBlTr6DtNjWDMBU20rFsduAoBGA0O 1ExoSPqjF7MBAR1yRdw3jX02gb3i6rkS4pP0H3wl7j1kR6iHWNPJihRfAwGlq6.yyOSHLUB1WyPv IEqe_LXWzGVZoJpTBUkUrCElj_vwgeZ80qJ9cw1B7M0WWAv9uiSwvKLxKWYIApxKu772hGaKPGZn E7jfLUUlA.hwrbaw3L84zDqcG5GoDjvJzNc5qTj9Iwphi4Sa_nM37.8bSoGPsL78QCGrDimnMPBb YbPT8qnDpm1bAgGUeQZmJJCtu01be5jI.clBkRi8twzeMnU5jXnRqZDZhOEE.ovGc6F_0piQPcb0 U7xWxGEllE1DuGpOynv1cysO.5V5egzAOlBoE4UtOa462k319Wl2iLwl34ujA5NMkw0JQm5QdaCF jdskVT3_aR1.94RHtKXX0OFDLd4dAuqJGeIdSsvGeufWAZcvc18T3N.azkiSOAWf0SGszK15lqlZ 4qtCy2vjRaJnstG0ptAiyL4kFxY6w71DM9DM8HJjrrS6oMDp0J2G41uphXq12ECQ499_yWKgM5TK YIAkQ0IURWCSq6IauoF_QjmhO37W.mBcKSBaNMZP7vQg.eJX_4oaY2v6HJw1RVQ3o9qnapSDZ00T V0UEHHjpcLoaJgeo0WAB82.3mj6Frb.65DwKuKK0ZZLlGQfgt7HQpPm8PxAX8YN.T62_D0cD2o94 Nf9PSBRk7p14ujGhktzDDQ8xT76.Ml68wASsyNoK0i2IiHa7y7XfqTN2LvXJs1WuiQGvZ7e9_mSr lqnaqBrNwL.Loz_Bh9gJgK3VhCUhslPx6h2Wffy8jmmcNt8YXmfy42Mv88.p_ci9dj2FUiA8TRng Th3cfuj9hhymjUxcCgHSSwbAYT9Wix.UfcscTOn5pDmnWqB0bFyZpEztVMCkgOzH3N4nW19zsNGO dLwWfA.Gvmk9WIDLqNsSopr3PpBZ8bdviIhdLy088tD4BOvu6RSN9LP5bMOKE335vFf09Apgbg_h sB0nGqqlL8muFYzA2t7Qi8GHrNRrSfP9hNWLnXmPkY6NZZCTv1eYsQymT9JvJIiJWNAJYNDccSm_ HN3QGgLKqIXNCXuXvNNPCo8ass6uTudsxcG6djYqOAAPxB9pFAeBKEfo.EdhH6r9QRF1tjVq.Ydp XTGg3sGFHwhNnV5Tv_mf9wIZfMU_XH7NZF7W8YnvASQZlN2iulicYmPMYfP8yvLqi8iSrumSHZTX cnd7Ckou6Jz0ejXf8Ezrg81EOEPwOt.1oCN4xre8SvLLg1xlmP5eaZdyahOa_Vqwhe3tJ52avvNU LOIA4CTqQvwWnTIypyntlHl1IofnOYfthQSIu8NniyIjuabaA6cApnl9MOcegjstHpDm3EWDu92l Ju6O.Jm3HUSJso2J8uinmXIRLLf59zPKWexBMJn18NDPYV18tKlt1SccKRBNMHtPTjchwReG9VaS nSmZ3uwMScUswJaUl38EXmZM3ld5jTurZNKhZq2KVVGMULeVToTHkiHtVwy_JcQHijN3Pf9FB6UK yNHu6gKxGih2Gj3WBzAvdiXF6pfW2lQ1WSQVQjH1K23r5w91dkWpBTYbm.GCubTGpBnTZDUVaZDf K9lQaniZ_L91ZSEjrGWNSXS1Kt3NNmUM2g3aJ3rh_w7bIJKSpuqiEVKy3dYpa2W_1u8Ec2UAv1xm S6eynEE3BXUnslVh70miDl02AhtiZ0nDmUj_cNneTSojVUHEFy3.qbu.o2cbwTb7p6NDHjJTmZWQ 3FwJyIVttpg8dRXud9dTjT3mJd8tWTBhEp9nMcWDTTs2pNDcQ5OipWcsXnzjTt1apV1RWKT7xtY7 BFaSqsASO2HSypFuBwhD9chr3AgTuqpkl32WC.20rzAw09XQS3mpY60OHlbQDj4ZW8IESsdAlbxp OAJsAE5v9sD7sHab5UmIXGFctPxkWx8DP3Wf6H8WIujrDmzFhq8pin5JEwg26tI0tFP8.QLTp0GM gBWKCQjtQJGeHjcuUHy30It4KRY.rZTwsYiPxrtRRQSqLRu.3vJ60q4_mClP8Q0Lr90xifzYMJju x3J0Bq3S0M4XKD6VQ4z2502QIjeyxcymMAObVqP2gpHHypWROMtdj38Ngmt3iQCdWb.tP5sdnj09 9F5mOLTVIg7nNLqpnoBcrtkYYlvy.TU_mNsVPbPgz2UXVfHlH6IvyrmtZL0EKeh7_47JI0G57Eq5 d X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sun, 12 Feb 2023 19:32:13 +0000 Received: by hermes--production-ne1-746bc6c6c4-8fvwf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID cdfeb7c91ab4e803c9f32f8117d88fd0; Sun, 12 Feb 2023 19:32:11 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: fsck segfaults on rpi3 running 13-stable From: Mark Millard In-Reply-To: <20230212191308.GA21535@www.zefox.net> Date: Sun, 12 Feb 2023 11:31:59 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20230211224057.GA17805@www.zefox.net> <9DC74DD9-9AA1-4822-B425-217AAC7DB3F5@yahoo.com> <20230212043524.GA19401@www.zefox.net> <984314A1-FF42-4F92-A212-6BC0D85CB630@yahoo.com> <20230212165333.GB19401@www.zefox.net> <20230212191308.GA21535@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4PFHfm3kxXz3x7Z X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 12, 2023, at 11:13, bob prohaska wrote: > On Sun, Feb 12, 2023 at 09:21:20AM -0800, Mark Millard wrote: >>=20 >> But the debugger inforation/symbols from your system are >> needed to get symbolic results from that file. My instance >> of main is not going to be a match. >>=20 >> You need to be the one getting the backtrace from your >> system. >>=20 >=20 > The -current system isn't updated yet, just running buildworld.=20 > There's no problem regenerating the core dump. >=20 > I've gotten as far as >=20 > root@www:~ # lldb --core ./fsck_ffs.core > (lldb) target create --core "./fsck_ffs.core" > Core file '/root/fsck_ffs.core' (aarch64) was loaded. > (lldb)=20 >=20 > Typing "gui" brings up a curses window, but I've no > idea what to do next.=20 >=20 > Some guidance will be needed to make further progress. > Is there a beginners's tutorial somewhere? help in lldb reports: . . . bt -- Show the current thread's call stack. Any numeric = argument displays at most that many frames. The argument 'all' displays = all threads. Use 'settings set frame-format' to customize the printing of individual frames and 'settings set = thread-format' to customize the thread header. . . . So typing: bt all should attempt to produce a backtrace (of each thread). (There is both exit and quit to leave lldb.) I'll note that another option is to run fsck_ffs from lldb in the first place. The below is running: "fsck_ffs -n" (which is not really a valid command) # which fsck_ffs /sbin/fsck_ffs # lldb /sbin/fsck_ffs (lldb) target create "/sbin/fsck_ffs" Current executable set to '/sbin/fsck_ffs' (aarch64). (lldb) run -n Process 8977 launched: '/sbin/fsck_ffs' (aarch64) usage: fsck_ffs [-BCdEFfnpRrSyZ] [-b block] [-c level] [-m mode] = filesystem ... Process 8977 exited with status =3D 1 (0x00000001) (lldb)=20 So you would use something else than "-n". Mine, of course, does not stop for the problem, but once yours does, you could use the "bt all" command. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Feb 12 19:53:24 2023 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 4PFJ6g6ynBz3rBRm for ; Sun, 12 Feb 2023 19:52:59 +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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PFJ6g4yg0z41fx for ; Sun, 12 Feb 2023 19:52:59 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 31CJrOft021875 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 12 Feb 2023 11:53:24 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 31CJrORI021874; Sun, 12 Feb 2023 11:53:24 -0800 (PST) (envelope-from fbsd) Date: Sun, 12 Feb 2023 11:53:24 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: fsck segfaults on rpi3 running 13-stable Message-ID: <20230212195324.GB21535@www.zefox.net> References: <20230211224057.GA17805@www.zefox.net> <9DC74DD9-9AA1-4822-B425-217AAC7DB3F5@yahoo.com> <20230212043524.GA19401@www.zefox.net> <984314A1-FF42-4F92-A212-6BC0D85CB630@yahoo.com> <20230212165333.GB19401@www.zefox.net> <20230212191308.GA21535@www.zefox.net> 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 In-Reply-To: X-Rspamd-Queue-Id: 4PFJ6g4yg0z41fx X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Sun, Feb 12, 2023 at 11:31:59AM -0800, Mark Millard wrote: > > I'll note that another option is to run fsck_ffs from > lldb in the first place. That seems more productive, yielding: root@www:~ # lldb /sbin/fsck_ffs (lldb) target create "/sbin/fsck_ffs" Current executable set to '/sbin/fsck_ffs' (aarch64). (lldb) run -fy Process 62596 launched: '/sbin/fsck_ffs' (aarch64) usage: fsck_ffs [-BCdEFfnpRrSyZ] [-b block] [-c level] [-m mode] filesystem ... Process 62596 exited with status = 1 (0x00000001) (lldb) q root@www:~ # lldb fsck_ffs (lldb) target create "fsck_ffs" Current executable set to 'fsck_ffs' (aarch64). (lldb) run -fy /dev/da1s2d Process 62609 launched: '/sbin/fsck_ffs' (aarch64) ** /dev/da1s2d ** Last Mounted on /usr ** Phase 1 - Check Blocks and Sizes 7912408300994173476 BAD I=69393345 4313599915630302063 BAD I=69393345 -4473632163892877928 BAD I=69393345 8068741989830080453 BAD I=69393345 3857159125896022134 BAD I=69393345 -4354179704011695453 BAD I=69393345 7611175298055105740 BAD I=69393345 3985638883347136889 BAD I=69393345 -2495754894521232470 BAD I=69393345 7739654885841380823 BAD I=69393345 7912408300994173476 BAD I=69393351 4313599915630302063 BAD I=69393351 -4473632163892877928 BAD I=69393351 8068741989830080453 BAD I=69393351 3857159125896022134 BAD I=69393351 -4354179704011695453 BAD I=69393351 7611175298055105740 BAD I=69393351 3985638883347136889 BAD I=69393351 -2495754894521232470 BAD I=69393351 7739654885841380823 BAD I=69393351 7912408300994173476 BAD I=74682090 4313599915630302063 BAD I=74682090 -4473632163892877928 BAD I=74682090 8068741989830080453 BAD I=74682090 3857159125896022134 BAD I=74682090 -4354179704011695453 BAD I=74682090 7611175298055105740 BAD I=74682090 3985638883347136889 BAD I=74682090 -2495754894521232470 BAD I=74682090 7739654885841380823 BAD I=74682090 INODE CHECK-HASH FAILED I=74999808 OWNER=1842251117 MODE=15044 This version of LLDB has no plugin for the language "assembler". Inspection of frame variables will be limited. Process 62609 stopped * thread #1, name = 'fsck_ffs', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) frame #0: 0x00005c6f47c3d550 libc.so.7`strnlen at strnlen.S:50 47 bic src, srcin, 15 48 mov wtmp, 0xf00f 49 cbz cntin, L(nomatch) -> 50 ld1 {vdata.16b}, [src], 16 51 dup vrepmask.8h, wtmp 52 cmeq vhas_chr.16b, vdata.16b, 0 53 lsl shift, srcin, 2 (lldb) bt all * thread #1, name = 'fsck_ffs', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) * frame #0: 0x00005c6f47c3d550 libc.so.7`strnlen at strnlen.S:50 frame #1: 0x00005c6f47c08b48 libc.so.7`__vfprintf(fp=0x00005c6f47cd8b68, locale=0x00005c6f47cd84a8, fmt0="MTIME=%12.12s %4.4s ", ap=(__stack = 0x00005c6f45005c40, __gr_top = 0x00005c6f45005bd0, __vr_top = 0x00005c6f45005b90, __gr_offs = -48, __vr_offs = -128)) at vfprintf.c:854:25 frame #2: 0x00005c6f47c0752c libc.so.7`vfprintf_l(fp=0x00005c6f47cd8b68, locale=0x00005c6f47cd84a8, fmt0="MTIME=%12.12s %4.4s ", ap=(__stack = 0x00005c6f45005c40, __gr_top = 0x00005c6f45005bd0, __vr_top = 0x00005c6f45005b90, __gr_offs = -56, __vr_offs = -128)) at vfprintf.c:285:9 frame #3: 0x00005c6f47c09f94 libc.so.7`vfprintf(fp=, fmt0=, ap=) at vfprintf.c:292:9 frame #4: 0x00005c6f47c03dc0 libc.so.7`printf(fmt=) at printf.c:57:8 frame #5: 0x00005c6ec487edac fsck_ffs`prtinode(ip=) at inode.c:1314:2 frame #6: 0x00005c6ec487f000 fsck_ffs`getnextinode(inumber=74999808, rebuildcg=0) at inode.c:563:3 frame #7: 0x00005c6ec4882d5c fsck_ffs`pass1 [inlined] checkinode(inumber=74999808, idesc=0x00005c6f45005d20, rebuildcg=0) at pass1.c:254:12 frame #8: 0x00005c6ec4882d58 fsck_ffs`pass1 at pass1.c:181:8 frame #9: 0x00005c6ec488209c fsck_ffs`main [inlined] checkfilesys(filesys=) at main.c:446:2 frame #10: 0x00005c6ec48818b0 fsck_ffs`main(argc=1, argv=0x00005c6f45006138) at main.c:210:16 frame #11: 0x00005c6ec4877ec0 fsck_ffs`__start(argc=3, argv=0x00005c6f45006128, env=0x00005c6f45006148, cleanup=) at crt1_c.c:72:7 frame #12: 0x00007813def681d8 ld-elf.so.1`.rtld_start at rtld_start.S:41 (lldb) Does that make any sense? Thanks for writing! bob prohaska From nobody Sun Feb 12 21:00:17 2023 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 4PFKcL3N0xz3rK8v for ; Sun, 12 Feb 2023 21:00:18 +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 4PFKcK6f8kz48lJ for ; Sun, 12 Feb 2023 21:00:17 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1676235617; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=HRQvktgxm1I681bNV95YztwBGeUADpPpexx+j7NUxyk=; b=HOOjGOkugqt2wzXMkpw9c2GXro/wycnPJae8A0kanO3WF+rC5j5RncaWHnuUC8bmtiwUwk xl99DxapHvcmFN4BencmKcIgBZCOQAzCu+u9RoMHPfqns+yFQ7r6eqy1qUwNAxlEdhAgo7 iGFoQ/JifSLTSXH2o5RWcYljYcQ9H0j3R83R1l2s31jJNnU8lfidBMI1s5fbZRc5KROYJH DV7DQ0TSWZ0d+OvYTGGzzeNNDkLulTKAW8nPLq36UYDXI0wzlSFv+uGU4BvItTkQzkc0tG oYHv+iC5is+RefzOVAVehJ4QpdbBZIH0VLRyDMlpWt8cY02pwiYj/IwiczKEpg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1676235617; a=rsa-sha256; cv=none; b=K5C5R/uatOn+wBDKrAWR4uxtlXJmfaNiwXXmwk/F780/4U2ryQkF01vLjVtbf0UI32nxbm WF4eMvNqW3llLWD93IOLY9vHP3OQ1B6w+/Z6C77pEO6ZijF98FhFrl9y0t/SF9xLNWAilh NY6ypZasbkNWf2tCztb5DKWqb1rlYF76T9yIN2u1DEQjcupem6j741sd9IPqZmerztZb2j PytDWFeHKbWl+pV+vC7S3z8nKggoWzbVa+DBAbb6UXcN1sAzMBtZnQQB5adOIfMQKaUAt4 yiLT33oSJu0MOI0tSn+W/f2ufmotZ5wlsQSS7lWgA8HWMy0eAZQbTbyrm7zMHw== 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 4PFKcK5m1CzsDm for ; Sun, 12 Feb 2023 21:00:17 +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 31CL0Hi5020502 for ; Sun, 12 Feb 2023 21:00:17 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 31CL0HYL020501 for freebsd-arm@FreeBSD.org; Sun, 12 Feb 2023 21:00:17 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202302122100.31CL0HYL020501@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention Date: Sun, 12 Feb 2023 21:00:17 +0000 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: multipart/alternative; boundary="16762356175.bdfcaA2.18574" Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N --16762356175.bdfcaA2.18574 Date: Sun, 12 Feb 2023 21:00:17 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off Open | 257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat 2 problems total for which you should take action. --16762356175.bdfcaA2.18574 Date: Sun, 12 Feb 2023 21:00:17 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" 
The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status      |    Bug Id | Description
------------+-----------+---------------------------------------------------
Open        |    238576 | Raspberry Pi 3B+ "shutdown -p" does not shut off 
Open        |    257670 | mpr(4): SAS3008 PCI-Express Fusion-MPT SAS-3: Fat

2 problems total for which you should take action.
--16762356175.bdfcaA2.18574-- From nobody Sun Feb 12 21:25:32 2023 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 4PFL9r64Vcz3p8gF for ; Sun, 12 Feb 2023 21:25:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (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 4PFL9r1PRXz4Ktj for ; Sun, 12 Feb 2023 21:25:52 +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=1676237150; bh=r+4C5sWthKSxRTkS1yGPu+OmOkMCvRgONJm52BV2gic=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=FcoAGc+6odlgaDDTX01Tj0fQ7pdGoyzsaCBblR0n5Tk8C/5vTQSY1HS/ITd9noYQ2uMnQ/oWQEqDmmk8B+mlRMskCin8bc1Z1sYa0p84hbWGA6zA16vduVAYAb6T4c3IKc4F5h4cl3sT2xksO7gfSRRSfDKRwqBM1z5NW5gP7XtfdHb7iE2GRaholWyLd1ba11kbb4fXscKauBNeGyD/W656we+zwYZ2VB3CYM/sf2/QRHK2ELr9cn3alBtM9i4671++2VnCxkwGlORdVx5XTMZGVX6mY9vhaKeLpFLPi/nnRjSTTp12woHew7A9zzdelHguRdTU/ROduT5YjTIRJg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676237150; bh=HwDVjbu6yjGnogn+wEHLP8JVvx+W9QjXiF4qdm625ZF=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=lYcKBD8EgmCf+DvzEnVzh5NHTNRLKg/EUJ/i4Rmvw7tRlNdDHNF8uUQNYhLzT4UFqcGFeqUMHbQbQtshasxRK4U9a2jbI023AEncFJFr6bf4KNCqpEb2WBsf7aNaL36/rDrLK3n40ZVBNT/NSyK1DLKajtmXXQo4SFGpdSWg7f7N0gdTuu5tE1tZ7BbcGoea7EGf/PVN4NMj0WPwsh1fBllsxPnNj4Ij6HKbRxMxkOei66bUM74MhBbNx9n+HUFayaGHDtsav2zLhDoHppKCh0JDkBgyDfvNxx0GfKaNnBmThHUBCOBp7BXanGC2GvNsBfSmFe8hfOWfBgyEFq5maQ== X-YMail-OSG: ojGQ.dAVM1miy_Rh.OBr2BXeV7h0Oir9QemIetrx41p0d0ba7Njiav5xFGDTF6m X1BM.cXeCMzbJ.MjvdV4OUsmJqadxGlq61HFjXyfElBE5rl8Y43YFaxu0Zxgbi9D_jnFOSt9Zr2A UHh2LA7OVQ_Gp_T4E9Xvg1Ols1Dhh7OdtlCBoIopdBMrG9STC86Q4FyCnDpD0PhOugiAY3mAhuhn WRNcvgrm0qhDANoD0tO59KKlElyZ6URu8gH_nDOy6cyH8P92odJ51wn1tPY2GSqXHTjHvr8TYNVQ kW_bu_dTlT1zeDY3TN7uvAkkT2TCcbqq5ZXiTwOsc_NMJV9bwIVp9efl24dwsZ78_o9pfBzJ.O8j imT_ceKWJSdVlgnEOL11ZWhX81CDiNMvN4FeCDp1Iluu1V9qWZJ47YkRyf3HQLcYsw_3jq7tauLC ePCfdpaHtX6fvrVRj4TwYJoVxGevhuf.FyRZupq1H_eSH8KTSzKB2H374_w8epy4f75A2vgnPvoa LGjPDlgd2Nsc0o.6013WwhedYv21L.Muz_GjFKIJPLH_6ppD04e8K8k7iFj_LgRFEi_.pdsbYBAk i_00bITYMQ2BIzOBHyfWYcy.k5KVD6FTy4V5WwLdVbWV4zaKfIUxGho4ubbCP08QFWAoOvRK46Xk xRzvQEGOcsTN0pWxRAtDlv_8EfhLlcY9.6V8hR0qI8ctgV6TJ0JogHymyJ0ApxPBns0UbAUlHUYQ cL6YZsL09h7mQ94JeXZH7jcLvIeq8UupQKfuCyPt4j8ZNYG0nRyKRjeSgt0mT2zCJ3v4i0pRM.KP Qig5iIC4KMlKJ5d10nTdyWj8Ad6TmznOf_WO2w5NNX2t7pbg4zN.fJ6DQb8GlI1Xzk9kOK.V.zpX S5a65gnUa6nXNXkFZ8OszFqKVadRjG0lDhZPq_k7SuYG.t3hiOUx90zblTntsjB2T5GciWboKpfz Fxr2Ql8UlSj3nI.4jbpjngobJVn0bKjIYMDoKTMFHjlS90Niw3445H176r16KiRr._6inm3Q6UbJ 3vWyuBXuMFp4LYZnTY0vlAtV2VppBc0.x4CpyEVqJWOrbNBeF5xX0aPYm3HCwRNgicpmnJ7MWtDu KzWiyEqindDgqbXR9t219WKJV.yrfD4w9IO2UylXjF_9ETr8Ptph3vLCaMr8EhwYavsSVJyJV5BO BMQcN1jRjuJ9PmIVxXch9Xxcxg9KEsfRq2D8A0WKgN23I0aiolDXi1ALX_OVcfM619v2kTv3ArS_ LSoGq3OdgObLbCK0OFaY5_CL_x_t1.UCbLFvgGiF5GmxF8dBBgZfn_pZTkTgResB.VAoITZB57hG Ig.gUqXdFclatmfTKmZnQnYQ31TkiKoC3I7s_ABL7CETfU76lxZgmyGYQEicQJCccuyjYdzvZPxw rzZaXQcfdcE_PBKrU.8UidxEqETi29c1yeiMOK_Y2SVRWcEbLCaXypfICXrJNIk3OsvdcOjsQ0r_ lnxMsgWzo3zxIcmJX1kUF6BMRY00J6OFVjFuI9A58Bfa1JzmTQLuS549I1BW8UF2ep1Ga5.8R10X _K37PpX.3MpkBtoiCPUqCgWjP34aj2aXxwIWmt6RZwJV9w0nEqRm4RJjsGnsnMUNrTWccZ5IS60d 1DNcK8MsZ6T9eg9DKfXc7NkEv70701dKwerQpBuvpL_rbNhOFT7QPEHx3StaxQBX1JVqYTCwCL45 CWFGFQuumD7pB0p9kHZjOl4XWEHxewORHwPh.wjF_52eWe55.d43sM6cki8tXOs4aqkPvQbsUPGH DfiGLtb7wumC5rBRRx1XlHKubCg.8yCmM47Y55d2tg2kIFPk264RXUmmpA2hPLjyY3JM0W_GPFjd QxLq5Ua8w_310hEd9DdPxRy0nQ_DVnSU.g6.iQRO1UDpRtGhNityIef6eNU.7GQF2rS0FOD2CAPj 1Wpi1NGqrmcGBpdSOxQXwKIK_M74dvNXc4XM.s8CvPk6imD19U_AV0r4CsdETmtNUUfUklWiPNj9 dU2osMBcqHH5HSDYqudDFVhDzO1FmXrwKhQpjcyOPSraK6d1YoZrVGvFkOW476xcg5iXocQlMBob ttZ7TmUQPT4sED1_gomJFsiF55G5BXJPQErbmrHXK8oOrGGpKu2gyR.2IegV9dhbh5HaXdRrXJCK TUUEcTP2MdltlGrMEQlgh9S0_Cuh15JHs1Rjjlk0V1JvigxyBVvdPAjPCipItVQUdj6h0KH.zIlP zMYMw8_MXLlh4r0Zn5jNcyyyrHrScn47Aw28mEMqaMUhfWFlNgb4fBeSdpAYdaASxA4aNvaGYLT_ GRhRtMbAH1mo- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sun, 12 Feb 2023 21:25:50 +0000 Received: by hermes--production-bf1-57c96c66f6-hmvtp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 8863ed9c40677febb79963d3e4810830; Sun, 12 Feb 2023 21:25:44 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash) From: Mark Millard In-Reply-To: <20230212195324.GB21535@www.zefox.net> Date: Sun, 12 Feb 2023 13:25:32 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <03840D0B-13D4-4F22-BDAF-2887A4D78BED@yahoo.com> References: <20230211224057.GA17805@www.zefox.net> <9DC74DD9-9AA1-4822-B425-217AAC7DB3F5@yahoo.com> <20230212043524.GA19401@www.zefox.net> <984314A1-FF42-4F92-A212-6BC0D85CB630@yahoo.com> <20230212165333.GB19401@www.zefox.net> <20230212191308.GA21535@www.zefox.net> <20230212195324.GB21535@www.zefox.net> To: bob prohaska , "mckusick@freebsd.org" X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4PFL9r1PRXz4Ktj X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N [With a backtrace for the fsck_ffs SIGSEGV crash and some listing of code involved, I'm now including mckusick@FreeBSD.org = in the To: . Kirk M. likely would like you to preserve the problematical UFS file system that produces the fsck_ffs crashes, at least for now. For Kirk M.: The below is from/for the fsck_ffs attempted from 14-CURRENT.] On Feb 12, 2023, at 11:53, bob prohaska wrote: > On Sun, Feb 12, 2023 at 11:31:59AM -0800, Mark Millard wrote: >>=20 >> I'll note that another option is to run fsck_ffs from >> lldb in the first place.=20 >=20 > That seems more productive, yielding: >=20 > root@www:~ # lldb /sbin/fsck_ffs > (lldb) target create "/sbin/fsck_ffs" > Current executable set to '/sbin/fsck_ffs' (aarch64). > (lldb) run -fy > Process 62596 launched: '/sbin/fsck_ffs' (aarch64) > usage: fsck_ffs [-BCdEFfnpRrSyZ] [-b block] [-c level] [-m mode] = filesystem ... > Process 62596 exited with status =3D 1 (0x00000001)=20 > (lldb) q > root@www:~ # lldb fsck_ffs > (lldb) target create "fsck_ffs" > Current executable set to 'fsck_ffs' (aarch64). > (lldb) run -fy /dev/da1s2d > Process 62609 launched: '/sbin/fsck_ffs' (aarch64) > ** /dev/da1s2d > ** Last Mounted on /usr > ** Phase 1 - Check Blocks and Sizes > 7912408300994173476 BAD I=3D69393345 > 4313599915630302063 BAD I=3D69393345 > -4473632163892877928 BAD I=3D69393345 > 8068741989830080453 BAD I=3D69393345 > 3857159125896022134 BAD I=3D69393345 > -4354179704011695453 BAD I=3D69393345 > 7611175298055105740 BAD I=3D69393345 > 3985638883347136889 BAD I=3D69393345 > -2495754894521232470 BAD I=3D69393345 > 7739654885841380823 BAD I=3D69393345 > 7912408300994173476 BAD I=3D69393351 > 4313599915630302063 BAD I=3D69393351 > -4473632163892877928 BAD I=3D69393351 > 8068741989830080453 BAD I=3D69393351 > 3857159125896022134 BAD I=3D69393351 > -4354179704011695453 BAD I=3D69393351 > 7611175298055105740 BAD I=3D69393351 > 3985638883347136889 BAD I=3D69393351 > -2495754894521232470 BAD I=3D69393351 > 7739654885841380823 BAD I=3D69393351 > 7912408300994173476 BAD I=3D74682090 > 4313599915630302063 BAD I=3D74682090 > -4473632163892877928 BAD I=3D74682090 > 8068741989830080453 BAD I=3D74682090 > 3857159125896022134 BAD I=3D74682090 > -4354179704011695453 BAD I=3D74682090 > 7611175298055105740 BAD I=3D74682090 > 3985638883347136889 BAD I=3D74682090 > -2495754894521232470 BAD I=3D74682090 > 7739654885841380823 BAD I=3D74682090 > INODE CHECK-HASH FAILED I=3D74999808 OWNER=3D1842251117 MODE=3D15044 > This version of LLDB has no plugin for the language "assembler". = Inspection of frame variables will be limited. > Process 62609 stopped > * thread #1, name =3D 'fsck_ffs', stop reason =3D signal SIGSEGV: = invalid address (fault address: 0x0) > frame #0: 0x00005c6f47c3d550 libc.so.7`strnlen at strnlen.S:50 > 47 bic src, srcin, 15 > 48 mov wtmp, 0xf00f > 49 cbz cntin, L(nomatch) > -> 50 ld1 {vdata.16b}, [src], 16 > 51 dup vrepmask.8h, wtmp > 52 cmeq vhas_chr.16b, vdata.16b, 0 > 53 lsl shift, srcin, 2 > (lldb) bt all > * thread #1, name =3D 'fsck_ffs', stop reason =3D signal SIGSEGV: = invalid address (fault address: 0x0) > * frame #0: 0x00005c6f47c3d550 libc.so.7`strnlen at strnlen.S:50 > frame #1: 0x00005c6f47c08b48 = libc.so.7`__vfprintf(fp=3D0x00005c6f47cd8b68, locale=3D0x00005c6f47cd84a8,= fmt0=3D"MTIME=3D%12.12s %4.4s ", ap=3D(__stack =3D 0x00005c6f45005c40, = __gr_top =3D 0x00005c6f45005bd0, __vr_top =3D 0x00005c6f45005b90, = __gr_offs =3D -48, __vr_offs =3D -128)) at vfprintf.c:854:25 > frame #2: 0x00005c6f47c0752c = libc.so.7`vfprintf_l(fp=3D0x00005c6f47cd8b68, locale=3D0x00005c6f47cd84a8,= fmt0=3D"MTIME=3D%12.12s %4.4s ", ap=3D(__stack =3D 0x00005c6f45005c40, = __gr_top =3D 0x00005c6f45005bd0, __vr_top =3D 0x00005c6f45005b90, = __gr_offs =3D -56, __vr_offs =3D -128)) at vfprintf.c:285:9 > frame #3: 0x00005c6f47c09f94 libc.so.7`vfprintf(fp=3D, = fmt0=3D, ap=3D) at vfprintf.c:292:9 > frame #4: 0x00005c6f47c03dc0 libc.so.7`printf(fmt=3D) = at printf.c:57:8 > frame #5: 0x00005c6ec487edac fsck_ffs`prtinode(ip=3D) = at inode.c:1314:2 > frame #6: 0x00005c6ec487f000 = fsck_ffs`getnextinode(inumber=3D74999808, rebuildcg=3D0) at = inode.c:563:3 > frame #7: 0x00005c6ec4882d5c fsck_ffs`pass1 [inlined] = checkinode(inumber=3D74999808, idesc=3D0x00005c6f45005d20, rebuildcg=3D0) = at pass1.c:254:12 > frame #8: 0x00005c6ec4882d58 fsck_ffs`pass1 at pass1.c:181:8 > frame #9: 0x00005c6ec488209c fsck_ffs`main [inlined] = checkfilesys(filesys=3D) at main.c:446:2 > frame #10: 0x00005c6ec48818b0 fsck_ffs`main(argc=3D1, = argv=3D0x00005c6f45006138) at main.c:210:16 > frame #11: 0x00005c6ec4877ec0 fsck_ffs`__start(argc=3D3, = argv=3D0x00005c6f45006128, env=3D0x00005c6f45006148, = cleanup=3D) at crt1_c.c:72:7 > frame #12: 0x00007813def681d8 ld-elf.so.1`.rtld_start at = rtld_start.S:41 > (lldb) =20 >=20 > Does that make any sense? It gives some context for the internal failure, for sure. I do not see a direct NULL pointer possibility in what I report that I looked at below. It leaves me wondering if something has trashed some memory (stack?) content that is involved. The backtrace indicates a NULL pointer was dereferenced: * thread #1, name =3D 'fsck_ffs', stop reason =3D signal SIGSEGV: = invalid address (fault address: 0x0) * frame #0: 0x00005c6f47c3d550 libc.so.7`strnlen at strnlen.S:50 The "-> 50 ld1 {vdata.16b}, [src], 16" for strnlen indicates that the code is from (given where I have main's source): /usr/main-src/contrib/arm-optimized-routines/string/aarch64/strnlen.S ENTRY (__strnlen_aarch64) PTR_ARG (0) SIZE_ARG (1) bic src, srcin, 15 mov wtmp, 0xf00f cbz cntin, L(nomatch) ld1 {vdata.16b}, [src], 16 . . . This is via the strnlen use in the /usr/main-src/lib/libc/stdio/vfprintf.c code below (leading white space might not be preserved): . . . int __vfprintf(FILE *fp, locale_t locale, const char *fmt0, va_list ap) { . . . case 's': if (flags & LONGINT) { wchar_t *wcp; =20 if (convbuf !=3D NULL) free(convbuf); if ((wcp =3D GETARG(wchar_t *)) =3D=3D = NULL) cp =3D "(null)"; else { convbuf =3D __wcsconv(wcp, = prec); if (convbuf =3D=3D NULL) { fp->_flags |=3D __SERR; goto error; } cp =3D convbuf; } } else if ((cp =3D GETARG(char *)) =3D=3D NULL) cp =3D "(null)"; size =3D (prec >=3D 0) ? strnlen(cp, prec) : = strlen(cp); sign =3D '\0'; break; . . . There are multiple layers involving va_list before we get down to printf in printf.c . I've not tried to validate this va_list related handling. Looking back at code that is inside fsck_ffs source files that leads to the printf usage (and indirectly to the other libc.so code involved) . . . So the code around /usr/main-src/sbin/fsck_ffs/inode.c:1314 looks like: (leading white space might not be preserved) void prtinode(struct inode *ip) { char *p; union dinode *dp; struct passwd *pw; time_t t; dp =3D ip->i_dp; printf(" I=3D%lu ", (u_long)ip->i_number); if (ip->i_number < UFS_ROOTINO || ip->i_number > maxino) return; printf(" OWNER=3D"); if ((pw =3D getpwuid((int)DIP(dp, di_uid))) !=3D NULL) printf("%s ", pw->pw_name); else printf("%u ", (unsigned)DIP(dp, di_uid)); printf("MODE=3D%o\n", DIP(dp, di_mode)); if (preen) printf("%s: ", cdevname); printf("SIZE=3D%ju ", (uintmax_t)DIP(dp, di_size)); t =3D DIP(dp, di_mtime); p =3D ctime(&t); printf("MTIME=3D%12.12s %4.4s ", &p[4], &p[20]); } That, in turned, was called via: ( /usr/main-src/sbin/fsck_ffs/inode.c ) . . . union dinode * getnextinode(ino_t inumber, int rebuildcg) { . . . dp =3D (union dinode *)nextinop; if (sblock.fs_magic =3D=3D FS_UFS1_MAGIC) nextinop +=3D sizeof(struct ufs1_dinode); else nextinop +=3D sizeof(struct ufs2_dinode); if ((ckhashadd & CK_INODE) !=3D 0) { ffs_update_dinode_ckhash(&sblock, (struct ufs2_dinode = *)dp); dirty(&inobuf); } if (ffs_verify_dinode_ckhash(&sblock, (struct ufs2_dinode *)dp) = !=3D 0) { pwarn("INODE CHECK-HASH FAILED"); ip.i_bp =3D NULL; ip.i_dp =3D dp; ip.i_number =3D inumber; prtinode(&ip); if (preen || reply("FIX") !=3D 0) { if (preen) printf(" (FIXED)\n"); ffs_update_dinode_ckhash(&sblock, (struct ufs2_dinode *)dp); dirty(&inobuf); } } . . . In turn: ( /usr/main-src/sbin/fsck_ffs/pass1.c ) . . . static int checkinode(ino_t inumber, struct inodesc *idesc, int rebuildcg) { . . .=20 if ((dp =3D getnextinode(inumber, rebuildcg)) =3D=3D NULL) { pfatal("INVALID INODE"); goto unknown; } . . . In turn (same file): void pass1(void) { . . . /* * Scan the allocated inodes. */ setinodebuf(c, inosused); for (i =3D 0; i < inosused; i++, inumber++) { if (inumber < UFS_ROOTINO) { (void)getnextinode(inumber, rebuildcg); continue; } /* * NULL return indicates probable end of = allocated * inodes during cylinder group rebuild attempt. * We always keep trying until we get to the = minimum * valid number for this cylinder group. */ if (checkinode(inumber, &idesc, rebuildcg) =3D=3D = 0 && i > cgp->cg_initediblk) break; } . . . With that I stop. So far, I've not identified how the NULL pointer showed up that ended up being dereferenced. It does not look likely that I will identify such. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Feb 13 23:25:19 2023 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 4PG0nH4LPSz3r6s2 for ; Mon, 13 Feb 2023 23:25:23 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gold.funkthat.com [IPv6:2001:470:800b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PG0nG54Lzz3Q9C; Mon, 13 Feb 2023 23:25:22 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 2001:470:800b::2) smtp.mailfrom=jmg@gold.funkthat.com; dmarc=none Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 31DNPJ0d065424 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 13 Feb 2023 15:25:20 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 31DNPJn8065423; Mon, 13 Feb 2023 15:25:19 -0800 (PST) (envelope-from jmg) Date: Mon, 13 Feb 2023 15:25:19 -0800 From: John-Mark Gurney To: Mark Millard Cc: bob prohaska , "mckusick@freebsd.org" , freebsd-arm@freebsd.org Subject: Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash) Message-ID: <20230213232519.GD95670@funkthat.com> Mail-Followup-To: Mark Millard , bob prohaska , "mckusick@freebsd.org" , freebsd-arm@freebsd.org References: <20230211224057.GA17805@www.zefox.net> <9DC74DD9-9AA1-4822-B425-217AAC7DB3F5@yahoo.com> <20230212043524.GA19401@www.zefox.net> <984314A1-FF42-4F92-A212-6BC0D85CB630@yahoo.com> <20230212165333.GB19401@www.zefox.net> <20230212191308.GA21535@www.zefox.net> <20230212195324.GB21535@www.zefox.net> <03840D0B-13D4-4F22-BDAF-2887A4D78BED@yahoo.com> 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 In-Reply-To: <03840D0B-13D4-4F22-BDAF-2887A4D78BED@yahoo.com> X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Mon, 13 Feb 2023 15:25:20 -0800 (PST) X-Spamd-Result: default: False [-1.80 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; MIME_GOOD(-0.10)[text/plain]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FREEMAIL_TO(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[jmg]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[funkthat.com]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PG0nG54Lzz3Q9C X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N Mark Millard wrote this message on Sun, Feb 12, 2023 at 13:25 -0800: > [With a backtrace for the fsck_ffs SIGSEGV crash and some > listing of code involved, I'm now including mckusick@FreeBSD.org > in the To: . Kirk M. likely would like you to preserve the > problematical UFS file system that produces the fsck_ffs > crashes, at least for now. For Kirk M.: The below is from/for > the fsck_ffs attempted from 14-CURRENT.] > > On Feb 12, 2023, at 11:53, bob prohaska wrote: > > > On Sun, Feb 12, 2023 at 11:31:59AM -0800, Mark Millard wrote: > >> > >> I'll note that another option is to run fsck_ffs from > >> lldb in the first place. > > > > That seems more productive, yielding: [...] > So the code around /usr/main-src/sbin/fsck_ffs/inode.c:1314 looks > like: (leading white space might not be preserved) > > void > prtinode(struct inode *ip) > { > char *p; > union dinode *dp; > struct passwd *pw; > time_t t; > dp = ip->i_dp; > printf(" I=%lu ", (u_long)ip->i_number); > if (ip->i_number < UFS_ROOTINO || ip->i_number > maxino) > return; > printf(" OWNER="); > if ((pw = getpwuid((int)DIP(dp, di_uid))) != NULL) > printf("%s ", pw->pw_name); > else > printf("%u ", (unsigned)DIP(dp, di_uid)); > printf("MODE=%o\n", DIP(dp, di_mode)); > if (preen) > printf("%s: ", cdevname); > printf("SIZE=%ju ", (uintmax_t)DIP(dp, di_size)); > t = DIP(dp, di_mtime); > p = ctime(&t); > printf("MTIME=%12.12s %4.4s ", &p[4], &p[20]); > } [...] > So far, I've not identified how the NULL pointer showed up > that ended up being dereferenced. It does not look likely > that I will identify such. Ok, decided to run AFL on fsck, and this one was the first crash it discovered. The problem is that ctime can return NULL, and the return value isn't checked, because it then immediately does &p[4] which results is printf and friends being passed 0x4. Simple test program that demonstrates this problem: #include #include int main() { const char *p; time_t t; t = -5098919203113507862; p = ctime(&t); printf("MTIME=%12.12s %4.4s ", &p[4], &p[20]); return 0; } I'm not sure what the correct fix is for when times are wildly out of valid range. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Tue Feb 14 00:15:17 2023 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 4PG1vD28Bfz3rD33 for ; Tue, 14 Feb 2023 00:15:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (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 4PG1vC5583z3kj3 for ; Tue, 14 Feb 2023 00:15:35 +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=1676333733; bh=ZQ45vFIIYYf7ESM2RuIj5zTUkAOdq9FSPWJYmJ6xopw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=RJSLY7K1fAQB+5tXjPojZIYBbJNF3zvT15kegFzZ3yp68Q2SVUnlqiI3gLoJhVuHmngsmik1BeGLFRPpOlGGw1uuct1sE4Wsu1DvlCcCnDObGKwxE4VfvNMsUKDNEIrx6Ol6F3e6XZ6uZI19YmRqIhty/oOg2cdPW/Kuz0ZfOF4crbgxKupxRzDCUml1agpHFyvWlYfF25He/5uetrkWUDz/VqXvBKiWF2G9OEfxnO0p4DGoruiMxWBQ5icPajmX7YR1CHSXXe8ifa3Q0JdwpETDweLOmnhQyzvjZdNVuYNZyzPY9u9M3Chu7V+tXalOPbFVL9OmyjdSz0J1oakSPw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676333733; bh=UvKIXLOja5YsLwXWUrqEz8gvSuT74VGv4+Eigv9M4X0=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=RwCSTYDcQoLTg1MW2VWf6S8JQysQYrDvgFTrIzDOtN+U4A3vpeE7JZqr+04tlM0nr0MT+W2e7La7d0IR88IJWjLEaFQVgIpvuYIjkPrI+Dq32y/VelX+uq1OeMzpEbtFgLsvQrn2iWHtEN6WzjP0D0j40+I7wFtV3PWmxC4XIjGr+Hz6eErjgFE7EJ2O9Y3cTfIoLPyNjs4PGBEw0urA0XgkHMrZ3ZeIiDRNga6xRZmI3s37WNJrulWpvu7W+yWQCBCJeQ9AyU04uiTWhfxJIbOibgyiashTraZEtGKuB0H2PeJ/HxDtN1vdmnMkrPuF/nLRXl7MMI6nZqHOQvQqKA== X-YMail-OSG: HveYy74VM1lt_hs4TUvthXPpVgrCc_8bYYBZzToJVGWnWSfyInXrtdvGiLuLvlb xS56HVKZaXgleTQanJjgk2KUE5Bh3kZNCa_KmlpPOOzxpyrc5hLGgqc_7FhnEqN.81lceM7cB_7r F5NTC8E8Y1MwXSZwH7sotT2VRQ_7WeKC5A_gX8Q4MWgGEPrawKIh0rNxENEEF35g9_OIfTnliD98 vb5qcQDqxEIXfDqJaMklUOMihc1SEC6SHtlHj9Zys97imQzGhiT8xWWC7q1reVznmlAasmaSqwuU btwXCSZr7zvr7QyqHjJXTBZpg6e91nxCABt4tuEBUCuCn54fyT_SXZ8dX7x4SBqJW_v.NhUiaXFN uzPefsbnx3hyC5579YN3xF1o7IqcFSNy0KxWFljcCWoqobCl0o1QWaJbAu8h_VBIuIQ3Ug_VfBSh x1QQI9bzIOl8Vr3NhB16Ri62fdG08S_kkNK3pKptxwuZT503Dlu6J0BWgXB_Ylmxp6FoLxsNMj_g ws0EkoJnmg5M_UIUMm8jJ16M.O8kY1Tfh_c4uhurwN9RQspkKszcjaSFr_ERobXH1u.gOGCOiCdk pCxcHs6RpMd2fThnA2FJgGTHCCytvxA7d1Zl0V5FE6qmvvz6qJUDbasbZFr8iWzMDraNi8jT4Nha NEf1xO62vdl7I5m68ILkPdN6CePYVT1hcdAK7GynRLGbs87sb7tww.GVfQv3KSSOFFrYYL5.osws 13lRgorY2ApI.GmMrbulejfVbGCtvLdJj8nZ_wAsheoMiQ2oKBpNpaHNqUZFT7B6k68MA5XPyMe7 TzpTRXfQB6eRGzW6GwMMCn6Zfp9yJUuM_NOB3yqeR96blNTsCPhojapnZ4dkZyy6vb_9iyvdjr5R taK2Od9diqkiisA.vxG0KjcuPcogB8gRnp_rTwAKOESOiOR_rq_u76EMCJrM2dXX1c9K3PiiIENm PVhalApcU5tjejbqf3SRe9evgxdt5quXl2JMILjtVvz4owcTLp.aVzeoaxC6EBTXLd1OzAAZupBT q0uTHZGiPnHraE8WuQ.pku6zlQRpSeKV98KJ2xgQmugsIU2aYnViNDLSZxDyY.hCXnMd71029tYH .Ga1wWioIAIOrFF558qVOkTKMSyzQ6KBpayHKVxdzTOdcBn4.E9Dq2R1k1qSR2NtNCRAqRuMTWyf qUyU3Ctun4Lq0C5rEImGUT8pEtkWxRJw4dQ0mcRWP70h56uAMMhOfA3vzo8XZNLCLEVwmwpJIFSy I0g912hb1IA3iF9v3tBCpyGGzs5T2TSPkUEf3NXDMDeHOKH5pEmAGDEVBwQeYr6RdQrYbsaqc7PW qZ_QQ1nsul7iZQP7AtexxX6WLT4smQKvN7KgX4VUJkmWVrlx4RpLc.4tIEUsTP.pEWpLTIrnPJ40 cB0sE4gNHmv5vJ5FYrgb4Qe.ra_gMcQsxKizqF9pzUYwz50oqiWrNxEXB_LKJgMYn79xSfLD.PPW 7oBh07ChFnJi.rV5cvqGUUK9MIDJonQKF34or5Sl1Nn.Kvn7pV9HHgiYdg51Mi_7qVLa_bClYOB_ yIVkPe_PeJL.7zUnsi4M.vSdTpNWHaa2HZLpM4Tbh0nawZqBhuqCH_8T0wImhRS9pZXa0IItxT6m g0nTjcn0DqyE_x7qYPSqab6cxwE5ouvU4L4iE12wL8VtSBYHwmPSJ6ScLvP5NXUWdmLqjzMvM0d5 8Kh3BdC1pntmK5Tu6wAlqUK3fNZXsoPiZdJakv_kbTlpac1BjH0qcWb10Su3rVniuf1FujdEfNQR Rg822x6I7JVSwr5x7hLqKvAMdI.enhuOjRi3hpQBXn4kF_x7lKlSAYgbtoum7Vcj6B9JQ_lLfHGs bx3.Fd.nHsi8PY_wZLVGCaUg8K.Og_mWk7brnadiYJ5OP7ydkLiCJ2prcAPQ8ewwsy2qY7bFy_EY .I1X5i5JOTWKHQcOzkLAIJWPIgZn.SLoJQZ9k9GUR5gDR3duapFmscFz6aaeaSvW0qGJCGQCOHPo 2cMLfL.b8eq8O.kZVRWRB03SAVZjWXnhGSHKxe_ae.JME9ZxIBSOH9fnkumITrqTebNnFRvZ1x6H 2jMa48NpDf4kuTWAShJo6ZaLi.3E4kmsWF4fuZS1sJLLvfxS_WDfyskAZSDB6c580t.I6SR7ON88 YS.ksB7jrE47huFgNlalq.iDzGsSu0HkWTVRbD5lrfCnldL8iFZPmrlj0oIF.W_ZFDIa0mt7trw_ N5t..dBo0dhIYtd79Jo0j9CR.IPdnlneJ4a_Bor8cf7Bg942Q21ytcSLr54H2LDSTG0QQI7tDbw- - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Tue, 14 Feb 2023 00:15:33 +0000 Received: by hermes--production-bf1-57c96c66f6-hmvtp (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ab98c74d4e8fd5730e632639f8f1af70; Tue, 14 Feb 2023 00:15:30 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash) From: Mark Millard In-Reply-To: <20230213232519.GD95670@funkthat.com> Date: Mon, 13 Feb 2023 16:15:17 -0800 Cc: bob prohaska , "mckusick@freebsd.org" , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20230211224057.GA17805@www.zefox.net> <9DC74DD9-9AA1-4822-B425-217AAC7DB3F5@yahoo.com> <20230212043524.GA19401@www.zefox.net> <984314A1-FF42-4F92-A212-6BC0D85CB630@yahoo.com> <20230212165333.GB19401@www.zefox.net> <20230212191308.GA21535@www.zefox.net> <20230212195324.GB21535@www.zefox.net> <03840D0B-13D4-4F22-BDAF-2887A4D78BED@yahoo.com> <20230213232519.GD95670@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4PG1vC5583z3kj3 X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 13, 2023, at 15:25, John-Mark Gurney wrote: > Mark Millard wrote this message on Sun, Feb 12, 2023 at 13:25 -0800: >> [With a backtrace for the fsck_ffs SIGSEGV crash and some >> listing of code involved, I'm now including mckusick@FreeBSD.org = >> in the To: . Kirk M. likely would like you to preserve the >> problematical UFS file system that produces the fsck_ffs >> crashes, at least for now. For Kirk M.: The below is from/for >> the fsck_ffs attempted from 14-CURRENT.] >>=20 >> On Feb 12, 2023, at 11:53, bob prohaska wrote: >>=20 >>> On Sun, Feb 12, 2023 at 11:31:59AM -0800, Mark Millard wrote: >>>>=20 >>>> I'll note that another option is to run fsck_ffs from >>>> lldb in the first place.=20 >>>=20 >>> That seems more productive, yielding: >=20 > [...] >=20 >> So the code around /usr/main-src/sbin/fsck_ffs/inode.c:1314 looks >> like: (leading white space might not be preserved) >>=20 >> void >> prtinode(struct inode *ip) >> { >> char *p; >> union dinode *dp; >> struct passwd *pw; >> time_t t; >> dp =3D ip->i_dp; >> printf(" I=3D%lu ", (u_long)ip->i_number); >> if (ip->i_number < UFS_ROOTINO || ip->i_number > maxino) >> return; >> printf(" OWNER=3D"); >> if ((pw =3D getpwuid((int)DIP(dp, di_uid))) !=3D NULL) >> printf("%s ", pw->pw_name); >> else >> printf("%u ", (unsigned)DIP(dp, di_uid)); >> printf("MODE=3D%o\n", DIP(dp, di_mode)); >> if (preen) >> printf("%s: ", cdevname); >> printf("SIZE=3D%ju ", (uintmax_t)DIP(dp, di_size)); >> t =3D DIP(dp, di_mtime); >> p =3D ctime(&t); >> printf("MTIME=3D%12.12s %4.4s ", &p[4], &p[20]); >> } >=20 > [...] >=20 >> So far, I've not identified how the NULL pointer showed up >> that ended up being dereferenced. It does not look likely >> that I will identify such. >=20 > Ok, decided to run AFL on fsck, and this one was the first crash it > discovered. The problem is that ctime can return NULL, and the return > value isn't checked, because it then immediately does &p[4] which > results is printf and friends being passed 0x4. >=20 > Simple test program that demonstrates this problem: > #include > #include >=20 > int > main() > { > const char *p; > time_t t; >=20 > t =3D -5098919203113507862; >=20 > p =3D ctime(&t); >=20 > printf("MTIME=3D%12.12s %4.4s ", &p[4], &p[20]); >=20 > return 0; > } >=20 > I'm not sure what the correct fix is for when times are wildly out of > valid range. >=20 Thanks. Looks like C23 is making ctime and asctime deprecated, recommending strftime use. As for existing behavior vs. standards: C11, for example, just indicates that ctime(t) is equivalent to asctime(localtime(t)) . C11 also indicates that asctime goes to a "the behavior of the asctime function is undefined" status. NULL returns are only one of the possibilities as far as he language is concerned. POSIX indicates the more specific NULL return value handling for asctime (and, so, ctime too). =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Feb 14 08:05:30 2023 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 4PGDKT3ycfz3rN8n for ; Tue, 14 Feb 2023 08:05:33 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gold.funkthat.com [IPv6:2001:470:800b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PGDKS4mHbz3FSK for ; Tue, 14 Feb 2023 08:05:32 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 2001:470:800b::2) smtp.mailfrom=jmg@gold.funkthat.com; dmarc=none Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 31E85UvT011796 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 14 Feb 2023 00:05:30 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 31E85U2D011795 for freebsd-arm@FreeBSD.org; Tue, 14 Feb 2023 00:05:30 -0800 (PST) (envelope-from jmg) Date: Tue, 14 Feb 2023 00:05:30 -0800 From: John-Mark Gurney To: freebsd-arm@FreeBSD.org Subject: detecting qemu/HVF on Apple M1 silicon Message-ID: <20230214080530.GE95670@funkthat.com> Mail-Followup-To: freebsd-arm@FreeBSD.org 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-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Tue, 14 Feb 2023 00:05:30 -0800 (PST) X-Spamd-Result: default: False [-1.77 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.970]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arm@FreeBSD.org]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[funkthat.com]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[jmg]; ARC_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PGDKS4mHbz3FSK X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N I managed to get FreeBSD running via qemu on Apple M1 silicon, but out of the box vm detection isn't working causing hz to be set to 1000, and causing lots of cpu usage to happen. What are the recommended ways to detect this, so we can get vm_guest set? A little poking around, shows that there's an ACPI device that is promising: Device (FWCF) { Name (_HID, "QEMU0002") // _HID: Hardware ID Name (_STA, 0x0B) // _STA: Status Name (_CCA, One) // _CCA: Cache Coherency Attribute Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings { Memory32Fixed (ReadWrite, 0x09020000, // Address Base 0x00000018, // Address Length ) }) } Here's a complete list of _HID's: # acpidump -d | grep _HID | sort -u Name (_HID, "PNP0C02" /* PNP Motherboard Resources */) // _HID: Hardware ID Name (_HID, "PNP0C0F" /* PCI Interrupt Link Device */) // _HID: Hardware ID Name (_HID, "ACPI0007" /* Processor Device */) // _HID: Hardware ID Name (_HID, "ACPI0013" /* Generic Event Device */) // _HID: Hardware ID Name (_HID, "ARMH0011") // _HID: Hardware ID Name (_HID, "LNRO0005") // _HID: Hardware ID Name (_HID, "PNP0A08" /* PCI Express Bus */) // _HID: Hardware ID Name (_HID, "PNP0C0C" /* Power Button Device */) // _HID: Hardware ID Name (_HID, "QEMU0002") // _HID: Hardware ID There's also the usual virtio devices as well. # pciconf -l hostb0@pci0:0:0:0: class=0x060000 rev=0x00 hdr=0x00 vendor=0x1b36 device=0x0008 subvendor=0x1af4 subdevice=0x1100 virtio_pci0@pci0:0:1:0: class=0x020000 rev=0x00 hdr=0x00 vendor=0x1af4 device=0x1000 subvendor=0x1af4 subdevice=0x0001 virtio_pci1@pci0:0:2:0: class=0x038000 rev=0x01 hdr=0x00 vendor=0x1af4 device=0x1050 subvendor=0x1af4 subdevice=0x1100 xhci0@pci0:0:3:0: class=0x0c0330 rev=0x01 hdr=0x00 vendor=0x1b36 device=0x000d subvendor=0x1af4 subdevice=0x1100 none0@pci0:0:4:0: class=0x040300 rev=0x01 hdr=0x00 vendor=0x8086 device=0x2668 subvendor=0x1af4 subdevice=0x1100 virtio_pci2@pci0:0:5:0: class=0x010000 rev=0x00 hdr=0x00 vendor=0x1af4 device=0x1001 subvendor=0x1af4 subdevice=0x0002 -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Tue Feb 14 09:24:02 2023 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 4PGG4C3fCvz3rSXl for ; Tue, 14 Feb 2023 09:24:11 +0000 (UTC) (envelope-from SRS0=upKc=6K=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4PGG4C14gSz3NZP for ; Tue, 14 Feb 2023 09:24:11 +0000 (UTC) (envelope-from SRS0=upKc=6K=klop.ws=ronald-lists@realworks.nl) Authentication-Results: mx1.freebsd.org; none Date: Tue, 14 Feb 2023 10:24:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1676366643; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6I48occBtTHPy/7UDs2CbrCZ65b34ADu+/OOPGAu/kw=; b=RwUV/7A3ETMQN6So85XGhdc4pSedccp6VvYvZUz1RvACtNju5Mbx3vMDRiRbBv6M+P05cK /Q4HNFIiZ6p7tiGOBe7ED42t426g791AheF0VzCi9hnuRL2OrHfJBDW9EHM4jy6Bb5mE3H D9KcREG7eB8HYNdcXjK7Ijq7b7LGID0Py/t4QHf1z6XLhC343AxcjgTdBF+mOAueZQWU8N OJWoNUCg4gr6aO/W30pfOuyMTv6xf86/W1JYRAIbj6AnRVMgZ2Men6q1JWQ2Do4cCA2HAI CfseLQc00BU/wH73U7R36NNgVUvHKUx4x2/x8LcIURZPz5H1hPs1cGYDAIqnxA== From: Ronald Klop To: John-Mark Gurney Cc: freebsd-arm@FreeBSD.org Message-ID: <306917284.1.1676366642956@mailrelay> In-Reply-To: <20230214080530.GE95670@funkthat.com> References: <20230214080530.GE95670@funkthat.com> Subject: Re: detecting qemu/HVF on Apple M1 silicon 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: multipart/alternative; boundary="----=_Part_0_1079485241.1676366641320" X-Mailer: Realworks (644.1101) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4PGG4C14gSz3NZP X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N ------=_Part_0_1079485241.1676366641320 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Van: John-Mark Gurney Datum: dinsdag, 14 februari 2023 09:05 Aan: freebsd-arm@FreeBSD.org Onderwerp: detecting qemu/HVF on Apple M1 silicon >=20 > I managed to get FreeBSD running via qemu on Apple M1 silicon, but out > of the box vm detection isn't working causing hz to be set to 1000, and > causing lots of cpu usage to happen. >=20 > What are the recommended ways to detect this, so we can get vm_guest set? >=20 > A little poking around, shows that there's an ACPI device that is > promising: > Device (FWCF) > { > Name (_HID, "QEMU0002") // _HID: Hardware ID > Name (_STA, 0x0B) // _STA: Status > Name (_CCA, One) // _CCA: Cache Coherency Attribute > Name (_CRS, ResourceTemplate () // _CRS: Current Resource Se= ttings > { > Memory32Fixed (ReadWrite, > 0x09020000, // Address Base > 0x00000018, // Address Length > ) > }) > } >=20 > Here's a complete list of _HID's: > # acpidump -d | grep _HID | sort -u > Name (_HID, "PNP0C02" /* PNP Motherboard Resources */) /= / _HID: Hardware ID > Name (_HID, "PNP0C0F" /* PCI Interrupt Link Device */) /= / _HID: Hardware ID > Name (_HID, "ACPI0007" /* Processor Device */) // _HID: Hard= ware ID > Name (_HID, "ACPI0013" /* Generic Event Device */) // _HID: = Hardware ID > Name (_HID, "ARMH0011") // _HID: Hardware ID > Name (_HID, "LNRO0005") // _HID: Hardware ID > Name (_HID, "PNP0A08" /* PCI Express Bus */) // _HID: Hardwa= re ID > Name (_HID, "PNP0C0C" /* Power Button Device */) // _HID: Ha= rdware ID > Name (_HID, "QEMU0002") // _HID: Hardware ID >=20 > There's also the usual virtio devices as well. > # pciconf -l > hostb0@pci0:0:0:0: class=3D0x060000 rev=3D0x00 hdr=3D0x00 vendor=3D0x1b3= 6 device=3D0x0008 subvendor=3D0x1af4 subdevice=3D0x1100 > virtio_pci0@pci0:0:1:0: class=3D0x020000 rev=3D0x00 hdr=3D0x00 vendor=3D0= x1af4 device=3D0x1000 subvendor=3D0x1af4 subdevice=3D0x0001 > virtio_pci1@pci0:0:2:0: class=3D0x038000 rev=3D0x01 hdr=3D0x00 vendor=3D0= x1af4 device=3D0x1050 subvendor=3D0x1af4 subdevice=3D0x1100 > xhci0@pci0:0:3:0: class=3D0x0c0330 rev=3D0x01 hdr=3D0x00 vendor=3D0x1b3= 6 device=3D0x000d subvendor=3D0x1af4 subdevice=3D0x1100 > none0@pci0:0:4:0: class=3D0x040300 rev=3D0x01 hdr=3D0x00 vendor=3D0x808= 6 device=3D0x2668 subvendor=3D0x1af4 subdevice=3D0x1100 > virtio_pci2@pci0:0:5:0: class=3D0x010000 rev=3D0x00 hdr=3D0x00 vendor=3D0= x1af4 device=3D0x1001 subvendor=3D0x1af4 subdevice=3D0x0002 >=20 > --=20 > John-Mark Gurney Voice: +1 415 225 5579 >=20 > "All that I will do, has been done, All that I have, has not." > =C3=82=20 >=20 >=20 >=20 Hi, I'm using UTM as a wrapper around qemu. This gives me the following in dmes= g which might be a good hint. acpi0: "BOCHS" is also in the output of kenv. Although I'm not sure if this is a good indicator for qemu. Regards, Ronald. =C3=82=20 ------=_Part_0_1079485241.1676366641320 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Van: John-Mark Gurney <jmg@funkthat.com>
Datum: dinsdag, 14 februari 2023 09:05
Aan: freebsd-arm@FreeBSD.org
Onderwerp: detecting qemu/HVF on Apple M1 silicon

I managed to get FreeBSD running = via qemu on Apple M1 silicon, but out
of the box vm detection isn't working causing hz to be set to 1000, and
causing lots of cpu usage to happen.

What are the recommended ways to detect this, so we can get vm_guest set?
A little poking around, shows that there's an ACPI device that is
promising:
        Device (FWCF)
        {
            Nam= e (_HID, "QEMU0002")  // _HID: Hardware ID
            Nam= e (_STA, 0x0B)  // _STA: Status
            Nam= e (_CCA, One)  // _CCA: Cache Coherency Attribute
            Nam= e (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
            {             &nb= sp;   Memory32Fixed (ReadWrite,
            &nb= sp;       0x09020000,    =      // Address Base
            &nb= sp;       0x00000018,    =      // Address Length
            &nb= sp;       )
            })<= br>         }

Here's a complete list of _HID's:
# acpidump -d | grep _HID | sort -u
            &nb= sp;   Name (_HID, "PNP0C02" /* PNP Motherboard Resources */)=  // _HID: Hardware ID
            &nb= sp;   Name (_HID, "PNP0C0F" /* PCI Interrupt Link Device */)=  // _HID: Hardware ID
            Nam= e (_HID, "ACPI0007" /* Processor Device */)  // _HID: Hardware ID
            Nam= e (_HID, "ACPI0013" /* Generic Event Device */)  // _HID: Hardware ID<= br>             Nam= e (_HID, "ARMH0011")  // _HID: Hardware ID
            Nam= e (_HID, "LNRO0005")  // _HID: Hardware ID
            Nam= e (_HID, "PNP0A08" /* PCI Express Bus */)  // _HID: Hardware ID
            Nam= e (_HID, "PNP0C0C" /* Power Button Device */)  // _HID: Hardware ID             Nam= e (_HID, "QEMU0002")  // _HID: Hardware ID

There's also the usual virtio devices as well.
# pciconf -l
hostb0@pci0:0:0:0:  class=3D0x060000 rev=3D0x00 hdr=3D0x00 vendor=3D0x= 1b36 device=3D0x0008 subvendor=3D0x1af4 subdevice=3D0x1100
virtio_pci0@pci0:0:1:0: class=3D0x020000 rev=3D0x00 hdr=3D0x00 vendor=3D0x1= af4 device=3D0x1000 subvendor=3D0x1af4 subdevice=3D0x0001
virtio_pci1@pci0:0:2:0: class=3D0x038000 rev=3D0x01 hdr=3D0x00 vendor=3D0x1= af4 device=3D0x1050 subvendor=3D0x1af4 subdevice=3D0x1100
xhci0@pci0:0:3:0:   class=3D0x0c0330 rev=3D0x01 hdr=3D0x00 vendor= =3D0x1b36 device=3D0x000d subvendor=3D0x1af4 subdevice=3D0x1100
none0@pci0:0:4:0:   class=3D0x040300 rev=3D0x01 hdr=3D0x00 vendor= =3D0x8086 device=3D0x2668 subvendor=3D0x1af4 subdevice=3D0x1100
virtio_pci2@pci0:0:5:0: class=3D0x010000 rev=3D0x00 hdr=3D0x00 vendor=3D0x1= af4 device=3D0x1001 subvendor=3D0x1af4 subdevice=3D0x0002

-- 
  John-Mark Gurney        &nbs= p;     Voice: +1 415 225 5579

     "All that I will do, has been done, All that = I have, has not."
=C3=82 


Hi,

I'm using UTM as a wrapper around qemu. This gives me the following in dmes= g which might be a good hint.
acpi0: <BOCHS BXPC>

"BOCHS" is also in the output of kenv.

Although I'm not sure if this is a good indicator for qemu.

Regards,
Ronald.
=C3=82  ------=_Part_0_1079485241.1676366641320-- From nobody Tue Feb 14 09:48:10 2023 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 4PGGby19Smz3rTSC for ; Tue, 14 Feb 2023 09:48:14 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gold.funkthat.com [IPv6:2001:470:800b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PGGbx72Sfz3QC3 for ; Tue, 14 Feb 2023 09:48:13 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Authentication-Results: mx1.freebsd.org; none Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 31E9mAmg020308 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Feb 2023 01:48:10 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 31E9mAiE020306; Tue, 14 Feb 2023 01:48:10 -0800 (PST) (envelope-from jmg) Date: Tue, 14 Feb 2023 01:48:10 -0800 From: John-Mark Gurney To: Ronald Klop Cc: freebsd-arm@FreeBSD.org Subject: Re: detecting qemu/HVF on Apple M1 silicon Message-ID: <20230214094810.GF95670@funkthat.com> Mail-Followup-To: Ronald Klop , freebsd-arm@FreeBSD.org References: <20230214080530.GE95670@funkthat.com> <306917284.1.1676366642956@mailrelay> 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 In-Reply-To: <306917284.1.1676366642956@mailrelay> X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Tue, 14 Feb 2023 01:48:10 -0800 (PST) X-Rspamd-Queue-Id: 4PGGbx72Sfz3QC3 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Ronald Klop wrote this message on Tue, Feb 14, 2023 at 10:24 +0100: > Van: John-Mark Gurney > Datum: dinsdag, 14 februari 2023 09:05 > Aan: freebsd-arm@FreeBSD.org > Onderwerp: detecting qemu/HVF on Apple M1 silicon > > > > I managed to get FreeBSD running via qemu on Apple M1 silicon, but out > > of the box vm detection isn't working causing hz to be set to 1000, and > > causing lots of cpu usage to happen. > > > > What are the recommended ways to detect this, so we can get vm_guest set? > > > > A little poking around, shows that there's an ACPI device that is > > promising: > > Device (FWCF) > > { > > Name (_HID, "QEMU0002") // _HID: Hardware ID > > Name (_STA, 0x0B) // _STA: Status > > Name (_CCA, One) // _CCA: Cache Coherency Attribute > > Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings > > { > > Memory32Fixed (ReadWrite, > > 0x09020000, // Address Base > > 0x00000018, // Address Length > > ) > > }) > > } > > > > Here's a complete list of _HID's: > > # acpidump -d | grep _HID | sort -u > > Name (_HID, "PNP0C02" /* PNP Motherboard Resources */) // _HID: Hardware ID > > Name (_HID, "PNP0C0F" /* PCI Interrupt Link Device */) // _HID: Hardware ID > > Name (_HID, "ACPI0007" /* Processor Device */) // _HID: Hardware ID > > Name (_HID, "ACPI0013" /* Generic Event Device */) // _HID: Hardware ID > > Name (_HID, "ARMH0011") // _HID: Hardware ID > > Name (_HID, "LNRO0005") // _HID: Hardware ID > > Name (_HID, "PNP0A08" /* PCI Express Bus */) // _HID: Hardware ID > > Name (_HID, "PNP0C0C" /* Power Button Device */) // _HID: Hardware ID > > Name (_HID, "QEMU0002") // _HID: Hardware ID > > > > There's also the usual virtio devices as well. > > # pciconf -l > > hostb0@pci0:0:0:0: class=0x060000 rev=0x00 hdr=0x00 vendor=0x1b36 device=0x0008 subvendor=0x1af4 subdevice=0x1100 > > virtio_pci0@pci0:0:1:0: class=0x020000 rev=0x00 hdr=0x00 vendor=0x1af4 device=0x1000 subvendor=0x1af4 subdevice=0x0001 > > virtio_pci1@pci0:0:2:0: class=0x038000 rev=0x01 hdr=0x00 vendor=0x1af4 device=0x1050 subvendor=0x1af4 subdevice=0x1100 > > xhci0@pci0:0:3:0: class=0x0c0330 rev=0x01 hdr=0x00 vendor=0x1b36 device=0x000d subvendor=0x1af4 subdevice=0x1100 > > none0@pci0:0:4:0: class=0x040300 rev=0x01 hdr=0x00 vendor=0x8086 device=0x2668 subvendor=0x1af4 subdevice=0x1100 > > virtio_pci2@pci0:0:5:0: class=0x010000 rev=0x00 hdr=0x00 vendor=0x1af4 device=0x1001 subvendor=0x1af4 subdevice=0x0002 > > I'm using UTM as a wrapper around qemu. This gives me the following in dmesg which might be a good hint. > acpi0: > > "BOCHS" is also in the output of kenv. > > Although I'm not sure if this is a good indicator for qemu. Yeah, I saw that as well, and I don't believe that is a good indicator, because BOCHS is probably from the x86 emulator project. I did do some additional research after I sent the email, and HyperV uses the FADT acpi table, and it does look like qemu has code to generate the FADT table w/ QEMU as the hypervisor string, but for some reason the HVF code isn't triggering the generation of the FADT table. This seems like a promising way to detect it. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Tue Feb 14 16:14:15 2023 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 4PGR911WlMz3pfZF for ; Tue, 14 Feb 2023 16:13: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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PGR8z2vH8z4QZX for ; Tue, 14 Feb 2023 16:13: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.16.1/8.15.2) with ESMTPS id 31EGEF2e028293 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 14 Feb 2023 08:14:16 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 31EGEFR7028292 for freebsd-arm@freebsd.org; Tue, 14 Feb 2023 08:14:15 -0800 (PST) (envelope-from fbsd) Date: Tue, 14 Feb 2023 08:14:15 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash) Message-ID: <20230214161415.GA28276@www.zefox.net> References: <20230212043524.GA19401@www.zefox.net> <984314A1-FF42-4F92-A212-6BC0D85CB630@yahoo.com> <20230212165333.GB19401@www.zefox.net> <20230212191308.GA21535@www.zefox.net> <20230212195324.GB21535@www.zefox.net> <03840D0B-13D4-4F22-BDAF-2887A4D78BED@yahoo.com> <20230213232519.GD95670@funkthat.com> 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 In-Reply-To: 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)[-1.000]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[zefox.net]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PGR8z2vH8z4QZX X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N > On Feb 13, 2023, at 15:25, John-Mark Gurney wrote: > [huge snip] > > Ok, decided to run AFL on fsck, and this one was the first crash it > > discovered. The problem is that ctime can return NULL, and the return > > value isn't checked, because it then immediately does &p[4] which > > results is printf and friends being passed 0x4. > > > > Simple test program that demonstrates this problem: > > #include > > #include > > > > int > > main() > > { > > const char *p; > > time_t t; > > > > t = -5098919203113507862; > > > > p = ctime(&t); > > > > printf("MTIME=%12.12s %4.4s ", &p[4], &p[20]); > > > > return 0; > > } > > > > I'm not sure what the correct fix is for when times are wildly out of > > valid range. > > Is this a demonstration that the fsck segfault can be reproduced independtly of my particular corrupt filesystem? AFL is new to me. Thanks for reading, bob prohaska From nobody Tue Feb 14 18:38:27 2023 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 4PGVMp3rmmz3pq3H for ; Tue, 14 Feb 2023 18:38:30 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gold.funkthat.com [IPv6:2001:470:800b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PGVMp1Tbvz3nVC for ; Tue, 14 Feb 2023 18:38:29 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Authentication-Results: mx1.freebsd.org; none Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 31EIcRMN018722 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Feb 2023 10:38:28 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 31EIcRVi018721; Tue, 14 Feb 2023 10:38:27 -0800 (PST) (envelope-from jmg) Date: Tue, 14 Feb 2023 10:38:27 -0800 From: John-Mark Gurney To: bob prohaska Cc: freebsd-arm@freebsd.org Subject: Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash) Message-ID: <20230214183827.GG95670@funkthat.com> Mail-Followup-To: bob prohaska , freebsd-arm@freebsd.org References: <984314A1-FF42-4F92-A212-6BC0D85CB630@yahoo.com> <20230212165333.GB19401@www.zefox.net> <20230212191308.GA21535@www.zefox.net> <20230212195324.GB21535@www.zefox.net> <03840D0B-13D4-4F22-BDAF-2887A4D78BED@yahoo.com> <20230213232519.GD95670@funkthat.com> <20230214161415.GA28276@www.zefox.net> 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 In-Reply-To: <20230214161415.GA28276@www.zefox.net> X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Tue, 14 Feb 2023 10:38:28 -0800 (PST) X-Rspamd-Queue-Id: 4PGVMp1Tbvz3nVC X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N bob prohaska wrote this message on Tue, Feb 14, 2023 at 08:14 -0800: > > On Feb 13, 2023, at 15:25, John-Mark Gurney wrote: > > > [huge snip] > > > > Ok, decided to run AFL on fsck, and this one was the first crash it > > > discovered. The problem is that ctime can return NULL, and the return > > > value isn't checked, because it then immediately does &p[4] which > > > results is printf and friends being passed 0x4. > > > > > > Simple test program that demonstrates this problem: > > > #include > > > #include > > > > > > int > > > main() > > > { > > > const char *p; > > > time_t t; > > > > > > t = -5098919203113507862; > > > > > > p = ctime(&t); > > > > > > printf("MTIME=%12.12s %4.4s ", &p[4], &p[20]); > > > > > > return 0; > > > } > > > > > > I'm not sure what the correct fix is for when times are wildly out of > > > valid range. > > > > > Is this a demonstration that the fsck segfault can be reproduced > independtly of my particular corrupt filesystem? AFL is new to me. Yes, it is. It turns out that the FS to produce this failure is a LOT smaller than I expected when compresed, I have included it later in the email. The constant above was taken directly from the failing FS. AFL is a very useful tool, and found this crash and apparently 50+ other crashes in only 5-10 minutes of running... I'll be investigating a few of the other crashes as well, as fsck does ocassionally deal w/ untrusted fs's. Also, afl was a LOT easier to run than I expected (I had run it before, just not insturmented a FreeBSD program before), installed afl++-llvm from ports, went into the fsck_ffs dir, and ran: CC=/usr/local/afl++-llvm/bin/afl-cc CXX=/usr/local/afl++-llvm/bin/afl-c++ make I then created a simple starting file system: mkdir testcase_dir; cd testcase_dir touch -s 1m test.ufs; mdconfig -f test.ufs; newfs /dev/md0; mdconfig -d -u 0 cd .. And then ran it against that test case: mkdir findings_dir /usr/local/afl++-llvm/bin/afl-fuzz -i testcase_dir/ -o findings_dir/ /usr/obj/usr/src/arm64.aarch64/sbin/fsck_ffs/fsck_ffs -y @@ To get back the FS, pipe in the base64 blob below through: openssl enc -d -base64 | xz -d > somefile And then run fsck_ffs on it. /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj5A/9BKddAABv/f//o7f/Rz5IFXI5YVG4 kijmo4YH+e7kHoLTL8U6PAFLsX7JiopNL6MN2X+m44wjEVPgWRjFdYrid/i2lH8M asDdr70i7w1p4SshtpY7LOoHpyp/p6OA/Nr4LJfZY/Svg3PS8bkcs82fLVdnpkfj tUW1Xpr6aNEd/6QbigL574jJbAi7hGfKb+aPYEZG51EtkwtmWbD+1giJdwmV7G7L P60SrLFhLMkWYShiaZGwmHTmITH6V9auY9KAbvDFpTq7fB17vIarx47LLJU2Bq8x o79kER0IFPTVa8m+D8xxIzruoGIWSBjeR1mBJWloKHU/2hBBT2PyeiQJ1I8MWowC 1T4KtnO6LMJhB7du7B2Z1hEwvTd+kzqpEFZgUSh8DiepZqT+6udLxvvtOYX1mH/4 ICQiRFVdjat7bKSNnTiDJHm3qZY0LdpDEhhTCJBSW1qzBgnUjz9jyXe78HKNtZBY HLHfCf/FoMC/CCVZwQnBJpKKBqbgXDexv3Gr9ePWQw6U7y6eBT1f/eQTTevL/jI5 TOhjcquYE+N9Jw5xL+4dpMEoukZ8kJ+WQRZIbrSM6L6w+E46sXqRXybaYSpwDhZV +8z1drD1RDY+vN7T1/psQNLjZw/IdDjlwMoOl+3c6N/n2i/+O+4dfJ/eMPXv3B+f Aa5kf3xx2qhF3czcD9iXHzN0kZpq/hLlZCSZJkkLsPcdh1yNinQ11m/x6kENoSBg bW/tjCEH52ULIixG7G58hDEZulYjmPpHYFum0eK+LMKMYdR/cRCr2euttKV9kA5i oVsoH9YT+YKc6xsFSL17308iGLSRXq8RGqCrtJ1Xjx2RMep8E9ayDyKPRnCbhHnl +/0kLjYBWwd4bB8y4o1fb/4yCSHvU94Uw/CPYryh0q6Xnio62UwXZmFfI7fI/4W3 29olwCloEgW2HFkAYtIKkbMJWvSR2+jNCkO/HxeSwghxlXnwveagDzbITvLapf3C LAJZxE9A1UFzDct8OmgaHRrqDcYxH/tdDsHO7hd9BbDL9ESXHFJfRzWvOVtZFDjj E/GPukGiMCLQAysgeiOpDH0I8CQjuJQZNyOF1qTC3XOg0z7azMBMYaVR7FlQkOQA DsklKx4GMe957nMiXb65GcysKBTykwcwXd3rY/vG1wWm7Umrk7/fOcAuvKr3rXrw vUSHNVznSejKf4nytxSbfIOTj8iFSAN/u0T1XnmWgW6aEmzMWx963S2g/NA52/rW Th7Tcpw127SOWOZAPApe7LNe1Gjq+vXKw2plLWG3rLyOzcgBgenjlRAMVB+nyQqF w2Lxzs9MsIYIlh23lJCRRH/qOaaKMmXFWx1Od2NPXq2DPWCW/gzinQ0tElWcP54s ZyoYcU+a3jCZmLGLY2B1pZkJGllWNCUMBNMjlpKGoBY5G3kIfMbXeJu6aE9orbXI 9eVI88jLM+WoSCRZog8bD9oE94uTFbxBw0ka703C/dJsFCDFGdN7FzmsGv0zvDyA cLHzCVwEg5KfaAjqA1T2/WSB947h+3YPImuV8JQxNPjT15yskd26f+V4f2s5D2/6 ugXWgY4fRzN9xfL8TjMD7SY3wByyIAAAuBN40havWu4AAcMJ/p8QAL5WDYOxxGf7 AgAAAAAEWVo= -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Tue Feb 14 19:29:28 2023 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 4PGWVf4hDcz3psxg for ; Tue, 14 Feb 2023 19:29:30 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gold.funkthat.com [IPv6:2001:470:800b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PGWVf0xW5z3sP0; Tue, 14 Feb 2023 19:29:30 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of jmg@gold.funkthat.com has no SPF policy when checking 2001:470:800b::2) smtp.mailfrom=jmg@gold.funkthat.com; dmarc=none Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 31EJTSL8023423 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Feb 2023 11:29:28 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 31EJTSX9023422; Tue, 14 Feb 2023 11:29:28 -0800 (PST) (envelope-from jmg) Date: Tue, 14 Feb 2023 11:29:28 -0800 From: John-Mark Gurney To: Mark Millard , bob prohaska , "mckusick@freebsd.org" , freebsd-arm@freebsd.org Subject: Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash) Message-ID: <20230214192928.GH95670@funkthat.com> Mail-Followup-To: Mark Millard , bob prohaska , "mckusick@freebsd.org" , freebsd-arm@freebsd.org References: <9DC74DD9-9AA1-4822-B425-217AAC7DB3F5@yahoo.com> <20230212043524.GA19401@www.zefox.net> <984314A1-FF42-4F92-A212-6BC0D85CB630@yahoo.com> <20230212165333.GB19401@www.zefox.net> <20230212191308.GA21535@www.zefox.net> <20230212195324.GB21535@www.zefox.net> <03840D0B-13D4-4F22-BDAF-2887A4D78BED@yahoo.com> <20230213232519.GD95670@funkthat.com> 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 In-Reply-To: <20230213232519.GD95670@funkthat.com> X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Tue, 14 Feb 2023 11:29:29 -0800 (PST) X-Spamd-Result: default: False [-1.79 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.989]; FORGED_SENDER(0.30)[jmg@funkthat.com,jmg@gold.funkthat.com]; MIME_GOOD(-0.10)[text/plain]; R_SPF_NA(0.00)[no SPF record]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FREEMAIL_TO(0.00)[yahoo.com,www.zefox.net,FreeBSD.org,freebsd.org]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_NEQ_ENVFROM(0.00)[jmg@funkthat.com,jmg@gold.funkthat.com]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[jmg]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[funkthat.com]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PGWVf0xW5z3sP0 X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N John-Mark Gurney wrote this message on Mon, Feb 13, 2023 at 15:25 -0800: After analyzing the remaining crashes that were detected, the following was found.. This was done w/ a minimal FS, It is possible that it'll find more crashes w/ a slightly more complex FS, e.g. one w/ indirect blocks, and other file types. Note that FS's that exhibit these are available at: https://www.funkthat.com/~jmg/FreeBSD/ffs.afl/ ---- FIRST ---- std_checkblkavail doesn't check that blkno is within valid range, e.g. if blkno is negative, it'll segfault: 0x0000000000121d6c in std_checkblkavail (blkno=blkno@entry=-288230376151711688, frags=frags@entry=1) at /usr/src/sbin/fsck_ffs/fsutil.c:1149 1149 if (testbmap(blkno + j)) ---- SECOND ---- pass5 doesn't check that cg_nextfreeoff is sane/within range, this causes a large value to be passed to memset, in this case: #1 0x000000000012fee4 in pass5 () at /usr/src/sbin/fsck_ffs/pass5.c:241 241 memset(cg_inosused(newcg), 0, (size_t)(mapsize)); (gdb) print *newcg $7 = {cg_firstfield = 0, cg_magic = 590421, cg_old_time = 0, cg_cgx = 0, cg_old_ncyl = 0, cg_old_niblk = 0, cg_ndblk = 256, cg_cs = {cs_ndir = 0, cs_nbfree = 0, cs_nifree = 128, cs_nffree = 0}, cg_rotor = 0, cg_frotor = 0, cg_irotor = 0, cg_frsum = {0, 0, 0, 0, 0, 0, 0, 0}, cg_old_btotoff = 0, cg_old_boff = 0, cg_iusedoff = 168, cg_freeoff = 184, cg_nextfreeoff = 61341980, cg_clustersumoff = 54526164, cg_clusteroff = 54526232, cg_nclusterblks = 32, cg_niblk = 128, cg_initediblk = 128, cg_unrefs = 0, cg_sparecon32 = {0}, cg_ckhash = 3548071837, cg_time = 1676327229, cg_sparecon64 = {0, 0, 0}, cg_space = ""} and mapsize is: (gdb) print newcg->cg_nextfreeoff - newcg->cg_iusedoff $6 = 61341812 which overflows buf, which is MAXBSIZE, or 8k. ---- THIRD ---- allocino doesn't make sure that cg_iusedoff is sane. In this case, cg_iusedoff is 4294965672, which means that in allocino, the setbit function call will access invalid memory. 0x0000000000127168 in allocino (request=2, type=16877) at /usr/src/sbin/fsck_ffs/inode.c:1379 1379 setbit(cg_inosused(cgp), ino % sblock.fs_ipg); (gdb) print *cgp $14 = {cg_firstfield = 0, cg_magic = 590421, cg_old_time = 0, cg_cgx = 0, cg_old_ncyl = 0, cg_old_niblk = 0, cg_ndblk = 256, cg_cs = {cs_ndir = 2, cs_nbfree = 23, cs_nifree = 124, cs_nffree = 21}, cg_rotor = 0, cg_frotor = 0, cg_irotor = 0, cg_frsum = {0, 0, 0, 0, 0, 0, 0, 3}, cg_old_btotoff = 0, cg_old_boff = 0, cg_iusedoff = 4294965672, cg_freeoff = 183, cg_nextfreeoff = 284, cg_clustersumoff = 212, cg_clusteroff = 280, cg_nclusterblks = 32, cg_niblk = 128, cg_initediblk = 128, cg_unrefs = 0, cg_sparecon32 = {0}, cg_ckhash = 3548071837, cg_time = 1676327229, cg_sparecon64 = {0, 0, 0}, cg_space = "\017"} -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Tue Feb 14 21:06:01 2023 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 4PGYdZ2nZyz3q09M for ; Tue, 14 Feb 2023 21:05:38 +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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PGYdY2rcYz43cx for ; Tue, 14 Feb 2023 21:05:37 +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.16.1/8.15.2) with ESMTPS id 31EL61GZ029000 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 14 Feb 2023 13:06:02 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 31EL61f4028999 for freebsd-arm@freebsd.org; Tue, 14 Feb 2023 13:06:01 -0800 (PST) (envelope-from fbsd) Date: Tue, 14 Feb 2023 13:06:01 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash) Message-ID: <20230214210601.GA28959@www.zefox.net> References: <20230212165333.GB19401@www.zefox.net> <20230212191308.GA21535@www.zefox.net> <20230212195324.GB21535@www.zefox.net> <03840D0B-13D4-4F22-BDAF-2887A4D78BED@yahoo.com> <20230213232519.GD95670@funkthat.com> <20230214161415.GA28276@www.zefox.net> <20230214183827.GG95670@funkthat.com> 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 In-Reply-To: <20230214183827.GG95670@funkthat.com> X-Spamd-Result: default: False [-1.10 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[zefox.net]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PGYdY2rcYz43cx X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N On Tue, Feb 14, 2023 at 10:38:27AM -0800, John-Mark Gurney wrote: > bob prohaska wrote this message on Tue, Feb 14, 2023 at 08:14 -0800: > > > > Is this a demonstration that the fsck segfault can be reproduced > > independtly of my particular corrupt filesystem? AFL is new to me. > > Yes, it is. It turns out that the FS to produce this failure is a LOT > smaller than I expected when compresed, I have included it later in the > email. The constant above was taken directly from the failing FS. > > AFL is a very useful tool, and found this crash and apparently 50+ > other crashes in only 5-10 minutes of running... I'll be investigating > a few of the other crashes as well, as fsck does ocassionally deal w/ > untrusted fs's. > Would trying to run fsck on the corrupt filesystem from an 8GB Pi4 (also running -current) make any difference? I.e., might more physical RAM cover up the bug and allow fsck to complete successfully? Is there a plain-English description of how AFL works? I gather it manipulates input read by a program to discover improperly handled cases, but even that is far from certain. There's no hope of me doing anything useful with AFL. I'm merely curious. Thanks very much for writing! bob prohaska From nobody Tue Feb 14 23:27:46 2023 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 4PGcnk5wYSz3qPWD for ; Tue, 14 Feb 2023 23:27:54 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gold.funkthat.com [IPv6:2001:470:800b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PGcnk3F7Kz4Pyp for ; Tue, 14 Feb 2023 23:27:54 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Authentication-Results: mx1.freebsd.org; none Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id 31ENRkRC043412 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Feb 2023 15:27:47 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 31ENRkST043411; Tue, 14 Feb 2023 15:27:46 -0800 (PST) (envelope-from jmg) Date: Tue, 14 Feb 2023 15:27:46 -0800 From: John-Mark Gurney To: bob prohaska Cc: freebsd-arm@freebsd.org Subject: Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash) Message-ID: <20230214232746.GI95670@funkthat.com> Mail-Followup-To: bob prohaska , freebsd-arm@freebsd.org References: <20230212191308.GA21535@www.zefox.net> <20230212195324.GB21535@www.zefox.net> <03840D0B-13D4-4F22-BDAF-2887A4D78BED@yahoo.com> <20230213232519.GD95670@funkthat.com> <20230214161415.GA28276@www.zefox.net> <20230214183827.GG95670@funkthat.com> <20230214210601.GA28959@www.zefox.net> 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 In-Reply-To: <20230214210601.GA28959@www.zefox.net> X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Tue, 14 Feb 2023 15:27:47 -0800 (PST) X-Rspamd-Queue-Id: 4PGcnk3F7Kz4Pyp X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N bob prohaska wrote this message on Tue, Feb 14, 2023 at 13:06 -0800: > On Tue, Feb 14, 2023 at 10:38:27AM -0800, John-Mark Gurney wrote: > > bob prohaska wrote this message on Tue, Feb 14, 2023 at 08:14 -0800: > > > > > > Is this a demonstration that the fsck segfault can be reproduced > > > independtly of my particular corrupt filesystem? AFL is new to me. > > > > Yes, it is. It turns out that the FS to produce this failure is a LOT > > smaller than I expected when compresed, I have included it later in the > > email. The constant above was taken directly from the failing FS. > > > > AFL is a very useful tool, and found this crash and apparently 50+ > > other crashes in only 5-10 minutes of running... I'll be investigating > > a few of the other crashes as well, as fsck does ocassionally deal w/ > > untrusted fs's. > > > > Would trying to run fsck on the corrupt filesystem from an 8GB Pi4 > (also running -current) make any difference? I.e., might more physical > RAM cover up the bug and allow fsck to complete successfully? No, it will not. It's trying to access memory address 0x4 which does not exist, no matter how much memory. In this case, an inode's mtime is wildly incorrect. Here is a simple patch that will let it get farther, BUT, it doesn't necessarily mean that the kernel can properly handle the mtime: diff --git a/sbin/fsck_ffs/inode.c b/sbin/fsck_ffs/inode.c index 82338f4f8c08..d0892a822dc5 100644 --- a/sbin/fsck_ffs/inode.c +++ b/sbin/fsck_ffs/inode.c @@ -1311,7 +1311,10 @@ prtinode(struct inode *ip) printf("SIZE=%ju ", (uintmax_t)DIP(dp, di_size)); t = DIP(dp, di_mtime); p = ctime(&t); - printf("MTIME=%12.12s %4.4s ", &p[4], &p[20]); + if (p == NULL) + printf("MTIME=invalid "); + else + printf("MTIME=%12.12s %4.4s ", &p[4], &p[20]); } void If you can get the inode number (should be in the gdb backtrace in one of the frames), you can use fsdb to switch to the inode (inode ), and then set the mtime to something reasonable (mtime 0), and then fsck should complete as well... > Is there a plain-English description of how AFL works? I gather it > manipulates input read by a program to discover improperly handled > cases, but even that is far from certain. There's no hope of me doing > anything useful with AFL. I'm merely curious. You are correct. It insturments a program to see when it modifies the input, which branches it takes, and uses that to make better choices on how to mutate the input. In another email I sent the instructions on how I ran it, but I used: https://afl-1.readthedocs.io/en/latest/quick_start.html to figure/remind myself how to run it. Only difference is that instead of running ./configure, I used make instead in the correct directory of the FreeBSD src tree. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From nobody Wed Feb 15 00:29:46 2023 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 4PGf8f6RQ9z3qTBj for ; Wed, 15 Feb 2023 00:29:22 +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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PGf8d68cSz4TDp for ; Wed, 15 Feb 2023 00:29:21 +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.16.1/8.15.2) with ESMTPS id 31F0Tlo4031862 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 14 Feb 2023 16:29:47 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 31F0TlGZ031861 for freebsd-arm@freebsd.org; Tue, 14 Feb 2023 16:29:47 -0800 (PST) (envelope-from fbsd) Date: Tue, 14 Feb 2023 16:29:46 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash) Message-ID: <20230215002946.GA29330@www.zefox.net> References: <20230212191308.GA21535@www.zefox.net> <20230212195324.GB21535@www.zefox.net> <03840D0B-13D4-4F22-BDAF-2887A4D78BED@yahoo.com> <20230213232519.GD95670@funkthat.com> <20230214161415.GA28276@www.zefox.net> <20230214183827.GG95670@funkthat.com> <20230214210601.GA28959@www.zefox.net> <20230214232746.GI95670@funkthat.com> 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 In-Reply-To: <20230214232746.GI95670@funkthat.com> X-Spamd-Result: default: False [-1.06 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.956]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[zefox.net]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PGf8d68cSz4TDp X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N On Tue, Feb 14, 2023 at 03:27:46PM -0800, John-Mark Gurney wrote: > bob prohaska wrote this message on Tue, Feb 14, 2023 at 13:06 -0800: > > On Tue, Feb 14, 2023 at 10:38:27AM -0800, John-Mark Gurney wrote: > > > bob prohaska wrote this message on Tue, Feb 14, 2023 at 08:14 -0800: > > > > > > > > Is this a demonstration that the fsck segfault can be reproduced > > > > independtly of my particular corrupt filesystem? AFL is new to me. > > > > > > Yes, it is. It turns out that the FS to produce this failure is a LOT > > > smaller than I expected when compresed, I have included it later in the > > > email. The constant above was taken directly from the failing FS. > > > > > > AFL is a very useful tool, and found this crash and apparently 50+ > > > other crashes in only 5-10 minutes of running... I'll be investigating > > > a few of the other crashes as well, as fsck does ocassionally deal w/ > > > untrusted fs's. > > > > > > > Would trying to run fsck on the corrupt filesystem from an 8GB Pi4 > > (also running -current) make any difference? I.e., might more physical > > RAM cover up the bug and allow fsck to complete successfully? > > No, it will not. It's trying to access memory address 0x4 which does > not exist, no matter how much memory. > > In this case, an inode's mtime is wildly incorrect. Here is a simple > patch that will let it get farther, BUT, it doesn't necessarily mean > that the kernel can properly handle the mtime: > diff --git a/sbin/fsck_ffs/inode.c b/sbin/fsck_ffs/inode.c > index 82338f4f8c08..d0892a822dc5 100644 > --- a/sbin/fsck_ffs/inode.c > +++ b/sbin/fsck_ffs/inode.c > @@ -1311,7 +1311,10 @@ prtinode(struct inode *ip) > printf("SIZE=%ju ", (uintmax_t)DIP(dp, di_size)); > t = DIP(dp, di_mtime); > p = ctime(&t); > - printf("MTIME=%12.12s %4.4s ", &p[4], &p[20]); > + if (p == NULL) > + printf("MTIME=invalid "); > + else > + printf("MTIME=%12.12s %4.4s ", &p[4], &p[20]); > } > > void > > > If you can get the inode number (should be in the gdb backtrace in one > of the frames), you can use fsdb to switch to the inode (inode ), > and then set the mtime to something reasonable (mtime 0), and then fsck > should complete as well... > That looks fairly tricky. I'm tempted to just wait till the fix propagates into -current, unless that'll take an extraordinary amount of time. > > Is there a plain-English description of how AFL works? I gather it > > manipulates input read by a program to discover improperly handled > > cases, but even that is far from certain. There's no hope of me doing > > anything useful with AFL. I'm merely curious. > > You are correct. It insturments a program to see when it modifies > the input, which branches it takes, and uses that to make better choices > on how to mutate the input. > > In another email I sent the instructions on how I ran it, but I used: > https://afl-1.readthedocs.io/en/latest/quick_start.html > > to figure/remind myself how to run it. Only difference is that instead > of running ./configure, I used make instead in the correct directory of > the FreeBSD src tree. The Wikepedia page is nearly readable for a non-programmer. It seems to suggest that one starts with a valid input file and valid input command for a specially-compiled version of the test program, then randomly modifies the command or input, catalogs the result and repeats successively until something gets past the program's error handling filters. Thanks for writing! bob prohaska From nobody Wed Feb 15 00:50:40 2023 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 4PGfdH3861z3qVHL for ; Wed, 15 Feb 2023 00:50:43 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PGfdH1GBvz4W1l for ; Wed, 15 Feb 2023 00:50:43 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.16.1/8.16.1) with ESMTP id 31F0ofGF073571; Tue, 14 Feb 2023 18:50:41 -0600 (CST) (envelope-from mike@karels.net) Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id yEa7L2Es7GNhHwEAs/W3XQ (envelope-from ); Tue, 14 Feb 2023 18:50:41 -0600 From: Mike Karels To: bob prohaska Cc: freebsd-arm@freebsd.org Subject: Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash) Date: Tue, 14 Feb 2023 18:50:40 -0600 X-Mailer: MailMate (1.14r5937) Message-ID: <5BC35FED-48F0-4BF8-9A66-2CF94F866CAA@karels.net> In-Reply-To: <20230215002946.GA29330@www.zefox.net> References: <20230212191308.GA21535@www.zefox.net> <20230212195324.GB21535@www.zefox.net> <03840D0B-13D4-4F22-BDAF-2887A4D78BED@yahoo.com> <20230213232519.GD95670@funkthat.com> <20230214161415.GA28276@www.zefox.net> <20230214183827.GG95670@funkthat.com> <20230214210601.GA28959@www.zefox.net> <20230214232746.GI95670@funkthat.com> <20230215002946.GA29330@www.zefox.net> 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 X-Rspamd-Queue-Id: 4PGfdH1GBvz4W1l X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 14 Feb 2023, at 18:29, bob prohaska wrote: > On Tue, Feb 14, 2023 at 03:27:46PM -0800, John-Mark Gurney wrote: >> bob prohaska wrote this message on Tue, Feb 14, 2023 at 13:06 -0800: >>> On Tue, Feb 14, 2023 at 10:38:27AM -0800, John-Mark Gurney wrote: >>>> bob prohaska wrote this message on Tue, Feb 14, 2023 at 08:14 -0800: >>>>> >>>>> Is this a demonstration that the fsck segfault can be reproduced >>>>> independtly of my particular corrupt filesystem? AFL is new to me. >>>> >>>> Yes, it is. It turns out that the FS to produce this failure is a LOT >>>> smaller than I expected when compresed, I have included it later in the >>>> email. The constant above was taken directly from the failing FS. >>>> >>>> AFL is a very useful tool, and found this crash and apparently 50+ >>>> other crashes in only 5-10 minutes of running... I'll be investigating >>>> a few of the other crashes as well, as fsck does ocassionally deal w/ >>>> untrusted fs's. >>>> >>> >>> Would trying to run fsck on the corrupt filesystem from an 8GB Pi4 >>> (also running -current) make any difference? I.e., might more physical >>> RAM cover up the bug and allow fsck to complete successfully? >> >> No, it will not. It's trying to access memory address 0x4 which does >> not exist, no matter how much memory. >> >> In this case, an inode's mtime is wildly incorrect. Here is a simple >> patch that will let it get farther, BUT, it doesn't necessarily mean >> that the kernel can properly handle the mtime: >> diff --git a/sbin/fsck_ffs/inode.c b/sbin/fsck_ffs/inode.c >> index 82338f4f8c08..d0892a822dc5 100644 >> --- a/sbin/fsck_ffs/inode.c >> +++ b/sbin/fsck_ffs/inode.c >> @@ -1311,7 +1311,10 @@ prtinode(struct inode *ip) >> printf("SIZE=%ju ", (uintmax_t)DIP(dp, di_size)); >> t = DIP(dp, di_mtime); >> p = ctime(&t); >> - printf("MTIME=%12.12s %4.4s ", &p[4], &p[20]); >> + if (p == NULL) >> + printf("MTIME=invalid "); >> + else >> + printf("MTIME=%12.12s %4.4s ", &p[4], &p[20]); >> } >> >> void >> >> >> If you can get the inode number (should be in the gdb backtrace in one >> of the frames), you can use fsdb to switch to the inode (inode ), >> and then set the mtime to something reasonable (mtime 0), and then fsck >> should complete as well... >> > > That looks fairly tricky. I'm tempted to just wait till the fix propagates > into -current, unless that'll take an extraordinary amount of time. Patching the file system should not be necessary in this case. It looked like the inodes are trashed, and fsck will want to delete them for at least one reason. A patch to fsck to keep it from coring would be sufficient. Mike >>> Is there a plain-English description of how AFL works? I gather it >>> manipulates input read by a program to discover improperly handled >>> cases, but even that is far from certain. There's no hope of me doing >>> anything useful with AFL. I'm merely curious. >> >> You are correct. It insturments a program to see when it modifies >> the input, which branches it takes, and uses that to make better choices >> on how to mutate the input. >> >> In another email I sent the instructions on how I ran it, but I used: >> https://afl-1.readthedocs.io/en/latest/quick_start.html >> >> to figure/remind myself how to run it. Only difference is that instead >> of running ./configure, I used make instead in the correct directory of >> the FreeBSD src tree. > > The Wikepedia page is nearly readable for a non-programmer. > It seems to suggest that one starts with a valid input file > and valid input command for a specially-compiled version of > the test program, then randomly modifies the command or input, > catalogs the result and repeats successively until something > gets past the program's error handling filters. > > Thanks for writing! > > bob prohaska From nobody Wed Feb 15 02:57:41 2023 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 4PGjRK2mjYz3r7xx for ; Wed, 15 Feb 2023 02:57:17 +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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PGjRJ2p83z3CFF for ; Wed, 15 Feb 2023 02:57:16 +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.16.1/8.15.2) with ESMTPS id 31F2vfQE032105 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 14 Feb 2023 18:57:42 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 31F2vfdq032104 for freebsd-arm@freebsd.org; Tue, 14 Feb 2023 18:57:41 -0800 (PST) (envelope-from fbsd) Date: Tue, 14 Feb 2023 18:57:41 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Armv7 panic on -current, rpi2 buildworld Message-ID: <20230215025741.GA32086@www.zefox.net> 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]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[zefox.net]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PGjRJ2p83z3CFF X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N Building world on an RPi2 armv7, buildworld stopped with bob@www:/usr/src % panic: Called fill_fpregs while the kernel is using the VFP cpuid = 0 time = 1676427410 KDB: stack backtrace: db_trace_self() at db_trace_self pc = 0xc05e8160 lr = 0xc007aa04 (db_trace_self_wrapper+0x30) sp = 0xde2c5790 fp = 0xde2c58a8 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc = 0xc007aa04 lr = 0xc02e9c54 (vpanic+0x140) sp = 0xde2c58b0 fp = 0xde2c58d0 r4 = 0x00000100 r5 = 0x00000000 r6 = 0xc07372ef r7 = 0xc0b13968 vpanic() at vpanic+0x140 pc = 0xc02e9c54 lr = 0xc02e9a34 (dump_savectx) sp = 0xde2c58d8 fp = 0xde2c58dc r4 = 0xd70c8600 r5 = 0xde2c5e90 r6 = 0xc3398090 r7 = 0xe0cfc440 r8 = 0xc3398080 r9 = 0xd70c8600 r10 = 0xde2c5960 dump_savectx() at dump_savectx pc = 0xc02e9a34 lr = 0xc05f51dc (set_regs) sp = 0xde2c58e4 fp = 0xde2c58f8 set_regs() at set_regs pc = 0xc05f51dc lr = 0xc026f8f0 (elf32_get_fpregset+0x2c) sp = 0xde2c5900 fp = 0xde2c5908 r4 = 0xc3398090 r5 = 0xc026f8c4 elf32_get_fpregset() at elf32_get_fpregset+0x2c pc = 0xc026f8f0 lr = 0xc026d848 (elf32_coredump+0x308) sp = 0xde2c5910 fp = 0xde2c5988 r4 = 0xc0902a7c r10 = 0xde2c5960 elf32_coredump() at elf32_coredump+0x308 pc = 0xc026d848 lr = 0xc02eea74 (sigexit+0xce0) sp = 0xde2c5990 fp = 0xde2c5cf8 r4 = 0x0000004e r5 = 0xdf580b60 r6 = 0xdf580a78 r7 = 0xc026d540 r8 = 0xdddcb2bc r9 = 0xdf580ad4 r10 = 0x00000000 sigexit() at sigexit+0xce0 pc = 0xc02eea74 lr = 0xc02ef36c (postsig+0x128) sp = 0xde2c5d00 fp = 0xde2c5d88 r4 = 0x00000006 r5 = 0xdd43fba0 r6 = 0xde2c5d20 r7 = 0xde2c5d18 r8 = 0xdddcb1f8 r9 = 0xdf3d9ab8 r10 = 0x00000005 postsig() at postsig+0x128 pc = 0xc02ef36c lr = 0xc02f316c (ast_sig+0x11c) sp = 0xde2c5d90 fp = 0xde2c5e08 r4 = 0xdd43fba0 r5 = 0xdddcb2bc r6 = 0xc0734d22 r7 = 0x00000000 r8 = 0xdddcb1f8 r9 = 0x00000ab8 r10 = 0x22530384 ast_sig() at ast_sig+0x11c pc = 0xc02f316c lr = 0xc035444c (ast_handler+0xe0) sp = 0xde2c5e10 fp = 0xde2c5e28 r4 = 0xde2c5e40 r5 = 0x0000000e r6 = 0x00004000 r7 = 0xc096b59c r8 = 0xdd43fba0 r9 = 0x00000001 ast_handler() at ast_handler+0xe0 pc = 0xc035444c lr = 0xc035435c (ast+0x20) sp = 0xde2c5e30 fp = 0xde2c5e38 r4 = 0xde2c5e40 r5 = 0xdd43fba0 r6 = 0x00000000 r7 = 0x000001b1 r8 = 0x22c4b500 r9 = 0x00000000 ast() at ast+0x20 pc = 0xc035435c lr = 0xc05eaa88 (swi_exit+0x3c) sp = 0xde2c5e40 fp = 0xbb9fbe38 r4 = 0x60000013 r5 = 0xdd43fba0 swi_exit() at swi_exit+0x3c pc = 0xc05eaa88 lr = 0xc05eaa88 (swi_exit+0x3c) sp = 0xde2c5e40 fp = 0xbb9fbe38 KDB: enter: panic [ thread pid 81621 tid 101111 ] Stopped at kdb_enter+0x54: ldrb r15, [r15, r15, ror r15]! db> bt Tracing pid 81621 tid 101111 td 0xdd43fba0 db_trace_self() at db_trace_self pc = 0xc05e8160 lr = 0xc00774a0 (db_stack_trace+0x140) sp = 0xde2c55d8 fp = 0xde2c55f0 db_stack_trace() at db_stack_trace+0x140 pc = 0xc00774a0 lr = 0xc00770f0 (db_command+0x310) sp = 0xde2c55f8 fp = 0xde2c56a0 r4 = 0xc0745722 r5 = 0x00000062 r6 = 0x00000000 r10 = 0x00000000 db_command() at db_command+0x310 pc = 0xc00770f0 lr = 0xc0076db8 (db_command_loop+0x64) sp = 0xde2c56a8 fp = 0xde2c56b8 r4 = 0xc07ac186 r5 = 0xc07ab7fe r6 = 0xc0986f5c r7 = 0xc0b13968 r8 = 0xc0b23738 r9 = 0x00000000 r10 = 0x00000001 db_command_loop() at db_command_loop+0x64 pc = 0xc0076db8 lr = 0xc007ab88 (db_trap+0x128) sp = 0xde2c56c0 fp = 0xde2c57d8 r4 = 0x00000000 r5 = 0xc0986f50 r6 = 0xc0b23758 r10 = 0x00000001 db_trap() at db_trap+0x128 pc = 0xc007ab88 lr = 0xc033bb84 (kdb_trap+0x258) sp = 0xde2c57e0 fp = 0xde2c5808 r4 = 0xc078390c r5 = 0xc08d5270 r6 = 0xc0b23758 r7 = 0xc0b13968 kdb_trap() at kdb_trap+0x258 pc = 0xc033bb84 lr = 0xc05eaab8 (exception_exit) sp = 0xde2c5810 fp = 0xde2c58a8 r4 = 0x200000d3 r5 = 0x00000000 r6 = 0xc07372ef r7 = 0xc0b13968 r8 = 0xc093fa0c r9 = 0xde2c58e4 r10 = 0xc0b13a68 exception_exit() at exception_exit pc = 0xc05eaab8 lr = 0xc033b044 (kdb_enter+0x50) sp = 0xde2c58a0 fp = 0xde2c58a8 r0 = 0x00000000 r1 = 0x00000001 r2 = 0x00000012 r3 = 0x00000000 r4 = 0xc0b23748 r5 = 0x00000000 r6 = 0xc07372ef r7 = 0xc0b13968 r8 = 0xc093fa0c r9 = 0xde2c58e4 r10 = 0xc0b13a68 r12 = 0x00000000 kdb_enter() at kdb_enter+0x58 pc = 0xc033b04c lr = 0xc02e9ca0 (vpanic+0x18c) sp = 0xde2c58b0 fp = 0xde2c58d0 r4 = 0x00000100 r10 = 0xc0b13a68 vpanic() at vpanic+0x18c pc = 0xc02e9ca0 lr = 0xc02e9a34 (dump_savectx) sp = 0xde2c58d8 fp = 0xde2c58dc r4 = 0xd70c8600 r5 = 0xde2c5e90 r6 = 0xc3398090 r7 = 0xe0cfc440 r8 = 0xc3398080 r9 = 0xd70c8600 r10 = 0xde2c5960 dump_savectx() at dump_savectx pc = 0xc02e9a34 lr = 0xc05f51dc (set_regs) sp = 0xde2c58e4 fp = 0xde2c58f8 set_regs() at set_regs pc = 0xc05f51dc lr = 0xc026f8f0 (elf32_get_fpregset+0x2c) sp = 0xde2c5900 fp = 0xde2c5908 r4 = 0xc3398090 r5 = 0xc026f8c4 elf32_get_fpregset() at elf32_get_fpregset+0x2c pc = 0xc026f8f0 lr = 0xc026d848 (elf32_coredump+0x308) sp = 0xde2c5910 fp = 0xde2c5988 r4 = 0xc0902a7c r10 = 0xde2c5960 elf32_coredump() at elf32_coredump+0x308 pc = 0xc026d848 lr = 0xc02eea74 (sigexit+0xce0) sp = 0xde2c5990 fp = 0xde2c5cf8 r4 = 0x0000004e r5 = 0xdf580b60 r6 = 0xdf580a78 r7 = 0xc026d540 r8 = 0xdddcb2bc r9 = 0xdf580ad4 r10 = 0x00000000 sigexit() at sigexit+0xce0 pc = 0xc02eea74 lr = 0xc02ef36c (postsig+0x128) sp = 0xde2c5d00 fp = 0xde2c5d88 r4 = 0x00000006 r5 = 0xdd43fba0 r6 = 0xde2c5d20 r7 = 0xde2c5d18 r8 = 0xdddcb1f8 r9 = 0xdf3d9ab8 r10 = 0x00000005 postsig() at postsig+0x128 pc = 0xc02ef36c lr = 0xc02f316c (ast_sig+0x11c) sp = 0xde2c5d90 fp = 0xde2c5e08 r4 = 0xdd43fba0 r5 = 0xdddcb2bc r6 = 0xc0734d22 r7 = 0x00000000 r8 = 0xdddcb1f8 r9 = 0x00000ab8 r10 = 0x22530384 ast_sig() at ast_sig+0x11c pc = 0xc02f316c lr = 0xc035444c (ast_handler+0xe0) sp = 0xde2c5e10 fp = 0xde2c5e28 r4 = 0xde2c5e40 r5 = 0x0000000e r6 = 0x00004000 r7 = 0xc096b59c r8 = 0xdd43fba0 r9 = 0x00000001 ast_handler() at ast_handler+0xe0 pc = 0xc035444c lr = 0xc035435c (ast+0x20) sp = 0xde2c5e30 fp = 0xde2c5e38 r4 = 0xde2c5e40 r5 = 0xdd43fba0 r6 = 0x00000000 r7 = 0x000001b1 r8 = 0x22c4b500 r9 = 0x00000000 ast() at ast+0x20 pc = 0xc035435c lr = 0xc05eaa88 (swi_exit+0x3c) sp = 0xde2c5e40 fp = 0xbb9fbe38 r4 = 0x60000013 r5 = 0xdd43fba0 swi_exit() at swi_exit+0x3c pc = 0xc05eaa88 lr = 0xc05eaa88 (swi_exit+0x3c) sp = 0xde2c5e40 fp = 0xbb9fbe38 db> The machine was last updated about a week ago, the sources were updated earlier today. This panic is new to me. Thanks for reading, bob prohaska From nobody Wed Feb 15 04:16:51 2023 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 4PGlCN5lTSz3rDNl for ; Wed, 15 Feb 2023 04:17:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PGlCN3Fb2z3JcH for ; Wed, 15 Feb 2023 04:17:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62a.google.com with SMTP id lf10so13281905ejc.5 for ; Tue, 14 Feb 2023 20:17:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JAAbXM5nkOCT2ytFVS5i3XH7lVFOeJ5mAy9ErQ51chM=; b=2VdfWBZ6IeqebEsXTRSgd8C9iK9jfZRVBBeTIsHPe5wFYGq2zFjeeCmrXmX59zBHtG uMs4R4N0gw4VKpxa690nryJFagZzvCmnl6QMGeREDLsk1s53POM21EZjcI3GbcVZVlDj D2ihydqZVdDWwUoRAHV9XwcEDggmoAjd+zBvb8nwzS/YkwHjb7HdJmzcrt9sC00Dlu26 pFAXsjiAzzS2meQsX1D0Y0+xyTYG8YtkYL2jC0Rp/P2eujAE8eZJx6ns1NGczseO2zPc 9Wx0JlHipwCAoTcboIuqkb+Xh9mPmkbCXQF39kk5wTozrJdrWTq/yKfG6UMsZ6H/NqIn tdtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JAAbXM5nkOCT2ytFVS5i3XH7lVFOeJ5mAy9ErQ51chM=; b=XZ/ioFD5pL4gt+0J5kzAhVKBXioOIvFX2NJ4eJuqXj3LYPRuTX/azUDX3HOsnVu3pK 1Ld4PkvoIreoPgydU5OAoiXGyT/3khtSWDvE1m9AldffH1NGEP93ln1a/6mdLqF8kWq0 VQsHGuyz7LmXngZg+n9ZZt7pEkJOmCaMBwsVJwVFDM0gEAi44bp92PTUkCW1MDMOKi+4 OiPDOMZc+YOCDR72dw3neewKmteo7c3lhcpfLSn5caY6A+YiHaLnU8wcz7vOaJbh/usB ZnpgAPTCrrrOsUhwO8sNsVRT1MwUVuX/UA7dHJg0VfrGWBQ7ZdTJVdPmW4atW8+HT79U v+lg== X-Gm-Message-State: AO0yUKWPxAqQK3FNdchqglbW5+NUHmMGiabLFDD/7ejFxqbwX6IK7sbA Ez/1Kb1DAmL3dcKs3JpNJRcy5hk9BbOMMDVC5arh81J8SK7IJg== X-Google-Smtp-Source: AK7set/uLr8PqhJLPiVR12UuemmXIlSa6ejVS4Kdh93L/6VK+NFW9n3j9WKIvcWrR2x71qXMQDQdaTecci1gDzNEnoI= X-Received: by 2002:a17:907:9949:b0:88d:ba79:4310 with SMTP id kl9-20020a170907994900b0088dba794310mr1187917ejc.0.1676434622507; Tue, 14 Feb 2023 20:17:02 -0800 (PST) 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 References: <20230215025741.GA32086@www.zefox.net> In-Reply-To: <20230215025741.GA32086@www.zefox.net> From: Warner Losh Date: Tue, 14 Feb 2023 21:16:51 -0700 Message-ID: Subject: Re: Armv7 panic on -current, rpi2 buildworld To: bob prohaska Cc: "freebsd-arm@freebsd.org" Content-Type: multipart/alternative; boundary="00000000000029fff705f4b55acb" X-Rspamd-Queue-Id: 4PGlCN3Fb2z3JcH X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --00000000000029fff705f4b55acb Content-Type: text/plain; charset="UTF-8" Sorry to top post... what program was dumping core? Looks like a too strict assert Warner On Tue, Feb 14, 2023, 7:57 PM bob prohaska wrote: > Building world on an RPi2 armv7, buildworld stopped with > bob@www:/usr/src % panic: Called fill_fpregs while the kernel is using > the VFP > cpuid = 0 > time = 1676427410 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc = 0xc05e8160 lr = 0xc007aa04 (db_trace_self_wrapper+0x30) > sp = 0xde2c5790 fp = 0xde2c58a8 > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc = 0xc007aa04 lr = 0xc02e9c54 (vpanic+0x140) > sp = 0xde2c58b0 fp = 0xde2c58d0 > r4 = 0x00000100 r5 = 0x00000000 > r6 = 0xc07372ef r7 = 0xc0b13968 > vpanic() at vpanic+0x140 > pc = 0xc02e9c54 lr = 0xc02e9a34 (dump_savectx) > sp = 0xde2c58d8 fp = 0xde2c58dc > r4 = 0xd70c8600 r5 = 0xde2c5e90 > r6 = 0xc3398090 r7 = 0xe0cfc440 > r8 = 0xc3398080 r9 = 0xd70c8600 > r10 = 0xde2c5960 > dump_savectx() at dump_savectx > pc = 0xc02e9a34 lr = 0xc05f51dc (set_regs) > sp = 0xde2c58e4 fp = 0xde2c58f8 > set_regs() at set_regs > pc = 0xc05f51dc lr = 0xc026f8f0 (elf32_get_fpregset+0x2c) > sp = 0xde2c5900 fp = 0xde2c5908 > r4 = 0xc3398090 r5 = 0xc026f8c4 > elf32_get_fpregset() at elf32_get_fpregset+0x2c > pc = 0xc026f8f0 lr = 0xc026d848 (elf32_coredump+0x308) > sp = 0xde2c5910 fp = 0xde2c5988 > r4 = 0xc0902a7c r10 = 0xde2c5960 > elf32_coredump() at elf32_coredump+0x308 > pc = 0xc026d848 lr = 0xc02eea74 (sigexit+0xce0) > sp = 0xde2c5990 fp = 0xde2c5cf8 > r4 = 0x0000004e r5 = 0xdf580b60 > r6 = 0xdf580a78 r7 = 0xc026d540 > r8 = 0xdddcb2bc r9 = 0xdf580ad4 > r10 = 0x00000000 > sigexit() at sigexit+0xce0 > pc = 0xc02eea74 lr = 0xc02ef36c (postsig+0x128) > sp = 0xde2c5d00 fp = 0xde2c5d88 > r4 = 0x00000006 r5 = 0xdd43fba0 > r6 = 0xde2c5d20 r7 = 0xde2c5d18 > r8 = 0xdddcb1f8 r9 = 0xdf3d9ab8 > r10 = 0x00000005 > postsig() at postsig+0x128 > pc = 0xc02ef36c lr = 0xc02f316c (ast_sig+0x11c) > sp = 0xde2c5d90 fp = 0xde2c5e08 > r4 = 0xdd43fba0 r5 = 0xdddcb2bc > r6 = 0xc0734d22 r7 = 0x00000000 > r8 = 0xdddcb1f8 r9 = 0x00000ab8 > r10 = 0x22530384 > ast_sig() at ast_sig+0x11c > pc = 0xc02f316c lr = 0xc035444c (ast_handler+0xe0) > sp = 0xde2c5e10 fp = 0xde2c5e28 > r4 = 0xde2c5e40 r5 = 0x0000000e > r6 = 0x00004000 r7 = 0xc096b59c > r8 = 0xdd43fba0 r9 = 0x00000001 > ast_handler() at ast_handler+0xe0 > pc = 0xc035444c lr = 0xc035435c (ast+0x20) > sp = 0xde2c5e30 fp = 0xde2c5e38 > r4 = 0xde2c5e40 r5 = 0xdd43fba0 > r6 = 0x00000000 r7 = 0x000001b1 > r8 = 0x22c4b500 r9 = 0x00000000 > ast() at ast+0x20 > pc = 0xc035435c lr = 0xc05eaa88 (swi_exit+0x3c) > sp = 0xde2c5e40 fp = 0xbb9fbe38 > r4 = 0x60000013 r5 = 0xdd43fba0 > swi_exit() at swi_exit+0x3c > pc = 0xc05eaa88 lr = 0xc05eaa88 (swi_exit+0x3c) > sp = 0xde2c5e40 fp = 0xbb9fbe38 > KDB: enter: panic > [ thread pid 81621 tid 101111 ] > Stopped at kdb_enter+0x54: ldrb r15, [r15, r15, ror r15]! > db> bt > Tracing pid 81621 tid 101111 td 0xdd43fba0 > db_trace_self() at db_trace_self > pc = 0xc05e8160 lr = 0xc00774a0 (db_stack_trace+0x140) > sp = 0xde2c55d8 fp = 0xde2c55f0 > db_stack_trace() at db_stack_trace+0x140 > pc = 0xc00774a0 lr = 0xc00770f0 (db_command+0x310) > sp = 0xde2c55f8 fp = 0xde2c56a0 > r4 = 0xc0745722 r5 = 0x00000062 > r6 = 0x00000000 r10 = 0x00000000 > db_command() at db_command+0x310 > pc = 0xc00770f0 lr = 0xc0076db8 (db_command_loop+0x64) > sp = 0xde2c56a8 fp = 0xde2c56b8 > r4 = 0xc07ac186 r5 = 0xc07ab7fe > r6 = 0xc0986f5c r7 = 0xc0b13968 > r8 = 0xc0b23738 r9 = 0x00000000 > r10 = 0x00000001 > db_command_loop() at db_command_loop+0x64 > pc = 0xc0076db8 lr = 0xc007ab88 (db_trap+0x128) > sp = 0xde2c56c0 fp = 0xde2c57d8 > r4 = 0x00000000 r5 = 0xc0986f50 > r6 = 0xc0b23758 r10 = 0x00000001 > db_trap() at db_trap+0x128 > pc = 0xc007ab88 lr = 0xc033bb84 (kdb_trap+0x258) > sp = 0xde2c57e0 fp = 0xde2c5808 > r4 = 0xc078390c r5 = 0xc08d5270 > r6 = 0xc0b23758 r7 = 0xc0b13968 > kdb_trap() at kdb_trap+0x258 > pc = 0xc033bb84 lr = 0xc05eaab8 (exception_exit) > sp = 0xde2c5810 fp = 0xde2c58a8 > r4 = 0x200000d3 r5 = 0x00000000 > r6 = 0xc07372ef r7 = 0xc0b13968 > r8 = 0xc093fa0c r9 = 0xde2c58e4 > r10 = 0xc0b13a68 > exception_exit() at exception_exit > pc = 0xc05eaab8 lr = 0xc033b044 (kdb_enter+0x50) > sp = 0xde2c58a0 fp = 0xde2c58a8 > r0 = 0x00000000 r1 = 0x00000001 > r2 = 0x00000012 r3 = 0x00000000 > r4 = 0xc0b23748 r5 = 0x00000000 > r6 = 0xc07372ef r7 = 0xc0b13968 > r8 = 0xc093fa0c r9 = 0xde2c58e4 > r10 = 0xc0b13a68 r12 = 0x00000000 > kdb_enter() at kdb_enter+0x58 > pc = 0xc033b04c lr = 0xc02e9ca0 (vpanic+0x18c) > sp = 0xde2c58b0 fp = 0xde2c58d0 > r4 = 0x00000100 r10 = 0xc0b13a68 > vpanic() at vpanic+0x18c > pc = 0xc02e9ca0 lr = 0xc02e9a34 (dump_savectx) > sp = 0xde2c58d8 fp = 0xde2c58dc > r4 = 0xd70c8600 r5 = 0xde2c5e90 > r6 = 0xc3398090 r7 = 0xe0cfc440 > r8 = 0xc3398080 r9 = 0xd70c8600 > r10 = 0xde2c5960 > dump_savectx() at dump_savectx > pc = 0xc02e9a34 lr = 0xc05f51dc (set_regs) > sp = 0xde2c58e4 fp = 0xde2c58f8 > set_regs() at set_regs > pc = 0xc05f51dc lr = 0xc026f8f0 (elf32_get_fpregset+0x2c) > sp = 0xde2c5900 fp = 0xde2c5908 > r4 = 0xc3398090 r5 = 0xc026f8c4 > elf32_get_fpregset() at elf32_get_fpregset+0x2c > pc = 0xc026f8f0 lr = 0xc026d848 (elf32_coredump+0x308) > sp = 0xde2c5910 fp = 0xde2c5988 > r4 = 0xc0902a7c r10 = 0xde2c5960 > elf32_coredump() at elf32_coredump+0x308 > pc = 0xc026d848 lr = 0xc02eea74 (sigexit+0xce0) > sp = 0xde2c5990 fp = 0xde2c5cf8 > r4 = 0x0000004e r5 = 0xdf580b60 > r6 = 0xdf580a78 r7 = 0xc026d540 > r8 = 0xdddcb2bc r9 = 0xdf580ad4 > r10 = 0x00000000 > sigexit() at sigexit+0xce0 > pc = 0xc02eea74 lr = 0xc02ef36c (postsig+0x128) > sp = 0xde2c5d00 fp = 0xde2c5d88 > r4 = 0x00000006 r5 = 0xdd43fba0 > r6 = 0xde2c5d20 r7 = 0xde2c5d18 > r8 = 0xdddcb1f8 r9 = 0xdf3d9ab8 > r10 = 0x00000005 > postsig() at postsig+0x128 > pc = 0xc02ef36c lr = 0xc02f316c (ast_sig+0x11c) > sp = 0xde2c5d90 fp = 0xde2c5e08 > r4 = 0xdd43fba0 r5 = 0xdddcb2bc > r6 = 0xc0734d22 r7 = 0x00000000 > r8 = 0xdddcb1f8 r9 = 0x00000ab8 > r10 = 0x22530384 > ast_sig() at ast_sig+0x11c > pc = 0xc02f316c lr = 0xc035444c (ast_handler+0xe0) > sp = 0xde2c5e10 fp = 0xde2c5e28 > r4 = 0xde2c5e40 r5 = 0x0000000e > r6 = 0x00004000 r7 = 0xc096b59c > r8 = 0xdd43fba0 r9 = 0x00000001 > ast_handler() at ast_handler+0xe0 > pc = 0xc035444c lr = 0xc035435c (ast+0x20) > sp = 0xde2c5e30 fp = 0xde2c5e38 > r4 = 0xde2c5e40 r5 = 0xdd43fba0 > r6 = 0x00000000 r7 = 0x000001b1 > r8 = 0x22c4b500 r9 = 0x00000000 > ast() at ast+0x20 > pc = 0xc035435c lr = 0xc05eaa88 (swi_exit+0x3c) > sp = 0xde2c5e40 fp = 0xbb9fbe38 > r4 = 0x60000013 r5 = 0xdd43fba0 > swi_exit() at swi_exit+0x3c > pc = 0xc05eaa88 lr = 0xc05eaa88 (swi_exit+0x3c) > sp = 0xde2c5e40 fp = 0xbb9fbe38 > db> > > The machine was last updated about a week ago, the > sources were updated earlier today. This panic is > new to me. > > Thanks for reading, > > bob prohaska > > > > --00000000000029fff705f4b55acb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBkaXI9ImF1dG8iPjxkaXY+U29ycnkgdG8gdG9wIHBvc3QuLi4gd2hhdCBwcm9ncmFtIHdh cyBkdW1waW5nIGNvcmU/IExvb2tzIGxpa2UgYSB0b28gc3RyaWN0IGFzc2VydDwvZGl2PjxkaXYg ZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPldhcm5lcjxicj48YnI+PGRpdiBj bGFzcz0iZ21haWxfcXVvdGUiIGRpcj0iYXV0byI+PGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWls X2F0dHIiPk9uIFR1ZSwgRmViIDE0LCAyMDIzLCA3OjU3IFBNIGJvYiBwcm9oYXNrYSAmbHQ7PGEg aHJlZj0ibWFpbHRvOmZic2RAd3d3LnplZm94Lm5ldCI+ZmJzZEB3d3cuemVmb3gubmV0PC9hPiZn dDsgd3JvdGU6PGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVm dDoxZXgiPkJ1aWxkaW5nIHdvcmxkIG9uIGFuIFJQaTIgYXJtdjcsIGJ1aWxkd29ybGQgc3RvcHBl ZCB3aXRoPGJyPg0KYm9iQHd3dzovdXNyL3NyYyAlIHBhbmljOiBDYWxsZWQgZmlsbF9mcHJlZ3Mg d2hpbGUgdGhlIGtlcm5lbCBpcyB1c2luZyB0aGUgVkZQPGJyPg0KY3B1aWQgPSAwPGJyPg0KdGlt ZSA9IDE2NzY0Mjc0MTA8YnI+DQpLREI6IHN0YWNrIGJhY2t0cmFjZTo8YnI+DQpkYl90cmFjZV9z ZWxmKCkgYXQgZGJfdHJhY2Vfc2VsZjxicj4NCsKgIMKgIMKgIMKgIMKgcGMgPSAweGMwNWU4MTYw wqAgbHIgPSAweGMwMDdhYTA0IChkYl90cmFjZV9zZWxmX3dyYXBwZXIrMHgzMCk8YnI+DQrCoCDC oCDCoCDCoCDCoHNwID0gMHhkZTJjNTc5MMKgIGZwID0gMHhkZTJjNThhODxicj4NCmRiX3RyYWNl X3NlbGZfd3JhcHBlcigpIGF0IGRiX3RyYWNlX3NlbGZfd3JhcHBlcisweDMwPGJyPg0KwqAgwqAg wqAgwqAgwqBwYyA9IDB4YzAwN2FhMDTCoCBsciA9IDB4YzAyZTljNTQgKHZwYW5pYysweDE0MCk8 YnI+DQrCoCDCoCDCoCDCoCDCoHNwID0gMHhkZTJjNThiMMKgIGZwID0gMHhkZTJjNThkMDxicj4N CsKgIMKgIMKgIMKgIMKgcjQgPSAweDAwMDAwMTAwwqAgcjUgPSAweDAwMDAwMDAwPGJyPg0KwqAg wqAgwqAgwqAgwqByNiA9IDB4YzA3MzcyZWbCoCByNyA9IDB4YzBiMTM5Njg8YnI+DQp2cGFuaWMo KSBhdCB2cGFuaWMrMHgxNDA8YnI+DQrCoCDCoCDCoCDCoCDCoHBjID0gMHhjMDJlOWM1NMKgIGxy ID0gMHhjMDJlOWEzNCAoZHVtcF9zYXZlY3R4KTxicj4NCsKgIMKgIMKgIMKgIMKgc3AgPSAweGRl MmM1OGQ4wqAgZnAgPSAweGRlMmM1OGRjPGJyPg0KwqAgwqAgwqAgwqAgwqByNCA9IDB4ZDcwYzg2 MDDCoCByNSA9IDB4ZGUyYzVlOTA8YnI+DQrCoCDCoCDCoCDCoCDCoHI2ID0gMHhjMzM5ODA5MMKg IHI3ID0gMHhlMGNmYzQ0MDxicj4NCsKgIMKgIMKgIMKgIMKgcjggPSAweGMzMzk4MDgwwqAgcjkg PSAweGQ3MGM4NjAwPGJyPg0KwqAgwqAgwqAgwqAgcjEwID0gMHhkZTJjNTk2MDxicj4NCmR1bXBf c2F2ZWN0eCgpIGF0IGR1bXBfc2F2ZWN0eDxicj4NCsKgIMKgIMKgIMKgIMKgcGMgPSAweGMwMmU5 YTM0wqAgbHIgPSAweGMwNWY1MWRjIChzZXRfcmVncyk8YnI+DQrCoCDCoCDCoCDCoCDCoHNwID0g MHhkZTJjNThlNMKgIGZwID0gMHhkZTJjNThmODxicj4NCnNldF9yZWdzKCkgYXQgc2V0X3JlZ3M8 YnI+DQrCoCDCoCDCoCDCoCDCoHBjID0gMHhjMDVmNTFkY8KgIGxyID0gMHhjMDI2ZjhmMCAoZWxm MzJfZ2V0X2ZwcmVnc2V0KzB4MmMpPGJyPg0KwqAgwqAgwqAgwqAgwqBzcCA9IDB4ZGUyYzU5MDDC oCBmcCA9IDB4ZGUyYzU5MDg8YnI+DQrCoCDCoCDCoCDCoCDCoHI0ID0gMHhjMzM5ODA5MMKgIHI1 ID0gMHhjMDI2ZjhjNDxicj4NCmVsZjMyX2dldF9mcHJlZ3NldCgpIGF0IGVsZjMyX2dldF9mcHJl Z3NldCsweDJjPGJyPg0KwqAgwqAgwqAgwqAgwqBwYyA9IDB4YzAyNmY4ZjDCoCBsciA9IDB4YzAy NmQ4NDggKGVsZjMyX2NvcmVkdW1wKzB4MzA4KTxicj4NCsKgIMKgIMKgIMKgIMKgc3AgPSAweGRl MmM1OTEwwqAgZnAgPSAweGRlMmM1OTg4PGJyPg0KwqAgwqAgwqAgwqAgwqByNCA9IDB4YzA5MDJh N2MgcjEwID0gMHhkZTJjNTk2MDxicj4NCmVsZjMyX2NvcmVkdW1wKCkgYXQgZWxmMzJfY29yZWR1 bXArMHgzMDg8YnI+DQrCoCDCoCDCoCDCoCDCoHBjID0gMHhjMDI2ZDg0OMKgIGxyID0gMHhjMDJl ZWE3NCAoc2lnZXhpdCsweGNlMCk8YnI+DQrCoCDCoCDCoCDCoCDCoHNwID0gMHhkZTJjNTk5MMKg IGZwID0gMHhkZTJjNWNmODxicj4NCsKgIMKgIMKgIMKgIMKgcjQgPSAweDAwMDAwMDRlwqAgcjUg PSAweGRmNTgwYjYwPGJyPg0KwqAgwqAgwqAgwqAgwqByNiA9IDB4ZGY1ODBhNzjCoCByNyA9IDB4 YzAyNmQ1NDA8YnI+DQrCoCDCoCDCoCDCoCDCoHI4ID0gMHhkZGRjYjJiY8KgIHI5ID0gMHhkZjU4 MGFkNDxicj4NCsKgIMKgIMKgIMKgIHIxMCA9IDB4MDAwMDAwMDA8YnI+DQpzaWdleGl0KCkgYXQg c2lnZXhpdCsweGNlMDxicj4NCsKgIMKgIMKgIMKgIMKgcGMgPSAweGMwMmVlYTc0wqAgbHIgPSAw eGMwMmVmMzZjIChwb3N0c2lnKzB4MTI4KTxicj4NCsKgIMKgIMKgIMKgIMKgc3AgPSAweGRlMmM1 ZDAwwqAgZnAgPSAweGRlMmM1ZDg4PGJyPg0KwqAgwqAgwqAgwqAgwqByNCA9IDB4MDAwMDAwMDbC oCByNSA9IDB4ZGQ0M2ZiYTA8YnI+DQrCoCDCoCDCoCDCoCDCoHI2ID0gMHhkZTJjNWQyMMKgIHI3 ID0gMHhkZTJjNWQxODxicj4NCsKgIMKgIMKgIMKgIMKgcjggPSAweGRkZGNiMWY4wqAgcjkgPSAw eGRmM2Q5YWI4PGJyPg0KwqAgwqAgwqAgwqAgcjEwID0gMHgwMDAwMDAwNTxicj4NCnBvc3RzaWco KSBhdCBwb3N0c2lnKzB4MTI4PGJyPg0KwqAgwqAgwqAgwqAgwqBwYyA9IDB4YzAyZWYzNmPCoCBs ciA9IDB4YzAyZjMxNmMgKGFzdF9zaWcrMHgxMWMpPGJyPg0KwqAgwqAgwqAgwqAgwqBzcCA9IDB4 ZGUyYzVkOTDCoCBmcCA9IDB4ZGUyYzVlMDg8YnI+DQrCoCDCoCDCoCDCoCDCoHI0ID0gMHhkZDQz ZmJhMMKgIHI1ID0gMHhkZGRjYjJiYzxicj4NCsKgIMKgIMKgIMKgIMKgcjYgPSAweGMwNzM0ZDIy wqAgcjcgPSAweDAwMDAwMDAwPGJyPg0KwqAgwqAgwqAgwqAgwqByOCA9IDB4ZGRkY2IxZjjCoCBy OSA9IDB4MDAwMDBhYjg8YnI+DQrCoCDCoCDCoCDCoCByMTAgPSAweDIyNTMwMzg0PGJyPg0KYXN0 X3NpZygpIGF0IGFzdF9zaWcrMHgxMWM8YnI+DQrCoCDCoCDCoCDCoCDCoHBjID0gMHhjMDJmMzE2 Y8KgIGxyID0gMHhjMDM1NDQ0YyAoYXN0X2hhbmRsZXIrMHhlMCk8YnI+DQrCoCDCoCDCoCDCoCDC oHNwID0gMHhkZTJjNWUxMMKgIGZwID0gMHhkZTJjNWUyODxicj4NCsKgIMKgIMKgIMKgIMKgcjQg PSAweGRlMmM1ZTQwwqAgcjUgPSAweDAwMDAwMDBlPGJyPg0KwqAgwqAgwqAgwqAgwqByNiA9IDB4 MDAwMDQwMDDCoCByNyA9IDB4YzA5NmI1OWM8YnI+DQrCoCDCoCDCoCDCoCDCoHI4ID0gMHhkZDQz ZmJhMMKgIHI5ID0gMHgwMDAwMDAwMTxicj4NCmFzdF9oYW5kbGVyKCkgYXQgYXN0X2hhbmRsZXIr MHhlMDxicj4NCsKgIMKgIMKgIMKgIMKgcGMgPSAweGMwMzU0NDRjwqAgbHIgPSAweGMwMzU0MzVj IChhc3QrMHgyMCk8YnI+DQrCoCDCoCDCoCDCoCDCoHNwID0gMHhkZTJjNWUzMMKgIGZwID0gMHhk ZTJjNWUzODxicj4NCsKgIMKgIMKgIMKgIMKgcjQgPSAweGRlMmM1ZTQwwqAgcjUgPSAweGRkNDNm YmEwPGJyPg0KwqAgwqAgwqAgwqAgwqByNiA9IDB4MDAwMDAwMDDCoCByNyA9IDB4MDAwMDAxYjE8 YnI+DQrCoCDCoCDCoCDCoCDCoHI4ID0gMHgyMmM0YjUwMMKgIHI5ID0gMHgwMDAwMDAwMDxicj4N CmFzdCgpIGF0IGFzdCsweDIwPGJyPg0KwqAgwqAgwqAgwqAgwqBwYyA9IDB4YzAzNTQzNWPCoCBs ciA9IDB4YzA1ZWFhODggKHN3aV9leGl0KzB4M2MpPGJyPg0KwqAgwqAgwqAgwqAgwqBzcCA9IDB4 ZGUyYzVlNDDCoCBmcCA9IDB4YmI5ZmJlMzg8YnI+DQrCoCDCoCDCoCDCoCDCoHI0ID0gMHg2MDAw MDAxM8KgIHI1ID0gMHhkZDQzZmJhMDxicj4NCnN3aV9leGl0KCkgYXQgc3dpX2V4aXQrMHgzYzxi cj4NCsKgIMKgIMKgIMKgIMKgcGMgPSAweGMwNWVhYTg4wqAgbHIgPSAweGMwNWVhYTg4IChzd2lf ZXhpdCsweDNjKTxicj4NCsKgIMKgIMKgIMKgIMKgc3AgPSAweGRlMmM1ZTQwwqAgZnAgPSAweGJi OWZiZTM4PGJyPg0KS0RCOiBlbnRlcjogcGFuaWM8YnI+DQpbIHRocmVhZCBwaWQgODE2MjEgdGlk IDEwMTExMSBdPGJyPg0KU3RvcHBlZCBhdMKgIMKgIMKgIGtkYl9lbnRlcisweDU0OiBsZHJiwqAg wqAgcjE1LCBbcjE1LCByMTUsIHJvciByMTVdITxicj4NCmRiJmd0OyBidDxicj4NClRyYWNpbmcg cGlkIDgxNjIxIHRpZCAxMDExMTEgdGQgMHhkZDQzZmJhMDxicj4NCmRiX3RyYWNlX3NlbGYoKSBh dCBkYl90cmFjZV9zZWxmPGJyPg0KwqAgwqAgwqAgwqAgwqBwYyA9IDB4YzA1ZTgxNjDCoCBsciA9 IDB4YzAwNzc0YTAgKGRiX3N0YWNrX3RyYWNlKzB4MTQwKTxicj4NCsKgIMKgIMKgIMKgIMKgc3Ag PSAweGRlMmM1NWQ4wqAgZnAgPSAweGRlMmM1NWYwPGJyPg0KZGJfc3RhY2tfdHJhY2UoKSBhdCBk Yl9zdGFja190cmFjZSsweDE0MDxicj4NCsKgIMKgIMKgIMKgIMKgcGMgPSAweGMwMDc3NGEwwqAg bHIgPSAweGMwMDc3MGYwIChkYl9jb21tYW5kKzB4MzEwKTxicj4NCsKgIMKgIMKgIMKgIMKgc3Ag PSAweGRlMmM1NWY4wqAgZnAgPSAweGRlMmM1NmEwPGJyPg0KwqAgwqAgwqAgwqAgwqByNCA9IDB4 YzA3NDU3MjLCoCByNSA9IDB4MDAwMDAwNjI8YnI+DQrCoCDCoCDCoCDCoCDCoHI2ID0gMHgwMDAw MDAwMCByMTAgPSAweDAwMDAwMDAwPGJyPg0KZGJfY29tbWFuZCgpIGF0IGRiX2NvbW1hbmQrMHgz MTA8YnI+DQrCoCDCoCDCoCDCoCDCoHBjID0gMHhjMDA3NzBmMMKgIGxyID0gMHhjMDA3NmRiOCAo ZGJfY29tbWFuZF9sb29wKzB4NjQpPGJyPg0KwqAgwqAgwqAgwqAgwqBzcCA9IDB4ZGUyYzU2YTjC oCBmcCA9IDB4ZGUyYzU2Yjg8YnI+DQrCoCDCoCDCoCDCoCDCoHI0ID0gMHhjMDdhYzE4NsKgIHI1 ID0gMHhjMDdhYjdmZTxicj4NCsKgIMKgIMKgIMKgIMKgcjYgPSAweGMwOTg2ZjVjwqAgcjcgPSAw eGMwYjEzOTY4PGJyPg0KwqAgwqAgwqAgwqAgwqByOCA9IDB4YzBiMjM3MzjCoCByOSA9IDB4MDAw MDAwMDA8YnI+DQrCoCDCoCDCoCDCoCByMTAgPSAweDAwMDAwMDAxPGJyPg0KZGJfY29tbWFuZF9s b29wKCkgYXQgZGJfY29tbWFuZF9sb29wKzB4NjQ8YnI+DQrCoCDCoCDCoCDCoCDCoHBjID0gMHhj MDA3NmRiOMKgIGxyID0gMHhjMDA3YWI4OCAoZGJfdHJhcCsweDEyOCk8YnI+DQrCoCDCoCDCoCDC oCDCoHNwID0gMHhkZTJjNTZjMMKgIGZwID0gMHhkZTJjNTdkODxicj4NCsKgIMKgIMKgIMKgIMKg cjQgPSAweDAwMDAwMDAwwqAgcjUgPSAweGMwOTg2ZjUwPGJyPg0KwqAgwqAgwqAgwqAgwqByNiA9 IDB4YzBiMjM3NTggcjEwID0gMHgwMDAwMDAwMTxicj4NCmRiX3RyYXAoKSBhdCBkYl90cmFwKzB4 MTI4PGJyPg0KwqAgwqAgwqAgwqAgwqBwYyA9IDB4YzAwN2FiODjCoCBsciA9IDB4YzAzM2JiODQg KGtkYl90cmFwKzB4MjU4KTxicj4NCsKgIMKgIMKgIMKgIMKgc3AgPSAweGRlMmM1N2UwwqAgZnAg PSAweGRlMmM1ODA4PGJyPg0KwqAgwqAgwqAgwqAgwqByNCA9IDB4YzA3ODM5MGPCoCByNSA9IDB4 YzA4ZDUyNzA8YnI+DQrCoCDCoCDCoCDCoCDCoHI2ID0gMHhjMGIyMzc1OMKgIHI3ID0gMHhjMGIx Mzk2ODxicj4NCmtkYl90cmFwKCkgYXQga2RiX3RyYXArMHgyNTg8YnI+DQrCoCDCoCDCoCDCoCDC oHBjID0gMHhjMDMzYmI4NMKgIGxyID0gMHhjMDVlYWFiOCAoZXhjZXB0aW9uX2V4aXQpPGJyPg0K wqAgwqAgwqAgwqAgwqBzcCA9IDB4ZGUyYzU4MTDCoCBmcCA9IDB4ZGUyYzU4YTg8YnI+DQrCoCDC oCDCoCDCoCDCoHI0ID0gMHgyMDAwMDBkM8KgIHI1ID0gMHgwMDAwMDAwMDxicj4NCsKgIMKgIMKg IMKgIMKgcjYgPSAweGMwNzM3MmVmwqAgcjcgPSAweGMwYjEzOTY4PGJyPg0KwqAgwqAgwqAgwqAg wqByOCA9IDB4YzA5M2ZhMGPCoCByOSA9IDB4ZGUyYzU4ZTQ8YnI+DQrCoCDCoCDCoCDCoCByMTAg PSAweGMwYjEzYTY4PGJyPg0KZXhjZXB0aW9uX2V4aXQoKSBhdCBleGNlcHRpb25fZXhpdDxicj4N CsKgIMKgIMKgIMKgIMKgcGMgPSAweGMwNWVhYWI4wqAgbHIgPSAweGMwMzNiMDQ0IChrZGJfZW50 ZXIrMHg1MCk8YnI+DQrCoCDCoCDCoCDCoCDCoHNwID0gMHhkZTJjNThhMMKgIGZwID0gMHhkZTJj NThhODxicj4NCsKgIMKgIMKgIMKgIMKgcjAgPSAweDAwMDAwMDAwwqAgcjEgPSAweDAwMDAwMDAx PGJyPg0KwqAgwqAgwqAgwqAgwqByMiA9IDB4MDAwMDAwMTLCoCByMyA9IDB4MDAwMDAwMDA8YnI+ DQrCoCDCoCDCoCDCoCDCoHI0ID0gMHhjMGIyMzc0OMKgIHI1ID0gMHgwMDAwMDAwMDxicj4NCsKg IMKgIMKgIMKgIMKgcjYgPSAweGMwNzM3MmVmwqAgcjcgPSAweGMwYjEzOTY4PGJyPg0KwqAgwqAg wqAgwqAgwqByOCA9IDB4YzA5M2ZhMGPCoCByOSA9IDB4ZGUyYzU4ZTQ8YnI+DQrCoCDCoCDCoCDC oCByMTAgPSAweGMwYjEzYTY4IHIxMiA9IDB4MDAwMDAwMDA8YnI+DQprZGJfZW50ZXIoKSBhdCBr ZGJfZW50ZXIrMHg1ODxicj4NCsKgIMKgIMKgIMKgIMKgcGMgPSAweGMwMzNiMDRjwqAgbHIgPSAw eGMwMmU5Y2EwICh2cGFuaWMrMHgxOGMpPGJyPg0KwqAgwqAgwqAgwqAgwqBzcCA9IDB4ZGUyYzU4 YjDCoCBmcCA9IDB4ZGUyYzU4ZDA8YnI+DQrCoCDCoCDCoCDCoCDCoHI0ID0gMHgwMDAwMDEwMCBy MTAgPSAweGMwYjEzYTY4PGJyPg0KdnBhbmljKCkgYXQgdnBhbmljKzB4MThjPGJyPg0KwqAgwqAg wqAgwqAgwqBwYyA9IDB4YzAyZTljYTDCoCBsciA9IDB4YzAyZTlhMzQgKGR1bXBfc2F2ZWN0eCk8 YnI+DQrCoCDCoCDCoCDCoCDCoHNwID0gMHhkZTJjNThkOMKgIGZwID0gMHhkZTJjNThkYzxicj4N CsKgIMKgIMKgIMKgIMKgcjQgPSAweGQ3MGM4NjAwwqAgcjUgPSAweGRlMmM1ZTkwPGJyPg0KwqAg wqAgwqAgwqAgwqByNiA9IDB4YzMzOTgwOTDCoCByNyA9IDB4ZTBjZmM0NDA8YnI+DQrCoCDCoCDC oCDCoCDCoHI4ID0gMHhjMzM5ODA4MMKgIHI5ID0gMHhkNzBjODYwMDxicj4NCsKgIMKgIMKgIMKg IHIxMCA9IDB4ZGUyYzU5NjA8YnI+DQpkdW1wX3NhdmVjdHgoKSBhdCBkdW1wX3NhdmVjdHg8YnI+ DQrCoCDCoCDCoCDCoCDCoHBjID0gMHhjMDJlOWEzNMKgIGxyID0gMHhjMDVmNTFkYyAoc2V0X3Jl Z3MpPGJyPg0KwqAgwqAgwqAgwqAgwqBzcCA9IDB4ZGUyYzU4ZTTCoCBmcCA9IDB4ZGUyYzU4Zjg8 YnI+DQpzZXRfcmVncygpIGF0IHNldF9yZWdzPGJyPg0KwqAgwqAgwqAgwqAgwqBwYyA9IDB4YzA1 ZjUxZGPCoCBsciA9IDB4YzAyNmY4ZjAgKGVsZjMyX2dldF9mcHJlZ3NldCsweDJjKTxicj4NCsKg IMKgIMKgIMKgIMKgc3AgPSAweGRlMmM1OTAwwqAgZnAgPSAweGRlMmM1OTA4PGJyPg0KwqAgwqAg wqAgwqAgwqByNCA9IDB4YzMzOTgwOTDCoCByNSA9IDB4YzAyNmY4YzQ8YnI+DQplbGYzMl9nZXRf ZnByZWdzZXQoKSBhdCBlbGYzMl9nZXRfZnByZWdzZXQrMHgyYzxicj4NCsKgIMKgIMKgIMKgIMKg cGMgPSAweGMwMjZmOGYwwqAgbHIgPSAweGMwMjZkODQ4IChlbGYzMl9jb3JlZHVtcCsweDMwOCk8 YnI+DQrCoCDCoCDCoCDCoCDCoHNwID0gMHhkZTJjNTkxMMKgIGZwID0gMHhkZTJjNTk4ODxicj4N CsKgIMKgIMKgIMKgIMKgcjQgPSAweGMwOTAyYTdjIHIxMCA9IDB4ZGUyYzU5NjA8YnI+DQplbGYz Ml9jb3JlZHVtcCgpIGF0IGVsZjMyX2NvcmVkdW1wKzB4MzA4PGJyPg0KwqAgwqAgwqAgwqAgwqBw YyA9IDB4YzAyNmQ4NDjCoCBsciA9IDB4YzAyZWVhNzQgKHNpZ2V4aXQrMHhjZTApPGJyPg0KwqAg wqAgwqAgwqAgwqBzcCA9IDB4ZGUyYzU5OTDCoCBmcCA9IDB4ZGUyYzVjZjg8YnI+DQrCoCDCoCDC oCDCoCDCoHI0ID0gMHgwMDAwMDA0ZcKgIHI1ID0gMHhkZjU4MGI2MDxicj4NCsKgIMKgIMKgIMKg IMKgcjYgPSAweGRmNTgwYTc4wqAgcjcgPSAweGMwMjZkNTQwPGJyPg0KwqAgwqAgwqAgwqAgwqBy OCA9IDB4ZGRkY2IyYmPCoCByOSA9IDB4ZGY1ODBhZDQ8YnI+DQrCoCDCoCDCoCDCoCByMTAgPSAw eDAwMDAwMDAwPGJyPg0Kc2lnZXhpdCgpIGF0IHNpZ2V4aXQrMHhjZTA8YnI+DQrCoCDCoCDCoCDC oCDCoHBjID0gMHhjMDJlZWE3NMKgIGxyID0gMHhjMDJlZjM2YyAocG9zdHNpZysweDEyOCk8YnI+ DQrCoCDCoCDCoCDCoCDCoHNwID0gMHhkZTJjNWQwMMKgIGZwID0gMHhkZTJjNWQ4ODxicj4NCsKg IMKgIMKgIMKgIMKgcjQgPSAweDAwMDAwMDA2wqAgcjUgPSAweGRkNDNmYmEwPGJyPg0KwqAgwqAg wqAgwqAgwqByNiA9IDB4ZGUyYzVkMjDCoCByNyA9IDB4ZGUyYzVkMTg8YnI+DQrCoCDCoCDCoCDC oCDCoHI4ID0gMHhkZGRjYjFmOMKgIHI5ID0gMHhkZjNkOWFiODxicj4NCsKgIMKgIMKgIMKgIHIx MCA9IDB4MDAwMDAwMDU8YnI+DQpwb3N0c2lnKCkgYXQgcG9zdHNpZysweDEyODxicj4NCsKgIMKg IMKgIMKgIMKgcGMgPSAweGMwMmVmMzZjwqAgbHIgPSAweGMwMmYzMTZjIChhc3Rfc2lnKzB4MTFj KTxicj4NCsKgIMKgIMKgIMKgIMKgc3AgPSAweGRlMmM1ZDkwwqAgZnAgPSAweGRlMmM1ZTA4PGJy Pg0KwqAgwqAgwqAgwqAgwqByNCA9IDB4ZGQ0M2ZiYTDCoCByNSA9IDB4ZGRkY2IyYmM8YnI+DQrC oCDCoCDCoCDCoCDCoHI2ID0gMHhjMDczNGQyMsKgIHI3ID0gMHgwMDAwMDAwMDxicj4NCsKgIMKg IMKgIMKgIMKgcjggPSAweGRkZGNiMWY4wqAgcjkgPSAweDAwMDAwYWI4PGJyPg0KwqAgwqAgwqAg wqAgcjEwID0gMHgyMjUzMDM4NDxicj4NCmFzdF9zaWcoKSBhdCBhc3Rfc2lnKzB4MTFjPGJyPg0K wqAgwqAgwqAgwqAgwqBwYyA9IDB4YzAyZjMxNmPCoCBsciA9IDB4YzAzNTQ0NGMgKGFzdF9oYW5k bGVyKzB4ZTApPGJyPg0KwqAgwqAgwqAgwqAgwqBzcCA9IDB4ZGUyYzVlMTDCoCBmcCA9IDB4ZGUy YzVlMjg8YnI+DQrCoCDCoCDCoCDCoCDCoHI0ID0gMHhkZTJjNWU0MMKgIHI1ID0gMHgwMDAwMDAw ZTxicj4NCsKgIMKgIMKgIMKgIMKgcjYgPSAweDAwMDA0MDAwwqAgcjcgPSAweGMwOTZiNTljPGJy Pg0KwqAgwqAgwqAgwqAgwqByOCA9IDB4ZGQ0M2ZiYTDCoCByOSA9IDB4MDAwMDAwMDE8YnI+DQph c3RfaGFuZGxlcigpIGF0IGFzdF9oYW5kbGVyKzB4ZTA8YnI+DQrCoCDCoCDCoCDCoCDCoHBjID0g MHhjMDM1NDQ0Y8KgIGxyID0gMHhjMDM1NDM1YyAoYXN0KzB4MjApPGJyPg0KwqAgwqAgwqAgwqAg wqBzcCA9IDB4ZGUyYzVlMzDCoCBmcCA9IDB4ZGUyYzVlMzg8YnI+DQrCoCDCoCDCoCDCoCDCoHI0 ID0gMHhkZTJjNWU0MMKgIHI1ID0gMHhkZDQzZmJhMDxicj4NCsKgIMKgIMKgIMKgIMKgcjYgPSAw eDAwMDAwMDAwwqAgcjcgPSAweDAwMDAwMWIxPGJyPg0KwqAgwqAgwqAgwqAgwqByOCA9IDB4MjJj NGI1MDDCoCByOSA9IDB4MDAwMDAwMDA8YnI+DQphc3QoKSBhdCBhc3QrMHgyMDxicj4NCsKgIMKg IMKgIMKgIMKgcGMgPSAweGMwMzU0MzVjwqAgbHIgPSAweGMwNWVhYTg4IChzd2lfZXhpdCsweDNj KTxicj4NCsKgIMKgIMKgIMKgIMKgc3AgPSAweGRlMmM1ZTQwwqAgZnAgPSAweGJiOWZiZTM4PGJy Pg0KwqAgwqAgwqAgwqAgwqByNCA9IDB4NjAwMDAwMTPCoCByNSA9IDB4ZGQ0M2ZiYTA8YnI+DQpz d2lfZXhpdCgpIGF0IHN3aV9leGl0KzB4M2M8YnI+DQrCoCDCoCDCoCDCoCDCoHBjID0gMHhjMDVl YWE4OMKgIGxyID0gMHhjMDVlYWE4OCAoc3dpX2V4aXQrMHgzYyk8YnI+DQrCoCDCoCDCoCDCoCDC oHNwID0gMHhkZTJjNWU0MMKgIGZwID0gMHhiYjlmYmUzODxicj4NCmRiJmd0OyA8YnI+DQo8YnI+ DQpUaGUgbWFjaGluZSB3YXMgbGFzdCB1cGRhdGVkIGFib3V0IGEgd2VlayBhZ28sIHRoZTxicj4N CnNvdXJjZXMgd2VyZSB1cGRhdGVkIGVhcmxpZXIgdG9kYXkuIFRoaXMgcGFuaWMgaXM8YnI+DQpu ZXcgdG8gbWUuPGJyPg0KPGJyPg0KVGhhbmtzIGZvciByZWFkaW5nLDxicj4NCjxicj4NCmJvYiBw cm9oYXNrYTxicj4NCjxicj4NCjxicj4NCjxicj4NCjwvYmxvY2txdW90ZT48L2Rpdj48L2Rpdj48 L2Rpdj4NCg== --00000000000029fff705f4b55acb-- From nobody Wed Feb 15 07:16:03 2023 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 4PGqBF5j4gz3rQ1H for ; Wed, 15 Feb 2023 07:16:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (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 4PGqBF3xHMz3kt3 for ; Wed, 15 Feb 2023 07:16:21 +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=1676445380; bh=RiJ3Twr+3DEXWump1TUwlNu8z7obZD18WhIUHCRN0g8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=dJGdtyo+Bp9ux7U7arest9e3J/4X4rfc0DjW7bVKk7o5ZGQQRii0K9IsfMrNjK/W3jQUZndfVD/y1B1sR4pcLTD/5byuaRwOCGjvDcteB02GawhexD5Q013JhgYD5tPNZAe5/ohk84/zM2sqmUTQf/wIT4RWUvyx4oW+IsLpirkJ4PZirtq28VZM7ryHxUCmokqmcfT31/caeBzfJOiqRnRFC9qQAf3z8pnhRbBZzsvfmmRKJm9qOqqW4lbfVpGe23OCEm3iKzEej2qNK63XpNkUi6vXQDs4qFfZVX9J5lJlirLwzDLkgriN2D7WiZksjejuVckk7/j3o5MuRgTH7A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676445380; bh=6J1QcXgdUkUEzxvWb0QgmMFAQJsOjyKNGWpes2phu+i=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=sP+So7agQK1Efl4aig5I+vp+K4PuPzvn4/U/aqRNOeg8BKUxd+1uKNHXRwJMu372NheYu6DWb7IALNFV6GaGe0ApY6zqHxCQqDTmgC7lC3JSlGC/eIbOGstPMlW1ATEUugFNF2EQbm+h1cEt8KC8hQwZWFeOFgUBvfJWKxzAEAwzqyLHLoqfjVXLI8MabBMdZMDgL1YexjJ/kGmpWYDqZGdtteIVqf7JGcVfulO98mhPKK1qLz2vN8MKaVLlvkZeTRAIZREmsEziGVhUAL+Yr9DtFueZB1ieXEAPJ3gwYzDBET/pOnJdvCVikFDfyK5m7u7INpmuJYfyqpvH8wVsUA== X-YMail-OSG: YvsNsaQVM1mNliP80GcMuojfMQ06AVhMBDiGGyxAG.YJRHPRkKb8KyXIjeXT0Bw Y1bmYz82sBNOAOinr8wIW5nyk_z93hMDqx1WRvGQZ0P0ltk6FIaIuzju1vk5DFpq9sl1V84FUBrw Lyi1gLkyfCf.wGO6ggtkWqRFdrW0jcHDXhLoka.lJisfA.apy5.3FQc2W4ZsfNBH.anuIrp8CYP9 E.4wj4IHDG.IWBYCUIzJYRAOikx57ZoQyGrTXurOle26eCIN62wT3e4vrAjnqf3g0dnDHwPvAANy YXXg028VlwQI2YaKVPpPV2kN1IgP0bJ3erfj6yldIzpmvcr2Qp.XwQpi.5z98Pzi4S3iEgBeSo16 I3S0dcxEymi7tu3erUxLODfaliibUnbMMNa6.XlfYDOxsTiveygytjN6.Md83a60u_1EG0jBZoPq E5np0vTFn_xCZeGlUxo2BCujnuFsGfq0tchaIhy5rQp9VYw7.QFxCjdHywGUrksHRDE_xudMRLpH SwQqH6dUXM.7KvdZ7BXADGgqHzkLLwpBhZjh4wqfKvY_iobSvne4301rwQ.CCJJgqavdzPdMqbSQ 03w9oeMx7eir.YCPYtBB_WadI21ShBj11FRsyZi84YszRGtEW8a0tRb2m4wvD4ggwPBlAODYYoBc 3hUUegFhgvdljQOyTzP3RQkRpTMS4S3aU0hA8q_Bq5RlwPflKF49qCf5F9nV_6.F5nNdDjuHswka 78eb5ACmI1GZ5bXmGeeX11KNmD0IkdAY7dS3mKCnlqcmJKOzLau1d7VxGwYcyWPLsyAnrmfGVjtP sNjLvMvBIiZvYnh9CA2B2BIEMwk_EFw.3w44fd8ZdtMdn2hvMRs.Q9qbpibq5ciWFifzKs_x.zFH LJRZW2ONiJfXe7mXMiEk65xZXRl6ioBKGZwC51tTHgxFsgBno.F2kIGRRo2uLSyYYMN6JzqbYxvx tdSKGg5DRcfPjaybilNiKAznqQaZ9WlKbrSmL_K5UVyM1Hz1sjVFZ.b4R2w_jVqrrYaegGyaZZXj NXbUKcV_ChQN8zouUJTbBDtw5U41gxCLNA8efWP9t_9uzj0JPZVwIu.DyHiRNMIWyrn1HGemjQIn k2Hleor4i5H4xYDw7YlI8Gp.BB83CapFDe70ZcuKhlkz0pH8u9ndybu._dBP0.EuzkpEyDU9ZDy0 Sbb8qwHA6JNcSpYoF8obfaOgZm7RkpTRh4IdUbq8_nYtKk3K05TPoi2As9i_fqLrSiXnHKGxm6bv kZ_5kK2aVCzR0hck2fDaK4XLUFej39lIKL_TkoOQ_kU97w2r1BY4rDH.N5qjq6dMamw5LgRgGDeo 2U.cyBFaghVzyNrNNKDNoFltCs3Cm5Xfq.k5NkrGOB8ctUcc3DT74DrmU0ZQjqHz6QWC6gk1c.br gfTgChHXVQLl3v6zSJurLx5XNL6UaomFIg9qa1ZXuPfffa.qkc_Lal0oF0qMIi4B3r24IRBjzgP3 I2tlOMMz8ZfAA7kwjQYhyeqOGah0gutNYXF_P3RwVsFQhAyJabC8eyPFAf.O7OH1kFV0nStRZIX. d_vl557e4UeISeWZtmGAcmxCYPgcQkgj76mupd5Y3bJWujzbGtiUQ2xB4XttofTL3GLhkGXk.axK QI7PxARGV0v0c2ZueEBGyQ4Pn8RcXqvJKrIREZ3NI9Z51yurSF0CGkheFymuHiWpsowvOlBFl_3o 4j6F5dcsBj2WyW.rmGVE_wcD8T_ZdNuI0fH_WlVQK45BN8MIwamYbGzSnAzfTpcRyPRkea03wyjp gFNVmAgZ.KWUItdFbuRC4ijI9ILxzaJZ46._5L4YMsed2FiV4IQP2P8YBLRrwy9_JdJaOHETGfsc oybp.aFJveWwdqIvA8x4yc9TEFrQQ5BDAXJU7xi81XE5vo0IdGOdAO2Bn3595t4eY9uEnGu9sFzi dgXJXMeOXnEdyaZt_CvSAbrLD3tReXzpdqDU8bId_nwQTp5YMm_NfHJTULcM0sh_sut4K1gc74v1 j8mnqDRd0IuAfqzxkGgepsoSXULBum7mNEEvyA2qLtSsvsp7EpPdBEDcyZzJjjWSR5p6DBh8_8qu sM6M3DSgQ26p5UrBJbr_VmIWVa6e0JsqmBKBszOet7zQz2HUuQc9_4vIwr48m1XCFZ51fM.jQCh8 BnjsQV_REsjAhu.e0tYabXbNXiM6fQf3p23dXVbuF6evKE3R1yG9oXTyWe8iPdG2jgSJaKsq0Bp3 1GbaEsX0pnb7YD5TOAya9zPOXiSl6P5ktwA8fTlPIffxLI1ORBK50fD6geZPnC9zK4Pal05AUSy4 t X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Wed, 15 Feb 2023 07:16:20 +0000 Received: by hermes--production-ne1-746bc6c6c4-kcw5g (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c1967e549ce0a7459282a543cac0bf99; Wed, 15 Feb 2023 07:16:14 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: Armv7 panic on -current, rpi2 buildworld From: Mark Millard In-Reply-To: Date: Tue, 14 Feb 2023 23:16:03 -0800 Cc: bob prohaska , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20230215025741.GA32086@www.zefox.net> To: Warner Losh X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4PGqBF3xHMz3kt3 X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 14, 2023, at 20:16, Warner Losh wrote: > Sorry to top post... what program was dumping core? Looks like a too = strict assert Just a possible point, given recent kernel floating point work: Because of Bob's note, I tried to do a typical build and test of some benchmark programs that I sometimes use that involve floating point in some of the programs, some use with multithreading involved. (As FreeBSD and g++ progress I tend to do this once and a while, not as often on armv7 as on aarch64.) On armv7, I now get a message about a failure of an internal cross-check, which also leads to the program being stopped early. The messaging from run to run varies what the failure is, but the runs should not vary and should not fail the cross-checks --and previously did not, including when I last tried armv7. (Not recently.) For the specific example failure, the initial serial (single thread) test with float involved works but the following multi-thread test in the same program fails and causes the program to stop when it notices there is a problem. The programs that do not test floating point do not fail. These can involve floating point outside the algorithm benchmarked, but with no multi-threading involved for such and no floating point based cross- checks involved. At this point it is far from obvious to me how I would trackdown the specifics of what leads to the failed cross-checks. But the above is suggestive of there being problems for armv7 handling of saving and restoring floating point context for multi-threading. I've no clue if such are limited to the floating point values or not. > Warner >=20 > On Tue, Feb 14, 2023, 7:57 PM bob prohaska wrote: > Building world on an RPi2 armv7, buildworld stopped with > bob@www:/usr/src % panic: Called fill_fpregs while the kernel is using = the VFP > cpuid =3D 0 > time =3D 1676427410 > KDB: stack backtrace: > db_trace_self() at db_trace_self > pc =3D 0xc05e8160 lr =3D 0xc007aa04 = (db_trace_self_wrapper+0x30) > sp =3D 0xde2c5790 fp =3D 0xde2c58a8 > db_trace_self_wrapper() at db_trace_self_wrapper+0x30 > pc =3D 0xc007aa04 lr =3D 0xc02e9c54 (vpanic+0x140) > sp =3D 0xde2c58b0 fp =3D 0xde2c58d0 > r4 =3D 0x00000100 r5 =3D 0x00000000 > r6 =3D 0xc07372ef r7 =3D 0xc0b13968 > vpanic() at vpanic+0x140 > pc =3D 0xc02e9c54 lr =3D 0xc02e9a34 (dump_savectx) > sp =3D 0xde2c58d8 fp =3D 0xde2c58dc > r4 =3D 0xd70c8600 r5 =3D 0xde2c5e90 > r6 =3D 0xc3398090 r7 =3D 0xe0cfc440 > r8 =3D 0xc3398080 r9 =3D 0xd70c8600 > r10 =3D 0xde2c5960 > dump_savectx() at dump_savectx > pc =3D 0xc02e9a34 lr =3D 0xc05f51dc (set_regs) > sp =3D 0xde2c58e4 fp =3D 0xde2c58f8 > set_regs() at set_regs > pc =3D 0xc05f51dc lr =3D 0xc026f8f0 = (elf32_get_fpregset+0x2c) > sp =3D 0xde2c5900 fp =3D 0xde2c5908 > r4 =3D 0xc3398090 r5 =3D 0xc026f8c4 > elf32_get_fpregset() at elf32_get_fpregset+0x2c > pc =3D 0xc026f8f0 lr =3D 0xc026d848 (elf32_coredump+0x308) > sp =3D 0xde2c5910 fp =3D 0xde2c5988 > r4 =3D 0xc0902a7c r10 =3D 0xde2c5960 > elf32_coredump() at elf32_coredump+0x308 > pc =3D 0xc026d848 lr =3D 0xc02eea74 (sigexit+0xce0) > sp =3D 0xde2c5990 fp =3D 0xde2c5cf8 > r4 =3D 0x0000004e r5 =3D 0xdf580b60 > r6 =3D 0xdf580a78 r7 =3D 0xc026d540 > r8 =3D 0xdddcb2bc r9 =3D 0xdf580ad4 > r10 =3D 0x00000000 > sigexit() at sigexit+0xce0 > pc =3D 0xc02eea74 lr =3D 0xc02ef36c (postsig+0x128) > sp =3D 0xde2c5d00 fp =3D 0xde2c5d88 > r4 =3D 0x00000006 r5 =3D 0xdd43fba0 > r6 =3D 0xde2c5d20 r7 =3D 0xde2c5d18 > r8 =3D 0xdddcb1f8 r9 =3D 0xdf3d9ab8 > r10 =3D 0x00000005 > postsig() at postsig+0x128 > pc =3D 0xc02ef36c lr =3D 0xc02f316c (ast_sig+0x11c) > sp =3D 0xde2c5d90 fp =3D 0xde2c5e08 > r4 =3D 0xdd43fba0 r5 =3D 0xdddcb2bc > r6 =3D 0xc0734d22 r7 =3D 0x00000000 > r8 =3D 0xdddcb1f8 r9 =3D 0x00000ab8 > r10 =3D 0x22530384 > ast_sig() at ast_sig+0x11c > pc =3D 0xc02f316c lr =3D 0xc035444c (ast_handler+0xe0) > sp =3D 0xde2c5e10 fp =3D 0xde2c5e28 > r4 =3D 0xde2c5e40 r5 =3D 0x0000000e > r6 =3D 0x00004000 r7 =3D 0xc096b59c > r8 =3D 0xdd43fba0 r9 =3D 0x00000001 > ast_handler() at ast_handler+0xe0 > pc =3D 0xc035444c lr =3D 0xc035435c (ast+0x20) > sp =3D 0xde2c5e30 fp =3D 0xde2c5e38 > r4 =3D 0xde2c5e40 r5 =3D 0xdd43fba0 > r6 =3D 0x00000000 r7 =3D 0x000001b1 > r8 =3D 0x22c4b500 r9 =3D 0x00000000 > ast() at ast+0x20 > pc =3D 0xc035435c lr =3D 0xc05eaa88 (swi_exit+0x3c) > sp =3D 0xde2c5e40 fp =3D 0xbb9fbe38 > r4 =3D 0x60000013 r5 =3D 0xdd43fba0 > swi_exit() at swi_exit+0x3c > pc =3D 0xc05eaa88 lr =3D 0xc05eaa88 (swi_exit+0x3c) > sp =3D 0xde2c5e40 fp =3D 0xbb9fbe38 > KDB: enter: panic > [ thread pid 81621 tid 101111 ] > Stopped at kdb_enter+0x54: ldrb r15, [r15, r15, ror r15]! > db> bt > Tracing pid 81621 tid 101111 td 0xdd43fba0 > db_trace_self() at db_trace_self > pc =3D 0xc05e8160 lr =3D 0xc00774a0 (db_stack_trace+0x140) > sp =3D 0xde2c55d8 fp =3D 0xde2c55f0 > db_stack_trace() at db_stack_trace+0x140 > pc =3D 0xc00774a0 lr =3D 0xc00770f0 (db_command+0x310) > sp =3D 0xde2c55f8 fp =3D 0xde2c56a0 > r4 =3D 0xc0745722 r5 =3D 0x00000062 > r6 =3D 0x00000000 r10 =3D 0x00000000 > db_command() at db_command+0x310 > pc =3D 0xc00770f0 lr =3D 0xc0076db8 (db_command_loop+0x64) > sp =3D 0xde2c56a8 fp =3D 0xde2c56b8 > r4 =3D 0xc07ac186 r5 =3D 0xc07ab7fe > r6 =3D 0xc0986f5c r7 =3D 0xc0b13968 > r8 =3D 0xc0b23738 r9 =3D 0x00000000 > r10 =3D 0x00000001 > db_command_loop() at db_command_loop+0x64 > pc =3D 0xc0076db8 lr =3D 0xc007ab88 (db_trap+0x128) > sp =3D 0xde2c56c0 fp =3D 0xde2c57d8 > r4 =3D 0x00000000 r5 =3D 0xc0986f50 > r6 =3D 0xc0b23758 r10 =3D 0x00000001 > db_trap() at db_trap+0x128 > pc =3D 0xc007ab88 lr =3D 0xc033bb84 (kdb_trap+0x258) > sp =3D 0xde2c57e0 fp =3D 0xde2c5808 > r4 =3D 0xc078390c r5 =3D 0xc08d5270 > r6 =3D 0xc0b23758 r7 =3D 0xc0b13968 > kdb_trap() at kdb_trap+0x258 > pc =3D 0xc033bb84 lr =3D 0xc05eaab8 (exception_exit) > sp =3D 0xde2c5810 fp =3D 0xde2c58a8 > r4 =3D 0x200000d3 r5 =3D 0x00000000 > r6 =3D 0xc07372ef r7 =3D 0xc0b13968 > r8 =3D 0xc093fa0c r9 =3D 0xde2c58e4 > r10 =3D 0xc0b13a68 > exception_exit() at exception_exit > pc =3D 0xc05eaab8 lr =3D 0xc033b044 (kdb_enter+0x50) > sp =3D 0xde2c58a0 fp =3D 0xde2c58a8 > r0 =3D 0x00000000 r1 =3D 0x00000001 > r2 =3D 0x00000012 r3 =3D 0x00000000 > r4 =3D 0xc0b23748 r5 =3D 0x00000000 > r6 =3D 0xc07372ef r7 =3D 0xc0b13968 > r8 =3D 0xc093fa0c r9 =3D 0xde2c58e4 > r10 =3D 0xc0b13a68 r12 =3D 0x00000000 > kdb_enter() at kdb_enter+0x58 > pc =3D 0xc033b04c lr =3D 0xc02e9ca0 (vpanic+0x18c) > sp =3D 0xde2c58b0 fp =3D 0xde2c58d0 > r4 =3D 0x00000100 r10 =3D 0xc0b13a68 > vpanic() at vpanic+0x18c > pc =3D 0xc02e9ca0 lr =3D 0xc02e9a34 (dump_savectx) > sp =3D 0xde2c58d8 fp =3D 0xde2c58dc > r4 =3D 0xd70c8600 r5 =3D 0xde2c5e90 > r6 =3D 0xc3398090 r7 =3D 0xe0cfc440 > r8 =3D 0xc3398080 r9 =3D 0xd70c8600 > r10 =3D 0xde2c5960 > dump_savectx() at dump_savectx > pc =3D 0xc02e9a34 lr =3D 0xc05f51dc (set_regs) > sp =3D 0xde2c58e4 fp =3D 0xde2c58f8 > set_regs() at set_regs > pc =3D 0xc05f51dc lr =3D 0xc026f8f0 = (elf32_get_fpregset+0x2c) > sp =3D 0xde2c5900 fp =3D 0xde2c5908 > r4 =3D 0xc3398090 r5 =3D 0xc026f8c4 > elf32_get_fpregset() at elf32_get_fpregset+0x2c > pc =3D 0xc026f8f0 lr =3D 0xc026d848 (elf32_coredump+0x308) > sp =3D 0xde2c5910 fp =3D 0xde2c5988 > r4 =3D 0xc0902a7c r10 =3D 0xde2c5960 > elf32_coredump() at elf32_coredump+0x308 > pc =3D 0xc026d848 lr =3D 0xc02eea74 (sigexit+0xce0) > sp =3D 0xde2c5990 fp =3D 0xde2c5cf8 > r4 =3D 0x0000004e r5 =3D 0xdf580b60 > r6 =3D 0xdf580a78 r7 =3D 0xc026d540 > r8 =3D 0xdddcb2bc r9 =3D 0xdf580ad4 > r10 =3D 0x00000000 > sigexit() at sigexit+0xce0 > pc =3D 0xc02eea74 lr =3D 0xc02ef36c (postsig+0x128) > sp =3D 0xde2c5d00 fp =3D 0xde2c5d88 > r4 =3D 0x00000006 r5 =3D 0xdd43fba0 > r6 =3D 0xde2c5d20 r7 =3D 0xde2c5d18 > r8 =3D 0xdddcb1f8 r9 =3D 0xdf3d9ab8 > r10 =3D 0x00000005 > postsig() at postsig+0x128 > pc =3D 0xc02ef36c lr =3D 0xc02f316c (ast_sig+0x11c) > sp =3D 0xde2c5d90 fp =3D 0xde2c5e08 > r4 =3D 0xdd43fba0 r5 =3D 0xdddcb2bc > r6 =3D 0xc0734d22 r7 =3D 0x00000000 > r8 =3D 0xdddcb1f8 r9 =3D 0x00000ab8 > r10 =3D 0x22530384 > ast_sig() at ast_sig+0x11c > pc =3D 0xc02f316c lr =3D 0xc035444c (ast_handler+0xe0) > sp =3D 0xde2c5e10 fp =3D 0xde2c5e28 > r4 =3D 0xde2c5e40 r5 =3D 0x0000000e > r6 =3D 0x00004000 r7 =3D 0xc096b59c > r8 =3D 0xdd43fba0 r9 =3D 0x00000001 > ast_handler() at ast_handler+0xe0 > pc =3D 0xc035444c lr =3D 0xc035435c (ast+0x20) > sp =3D 0xde2c5e30 fp =3D 0xde2c5e38 > r4 =3D 0xde2c5e40 r5 =3D 0xdd43fba0 > r6 =3D 0x00000000 r7 =3D 0x000001b1 > r8 =3D 0x22c4b500 r9 =3D 0x00000000 > ast() at ast+0x20 > pc =3D 0xc035435c lr =3D 0xc05eaa88 (swi_exit+0x3c) > sp =3D 0xde2c5e40 fp =3D 0xbb9fbe38 > r4 =3D 0x60000013 r5 =3D 0xdd43fba0 > swi_exit() at swi_exit+0x3c > pc =3D 0xc05eaa88 lr =3D 0xc05eaa88 (swi_exit+0x3c) > sp =3D 0xde2c5e40 fp =3D 0xbb9fbe38 > db>=20 >=20 > The machine was last updated about a week ago, the > sources were updated earlier today. This panic is > new to me. >=20 > Thanks for reading, >=20 > bob prohaska >=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Wed Feb 15 15:44:24 2023 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 4PH2S16jwWz3qSkQ for ; Wed, 15 Feb 2023 15:44:01 +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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PH2Rz5sZJz3R1s for ; Wed, 15 Feb 2023 15:43:59 +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.16.1/8.15.2) with ESMTPS id 31FFiPih034396 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 15 Feb 2023 07:44:25 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 31FFiPIH034395 for freebsd-arm@freebsd.org; Wed, 15 Feb 2023 07:44:25 -0800 (PST) (envelope-from fbsd) Date: Wed, 15 Feb 2023 07:44:24 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash) Message-ID: <20230215154424.GA34278@www.zefox.net> References: <20230212191308.GA21535@www.zefox.net> <20230212195324.GB21535@www.zefox.net> <03840D0B-13D4-4F22-BDAF-2887A4D78BED@yahoo.com> <20230213232519.GD95670@funkthat.com> <20230214161415.GA28276@www.zefox.net> <20230214183827.GG95670@funkthat.com> <20230214210601.GA28959@www.zefox.net> <20230214232746.GI95670@funkthat.com> 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 In-Reply-To: <20230214232746.GI95670@funkthat.com> X-Spamd-Result: default: False [-1.10 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[zefox.net]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PH2Rz5sZJz3R1s X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N On Tue, Feb 14, 2023 at 03:27:46PM -0800, John-Mark Gurney wrote: > > In this case, an inode's mtime is wildly incorrect. Here is a simple > patch that will let it get farther, BUT, it doesn't necessarily mean > that the kernel can properly handle the mtime: > diff --git a/sbin/fsck_ffs/inode.c b/sbin/fsck_ffs/inode.c > index 82338f4f8c08..d0892a822dc5 100644 > --- a/sbin/fsck_ffs/inode.c > +++ b/sbin/fsck_ffs/inode.c > @@ -1311,7 +1311,10 @@ prtinode(struct inode *ip) > printf("SIZE=%ju ", (uintmax_t)DIP(dp, di_size)); > t = DIP(dp, di_mtime); > p = ctime(&t); > - printf("MTIME=%12.12s %4.4s ", &p[4], &p[20]); > + if (p == NULL) > + printf("MTIME=invalid "); > + else > + printf("MTIME=%12.12s %4.4s ", &p[4], &p[20]); > } > > void I tried to apply the patch with root@www:/usr/src # patch -p1 < fsck.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |index 82338f4f8c08..d0892a822dc5 100644 |--- a/sbin/fsck_ffs/inode.c |+++ b/sbin/fsck_ffs/inode.c -------------------------- Patching file sbin/fsck_ffs/inode.c using Plan A... Hunk #1 failed at 1311. 1 out of 1 hunks failed--saving rejects to sbin/fsck_ffs/inode.c.rej Hmm... Ignoring the trailing garbage. done Obviously I'm doing something dumb.....any hints? Thanks for writing, bob prohaska From nobody Wed Feb 15 17:40:51 2023 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 4PH53B4191z3qc6w for ; Wed, 15 Feb 2023 17:41:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (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 4PH53B1gdgz40Xj for ; Wed, 15 Feb 2023 17:41:09 +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=1676482867; bh=VeeYkNV+8y45TGYGDTE8BC1qvFu15obe5jKVWrddiC8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=UDZUYphyQPTI0h92CciOZxZG/QRUPiINr10lbkWWAtuLWh9unHUNcogk+Rv2zC3KYQrWusnylzMk5jlMU1G8I2n4x7GXAo6M8IRGnI89DO+52/ULXgUUKvbp5qQEE/hY09RdWPcYfaMMxZvjEDdGndn+xzSlBIvEAsryFT1VZVvvWBlu7bGN2SNAOIKvGrtpJMeVUlLDuCvnjIqiHyyDj0TKAaa+CI9isyrKnjAscqxcBtBQzh1lNp3bPGs5BpBxAtGnc6q4z3LwpJPa8syjJq0OxuHG4l2kVxE/F1kjtcY4MnkuWqdWmncNjpAOIk3SHoNxpqVDJyzI6C6k5UfkVA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676482867; bh=2xMaSQ/zkLmh/dnNo1H6dP8wLOYj6Hr3KNjks3yZj6w=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=KEf6f0VEwkzrvsGk3Tqcnrubcz6pSdp+TYSr/WR8YcTE3u/ayL+UJn/acxNwM5YJtktopsbEpKBN8Wy26aIO9ToviNPXJYQntw0LB1JlkSoiXueeFn7kL8IbLFH7nducK6tIgaLZ5/QdvQcclQG+AXH22VLJXWzyDpourXB6lZBo7XpwlzCg6VzM+H4ar/3hneI4/Ok3b7pivWPEccbYVnfYVLUH8BzgLbJ40qY+Ny8LKrw2KLm9v/7KFq+UbDVly5pHGZNpahbsUrrzgzqu11dxJegbAbj0Gma9uR2y+m5SoYZU4S4qDFKpUE7SzQUa2YDak6RvjrLX5qP7yxuyoA== X-YMail-OSG: 6uymPpAVM1ky_1D4Yo3BmBh.l3TUHG9Y8LP_2GTOov83VBVFfTZNa3rS.lGKstX .kb3U8MFTBc.1jwrW.mYFOsLEg4DpbVNJWIsgWFS.LNgy7CSC2cOoRRjmY6PosdALbwy9OnfgMnb HNnodj9yVQ3PLXUkc2p_BwgG2K68I2HdOnvOSyeoGcCExyw65ccs9sjA_FUgUBmEUoaNg_AWUUev xonEXsMcGB2HyH5WpxxNAiMaMwab7K8jdIJaTOM9iaJNh47vp3SoCk1GevVhqkZ3ZzyF7lKz8JcB zkzpc1V2y9dt7LKs.y.ZEUyxDlL9EvdwglwOHaSQuupcD8BSlvVvi.PUvhdQ7BjHgtJ6EfeP6PTF O87UX_lhzOXckhCdAPwI.f.QUTGypE8FnbGlc9Ccwj9IfA93AAyu3fBaV2bVf7qN8Qa5D7D7veDK eJjyJNGQlfyZGScKFPUDbnCvXlrMhdHErzJv4DAmyyfXO6UCdxFoB1cuUe_i7Q8K2PaRMiJQfjz7 ElMsQCqtFmYxNqie8nTyk5hsRsFqqyUTORejhw5gPVjiVjjtihFKY4E5tZfBDnQrdSrH503_WmF1 m5u3597QmtfStNt8wg3tuvVB.uy.R0s9LYHxH.sYEUJAzegXoDZtZ82qlz30ZEiPASzRqTBnj1tz h4NM.w26.duXJn18zUnE1FJi8ZB2j8IO94FNPyXvc8tkr9wAYYweHDswyeWxWpQYGVaU9hpmTa5x jn476g9p6L1sZ_iWF6PxLE2nx21mkGCgT07IL3SXA1vuPGGTRbhDywBYOgE.sNGJl3.wpfNH2f2G TAie9pVYhb0jdoBLaBGhFWkqO3JZZY2fSjc4cI_CuO8CFTOAfabB2dRCNMFZtsz0AN_2xx_kDBUF uX0MJS5acCHZXojlVa0LzFBAvPBBdijQumdFzE.LYP0Tc2fzej6Wwq9dftBKsDVW0vrhAvE1Uh7W DUwQYdQ5i30hIz72oro2NnY1Gjg6B1yX7orNjqUdsp682en2c89rMcPa6dm7ESXCS5G8u.qVtB4J HR.azkxxDxY0t.1xdDkwwgXtHP0e74EKWjZazLscCvqz1jyhY7M617OKwy9F8a6c9CnVjynLdMNp jP5_z.o8cRAc.h.A7V_IIEHeG9HphTgA68wFCm0Q.L.wPEeTXBSVhGVfg0DQfhmazbPCMUxfxQZ9 GkqukkDwcbIhBq8TkQwi0uxXMski3QsFD2BpqKhoDDS4Do7FwQrcvj4YPDW17Do1V_AgTwgmudFJ jj08k5QdSCLxpREwU4hbfiFplXJFPtLC0wCBKR6fd0kOUtnrb6Hn0QeA8PHMvJbw9rX5a9UPw5eG 2morTYaCiLv8JOncTwPkQQGK.vcG.xGg7gJ3OuP7NnPK9xN93vXOjeptD4bI1w6kduI6Ar4IbS3i Awhvv3Nbz4rAPNRw1NSRM6BGbBu7GGgc15RmXX6i_qnP7guWWOBfTgew7sXeW0chZCbv8uQMmw3N qS3IhJsQRrmk5C1SmG.s2E7T.pxbCWfypDRGiEjcJT5N9a_yeNYv8f5dyE1TawNdd2LbA5fW3mRt rfsAmp1_KBvufeR2TYI97k3v9K2Q3uJmtvDjt4LRVQ3bui0kGhitMQHZhXaw7RQyZjtL.RoBV43K uruyUMkvypWTEB0atoljbSs5V1zXnsNNxBKHaa4RdBI6VeoN8ELahxp68JvEAYKCtofY5vMGD_b9 9EEh6addPIFFk18yIclAnPIvY25il6hb1C5DrRJfVX4v6UFLy47jHLqhxCiMn0ercCpaO_E7Y58k qoK7wpo5cB53U5U8jZooL0Xf1yiGy7eW_MdGcrj1Adj3gv5wKRqiAZw_GbsM0so0fNzYm6INjHr. 3hviIBQX2JafrlbROIHO50VlciP2m6K2BQ2C.WrIK32hZ7.TKq.Pgr8htUoIG.AGXYUgWCPD2MKT AvTeGZC1pBvfe5949CSWcDIuqBAVASj8g3fxClZYeegXdzZw6gFlC7fyHv_tppxzmQJodKRtz28P m7y4VmsN5vQTL6sqkWxrWDeUllo2MNyMg8X.WA9vaP2jO03h4yYfvN3n_GKtVdwW0jpzD_fM82dZ YUQxyWQj__FCHXfUBAgL0o.xZc2bAK.Su02VTDNhxjTIcOG8lBS1bCrm1vwQJBGN9xpOXckCJnyf 3nRivo7n_iPdu5TNI3Q3tC0GFpusuq2O1RLJRqYWOYmbOsh4F2gjxqvsKjGVb5.o6GvKGeYAcfe6 8Zr8_lD89RgaO1sLlxKXslUD32zcnvfUPYsBXFjWV6.P81YmpVpG.08qohf1w_mHUzzFDd.U4W0U - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Wed, 15 Feb 2023 17:41:07 +0000 Received: by hermes--production-bf1-57c96c66f6-bbrmg (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 94d80fbc7439a567606e34e00156c5e4; Wed, 15 Feb 2023 17:41:04 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash) From: Mark Millard In-Reply-To: <20230215154424.GA34278@www.zefox.net> Date: Wed, 15 Feb 2023 09:40:51 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: <20230212191308.GA21535@www.zefox.net> <20230212195324.GB21535@www.zefox.net> <03840D0B-13D4-4F22-BDAF-2887A4D78BED@yahoo.com> <20230213232519.GD95670@funkthat.com> <20230214161415.GA28276@www.zefox.net> <20230214183827.GG95670@funkthat.com> <20230214210601.GA28959@www.zefox.net> <20230214232746.GI95670@funkthat.com> <20230215154424.GA34278@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4PH53B1gdgz40Xj X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 15, 2023, at 07:44, bob prohaska wrote: > On Tue, Feb 14, 2023 at 03:27:46PM -0800, John-Mark Gurney wrote: >> >> In this case, an inode's mtime is wildly incorrect. Here is a simple >> patch that will let it get farther, BUT, it doesn't necessarily mean >> that the kernel can properly handle the mtime: >> diff --git a/sbin/fsck_ffs/inode.c b/sbin/fsck_ffs/inode.c >> index 82338f4f8c08..d0892a822dc5 100644 >> --- a/sbin/fsck_ffs/inode.c >> +++ b/sbin/fsck_ffs/inode.c >> @@ -1311,7 +1311,10 @@ prtinode(struct inode *ip) >> printf("SIZE=%ju ", (uintmax_t)DIP(dp, di_size)); >> t = DIP(dp, di_mtime); >> p = ctime(&t); >> - printf("MTIME=%12.12s %4.4s ", &p[4], &p[20]); >> + if (p == NULL) >> + printf("MTIME=invalid "); >> + else >> + printf("MTIME=%12.12s %4.4s ", &p[4], &p[20]); >> } (The above probably has more whitespace changes than what you started with.) >> void > > I tried to apply the patch with > root@www:/usr/src # patch -p1 < fsck.patch > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -------------------------- > |index 82338f4f8c08..d0892a822dc5 100644 > |--- a/sbin/fsck_ffs/inode.c > |+++ b/sbin/fsck_ffs/inode.c > -------------------------- > Patching file sbin/fsck_ffs/inode.c using Plan A... > Hunk #1 failed at 1311. > 1 out of 1 hunks failed--saving rejects to sbin/fsck_ffs/inode.c.rej > Hmm... Ignoring the trailing garbage. > done My guess is the following is the type of issue. Looking in my /usr/main-src/sbin/fsck_ffs/inode.c I see that the original file has a leading tab instead of spaces. The following mostly ignores the 1st column that should have a space, -, or + in the diff output for the file-content lines. It is mostly about the text after the first column. So, if you have spaces instead after the first column for the lines that start with a space, those lines will not match, leading to a rejection for the context matching done by patch. It is common for E-mail based text to end up with whitespace not preserved, especially leading whitespace. So patches received that way commonly need adjustment to get back the original whitespace structure. Copying and pasting text from a web browser window can have its own whitespace-not-preserved issues. Sometimes it can be easier to hand edit the original file and then confirm the edit via looking at a git diff and seeing if it looks like the original patch. In part, this is because unchanged lines can be left alone instead of needing whitespace adjustments in a mangled patch. For the new lines, the "+" lines can sometimes be copied/pasted and the leading "+" removed. Especially true if the whitespace details on those lines do not really matter for a temporary purpose. (Otherwise: adjust the whitespace afterwards.) === Mark Millard marklmi at yahoo.com From nobody Wed Feb 15 19:08:56 2023 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 4PH7052m9qz3rCbl for ; Wed, 15 Feb 2023 19:08:37 +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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PH7046kj0z4D4H for ; Wed, 15 Feb 2023 19:08:36 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 31FJ8us7034800 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 15 Feb 2023 11:08:57 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 31FJ8uGq034799; Wed, 15 Feb 2023 11:08:56 -0800 (PST) (envelope-from fbsd) Date: Wed, 15 Feb 2023 11:08:56 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash) Message-ID: <20230215190856.GA34665@www.zefox.net> References: <20230212195324.GB21535@www.zefox.net> <03840D0B-13D4-4F22-BDAF-2887A4D78BED@yahoo.com> <20230213232519.GD95670@funkthat.com> <20230214161415.GA28276@www.zefox.net> <20230214183827.GG95670@funkthat.com> <20230214210601.GA28959@www.zefox.net> <20230214232746.GI95670@funkthat.com> <20230215154424.GA34278@www.zefox.net> 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 In-Reply-To: X-Rspamd-Queue-Id: 4PH7046kj0z4D4H X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Wed, Feb 15, 2023 at 09:40:51AM -0800, Mark Millard wrote: > > Looking in my /usr/main-src/sbin/fsck_ffs/inode.c > I see that the original file has a leading tab > instead of spaces. > > The following mostly ignores the 1st column that > should have a space, -, or + in the diff output for > the file-content lines. It is mostly about the text > after the first column. > > So, if you have spaces instead after the first column > for the lines that start with a space, those lines > will not match, leading to a rejection for the > context matching done by patch. Replacing spaces with tabs allowed patch to find the location, but it still fails with patch: **** malformed patch at line 5: printf("SIZE=%ju ", (uintmax_t)DIP(dp, di_size)); Editing by hand looks like a good way to drive myself crazy 8-) I take it the goal is to find the lines printf("SIZE=%ju ", (uintmax_t)DIP(dp, di_size)); t = DIP(dp, di_mtime); p = ctime(&t); delete the line printf("MTIME=%12.12s %4.4s ", &p[4], &p[20]); and add the four lines if (p == NULL) printf("MTIME=invalid "); else printf("MTIME=%12.12s %4.4s ", &p[4], &p[20]); Do I at least correctly understand the intent of the patch? Thanks for all your patience, it might be best to wait for a fix to be committed to src. bob prohaska From nobody Wed Feb 15 19:39:13 2023 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 4PH7gh66tLz3rFh9 for ; Wed, 15 Feb 2023 19:39:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (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 4PH7gh2q6tz4Jlx for ; Wed, 15 Feb 2023 19:39:28 +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=1676489966; bh=+YrjK5jFkLVLjJV2/gx2NamGSBQMvUpicY++SV7yfMo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=hlsIsa/ix4FD49dHjMI49JpPAmOTv9H5jmhCjIi28e4/L/ahgeC6NiOd1299nt1Mr/Ze331FYm6ZgyCm/4jS+w4WadMkfYbqg062q8RuWe989S4u+vJea7FsxgksNE/aWytld3HUOFIzRMj55HFcDQSwBqvPd7P5HF1uB771o5vjjVMvI0mfTznqJri6owmNeXVxJYI4CH8wOoRqNTFG7mAR1yi+jQVm0XgmM3D3ZpU13+M84hnskjMV8RBCDSXoc92m4Z0GMzCikWL9dyBnjamenp4RexxiBNZ12UPaEfPUzcfcM4WOSwk65ner4G6m4lrtGikNAeI2d39/hUJh7Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676489966; bh=LHy1rzKMpvpXFXUgP2O3QV2boFeGst/+K6p7My9+CsD=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=LIEqyQxUMNuKWdCIglN8gFV/T91YRNOp69o0Gu/oOMW52dblvI4OYK9pFQQvq1YZe/pVbqG1anDkc68JnCWB4oiN+O3Q7xbA+e5O4GFxSqRzXwrBC5811FXxfMexS7guGFGhubZC11V2kOxxJekmsyacOiliYoRtEQSPFvC/XA0Xb7Qy2vYJlKV/BgkRn6DpmykBI0yxbhHPK2hLTm8pG5WDX+T/Qk7d99oqfvhDHIbmb+j4NRkWI0Q4/sjR+kfASnBiyoQ2AXfjP6EIkw9v1ERZry89vBywMUkhkCvJk2tvoYmakGbrUjQOynHvgPKctRtimThaQFFkzxg3MekSGA== X-YMail-OSG: .eqHbvIVM1m4HK7nprIsgjYrFpnC4_Sn85v1bAj_SzhLTC3lgxoJLFJ2Q9Ma5uI oQP0uvv0YJcIPgSZllAhtZ5q63tLlYXlSbx6L.DuwzL0kMGe6Eb0mY_DIX9bA1aHsR3DunAwvivs 05x6nAKz9TxzJIuAng6mxv4D0jGztgKlfibgaRvSTWNIMc298NJNxUF8CplHgI3OL51xfrnJ.lKt gfaK74RSRQE.x2Z6albWACz2tEwaKbSsaDxalJUaeDb79ZBjYhZVa_esw2PltRAjyoj4ZBo6fZaP vmiH9Joskzi0dgRRnJC84dUd6xIdGQ0U2.MDaiqUBdqBCpcONk2rcaX13JOjpyltFBfEAhXW1rCF 71uim54OkppFBatILcJS.ioC5gQTN5cn7EsNEdEicPD8K9Q1694z0ZBnosdmK_FO6ScWm7nsZpEB 78Zqr8ftKGcfHg2inKsVpE4rQAfdgtAY_JhlwVsDzH8fn.WrGywzGHYVQKdo4kbzFkUEWCLTSwsz I6.ywlrnASBIajY3YBd.YjnRbYCsRyu11AcmsIeTiOOpBm0TB2x.PIEBkhD4gH.e1ByBqFqI1mah ZvfclXH7nZQalORtmA8lZn_h03fqwBn5pklt_jolALCYMMG8lCMANCVgtJUD7xSzHfnxWOfZIDi2 CuRNFfcBm9ngFJgkeIeHE__7phKfLgH4inCJ56Y61n0l4xlARGSdtvA2xLLYTI.nJ09nyGMaU3k7 mhB5XEChPmSD2ekgB7Q6R7SFYQFAU5xxKsWjtUsAW_U8gF_aPQDODDnZOxC4gBTtA.iUWdrCN7oL oRjfHNFNaVNg5c14LHO1y.My2hibPYTrSsOCpXPEowR13JLSl7s5S.0KifDau5tMZXie1sNJoD1R P6_.B0Eli_.LIiELv0LFlkbOBTR_djlzuAw7N7XeB89koKr9Z0htg6ibeHTlHSVN691wJrpe7i_T PDpuJQ7g1MaXRsZjFRThBvX03yJXl0IKDDqGzGqS7YYd5QpMfzuL7EGS8x8Gz9CFlv3dzcb6TStG RNVY0B_THb8goVL8DnATervOefFnPfq1xljuE2yoO3YdVAIVV2XvA.1s1VoMab28P7JSwNciN3sj JLQr6txOl9oTsz5TFoxkwUfqvvsbl2hMGYhJR.g4UFPvoE0Q0Ctwb.v6Dqz6p7kATXlxq0d5DcjB vSTn5s5mh5_771H_Pvx8J2VQH1HVdb4Yepf_Ik80hB5IwlZo7p5kgwG5M3pSFqPAck29EQ5rKHHQ d85.uiVl._vKW577u.Do9gcbS3vae1UDRAYSnaOaW20NkbAGvXv7w3gIt4MCr7dZxU4dqZU.8ZMQ T1_E_I54hiBOqvJJUQ.E4aovQuWL6q7YD5swqH.ohfo.9NhP1hgcQ7eWrr1ORlDV2N7.Z2VA5e.6 sfNbwOL0cKQ80o1hABTNkMNOSRQu5hbYFtRpY6u1CBsfe_A7ZbDAzIKmPUHNw2Lmzvcnus0fo_ln HVK_AsH9y41kw9imxalu_vgMacTlxNcyb6x7Efxrvz1eAgZg32rxAln_Am8wlAKfF7aHW5JRPKTg oJ6yQ36.LB8MGBmYtgKeye.mWuG5.ebKjgmA0QdNCsYbuIWdbVE4wY32Z8QS84Bef0Zq3Il4U5Lv 3D.IVkB7JdZNcVPyi7abcYk3vsip_Joyh7T7cgC3YX.v_h1RHMQG2zZaB0Ql9rp.ttzxWoIlkLsV 3vCglR.rab8ijlR9dpqG1hH6qzM4xNvA2Iadp4fk0JOLR5W88U7.MgAlwDG7gKIiwEpw7FtuSRtD ipBXAx2z6F1qJBrg8h96k3dbHpKF.G4zE0IhALOHgT6jZwMufC4T1.uHuFKcnaiUtnYoKsDWbZBf 7i_iQugYDArttQX1.Vl2cO7CYZtXcVzU0gz3XUh3sn96U2otGkYRve.a4s9b.4pza1OdgGSLbhSY gCFO0wF3sQKvSbTYTBmCdMPpOxtsDFF9DbJDLVHpOZEOTmTT70UqRLd0NV6rHhNYTLMyIWccvwMp V5ZRsl9hWvhN3TFSC2ChGJZ6al2y3u4Cf4Fk7g.qodtuKxSWzwwd.yhs.fiZ3q3e9aGQWZ2j9ZNp Jl5jaisrptmOsGaEqfkntHgucb0wuVy2owuvPiSnp0BBrgWO9GPXhXZjBQhkMtWidwYI_O_3FA7t aSst_taZd6Ba9aODjwBwlFidptVuXmhA.6KuPBv92bQoGDVmdyuOZT6KUX5yIE5Gu73SCUJKNLFr xzCtuk77.DZY7iJZlhE8kACp96oRyemIugZx33YftVmRUerSa0n7co9wXOPgiHzYzlOfBOSbmroc - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Wed, 15 Feb 2023 19:39:26 +0000 Received: by hermes--production-gq1-655ddccc9-j6kw5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e43f6812d050da1e2a089eab771621a2; Wed, 15 Feb 2023 19:39:24 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash) From: Mark Millard In-Reply-To: <20230215190856.GA34665@www.zefox.net> Date: Wed, 15 Feb 2023 11:39:13 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20230212195324.GB21535@www.zefox.net> <03840D0B-13D4-4F22-BDAF-2887A4D78BED@yahoo.com> <20230213232519.GD95670@funkthat.com> <20230214161415.GA28276@www.zefox.net> <20230214183827.GG95670@funkthat.com> <20230214210601.GA28959@www.zefox.net> <20230214232746.GI95670@funkthat.com> <20230215154424.GA34278@www.zefox.net> <20230215190856.GA34665@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4PH7gh2q6tz4Jlx X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 15, 2023, at 11:08, bob prohaska wrote: > On Wed, Feb 15, 2023 at 09:40:51AM -0800, Mark Millard wrote: >>=20 >> Looking in my /usr/main-src/sbin/fsck_ffs/inode.c >> I see that the original file has a leading tab >> instead of spaces. >>=20 >> The following mostly ignores the 1st column that >> should have a space, -, or + in the diff output for >> the file-content lines. It is mostly about the text >> after the first column. >>=20 >> So, if you have spaces instead after the first column >> for the lines that start with a space, those lines >> will not match, leading to a rejection for the >> context matching done by patch. >=20 > Replacing spaces with tabs allowed patch to find the=20 > location, but it still fails with=20 > patch: **** malformed patch at line 5: printf("SIZE=3D%ju ", = (uintmax_t)DIP(dp, di_size)); My guess is that when you made the adjustment to have the tabs, the leading space was also removed on this line. The first column is not part of the original text but is instead a directive to the tool. The missing space would be that directive and it needs to be there. So: printf("SIZE=3D%ju ", (uintmax_t)DIP(dp, di_size)); The space indicates to use the reset of the line just for context identification. Of course, since I've no access the file to check my hypothesis, it is just a guess. > Editing by hand looks like a good way to drive myself crazy 8-) >=20 > I take it the goal is to find the lines > printf("SIZE=3D%ju ", (uintmax_t)DIP(dp, di_size)); > t =3D DIP(dp, di_mtime); > p =3D ctime(&t); > delete the line=20 > printf("MTIME=3D%12.12s %4.4s ", &p[4], &p[20]); Yes. (I ignored whitespace details here: not preserved in the E-mail result as I see it.) > and add the four lines > if (p =3D=3D NULL) > printf("MTIME=3Dinvalid "); > else > printf("MTIME=3D%12.12s %4.4s ", &p[4], &p[20]); =20 Yes. (I ignored whitespace details here too.) > Do I at least correctly understand the intent of the patch? >=20 Yes. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Thu Feb 16 11:32:13 2023 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 4PHXq12V82z3q3rf for ; Thu, 16 Feb 2023 11:32:13 +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 4PHXq11MZtz45hC for ; Thu, 16 Feb 2023 11:32:13 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1676547133; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QOWjVTWXIxMwZKLed88S/rqT3N/u3PBoNGIctlDYtRE=; b=FhyhAKb3Cqefs8PB64r1X1Yw4rWMbR4anASnMOOmG+ZBgsS9cf1VEngsZBM/ag2YYNZsEZ SH057qoQrH4BdqdCQA9jwMC5P3cMk+ecT8ey5hjFWJ9yMCIZPZgbroySl36zFoQJOGSQAu HYllu+pLbWI9mOGhCx9jWDYi67pvlATFQJq0HEZ91eeino/hYxiZTInPQs+YhprrF6gq3/ Z5BjCdATqHV9oJwOuRoEIPLeh93aPZzmw4jfnVJeZ79c2xu+HeHSRfbCMj7JqgrRGZt9GU FFqylxyuk/N/LF+zrLhAJcxqrxvl7qT3wGVGCVbdXK7iCA+/W0eSLiTjt44uuA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1676547133; a=rsa-sha256; cv=none; b=hrqzJRlG+lNd9qLz3HuUdB7wdWABvg20pImU9y5xKlMuo5XyceEuVFKM/3jhBeaLlPmuEt 54tFu0rwPmoa/aNtwc791hLfvv9qs64NynWeGeAdwmcsZD9+UX1objQOa0yNnqK0Mx4oyl rTuZAI8pFCqa1+yMu5Mt0S2czAIkgkXez101gV/H6Ml0WeoLSc4aFTzjLEwUI4Tk+dhC1g gIdKT9D2EQ+wUy5Qp7w2/1Kudt9ykEm9ZyLzXRiWovU/eEo1JR0iTGcwkp22ZrBfgIStJD YdaW/4pW/tKY28OL2YxdhXTQJbX/Gzp+nRa7saidXlUw5TRqG0O1ZX5CLT1iZg== 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 4PHXq10RSWz12Tf for ; Thu, 16 Feb 2023 11:32:13 +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 31GBWD4R051607 for ; Thu, 16 Feb 2023 11:32:13 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 31GBWDBp051606 for freebsd-arm@FreeBSD.org; Thu, 16 Feb 2023 11:32:13 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: freebsd-arm@FreeBSD.org Subject: [Bug 267361] EINVAL accessing fpcsr for armv7 process on arm64 kernel Date: Thu, 16 Feb 2023 11:32:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 13.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: fuz@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status 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: 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 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D267361 Robert Clausecker changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|In Progress |Closed --- Comment #12 from Robert Clausecker --- I guess we are done here. --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Feb 16 19:35:45 2023 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 4PHlYH4dgmz3rQ71 for ; Thu, 16 Feb 2023 19:36:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (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 4PHlYF6GGtz3qQx for ; Thu, 16 Feb 2023 19:36:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=cBaJmcGm; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676576159; bh=4bF34YbLhuPC4JjnoP4zCxWAxpxE/nbflcKabf9itgo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=cBaJmcGmkPJyeE1p1Apl/Y2GvKgncYeGxLX9fouI7y+gaiezyijX00soNAT1st6KbEe5cvcW5Exdfx9ybBh68mS255ucbxw11AeBs1bmWj6dOuH6Iuop3p6k+yKjl5UGJCIE2TdxjCn2GsKgeN/5r+5gIWRvkwp6ERSryotxDvef8rSFjHbKwBl+ruwhuYIx54rwAlB2ECvhvUKfpfZ/QLqnYQ328JldWJZAljWGxIZNxoRNDuejSDdUHrDw9ySjcX8/x/yAHB8lnKj69/svjiN9MqtN3/ePPzSPnahCn3nf0F0nJxenf4i4HZC5xvUBzYbELxd5Tk3fQl/eqm6TZw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676576159; bh=UkY28YIEjRgoz32wJJVzdPmv1eOISDjCcRlOLs164BF=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=i/F/0I8JbTteeO1cb/tERGsqITNYsywUilOvo5RTSE2X4KOC4YUl/uFs/Qxm3gHYzZbIgFC662Gyx9Kp0v5qCP8L+9F5ajfFTbmwKDLVz1yo3tzvXHc6dlPTpF5jNKauAznEJGWNISeKTRLMACcSkM6YaMrXJmgC9hrQkqmGK0N1GEc3Ya7JHOOAUEJhr3ewRXwX/E9IlIYxCL8ChD1MaHOGAiCaYGM+dZ39QWFwxubengHJa7YCUh7YcosFe8+2LiX/yqFvo69v2KXreit0yd9ZQEUBeRuxR8JJ5JRWXR5Jx22PPeAjBY98FFdP3QXm8swT+REillC891LDwzFptw== X-YMail-OSG: s7gfGlgVM1muLdnv0lMtKJ73sqj9KWtf5FVydBvPpZgN7mOZFdAVxK5Gg2LV6jD RiXzEC4kVXLHjFZdicTAHmcYbNeL5O10sErSF4FaLZPgqCbYu_dSx7cRD__8OFV0b5C5rNRk6oFh kLVWJa50QF3IMJYnFs463ppyhVp297.Ty9BusIwAchxV.TQZI3W4QMV_LYicEWrglRcgcnTTOfLQ K3qYP38BaxcliEjIB7IkdQIxj339SRMfPQ9rtIPORH9obBus62qEaQKf4JvOo9Kx.i2x2fvWIRKY 70ERxaDYkPp0E7_pWRE_hnC3xrIDtggClgqF6krI9vQ6OscvjwCng.hdFKb9eJVXYlBR6fe9nas4 wjVK6C6GlNDIKJK3HXhH4wOctzEB2TcYfz3N9sXbZ8cntGVPNzZ58TKgRp1I5qV6vH8MaIVpKCCB cH7I99uuz553crWQegZwOOZ_rXjfFSLRyX73EJJHPLHKzsYWagS8SWD1mxvDpJiAYEzsMKT_1VV_ 7JOSqzCOzaFyNwJjEntRWq0qikS7CIoiucoSp.SlSskslgW7JTGuvPHRWnVwitpZFyZbyFLapmW9 _Oms8bdzAhijLQwZkv.tXBunwOHGIbGB8eCjEKKqNXO2cKhdGculAmHtixhWF.dEh.dnV3rb2ZWO A1WvDbXenwCfGBtTCNESoc.C54bddJRn.TC8oOcuAi_8zbTx_mUlQq_b96iO.7laLThdDsHZQsaW K3V7csEmplHNizItLmDr7RNxuQ.tDXBJzEaF6bjOALZbr1YHhujpGLwdLsj2GzGg9qZoS.O8O6OX kT2cM7j42o7nhns2xGKnyayNzEWkwzHuKwysMQ4UwX9_qgjM.QJQ5pYHBo0UxfajhxL4H.IOE7vt Gh1zdLQdGKBjkBlHxNAwPjDyhBQu6Odv5eMMRiVMONiZ96Mq6Y2YaYPvxQlQs8jALJXGvJt2YaDD SJk2hKHvmNTWHPmglSQX8V147RBDDMh1Y5w4wWKpTYqoK3oB3CXw_jzGyzbZ5rfYDOszSS_hNEzh UsBmsR8Dna683L8_e4D2B0ccJ6wRGvCl1snmdidn7TiLkcwu.WoUp5IXsWN_2iSWa50vl6itH7X8 .Ox2UoNTSnki5xrX5UMEvSzL87Dsa3.EMZPZpiYVKGrsY6wzRM2vxzN0kMvnZ3W72X0RwaWnmiid O8lEHrLFubB4FnzVfv0BRvaknD5RMQM1h5G_aLI1p4eRrKPCzHJTJT3Y4iMR0PAI_8mpKA0ktMOv yyVCvkZW_E2KNvdnlQigsP7C9dSqzClwiZ57xSjAw8rmRbL90Bd2bu4GEGLMOlaTR_CMk5W.WPkb vaBfMOH5hjeasYgmxYpBpvurXK1VIs2q3Hbu0ufzywkkLFjBHNRtFNZ1D.ry.LOWDbWnbOnB1sBM uZfRzw4ywfx6fEZO8pbn05iLCpB1_GDF6E6bMxSQ_NaOe0V.oIh4kY5rv9mUImvf2Xd9ArMflJXN POo94e7BhGTZ_9TwD7pnOi9fjN4_MK4ufOUycnoc64SSN.z1YfUx.BtE4751T_bkZ_M9PAwoykcg AFir1wmVc0w1kytonkjEeuTm4Ss5TYxBL.9w7Vf5HtXqd8kG3dlrf4b4gM3f.BHXfCdrqBrXRDZ2 QZ82zOMedJk2BBWO7baJhZKjP5.CuKi.1Ne_OdE7BVpnPzscM.eQa7nGeo2BaprSDD7i9uA9nxq6 dnzGk3wjw130MIXZ.UC.jrIluqtEtfq_CNFp6AFisy_NhDTJuKq9C7Uh73u5Gf1euq90roAJYGq1 6UskbBBRTHCqOlyaIOQmTolvlJ9TgkJRP3qQ2HpIaXZ1fhkc6CrF.vt2eV0uOltndVjloysy09JZ YA1J33_0eXCb5SvTyvN.oqGYeI1YH4ZcIfekAcoDpVANcA94ls5PUWSxgYV7W_RSppZ5nCELkTB6 DGenhM.CmJoXafxVXcfeGFnmxiOKRW03tkXgaczsWz3zkAweF4ZOquPCxdEz7ABUx5Y63u01IdCV jBOry0.wBN0wCxoSY5b_zjYU8K4HsWciT6tp.IoWaPvAOTFl_5zeXLxWYzLQtAovYN2yvpqn2nPw 9zqHtP9D6RaRqOhsojY1tHkGWQbUOLKukH04Boie6wjUQ7CjGoZi3NkZD05lZGYo0jVJ0_Ws5uJ_ .1Z9smwF4IGXiOMUHZLIbn4ZaWhtkBCLaerejD89M9oFLPGOIT.1hmnHZhqNQPmlyAYUOJjUNjdD p9IrrJl82fW0ImhItf0ykwaqWeDJ4Ca9LoZIqzury4VTqM4z9LL8JEyJhSbBx_PLMBswsIgMEKOl J X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Thu, 16 Feb 2023 19:35:59 +0000 Received: by hermes--production-ne1-746bc6c6c4-fgv82 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 5f8f2c94dda217484ad54b40297c502c; Thu, 16 Feb 2023 19:35:56 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: Armv7 panic on -current, rpi2 buildworld From: Mark Millard In-Reply-To: Date: Thu, 16 Feb 2023 11:35:45 -0800 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20230215025741.GA32086@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Spamd-Result: default: False [-3.47 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.97)[-0.971]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_DN_EQ_ADDR_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_THREE(0.00)[3]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[yahoo.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org] X-Rspamd-Queue-Id: 4PHlYF6GGtz3qQx X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Feb 14, 2023, at 23:16, Mark Millard wrote: > On Feb 14, 2023, at 20:16, Warner Losh wrote: >=20 >> Sorry to top post... what program was dumping core? Looks like a too = strict assert >=20 > Just a possible point, given recent kernel floating > point work: >=20 > Because of Bob's note, I tried to do a typical build > and test of some benchmark programs that I sometimes > use that involve floating point in some of the > programs, some use with multithreading involved. (As > FreeBSD and g++ progress I tend to do this once and > a while, not as often on armv7 as on aarch64.) >=20 > On armv7, I now get a message about a failure of an > internal cross-check, which also leads to the program > being stopped early. The messaging from run to run > varies what the failure is, but the runs should not > vary and should not fail the cross-checks --and > previously did not, including when I last tried armv7. > (Not recently.) >=20 > For the specific example failure, the initial serial > (single thread) test with float involved works but the > following multi-thread test in the same program fails > and causes the program to stop when it notices there > is a problem. >=20 > The programs that do not test floating point do not > fail. These can involve floating point outside the > algorithm benchmarked, but with no multi-threading > involved for such and no floating point based cross- > checks involved. >=20 > At this point it is far from obvious to me how I > would trackdown the specifics of what leads to the > failed cross-checks. But the above is suggestive of > there being problems for armv7 handling of saving > and restoring floating point context for > multi-threading. I've no clue if such are limited > to the floating point values or not. >=20 >> Warner >>=20 >> On Tue, Feb 14, 2023, 7:57 PM bob prohaska = wrote: >> Building world on an RPi2 armv7, buildworld stopped with >> bob@www:/usr/src % panic: Called fill_fpregs while the kernel is = using the VFP >> cpuid =3D 0 >> time =3D 1676427410 >> KDB: stack backtrace: >> db_trace_self() at db_trace_self >> pc =3D 0xc05e8160 lr =3D 0xc007aa04 = (db_trace_self_wrapper+0x30) >> sp =3D 0xde2c5790 fp =3D 0xde2c58a8 >> db_trace_self_wrapper() at db_trace_self_wrapper+0x30 >> pc =3D 0xc007aa04 lr =3D 0xc02e9c54 (vpanic+0x140) >> sp =3D 0xde2c58b0 fp =3D 0xde2c58d0 >> r4 =3D 0x00000100 r5 =3D 0x00000000 >> r6 =3D 0xc07372ef r7 =3D 0xc0b13968 >> vpanic() at vpanic+0x140 >> pc =3D 0xc02e9c54 lr =3D 0xc02e9a34 (dump_savectx) >> sp =3D 0xde2c58d8 fp =3D 0xde2c58dc >> r4 =3D 0xd70c8600 r5 =3D 0xde2c5e90 >> r6 =3D 0xc3398090 r7 =3D 0xe0cfc440 >> r8 =3D 0xc3398080 r9 =3D 0xd70c8600 >> r10 =3D 0xde2c5960 >> dump_savectx() at dump_savectx >> pc =3D 0xc02e9a34 lr =3D 0xc05f51dc (set_regs) >> sp =3D 0xde2c58e4 fp =3D 0xde2c58f8 >> set_regs() at set_regs >> pc =3D 0xc05f51dc lr =3D 0xc026f8f0 = (elf32_get_fpregset+0x2c) >> sp =3D 0xde2c5900 fp =3D 0xde2c5908 >> r4 =3D 0xc3398090 r5 =3D 0xc026f8c4 >> elf32_get_fpregset() at elf32_get_fpregset+0x2c >> pc =3D 0xc026f8f0 lr =3D 0xc026d848 (elf32_coredump+0x308) >> sp =3D 0xde2c5910 fp =3D 0xde2c5988 >> r4 =3D 0xc0902a7c r10 =3D 0xde2c5960 >> elf32_coredump() at elf32_coredump+0x308 >> pc =3D 0xc026d848 lr =3D 0xc02eea74 (sigexit+0xce0) >> sp =3D 0xde2c5990 fp =3D 0xde2c5cf8 >> r4 =3D 0x0000004e r5 =3D 0xdf580b60 >> r6 =3D 0xdf580a78 r7 =3D 0xc026d540 >> r8 =3D 0xdddcb2bc r9 =3D 0xdf580ad4 >> r10 =3D 0x00000000 >> sigexit() at sigexit+0xce0 >> pc =3D 0xc02eea74 lr =3D 0xc02ef36c (postsig+0x128) >> sp =3D 0xde2c5d00 fp =3D 0xde2c5d88 >> r4 =3D 0x00000006 r5 =3D 0xdd43fba0 >> r6 =3D 0xde2c5d20 r7 =3D 0xde2c5d18 >> r8 =3D 0xdddcb1f8 r9 =3D 0xdf3d9ab8 >> r10 =3D 0x00000005 >> postsig() at postsig+0x128 >> pc =3D 0xc02ef36c lr =3D 0xc02f316c (ast_sig+0x11c) >> sp =3D 0xde2c5d90 fp =3D 0xde2c5e08 >> r4 =3D 0xdd43fba0 r5 =3D 0xdddcb2bc >> r6 =3D 0xc0734d22 r7 =3D 0x00000000 >> r8 =3D 0xdddcb1f8 r9 =3D 0x00000ab8 >> r10 =3D 0x22530384 >> ast_sig() at ast_sig+0x11c >> pc =3D 0xc02f316c lr =3D 0xc035444c (ast_handler+0xe0) >> sp =3D 0xde2c5e10 fp =3D 0xde2c5e28 >> r4 =3D 0xde2c5e40 r5 =3D 0x0000000e >> r6 =3D 0x00004000 r7 =3D 0xc096b59c >> r8 =3D 0xdd43fba0 r9 =3D 0x00000001 >> ast_handler() at ast_handler+0xe0 >> pc =3D 0xc035444c lr =3D 0xc035435c (ast+0x20) >> sp =3D 0xde2c5e30 fp =3D 0xde2c5e38 >> r4 =3D 0xde2c5e40 r5 =3D 0xdd43fba0 >> r6 =3D 0x00000000 r7 =3D 0x000001b1 >> r8 =3D 0x22c4b500 r9 =3D 0x00000000 >> ast() at ast+0x20 >> pc =3D 0xc035435c lr =3D 0xc05eaa88 (swi_exit+0x3c) >> sp =3D 0xde2c5e40 fp =3D 0xbb9fbe38 >> r4 =3D 0x60000013 r5 =3D 0xdd43fba0 >> swi_exit() at swi_exit+0x3c >> pc =3D 0xc05eaa88 lr =3D 0xc05eaa88 (swi_exit+0x3c) >> sp =3D 0xde2c5e40 fp =3D 0xbb9fbe38 >> KDB: enter: panic >> [ thread pid 81621 tid 101111 ] >> Stopped at kdb_enter+0x54: ldrb r15, [r15, r15, ror r15]! >> db> bt >> Tracing pid 81621 tid 101111 td 0xdd43fba0 >> db_trace_self() at db_trace_self >> pc =3D 0xc05e8160 lr =3D 0xc00774a0 (db_stack_trace+0x140) >> sp =3D 0xde2c55d8 fp =3D 0xde2c55f0 >> db_stack_trace() at db_stack_trace+0x140 >> pc =3D 0xc00774a0 lr =3D 0xc00770f0 (db_command+0x310) >> sp =3D 0xde2c55f8 fp =3D 0xde2c56a0 >> r4 =3D 0xc0745722 r5 =3D 0x00000062 >> r6 =3D 0x00000000 r10 =3D 0x00000000 >> db_command() at db_command+0x310 >> pc =3D 0xc00770f0 lr =3D 0xc0076db8 (db_command_loop+0x64) >> sp =3D 0xde2c56a8 fp =3D 0xde2c56b8 >> r4 =3D 0xc07ac186 r5 =3D 0xc07ab7fe >> r6 =3D 0xc0986f5c r7 =3D 0xc0b13968 >> r8 =3D 0xc0b23738 r9 =3D 0x00000000 >> r10 =3D 0x00000001 >> db_command_loop() at db_command_loop+0x64 >> pc =3D 0xc0076db8 lr =3D 0xc007ab88 (db_trap+0x128) >> sp =3D 0xde2c56c0 fp =3D 0xde2c57d8 >> r4 =3D 0x00000000 r5 =3D 0xc0986f50 >> r6 =3D 0xc0b23758 r10 =3D 0x00000001 >> db_trap() at db_trap+0x128 >> pc =3D 0xc007ab88 lr =3D 0xc033bb84 (kdb_trap+0x258) >> sp =3D 0xde2c57e0 fp =3D 0xde2c5808 >> r4 =3D 0xc078390c r5 =3D 0xc08d5270 >> r6 =3D 0xc0b23758 r7 =3D 0xc0b13968 >> kdb_trap() at kdb_trap+0x258 >> pc =3D 0xc033bb84 lr =3D 0xc05eaab8 (exception_exit) >> sp =3D 0xde2c5810 fp =3D 0xde2c58a8 >> r4 =3D 0x200000d3 r5 =3D 0x00000000 >> r6 =3D 0xc07372ef r7 =3D 0xc0b13968 >> r8 =3D 0xc093fa0c r9 =3D 0xde2c58e4 >> r10 =3D 0xc0b13a68 >> exception_exit() at exception_exit >> pc =3D 0xc05eaab8 lr =3D 0xc033b044 (kdb_enter+0x50) >> sp =3D 0xde2c58a0 fp =3D 0xde2c58a8 >> r0 =3D 0x00000000 r1 =3D 0x00000001 >> r2 =3D 0x00000012 r3 =3D 0x00000000 >> r4 =3D 0xc0b23748 r5 =3D 0x00000000 >> r6 =3D 0xc07372ef r7 =3D 0xc0b13968 >> r8 =3D 0xc093fa0c r9 =3D 0xde2c58e4 >> r10 =3D 0xc0b13a68 r12 =3D 0x00000000 >> kdb_enter() at kdb_enter+0x58 >> pc =3D 0xc033b04c lr =3D 0xc02e9ca0 (vpanic+0x18c) >> sp =3D 0xde2c58b0 fp =3D 0xde2c58d0 >> r4 =3D 0x00000100 r10 =3D 0xc0b13a68 >> vpanic() at vpanic+0x18c >> pc =3D 0xc02e9ca0 lr =3D 0xc02e9a34 (dump_savectx) >> sp =3D 0xde2c58d8 fp =3D 0xde2c58dc >> r4 =3D 0xd70c8600 r5 =3D 0xde2c5e90 >> r6 =3D 0xc3398090 r7 =3D 0xe0cfc440 >> r8 =3D 0xc3398080 r9 =3D 0xd70c8600 >> r10 =3D 0xde2c5960 >> dump_savectx() at dump_savectx >> pc =3D 0xc02e9a34 lr =3D 0xc05f51dc (set_regs) >> sp =3D 0xde2c58e4 fp =3D 0xde2c58f8 >> set_regs() at set_regs >> pc =3D 0xc05f51dc lr =3D 0xc026f8f0 = (elf32_get_fpregset+0x2c) >> sp =3D 0xde2c5900 fp =3D 0xde2c5908 >> r4 =3D 0xc3398090 r5 =3D 0xc026f8c4 >> elf32_get_fpregset() at elf32_get_fpregset+0x2c >> pc =3D 0xc026f8f0 lr =3D 0xc026d848 (elf32_coredump+0x308) >> sp =3D 0xde2c5910 fp =3D 0xde2c5988 >> r4 =3D 0xc0902a7c r10 =3D 0xde2c5960 >> elf32_coredump() at elf32_coredump+0x308 >> pc =3D 0xc026d848 lr =3D 0xc02eea74 (sigexit+0xce0) >> sp =3D 0xde2c5990 fp =3D 0xde2c5cf8 >> r4 =3D 0x0000004e r5 =3D 0xdf580b60 >> r6 =3D 0xdf580a78 r7 =3D 0xc026d540 >> r8 =3D 0xdddcb2bc r9 =3D 0xdf580ad4 >> r10 =3D 0x00000000 >> sigexit() at sigexit+0xce0 >> pc =3D 0xc02eea74 lr =3D 0xc02ef36c (postsig+0x128) >> sp =3D 0xde2c5d00 fp =3D 0xde2c5d88 >> r4 =3D 0x00000006 r5 =3D 0xdd43fba0 >> r6 =3D 0xde2c5d20 r7 =3D 0xde2c5d18 >> r8 =3D 0xdddcb1f8 r9 =3D 0xdf3d9ab8 >> r10 =3D 0x00000005 >> postsig() at postsig+0x128 >> pc =3D 0xc02ef36c lr =3D 0xc02f316c (ast_sig+0x11c) >> sp =3D 0xde2c5d90 fp =3D 0xde2c5e08 >> r4 =3D 0xdd43fba0 r5 =3D 0xdddcb2bc >> r6 =3D 0xc0734d22 r7 =3D 0x00000000 >> r8 =3D 0xdddcb1f8 r9 =3D 0x00000ab8 >> r10 =3D 0x22530384 >> ast_sig() at ast_sig+0x11c >> pc =3D 0xc02f316c lr =3D 0xc035444c (ast_handler+0xe0) >> sp =3D 0xde2c5e10 fp =3D 0xde2c5e28 >> r4 =3D 0xde2c5e40 r5 =3D 0x0000000e >> r6 =3D 0x00004000 r7 =3D 0xc096b59c >> r8 =3D 0xdd43fba0 r9 =3D 0x00000001 >> ast_handler() at ast_handler+0xe0 >> pc =3D 0xc035444c lr =3D 0xc035435c (ast+0x20) >> sp =3D 0xde2c5e30 fp =3D 0xde2c5e38 >> r4 =3D 0xde2c5e40 r5 =3D 0xdd43fba0 >> r6 =3D 0x00000000 r7 =3D 0x000001b1 >> r8 =3D 0x22c4b500 r9 =3D 0x00000000 >> ast() at ast+0x20 >> pc =3D 0xc035435c lr =3D 0xc05eaa88 (swi_exit+0x3c) >> sp =3D 0xde2c5e40 fp =3D 0xbb9fbe38 >> r4 =3D 0x60000013 r5 =3D 0xdd43fba0 >> swi_exit() at swi_exit+0x3c >> pc =3D 0xc05eaa88 lr =3D 0xc05eaa88 (swi_exit+0x3c) >> sp =3D 0xde2c5e40 fp =3D 0xbb9fbe38 >> db>=20 >>=20 >> The machine was last updated about a week ago, the >> sources were updated earlier today. This panic is >> new to me. >=20 I now have a small C++ program that, when aborted by SIGABRT on armv7 (say via control-\), gets the above type of FreeBSD crash while trying to produce the *.core file (debug style armv7 kernel in use). I've sent the authors of the recent VFP-use-in-armv7-kernel changes the details, also: Warner L. . I previously sent them a small C program that gets a KASSERT based panic for a debug armv7 kernel when run under gdb or lldb with a breakpoint at a specific routine. In general, looks like armv7 floating point use is now problematical on main's [so: 14's] armv7 kernel until more work is done. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Fri Feb 17 23:25:37 2023 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 4PJSbL6bp6z3rwPB for ; Fri, 17 Feb 2023 23:25:18 +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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PJSbK5tDrz3Dr2 for ; Fri, 17 Feb 2023 23:25:17 +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.16.1/8.15.2) with ESMTPS id 31HNPbZ5046237 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 17 Feb 2023 15:25:38 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 31HNPb7U046236; Fri, 17 Feb 2023 15:25:37 -0800 (PST) (envelope-from fbsd) Date: Fri, 17 Feb 2023 15:25:37 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash) Message-ID: <20230217232537.GA46176@www.zefox.net> References: <20230213232519.GD95670@funkthat.com> <20230214161415.GA28276@www.zefox.net> <20230214183827.GG95670@funkthat.com> <20230214210601.GA28959@www.zefox.net> <20230214232746.GI95670@funkthat.com> <20230215154424.GA34278@www.zefox.net> <20230215190856.GA34665@www.zefox.net> 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 In-Reply-To: X-Spamd-Result: default: False [-1.10 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; MID_RHS_WWW(0.50)[]; WWW_DOT_DOMAIN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_TO(0.00)[yahoo.com]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; DMARC_NA(0.00)[zefox.net]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4PJSbK5tDrz3Dr2 X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N On Wed, Feb 15, 2023 at 11:39:13AM -0800, Mark Millard wrote: > On Feb 15, 2023, at 11:08, bob prohaska wrote: > > > On Wed, Feb 15, 2023 at 09:40:51AM -0800, Mark Millard wrote: > >> > >> Looking in my /usr/main-src/sbin/fsck_ffs/inode.c > >> I see that the original file has a leading tab > >> instead of spaces. > >> > >> The following mostly ignores the 1st column that > >> should have a space, -, or + in the diff output for > >> the file-content lines. It is mostly about the text > >> after the first column. > >> > >> So, if you have spaces instead after the first column > >> for the lines that start with a space, those lines > >> will not match, leading to a rejection for the > >> context matching done by patch. > > > > Replacing spaces with tabs allowed patch to find the > > location, but it still fails with > > patch: **** malformed patch at line 5: printf("SIZE=%ju ", (uintmax_t)DIP(dp, di_size)); > > My guess is that when you made the adjustment to have > the tabs, the leading space was also removed on this > line. The first column is not part of the original > text but is instead a directive to the tool. The > missing space would be that directive and it needs to > be there. So: > > printf("SIZE=%ju ", (uintmax_t)DIP(dp, di_size)); > > The space indicates to use the reset of the line just > for context identification. > > Of course, since I've no access the file to check my > hypothesis, it is just a guess. > > > Editing by hand looks like a good way to drive myself crazy 8-) Turns out to be true, but not in the manner expected. Editing in the changes by hand seems to have worked, in that fsck_ffs recompiled and no longer segfaults when examining the -stable filesystem. However, repeated runs of fsck continue to emit errors starting with root@www:/usr/src # fsck -y /dev/da1s2d ** /dev/da1s2d ** Last Mounted on /usr ** Phase 1 - Check Blocks and Sizes 7912408300994173476 BAD I=69393345 4313599915630302063 BAD I=69393345 -4473632163892877928 BAD I=69393345 8068741989830080453 BAD I=69393345 .... This continues through a succession of I values, ending with ..... 3857159125896022134 BAD I=74682090 -4354179704011695453 BAD I=74682090 7611175298055105740 BAD I=74682090 3985638883347136889 BAD I=74682090 -2495754894521232470 BAD I=74682090 7739654885841380823 BAD I=74682090 ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts LINK COUNT FILE I=69316035 OWNER=root MODE=100644 SIZE=36680 MTIME=Feb 11 12:06 2023 COUNT 2 SHOULD BE 1 ADJUST? yes BAD/DUP FILE I=69393345 OWNER=root MODE=100644 SIZE=720896 MTIME=Jul 22 23:00 2022 CLEAR? yes fsck_ffs: cglookup: out of range cylinder group 175966913 root@www:/usr/src It's unclear whether the patch is preventing fsck from repairing the filesystem, or the problems are inherently beyond fixing. Repeated fsck runs seem to just reproduce the same output. There's no prompt to re-run fsck. Thanks to both Marks for the patch and essential help it making it stick. If anything else is worth trying I'm game, there's little to lose. bob prohaska From nobody Sat Feb 18 00:23:59 2023 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 4PJTvS0VY9z3s0sg for ; Sat, 18 Feb 2023 00:24:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-20.consmr.mail.gq1.yahoo.com (sonic301-20.consmr.mail.gq1.yahoo.com [98.137.64.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 4PJTvR5CySz3QJ7 for ; Sat, 18 Feb 2023 00:24:19 +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=1676679858; bh=zmDbU//TzsQJ7Ag4bdhPyTEh73o5u7uDCwYb0Ft6BJo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=WPclRCXnyi50obDr5JxsHcdv5UiB3J1P6mfL4G8jttFhdHZWBpfMkpcnlkD0I77Rxyv0JVAk0bxEFB4R/M1e1T+2rusM9TkkCxOzH5Pjyt6fCgY9qGtRREFP7kupD5ZNuUF/RnapD7rdNy+boxSYi4kB1dIRXdkazJy3vk91tPwUuPOmfaztOdpS5ebnxQHzCC2+AotdqkeOk3qRC2S2KPdflg5+v4ZDrQMUlwUlrr3+kRLdzrqEg7t2itwckWsFjUzfVjW4rsqih659+wZqBM8eqPozL3F1VLlV818EfRRFL1aL6HeuwqHU3HBfNoSq+qly1+PKowkkKHQPpYdliw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676679858; bh=DeCe80fvfExy7677do+WsXFR+IknoZh2OzrThOHAcsP=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=eJKT8CVvIoN5zn88272SWqkOXLJJYIn2Eg7aFUEIq4ZbTC1hPmCiJKvPY3k0jDvhDg5610YsThZtsYmhsuyiL7wVKuweJl2zQ19eRkzo6sQ/roSz9ec+Ag41dzVDc85vaUZP2L0Pp2BzMLsrHoCEGPLK7K565gb552iPjlNcsT9aBSdMmqS+M4Z7sNbt1Q7hyixnmtN+t4c97d85brHs06iP3qK9YIBsQm1Ri8MWy2lXeJKo2fRRgvG9v0pddI3Ik2hfqojo6vvbflkh+IfMGk0O8ljbOur5Ywb+95CsXyDBJ7Q7JmpRVPe6N8tpGIVW1VMwPN5dEwkfwVm40Mwfkw== X-YMail-OSG: nCeCpGwVM1lsOR.13BPyMtvIbeQzhk3HTIZ5H01_.8tmsFggQbNrrS7InI5m4fZ 2FfMsnBIoesxvjvpHmrO4uu.cNem4tiSpyo4tnKQ2gfal8QzYB8aP5W7k_TFfsgzXMhOfLAZ.hO1 nskS5F5nkCxHJuLBHu_2OzXJd5KOrK913cnEA3flNl.qvpmiYeHBD0GdYRwVZsGcdftZ9o1rBfYT _26cDGvfOKcmAz0HvvQPHL8ILdCfDS6_2GfRxfZsCUkGDun8LgDAlNZPHx_cXCcd4r8xlb6GqwSd a5ZO0Ip7hd_viFmXSKSaQ611WmkzK8WgJSaFuNn7R0S_PDuP4Y4YPxOTWdov.m_sbTyluHwT1ed4 BplqVJv10xLsMt1F1ApATyM8MmjsSGkf.SpvUHZeyONXCImUyQxzmLo3iS3nGkmJCDmY6rhc5YqF zPGipqqlIeHz7V9vSoNCwOoYNRjvGrKS5gAzWUzD9fyueNiJwue.F4vC2N4b4vMVq5W4.Z32b47i eULVyykEc0LEkl8cYlyTJhR31i6bRN7m1ZyPkba4bFaiibG62nr3T2e8uJjs5LfK7ycbz4dhfUKx TQCOi9R6Otj.9HS6xUlXXpdchTzbHNJ1kLML8TVcnCv7.YybeHVxv3MOz4kGtyXH_KEoqKpNB2eM Ugvy3V2jiXi7nOSfDGahy.R38Ec1dNt53S.l5wp5aIXvf2br2hNLyS7fqrVGeAMXUU7c6Vl1KkZc kUmf86_Mc1N7USM1NcMBL6_TnlLMMlguz9JKQElkvrWhCf.nEPWrr39L1FyS4er70A5U1xKisrdN i5Lz0BQZLhq1UgMbC76ZloWNVYQzLDzoHrUk6MAtEDR0GGB9gPTrx1QcDMSX_VLC1bFBuGsUgmZy 6IXu_ERyN093oKcAcOY3N3dkTv9YPv39mfgNNDdFCbvRiWqZpsk26oSCKq8CWhD5fSLNpP.PEKkJ EFCqahggIa_UPEvnG6SBKmUJjQ8K_OecCEEjDsLGAMWkyMGMkQYwMLl_IpJ75VzMN2BrRwHj7K.3 LbJuL2z.fA79i6SE9w3vIE_Xubd481FuyV6Yp94oNH2MUc3dmqD1gykt2By8ta77t3B3sSpFBMI4 xkxL.DeOUMzkm1Bi_z6VvW3C20zwxd56NRmMsqbQZ50hx_R4Q8RSTUOho2DQPfU.BPov1jl6PRrC GuDXfijzrokyzqEn9VmeW29728zH.p7syzUUScj2R0OuUHMKIylcvqp2henPvH4CO13c22FqhssM x6umwjq3N.aaFP8IPYn25lA8rbsI4SyTazSJcuCT8JyegWNRANA6JPN9onOc4n6ZvR1AKLx.Swi4 juQzQWm3OrmYcXpexIsLoBmNNa1HVginrelJZvySwncoGNt9Ce.LFDC0VPFltBHlGx.VbLhiItBi MWR5aJtRVU03L73_2mREgkgZN3oEc1ELEXNrH5cDr3tPQHM.y..YVkEIvZWgCxdKEk9oChR8XkY6 Yo08c058CUDa1pvNdP9hY1m3sqZq_T6O9Rs1saxDcmDxqba9twyBSWM_amk1Rn2oPPOcUPrJ7fFo ZzgHHKeElsF.n6SWXd.DQFtL4ZpnExIpqolViKeUArgxXHgEdRPqFySXIcT7y9BFAPXJuzMMFi8J EpyaE5dR6coYTcRV.2n9eKFF5NNihsFix5oXF_AGC.pAyxjz7Ys1VEoGAvmKnjcczRvPvWUaHn1t Cxw7VCoKSDKuZGVeb_hhVBHQeFRfWa_Ci7Mu9UFo4P1zDLJDSLjqYAJCvHp_E_Q8E_nlt02uZif3 Jau8_M0QeFK8_zAD4INwNKYejm2n2Ezu5uRgHQIcP8q2b8y4SfzSYqb_UFWirl91w.P2c3M1lZMv e0jIlH.Tf62skMCIImYNbD7ydzVugQaMmcA9F6K7dHv6pSPKneUFijyuXzyTTHI8ME4B.exL41M9 XGrFkAoAqWe5OzdllzexIwZ_K0jFHBBmE7CRVXhLZ1UVOojElDhOOmU7bP8m0y7Ep3hkeK27AhbN XosDnJKyNcPwmDaXvwLQZbEsv06mWOT5dxp1cH9rps6MW.GxLKnGjchhsoZts67qv3HPOJwOKPqu 8ECQ8utcg_r.PS1ZUnYiJU2WJG6nSm0xXMfAoVvDY52yHcuFUX_Ef1YVs1xuwRNmZpDbTXPEAhfU DqzpsVTtrk6w4kupuaKFTCJX8SGuzSTpjk_xcQvP247rLvrLxH44.yvSw6uNedqRtPhVG.P_OOIh Q9BmK6qA267E9UV3eXRBEGURNMu_z31InqJFj2fvza6o6Ga1UGcg4x5UsDMZI_XlDbZUWH5N2U6J i X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Sat, 18 Feb 2023 00:24:18 +0000 Received: by hermes--production-bf1-57c96c66f6-kqcsw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 4fbc28749280701e828452a5d5fdc951; Sat, 18 Feb 2023 00:24:12 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash) From: Mark Millard In-Reply-To: <20230217232537.GA46176@www.zefox.net> Date: Fri, 17 Feb 2023 16:23:59 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <5FFA8C73-4F9B-4633-897C-75368FA9FD4F@yahoo.com> References: <20230213232519.GD95670@funkthat.com> <20230214161415.GA28276@www.zefox.net> <20230214183827.GG95670@funkthat.com> <20230214210601.GA28959@www.zefox.net> <20230214232746.GI95670@funkthat.com> <20230215154424.GA34278@www.zefox.net> <20230215190856.GA34665@www.zefox.net> <20230217232537.GA46176@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Rspamd-Queue-Id: 4PJTvR5CySz3QJ7 X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 17, 2023, at 15:25, bob prohaska wrote: > On Wed, Feb 15, 2023 at 11:39:13AM -0800, Mark Millard wrote: >> On Feb 15, 2023, at 11:08, bob prohaska wrote: >>=20 >>> On Wed, Feb 15, 2023 at 09:40:51AM -0800, Mark Millard wrote: >>>>=20 >>>> Looking in my /usr/main-src/sbin/fsck_ffs/inode.c >>>> I see that the original file has a leading tab >>>> instead of spaces. >>>>=20 >>>> The following mostly ignores the 1st column that >>>> should have a space, -, or + in the diff output for >>>> the file-content lines. It is mostly about the text >>>> after the first column. >>>>=20 >>>> So, if you have spaces instead after the first column >>>> for the lines that start with a space, those lines >>>> will not match, leading to a rejection for the >>>> context matching done by patch. >>>=20 >>> Replacing spaces with tabs allowed patch to find the=20 >>> location, but it still fails with=20 >>> patch: **** malformed patch at line 5: printf("SIZE=3D%ju ", = (uintmax_t)DIP(dp, di_size)); >>=20 >> My guess is that when you made the adjustment to have >> the tabs, the leading space was also removed on this >> line. The first column is not part of the original >> text but is instead a directive to the tool. The >> missing space would be that directive and it needs to >> be there. So: >>=20 >> printf("SIZE=3D%ju ", (uintmax_t)DIP(dp, di_size)); >>=20 >> The space indicates to use the reset of the line just >> for context identification. >>=20 >> Of course, since I've no access the file to check my >> hypothesis, it is just a guess. >>=20 >>> Editing by hand looks like a good way to drive myself crazy 8-) >=20 > Turns out to be true, but not in the manner expected. Editing in=20 > the changes by hand seems to have worked, in that fsck_ffs recompiled > and no longer segfaults when examining the -stable filesystem. >=20 > However, repeated runs of fsck continue to emit errors starting with > root@www:/usr/src # fsck -y /dev/da1s2d > ** /dev/da1s2d > ** Last Mounted on /usr > ** Phase 1 - Check Blocks and Sizes > 7912408300994173476 BAD I=3D69393345 > 4313599915630302063 BAD I=3D69393345 > -4473632163892877928 BAD I=3D69393345 > 8068741989830080453 BAD I=3D69393345 > .... > This continues through a succession of I values,=20 > ending with =20 >=20 > ..... >=20 > 3857159125896022134 BAD I=3D74682090 > -4354179704011695453 BAD I=3D74682090 > 7611175298055105740 BAD I=3D74682090 > 3985638883347136889 BAD I=3D74682090 > -2495754894521232470 BAD I=3D74682090 > 7739654885841380823 BAD I=3D74682090 > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > LINK COUNT FILE I=3D69316035 OWNER=3Droot MODE=3D100644 > SIZE=3D36680 MTIME=3DFeb 11 12:06 2023 COUNT 2 SHOULD BE 1 > ADJUST? yes >=20 > BAD/DUP FILE I=3D69393345 OWNER=3Droot MODE=3D100644 > SIZE=3D720896 MTIME=3DJul 22 23:00 2022=20 >=20 > CLEAR? yes >=20 > fsck_ffs: cglookup: out of range cylinder group 175966913 > root@www:/usr/src Looks like that is one of the messages for problems fsck_ffs does not attempt to deal with (probably for good reasons in each case/context). The below does not show the specific conditions, just the calls with the message texts used for the various exits of the "errx(EEXIT" form: # grep -r "errx(EEXIT," /usr/main-src/sbin/fsck_ffs/ | more /usr/main-src/sbin/fsck_ffs/pass5.c: = errx(EEXIT, "BAD STATE %d FOR INODE I=3D%ju", /usr/main-src/sbin/fsck_ffs/inode.c: errx(EEXIT, "bad inode = number %ju to ginode", /usr/main-src/sbin/fsck_ffs/inode.c: errx(EEXIT, "bad inode = number %ju to nextinode", /usr/main-src/sbin/fsck_ffs/inode.c: errx(EEXIT, = "cannot allocate space for inode buffer"); /usr/main-src/sbin/fsck_ffs/inode.c: errx(EEXIT, "cannot = increase directory list"); /usr/main-src/sbin/fsck_ffs/inode.c: errx(EEXIT, = "cannot increase directory list"); /usr/main-src/sbin/fsck_ffs/inode.c: errx(EEXIT, "BAD STATE = %d TO BLKERR", inoinfo(ino)->ino_state); /usr/main-src/sbin/fsck_ffs/dir.c: errx(EEXIT, "wrong type = to dirscan %d", idesc->id_type); /usr/main-src/sbin/fsck_ffs/fsutil.c: errx(EEXIT, "inoinfo: = inumber %ju out of range", /usr/main-src/sbin/fsck_ffs/fsutil.c: errx(EEXIT, "Initial = malloc(%d) failed", sblock.fs_bsize); /usr/main-src/sbin/fsck_ffs/fsutil.c: errx(EEXIT, "%s", = failreason); /usr/main-src/sbin/fsck_ffs/fsutil.c: errx(EEXIT, "cglookup: = out of range cylinder group %d", cg); /usr/main-src/sbin/fsck_ffs/fsutil.c: errx(EEXIT, = "Cannot allocate cylinder group buffers"); /usr/main-src/sbin/fsck_ffs/fsutil.c: errx(EEXIT,"Ran = out of memory during journal recovery"); /usr/main-src/sbin/fsck_ffs/fsutil.c: errx(EEXIT, "Excessive = buffer size %ld > %d\n", size, /usr/main-src/sbin/fsck_ffs/fsutil.c: errx(EEXIT, "panic: lost = %d buffers", numbufs - cnt); /usr/main-src/sbin/fsck_ffs/fsutil.c: errx(EEXIT, "ABORTING = DUE TO READ ERRORS"); /usr/main-src/sbin/fsck_ffs/fsutil.c: errx(EEXIT, = "cannot allocate buffer pool"); /usr/main-src/sbin/fsck_ffs/fsutil.c: errx(EEXIT, "UNKNOWN = INODESC FIX MODE %d", idesc->id_fix); /usr/main-src/sbin/fsck_ffs/pass4.c: = errx(EEXIT, "BAD STATE %d FOR INODE I=3D%ju", /usr/main-src/sbin/fsck_ffs/pass1.c: errx(EEXIT, = "cannot alloc %u bytes for inoinfo", /usr/main-src/sbin/fsck_ffs/pass1.c: errx(EEXIT, = "cannot alloc %u bytes for inoinfo", /usr/main-src/sbin/fsck_ffs/setup.c: errx(EEXIT, = "cannot allocate space for snapshot " /usr/main-src/sbin/fsck_ffs/setup.c: errx(EEXIT, "cannot = allocate space for superblock"); /usr/main-src/sbin/fsck_ffs/setup.c: errx(EEXIT, "calcsb: = cannot allocate recovery buffer"); /usr/main-src/sbin/fsck_ffs/main.c: = errx(EEXIT, "cannot do level %d conversion", /usr/main-src/sbin/fsck_ffs/main.c: = errx(EEXIT, "bad mode to -m: %o", lfmode); /usr/main-src/sbin/fsck_ffs/main.c: errx(EEXIT, "-%c flag = requires a %s", flag, req); /usr/main-src/sbin/fsck_ffs/pass2.c: errx(EEXIT, = "CANNOT ALLOCATE ROOT INODE"); /usr/main-src/sbin/fsck_ffs/pass2.c: = errx(EEXIT, "CANNOT ALLOCATE ROOT INODE"); /usr/main-src/sbin/fsck_ffs/pass2.c: = errx(EEXIT, "CANNOT ALLOCATE ROOT INODE"); /usr/main-src/sbin/fsck_ffs/pass2.c: errx(EEXIT, "BAD STATE = %d FOR ROOT INODE", /usr/main-src/sbin/fsck_ffs/pass2.c: errx(EEXIT, "BAD = STATE %d FOR INODE I=3D%ju", > It's unclear whether the patch is preventing fsck > from repairing the filesystem, or the problems are > inherently beyond fixing. Looks like it is in the do-not-fix category. If no prior adjustments were made in the run, then things have stayed as they were. (These messages could be clearer about the status that they imply and what one should do in responce.) > Repeated fsck runs seem > to just reproduce the same output. So, appearently, no prior adjustments either for the re-runs. > There's no prompt=20 > to re-run fsck. =20 I expect that is true of all the above "errx(EEXIT" lines: the report is of a "did not fix" issue that blocks progress. > Thanks to both Marks for the patch and essential > help it making it stick. If anything else is > worth trying I'm game, there's little to lose. I've no clue if there is more to try. But, even if there is, there may be other issues/constraints that lead to not bothering to try? Beyond that, things with floating-point use in multi-threading contexts looks to be significantly broken in main [so: 14] for now. (This was involved in your FreeBSD crash based on the the backtrace showed.) If you try to set up another armv7 context, I suggest, for now, staying before: commit 6926e2699ae55080f860488895a2a9aa6e6d9b4d Author: Kornel Dul=C4=99ba AuthorDate: 2023-02-04 12:59:30 +0000 Commit: Kornel Dul=C4=99ba CommitDate: 2023-02-04 19:21:43 +0000 arm: Add support for using VFP in kernel This would be until a list of issues have been addressed. I've reported how to produce 3 distinct failures, 2 of which hit KASSERT panics, and the other one is for ending up with floating-point values from the wrong thread (but same process). More may be identified and fixed before things generally work again for main for armv7 FreeBSD. =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sat Feb 18 21:06:10 2023 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 4PK1Rs1BMbz3rrYQ for ; Sat, 18 Feb 2023 21:05:45 +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 "www.zefox.com", Issuer "www.zefox.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PK1Rr4d4nz3MqB for ; Sat, 18 Feb 2023 21:05:44 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.16.1/8.15.2) with ESMTPS id 31IL6Afi050136 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 18 Feb 2023 13:06:10 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.16.1/8.15.2/Submit) id 31IL6Ac7050135; Sat, 18 Feb 2023 13:06:10 -0800 (PST) (envelope-from fbsd) Date: Sat, 18 Feb 2023 13:06:10 -0800 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash) Message-ID: <20230218210610.GA50074@www.zefox.net> References: <20230214161415.GA28276@www.zefox.net> <20230214183827.GG95670@funkthat.com> <20230214210601.GA28959@www.zefox.net> <20230214232746.GI95670@funkthat.com> <20230215154424.GA34278@www.zefox.net> <20230215190856.GA34665@www.zefox.net> <20230217232537.GA46176@www.zefox.net> <5FFA8C73-4F9B-4633-897C-75368FA9FD4F@yahoo.com> 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 In-Reply-To: <5FFA8C73-4F9B-4633-897C-75368FA9FD4F@yahoo.com> X-Rspamd-Queue-Id: 4PK1Rr4d4nz3MqB X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Fri, Feb 17, 2023 at 04:23:59PM -0800, Mark Millard wrote: [huge snip] > Looks like that is one of the messages for problems > fsck_ffs does not attempt to deal with (probably for > good reasons in each case/context). Since there wasn't much to lose I tried deleting the bad inodes using fsdb clri and re-running fsck. After maybe a dozen cycles fsck reported the filesystem clean and, to a superficial inspection, intact. The disk rebooted, ran git reset --hard and is now running buildworld. Fingers and toes are now fully crossed 8-) Is it possible to continue updating the -current Pi3 using git while preserving the hand-applied changes to /sbin/fsck? Simply running git pull results in complaints about unstaged changes. IIRC, subversion didn't care. [another huge snip} > > Beyond that, things with floating-point use in > multi-threading contexts looks to be significantly > broken in main [so: 14] for now. (This was involved > in your FreeBSD crash based on the the backtrace > showed.) > > If you try to set up another armv7 context, I suggest, > for now, staying before: > > commit 6926e2699ae55080f860488895a2a9aa6e6d9b4d > Author: Kornel Dul??ba > AuthorDate: 2023-02-04 12:59:30 +0000 > Commit: Kornel Dul??ba > CommitDate: 2023-02-04 19:21:43 +0000 > > arm: Add support for using VFP in kernel > > This would be until a list of issues have been > addressed. I've reported how to produce 3 > distinct failures, 2 of which hit KASSERT > panics, and the other one is for ending up with > floating-point values from the wrong thread > (but same process). More may be identified > and fixed before things generally work again > for main for armv7 FreeBSD. The relative merits of aarch64 vs armv7 are a bit muddy from my point of view. The only real objection to aarch64 on the Pi3 is running out of memory during buildworld. On a "production" machine that happens infrequently and needn't be fast, so -j2 solves the problem. I was interested in trying to use armv7 on the Pi3, but unless it works "out of the box" it's probably more trouble than benefit. Many thanks for all your help! bob prohaska From nobody Sat Feb 18 21:53:56 2023 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 4PK2Wb0Gflz3rwNJ for ; Sat, 18 Feb 2023 21:54:03 +0000 (UTC) (envelope-from void@f-m.fm) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4PK2WZ07zBz3hYt for ; Sat, 18 Feb 2023 21:54:01 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm1 header.b=m+8fnzz5; dkim=pass header.d=messagingengine.com header.s=fm1 header.b="W yZR1cI"; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.21 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 638BA32000EB for ; Sat, 18 Feb 2023 16:53:59 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sat, 18 Feb 2023 16:53:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:date:date:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to; s=fm1; t= 1676757239; x=1676843639; bh=x3nP6r5T0bjfOtZRZjxDgohgzkQq1b51bHO owCqXqTg=; b=m+8fnzz5I4EVjiqQaQHOw/+esjEo9c0J2b0zWILBtZlN3pkceZn f58BmScfiv3b5AAQNMeGfZ3WBnbhqwXQdGESRTsGobBI7dWfq3KjVTx0mRo/ok4F QMm9KhshjmPI8clypnyaRFuxMO0/eQgcICY/gEAdowX6on/X7uGrQeysPgAjTOb9 luauHITBnoK1QTTQXjK9hyMxPxvT21y33xfGCpAeoLjxXbM7/+n+v4Oewnmy932K ygP+WqxqD+3GWV5YouDne43PjIhDJAu18ZhDfbAp6wQh0T/LI6qCokP/SwaxQg7q 5F9uGKpSdo7E9yZib8mKPLHCiJmt2NgSRtw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:message-id:mime-version :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1676757239; x= 1676843639; bh=x3nP6r5T0bjfOtZRZjxDgohgzkQq1b51bHOowCqXqTg=; b=W yZR1cIwi4SnpshwqdkGrjWDT1rHMVAIILlhvOKgMdcL9bc+5lmY9prkQmqf4pOHU cCtmZLy7gNSpYAzqT6DO68UEbiOEPQB4ljMsIrbCN5FvoQT0mxupil+kwfe5UNi/ KU3oAM58xI80cqV/M0m8uTfObY2s1THHD8dn9ZmDqHvx+4XyV2dzwOinH56HrEX2 2TZ3Rs5GYFYTUBwfNrIi2xa5+F0tKJMHE1t0N/RuE9QE/YmSPkmWQPOs27QU8SZK ajWWQXAH77t9DJmh2gYMXRo8rKVwzqian+9TWsw+nfTzIRR5G1IBd8EdTkU7p5vf kTEOhoX4zPjeF8bPsiZNw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudejuddgudehudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfggtggusehttdertd dttddvnecuhfhrohhmpehvohhiugcuoehvohhiugesfhdqmhdrfhhmqeenucggtffrrght thgvrhhnpeekfedugffgieeuieffhefgvdffjeduvdfhvdeifeelvdejtdfhvdehjefhgf elueenucffohhmrghinhepfhhrvggvsghsugdrohhrghenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehvohhiugesfhdqmhdrfhhm X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sat, 18 Feb 2023 16:53:58 -0500 (EST) Date: Sat, 18 Feb 2023 21:53:56 +0000 From: void To: freebsd-arm@freebsd.org Subject: freebsd-update confusion Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org 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; format=flowed Content-Disposition: inline X-Spamd-Result: default: False [-4.60 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; MID_RHS_NOT_FQDN(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.21]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm1,messagingengine.com:s=fm1]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.21:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[f-m.fm]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4PK2WZ07zBz3hYt X-Spamd-Bar: ---- X-ThisMailContainsUnwantedMimeParts: N In https://lists.freebsd.org/archives/freebsd-security/2023-February/000146.html there's an SA for openssl. If I upgrade (buildworld etc) on an amd box, it gets: % openssl version OpenSSL 1.1.1t-freebsd 7 Feb 2023 (as expected) If freebsd-update is run on a 13.1-R arm64 machine, installed updates then rebooted, it gets: $ openssl version OpenSSL 1.1.1o-freebsd 3 May 2022 ??? The freebsd-update was run about 10 mins ago (feb 18th 1821 UTC) -- From nobody Sat Feb 18 22:11:50 2023 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 4PK2wD5CrHz3rxJc for ; Sat, 18 Feb 2023 22:11:56 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [IPv6:2a01:4f8:13b:240c::25]) (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 ECDSA (P-384) client-digest SHA384) (Client CN "mail.bsd4all.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PK2wC0cH1z3lc0 for ; Sat, 18 Feb 2023 22:11:55 +0000 (UTC) (envelope-from herbert@gojira.at) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gojira.at header.s=mail202005 header.b=WRJUK1Lj; spf=pass (mx1.freebsd.org: domain of herbert@gojira.at designates 2a01:4f8:13b:240c::25 as permitted sender) smtp.mailfrom=herbert@gojira.at; dmarc=none Date: Sat, 18 Feb 2023 23:11:50 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gojira.at; s=mail202005; t=1676758310; bh=+Zww//vF+MIzujSZFRTDq1YFwspG7kw/b0ALCKVsC6Q=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=WRJUK1LjvkjYEFhw42BveLJ8etPZPP94QMZssk6x36VURDHJUWoLLOrfowhVsVm8Y VFNTGXhltZ+pVnBm4y6P82pC4mkRb5YVZNhXFY6Ow4+Sg4gJr4UB3719Mj7BCpoBV/ A52LG1K6R+d3RsYjK994F7X5SA1efIjFV0VP9OGIXmppFrUTp9pDb98ZhofzbxZ/jC Zqf/wEH63SaZ8IQqiym/zyryDoVfDZX3TLq2nFndKTiuR7vIGA11MXpBabLJQPc5us MH7Se3klrSrPAyCi5G3PXkDAKJ/Wnf31hRzkvIZbOjT271saAh1mGvpMRMuOLstW/x ImkvfazrK3Oww== From: "Herbert J. Skuhra" To: freebsd-arm@freebsd.org Subject: Re: freebsd-update confusion Message-ID: References: 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 In-Reply-To: X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.989]; R_SPF_ALLOW(-0.20)[+ip6:2a01:4f8:13b:240c::25]; R_DKIM_ALLOW(-0.20)[gojira.at:s=mail202005]; MIME_GOOD(-0.10)[text/plain]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; DKIM_TRACE(0.00)[gojira.at:+]; ARC_NA(0.00)[]; DMARC_NA(0.00)[gojira.at]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE] X-Rspamd-Queue-Id: 4PK2wC0cH1z3lc0 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Sat, Feb 18, 2023 at 09:53:56PM +0000, void wrote: > In https://lists.freebsd.org/archives/freebsd-security/2023-February/000146.html > there's an SA for openssl. > > If I upgrade (buildworld etc) on an amd box, it gets: > > % openssl version > OpenSSL 1.1.1t-freebsd 7 Feb 2023 > > (as expected) This is either stable/13, releng/13.2 or main where openssl was updated to version OpenSSL 1.1.1t. > If freebsd-update is run on a 13.1-R arm64 machine, installed updates then > rebooted, it gets: > > $ openssl version > OpenSSL 1.1.1o-freebsd 3 May 2022 > > ??? > > The freebsd-update was run about 10 mins ago (feb 18th 1821 UTC) This is releng/13.1 where openssl is still OpenSSL 1.1.1o; only security fixes were applied. You will get OpenSSL 1.1.1t after upgrading to 13.2-RELEASE (expected to be released next month). What's the output of 'freebsd-version -kru'? It will tell you if your system is up-to-date. -- Herbert From nobody Sat Feb 18 23:06:20 2023 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 4PK4764zK3z3s2DT for ; Sat, 18 Feb 2023 23:06:26 +0000 (UTC) (envelope-from void@f-m.fm) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (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 mx1.freebsd.org (Postfix) with ESMTPS id 4PK4751vC6z3rB2 for ; Sat, 18 Feb 2023 23:06:25 +0000 (UTC) (envelope-from void@f-m.fm) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=f-m.fm header.s=fm1 header.b="N9o/iB8O"; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=MAPPrbl3; spf=pass (mx1.freebsd.org: domain of void@f-m.fm designates 64.147.123.25 as permitted sender) smtp.mailfrom=void@f-m.fm; dmarc=pass (policy=none) header.from=f-m.fm Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id C90BF3200564 for ; Sat, 18 Feb 2023 18:06:23 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sat, 18 Feb 2023 18:06:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=f-m.fm; h=cc :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; t=1676761583; x=1676847983; bh=5ajuCaDD5h 0D8VCsNcy9SufMit3fueFXYhID+skDWdM=; b=N9o/iB8OX9cNFmGFSfhmwTEvtd X/rm8rRV6svf+FWL0rsfobi02rWcc/MzLbx0Ph7+8l/xemnQEbuFzJPTatoJ6scV Y0aLECEH2FRmkUPu8HRJLh4cROhzDb6Osk0QB4NQetkmi1sveGRN7JdWJ7zsUYg1 6T7kWgMtqjyiHz8kG6zZZql76GcWFVrHcEw/Bn9y391gQXH2995qWisAPusB/eYQ 1GKqP89pNy7EK0nRs55vRD4QJwfT1FdGgJP5ZC0V0FQQEnMpxOxPBAOX9KcHup+Y d+1Z4Z45I5irLz+O/k2lfib4mcMr+Hu1VjAe0FQljc2rmdy5c13EVTDZNVPQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1676761583; x=1676847983; bh=5ajuCaDD5h0D8VCsNcy9SufMit3f ueFXYhID+skDWdM=; b=MAPPrbl3JISwLMvGlh5YgnVt13gSIKs7RBIWvg6HSCGe LkN7fdkbEZQESaLWkEY5hJ7WtzzsToMHoMuRxo0jeskdwoHjtnbqWKvU4bZARJIK QVI23sTjW+D25Y8dTOh2W8XYsTmx+FSYZNlNtxWtZrJOosaWhz4luSqKf+XXN8ua 7mtWh7e/uzQtBGj8dPD/k8ivhuXILKOM5RPLF9qdnAg1y4VJ+g1rejxzKTw56BaN Sa1svHkbWBfhllf7xJRJ+/leZ21zOK5U7Jnr8l+2EBIPykItRVlpb5dwgMTPJHMJ ViNmaAXMdhOb4tgJQFrDBnTnmYQLa6AIZR3VIpwt7g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudejvddgtdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre dttddtvdenucfhrhhomhepvhhoihguuceovhhoihgusehfqdhmrdhfmheqnecuggftrfgr thhtvghrnheptdfhheeuteejudffkefhtdfhfeekgedtvdeiteevgfejtdfgfeffhfeuie eltdeinecuffhomhgrihhnpehfrhgvvggsshgurdhorhhgnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepvhhoihgusehfqdhmrdhfmh X-ME-Proxy: Feedback-ID: i2541463c:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sat, 18 Feb 2023 18:06:22 -0500 (EST) Date: Sat, 18 Feb 2023 23:06:20 +0000 From: void To: freebsd-arm@freebsd.org Subject: Re: freebsd-update confusion Message-ID: Mail-Followup-To: freebsd-arm@freebsd.org References: 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; format=flowed Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-4.58 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.977]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[f-m.fm,none]; R_DKIM_ALLOW(-0.20)[f-m.fm:s=fm1,messagingengine.com:s=fm1]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.25]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.25:from]; FREEMAIL_ENVFROM(0.00)[f-m.fm]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arm@freebsd.org]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; RCPT_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; FREEMAIL_FROM(0.00)[f-m.fm]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[f-m.fm:+,messagingengine.com:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.25:from]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4PK4751vC6z3rB2 X-Spamd-Bar: ---- X-ThisMailContainsUnwantedMimeParts: N Hello Herbert, On Sat, Feb 18, 2023 at 11:11:50PM +0100, Herbert J. Skuhra wrote: >On Sat, Feb 18, 2023 at 09:53:56PM +0000, void wrote: >> In https://lists.freebsd.org/archives/freebsd-security/2023-February/000146.html >> there's an SA for openssl. >> >> If I upgrade (buildworld etc) on an amd box, it gets: >> >> % openssl version >> OpenSSL 1.1.1t-freebsd 7 Feb 2023 >> >> (as expected) > >This is either stable/13, releng/13.2 or main where openssl was updated >to version OpenSSL 1.1.1t. > >> If freebsd-update is run on a 13.1-R arm64 machine, installed updates then >> rebooted, it gets: >> >> $ openssl version >> OpenSSL 1.1.1o-freebsd 3 May 2022 >> >> ??? >> >> The freebsd-update was run about 10 mins ago (feb 18th 1821 UTC) > >This is releng/13.1 where openssl is still OpenSSL 1.1.1o; only security >fixes were applied. This is the bit that was confusing me. I thought 1.1.1t was with the security fixes. >You will get OpenSSL 1.1.1t after upgrading to >13.2-RELEASE (expected to be released next month). https://lists.freebsd.org/archives/freebsd-security/2023-February/000146.html has this: Corrected: 2023-02-07 22:38:40 UTC (stable/13, 13.1-STABLE) 2023-02-16 17:58:13 UTC (releng/13.1, 13.1-RELEASE-p7) 2023-02-07 23:09:41 UTC (stable/12, 12.4-STABLE) 2023-02-16 18:04:12 UTC (releng/12.4, 12.4-RELEASE-p2) 2023-02-16 18:03:37 UTC (releng/12.3, 12.3-RELEASE-p12) So, if I'm understanding you correctly, none of those releases indicated above would go to 1.1.1t ? >What's the output of 'freebsd-version -kru'? It will tell you if your >system is up-to-date. % freebsd-version -kru 13.1-RELEASE-p6 13.1-RELEASE-p6 13.1-RELEASE-p7 It's really kind of opaque (to me) that openssl version is '1.1.1o-freebsd 3 May 2022' *after* the update has been applied. If it was something like '1.1.1o-freebsd-p1 16 Feb 2023', I'd feel a bit better, because as it stands, it looks like, on the face of it, that openssl hasn't been patched. Otherwise wouldn't the versioning info change in some respect, to indicate that it had? -- From nobody Sat Feb 18 23:49:32 2023 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 4PK5576pXPz3s4cP for ; Sat, 18 Feb 2023 23:49:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-25.consmr.mail.gq1.yahoo.com (sonic304-25.consmr.mail.gq1.yahoo.com [98.137.68.206]) (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 4PK5574F30z3vKN for ; Sat, 18 Feb 2023 23:49:47 +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=1676764185; bh=T+P6IBI2SqS5iInSYaxtVRZmerZTyYrxvY2TGcwljxc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=kEofEwmJfBj01NH6OkhIeWhDJdeLXXl4H1YRBW02eUuZ1anJLPpmQE7rGenalG1SMHZAHP9pEkvVAq63Aa7TKBPvkq7L06OsG57NKTlVqmpbmXpO0C+hLaCcAYNrRHdCD6rdapAs0eX1b9vwoP98qoq+9Czut/vQ7N1oyVJzIxqr5ygykCaZOAWwSSf15RmZYeD5GY4Yo15gvMAE1sDH6j0sabrjdHaoHxH+7ldtash+tMvyFEkLEUjA6kL3sBGcCId2zCmss3w20AZLwnp4u4i39Vph1XzHAhkaA3D4Z0p8tO7LcgdzhfIK3HLdpLwxNiBP/FY0jDzWJkeNhiaIGw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676764185; bh=b4XFchI9Z0NHspa6TNx3obq40y8b5GKYEt7juV/7qIr=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=gbg9qJ4eXG//+Ua4zWlv5Sw/+i451hNh/9y9gZecoim6WCeUrj0z9vvb9WWFMWUnUQfBisMK9pqTU9NJBCVFBMOHwJNBkTlYoBXG5C2OlP002O+KjRwtKmRE3EECADjUR5PoTrHKFW3arbHLnJ7vOLThjo/JMHdIVdlIrkA9NYx15lcdXNlNUzrUVrNkejWJw35jTxd2oO3pMm9/zsgin47KpQY//QqtW75dDlkcVkXX+xnVur1hiiFjNIF6ROqYfqh0iuMwre2nP8gNsCMJurUAeLpfqtNJ1JweqAv5dZfr4PXeSb6L7f5KplrdLLOoNEOtKnpdXOtW3aMLjG25FA== X-YMail-OSG: hnEt6CoVM1m8HrheQdMNNtWgbJR5xeY6lYRfBL5c1p1yWTp1kpBEogeSfJuOLtT kWX7b3gB10DFH3EP69jddrIjCTdE_0Fd47lhXXQpbsk4eBZoXyjBN8OvMIRQiQyU33ZWIj10nZdv Nd_TccU_gsOpT9SLeCpjOeJPkQVII0dZcxcPRYRiJRMjc9cgHUbs2XrBhN5Je0eq2t5T_VXEbbbb k.D0Lox7JHhRYMUaNEamCeOXHcei4MaxgrJjCeEm6se.t6QEwMDZ0xQVOLf3ITKuvUMxKJWHQWNp HR_3ZVF38gyP9lsQ7wBQmwvsUfvYslBQOAH3H2MZz6oOSWuSDuqLTRhTKKe8YUB2OA1mwzdw.1zO 0eX_PV8JcjXkCT4CciEk8uqqas6s5CsP3fSBpZH_uLJLs8KtKJv0wyjwxci5diWZ_KMsVVejARcl XWg6WuzLs2CNTMUf6o8VQ3WbNUtm0.WnEV.AbBzv_3ao1f2an4H7kopK2ozGYY_s9Q.wM18afEVZ sggQuJn.R0ZDp886B3SBM3Jl_zGIf3xz1JI9BjDd6oMa.0GnhM8M6jgmGyt8RUDkVOM80GDjxlY5 _cwBKsvFsvJ0ahVN8Ef8IPLE_ufT3Mtp6C9RPw1kQI95egijLGZq3rT2mFa.DQQB.D.YVnYlpSY1 Qge3iu6LLpi6SBq.UOFOf36NFojzFyFnzdskCM4h20sBmfXxCn.CKaFd86MQZJ.nEqKpUcodRV8W cRINymZQsWTC2edEbe6.T6omGmkvZfEmeJpLmzBMY5tLFqUVpjneBXGUPHf8SGZaT6cPfBlMS7LT J8WA8p3ND95OONNJB5w9rzsB_3NzlXyWgj3.uRrLqvN8ZIcbD1fRomvKRNkI3ptBVGg5ZeRdL.VM 6ovrJbVry2XETEeMKEHmxkQ1SB478RdvVCcVsY6Qy3jybBNZf3ciQZAcMxRWx.mjf3ODcWxwMAnf 0CmpYTJAPcLVlc438vEMVaGh5qyWrEbVkoN4khiwz3lOufe6WjhBhiVxMdExuruozIjK0dCI7nIT m1aUCxmFABe.kHL8aMrFC48x4sIHS7aUO6DAx1Go4Td5Q345qdl_fAMDK6CGYn..kMAyOlSQxM.i 37g6lMNAHykjtsjpwgQy4IcIcVRX2kGS2NxRyv3Nhl7fhY8NNBoLQjf53PJB_XWBuYs3IGem_qCI msQDVVOxrg4pcxGtp3tkVohq8dtRKIqdACaHx3t.G3g36x4.FeAsN7jflhns.Nr37DsNeuDTFEdT loIU8PSDjIGbETk5ec6obXW5WRuINpU8jl8fOHOj5ICVGaJLtfnpkL7IB4SFzh75VT3ow4pGYvaI NvI3hkoZKyANPZB9V2io4.x85e.yu1fwVzu3vove2iss7mMsfqrQT_AkRWp7RlxMdvXg9xh1iXCQ ntvIQzVhH2OSsPYVt0xwD5Hfomg2VQKUSYlhlz0In.7j_nb03pDmRgLfamiuiozGz3Dr5F2erOz3 J.Od9V9S_R0itApwlpnoF12QZIA46M_Y93tgIgLjNfe2Pu1dJtBINK_phW0eTLc_I.V5fJELvT3G Ium4Mj10gOPLQdighxHZHKwlM1Vcbn2ZcZ30vQ1CA.4Ql_HX3ke7tUnz2J2D02s5CtilYsy7Yiv_ oYwih9JmsJqvCrrtJufeKBaIDHuV57VPI46Hcbj6xXPpZN.VazHQDgIPGPZ9qWXs83IbW_qbTUl1 qU8uq53dTeZH8rW5GUMKA4OKTi.v42vZdCbJOdBSss97CVCpr9803e106nwGmfJ3rKuAhVkcCu2y k.2DR6MKb1niM23G2T3tcNLCjV7ZDiHURFw0fRGwklqoi1aHHcZtwUOmgpymK19BCaH_YKaKVFX6 PpvNQqMzeIeMvDUVwetwTKZe1m2NyUJ3KrfMZR5c3FbkD61Fy_CJ1Ul__xoGw0sQ6VixSWhWyHRM vTx5q8Ol0aGzyK.fqO7j1Mv1vIiSmZgOl7QtY2oTyfNuoqZZFVqXO3Ej0ioBGEdMNLCNnRLXy87K bl7YAyEjohYyGKLm2j3LSBcqArO9cWzQPlDm1bp6gLFb_FsBtWbkL0V48znw328Pm1I0CV_4Relj m9y3Lel3sJa4ZtnGrOaLoP2D9YHsbJFDMOy6Qo1cfMtCIHBhyFy2Jf1qwjNT7P7axri_oJw4JsPl xGR1CN51PUF5Xs.6kaq0roBCydZtOv2v0IGBOwNTAR9hWWRke3tNNRR9liPZxM.oZIIX1nAnr2ft SvL4b_mtoMyHEE2ZO_Sg7hSTdnjy2tyFF9IhzVNjqht1t9qk.OBbIKblE2DXOXbC3FIRYoVbJrKQ - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sat, 18 Feb 2023 23:49:45 +0000 Received: by hermes--production-bf1-57c96c66f6-7qgxj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c8f6972ec1109afbc54849f08b95684e; Sat, 18 Feb 2023 23:49:43 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: fsck segfaults on rpi3 running 13-stable (and on 14-CURRENT analyzing the same file system that resulted from the 13-STABLE crash) From: Mark Millard In-Reply-To: <20230218210610.GA50074@www.zefox.net> Date: Sat, 18 Feb 2023 15:49:32 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <940E58F8-4EC4-4DDB-9428-F6D13ED3132F@yahoo.com> References: <20230214161415.GA28276@www.zefox.net> <20230214183827.GG95670@funkthat.com> <20230214210601.GA28959@www.zefox.net> <20230214232746.GI95670@funkthat.com> <20230215154424.GA34278@www.zefox.net> <20230215190856.GA34665@www.zefox.net> <20230217232537.GA46176@www.zefox.net> <5FFA8C73-4F9B-4633-897C-75368FA9FD4F@yahoo.com> <20230218210610.GA50074@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4PK5574F30z3vKN X-Spamd-Bar: ---- 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-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Feb 18, 2023, at 13:06, bob prohaska wrote: > On Fri, Feb 17, 2023 at 04:23:59PM -0800, Mark Millard wrote: > [huge snip] >> Looks like that is one of the messages for problems >> fsck_ffs does not attempt to deal with (probably for >> good reasons in each case/context). > > Since there wasn't much to lose I tried deleting > the bad inodes using fsdb clri and re-running fsck. > > After maybe a dozen cycles fsck reported the filesystem > clean and, to a superficial inspection, intact. > > The disk rebooted, ran git reset --hard and is now running > buildworld. Fingers and toes are now fully crossed 8-) > > Is it possible to continue updating the -current Pi3 using > git while preserving the hand-applied changes to /sbin/fsck? Making some presumptions about your source path ( /usr/src/ ) . . . (Beware that I do not use git pull but do fetch and merge --ff-only separately. So I'm guessing some below.) # git -C /usr/src/ status (Any surprises? Deal with such. YOu might want to restore sources that you know you will just want the newer official content of.) # git -C /usr/src/ stash push # git -C /usr/src/ pull # git -C /usr/src/ stash apply AT THIS POINT IT MIGHT INDICATE CONFLICTS IF THE fsck_fft SOURCE HAS BEEN UPDATED. There is more to it if/when that happens. You might choose to restore the official source, for example. I'm not listing explicit steps for any alternatives. Sometime later when things are known okay but likely before the next stash push: # git -C /usr/src/ stash drop I'll note that you could first "cd /usr/src/" instead of using "-C /usr/src/" on the command lines. > Simply running git pull results in complaints about unstaged > changes. IIRC, subversion didn't care. > > [another huge snip} > > >> >> Beyond that, things with floating-point use in >> multi-threading contexts looks to be significantly >> broken in main [so: 14] for now. (This was involved >> in your FreeBSD crash based on the the backtrace >> showed.) >> >> If you try to set up another armv7 context, I suggest, >> for now, staying before: >> >> commit 6926e2699ae55080f860488895a2a9aa6e6d9b4d >> Author: Kornel Dul??ba >> AuthorDate: 2023-02-04 12:59:30 +0000 >> Commit: Kornel Dul??ba >> CommitDate: 2023-02-04 19:21:43 +0000 >> >> arm: Add support for using VFP in kernel >> >> This would be until a list of issues have been >> addressed. I've reported how to produce 3 >> distinct failures, 2 of which hit KASSERT >> panics, and the other one is for ending up with >> floating-point values from the wrong thread >> (but same process). More may be identified >> and fixed before things generally work again >> for main for armv7 FreeBSD. > > The relative merits of aarch64 vs armv7 are a bit > muddy from my point of view. The only real objection > to aarch64 on the Pi3 is running out of memory > during buildworld. Using armv7 on an RPi3B runs out of RAM+SWAP sooner because it only allows a much smaller swapspace due to the armv7 code's addressing limitations, as I understand. (It also ends up mistuned at a much smaller swap space size.) So to allow (near) maximum RAM+SWAP for a reasonably tuned context: use aarch64 on RPi3B's. > On a "production" machine that > happens infrequently and needn't be fast, so -j2 > solves the problem. I was interested in trying to > use armv7 on the Pi3, but unless it works "out of > the box" it's probably more trouble than benefit. All sufficiently recent main native-armv7 kernels are broken because of the VFP handling changes, at least for hardware with VFP. Your original report was for the buildworld failure on a RPi2. Was that v1.1 so armv7-only (no aarch64 present)? The original backtrace indicates a problem that is tied to the armv7 kernel new VFP handling that is not working well yet. That would also apply to a RPi3B using an armv7 kernel. FYI: I did my how-to-reproduce investigations on a OrPi+2e armv7, not on a RPi* . === Mark Millard marklmi at yahoo.com