From owner-freebsd-current@freebsd.org Sun Oct 25 00:15:46 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A1E66438E35; Sun, 25 Oct 2020 00:15:46 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-to1can01on0618.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5d::618]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CJdm04n36z4JX3; Sun, 25 Oct 2020 00:15:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E6i5fcarYR1WDwSZ7U8SvQJBRa53kVtoEywaCEIoMjc2EmzY842bmnGC4//EJHPnWrJnTCnbBBiKrbPC/Oa10cKd7DrDYV3K8/OMVtBFWxCz58WPwLGk3z1rpj/gTZXXuTCCLVmQVZ/vZ1Gjg1raHv6vy24eMMks9RuyN0Vpx1HF/c7yfOqkMwIk2w194HlqXVaMJLOWb0PX11n4oO44dDURiiiquMc4+/ufSRTzOL/QLwL3N+pRb7sgLzEEYeHlYoecbCvgC8JvX85540ch2CEvLMXlEupPxY+Ip1WekgX+XuQGHbDtWYN0hIfDBceDHeDFe7J8tqim9SxrVQwq6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Rpqscr7zRMNEZ6vOlN/FfcJzueCjNYk/fEkSY+cgSMk=; b=iG2bjk83SG+3iYrICnQdU+QPECIVswkouVLZJqRapMMwC/fiPAfL5NIuj8b+eWbyh4Ljdmer5IwpkMPYKdBbAedRLqDFZkhPtys6Bh0ZsktZurY3FWDJ00jpMaZJFv2owJ6gHR7/5PwekhXHTAmVrRWZIUxgH0swuNTHNSWoYmfOdXubUFIYYzFZ2nABhAg5AFxa80YlGdvt/L4cj9bdqnLgS9oO1dQWOodsj98F7W8blH8lP6DrRH2/UBo24Tma5kemqK97Rq37Gg5cCa2fbvIz/VoZwY+rKwjSQSOum51sBfSVdll8Gwz0bvsAfSDWISn6S88QEGh+oV2ZAoaiqA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (10.255.13.27) by YTOPR0101MB0891.CANPRD01.PROD.OUTLOOK.COM (52.132.49.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Sun, 25 Oct 2020 00:15:34 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3499.018; Sun, 25 Oct 2020 00:15:34 +0000 From: Rick Macklem To: "rc@freebsd.org" CC: "freebsd-current@FreeBSD.org" Subject: rc.d scripts patch needs review Thread-Topic: rc.d scripts patch needs review Thread-Index: AQHWqmOnTcN7PWMs+UCABTf0b8WoTw== Date: Sun, 25 Oct 2020 00:15:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b45d2243-da92-40a7-417b-08d8787b17d9 x-ms-traffictypediagnostic: YTOPR0101MB0891: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0otVDqi8CgJ2uD7whmv9KWmos7CN77rTYmNIWEW290I9iir1CZMslsv44EZVzlQhhZvqPGGXDbJE+vfvu+t5NxriY54Bxj/JDafc/6eSCI66cptxIVdbff+viBklUOCS2IE0FGqp9wqWYt04mIVyboWQs6JAc27ruGVv7/RIto2oDClP3/lDPJw07S4V5e51futLLM7k2xXbJwLZxtgS9QFVp1foXkSDrKkKRuOYyZqUaBxx+pU6kI6O5qQ0PuKAlk611j/g/k34i39aqJ3IbczFHEeTURq3JgFfKohKPhqf3JYAUDvjBpLfcpaG6m3Ut83BGYELeBCBk8LfRbEGrg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39850400004)(396003)(366004)(346002)(136003)(376002)(450100002)(2906002)(4326008)(52536014)(71200400001)(5660300002)(558084003)(6916009)(86362001)(7696005)(9686003)(6506007)(64756008)(66446008)(66476007)(316002)(66556008)(55016002)(33656002)(91956017)(8676002)(478600001)(8936002)(66946007)(786003)(76116006)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: J6oRwGnDsnuWjKGI5hN6RMnPF+MRRjLf6avYeji4rDIX84RHFVpdlI2awYyvi3z5S1oKxl4qt2TQTVt/HJ4UvJ9Kqu/d79DKGfgXNCkiW+Qd4mr9xsuJq1yeVHJfurLpgnGyg5y37eEupiblfghMiEtP8xKT2B77Pph6E0kWbtkoh2fo4Ru/za22uXm71/gT0HFVu4p+nIvx2iT7AUXGanXx5vXg751+WQZpa2spJL8VygGddennU5p0DpSbusa49r0Z5RWMc83O84y1SCuv2+O6mydAmBlrc8LSGosAGgov2kQkGNIgaMVYDBSTSNGAhBAzb0SBQhhIV6NKEmoNHzeWy5zRmjgEqtbrsigjjBqzn6vDm5o3K2JhPl+XWRyEgXqJyX8tqaMgOS0MMExuherz0CAb2g1D194IA8Y4h+VDSt7pq02vrEljCUJxKJRbJEX+FxpEQuLcnBaSfxuSodJa5r6NhdypzKPz33KOL9EGNSfmKFXTiP4TbDLIkCulPcPgjY3Qw2BUpRo5bMclvj4LQV9IKECc5NgZkiD93iC00N6VS2bcQfENVSFppyPPa7/xiRy+gZDJDcWd7JMICOEtEU2TYGIlYdCUUxNp0M05cnhgbzvts5Kv+LB+rxudj4jXDusBhr+7WkJ3AqZ4q0DybovZF6jVEYNxJDvfcf7I2Ke8Lnwkn2wXBvKZZpcSBajPaFDklrc7xx1C9dE6mg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: b45d2243-da92-40a7-417b-08d8787b17d9 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2020 00:15:34.8130 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UX4vtP60/nmQlo0SKA5q7DNsPutd95pQb3mKmrnGhRiVaRZxPydTcT7113PyQ3N/J3HgXVu4sSeqW5wJaldPXQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB0891 X-Rspamd-Queue-Id: 4CJdm04n36z4JX3 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.21 / 15.00]; NEURAL_HAM_MEDIUM(-1.05)[-1.050]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-0.99)[-0.986]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; NEURAL_HAM_SHORT(-1.17)[-1.173]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MAILMAN_DEST(0.00)[rc,freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2020 00:15:46 -0000 Hi,=0A= =0A= I've put D26938 up on phabricator. The patch applies to the=0A= /etc/rc.d scripts mountd and nfsd, to make use of the new=0A= mountd "-R" option committed via r376026.=0A= =0A= If anyone can review this, please do so.=0A= (Is there a group review for rc scripts?)=0A= =0A= Thanks, rick=0A= From owner-freebsd-current@freebsd.org Sun Oct 25 05:52:38 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AD28F443BD5 for ; Sun, 25 Oct 2020 05:52:38 +0000 (UTC) (envelope-from yasu@utahime.org) Received: from maybe.home.utahime.org (gate.home.utahime.org [183.180.29.210]) (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 4CJnDj5j42z4cPG for ; Sun, 25 Oct 2020 05:52:37 +0000 (UTC) (envelope-from yasu@utahime.org) Received: from eastasia.home.utahime.org (eastasia.home.utahime.org [192.168.174.1]) (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) (No client certificate requested) by maybe.home.utahime.org (Postfix) with ESMTPS id 11DF42196C for ; Sun, 25 Oct 2020 14:52:28 +0900 (JST) Received: from localhost (rolling.home.utahime.org [192.168.174.11]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by eastasia.home.utahime.org (Postfix) with ESMTPSA id 3FA03207EE; Sun, 25 Oct 2020 14:52:27 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.0 at eastasia.home.utahime.org Date: Sun, 25 Oct 2020 14:52:05 +0900 (JST) Message-Id: <20201025.145205.2130959911090091593.yasu@utahime.org> To: freebsd-current@freebsd.org Subject: Building packages with poudriere fails after `zfs upgrade` From: Yasuhiro KIMURA X-Mailer: Mew version 6.8 on Emacs 27.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4CJnDj5j42z4cPG X-Spamd-Bar: / X-Spamd-Result: default: False [0.14 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[utahime.org:s=maybe2019112701]; NEURAL_HAM_MEDIUM(-1.02)[-1.020]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[utahime.org]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.96)[-0.965]; RCVD_COUNT_THREE(0.00)[3]; HFILTER_HELO_IP_A(1.00)[maybe.home.utahime.org]; R_SPF_ALLOW(-0.20)[+a:spf-authorized.utahime.org]; DKIM_TRACE(0.00)[utahime.org:+]; NEURAL_HAM_SHORT(-0.18)[-0.176]; MID_CONTAINS_FROM(1.00)[]; HFILTER_HELO_NORES_A_OR_MX(0.30)[maybe.home.utahime.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2519, ipnet:183.180.0.0/16, country:JP]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2020 05:52:38 -0000 Hello, I tried `zfs upgrade zroot` on my 13-CURRENT r366977 host and after that building packages with poudriere fails as following. [00:04:55] [02] [00:00:00] Building security/libtasn1 | libtasn1-4.16.0 [00:05:10] [02] [00:00:15] Finished security/libtasn1 | libtasn1-4.16.0: Success [00:05:10] [02] [00:00:00] Building devel/libunistring | libunistring-0.9.10_1 cannot rollback 'zroot/poudriere/jails/curamd64-original-ref/02': dataset is busy [00:05:11] [02] [00:00:01] Error: Unable to rollback zroot/poudriere/jails/curamd64-original-ref/02 to prepkg =>> Error: Unable to rollback zroot/poudriere/jails/curamd64-original-ref/02 to prepkg How should I fix it? Best Regards. --- Yasuhiro KIMURA From owner-freebsd-current@freebsd.org Sun Oct 25 13:11:00 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8E2E944EB01 for ; Sun, 25 Oct 2020 13:11:00 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CJyyX2Xcvz42sM; Sun, 25 Oct 2020 13:11:00 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-WLAN.fritz.box (p200300cd5f0bbc0059aab49e04a56e55.dip0.t-ipconnect.de [IPv6:2003:cd:5f0b:bc00:59aa:b49e:4a5:6e55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id E049E17F56; Sun, 25 Oct 2020 13:10:59 +0000 (UTC) (envelope-from se@freebsd.org) To: FreeBSD CURRENT From: Stefan Esser Subject: [REVIEW] replace literal uses of /usr/local with a macro [D26942] Message-ID: <2b938572-dfbb-4597-0095-8490bb3745ee@freebsd.org> Date: Sun, 25 Oct 2020 14:10:58 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2020 13:11:00 -0000 I have created https://reviews.freebsd.org/D26942 as a suggested patch to remove nearly 20 literal uses of /usr/local in the base system. This requires to add an include of paths.h to some of the source files (.c or .h), but none of these includes is leaked to /usr/include and they are thus only visible during the build. I have built the world with this patch applied and the resulting binaries are unchanged. The definition of _PATH_LOCALBASE in paths.h could at a later time be derived from the value of LOCALBASE (in src/Makefile.inc1 or overridden my the user in src.conf), but this is a change that should be discussed separately from this review. Please comment on this patch, the decision to not touch contrib sources and which follow-up steps to perform next (e.g. similar changes to shell scripts or configuration files). From owner-freebsd-current@freebsd.org Sun Oct 25 18:38:06 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6542745573C for ; Sun, 25 Oct 2020 18:38:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CK6Cx3Bt6z4NTF for ; Sun, 25 Oct 2020 18:38:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82b.google.com with SMTP id p88so5184913qtd.12 for ; Sun, 25 Oct 2020 11:38:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V1Y0NoteYJeakCubGTiVFZ3QYql3XiBq5iG+1M71+M0=; b=DPA0G5Gh1fah42Ow/JqW1vmiRD+f4wV1Sab+dg2me2cTb4ecv9Dypv1IbbCp3mp7rX R3/Iybys39WSjAWRNpyEeUX/wsL0kVnXUh6j9OEcL24HqaoTMSD84iIXGvaF+0N2U8+a JwbC10S7t/w0c4iamo1HkmcswZVF+KM+eFLS1krS0r3vz1sWoUZejnX6YK+qsN/vveCZ btQ/+KdsSNXIoDGUWaCKdT13WVQcELEKkzSYIyyJmHZTLMLWUPXcloHxAfVvactptrQm n+N7q+zEuLjBN803sif8cCx9DI3K8xT8KNiD8t84/FGa0ohgMBtDcmf0/5iMCClfvTCb qy5g== X-Gm-Message-State: AOAM530qmw4vABD6+OCyPzWGrU972FDm0aToBth49OyRrLV1FbOfTd7Q aOt6Oiz+565/P1DHgRCaNYujKqiGgnrKhfODUk03cw== X-Google-Smtp-Source: ABdhPJx6e9itBok8oyWiB/dG0bFHJYxaTMU1X3C4hgeZ1KhmlhFdfETeiM7pvmjqOSLUTs/++R7XQd2KSjA4nql04RA= X-Received: by 2002:aed:3031:: with SMTP id 46mr13480590qte.49.1603651084182; Sun, 25 Oct 2020 11:38:04 -0700 (PDT) MIME-Version: 1.0 References: <2b938572-dfbb-4597-0095-8490bb3745ee@freebsd.org> In-Reply-To: <2b938572-dfbb-4597-0095-8490bb3745ee@freebsd.org> From: Warner Losh Date: Sun, 25 Oct 2020 12:37:53 -0600 Message-ID: Subject: Re: [REVIEW] replace literal uses of /usr/local with a macro [D26942] To: Stefan Esser Cc: FreeBSD CURRENT X-Rspamd-Queue-Id: 4CK6Cx3Bt6z4NTF X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.69 / 15.00]; ARC_NA(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-0.93)[-0.928]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.01)[-1.009]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82b:from]; NEURAL_HAM_SHORT(-0.75)[-0.752]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2020 18:38:06 -0000 On Sun, Oct 25, 2020 at 7:11 AM Stefan Esser wrote: > I have created > > https://reviews.freebsd.org/D26942 > > as a suggested patch to remove nearly 20 literal uses of /usr/local > in the base system. > > This requires to add an include of paths.h to some of the source files > (.c or .h), but none of these includes is leaked to /usr/include and > they are thus only visible during the build. > > I have built the world with this patch applied and the resulting > binaries are unchanged. > > The definition of _PATH_LOCALBASE in paths.h could at a later time > be derived from the value of LOCALBASE (in src/Makefile.inc1 or > overridden my the user in src.conf), but this is a change that > should be discussed separately from this review. > > Please comment on this patch, the decision to not touch contrib > sources and which follow-up steps to perform next (e.g. similar > changes to shell scripts or configuration files). > I hope this is coupled with creating an option to have /usr/local/lib, /usr/local/inclulde, etc in the default search paths. While some may dislike it, when I've hacked these in the past I've found that porting some specialized Linux software to go more quickly since I didn't have to thread this through autoconfig scripts that were poorly written... I know it's not for everybody (hence my use of the word 'option'), though. Thanks for jumping into this problem and sorting it out. I tend to agree with comments you've made elsewhere the only hope is a series of incremental solutions give the twisty nature of where and how this is used. Warner From owner-freebsd-current@freebsd.org Mon Oct 26 03:24:43 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8676F45FA4F; Mon, 26 Oct 2020 03:24:43 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CKKvZ4DMrz4sfX; Mon, 26 Oct 2020 03:24:42 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: by mail-ot1-x343.google.com with SMTP id m22so6813326ots.4; Sun, 25 Oct 2020 20:24:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=E0p4IQyynXfuDQREqz90oFb+GMZfYSBTw/F660fpwvQ=; b=sSvfyR2cJ+4ie8S+KZx4S1zts//Ajcl7e0CLiQYNjQ+Cm511ZJC7FfzN1fls2X+y+G La2TOAs/LADn2iZQS6sw2zur4mt0z71zA1DD7hx4RR4IDcsQp70tcC0zCq0mzSThgmQ5 /Moxn1czu5cIBT/e5RrOf0LQ02eNCRQBmw5VTLuAJIClDHo8wL5qHlPvAv+wGwG2aSAG vW7YAyX2TM602xJCoxK5S2VY8615Od33QhjEiUn4F35DAE785rJUbj4jQB9urx0U9DIr RmaeUV8N4I5Q7x1WaiiviIcCNJJjZsJxnonpII6iYgvi9GwKjE+ursHMRPmLGKGww8Be T0dw== X-Gm-Message-State: AOAM533HwS0epruf/zkWiVWQOSCvkF28hhm21pYLvU7p42gtk71inn+6 CBOsi6dj2jF6CKZJ1Sws2xIgo9O8Pzo9RJDVjKvyrK2V X-Google-Smtp-Source: ABdhPJwFEX9KN36/hip3zhV4j3W/cFWm5oUSYy59+MtBTk/qLtKK5NbdoQlcfQOfz2fVwLABnEUbi8PdbbfOZxm4Owc= X-Received: by 2002:a9d:518c:: with SMTP id y12mr3369564otg.284.1603682681308; Sun, 25 Oct 2020 20:24:41 -0700 (PDT) MIME-Version: 1.0 References: <20201006021029.GA13260@www.zefox.net> <20201006133743.GA96285@raichu> <20201019203954.GC46122@raichu> <454e1e9f-e839-8961-2ae1-9ddd86f1cefd@freebsd.org> <20201024193735.GA7755@raichu> In-Reply-To: <20201024193735.GA7755@raichu> Reply-To: alc@freebsd.org From: Alan Cox Date: Sun, 25 Oct 2020 22:24:30 -0500 Message-ID: Subject: Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3 To: Mark Johnston Cc: mmel@freebsd.org, bob prohaska , freebsd-current , freebsd-arm X-Rspamd-Queue-Id: 4CKKvZ4DMrz4sfX X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; HAS_REPLYTO(0.00)[alc@freebsd.org]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCPT_COUNT_FIVE(0.00)[5]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.04)[-1.036]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.03)[0.030]; NEURAL_HAM_LONG(-0.99)[-0.992]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::343:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-arm] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 03:24:43 -0000 On Sat, Oct 24, 2020 at 2:38 PM Mark Johnston wrote: > On Fri, Oct 23, 2020 at 06:32:25PM +0200, Michal Meloun wrote: > > > > > > On 19.10.2020 22:39, Mark Johnston wrote: > > > On Fri, Oct 16, 2020 at 11:53:56AM +0200, Michal Meloun wrote: > > >> > > >> > > >> On 06.10.2020 15:37, Mark Johnston wrote: > > >>> On Mon, Oct 05, 2020 at 07:10:29PM -0700, bob prohaska wrote: > > >>>> Still seeing non-current pmap panics on the Pi3, this time a B+ > running > > >>>> 13.0-CURRENT (GENERIC-MMCCAM) #0 71e02448ffb-c271826(master) > > >>>> during a -j4 buildworld. The backtrace reports > > >>>> > > >>>> panic: non-current pmap 0xffffa00020eab8f0 > > >>> > > >>> Could you show the output of "show procvm" from the debugger? > > >> > > >> I see same panic too, in my case its very rare - typical scenario is > > >> rebuild of kf5 ports (~250, 2 days of full load). Any idea how to > debug > > >> this? > > >> Michal > > > > > > I suspect that there is some race involving the pmap switching in > > > vmspace_exit(), but I can't see it. In the example below, presumably > > > process 22604 on CPU 0 is also exiting? Could you show the backtrace?> > > > It would also be useful to see the value of PCPU_GET(curpmap) at the > > > time of the panic. I'm not sure if there's a way to get that from DDB, > > > but I suspect it should be equal to &vmspace0->vm_pmap. > > Mark, > > I think that I found problem. > > The PCPU_GET() is not (and is not supposed to be) an atomic operation, > > it expects that thread is at least pinned. > > This is not true for pmap_remove_pages() - so I think that the KASSERT > > is racy and shoud be removed (or at least covered by > > sched_pin()/sched_unpin() pair). > > What do you think? > > I think you're right. On amd64 curpmap is loaded using a single > instruction so the assertion happens to work properly. On arm64 we > have: > > 0xffff0000007ff138 <+32>: mov x8, x18 > 0xffff0000007ff13c <+36>: ldr x8, [x8, #216] > 0xffff0000007ff140 <+40>: mov x26, x0 > 0xffff0000007ff144 <+44>: cmp x8, x0 > > Though, it looks like arm64's PCPU_GET could be modified to combine the > first two instructions. > > To fix it, we could perhaps change the KASSERT to verify that pmap == > vmspace_pmap(curthread->td_proc->p_vmspace). ... > Just delete it. It isn't useful. ... The various > implementations of pmap_remove_pages() have different flavours of the > same check and it would be nice to unify them. Using sched_pin() would > also be fine I think. > The useful version exists on amd64, where we verify that the pmap is only active on the processor performing pmap_remove_pages(). The reason being that some implementations of pmap_remove_pages(), including amd64's and arm64's, don't not use atomic RMW operations to simultaneously clear a PTE and check the status of the dirty bit. > > I think vmspace_exit() should issue a release fence with the cmpset and > > > an acquire fence when handling the refcnt == 1 case, > > Yep, true, fully agree. > > Alan pointed out in the review that pmap_remove_pages() acquires the > pmap lock, which I missed, so I don't think the extra barriers are > necessary after all. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Mon Oct 26 05:47:24 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1770F43AADA for ; Mon, 26 Oct 2020 05:47:24 +0000 (UTC) (envelope-from qroxana@mail.ru) Received: from smtp29.i.mail.ru (smtp29.i.mail.ru [94.100.177.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CKP4B6rPrz3Vw5 for ; Mon, 26 Oct 2020 05:47:22 +0000 (UTC) (envelope-from qroxana@mail.ru) Received: by smtp29.i.mail.ru with esmtpa (envelope-from ) id 1kWvLj-0000GY-Ic for freebsd-current@freebsd.org; Mon, 26 Oct 2020 08:47:20 +0300 Date: Mon, 26 Oct 2020 05:47:09 +0000 From: qroxana To: freebsd-current@freebsd.org Subject: OpenZFS: kldload zfs.ko freezes on i386 4GB memory MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: X-7564579A: B8F34718100C35BD X-77F55803: 4F1203BC0FB41BD97656661D03C0722C2D042CF307720508C6AD80ADC9ACBF3E182A05F5380850402553078F17C615391F248D014FDD15BD7A22A01AFAE5CDC47220C8A735F1AF31 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE71BDE6A359BD5B800EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F790063716A4A39B750036BB8638F802B75D45FF5571747095F342E8C7A0BC55FA0FE5FCC573900100D82C6F788AAB1C4BE79711AB391DED4F848BB0389733CBF5DBD5E913377AFFFEAFD269176DF2183F8FC7C0D9442B0B5983000E8941B15DA834481FCF19DD082D7633A0E7DDDDC251EA7DABA471835C12D1D977725E5C173C3A84C34964A708C60C975A117882F4460429728AD0CFFFB425014E592AE0A758652A3D76E601842F6C81A19E625A9149C048EE25175C6951743F6F28765F5520A300B2D8FC6C240DEA76429449624AB7ADAF37B2D370F7B14D4BC40A6AB1C7CE11FEE33BE4A381F4F6CAD8AD7EC71F1DB88427C4224003CC8364767A15B7713DBEF166A7F4EDE966BC389F9E8FC8737B5C22494DF83050870D0EDA75ECD9A6C639B01BBD4B6F7A4D31EC0BC0CAF46E325F83A522CA9DD8327EE493C1DE5D12A4F17E62CE5475246E174218B5C8C57E37DE458B4C7702A67D5C3316FA3894348FB808DBFC9E6230DA1D153FE5BFE6E7EFDEDCD789D4C264860C145E X-C8649E89: 789926F6B805DF841A0ACF88C903EEB62C851E5BF13907FDE1C8EA2897446A21C4BF2A2ACDBC5ABC X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojbL9S8ysBdXgj6APN4M2TmA0InRR+oc+W X-Mailru-Sender: 45472660D706069967F470449D4ADE187B4DE9A91F6938E27FFB988CDFBDDFB404A89304D2F11E7F60D6D505C5898BD5FF8C365A9CCAA137082AC48A80CE5D4D490AD6122F96B7B99DAF8AF4E272FCB55FAD6D05200F5AE3B84DA3FFC0930502EAB4BC95F72C04283CDA0F3B3F5B9367 X-Mras: Ok X-Rspamd-Queue-Id: 4CKP4B6rPrz3Vw5 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.73 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.989]; R_DKIM_ALLOW(-0.20)[mail.ru:s=mail3]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[mail.ru:dkim]; FREEMAIL_FROM(0.00)[mail.ru]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.988]; RCPT_COUNT_ONE(0.00)[1]; R_SPF_ALLOW(-0.20)[+ip4:94.100.176.0/20]; DKIM_TRACE(0.00)[mail.ru:+]; DMARC_POLICY_ALLOW(-0.50)[mail.ru,reject]; NEURAL_HAM_SHORT(-0.66)[-0.657]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[mail.ru]; ASN(0.00)[asn:47764, ipnet:94.100.176.0/20, country:RU]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_IN_DNSWL_LOW(-0.10)[94.100.177.89:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 05:47:24 -0000 Hi, I have an old i386 machine running r364479. After upgrading to r367045, running kldload zfs.ko freezes the whole system. I also tried to replace the 4GB memory with another 2GB one and kldload zfs.ko works without freezing the machine. Thanks. From owner-freebsd-current@freebsd.org Mon Oct 26 13:24:52 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A75304456BC for ; Mon, 26 Oct 2020 13:24:52 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CKbD43xtwz4GZk; Mon, 26 Oct 2020 13:24:52 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MBP-WLAN.fritz.box (p200300cd5f0bbc00cca8037de6f87d0d.dip0.t-ipconnect.de [IPv6:2003:cd:5f0b:bc00:cca8:37d:e6f8:7d0d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 1F0AE23464; Mon, 26 Oct 2020 13:24:52 +0000 (UTC) (envelope-from se@freebsd.org) To: FreeBSD CURRENT From: Stefan Esser Subject: Literal references to /usr/local in shell scripts Message-ID: Date: Mon, 26 Oct 2020 14:24:50 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 13:24:52 -0000 The following shell scripts (or configuration files parsed by a shell) contain literal references to /usr/local: libexec/rc/rc.conf # many variables libexec/rc/rc.shutdown # PATH component sys/conf/newvers.sh # search for svnversion, git, hg usr.bin/man/man.sh # man_default_path, config_local usr.sbin/autofs/autofs/include_ldap # path to ldapsearch usr.sbin/autofs/autofs/special_media # path to mount.exfat, ntfs-3g usr.sbin/bsdconfig/bsdconfig # BSDCFG_LOCAL_LIBE usr.sbin/certctl/certctl.sh # TRUSTPATH, BLACKLISTPATH usr.sbin/crashinfo/crashinfo.sh # path to gdb usr.sbin/periodic/periodic.conf # local_periodic variable On systems with non-default LOCALBASE these scripts need to be adjusted. In the case of rc.shutdown, for example, shutdown routines will not be executed for a LOCALBASE other then /usr/local. The rc.shutdown, autofs/*, certctl.sh, and crashinfo scripts will be run with root privileges and must not use an untrusted LOCALBASE value (but could refer to a sysctl variable). The same applies to the periodic script that relies on the local_periodic variable set in periodic.conf (but probably overridden in periodic.conf.local, if required). rc.conf could use a $LOCALBASE variable instead of literal values to construct paths to port/package provided files in order to not require that each value is modified in the systems /etc/rc.conf file - which will fail if new variables referring to /usr/local are introduced in the default configuration). The list of shell scripts checked excludes those in contrib, release, tests, and tools directories, since I think those will be used with default LOCALBASE, in general. From owner-freebsd-current@freebsd.org Tue Oct 27 08:17:07 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8121A442BC6 for ; Tue, 27 Oct 2020 08:17:07 +0000 (UTC) (envelope-from kozlov@ravenloft.kiev.ua) Received: from ravenloft.kiev.ua (ravenloft.kiev.ua [94.244.131.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CL4LW1zkDz4TVh; Tue, 27 Oct 2020 08:17:07 +0000 (UTC) (envelope-from kozlov@ravenloft.kiev.ua) Date: Tue, 27 Oct 2020 09:17:05 +0100 From: Alex Kozlov To: Stefan Esser Cc: freebsd-current@freebsd.org Subject: Re: Literal references to /usr/local in shell scripts Message-ID: <20201027081705.GA28065@ravenloft.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4CL4LW1zkDz4TVh X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; ASN(0.00)[asn:34743, ipnet:94.244.128.0/18, country:UA]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 08:17:07 -0000 On Mon, Oct 26, 2020 at 02:24:50PM +0100, Stefan Esser wrote: > The following shell scripts (or configuration files parsed by a > shell) contain literal references to /usr/local: > > libexec/rc/rc.conf # many variables > libexec/rc/rc.shutdown # PATH component > > sys/conf/newvers.sh # search for svnversion, git, hg > > usr.bin/man/man.sh # man_default_path, config_local > > usr.sbin/autofs/autofs/include_ldap # path to ldapsearch > usr.sbin/autofs/autofs/special_media # path to mount.exfat, ntfs-3g > usr.sbin/bsdconfig/bsdconfig # BSDCFG_LOCAL_LIBE > usr.sbin/certctl/certctl.sh # TRUSTPATH, BLACKLISTPATH > usr.sbin/crashinfo/crashinfo.sh # path to gdb > usr.sbin/periodic/periodic.conf # local_periodic variable > > On systems with non-default LOCALBASE these scripts need to be > adjusted. I've one 12.x system with PREFIX/LOCALBASE = /usr/pkg. This is what I'd to change: rc.conf: local_startup ldconfig_paths ldconfig_local_dirs, set $MANPATH, $PATH periodic.conf: local_periodic All these regressions needs to be fixed of course. Thanks for tacking this. > In the case of rc.shutdown, for example, shutdown routines will > not be executed for a LOCALBASE other then /usr/local. > > The rc.shutdown, autofs/*, certctl.sh, and crashinfo scripts will > be run with root privileges and must not use an untrusted LOCALBASE > value (but could refer to a sysctl variable). The same applies to > the periodic script that relies on the local_periodic variable set > in periodic.conf (but probably overridden in periodic.conf.local, > if required). > > rc.conf could use a $LOCALBASE variable instead of literal values > to construct paths to port/package provided files in order to not > require that each value is modified in the systems /etc/rc.conf > file - which will fail if new variables referring to /usr/local > are introduced in the default configuration). > > The list of shell scripts checked excludes those in contrib, release, tests, > and tools directories, since I think those will be used with > default LOCALBASE, in general. -- Alex From owner-freebsd-current@freebsd.org Fri Oct 30 00:54:28 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 514534432FB for ; Fri, 30 Oct 2020 00:54:28 +0000 (UTC) (envelope-from samy.mahmoudi@gmail.com) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CMkNM29mSz4ZXK for ; Fri, 30 Oct 2020 00:54:26 +0000 (UTC) (envelope-from samy.mahmoudi@gmail.com) Received: by mail-pl1-x631.google.com with SMTP id p17so2123456pli.13 for ; Thu, 29 Oct 2020 17:54:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZT/HOS0i1Sg1gtLMdGrgmyBmRRZaAOETqCKGE8uOPj8=; b=O9Mm8n3VvNZtbdNDvFFTgkbZXDOeJJsrlNzFRCmgLiYacolhIfbCkbWAdvy8j17Mq+ YG2bcHa2k8RK1+H62KTakmFofVa/dSZxy7yNnVcDv+s0+TseK+KK3SjRG4iCtqs1rxDu slHkp/iw9OTcjCtDW82VT2er4XhUqhdnNcJT/GKHNyDHhDvGvMF6nl22jxkzHZ0NWz/s 5ZlMvMmcpCAI2+v0fNEbz4pSTXg28r7+c89KiYZIb/3vuswhroJY0IeM2xgpfA9/tdCB CvfnciiDhWY+F9S5+RV+75j5Zc6FUAfRK3WzBeIE1//tF8JvlDslj6/6k+6rIyiH6RVV aSAQ== X-Gm-Message-State: AOAM531y41bQhsb4fQvwPb+XPb0QvKoIe0ZzvZsNf0H6XSJteVtReFAQ rA+qHzfsOHUpDkIrWWI7a9+teS+eNuN2bg76NFJ5pRFIwQiVAQ== X-Google-Smtp-Source: ABdhPJx4i8kSgwMyxGUHUyKerTZmXqS+lZ9p6EmAVePCNQlO4kMNGxXEQQSkYfAOn8sdMwqF2VB0o8aG3dDvunDU2Ts= X-Received: by 2002:a17:902:b192:b029:d2:f08:f85a with SMTP id s18-20020a170902b192b02900d20f08f85amr6476944plr.49.1604019265102; Thu, 29 Oct 2020 17:54:25 -0700 (PDT) MIME-Version: 1.0 References: <20201025.145205.2130959911090091593.yasu@utahime.org> In-Reply-To: <20201025.145205.2130959911090091593.yasu@utahime.org> From: Samy Mahmoudi Date: Thu, 29 Oct 2020 20:54:13 -0400 Message-ID: Subject: Re: Building packages with poudriere fails after `zfs upgrade` To: Yasuhiro KIMURA Cc: FreeBSD CURRENT X-Rspamd-Queue-Id: 4CMkNM29mSz4ZXK X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.05 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-0.98)[-0.982]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.02)[-1.022]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::631:from]; NEURAL_HAM_SHORT(-1.04)[-1.041]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 00:54:28 -0000 Hi, Have you tried to work around the issue by creating a new jail with poudriere, or even by changing the value of ZROOTFS in poudriere.conf ? Best regards, Samy Mahmoudi From owner-freebsd-current@freebsd.org Fri Oct 30 03:13:08 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EC7CC4461F9 for ; Fri, 30 Oct 2020 03:13:08 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CMnSM5lTKz4hTW for ; Fri, 30 Oct 2020 03:13:07 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.229.168]) by shaw.ca with ESMTPA id YKqdkYSCfRAWfYKqeka8KM; Thu, 29 Oct 2020 21:13:05 -0600 X-Authority-Analysis: v=2.4 cv=P9aEOgMu c=1 sm=1 tr=0 ts=5f9b84c1 a=7AlCcx2GqMg+lh9P3BclKA==:117 a=7AlCcx2GqMg+lh9P3BclKA==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=afefHYAZSVUA:10 a=RgBw9RmQAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=CX2mE1owdtc5oVmwsNcA:9 a=CjuIK1q_8ugA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 a=pHzHmUro8NiASowvMSCR:22 a=6VlIyEUom7LUIeUMNQJH:22 Received: from slippy.cwsent.com (slippy [IPv6:fc00:1:1:1::5b]) by spqr.komquats.com (Postfix) with ESMTPS id 21EF4470; Thu, 29 Oct 2020 20:13:02 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.16.1/8.16.1) with ESMTP id 09U3D0KZ006216; Thu, 29 Oct 2020 20:13:01 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202010300313.09U3D0KZ006216@slippy.cwsent.com> X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: qroxana cc: freebsd-current@freebsd.org Subject: Re: OpenZFS: kldload zfs.ko freezes on i386 4GB memory In-reply-to: References: Comments: In-reply-to qroxana message dated "Mon, 26 Oct 2020 05:47:09 -0000." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 Oct 2020 20:13:00 -0700 X-CMAE-Envelope: MS4xfOWqBOFaVDjZkRpo404mf8bfdCxw3EUBxdFr8FeKjmKuAS1G3qjhYy5xFfQ45x9xRf4i2qsAD9ZorskjVm/dcdwk/eDuTK0ilct/slnRRJNEdCSVcx1T GMxckf0MwkKy7/iwOd84hd2jp0I3ToPdOYJ5fDLTTWQ+v/Rxuc//Ju+De3QL+aHp1UNlkoE3QwqCU+RSHjpdDxkLiGL5PyVIOV14nk/sorw/n+4mjbbItlo4 X-Rspamd-Queue-Id: 4CMnSM5lTKz4hTW X-Spamd-Bar: / X-Spamd-Result: default: False [-0.23 / 15.00]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[4]; NEURAL_HAM_SHORT(-0.13)[-0.131]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[mail.ru]; RECEIVED_SPAMHAUS_PBL(0.00)[70.67.229.168:received]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_LOW(-0.10)[64.59.136.138:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.84)[-0.838]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.56)[-0.559]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[no SPF record]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 03:13:09 -0000 In message , qroxana writes : > > Hi, > > I have an old i386 machine running r364479. After upgrading to > r367045, running kldload zfs.ko freezes the whole system. > > I also tried to replace the 4GB memory with another 2GB one > and kldload zfs.ko works without freezing the machine. ZFS ARC stresses memory. I've found a number of bad RAM chips over the years using ZFS. The OpenZFS upgrade significantly changed how it manages ARC. It's likely that prior to the OpenZFS upgrade your memory wasn't stressed to the point of failure. You can try to mask the problem by reducing your RAM clock rate or or increase one of the other latency settings in your BIOS. However, again, this only masks an already weak RAM chip. Like everything, RAM does age over its lifetime. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Fri Oct 30 12:37:54 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 51684451A1B for ; Fri, 30 Oct 2020 12:37:54 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4CN2020np7z3g5j for ; Fri, 30 Oct 2020 12:37:54 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.nyi.freebsd.org (Postfix) id 1B330451A1A; Fri, 30 Oct 2020 12:37:54 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1AF674519C2 for ; Fri, 30 Oct 2020 12:37:54 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (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 4CN2006315z3g86 for ; Fri, 30 Oct 2020 12:37:52 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 09UCbiCR063633 for ; Fri, 30 Oct 2020 12:37:44 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 09UCbiNt063632 for current@freebsd.org; Fri, 30 Oct 2020 05:37:44 -0700 (PDT) (envelope-from david) Date: Fri, 30 Oct 2020 05:37:44 -0700 From: David Wolfskill To: current@freebsd.org Subject: "panic: page fault" in iwn signal handler(?) at r367127 Message-ID: <20201030123744.GT1430@albert.catwhisker.org> Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="o9qiPLpykPxkk5uk" Content-Disposition: inline X-Rspamd-Queue-Id: 4CN2006315z3g86 X-Spamd-Bar: / X-Spamd-Result: default: False [0.69 / 15.00]; HAS_REPLYTO(0.00)[current@freebsd.org]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[david]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.99)[-0.987]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_SHORT(0.07)[0.074]; DMARC_NA(0.00)[catwhisker.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US]; REPLYTO_EQ_TO_ADDR(5.00)[]; MAILMAN_DEST(0.00)[current]; SUBJECT_HAS_QUESTION(0.00)[] X-Spam: Yes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 12:37:54 -0000 --o9qiPLpykPxkk5uk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've copied the dump and core.txt files to http://www.catwhisker.org/~david/FreeBSD/head/r367127/ Here's a copy/paste of the stack trace (from the core.txt.3 file): p 12: page fault while in kernel mode cpuid =3D 4; apic id =3D 04 fault virtual address =3D 0xfffff80840000000 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff80495f03 stack pointer =3D 0x0:0xffffffff8241d748 frame pointer =3D 0x0:0xffffffff8241d7a0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 12 (irq36: iwn0) trap number =3D 12 panic: page fault cpuid =3D 4 time =3D 1604056852 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff804a69db =3D db_trace_self_wrapper+0x2= b/frame 0xffffffff8241d3f0 vpanic() at 0xffffffff80baf802 =3D vpanic+0x182/frame 0xffffffff8241d440 panic() at 0xffffffff80baf5c3 =3D panic+0x43/frame 0xffffffff8241d4a0 trap_fatal() at 0xffffffff8102c2f7 =3D trap_fatal+0x387/frame 0xffffffff824= 1d500 trap_pfault() at 0xffffffff8102c397 =3D trap_pfault+0x97/frame 0xffffffff82= 41d560 trap() at 0xffffffff8102b98b =3D trap+0x2ab/frame 0xffffffff8241d670 calltrap() at 0xffffffff80fffa08 =3D calltrap+0x8/frame 0xffffffff8241d670 --- trap 0xc, rip =3D 0xffffffff80495f03, rsp =3D 0xffffffff8241d748, rbp = =3D 0xffffffff8241d7a0 --- rijndaelEncrypt() at 0xffffffff80495f03 =3D rijndaelEncrypt+0x233/frame 0xf= fffffff8241d7a0 ccmp_decap() at 0xffffffff80d08bc1 =3D ccmp_decap+0x421/frame 0xffffffff824= 1d8b0 ieee80211_crypto_decap() at 0xffffffff80d07955 =3D ieee80211_crypto_decap+0= x125/frame 0xffffffff8241d900 sta_input() at 0xffffffff80d41dec =3D sta_input+0x43c/frame 0xffffffff8241d= 9a0 iwn_notif_intr() at 0xffffffff8069949c =3D iwn_notif_intr+0x137c/frame 0xff= ffffff8241dab0 iwn_intr() at 0xffffffff8068f4f8 =3D iwn_intr+0x2b8/frame 0xffffffff8241db20 ithread_loop() at 0xffffffff80b6dbb9 =3D ithread_loop+0x279/frame 0xfffffff= f8241dbb0 fork_exit() at 0xffffffff80b6a690 =3D fork_exit+0x80/frame 0xffffffff8241db= f0 fork_trampoline() at 0xffffffff81000a5e =3D fork_trampoline+0xe/frame 0xfff= fffff8241dbf0 --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- KDB: enter: panic __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 55 __asm("movq %%gs:%P1,%0" : "=3Dr" (td) : "n" (offsetof(struct pcpu, (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 #1 doadump (textdump=3D0) at /usr/src/sys/kern/kern_shutdown.c:394 #2 0xffffffff804a3cea in db_dump (dummy=3D,=20 dummy2=3D, dummy3=3D, dummy4=3D) at /usr/src/sys/ddb/db_command.c:575 #3 0xffffffff804a3ab0 in db_command (last_cmdp=3D,=20 cmd_table=3D, dopager=3D1) at /usr/src/sys/ddb/db_comman= d.c:482 #4 0xffffffff804a380d in db_command_loop () at /usr/src/sys/ddb/db_command.c:535 #5 0xffffffff804a6b26 in db_trap (type=3D, code=3D) at /usr/src/sys/ddb/db_main.c:270 #6 0xffffffff80bfb5c4 in kdb_trap (type=3D3, code=3D0, tf=3D) at /usr/src/sys/kern/subr_kdb.c:699 #7 0xffffffff8102be9e in trap (frame=3D0xffffffff8241d320) at /usr/src/sys/amd64/amd64/trap.c:576 #8 #9 kdb_enter (why=3D0xffffffff8120d701 "panic", msg=3D) at /usr/src/sys/kern/subr_kdb.c:486 #10 0xffffffff80baf81e in vpanic (fmt=3D, ap=3D) at /usr/src/sys/kern/kern_shutdown.c:901 #11 0xffffffff80baf5c3 in panic ( fmt=3D0xffffffff81c79aa8 "\362\357\034\201\377\377\377\377= ") at /usr/src/sys/kern/kern_shutdown.c:838 #12 0xffffffff8102c2f7 in trap_fatal (frame=3D0xffffffff8241d680,=20 eva=3D18446735313050009600) at /usr/src/sys/amd64/amd64/trap.c:915 #13 0xffffffff8102c397 in trap_pfault (frame=3D0xffffffff8241d680,=20 usermode=3D, signo=3D, ucode=3D) at /usr/src/sys/amd64/amd64/trap.c:732 #14 0xffffffff8102b98b in trap (frame=3D0xffffffff8241d680) at /usr/src/sys/amd64/amd64/trap.c:398 #15 #16 rijndaelEncrypt (rk=3D, Nr=3D,=20 pt=3D,=20 ct=3D0xffffffff8241d830 "\277\243\ff\211\335\330\v5\234\035{\210\330\32= 0\327Fe\235>\226\026\025c\266n\325\305\205]\251%\001\002\004\030\326!\"\037= ") at /usr/src/sys/crypto/rijndael/rijndael-alg-fst.c:1000 #17 0xffffffff80d08bc1 in ccmp_decrypt (key=3D0xfffffe106978a160, pn=3D2562= 7,=20 m=3D0xfffff8010ffc9b00, hdrlen=3D) at /usr/src/sys/net80211/ieee80211_crypto_ccmp.c:623 #18 ccmp_decap (k=3D, m=3D, hdrlen=3D) at /usr/src/sys/net80211/ieee80211_crypto_ccmp.c:284 #19 0xffffffff80d07955 in ieee80211_crypto_decap (ni=3D,=20 m=3D0xfffff8010ffc9b00, hdrlen=3D26, key=3D0xffffffff8241d920) at /usr/src/sys/net80211/ieee80211_crypto.c:684 #20 0xffffffff80d41dec in sta_input (ni=3D,=20 m=3D0xfffff8010ffc9b00, rxs=3D, rssi=3D,= =20 nf=3D) at /usr/src/sys/net80211/ieee80211_sta.c:773 #21 0xffffffff8069949c in iwn_rx_done (sc=3D0xfffffe1033319000,=20 desc=3D, data=3D) at /usr/src/sys/dev/iwn/if_iwn.c:3191 #22 iwn_notif_intr (sc=3D) at /usr/src/sys/dev/iwn/if_iwn.c:= 4018 #23 0xffffffff8068f4f8 in iwn_intr (arg=3D0xfffffe1033319000) at /usr/src/sys/dev/iwn/if_iwn.c:4337 #24 0xffffffff80b6dbb9 in intr_event_execute_handlers (p=3D,= =20 ie=3D0xfffff8000c52b300) at /usr/src/sys/kern/kern_intr.c:1168 #25 ithread_execute_handlers (p=3D, ie=3D0xfffff8000c52b300) at /usr/src/sys/kern/kern_intr.c:1181 #26 ithread_loop (arg=3D) at /usr/src/sys/kern/kern_intr.c:1= 269 #27 0xffffffff80b6a690 in fork_exit ( callout=3D0xffffffff80b6d940 , arg=3D0xfffff8000d18ef00,= =20 frame=3D0xffffffff8241dc00) at /usr/src/sys/kern/kern_fork.c:1052 #28 (kgdb)=20 This happened while my laptop was running: FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #43 r367127M= /367127: Thu Oct 29 05:52:40 PDT 2020 root@g1-55.catwhisker.org:/common= /S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 1300123 1300123 during the "make buildkernel" phase of an in-place source update to r367160. As often happens while I'm running head, there was an "iwn firmware panic" (see, e.g., https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214435); record of it may be found in /var/log/messages, starting around: <2>1 2020-10-30T11:05:07.327958+00:00 g1-55.catwhisker.org kernel - - - Exp= ensive timeout(9) function: 0xffffffff80d8d2f0(0xfffffe1067a408f0) 0.840172= 647 s <2>1 2020-10-30T11:07:36.367805+00:00 g1-55.catwhisker.org kernel - - - iwn= 0: iwn_intr: fatal firmware error <2>1 2020-10-30T11:07:36.367830+00:00 g1-55.catwhisker.org kernel - - - fir= mware error log: <2>1 2020-10-30T11:07:36.367839+00:00 g1-55.catwhisker.org kernel - - - e= rror type =3D "UNKNOWN" (0x0000001D) and the "WiFi" LED on the laptop went dark. As I was trying to do some work on another machine (while logged in to that machine from the laptop), the loss of connectivity was ... disruptive. While I was mildly gratified that (this time) the "make buildkernel" appeared to be proceeding despite the iwn(4) issue(s), I also wanted to get back to what I was doing. So after a few minutes -- when it became apparent that the link wasn't being recovered on its own -- I switched from X11 to vty1 (to leave vty0 for console messages), logged in as root, and issued: service netif restart wlan0 after a couple of minutes (during which the "make buildkernel" was continuing), the "service netif restart wlan0" had not yet completed, so I sent it a SIGNIFO (via ^T), and (as I recall), it indocated that the process was invoking ifconfig, and there was some mention of a function whose name included "epoch". I resumed waiting; after another minute or so, I trued ^T again, and there appeared to be no progress. After waiting another 30 seconds or so, I tried to bail out via ^C; that appeared to be ineffective. So after waiting another 10 - 15 seconds or so, I tried backgrounding (^Z), followed by "kill %1". It was shortly after that the panic occurred. Which may well -- to some extent -- have been self-inflicted. That said, the iwn firmware panics are not something I can control (as far as I know -- please let me know how I can control them if I'm incoorrect on that score). For that matter, I have no particular attachment to this NIC -- I'm open to a suggestion for any NIC with the same (miniPCI) form factor that will work well with FreeBSD. Peace, david --=20 David H. Wolfskill david@catwhisker.org I have voted to fire Mr. Trump. With prejudice. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --o9qiPLpykPxkk5uk Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE4owz2QxMJyaxAefyQLJg+bY2PckFAl+cCRhfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEUy OEMzM0Q5MEM0QzI3MjZCMTAxRTdGMjQwQjI2MEY5QjYzNjNEQzkACgkQQLJg+bY2 PcnBFgf/dLnCOdOw5bR28O+ZOLpCfYll31Pv2Q8BVP+WAu2a09x52zvfIRQ9na7v Ov7EyiRv2RUOoe3V5ViefWayEJ5la7SyReCnRXuFs9UvedsVC9QYYjfD3z3WsWgF AO6RvIRaI7s2LC5QBcUqT5Q+W5WgUrYuEqDu/LoWAfPbiW7/0iG4Dy3R9VGQAgGj 5BbTljEPgGwYH9ntXPNgKmhWJQHEuwzsbR/COOur4clDr0fem4sq29FBtKqlLx9C vfYTYK99Rhtq4O5/uhyq4S1XqrAZ/X9vAH0FsLwHCqRGZek+0hYuwBEkonIoZ4+5 X7he/sJMGTMLVhli8GcoSmF+l6z2xQ== =Tk94 -----END PGP SIGNATURE----- --o9qiPLpykPxkk5uk-- From owner-freebsd-current@freebsd.org Fri Oct 30 18:27:02 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2A960458A02 for ; Fri, 30 Oct 2020 18:27:02 +0000 (UTC) (envelope-from aaronfarias@att.net) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4CN9ks5kscz4Kpr for ; Fri, 30 Oct 2020 18:27:01 +0000 (UTC) (envelope-from aaronfarias@att.net) Received: by mailman.nyi.freebsd.org (Postfix) id C2FBC458A01; Fri, 30 Oct 2020 18:27:01 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C2B854586E5 for ; Fri, 30 Oct 2020 18:27:01 +0000 (UTC) (envelope-from aaronfarias@att.net) Received: from sonic312-27.consmr.mail.gq1.yahoo.com (sonic312-27.consmr.mail.gq1.yahoo.com [98.137.69.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CN9ks1kFLz4L9n for ; Fri, 30 Oct 2020 18:27:00 +0000 (UTC) (envelope-from aaronfarias@att.net) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1604082419; bh=qaF4CBqtJY2eyCLqTGrVG26Ih/jOUw+i4Ud3dsBwX0D=; h=Subject:From:To:Date; b=QeTYfI8xlQatN4CedtoY7mRpcy21Ubx1yDEpUX2qFez9H/6HzcQXIn6b5z+lh9rQx0z1B9YhoudO3Pqe+K+JWI/VdZatOZtw6dSwI0Begpvt1gG9gFdgXG0QYCSo89NDwas6GqLppQ216D+DjmZTrfgXvXTKBp8UYNa1EQS6gWxy4PvoPl0CPAzDeJkdeEquaqpEsODs1hcBDYU4KPecR/3W+l79kZbAiPupDuySyDJICbhXmBPHGPJ0zr5p64AWYBJgJPaGE1MMs2lyS10WFKHnBryWUXa2WXiKBhUcOd8jY4OOdIR6piG7PSko9p4MwRcuWiwbevWh/CfguExMnA== X-YMail-OSG: cokQiKcVM1nOxlDcb27k5TLIcUBWani7rqbYgcuA5gQD1KOpnd2f7x1Y7mNrkPK r.FSZl1M4bePoil64nisN78oSLZk6TgyN353YGH0MY9ZchuFKE_9iaE18rhqWiADgSCqk4sUfrRh vjc3mzpY67iExHtbjUYIJESUrzcnsMhV2VSFAOXwwUoagCCP1bPiJbI_4Gmh2NyyHDyZ9rxnjYD8 q0QNbU0pMb.p6xMWNKC1e41GQIIiqLG9xw9jmKQcdqkrVgZ3bc0q2XPw4O4Xx_aVq0v5.MJnxwYI C5hWrZHHwv9W7ACfphRZL.F8BFgMVvCjigXZFbmk.OB3cNVl7.DL4RbOps1OX2JWOFA.Dp.culgX b3gHmQja9K00vHWHPrgjuDm3b7jW6yDOyFG5A7ubMcEfuXgjc0D79Le5Ul3ntos6wYfnPdqmSBD0 GTpMh459VCVJSV69cmb_lHbSVkKxNMqQLCgErRARP5VCsteATvoyfc1pTSY60mm7T9RryI_OkgY8 QKIUZf5NPaM7OdtJ5eOZNK4Jm0RxOCVQzfQN9l2PQc3NsAZ.C6ZRAmdxsLji2pssBdXSPx1xVJU5 RYTGVH0xavQtVHYA_VgFunpOubWyOqRf88MzRw1xWzESO1klaFhsJ1IXy53tbbWgY5r2MPvYb8I7 mJzX05MTpXi8RoFYat9f5FMk5MjKzYmDOFtKrwqkD4BKVpBGGKcS0QHo5f6dHj6Aru8_iu79RAF1 F9y2BfhLVRJvAQL_Lg6KfufVNZL.qtszxhiqiEXHYpt1b7xc3p5tmA5XG7zb7anIeJ7iNWqszwMq B9Z5D8Ikv1hBHVGCZtMEczogrkLSOp.oSktp7rdm4QEot8jJFQR7sfo3CYF8NA_kPgs43hJPbLz5 eG5tTt4vCfYaYzAFzrId_V3SA1.MxVUrVn4NLVC2hig8A_M13OMtO3TLG5sQ78otd7UxOaeiTGxo m9yLgeej2UdI2M3KLVlR12amPZz5qhdSh22a6aKyzVN5t7u2MfMjM3LbIJ1dpvOvr5Tm0ATK6k.b qffMKOLasq_kz.cxUKqWBI9pGj3ByHlCPqgGaZfPAxNgGKDyH2tV8gLPqvh0g6U7dFcSPsh9bTZA OlXnV285mRVlFPyxu3xjVcbEyQm329xbu6mQA3gzcT2DJstp9M8rvzFgLSkporF4nMgdjGmer45X kIR06uvn0b067peTijzccEMDfxIfFsfH.NuPJXu2bE.9TbAfQ8FdZCvmv3dsx9ox11HQkf2u5dag 2ljsd1zkn1cGMkABsfKZ_kOvCnJomGfWESVTqCAeDh7yJeImVp.Z0yMGkv5VlI0IM50_ULim1t0n U_ltGXMQ5Y64tRWdiaoj_5dlxsA4r83Togx_Y4dRhgAmQ2qlzmoiPA6HNHgyxF5DCuFhpRm.G8gj ZkKOaF7HPkz0Frx8prLwpbUdkIXuRHH2L5xmlVJKvxDl5JpOpVCgLVH1Cl7oDxKdSy2NXPL4kJfe HFUZes3D34YmDK0Wb7mlQwU9nzUekDVW8Um7qfxMIxjA7AKMp1.R2pAFpIK1mE.uorxXH9ah8yT_ iIMAOOWLOtfCCCJ5XDot1O48_PKv7HKHVnhTabSbv1uDAlRA_F0AjAaBjQnBjsgxeMHCxyZOOIqE 9bqVlGClwjmDyF6hgnUoBVjEHKoc3HKyQouoOWD0MIC.qoQF0zjv63cGtD_Feq8XnDfoU0TjUqXP 9OWUYRo5PmGyBy2RQPiVtFY8ECdAUYOewPMVkKBrY6FSgPvMEri6Cr9aCJXNJHsyZoZNJFCZ_YFm UPMjkFxfm945LwFPgXEtiUXy0HCYu7qhvUG1DtXvIAztzWYLfMVFCSBFXJw3GmS6UtoxTwDx6_HQ MClT0deK8jhbz7n_MBcl2jwD0vpvBmrssKKjmL1kvt3_ahs0fqTIqSXeSqm.BczWQtE.f.J369ts 7UByQQSJ9mDwUXKGblNhFpdhgpxKwnep1Nt.NZCuLSA3F64ufhxN8FREMXanZ677Ep54Bx0VRNQz OvHE8EJBArxZw9WQwHiVdet5TLrlqdc7jsS6twtiDddAhlwhTDbKao8Ngz77.zkkNegboh85BH2D uroHF0WHMOsO4q6N_erqR5Nd8rjc5Mth8MGtTPRkUrQY4zScGcYRAO0FBGsL9Cb7YwWPV69EdoJU kahQzYfGy1.EGW07TGwcq2uhbjnfqG0C_7uLFPUC1n8c3AHwpnBEaEfEhgCF7U.dLhpqhcN3dv9R kvQlmLfvM7I3FLeExmzjkMFbHHVFOlay1guy4XRlezE4eH82FEgeWT_GnL_X3GCtBoLRe3FDIROg bbmx_nRqiDwKByzD9jMzVawFz0doqmsvzM8MkWO0rWgA30aL3SoS7lrADAAogkdc4k.Tdsvniw2M B2bRbIr5aZ8bCaa1Y3lpmdagQDBHpAGf8Fs8DrsRNbXyC6hnWMc_bWJtFmVQmVKHlIp9hdpNbZLe tnDaAJuLuaX_Sreq5_sHje4OFgVHeajRG2qYnSwnhd27ayUzNjhrz_Dj6758231cvQMTeroXtptE SBwt3rbX0u_xOonI8gujixjlq8mlgpSd29teIhhRpLR8q_MLYkd8SY3rp_zUXDbMcp3d99yu5w3. 25rI6.5U.3c6xPEMI2xNa Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Fri, 30 Oct 2020 18:26:59 +0000 Received: by smtp403.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 955b8e3e7c52467939857e66857a7bf4; Fri, 30 Oct 2020 18:26:55 +0000 (UTC) Message-ID: <503577abda2d455126c6639de9c5faea88bc413d.camel@ubuntu.com> Subject: Re: "panic: page fault" in iwn signal handler(?) at r367127 From: Aaron H Farias Martinez To: current@freebsd.org Date: Fri, 30 Oct 2020 14:26:53 -0400 In-Reply-To: <20201030123744.GT1430@albert.catwhisker.org> References: <20201030123744.GT1430@albert.catwhisker.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.0 FreeBSD GNOME Team MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.16944 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) X-Rspamd-Queue-Id: 4CN9ks1kFLz4L9n 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-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 18:27:02 -0000 On Fri, 2020-10-30 at 05:37 -0700, David Wolfskill wrote: > I've copied the dump and core.txt files to > http://www.catwhisker.org/~david/FreeBSD/head/r367127/ >=20 > Here's a copy/paste of the stack trace (from the core.txt.3 file): > p 12: page fault while in kernel mode > cpuid =3D 4; apic id =3D 04 > fault virtual address =3D 0xfffff80840000000 > fault code=C2=A0 =3D supervisor read data, page not present > instruction pointer =3D 0x20:0xffffffff80495f03 > stack pointer=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D 0x0:0xf= fffffff8241d748 > frame pointer=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D 0x0:0xf= fffffff8241d7a0 > code segment=C2=A0 =3D base 0x0, limit 0xfffff, type 0x1b > =C2=A0=C2=A0 =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process=C2=A0 =3D 12 (irq36: iwn0) > trap number=C2=A0 =3D 12 > panic: page fault > cpuid =3D 4 > time =3D 1604056852 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff804a69db =3D > db_trace_self_wrapper+0x2b/frame 0xffffffff8241d3f0 > vpanic() at 0xffffffff80baf802 =3D vpanic+0x182/frame > 0xffffffff8241d440 > panic() at 0xffffffff80baf5c3 =3D panic+0x43/frame 0xffffffff8241d4a0 > trap_fatal() at 0xffffffff8102c2f7 =3D trap_fatal+0x387/frame > 0xffffffff8241d500 > trap_pfault() at 0xffffffff8102c397 =3D trap_pfault+0x97/frame > 0xffffffff8241d560 > trap() at 0xffffffff8102b98b =3D trap+0x2ab/frame 0xffffffff8241d670 > calltrap() at 0xffffffff80fffa08 =3D calltrap+0x8/frame > 0xffffffff8241d670 > --- trap 0xc, rip =3D 0xffffffff80495f03, rsp =3D 0xffffffff8241d748, rbp > =3D 0xffffffff8241d7a0 --- > rijndaelEncrypt() at 0xffffffff80495f03 =3D rijndaelEncrypt+0x233/frame > 0xffffffff8241d7a0 > ccmp_decap() at 0xffffffff80d08bc1 =3D ccmp_decap+0x421/frame > 0xffffffff8241d8b0 > ieee80211_crypto_decap() at 0xffffffff80d07955 =3D > ieee80211_crypto_decap+0x125/frame 0xffffffff8241d900 > sta_input() at 0xffffffff80d41dec =3D sta_input+0x43c/frame > 0xffffffff8241d9a0 > iwn_notif_intr() at 0xffffffff8069949c =3D iwn_notif_intr+0x137c/frame > 0xffffffff8241dab0 > iwn_intr() at 0xffffffff8068f4f8 =3D iwn_intr+0x2b8/frame > 0xffffffff8241db20 > ithread_loop() at 0xffffffff80b6dbb9 =3D ithread_loop+0x279/frame > 0xffffffff8241dbb0 > fork_exit() at 0xffffffff80b6a690 =3D fork_exit+0x80/frame > 0xffffffff8241dbf0 > fork_trampoline() at 0xffffffff81000a5e =3D fork_trampoline+0xe/frame > 0xffffffff8241dbf0 > --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- > KDB: enter: panic >=20 > __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 > 55=C2=A0 __asm("movq %%gs:%P1,%0" : "=3Dr" (td) : "n" (offsetof(struct pc= pu, > (kgdb) #0=C2=A0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:5= 5 > #1=C2=A0 doadump (textdump=3D0) at /usr/src/sys/kern/kern_shutdown.c:394 > #2=C2=A0 0xffffffff804a3cea in db_dump (dummy=3D,=20 > =C2=A0=C2=A0=C2=A0 dummy2=3D, dummy3=3D, > dummy4=3D) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/ddb/db_command.c:575 > #3=C2=A0 0xffffffff804a3ab0 in db_command (last_cmdp=3D,= =20 > =C2=A0=C2=A0=C2=A0 cmd_table=3D, dopager=3D1) at > /usr/src/sys/ddb/db_command.c:482 > #4=C2=A0 0xffffffff804a380d in db_command_loop () > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/ddb/db_command.c:535 > #5=C2=A0 0xffffffff804a6b26 in db_trap (type=3D, > code=3D) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/ddb/db_main.c:270 > #6=C2=A0 0xffffffff80bfb5c4 in kdb_trap (type=3D3, code=3D0, tf=3D out>) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/kern/subr_kdb.c:699 > #7=C2=A0 0xffffffff8102be9e in trap (frame=3D0xffffffff8241d320) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/amd64/amd64/trap.c:576 > #8=C2=A0 > #9=C2=A0 kdb_enter (why=3D0xffffffff8120d701 "panic", msg=3D) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/kern/subr_kdb.c:486 > #10 0xffffffff80baf81e in vpanic (fmt=3D, ap=3D out>) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/kern/kern_shutdown.c:901 > #11 0xffffffff80baf5c3 in panic ( > =C2=A0=C2=A0=C2=A0 fmt=3D0xffffffff81c79aa8 > "\362\357\034\201\377\377\377\377") > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/kern/kern_shutdown.c:838 > #12 0xffffffff8102c2f7 in trap_fatal (frame=3D0xffffffff8241d680,=20 > =C2=A0=C2=A0=C2=A0 eva=3D18446735313050009600) at /usr/src/sys/amd64/amd6= 4/trap.c:915 > #13 0xffffffff8102c397 in trap_pfault (frame=3D0xffffffff8241d680,=20 > =C2=A0=C2=A0=C2=A0 usermode=3D, signo=3D, u= code=3D out>) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/amd64/amd64/trap.c:732 > #14 0xffffffff8102b98b in trap (frame=3D0xffffffff8241d680) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/amd64/amd64/trap.c:398 > #15 > #16 rijndaelEncrypt (rk=3D, Nr=3D,=20 > =C2=A0=C2=A0=C2=A0 pt=3D,=20 > =C2=A0=C2=A0=C2=A0 ct=3D0xffffffff8241d830 > "\277\243\ff\211\335\330\v5\234\035{\210\330\320\327Fe\235>\226\026\0 > 25c\266n\325\305\205]\251%\001\002\004\030\326!\"\037") > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/crypto/rijndael/rijndael-alg-fst.c:100= 0 > #17 0xffffffff80d08bc1 in ccmp_decrypt (key=3D0xfffffe106978a160, > pn=3D25627,=20 > =C2=A0=C2=A0=C2=A0 m=3D0xfffff8010ffc9b00, hdrlen=3D) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/net80211/ieee80211_crypto_ccmp.c:623 > #18 ccmp_decap (k=3D, m=3D, > hdrlen=3D) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/net80211/ieee80211_crypto_ccmp.c:284 > #19 0xffffffff80d07955 in ieee80211_crypto_decap (ni=3D, > =C2=A0=C2=A0=C2=A0 m=3D0xfffff8010ffc9b00, hdrlen=3D26, key=3D0xffffffff8= 241d920) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/net80211/ieee80211_crypto.c:684 > #20 0xffffffff80d41dec in sta_input (ni=3D,=20 > =C2=A0=C2=A0=C2=A0 m=3D0xfffff8010ffc9b00, rxs=3D, rssi=3D= ,=20 > =C2=A0=C2=A0=C2=A0 nf=3D) at /usr/src/sys/net80211/ieee802= 11_sta.c:773 > #21 0xffffffff8069949c in iwn_rx_done (sc=3D0xfffffe1033319000,=20 > =C2=A0=C2=A0=C2=A0 desc=3D, data=3D) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/dev/iwn/if_iwn.c:3191 > #22 iwn_notif_intr (sc=3D) at > /usr/src/sys/dev/iwn/if_iwn.c:4018 > #23 0xffffffff8068f4f8 in iwn_intr (arg=3D0xfffffe1033319000) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/dev/iwn/if_iwn.c:4337 > #24 0xffffffff80b6dbb9 in intr_event_execute_handlers (p=3D out>,=20 > =C2=A0=C2=A0=C2=A0 ie=3D0xfffff8000c52b300) at /usr/src/sys/kern/kern_int= r.c:1168 > #25 ithread_execute_handlers (p=3D, > ie=3D0xfffff8000c52b300) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/kern/kern_intr.c:1181 > #26 ithread_loop (arg=3D) at > /usr/src/sys/kern/kern_intr.c:1269 > #27 0xffffffff80b6a690 in fork_exit ( > =C2=A0=C2=A0=C2=A0 callout=3D0xffffffff80b6d940 , > arg=3D0xfffff8000d18ef00,=20 > =C2=A0=C2=A0=C2=A0 frame=3D0xffffffff8241dc00) at /usr/src/sys/kern/kern_= fork.c:1052 > #28 > (kgdb)=20 >=20 >=20 > This happened while my laptop was running: > FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #43 > r367127M/367127: Thu Oct 29 05:52:40 PDT 2020=C2=A0=C2=A0=C2=A0=C2=A0 > root@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANA > RY=C2=A0 amd64 1300123 1300123 >=20 > during the "make buildkernel" phase of an in-place source update to > r367160. >=20 > As often happens while I'm running head, there was an "iwn firmware > panic" (see, e.g., > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214435); record of > it > may be found in /var/log/messages, starting around: >=20 > <2>1 2020-10-30T11:05:07.327958+00:00 g1-55.catwhisker.org kernel - - > - Expensive timeout(9) function: > 0xffffffff80d8d2f0(0xfffffe1067a408f0) 0.840172647 s > <2>1 2020-10-30T11:07:36.367805+00:00 g1-55.catwhisker.org kernel - - > - iwn0: iwn_intr: fatal firmware error > <2>1 2020-10-30T11:07:36.367830+00:00 g1-55.catwhisker.org kernel - - > - firmware error log: > <2>1 2020-10-30T11:07:36.367839+00:00 g1-55.catwhisker.org kernel - - > -=C2=A0=C2=A0 error type=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D "UNKNOWN" (0x0= 000001D) >=20 >=20 > and the "WiFi" LED on the laptop went dark.=C2=A0 As I was trying to do > some work on another machine (while logged in to that machine from > the > laptop), the loss of connectivity was ... disruptive.=C2=A0 While I was > mildly gratified that (this time) the "make buildkernel" appeared to > be > proceeding despite the iwn(4) issue(s), I also wanted to get back to > what I was doing. >=20 > So after a few minutes -- when it became apparent that the link > wasn't > being recovered on its own -- I switched from X11 to vty1 (to leave > vty0 > for console messages), logged in as root, and issued: >=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0service netif restart wla= n0 >=20 > after a couple of minutes (during which the "make buildkernel" was > continuing), the "service netif restart wlan0" had not yet completed, > so > I sent it a SIGNIFO (via ^T), and (as I recall), it indocated that > the > process was invoking ifconfig, and there was some mention of a > function > whose name included "epoch". >=20 > I resumed waiting; after another minute or so, I trued ^T again, and > there appeared to be no progress. >=20 > After waiting another 30 seconds or so, I tried to bail out via ^C; > that > appeared to be ineffective.=C2=A0 So after waiting another 10 - 15 second= s > or > so, I tried backgrounding (^Z), followed by "kill %1". >=20 > It was shortly after that the panic occurred.=C2=A0 Which may well -- to > some > extent -- have been self-inflicted.=C2=A0 That said, the iwn firmware > panics > are not something I can control (as far as I know -- please let me > know > how I can control them if I'm incoorrect on that score).=C2=A0 For that > matter, I have no particular attachment to this NIC -- I'm open to a > suggestion for any NIC with the same (miniPCI) form factor that will > work well with FreeBSD. >=20 > Peace, > david I got the same issue. From owner-freebsd-current@freebsd.org Fri Oct 30 18:28:09 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4A96F45896E for ; Fri, 30 Oct 2020 18:28:09 +0000 (UTC) (envelope-from aaronfarias@att.net) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4CN9m90MfPz4LNP for ; Fri, 30 Oct 2020 18:28:09 +0000 (UTC) (envelope-from aaronfarias@att.net) Received: by mailman.nyi.freebsd.org (Postfix) id 0C7E0458AA1; Fri, 30 Oct 2020 18:28:09 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0C3F8458B1B for ; Fri, 30 Oct 2020 18:28:09 +0000 (UTC) (envelope-from aaronfarias@att.net) Received: from sonic309-24.consmr.mail.gq1.yahoo.com (sonic309-24.consmr.mail.gq1.yahoo.com [98.137.65.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CN9m81zJ8z4LNN for ; Fri, 30 Oct 2020 18:28:08 +0000 (UTC) (envelope-from aaronfarias@att.net) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1604082487; bh=8xe90eNXen9+yVD08v3z7kq7vYDt6WOC4+sWJMg8yaG=; h=Subject:From:To:Date; b=X69t1BtERU4taQ2VuIHDB/pxYOkJd5lctHbZXl5+jD4ETqb0Uk47sOHlgfesAqI8F93/n46kp5W7JX6JoXoLCIeuNPj4/eZvtS+TxT3N+eoSCWUhX4ivKP8BSWjsPiB+LZLv/xxADDyISB6JJm7dNB7L7dfoITS3nN3d0OEqHGPNb+ubb8AR0MAU6cd7l41YQHJXQKR1cukC7Hejpgo+yeeFgU3eL/b80JAX+voSvikePnjjze5V38mxvbPUUqocX3KBZTDy6T6KIA0uPMoAX7Dic18BNaTlDZwKEZYK0INwhd2VEQQ7lhLuyHyKFf4eOi84DBL+zXeBhiYl3RcbEQ== X-YMail-OSG: IGrpjGwVM1mp2DsXDh6LS52pLnjb0PLn6bsTW1IcPqHiRanGZcrst48T47Mk6Gb p4ObJESl_6tnLHlnfNg0S0H73YUV4liMAtXiBiblducb_fOMNnGKl.erq6yvR4AXP3JhMMyCORRj OmmbnozXCjiH4P8aYn.CmqsesgJ9DO6_LwES12eQeyqzZrdgemtPCOp85UI19MjYxHBccZmt4Agd 1D5j9nQLXUFqAt6Ipb4TodoDrYK4hg_hCd6nbCOyaqlfSB8QpL7bpWwVvzv2z.mhFPG61ww24nLm ciQpEpUKvpwjmlEsQqHBrr.4r1PRH5NZyF3InkLBx1TyiV6hyG_viLY1MBqzjCKhi1VZBQ77poDg Ip1ymXT2P4JgVTe92fx8BWuthjnjG76E0FuTyGpfBV3CuzNOGZ0tTZqwEuvOPvEuGBDYAXpe3c66 b1yuno0M8i9ZIcDFMxJfJDlfd5vJ37YT6COdk31h6InDBkMO64tXwen4661wsFRWGml0sWsAJaUL gMolxcY2zW1MjlQY9dik0oB8I13As7b7vyvkH_jLnJ7jiL8a8Ln9qFZS8bk5hrUWx0gjpgbqvCi8 LgKeHUL47hkZ_ly3Xl4hc2UzwuB.nNgeQGTZ1agL6NuitPhfUG4mOgP2qODAeeTDeAtoqI3_ezeN iZgDWCeYgKwU9iyij4shVojutLbYox8MvrpN9BTEXzAIJcXkB.4IGm.Ee_uzhv0jm39QSgdEeMNl eOYvU19Mb_U9ZHE16oOfXSI16zR3aDw4giaoRtPvdcNbZ1I1yUuGoIXxEzOeE0dYie1fSYuugvnI CxNRgoxXCL7snT4r.uXu3MP51KhcU6mLDLvRvOEEcA.hjuBrkOdSXaBGiJbOWRpmSlGdqGrI2s7Y 2YKVOshZEq8HOHRPhExj54J9KcD9IINgrLuyuD_7H8k3Ax1I.35utOPl2y2yWJ5wYL1FLHJJWL2l jj4HSzAIFvATw.AE7HmYBIFls4RmoKju9ikX6SsIvWLTsTwSZb_f9A5vUhi_IGeM0TubXCP39Me1 qr9UEcrBm9.k_9GCgIZudCCMCib0nY5knMdWlVnPp1ieAvYxU9Gkw.QrSfvzl1NevaeCZ.gZEeI_ x2MAQzDJ3f5ky4WrbazvAlO1rc2h.FVVXox.aW1V_A7DHKlCPEImUrbLfLfD0C6U60z9eGSbPzE2 9pg3aqoPi0zujRhAnnmS2Li82cnhTtswnegtHgdIGTLlWtGeuSUQNRHE5Ar..gBrgXhVqxWYD8bA yZ0oJdWGGV0FXcm8t1RcHhNu9zDDcgRBlB2weDCWPpZqIWqRIIbirImHE7R_FA0m8qBaw1Qcnjg9 K1h3R_CbfxtT60hwBZnhj34ucfMysvathB0aAPemVFvcoGNtIxLcQtUraBQjx_d5o.2gpX4DFbsD KBUoFv0A.pRvdCWfUNPah4hOa8K5llaFsMQAYs_VggsC4TgM2HxySOeU.sLcXSsDlHdIhEt3iefA xW5OOornmptPnlZTKM4idsoohH2ibI0uoYFlac.y47qPNYykvkL.xvN0AqfrUObaEZdpjJlD5CRn GSk1U0XBCDZpcfRVgkguqCqiSzdZDyJ1Stxsi6BF84OBrx63VrCuBd_cFufMu_p.RWf85iPaUMg6 9t5PN5Z_KxRU8ZW1yzMFQDP1an_fC644dToakaocAX.qhJcdtYoXM8gQuwQsiukc1b7P1Mf8u346 nC0h77yXox8HLH6JSt.0gs2Ky9qELhjfcaoOVo3IHEXL.UigTuJAo5Y7b1Q_tu0olFpXKkXg2l66 DXl90PYzI_H7dWH.Ol8WRqg12SEi1_3hkOevThTrqfPP6SkQCm8GE_3G6WzIZzYo0pkHHLH6disL a1RiG7uX403QqcQ2zK99YQ1utFygNWEGd6L1Fh2ynEOc9j3rkrqa.KQZMBAa8KSs6wfl1NHrFrmB JDpaCPkENl2J88zuV804CIn.CWIP1aDxStkuxrUqRIsxqzRKCcApT0NLIKNSb6KZlTMS5Wa3uSsi fBpZYGS1ORK7AklawU2C7QH4dCIZ._GR1ouXBkiNyWJRtLB2HHml8he.efEuspINdwPfY1e7dRHa __14MUq02kiEEfLb71MJO7bnCotTgs5WEeL1pbpNQPvw6qU8xExQ9V0el5sDpFoExlOIHxJXt0pN O_bbDVbijR.dqnF6q750w.dL_bkxuE.wUKa8Mol5QNmRvjKjVXTc7udbl3.o1vrDZf2JPFpfy82J x9SKSKejf9APB7II8Mwtp.C7KED1xwb1GxGY.zFCne3VxrusOmOd.EgtkaPkyIDBHaK5f33jCS1J U_6qs.0hwQQHk.6LPUmGGMRcO6yCNdRQAIxoDabBOt6e2fG8UsIpnAX3KRXMvGdZg8cNTo1pJZ2k MHo9qxLoYIAeLrLYH_5kqeUIYEsgem7537rOdh17zwhc6QFhwN_miKzpxod7ELtPs_EtaKR44cRz RnZyUzXeLs48isSAy.oYifJZo3VbKRRhMvUHPaYtZ9IWaiNDmxpiYRx5XRiKNGfccTjR1YxOXexp NxVUBx.OjRIQTleiJsVe7GqPeh9acGaIbgKlBsIyvVZGggQj.gfYFaZyIsAdFckbiK2bOq43KGfc QY1sICyizOC2dUACQPDZ53_qO5KUgUpnG8JskbVIb17De Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Fri, 30 Oct 2020 18:28:07 +0000 Received: by smtp412.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4e2cf58cabf572a41be47baa7f9c4c17; Fri, 30 Oct 2020 18:28:03 +0000 (UTC) Message-ID: <2b94dc4b39d33108e089762b57f16dc03f7e1ce9.camel@ubuntu.com> Subject: Re: "panic: page fault" in iwn signal handler(?) at r367127 From: Aaron H Farias Martinez To: current@freebsd.org Date: Fri, 30 Oct 2020 14:28:01 -0400 In-Reply-To: <20201030123744.GT1430@albert.catwhisker.org> References: <20201030123744.GT1430@albert.catwhisker.org> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-tPUOQDJra8a/u1l7EqVw" User-Agent: Evolution 3.38.0 FreeBSD GNOME Team MIME-Version: 1.0 X-Mailer: WebService/1.1.16944 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) X-Rspamd-Queue-Id: 4CN9m81zJ8z4LNN 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-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 18:28:09 -0000 --=-tPUOQDJra8a/u1l7EqVw Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2020-10-30 at 05:37 -0700, David Wolfskill wrote: > I've copied the dump and core.txt files to > http://www.catwhisker.org/~david/FreeBSD/head/r367127/ >=20 > Here's a copy/paste of the stack trace (from the core.txt.3 file): > p 12: page fault while in kernel mode > cpuid =3D 4; apic id =3D 04 > fault virtual address =3D 0xfffff80840000000 > fault code=C2=A0 =3D supervisor read data, page not present > instruction pointer =3D 0x20:0xffffffff80495f03 > stack pointer=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D 0x0:0xf= fffffff8241d748 > frame pointer=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D 0x0:0xf= fffffff8241d7a0 > code segment=C2=A0 =3D base 0x0, limit 0xfffff, type 0x1b > =C2=A0=C2=A0 =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process=C2=A0 =3D 12 (irq36: iwn0) > trap number=C2=A0 =3D 12 > panic: page fault > cpuid =3D 4 > time =3D 1604056852 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff804a69db =3D > db_trace_self_wrapper+0x2b/frame 0xffffffff8241d3f0 > vpanic() at 0xffffffff80baf802 =3D vpanic+0x182/frame > 0xffffffff8241d440 > panic() at 0xffffffff80baf5c3 =3D panic+0x43/frame 0xffffffff8241d4a0 > trap_fatal() at 0xffffffff8102c2f7 =3D trap_fatal+0x387/frame > 0xffffffff8241d500 > trap_pfault() at 0xffffffff8102c397 =3D trap_pfault+0x97/frame > 0xffffffff8241d560 > trap() at 0xffffffff8102b98b =3D trap+0x2ab/frame 0xffffffff8241d670 > calltrap() at 0xffffffff80fffa08 =3D calltrap+0x8/frame > 0xffffffff8241d670 > --- trap 0xc, rip =3D 0xffffffff80495f03, rsp =3D 0xffffffff8241d748, rbp > =3D 0xffffffff8241d7a0 --- > rijndaelEncrypt() at 0xffffffff80495f03 =3D rijndaelEncrypt+0x233/frame > 0xffffffff8241d7a0 > ccmp_decap() at 0xffffffff80d08bc1 =3D ccmp_decap+0x421/frame > 0xffffffff8241d8b0 > ieee80211_crypto_decap() at 0xffffffff80d07955 =3D > ieee80211_crypto_decap+0x125/frame 0xffffffff8241d900 > sta_input() at 0xffffffff80d41dec =3D sta_input+0x43c/frame > 0xffffffff8241d9a0 > iwn_notif_intr() at 0xffffffff8069949c =3D iwn_notif_intr+0x137c/frame > 0xffffffff8241dab0 > iwn_intr() at 0xffffffff8068f4f8 =3D iwn_intr+0x2b8/frame > 0xffffffff8241db20 > ithread_loop() at 0xffffffff80b6dbb9 =3D ithread_loop+0x279/frame > 0xffffffff8241dbb0 > fork_exit() at 0xffffffff80b6a690 =3D fork_exit+0x80/frame > 0xffffffff8241dbf0 > fork_trampoline() at 0xffffffff81000a5e =3D fork_trampoline+0xe/frame > 0xffffffff8241dbf0 > --- trap 0, rip =3D 0, rsp =3D 0, rbp =3D 0 --- > KDB: enter: panic >=20 > __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 > 55=C2=A0 __asm("movq %%gs:%P1,%0" : "=3Dr" (td) : "n" (offsetof(struct pc= pu, > (kgdb) #0=C2=A0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:5= 5 > #1=C2=A0 doadump (textdump=3D0) at /usr/src/sys/kern/kern_shutdown.c:394 > #2=C2=A0 0xffffffff804a3cea in db_dump (dummy=3D,=20 > =C2=A0=C2=A0=C2=A0 dummy2=3D, dummy3=3D, > dummy4=3D) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/ddb/db_command.c:575 > #3=C2=A0 0xffffffff804a3ab0 in db_command (last_cmdp=3D,= =20 > =C2=A0=C2=A0=C2=A0 cmd_table=3D, dopager=3D1) at > /usr/src/sys/ddb/db_command.c:482 > #4=C2=A0 0xffffffff804a380d in db_command_loop () > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/ddb/db_command.c:535 > #5=C2=A0 0xffffffff804a6b26 in db_trap (type=3D, > code=3D) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/ddb/db_main.c:270 > #6=C2=A0 0xffffffff80bfb5c4 in kdb_trap (type=3D3, code=3D0, tf=3D out>) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/kern/subr_kdb.c:699 > #7=C2=A0 0xffffffff8102be9e in trap (frame=3D0xffffffff8241d320) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/amd64/amd64/trap.c:576 > #8=C2=A0 > #9=C2=A0 kdb_enter (why=3D0xffffffff8120d701 "panic", msg=3D) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/kern/subr_kdb.c:486 > #10 0xffffffff80baf81e in vpanic (fmt=3D, ap=3D out>) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/kern/kern_shutdown.c:901 > #11 0xffffffff80baf5c3 in panic ( > =C2=A0=C2=A0=C2=A0 fmt=3D0xffffffff81c79aa8 > "\362\357\034\201\377\377\377\377") > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/kern/kern_shutdown.c:838 > #12 0xffffffff8102c2f7 in trap_fatal (frame=3D0xffffffff8241d680,=20 > =C2=A0=C2=A0=C2=A0 eva=3D18446735313050009600) at /usr/src/sys/amd64/amd6= 4/trap.c:915 > #13 0xffffffff8102c397 in trap_pfault (frame=3D0xffffffff8241d680,=20 > =C2=A0=C2=A0=C2=A0 usermode=3D, signo=3D, u= code=3D out>) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/amd64/amd64/trap.c:732 > #14 0xffffffff8102b98b in trap (frame=3D0xffffffff8241d680) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/amd64/amd64/trap.c:398 > #15 > #16 rijndaelEncrypt (rk=3D, Nr=3D,=20 > =C2=A0=C2=A0=C2=A0 pt=3D,=20 > =C2=A0=C2=A0=C2=A0 ct=3D0xffffffff8241d830 > "\277\243\ff\211\335\330\v5\234\035{\210\330\320\327Fe\235>\226\026\0 > 25c\266n\325\305\205]\251%\001\002\004\030\326!\"\037") > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/crypto/rijndael/rijndael-alg-fst.c:100= 0 > #17 0xffffffff80d08bc1 in ccmp_decrypt (key=3D0xfffffe106978a160, > pn=3D25627,=20 > =C2=A0=C2=A0=C2=A0 m=3D0xfffff8010ffc9b00, hdrlen=3D) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/net80211/ieee80211_crypto_ccmp.c:623 > #18 ccmp_decap (k=3D, m=3D, > hdrlen=3D) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/net80211/ieee80211_crypto_ccmp.c:284 > #19 0xffffffff80d07955 in ieee80211_crypto_decap (ni=3D, > =C2=A0=C2=A0=C2=A0 m=3D0xfffff8010ffc9b00, hdrlen=3D26, key=3D0xffffffff8= 241d920) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/net80211/ieee80211_crypto.c:684 > #20 0xffffffff80d41dec in sta_input (ni=3D,=20 > =C2=A0=C2=A0=C2=A0 m=3D0xfffff8010ffc9b00, rxs=3D, rssi=3D= ,=20 > =C2=A0=C2=A0=C2=A0 nf=3D) at /usr/src/sys/net80211/ieee802= 11_sta.c:773 > #21 0xffffffff8069949c in iwn_rx_done (sc=3D0xfffffe1033319000,=20 > =C2=A0=C2=A0=C2=A0 desc=3D, data=3D) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/dev/iwn/if_iwn.c:3191 > #22 iwn_notif_intr (sc=3D) at > /usr/src/sys/dev/iwn/if_iwn.c:4018 > #23 0xffffffff8068f4f8 in iwn_intr (arg=3D0xfffffe1033319000) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/dev/iwn/if_iwn.c:4337 > #24 0xffffffff80b6dbb9 in intr_event_execute_handlers (p=3D out>,=20 > =C2=A0=C2=A0=C2=A0 ie=3D0xfffff8000c52b300) at /usr/src/sys/kern/kern_int= r.c:1168 > #25 ithread_execute_handlers (p=3D, > ie=3D0xfffff8000c52b300) > =C2=A0=C2=A0=C2=A0 at /usr/src/sys/kern/kern_intr.c:1181 > #26 ithread_loop (arg=3D) at > /usr/src/sys/kern/kern_intr.c:1269 > #27 0xffffffff80b6a690 in fork_exit ( > =C2=A0=C2=A0=C2=A0 callout=3D0xffffffff80b6d940 , > arg=3D0xfffff8000d18ef00,=20 > =C2=A0=C2=A0=C2=A0 frame=3D0xffffffff8241dc00) at /usr/src/sys/kern/kern_= fork.c:1052 > #28 > (kgdb)=20 >=20 >=20 > This happened while my laptop was running: > FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #43 > r367127M/367127: Thu Oct 29 05:52:40 PDT 2020=C2=A0=C2=A0=C2=A0=C2=A0 > root@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANA > RY=C2=A0 amd64 1300123 1300123 >=20 > during the "make buildkernel" phase of an in-place source update to > r367160. >=20 > As often happens while I'm running head, there was an "iwn firmware > panic" (see, e.g., > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214435); record of > it > may be found in /var/log/messages, starting around: >=20 > <2>1 2020-10-30T11:05:07.327958+00:00 g1-55.catwhisker.org kernel - - > - Expensive timeout(9) function: > 0xffffffff80d8d2f0(0xfffffe1067a408f0) 0.840172647 s > <2>1 2020-10-30T11:07:36.367805+00:00 g1-55.catwhisker.org kernel - - > - iwn0: iwn_intr: fatal firmware error > <2>1 2020-10-30T11:07:36.367830+00:00 g1-55.catwhisker.org kernel - - > - firmware error log: > <2>1 2020-10-30T11:07:36.367839+00:00 g1-55.catwhisker.org kernel - - > -=C2=A0=C2=A0 error type=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D "UNKNOWN" (0x0= 000001D) >=20 >=20 > and the "WiFi" LED on the laptop went dark.=C2=A0 As I was trying to do > some work on another machine (while logged in to that machine from > the > laptop), the loss of connectivity was ... disruptive.=C2=A0 While I was > mildly gratified that (this time) the "make buildkernel" appeared to > be > proceeding despite the iwn(4) issue(s), I also wanted to get back to > what I was doing. >=20 > So after a few minutes -- when it became apparent that the link > wasn't > being recovered on its own -- I switched from X11 to vty1 (to leave > vty0 > for console messages), logged in as root, and issued: >=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0service netif restart wla= n0 >=20 > after a couple of minutes (during which the "make buildkernel" was > continuing), the "service netif restart wlan0" had not yet completed, > so > I sent it a SIGNIFO (via ^T), and (as I recall), it indocated that > the > process was invoking ifconfig, and there was some mention of a > function > whose name included "epoch". >=20 > I resumed waiting; after another minute or so, I trued ^T again, and > there appeared to be no progress. >=20 > After waiting another 30 seconds or so, I tried to bail out via ^C; > that > appeared to be ineffective.=C2=A0 So after waiting another 10 - 15 second= s > or > so, I tried backgrounding (^Z), followed by "kill %1". >=20 > It was shortly after that the panic occurred.=C2=A0 Which may well -- to > some > extent -- have been self-inflicted.=C2=A0 That said, the iwn firmware > panics > are not something I can control (as far as I know -- please let me > know > how I can control them if I'm incoorrect on that score).=C2=A0 For that > matter, I have no particular attachment to this NIC -- I'm open to a > suggestion for any NIC with the same (miniPCI) form factor that will > work well with FreeBSD. >=20 > Peace, > david I got the same issue. --=-tPUOQDJra8a/u1l7EqVw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEHG6L9rsswhVpZfW0syGtfDj30pgFAl+cWzEACgkQsyGtfDj3 0pgnHQgAni3xqR5rvaGn/T7M7LH82LAsgpTcJWbPrqIa3sTBiyQJLvubapHySdqA TSP9PH8RzYc7YqfALp3iUmfsxwDAX8nG3Ha+g5rG1/MgeuaIEcXMmqE6+o8bO/uV XhG6+V4w6D+bpaYmi1yHy92AbuiUfQEPWxGpc3neMUj5oYezCLzUI8zeN3g4kge+ /4eN0UwF8Fn604phjApSJB3KTmKNmWaqoUnT54pjsQLdoKvOWKB/8fBCQGkIFdxb xZbH8owF4fW336aKMOnRHgan+44tvGmfCGyVbk8URdNNmHnx/IPSUWbxR24yt99C SlJ6kz/oZlSr5N0Iqc5CakrtqFKplA== =Ai3w -----END PGP SIGNATURE----- --=-tPUOQDJra8a/u1l7EqVw-- From owner-freebsd-current@freebsd.org Fri Oct 30 20:46:35 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 96ABA45B382 for ; Fri, 30 Oct 2020 20:46:35 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CNDqt0PvXz4SrV for ; Fri, 30 Oct 2020 20:46:33 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1kYbHy-000JnH-Sy; Fri, 30 Oct 2020 23:46:22 +0300 Date: Fri, 30 Oct 2020 23:46:22 +0300 From: Slawa Olhovchenkov To: Cy Schubert Cc: qroxana , freebsd-current@freebsd.org Subject: Re: OpenZFS: kldload zfs.ko freezes on i386 4GB memory Message-ID: <20201030204622.GF2033@zxy.spb.ru> References: <202010300313.09U3D0KZ006216@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202010300313.09U3D0KZ006216@slippy.cwsent.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-Rspamd-Queue-Id: 4CNDqt0PvXz4SrV X-Spamd-Bar: / X-Spamd-Result: default: False [-0.48 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.74)[-0.742]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zxy.spb.ru]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.23)[0.227]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.87)[-0.869]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:5495, ipnet:195.70.192.0/19, country:RU]; MAILMAN_DEST(0.00)[freebsd-current]; FREEMAIL_CC(0.00)[mail.ru,freebsd.org] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 20:46:35 -0000 On Thu, Oct 29, 2020 at 08:13:00PM -0700, Cy Schubert wrote: > In message , qroxana > writes > : > > > > Hi, > > > > I have an old i386 machine running r364479. After upgrading to > > r367045, running kldload zfs.ko freezes the whole system. > > > > I also tried to replace the 4GB memory with another 2GB one > > and kldload zfs.ko works without freezing the machine. > > ZFS ARC stresses memory. I've found a number of bad RAM chips over the > years using ZFS. > > The OpenZFS upgrade significantly changed how it manages ARC. It's likely > that prior to the OpenZFS upgrade your memory wasn't stressed to the point > of failure. You can try to mask the problem by reducing your RAM clock rate > or or increase one of the other latency settings in your BIOS. However, > again, this only masks an already weak RAM chip. Sounds like performance drop and regression From owner-freebsd-current@freebsd.org Fri Oct 30 20:53:19 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3246C45B34D for ; Fri, 30 Oct 2020 20:53:19 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CNDzd6TyQz4TV7 for ; Fri, 30 Oct 2020 20:53:17 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.229.168]) by shaw.ca with ESMTPA id YbObkqfWi34axYbOcksSpC; Fri, 30 Oct 2020 14:53:15 -0600 X-Authority-Analysis: v=2.4 cv=LvQsdlRc c=1 sm=1 tr=0 ts=5f9c7d3b a=7AlCcx2GqMg+lh9P3BclKA==:117 a=7AlCcx2GqMg+lh9P3BclKA==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=afefHYAZSVUA:10 a=KawIFhhbAAAA:8 a=RgBw9RmQAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=mCggUBy7LPhKHz6oaoAA:9 a=CjuIK1q_8ugA:10 a=sDZbbUVwIjaXAAecbMhh:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [IPv6:fc00:1:1:1::5b]) by spqr.komquats.com (Postfix) with ESMTPS id C01C9CFA; Fri, 30 Oct 2020 13:53:11 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.16.1/8.16.1) with ESMTP id 09UKrAXc031272; Fri, 30 Oct 2020 13:53:10 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202010302053.09UKrAXc031272@slippy.cwsent.com> X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Slawa Olhovchenkov cc: Cy Schubert , qroxana , freebsd-current@freebsd.org Subject: Re: OpenZFS: kldload zfs.ko freezes on i386 4GB memory In-reply-to: <20201030204622.GF2033@zxy.spb.ru> References: <202010300313.09U3D0KZ006216@slippy.cwsent.com> <20201030204622.GF2033@zxy.spb.ru> Comments: In-reply-to Slawa Olhovchenkov message dated "Fri, 30 Oct 2020 23:46:22 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Oct 2020 13:53:10 -0700 X-CMAE-Envelope: MS4xfOLFcetvlS9O3jlWioeEi4WiLcg+m/gzRLXIE33tfmjRPOCS1HAG0BJWsbXMcB1dXXAMdFO0fzdsTghXzaAFzHEPK6k2iQ1weSWpMqq67/Cy3S2m2zOl 4Hmxhh2/mRyS4NaEDitocyu76ALy/GEfa5mp9z4/ta4nY3V2A+XgfFm99AiRJfC402c2KHGnLuLMpoJWmW0yLfVXQwWtIXJoQoyVmnqa1HffSHdSQ3kwOWUX Yy5Ggcr+VuIrm8kOUTLFrxuytJcmz8Id27qnaNxL308= X-Rspamd-Queue-Id: 4CNDzd6TyQz4TV7 X-Spamd-Bar: / X-Spamd-Result: default: False [0.60 / 15.00]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; RWL_MAILSPIKE_GOOD(0.00)[64.59.134.9:from]; RCVD_COUNT_THREE(0.00)[4]; RECEIVED_SPAMHAUS_PBL(0.00)[70.67.229.168:received]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.87)[-0.872]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.86)[0.863]; NEURAL_HAM_LONG(-0.69)[-0.692]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; AUTH_NA(1.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[64.59.134.9:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_CC(0.00)[cschubert.com,mail.ru,freebsd.org]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 20:53:19 -0000 In message <20201030204622.GF2033@zxy.spb.ru>, Slawa Olhovchenkov writes: > On Thu, Oct 29, 2020 at 08:13:00PM -0700, Cy Schubert wrote: > > > In message , qroxana > > writes > > : > > > > > > Hi, > > > > > > I have an old i386 machine running r364479. After upgrading to > > > r367045, running kldload zfs.ko freezes the whole system. > > > > > > I also tried to replace the 4GB memory with another 2GB one > > > and kldload zfs.ko works without freezing the machine. > > > > ZFS ARC stresses memory. I've found a number of bad RAM chips over the > > years using ZFS. > > > > The OpenZFS upgrade significantly changed how it manages ARC. It's likely > > that prior to the OpenZFS upgrade your memory wasn't stressed to the point > > of failure. You can try to mask the problem by reducing your RAM clock rate > > > or or increase one of the other latency settings in your BIOS. However, > > again, this only masks an already weak RAM chip. > > Sounds like performance drop and regression How so. Please explain. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Fri Oct 30 22:08:13 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F1D9E45C82D for ; Fri, 30 Oct 2020 22:08:13 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CNGf50m10z4X1Y for ; Fri, 30 Oct 2020 22:08:12 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1kYcZ7-000KCC-Ew; Sat, 31 Oct 2020 01:08:09 +0300 Date: Sat, 31 Oct 2020 01:08:09 +0300 From: Slawa Olhovchenkov To: Cy Schubert Cc: qroxana , freebsd-current@freebsd.org Subject: Re: OpenZFS: kldload zfs.ko freezes on i386 4GB memory Message-ID: <20201030220809.GG2033@zxy.spb.ru> References: <202010300313.09U3D0KZ006216@slippy.cwsent.com> <20201030204622.GF2033@zxy.spb.ru> <202010302053.09UKrAXc031272@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202010302053.09UKrAXc031272@slippy.cwsent.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-Rspamd-Queue-Id: 4CNGf50m10z4X1Y X-Spamd-Bar: / X-Spamd-Result: default: False [0.35 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.62)[-0.617]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zxy.spb.ru]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.92)[0.924]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.86)[-0.858]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5495, ipnet:195.70.192.0/19, country:RU]; FREEMAIL_CC(0.00)[mail.ru,freebsd.org]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 22:08:14 -0000 On Fri, Oct 30, 2020 at 01:53:10PM -0700, Cy Schubert wrote: > In message <20201030204622.GF2033@zxy.spb.ru>, Slawa Olhovchenkov writes: > > On Thu, Oct 29, 2020 at 08:13:00PM -0700, Cy Schubert wrote: > > > > > In message , qroxana > > > writes > > > : > > > > > > > > Hi, > > > > > > > > I have an old i386 machine running r364479. After upgrading to > > > > r367045, running kldload zfs.ko freezes the whole system. > > > > > > > > I also tried to replace the 4GB memory with another 2GB one > > > > and kldload zfs.ko works without freezing the machine. > > > > > > ZFS ARC stresses memory. I've found a number of bad RAM chips over the > > > years using ZFS. > > > > > > The OpenZFS upgrade significantly changed how it manages ARC. It's likely > > > that prior to the OpenZFS upgrade your memory wasn't stressed to the point > > > of failure. You can try to mask the problem by reducing your RAM clock rate > > > > > or or increase one of the other latency settings in your BIOS. However, > > > again, this only masks an already weak RAM chip. > > > > Sounds like performance drop and regression > > How so. Please explain. More stresses memory usually refers to performance penalty. Usually way for better performance is reduce memory access. From owner-freebsd-current@freebsd.org Fri Oct 30 22:34:20 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8525D45D0AD for ; Fri, 30 Oct 2020 22:34:20 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CNHDC4Gspz4Ykp for ; Fri, 30 Oct 2020 22:34:19 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.229.168]) by shaw.ca with ESMTPA id YcyNkPEkYtdldYcyOkni9m; Fri, 30 Oct 2020 16:34:18 -0600 X-Authority-Analysis: v=2.4 cv=INe8tijG c=1 sm=1 tr=0 ts=5f9c94ea a=7AlCcx2GqMg+lh9P3BclKA==:117 a=7AlCcx2GqMg+lh9P3BclKA==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=afefHYAZSVUA:10 a=KawIFhhbAAAA:8 a=RgBw9RmQAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=xZhfuQNd9EuEz4NgfawA:9 a=CjuIK1q_8ugA:10 a=sDZbbUVwIjaXAAecbMhh:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [IPv6:fc00:1:1:1::5b]) by spqr.komquats.com (Postfix) with ESMTPS id BAEE2DB8; Fri, 30 Oct 2020 15:34:13 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.16.1/8.16.1) with ESMTP id 09UMYA5d032018; Fri, 30 Oct 2020 15:34:11 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202010302234.09UMYA5d032018@slippy.cwsent.com> X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Slawa Olhovchenkov cc: Cy Schubert , qroxana , freebsd-current@freebsd.org Subject: Re: OpenZFS: kldload zfs.ko freezes on i386 4GB memory In-reply-to: <20201030220809.GG2033@zxy.spb.ru> References: <202010300313.09U3D0KZ006216@slippy.cwsent.com> <20201030204622.GF2033@zxy.spb.ru> <202010302053.09UKrAXc031272@slippy.cwsent.com> <20201030220809.GG2033@zxy.spb.ru> Comments: In-reply-to Slawa Olhovchenkov message dated "Sat, 31 Oct 2020 01:08:09 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Oct 2020 15:34:10 -0700 X-CMAE-Envelope: MS4xfDAp6FR8Q4q1Z28of+LBQUFEHqoGntvDbP3Ux4PRhKLMOVMQI4p96ObCm4W4QBaTlvNakJ5xfhnrA541ATqBMUywQNBTFl5F3ozaQzNnpxqdIKKFvSHV 2roqYuqsYtSsxWpfMmSwsXt8kvIzBmdaCti4Ppmm0s8nViDqB0LWB0wv+ubk9lkU0c8Ub+Mb6oRyEI0kciS7AD5tK5B5uHiZXNmPJ/Vl1PQNaZ0EHBp2Rj+C qFhh+/1L/J11W16yhGmDXcg+6Fbjmz5xCYxEfjpyBHM= X-Rspamd-Queue-Id: 4CNHDC4Gspz4Ykp X-Spamd-Bar: / X-Spamd-Result: default: False [0.63 / 15.00]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; RWL_MAILSPIKE_GOOD(0.00)[64.59.134.12:from]; RCVD_COUNT_THREE(0.00)[4]; RECEIVED_SPAMHAUS_PBL(0.00)[70.67.229.168:received]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.86)[-0.864]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.86)[0.860]; NEURAL_HAM_LONG(-0.67)[-0.669]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; AUTH_NA(1.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[64.59.134.12:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_CC(0.00)[cschubert.com,mail.ru,freebsd.org]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 22:34:20 -0000 In message <20201030220809.GG2033@zxy.spb.ru>, Slawa Olhovchenkov writes: > On Fri, Oct 30, 2020 at 01:53:10PM -0700, Cy Schubert wrote: > > > In message <20201030204622.GF2033@zxy.spb.ru>, Slawa Olhovchenkov writes: > > > On Thu, Oct 29, 2020 at 08:13:00PM -0700, Cy Schubert wrote: > > > > > > > In message , qroxan > a > > > > writes > > > > : > > > > > > > > > > Hi, > > > > > > > > > > I have an old i386 machine running r364479. After upgrading to > > > > > r367045, running kldload zfs.ko freezes the whole system. > > > > > > > > > > I also tried to replace the 4GB memory with another 2GB one > > > > > and kldload zfs.ko works without freezing the machine. > > > > > > > > ZFS ARC stresses memory. I've found a number of bad RAM chips over the > > > > years using ZFS. > > > > > > > > The OpenZFS upgrade significantly changed how it manages ARC. It's like > ly > > > > that prior to the OpenZFS upgrade your memory wasn't stressed to the po > int > > > > of failure. You can try to mask the problem by reducing your RAM clock > rate > > > > > > > or or increase one of the other latency settings in your BIOS. However, > > > > > again, this only masks an already weak RAM chip. > > > > > > Sounds like performance drop and regression > > > > How so. Please explain. > > More stresses memory usually refers to performance penalty. > Usually way for better performance is reduce memory access. The reason filesystems (UFS, ZFS, EXT4, etc.) cache is to avoid disk accesses. Nanoseconds vs milliseconds. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Fri Oct 30 22:47:41 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 894E645D684 for ; Fri, 30 Oct 2020 22:47:41 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CNHWc1jqQz4ZFX for ; Fri, 30 Oct 2020 22:47:40 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1kYdBH-000KPa-2u; Sat, 31 Oct 2020 01:47:35 +0300 Date: Sat, 31 Oct 2020 01:47:35 +0300 From: Slawa Olhovchenkov To: Cy Schubert Cc: qroxana , freebsd-current@freebsd.org Subject: Re: OpenZFS: kldload zfs.ko freezes on i386 4GB memory Message-ID: <20201030224734.GH2033@zxy.spb.ru> References: <202010300313.09U3D0KZ006216@slippy.cwsent.com> <20201030204622.GF2033@zxy.spb.ru> <202010302053.09UKrAXc031272@slippy.cwsent.com> <20201030220809.GG2033@zxy.spb.ru> <202010302234.09UMYA5d032018@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202010302234.09UMYA5d032018@slippy.cwsent.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-Rspamd-Queue-Id: 4CNHWc1jqQz4ZFX X-Spamd-Bar: / X-Spamd-Result: default: False [-0.61 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.96)[-0.956]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zxy.spb.ru]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.30)[0.298]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.86)[-0.856]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5495, ipnet:195.70.192.0/19, country:RU]; FREEMAIL_CC(0.00)[mail.ru,freebsd.org]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 22:47:41 -0000 On Fri, Oct 30, 2020 at 03:34:10PM -0700, Cy Schubert wrote: > In message <20201030220809.GG2033@zxy.spb.ru>, Slawa Olhovchenkov writes: > > On Fri, Oct 30, 2020 at 01:53:10PM -0700, Cy Schubert wrote: > > > > > In message <20201030204622.GF2033@zxy.spb.ru>, Slawa Olhovchenkov writes: > > > > On Thu, Oct 29, 2020 at 08:13:00PM -0700, Cy Schubert wrote: > > > > > > > > > In message , qroxan > > a > > > > > writes > > > > > : > > > > > > > > > > > > Hi, > > > > > > > > > > > > I have an old i386 machine running r364479. After upgrading to > > > > > > r367045, running kldload zfs.ko freezes the whole system. > > > > > > > > > > > > I also tried to replace the 4GB memory with another 2GB one > > > > > > and kldload zfs.ko works without freezing the machine. > > > > > > > > > > ZFS ARC stresses memory. I've found a number of bad RAM chips over the > > > > > years using ZFS. > > > > > > > > > > The OpenZFS upgrade significantly changed how it manages ARC. It's like > > ly > > > > > that prior to the OpenZFS upgrade your memory wasn't stressed to the po > > int > > > > > of failure. You can try to mask the problem by reducing your RAM clock > > rate > > > > > > > > > or or increase one of the other latency settings in your BIOS. However, > > > > > > > again, this only masks an already weak RAM chip. > > > > > > > > Sounds like performance drop and regression > > > > > > How so. Please explain. > > > > More stresses memory usually refers to performance penalty. > > Usually way for better performance is reduce memory access. > > The reason filesystems (UFS, ZFS, EXT4, etc.) cache is to avoid disk > accesses. Nanoseconds vs milliseconds. I mean compared ZoL ZFS ARC vs old (BSD/Opensolaris/Illumos) ZFS ARC. Any reaason to rise ARC hit rate in ZoL case? From owner-freebsd-current@freebsd.org Fri Oct 30 23:01:05 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5453F45DB53 for ; Fri, 30 Oct 2020 23:01:05 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CNHq42yDFz4ZnT for ; Fri, 30 Oct 2020 23:01:04 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.229.168]) by shaw.ca with ESMTPA id YdOEkeiL4RAWfYdOGkdDMk; Fri, 30 Oct 2020 17:01:02 -0600 X-Authority-Analysis: v=2.4 cv=P9aEOgMu c=1 sm=1 tr=0 ts=5f9c9b2e a=7AlCcx2GqMg+lh9P3BclKA==:117 a=7AlCcx2GqMg+lh9P3BclKA==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=afefHYAZSVUA:10 a=KawIFhhbAAAA:8 a=RgBw9RmQAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=sQiMz30JYC253yhkjtMA:9 a=CjuIK1q_8ugA:10 a=sDZbbUVwIjaXAAecbMhh:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [IPv6:fc00:1:1:1::5b]) by spqr.komquats.com (Postfix) with ESMTPS id 1DB53D6C; Fri, 30 Oct 2020 16:00:58 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.16.1/8.16.1) with ESMTP id 09UN0t4A032372; Fri, 30 Oct 2020 16:00:57 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202010302300.09UN0t4A032372@slippy.cwsent.com> X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Slawa Olhovchenkov cc: Cy Schubert , qroxana , freebsd-current@freebsd.org Subject: Re: OpenZFS: kldload zfs.ko freezes on i386 4GB memory In-reply-to: <20201030224734.GH2033@zxy.spb.ru> References: <202010300313.09U3D0KZ006216@slippy.cwsent.com> <20201030204622.GF2033@zxy.spb.ru> <202010302053.09UKrAXc031272@slippy.cwsent.com> <20201030220809.GG2033@zxy.spb.ru> <202010302234.09UMYA5d032018@slippy.cwsent.com> <20201030224734.GH2033@zxy.spb.ru> Comments: In-reply-to Slawa Olhovchenkov message dated "Sat, 31 Oct 2020 01:47:35 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Oct 2020 16:00:55 -0700 X-CMAE-Envelope: MS4xfIDLNHxxk46TDu8yeQUhC4E6ePaYTKYNZPzR6zXTcwesTvv2lmSXTiRKVPSiauI4rwLiWD0yqJKol+GIpQdf9zsmL0DHik0AiURoby3p6+4hcAlun+Hj K5S0X5oA7VIPtCNnaNKuapSbR92WC4j6syPx8obyIAzha5CQhebN9uHfxRErh1FH0WnATYuBwm4U87PuKzLYOZZle/8QhyyqfxW1ZLmruUT5NZ1WXQ21BMPl RTF9iSmNu8WZSdvr+YnoGHBgCkm4hM1CuSvFOMi5arA= X-Rspamd-Queue-Id: 4CNHq42yDFz4ZnT X-Spamd-Bar: / X-Spamd-Result: default: False [-0.37 / 15.00]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[4]; RECEIVED_SPAMHAUS_PBL(0.00)[70.67.229.168:received]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.979]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.39)[0.386]; NEURAL_HAM_LONG(-1.07)[-1.075]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; AUTH_NA(1.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[64.59.136.139:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RWL_MAILSPIKE_VERYGOOD(0.00)[64.59.136.139:from]; FREEMAIL_CC(0.00)[cschubert.com,mail.ru,freebsd.org]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 23:01:05 -0000 In message <20201030224734.GH2033@zxy.spb.ru>, Slawa Olhovchenkov writes: > On Fri, Oct 30, 2020 at 03:34:10PM -0700, Cy Schubert wrote: > > > In message <20201030220809.GG2033@zxy.spb.ru>, Slawa Olhovchenkov writes: > > > On Fri, Oct 30, 2020 at 01:53:10PM -0700, Cy Schubert wrote: > > > > > > > In message <20201030204622.GF2033@zxy.spb.ru>, Slawa Olhovchenkov write > s: > > > > > On Thu, Oct 29, 2020 at 08:13:00PM -0700, Cy Schubert wrote: > > > > > > > > > > > In message , qr > oxan > > > a > > > > > > writes > > > > > > : > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I have an old i386 machine running r364479. After upgrading to > > > > > > > r367045, running kldload zfs.ko freezes the whole system. > > > > > > > > > > > > > > I also tried to replace the 4GB memory with another 2GB one > > > > > > > and kldload zfs.ko works without freezing the machine. > > > > > > > > > > > > ZFS ARC stresses memory. I've found a number of bad RAM chips over > the > > > > > > years using ZFS. > > > > > > > > > > > > The OpenZFS upgrade significantly changed how it manages ARC. It's > like > > > ly > > > > > > that prior to the OpenZFS upgrade your memory wasn't stressed to th > e po > > > int > > > > > > of failure. You can try to mask the problem by reducing your RAM cl > ock > > > rate > > > > > > > > > > > or or increase one of the other latency settings in your BIOS. Howe > ver, > > > > > > > > > again, this only masks an already weak RAM chip. > > > > > > > > > > Sounds like performance drop and regression > > > > > > > > How so. Please explain. > > > > > > More stresses memory usually refers to performance penalty. > > > Usually way for better performance is reduce memory access. > > > > The reason filesystems (UFS, ZFS, EXT4, etc.) cache is to avoid disk > > accesses. Nanoseconds vs milliseconds. > > I mean compared ZoL ZFS ARC vs old (BSD/Opensolaris/Illumos) ZFS ARC. > Any reaason to rise ARC hit rate in ZoL case? That's what hit rate is. It's a memory access instead of a disk access. That's what you want. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Fri Oct 30 23:08:42 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D143F45DF3F for ; Fri, 30 Oct 2020 23:08:42 +0000 (UTC) (envelope-from yasu@utahime.org) Received: from maybe.home.utahime.org (gate.home.utahime.org [183.180.29.210]) (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 4CNHzs6N5tz4bGJ for ; Fri, 30 Oct 2020 23:08:41 +0000 (UTC) (envelope-from yasu@utahime.org) Received: from eastasia.home.utahime.org (eastasia.home.utahime.org [192.168.174.1]) (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) (No client certificate requested) by maybe.home.utahime.org (Postfix) with ESMTPS id 96B95198C9; Sat, 31 Oct 2020 08:08:30 +0900 (JST) Received: from localhost (rolling.home.utahime.org [192.168.174.11]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by eastasia.home.utahime.org (Postfix) with ESMTPSA id 7A10E2DD0D; Sat, 31 Oct 2020 08:08:29 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.0 at eastasia.home.utahime.org Date: Sat, 31 Oct 2020 08:08:18 +0900 (JST) Message-Id: <20201031.080818.656406514696380037.yasu@utahime.org> To: freebsd-current@freebsd.org Subject: Re: Building packages with poudriere fails after `zfs upgrade` From: Yasuhiro KIMURA In-Reply-To: References: <20201025.145205.2130959911090091593.yasu@utahime.org> X-Mailer: Mew version 6.8 on Emacs 27.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4CNHzs6N5tz4bGJ X-Spamd-Bar: / X-Spamd-Result: default: False [0.03 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[utahime.org:s=maybe2019112701]; NEURAL_HAM_MEDIUM(-1.02)[-1.024]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; HFILTER_HELO_IP_A(1.00)[maybe.home.utahime.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.07)[-1.071]; RCVD_COUNT_THREE(0.00)[3]; HFILTER_HELO_NORES_A_OR_MX(0.30)[maybe.home.utahime.org]; R_SPF_ALLOW(-0.20)[+a:spf-authorized.utahime.org]; DKIM_TRACE(0.00)[utahime.org:+]; NEURAL_HAM_SHORT(-0.18)[-0.175]; MID_CONTAINS_FROM(1.00)[]; DMARC_NA(0.00)[utahime.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2519, ipnet:183.180.0.0/16, country:JP]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 23:08:42 -0000 From: Samy Mahmoudi Subject: Re: Building packages with poudriere fails after `zfs upgrade` Date: Thu, 29 Oct 2020 20:54:13 -0400 > Have you tried to work around the issue by creating a new jail with > poudriere, > or even by changing the value of ZROOTFS in poudriere.conf ? Thanks for suggestion. But I already fixed the problem by making clean install of base system with latest snapshot. --- Yasuhiro KIMURA From owner-freebsd-current@freebsd.org Fri Oct 30 23:31:43 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6414345E1DA for ; Fri, 30 Oct 2020 23:31:43 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CNJVQ3b0xz4cCd for ; Fri, 30 Oct 2020 23:31:42 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1kYdru-000KeO-DM; Sat, 31 Oct 2020 02:31:38 +0300 Date: Sat, 31 Oct 2020 02:31:38 +0300 From: Slawa Olhovchenkov To: Cy Schubert Cc: qroxana , freebsd-current@freebsd.org Subject: Re: OpenZFS: kldload zfs.ko freezes on i386 4GB memory Message-ID: <20201030233138.GD34923@zxy.spb.ru> References: <202010300313.09U3D0KZ006216@slippy.cwsent.com> <20201030204622.GF2033@zxy.spb.ru> <202010302053.09UKrAXc031272@slippy.cwsent.com> <20201030220809.GG2033@zxy.spb.ru> <202010302234.09UMYA5d032018@slippy.cwsent.com> <20201030224734.GH2033@zxy.spb.ru> <202010302300.09UN0t4A032372@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202010302300.09UN0t4A032372@slippy.cwsent.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-Rspamd-Queue-Id: 4CNJVQ3b0xz4cCd X-Spamd-Bar: / X-Spamd-Result: default: False [-0.57 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.96)[-0.959]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zxy.spb.ru]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.34)[0.340]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.85)[-0.848]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:5495, ipnet:195.70.192.0/19, country:RU]; MAILMAN_DEST(0.00)[freebsd-current]; FREEMAIL_CC(0.00)[mail.ru,freebsd.org] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 23:31:43 -0000 On Fri, Oct 30, 2020 at 04:00:55PM -0700, Cy Schubert wrote: > > > > More stresses memory usually refers to performance penalty. > > > > Usually way for better performance is reduce memory access. > > > > > > The reason filesystems (UFS, ZFS, EXT4, etc.) cache is to avoid disk > > > accesses. Nanoseconds vs milliseconds. > > > > I mean compared ZoL ZFS ARC vs old (BSD/Opensolaris/Illumos) ZFS ARC. > > Any reaason to rise ARC hit rate in ZoL case? > > That's what hit rate is. It's a memory access instead of a disk access. > That's what you want. Is ZoL ARC hit rate rise from FreeBSD ARC hit rate? From owner-freebsd-current@freebsd.org Fri Oct 30 23:50:39 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 638BE45EC13 for ; Fri, 30 Oct 2020 23:50:39 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CNJwG5R2rz4d0m for ; Fri, 30 Oct 2020 23:50:38 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.229.168]) by shaw.ca with ESMTPA id YeAEkPfmWtdldYeAFknxB8; Fri, 30 Oct 2020 17:50:37 -0600 X-Authority-Analysis: v=2.4 cv=INe8tijG c=1 sm=1 tr=0 ts=5f9ca6cd a=7AlCcx2GqMg+lh9P3BclKA==:117 a=7AlCcx2GqMg+lh9P3BclKA==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=afefHYAZSVUA:10 a=KawIFhhbAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=Oqed5r7jc3Zl1anTDEAA:9 a=CjuIK1q_8ugA:10 a=sDZbbUVwIjaXAAecbMhh:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [IPv6:fc00:1:1:1::5b]) by spqr.komquats.com (Postfix) with ESMTPS id 7F027DF9; Fri, 30 Oct 2020 16:50:32 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.16.1/8.16.1) with ESMTP id 09UNoVcM033686; Fri, 30 Oct 2020 16:50:31 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202010302350.09UNoVcM033686@slippy.cwsent.com> X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Slawa Olhovchenkov cc: Cy Schubert , qroxana , freebsd-current@freebsd.org Subject: Re: OpenZFS: kldload zfs.ko freezes on i386 4GB memory In-reply-to: <20201030233138.GD34923@zxy.spb.ru> References: <202010300313.09U3D0KZ006216@slippy.cwsent.com> <20201030204622.GF2033@zxy.spb.ru> <202010302053.09UKrAXc031272@slippy.cwsent.com> <20201030220809.GG2033@zxy.spb.ru> <202010302234.09UMYA5d032018@slippy.cwsent.com> <20201030224734.GH2033@zxy.spb.ru> <202010302300.09UN0t4A032372@slippy.cwsent.com> <20201030233138.GD34923@zxy.spb.ru> Comments: In-reply-to Slawa Olhovchenkov message dated "Sat, 31 Oct 2020 02:31:38 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Oct 2020 16:50:31 -0700 X-CMAE-Envelope: MS4xfGl5ShOSkmVbV3UTYLT70uYPr2GMfiRlmeuGqN/bXhGzTaCPMglRmf769488SjH1/s+MND+8Med0bfZOJOjRfCfp6wuih2lH8RQVAPCjz+qJS2NaLAPm sgKH0IkF0CyZt15vTlvJ6KjXCYjsKjKNJFUBXpbsGIDWNo5rKrdDF2VFa73raQYPUwXXaVRvHr/rWbMQP3QaH0r4q6wW/vF7b6NBUwjIMOlUHV/z/JoWIm99 M3iSiJk272HZ64dNoVACShJ1su2iMoHVTd3/XXe+YZA= X-Rspamd-Queue-Id: 4CNJwG5R2rz4d0m X-Spamd-Bar: / X-Spamd-Result: default: False [-0.25 / 15.00]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; RWL_MAILSPIKE_GOOD(0.00)[64.59.134.12:from]; RCVD_COUNT_THREE(0.00)[4]; RECEIVED_SPAMHAUS_PBL(0.00)[70.67.229.168:received]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.87)[-0.867]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.35)[0.350]; NEURAL_HAM_LONG(-1.04)[-1.035]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; AUTH_NA(1.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[64.59.134.12:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_CC(0.00)[cschubert.com,mail.ru,freebsd.org]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 23:50:39 -0000 In message <20201030233138.GD34923@zxy.spb.ru>, Slawa Olhovchenkov writes: > On Fri, Oct 30, 2020 at 04:00:55PM -0700, Cy Schubert wrote: > > > > > > More stresses memory usually refers to performance penalty. > > > > > Usually way for better performance is reduce memory access. > > > > > > > > The reason filesystems (UFS, ZFS, EXT4, etc.) cache is to avoid disk > > > > accesses. Nanoseconds vs milliseconds. > > > > > > I mean compared ZoL ZFS ARC vs old (BSD/Opensolaris/Illumos) ZFS ARC. > > > Any reaason to rise ARC hit rate in ZoL case? > > > > That's what hit rate is. It's a memory access instead of a disk access. > > That's what you want. > > Is ZoL ARC hit rate rise from FreeBSD ARC hit rate? We don't know that. You should be able to find out by running some tests that would populate your ARC and run the test again. I see that my -DNO_CLEAN buildworlds run faster, when I run them a second or third time after making a minor edit, than they did before. Thus I assume it uses memory more efficiently. By default it stores more metadata in ARC, 75% instead of IIRC 25% by default. Getting back to your original question. A more efficient ARC would exercise your memory more intensely because you are replacing disk reads with memory reads. And as I said before the old ZFS "found" weak RAM on three separate occasions in three different machines over the last ten years. You're advised to replace the marginal memory. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Sat Oct 31 00:32:21 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6118A45F654 for ; Sat, 31 Oct 2020 00:32:21 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CNKrP1yQCz4fCk for ; Sat, 31 Oct 2020 00:32:21 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id 2260D1361C for ; Sat, 31 Oct 2020 00:32:21 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-lj1-f170.google.com with SMTP id v19so3781982lji.5 for ; Fri, 30 Oct 2020 17:32:21 -0700 (PDT) X-Gm-Message-State: AOAM530clz7nLGi+Fc/u46ERTTAPptRmo4MeVePk8dx7MnbjuJ5cANhJ X4AfT7aA1CvSwTeuhrvpHg3IuznMtVldQKinG0c= X-Google-Smtp-Source: ABdhPJyNLvas9ClEB7RlynbqpZ7hmdG8Yj87IukcRvLi0cjSh/MBRIErvjcTc14/xD4kEP+atqCcEkJldA650SKtQoI= X-Received: by 2002:a2e:86c8:: with SMTP id n8mr2065289ljj.321.1604104339715; Fri, 30 Oct 2020 17:32:19 -0700 (PDT) MIME-Version: 1.0 References: <202010300313.09U3D0KZ006216@slippy.cwsent.com> <20201030204622.GF2033@zxy.spb.ru> <202010302053.09UKrAXc031272@slippy.cwsent.com> <20201030220809.GG2033@zxy.spb.ru> <202010302234.09UMYA5d032018@slippy.cwsent.com> <20201030224734.GH2033@zxy.spb.ru> <202010302300.09UN0t4A032372@slippy.cwsent.com> <20201030233138.GD34923@zxy.spb.ru> <202010302350.09UNoVcM033686@slippy.cwsent.com> In-Reply-To: From: Matthew Macy Date: Fri, 30 Oct 2020 17:32:08 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: OpenZFS: kldload zfs.ko freezes on i386 4GB memory To: freebsd-current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2020 00:32:21 -0000 > > Getting back to your original question. A more efficient ARC would exercise > your memory more intensely because you are replacing disk reads with memory > reads. And as I said before the old ZFS "found" weak RAM on three separate > occasions in three different machines over the last ten years. You're > advised to replace the marginal memory. Ryan has been able to reproduce this in a VM with 4GB, similarly a VM with 2GB loads just fine. It would seem that 4GB triggers a bug in limit handling. We're hoping that we can simply lower one of the default limits on i386 and make the problem go away. Please don't shoot the messenger when I observe that, generally speaking, i386 is considered a self supported platform due to ZFS general inability to perform well with limited memory or KVA. Long mode has been available on virtually all processors shipped since 2006. Cheers. -M From owner-freebsd-current@freebsd.org Sat Oct 31 00:41:48 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AF9CB45FFFF for ; Sat, 31 Oct 2020 00:41:48 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CNL3H6JGyz4fxZ for ; Sat, 31 Oct 2020 00:41:47 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.229.168]) by shaw.ca with ESMTPA id YexjkfHo1RAWfYexlkdVQ2; Fri, 30 Oct 2020 18:41:46 -0600 X-Authority-Analysis: v=2.4 cv=P9aEOgMu c=1 sm=1 tr=0 ts=5f9cb2ca a=7AlCcx2GqMg+lh9P3BclKA==:117 a=7AlCcx2GqMg+lh9P3BclKA==:17 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=afefHYAZSVUA:10 a=YxBL1-UpAAAA:8 a=KawIFhhbAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=fm1SXRAjbU24maD8A3wA:9 a=CjuIK1q_8ugA:10 a=UJ0tAi3fqDAA:10 a=OJAZQCPpPQ8A:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=sDZbbUVwIjaXAAecbMhh:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [IPv6:fc00:1:1:1::5b]) by spqr.komquats.com (Postfix) with ESMTPS id 22A1FE93; Fri, 30 Oct 2020 17:41:43 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.16.1/8.16.1) with ESMTP id 09V0ffBL035185; Fri, 30 Oct 2020 17:41:41 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202010310041.09V0ffBL035185@slippy.cwsent.com> X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Matthew Macy cc: Cy Schubert , Slawa Olhovchenkov , qroxana , freebsd-current Subject: Re: OpenZFS: kldload zfs.ko freezes on i386 4GB memory In-reply-to: References: <202010300313.09U3D0KZ006216@slippy.cwsent.com> <20201030204622.GF2033@zxy.spb.ru> <202010302053.09UKrAXc031272@slippy.cwsent.com> <20201030220809.GG2033@zxy.spb.ru> <202010302234.09UMYA5d032018@slippy.cwsent.com> <20201030224734.GH2033@zxy.spb.ru> <202010302300.09UN0t4A032372@slippy.cwsent.com> <20201030233138.GD34923@zxy.spb.ru> <202010302350.09UNoVcM033686@slippy.cwsent.com> Comments: In-reply-to Matthew Macy message dated "Fri, 30 Oct 2020 17:30:35 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Oct 2020 17:41:41 -0700 X-CMAE-Envelope: MS4xfKvdoiNwDKFKuX+HsdekYjfHtXCol16V41vbNGa5xAq+YM+Muokbr2yFvRfoNPVSTUsTsYUrO8g8pZAD8DR6cnPVZ7uk3gHDycD+rzacnkIaBX1x1aUq NsaYM3mCtbgeJYfHlBBLsQF7taE174Dx0qNVliaBaXeutw9ejrLNdJ5Dn4LIRl5U4VLUIuVNwKuKrHiMd0sI4d3/UBjr+CKd9GyBQgADhcm2cPKRFuw1Ew0b WNBFV+7sKNRYampayaRg8Fyx67qiHfxcmW3rVCNuy1l+HxiW2mydCgxHhHf3olGz X-Rspamd-Queue-Id: 4CNL3H6JGyz4fxZ X-Spamd-Bar: + X-Spamd-Result: default: False [1.09 / 15.00]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[70.67.229.168:received]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[64.59.136.137:from]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.90)[-0.899]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.25)[0.249]; NEURAL_HAM_LONG(-1.06)[-1.064]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_CC(0.00)[cschubert.com,zxy.spb.ru,mail.ru,freebsd.org]; SUSPICIOUS_RECIPS(1.50)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2020 00:41:48 -0000 In message , Matthew Macy writes: > On Fri, Oct 30, 2020 at 4:50 PM Cy Schubert wrote > : > > > > In message <20201030233138.GD34923@zxy.spb.ru>, Slawa Olhovchenkov writes: > > > On Fri, Oct 30, 2020 at 04:00:55PM -0700, Cy Schubert wrote: > > > > > > > > > > More stresses memory usually refers to performance penalty. > > > > > > > Usually way for better performance is reduce memory access. > > > > > > > > > > > > The reason filesystems (UFS, ZFS, EXT4, etc.) cache is to avoid dis > k > > > > > > accesses. Nanoseconds vs milliseconds. > > > > > > > > > > I mean compared ZoL ZFS ARC vs old (BSD/Opensolaris/Illumos) ZFS ARC. > > > > > Any reaason to rise ARC hit rate in ZoL case? > > > > > > > > That's what hit rate is. It's a memory access instead of a disk access. > > > > That's what you want. > > > > > > Is ZoL ARC hit rate rise from FreeBSD ARC hit rate? > > > > We don't know that. You should be able to find out by running some tests > > that would populate your ARC and run the test again. I see that my > > -DNO_CLEAN buildworlds run faster, when I run them a second or third time > > after making a minor edit, than they did before. Thus I assume it uses > > memory more efficiently. By default it stores more metadata in ARC, 75% > > instead of IIRC 25% by default. > > > > Getting back to your original question. A more efficient ARC would exercise > > your memory more intensely because you are replacing disk reads with memory > > reads. And as I said before the old ZFS "found" weak RAM on three separate > > occasions in three different machines over the last ten years. You're > > advised to replace the marginal memory. > > Ryan has been able to reproduce this in a VM with 4GB, similarly a VM > with 2GB loads just fine. It would seem that 4GB triggers a bug in > limit handling. We're hoping that we can simply lower one of the > default limits on i386 and make the problem go away. > > Please don't shoot the messenger when I observe that, generally > speaking, i386 is considered a self supported platform due to ZFS > general inability to perform well with limited memory or KVA. Long > mode has been available on virtually all processors shipped since > 2006. Yes, I was able to use ZFS on a 2 GB Pentium-M (i386) laptop for many years. ZFS worked well with a little tuning on such a small machine. Last time I booted it was late last year or early this year. It's in a drawer right now. I'll try to pull it out this coming week to test it out. Serendipitous that I was thinking about pulling out that old laptop to test out the new ZFS just last week. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. From owner-freebsd-current@freebsd.org Sat Oct 31 02:26:32 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 93B26464F18 for ; Sat, 31 Oct 2020 02:26:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CNNN72FWMz3ZtB for ; Sat, 31 Oct 2020 02:26:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x830.google.com with SMTP id k90so14236qte.2 for ; Fri, 30 Oct 2020 19:26:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xANjZJBGTuiEBJvECNrW+zBXJgEPHo/mVCz/+B1FXok=; b=Udh05liZYICKSHrDgd2SAXUS4Q2QcjYgj3QWKtSopHm2Oa71+VFeINMW7tZDlVtoFO NSZDNDmXutoKrqOdDXrQLb+DvCNfcS/W9REMyLFsXBgBkcaR/dy5st4vFXx3UwNOi9rW 8Bl73MdkpkiiQ/6ckvl/bbhbOIARcXFtIQxwsop+1tJMh4T0oEA1AE756DZqODr3upvN 91EU1q2e0blWkmgZ2GqDzrmryC5LJZjGrSH0olX79HZo1tFAAtKx2fLz2KKp35ERtwZn t9VBD9K5c2GatqM3c7iyEPf/g+CAPOReXC91Y6s/grPBcIyaGALLUkZ09AIdKZke2Mhj IX0w== X-Gm-Message-State: AOAM531VdDiOXZRgCtc14e4TsiOVuxD5OJ3bFQWpga2/wqXNaZHlLPfL 1Mvn/aBt1WCMtGLd57/aUaxJ4G01/m16MQdbqpYA2Q== X-Google-Smtp-Source: ABdhPJzQ2bAj1dOJf4dIpiNrQpBDPgp/xY4llPMsk3qiQmWiRk087N2WPRrbW7jg359WhE10PQnKWMkXg7c13DkE0OU= X-Received: by 2002:a05:622a:10b:: with SMTP id u11mr5117687qtw.235.1604111190087; Fri, 30 Oct 2020 19:26:30 -0700 (PDT) MIME-Version: 1.0 References: <202010300313.09U3D0KZ006216@slippy.cwsent.com> <20201030204622.GF2033@zxy.spb.ru> <202010302053.09UKrAXc031272@slippy.cwsent.com> <20201030220809.GG2033@zxy.spb.ru> <202010302234.09UMYA5d032018@slippy.cwsent.com> <20201030224734.GH2033@zxy.spb.ru> <202010302300.09UN0t4A032372@slippy.cwsent.com> <20201030233138.GD34923@zxy.spb.ru> <202010302350.09UNoVcM033686@slippy.cwsent.com> <202010310041.09V0ffBL035185@slippy.cwsent.com> In-Reply-To: <202010310041.09V0ffBL035185@slippy.cwsent.com> From: Warner Losh Date: Fri, 30 Oct 2020 20:26:19 -0600 Message-ID: Subject: Re: OpenZFS: kldload zfs.ko freezes on i386 4GB memory To: Cy Schubert Cc: Matthew Macy , Slawa Olhovchenkov , qroxana , freebsd-current X-Rspamd-Queue-Id: 4CNNN72FWMz3ZtB X-Spamd-Bar: / X-Spamd-Result: default: False [-0.50 / 15.00]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; MAILMAN_DEST(0.00)[freebsd-current]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-1.02)[-1.022]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::830:from]; NEURAL_HAM_MEDIUM(-1.03)[-1.031]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; DMARC_NA(0.00)[bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; NEURAL_SPAM_SHORT(0.05)[0.050]; FREEMAIL_CC(0.00)[gmail.com,zxy.spb.ru,mail.ru,freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; SUSPICIOUS_RECIPS(1.50)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2020 02:26:32 -0000 On Fri, Oct 30, 2020 at 6:42 PM Cy Schubert wrote: > In message > om> > , Matthew Macy writes: > > On Fri, Oct 30, 2020 at 4:50 PM Cy Schubert > wrote > > : > > > > > > In message <20201030233138.GD34923@zxy.spb.ru>, Slawa Olhovchenkov > writes: > > > > On Fri, Oct 30, 2020 at 04:00:55PM -0700, Cy Schubert wrote: > > > > > > > > > > > > More stresses memory usually refers to performance penalty. > > > > > > > > Usually way for better performance is reduce memory access. > > > > > > > > > > > > > > The reason filesystems (UFS, ZFS, EXT4, etc.) cache is to > avoid dis > > k > > > > > > > accesses. Nanoseconds vs milliseconds. > > > > > > > > > > > > I mean compared ZoL ZFS ARC vs old (BSD/Opensolaris/Illumos) ZFS > ARC. > > > > > > Any reaason to rise ARC hit rate in ZoL case? > > > > > > > > > > That's what hit rate is. It's a memory access instead of a disk > access. > > > > > That's what you want. > > > > > > > > Is ZoL ARC hit rate rise from FreeBSD ARC hit rate? > > > > > > We don't know that. You should be able to find out by running some > tests > > > that would populate your ARC and run the test again. I see that my > > > -DNO_CLEAN buildworlds run faster, when I run them a second or third > time > > > after making a minor edit, than they did before. Thus I assume it uses > > > memory more efficiently. By default it stores more metadata in ARC, 75% > > > instead of IIRC 25% by default. > > > > > > Getting back to your original question. A more efficient ARC would > exercise > > > your memory more intensely because you are replacing disk reads with > memory > > > reads. And as I said before the old ZFS "found" weak RAM on three > separate > > > occasions in three different machines over the last ten years. You're > > > advised to replace the marginal memory. > > > > Ryan has been able to reproduce this in a VM with 4GB, similarly a VM > > with 2GB loads just fine. It would seem that 4GB triggers a bug in > > limit handling. We're hoping that we can simply lower one of the > > default limits on i386 and make the problem go away. > > > > Please don't shoot the messenger when I observe that, generally > > speaking, i386 is considered a self supported platform due to ZFS > > general inability to perform well with limited memory or KVA. Long > > mode has been available on virtually all processors shipped since > > 2006. > > Yes, I was able to use ZFS on a 2 GB Pentium-M (i386) laptop for many > years. ZFS worked well with a little tuning on such a small machine. Last > time I booted it was late last year or early this year. It's in a drawer > right now. I'll try to pull it out this coming week to test it out. > > Serendipitous that I was thinking about pulling out that old laptop to > test > out the new ZFS just last week. > History has shown that as we tune by default for modern machines, the older machines will need more and more tuning to get reasonable performance. We had issues with the default number of bufs, for example, on small memory footprint machines. The first order tuning helped, but it was only a matter of time before even that was not enough. I suspect that using a smaller ARC on 32-bit platforms will suffice, for now. We should learn from history and understand that it's the first step down the path to the setup not working and gently encourage people to use this time to retool their platforms. This likely will take a year or four if history is any indicator, so there's plenty of time to retool... Warner