From owner-freebsd-hackers@freebsd.org Mon Apr 27 11:23:48 2020 Return-Path: Delivered-To: freebsd-hackers@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 5B9F92B486D for ; Mon, 27 Apr 2020 11:23:48 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 499j8M4BRjz3Nf0 for ; Mon, 27 Apr 2020 11:23:47 +0000 (UTC) (envelope-from jhs@berklix.com) Received: by mailman.nyi.freebsd.org (Postfix) id 8DF1D2B486C; Mon, 27 Apr 2020 11:23:47 +0000 (UTC) Delivered-To: hackers@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 8DB442B486A for ; Mon, 27 Apr 2020 11:23:47 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "slim.berklix.org", Issuer "slim.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 499j8L3tcnz3Ndy; Mon, 27 Apr 2020 11:23:46 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p5DDB7209.dip0.t-ipconnect.de [93.219.114.9]) (authenticated bits=128) by slim.berklix.org (8.15.2/8.15.2) with ESMTPSA id 03RBNcmc084658 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Apr 2020 13:23:42 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 03RBNcBW029374; Mon, 27 Apr 2020 13:23:38 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 03RBNRgr047759; Mon, 27 Apr 2020 13:23:39 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <202004271123.03RBNRgr047759@fire.js.berklix.net> To: webmaster@freebsd.org cc: hackers@freebsd.org Subject: http://www.freebsd.org search box broken again. Fix it. From: "Julian H. Stacey" Organization: http://berklix.com/jhs http://stolenvotes.uk User-agent: EXMH on FreeBSD http://www.berklix.eu/free/ X-From: http://www.berklix.eu/~jhs/ Date: Mon, 27 Apr 2020 13:23:27 +0200 X-Rspamd-Queue-Id: 499j8L3tcnz3Ndy X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 94.185.90.68) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [0.89 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; URL_IN_SUBJECT(1.00)[www.freebsd.org]; NEURAL_HAM_MEDIUM(-0.85)[-0.849,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.16)[-0.158,0]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; IP_SCORE(0.00)[ip: (0.02), ipnet: 94.185.88.0/22(0.01), asn: 33824(-0.00), country: DE(-0.02)]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[68.90.185.94.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33824, ipnet:94.185.88.0/22, country:DE]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 11:23:48 -0000 http://www.freebsd.org has a search box, that's broken & often has been. Try typing any one of ls camera kde 3 Empty pages ! Compare with direct use of the search engine freebsd.org fails to use: https://duckduckgo.com/?q=freebsd.org++ls&t=h_&ia=web The FreeBSD Project ls(1) [freebsd man page] FreeBSD search box was OK decades back I recall, but broken often since (in attempts for local based search I think?). Let's throw it out & revert to something simple & reliable that works. If tinkerers want we could also offer a 2nd button underneath for support of fancy experimental local based search apt to break. Please fix it to call the existing duckduck properly, or if you can't call some other search engine, here's a list http://www.berklix.net/search/ FreeBSD will have lost a lot of interest over a long time, with our search box so often broken, returning nothing or not enough useful. An example of multiple search boxes on http://www.berklix.org/ Type in Jitsi & get https://www.google.com/search?q=jitsi&domains=berklix.org&sitesearch=berklix.org&btnG=Search I've never needed time to maintain it, it's simple & worked for decades. Cheers -- Julian Stacey, Consultant Systems Engineer, BSD Linux http://berklix.com/jhs/ http://www.berklix.org/corona/#masks 150 Euro fine or tie 2 handkerchiefs ? www.bbc.com/news/business-52304821 Brexit 31 Dec 2020 will further hit UK & EU From owner-freebsd-hackers@freebsd.org Mon Apr 27 13:46:39 2020 Return-Path: Delivered-To: freebsd-hackers@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 1BA7F2B9272 for ; Mon, 27 Apr 2020 13:46:39 +0000 (UTC) (envelope-from jhs@berklix.com) 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 499mKB0r0zz43nM for ; Mon, 27 Apr 2020 13:46:37 +0000 (UTC) (envelope-from jhs@berklix.com) Received: by mailman.nyi.freebsd.org (Postfix) id C39B72B926F; Mon, 27 Apr 2020 13:46:36 +0000 (UTC) Delivered-To: hackers@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 B626F2B926B for ; Mon, 27 Apr 2020 13:46:36 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from slim.berklix.org (slim.berklix.org [94.185.90.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "slim.berklix.org", Issuer "slim.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 499mK61Mdzz43k4; Mon, 27 Apr 2020 13:46:33 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p5DDB7209.dip0.t-ipconnect.de [93.219.114.9]) (authenticated bits=128) by slim.berklix.org (8.15.2/8.15.2) with ESMTPSA id 03RDkOKQ085678 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Apr 2020 15:46:31 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id 03RDkNaI030326; Mon, 27 Apr 2020 15:46:23 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id 03RDkBZ2050217; Mon, 27 Apr 2020 15:46:23 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <202004271346.03RDkBZ2050217@fire.js.berklix.net> cc: webmaster@freebsd.org, hackers@freebsd.org Subject: Re: http://www.freebsd.org search box broken again. Fix it. From: "Julian H. Stacey" Organization: http://berklix.com/jhs http://stolenvotes.uk User-agent: EXMH on FreeBSD http://berklix.com/free/ X-From: http://www.berklix.org/~jhs/ In-reply-to: Your message "Mon, 27 Apr 2020 13:23:27 +0200." Date: Mon, 27 Apr 2020 15:46:11 +0200 X-Rspamd-Queue-Id: 499mK61Mdzz43k4 X-Spamd-Bar: +++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of jhs@berklix.com has no SPF policy when checking 94.185.90.68) smtp.mailfrom=jhs@berklix.com X-Spamd-Result: default: False [5.44 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; URL_IN_SUBJECT(1.00)[www.freebsd.org]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[berklix.com]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.54)[0.543,0]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; IP_SCORE(0.00)[ip: (0.02), ipnet: 94.185.88.0/22(0.01), asn: 33824(-0.00), country: DE(-0.02)]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[68.90.185.94.list.dnswl.org : 127.0.10.0]; MISSING_TO(2.00)[]; NEURAL_SPAM_LONG(1.00)[1.000,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33824, ipnet:94.185.88.0/22, country:DE]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 13:46:39 -0000 "Julian H. Stacey" wrote: > http://www.freebsd.org has a search box, that's broken & often has been. > Try typing any one of > ls > camera > kde > 3 Empty pages ! > > Compare with direct use of the search engine freebsd.org fails to use: > https://duckduckgo.com/?q=freebsd.org++ls&t=h_&ia=web > The FreeBSD Project > ls(1) [freebsd man page] > > FreeBSD search box was OK decades back I recall, but broken often > since (in attempts for local based search I think?). Let's throw > it out & revert to something simple & reliable that works. If > tinkerers want we could also offer a 2nd button underneath for > support of fancy experimental local based search apt to break. > > Please fix it to call the existing duckduck properly, or if you can't > call some other search engine, here's a list http://www.berklix.net/search/ > > FreeBSD will have lost a lot of interest over a long time, with our > search box so often broken, returning nothing or not enough useful. > > An example of multiple search boxes on http://www.berklix.org/ > Type in Jitsi & get > https://www.google.com/search?q=jitsi&domains=berklix.org&sitesearch=berklix.org&btnG=Search > I've never needed time to maintain it, it's simple & worked for decades. PS The search box works on https://wiki.freebsd.org/ ! Cheers -- Julian Stacey, Consultant Systems Engineer, BSD Linux http://berklix.com/jhs/ http://www.berklix.org/corona/#masks 150 Euro fine or tie 2 handkerchiefs ? www.bbc.com/news/business-52304821 Brexit 31 Dec 2020 will further hit UK & EU From owner-freebsd-hackers@freebsd.org Mon Apr 27 15:15:36 2020 Return-Path: Delivered-To: freebsd-hackers@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 5CF892BBD71 for ; Mon, 27 Apr 2020 15:15:36 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 499pHr1QCKz4B8L for ; Mon, 27 Apr 2020 15:15:36 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 308B72BBD70; Mon, 27 Apr 2020 15:15:36 +0000 (UTC) Delivered-To: hackers@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 304E42BBD6D for ; Mon, 27 Apr 2020 15:15:36 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: from mail-yb1-f174.google.com (mail-yb1-f174.google.com [209.85.219.174]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) 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 499pHq2xsjz4B8K; Mon, 27 Apr 2020 15:15:35 +0000 (UTC) (envelope-from lwhsu.freebsd@gmail.com) Received: by mail-yb1-f174.google.com with SMTP id t9so2109992ybo.8; Mon, 27 Apr 2020 08:15:35 -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=oeccjHpOr3vFvRDVbei1EF1UGG9ZE9CjhzwTpeHKT40=; b=j1R0kmBxDXnD2pJzTy/38KamsJlj3o92R1KM7QSZevi4DlvU/aTG0QxklD1ZG1SJ9F 9IMoPn6/qNiywTe/6iDuS+q6870FcaLfG3SS8fko5e2pvyeq/eV9onK4wI5AN+dba66x +BwlesbQ/7vLl2TLCfmY+aFHeSA0+N5+4Z9MmAtyoj4DKVGErcwL0ZFjnDUR299PI+dd dPn2xDA50fUVAZ264I14xvJt+u0ETn1rqVvIoOd77KAMKT72hit1bzlJzt+NeUjZOOKA ftO/U4NUYGDx5tjaKuy4+CNJoq8AEUzF0pqzZpgPcSFp3TFFHAdD+h2ifTKRMsY/eaP7 Zl0g== X-Gm-Message-State: AGi0PuZS1s0/TOEpPBAxCcXHY4a17WmAMZn8eUoc1XfiJI5cilkBaNeI pruEw8p3edknihUwqqY1JN1/RRZIWW/e8QLJRJICbiLy X-Google-Smtp-Source: APiQypJD6KDqatP8HLqT+X2YTwBrbaEUZXl7TS81EHeIL2Ex7J4bfx46tLyPwaHCYRsq2Nk7K2hcYlW/5BW03tlfqZs= X-Received: by 2002:a25:d7c5:: with SMTP id o188mr36271541ybg.241.1588000534294; Mon, 27 Apr 2020 08:15:34 -0700 (PDT) MIME-Version: 1.0 References: <202004271123.03RBNRgr047759@fire.js.berklix.net> In-Reply-To: <202004271123.03RBNRgr047759@fire.js.berklix.net> From: Li-Wen Hsu Date: Mon, 27 Apr 2020 23:15:22 +0800 Message-ID: Subject: Re: http://www.freebsd.org search box broken again. Fix it. To: "Julian H. Stacey" Cc: webmaster@freebsd.org, hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 499pHq2xsjz4B8K X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of lwhsufreebsd@gmail.com designates 209.85.219.174 as permitted sender) smtp.mailfrom=lwhsufreebsd@gmail.com X-Spamd-Result: default: False [-2.76 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; URL_IN_SUBJECT(1.00)[www.freebsd.org]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[174.219.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.76)[ip: (-7.94), ipnet: 209.85.128.0/17(-0.40), asn: 15169(-0.43), country: US(-0.05)]; FORGED_SENDER(0.30)[lwhsu@freebsd.org,lwhsufreebsd@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[174.219.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TAGGED_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[lwhsu@freebsd.org,lwhsufreebsd@gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 15:15:36 -0000 On Mon, Apr 27, 2020 at 7:23 PM Julian H. Stacey wrote: > > http://www.freebsd.org has a search box, that's broken & often has been. I think this one helps https://reviews.freebsd.org/D24590 From owner-freebsd-hackers@freebsd.org Tue Apr 28 14:44:14 2020 Return-Path: Delivered-To: freebsd-hackers@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 67A952BB5EC for ; Tue, 28 Apr 2020 14:44:14 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49BPY943ftz3KLL; Tue, 28 Apr 2020 14:44:13 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1588085052; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=ICnKtKYzH/gYHxbsUUTJd6HYC9bzRF60PjNWdX87TyI=; b=HWp78EOsYDHqoZh4qK9OszmbrBBPMSE+PEjBt9Ok9AhU4eQVB0hwllmUqEfAUKwhffTzfQ vaTxse2dpWzq6tLSR48uEMMdiW6JGAxBvA8CvJE/dSgxMf5HpmKqjWGWkYPBxuKS1jBgUt BGyyuhkeHOSYSn74kVZLsS5+AsEdE0g= Received: from skull.home.blih.net (lfbn-idf2-1-900-181.w86-238.abo.wanadoo.fr [86.238.131.181]) by mx.blih.net (OpenSMTPD) with ESMTPSA id 50de9aac (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 28 Apr 2020 14:44:11 +0000 (UTC) Date: Tue, 28 Apr 2020 16:44:08 +0200 From: Emmanuel Vadot To: freebsd-hackers@freebsd.org Cc: hselasky@FreeBSD.org Subject: Linuxkpi lock types Message-Id: <20200428164408.8de0f460c77c5f38f03fe9af@bidouilliste.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49BPY943ftz3KLL X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=HWp78EOs; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-3.93 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-1.43)[ip: (-9.36), ipnet: 212.83.128.0/19(1.81), asn: 12876(0.42), country: FR(0.00)]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 14:44:14 -0000 Hello, I was looking at the linuxkpi locks and notice something that I don't understand. For linux struct mutex we use or sx locks but looking at the doc in linux (Documentation/locking/mutex-design.rst) it seems that those are almost 1:1 our mtx, is there a reason that sx where chosen ? For the linux spinlocks we use MTX_DEF lock, which doesn't seems right at all so same question. Thanks for your answers, -- Emmanuel Vadot From owner-freebsd-hackers@freebsd.org Tue Apr 28 15:04:10 2020 Return-Path: Delivered-To: freebsd-hackers@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 AC1592BC03C for ; Tue, 28 Apr 2020 15:04:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49BQ092b84z3LgC; Tue, 28 Apr 2020 15:04:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id 03SF3vli042259 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 28 Apr 2020 18:04:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 03SF3vli042259 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 03SF3vMH042258; Tue, 28 Apr 2020 18:03:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 28 Apr 2020 18:03:57 +0300 From: Konstantin Belousov To: Emmanuel Vadot Cc: freebsd-hackers@freebsd.org, hselasky@freebsd.org Subject: Re: Linuxkpi lock types Message-ID: <20200428150357.GX2522@kib.kiev.ua> References: <20200428164408.8de0f460c77c5f38f03fe9af@bidouilliste.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200428164408.8de0f460c77c5f38f03fe9af@bidouilliste.com> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 49BQ092b84z3LgC X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all:c]; IP_SCORE_FREEMAIL(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(0.00)[ip: (-2.99), ipnet: 2001:470::/32(-4.65), asn: 6939(-3.60), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 15:04:10 -0000 On Tue, Apr 28, 2020 at 04:44:08PM +0200, Emmanuel Vadot wrote: > > Hello, > > I was looking at the linuxkpi locks and notice something that I don't > understand. > > For linux struct mutex we use or sx locks but looking at the doc in > linux (Documentation/locking/mutex-design.rst) it seems that those are > almost 1:1 our mtx, is there a reason that sx where chosen ? > For the linux spinlocks we use MTX_DEF lock, which doesn't seems right > at all so same question. > > Thanks for your answers, Linux spinlocks must protect interrupt handlers. Since Linuxkpi runs handlers threaded, they should (or must) use normal mutexes in FreeBSD land, so translation of spinlocks to mutexes is fine. If handlers were non-threaded but fast, then linux spinlocks-> FreeBSD mtx_spin is somewhat reasonable, but I believe that Linux interrupt handlers might try to do things like memory allocation which cannot work from FreeBSD fast handlers. Also, running handlers with interrupts enabled improves system responsibility to other events. After spinlocks are translated to sleepable mutexes, it is natural to convert sleepable Linux mutexes to sx'es. I do not think that Linux mutexes provide priority propagation (but I can be wrong), which matches sx behaviour. Also sx provide some more required features like interruptible sleep, which mtx lacks. In other words, it all starts with the decision to run interrupt handlers threaded as most FreeBSD drivers do, and then it is logical to 'step up' each locking primitive. I have some memories the realtime Linux patches did the same. From owner-freebsd-hackers@freebsd.org Tue Apr 28 16:11:38 2020 Return-Path: Delivered-To: freebsd-hackers@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 0FB8A2BE613 for ; Tue, 28 Apr 2020 16:11:38 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mx.blih.net (mx.blih.net [212.83.155.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mx.blih.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49BRV05hHgz3xCX; Tue, 28 Apr 2020 16:11:36 +0000 (UTC) (envelope-from manu@bidouilliste.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bidouilliste.com; s=mx; t=1588090294; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=E6h1d/yYoa/ryUyBIBDdmiF7DPMJHuWe0GrSBA9hfwg=; b=ZfIr2ve3k0sqab+lQC9qqTPqjmmvNS51qiAts1XoOXCxejBkmslU0MmAVisdrBb+L6FZ81 K62AZadGbsHGf59o8n1fbcg5AnoQOs5VgoMe9tzaqixqM8MWIz/CHeKci9eVl487K1KobH qte2SMhLz3M4ofQt33eQ2JEEtOmiSRY= Received: from skull.home.blih.net (lfbn-idf2-1-900-181.w86-238.abo.wanadoo.fr [86.238.131.181]) by mx.blih.net (OpenSMTPD) with ESMTPSA id a193bf94 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 28 Apr 2020 16:11:34 +0000 (UTC) Date: Tue, 28 Apr 2020 18:11:31 +0200 From: Emmanuel Vadot To: Konstantin Belousov Cc: freebsd-hackers@freebsd.org, hselasky@freebsd.org Subject: Re: Linuxkpi lock types Message-Id: <20200428181131.7a075541001564f3a35517e8@bidouilliste.com> In-Reply-To: <20200428150357.GX2522@kib.kiev.ua> References: <20200428164408.8de0f460c77c5f38f03fe9af@bidouilliste.com> <20200428150357.GX2522@kib.kiev.ua> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49BRV05hHgz3xCX X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bidouilliste.com header.s=mx header.b=ZfIr2ve3; dmarc=pass (policy=none) header.from=bidouilliste.com; spf=pass (mx1.freebsd.org: domain of manu@bidouilliste.com designates 212.83.155.74 as permitted sender) smtp.mailfrom=manu@bidouilliste.com X-Spamd-Result: default: False [-3.93 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[bidouilliste.com:s=mx]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bidouilliste.com:+]; DMARC_POLICY_ALLOW(-0.50)[bidouilliste.com,none]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-1.43)[ip: (-9.38), ipnet: 212.83.128.0/19(1.80), asn: 12876(0.42), country: FR(0.00)]; ASN(0.00)[asn:12876, ipnet:212.83.128.0/19, country:FR]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2020 16:11:38 -0000 On Tue, 28 Apr 2020 18:03:57 +0300 Konstantin Belousov wrote: > On Tue, Apr 28, 2020 at 04:44:08PM +0200, Emmanuel Vadot wrote: > > > > Hello, > > > > I was looking at the linuxkpi locks and notice something that I don't > > understand. > > > > For linux struct mutex we use or sx locks but looking at the doc in > > linux (Documentation/locking/mutex-design.rst) it seems that those are > > almost 1:1 our mtx, is there a reason that sx where chosen ? > > For the linux spinlocks we use MTX_DEF lock, which doesn't seems right > > at all so same question. > > > > Thanks for your answers, > > Linux spinlocks must protect interrupt handlers. Since Linuxkpi runs > handlers threaded, they should (or must) use normal mutexes in FreeBSD > land, so translation of spinlocks to mutexes is fine. If handlers were > non-threaded but fast, then linux spinlocks-> FreeBSD mtx_spin is > somewhat reasonable, but I believe that Linux interrupt handlers might > try to do things like memory allocation which cannot work from FreeBSD > fast handlers. > > Also, running handlers with interrupts enabled improves system responsibility > to other events. > > After spinlocks are translated to sleepable mutexes, it is natural to > convert sleepable Linux mutexes to sx'es. I do not think that Linux > mutexes provide priority propagation (but I can be wrong), which > matches sx behaviour. Also sx provide some more required features like > interruptible sleep, which mtx lacks. > > In other words, it all starts with the decision to run interrupt handlers > threaded as most FreeBSD drivers do, and then it is logical to 'step up' > each locking primitive. I have some memories the realtime Linux patches > did the same. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" Thanks for your answer that explain a lot of things. I guess this should be written somewhere ? A comment block in the header file of linuxkpi might be enough. -- Emmanuel Vadot From owner-freebsd-hackers@freebsd.org Wed Apr 29 09:27:22 2020 Return-Path: Delivered-To: freebsd-hackers@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 191382AD90F for ; Wed, 29 Apr 2020 09:27:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.148]) (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 49BtT469crz3ykm for ; Wed, 29 Apr 2020 09:27:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: qP_h6CYVM1mXA9uOJYf0XGUJkrx0.xgdBfCAl3MMUi3hnnsLZk0wH.R8Gb8iHCv I0fDeqGO_vMlIV_84QPewIdOBIjQYTxaBcm091cFiUsiqp1rqotrV1bUEAWjlZ_HUdInCop1aPTu 0ufIyNK2d5bRThjqyJxAKd.QsuVCVfOz_xrrXY5d_Z9jP3pAHg_QQA_kuryMcteR_Slr_qCBC2WO DsKx03ovX.fE7REyE8Wbj3So9ecQ26zO.gG5oE2Lk7Bwj0XO4shI8TwutI7HLTR3oylNadAUVQ9Z AXZxUzxTX07MdWechedTR7axZQCdD1tGhLz4prL147YzKe53WeRruJyp2GpzVXdtJcCV5ZFp94oy rwXWha.oij.u1PSmKTtku0G4kkDTDuGeBej1IX8Yqx5blDgFJf5GVUL8VbVJB3xD8H0AUZwV7Ule bR9CD1valY_5peldEOZ4RizBF8izMRGsyeljOMCHSj8ivcWAUfOLUZnPC8kd3hHd3dsciuGUFau3 Pzdrk7b0oUELX2LCXIT7Z1GPpuPdk.rUQDBeimOIHwBbOjmeh4mq5YOG8iTiz9RgPy5ey5HXEGgG qvcpfuScYpJ0IsIz_.mKNnpMvSOLWVHh6j5wICI_4GkmzGps4XlMlyS3Ov8lPPIRRG3WN.Te9GWz M97zQNXn8WlLSqI5UZ2xjbR_8j1Db1qD6esa6a.WQjNUmv8SD1WVB5eGDaPW9jVl9DAPWyb8Aibo X20Fm2caOOyme4zp6Oxi3T_EK2VAo16VTOdobMms4JCAUAa4xp2dVNx8hHIRhLg8WtUv7TqrGgGw kOFY3o.jE10_cH4YUGWI5KpVL3pl9TSZHm1a8Bmb6Ud7n_zhRmU60Di700lywEnFE2tKJ3etdC9I 0X_oeQQ0QcMeApVCTJHRTor16g0ftjJdSv6fs1VvL5_4NGaukSGHYlXeCKknpA1uvcXuKhoB7x5r CcjDha042FhHjHyH4yYWsczY0QvuUGmzhKWKsWN4i2UAnqgMrXkA15xruJOr9KE6ZAXvkLWyIcFO L.._z1Qv9ajVqD5r8epLhGFV3QocdB3bt6PPORYrcW63pj.jRJqt3RLtGrG3CIvTSS2ZvF.fP6nm 8XJwEv2Kq9S4S3kaSTRhvYMfJJ.8n2TQHq2.r5Zl_25Mqxa74q1gSFBAr8eEQCbhpXbu6Wxz2dw0 cl60YieM2_5zLpeYPMiRc3rwhVOy02RHWrmxc86R8i8cD2sg1m4tq1LtZ.hHeUqooyg7YDBZSavu KUTsir_kVmPRVhLUBH0L2sbYEtt_GuY8vOishCO0q1FhaLVNJWkcUTmHwirj.W1F77zF0o8W8nsO n2XPsuGRYuv5hLCv._0vNJFdfeHS6TyFsaSWfuoCiS2URT2Nqt7HzhZhlkfNHXBG.Lt6_IEqeR7L eTQVJub35.1DG7Em8SuN4Hjw- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Wed, 29 Apr 2020 09:27:18 +0000 Received: by smtp423.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a91d4d57bd520584944fe9662aa6641f; Wed, 29 Apr 2020 09:27:13 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: 32-bit powerpc head -r360311 has signal 11 process crashes with rendezvous_request involved (old PowerMac dual-socket, 1 core each) Message-Id: <76D3A482-98BC-44C3-B84D-504A012CA8D8@yahoo.com> Date: Wed, 29 Apr 2020 02:27:11 -0700 To: FreeBSD PowerPC ML , FreeBSD Hackers X-Mailer: Apple Mail (2.3608.80.23.2.2) References: <76D3A482-98BC-44C3-B84D-504A012CA8D8.ref@yahoo.com> X-Rspamd-Queue-Id: 49BtT469crz3ykm X-Spamd-Bar: / X-Spamd-Result: default: False [-0.61 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.03)[-0.031,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.08)[-0.078,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (6.26), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[148.66.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[148.66.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2020 09:27:22 -0000 Since updating from head -r359427 based to head -r360311 base (my own non-debug builds), various things report segmentation faults. It appears that rendezvous_request may always be involved. I've not had time (yet) to deal with substituting a debug kernel from: https://artifact.ci.freebsd.org/snapshot/head/r360311/powerpc/powerpc/ I expect to do so at some point. I give 2 examples below (mountd and rpcbind). Both involve rendezvous_request and svc_getreq_common . First mountd : # gdb mountd /mountd.core=20 GNU gdb (GDB) 9.1 [GDB v9.1 for FreeBSD] Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later = . . . Reading symbols from mountd... Reading symbols from /usr/lib/debug//usr/sbin/mountd.debug... [New LWP 100105] Core was generated by `/usr/sbin/mountd -r'. Program terminated with signal SIGSEGV, Segmentation fault. #0 atomic_load_u (a=3D, mo=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/atomic.h:70 warning: Source file is more recent than executable. 70 JEMALLOC_GENERATE_INT_ATOMICS(unsigned, u, LG_SIZEOF_INT) (gdb) bt #0 atomic_load_u (a=3D, mo=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/atomic.h:70 #1 rtree_leaf_elm_szind_read (tsdn=3D, rtree=3D, elm=3D, dependent=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/rtree.h:230 #2 rtree_szind_slab_read (tsdn=3D0x50094018, rtree=3D, = rtree_ctx=3D0x50094044, key=3D1869636193, dependent=3Dtrue, = r_szind=3D, r_slab=3D) at /usr/src/contrib/jemalloc/include/jemalloc/internal/rtree.h:504 #3 ifree (tsd=3D, ptr=3D0x6f706261, tcache=3D, slow_path=3Dfalse) at jemalloc_jemalloc.c:2574 #4 __je_free_default (ptr=3D0x6f706261) at jemalloc_jemalloc.c:2775 #5 0x50235db0 in __free (ptr=3D0x6f706261) at jemalloc_jemalloc.c:2852 #6 0x5026525c in freenetconfigent (netconfigp=3D0x50049170) at = /usr/src/lib/libc/rpc/getnetconfig.c:540 #7 0x50260d8c in __rpc_sockinfo2netid (sip=3D, = netid=3D) at /usr/src/lib/libc/rpc/rpc_generic.c:573 #8 0x502521f0 in makefd_xprt (fd=3D10, sendsize=3D9000, recvsize=3D9000) = at /usr/src/lib/libc/rpc/svc_vc.c:270 #9 0x50252fa4 in rendezvous_request (xprt=3D0x5007b120, msg=3D) at /usr/src/lib/libc/rpc/svc_vc.c:315 #10 0x50254588 in svc_getreq_common (fd=3D) at = /usr/src/lib/libc/rpc/svc.c:640 #11 0x502543d0 in svc_getreqset (readfds=3D) at = /usr/src/lib/libc/rpc/svc.c:611 #12 0x1001434c in main (argc=3D, argv=3D0xffffde3c) at = /usr/src/usr.sbin/mountd/mountd.c:683 (gdb) disass Dump of assembler code for function __je_free_default: 0x50235244 <+0>: mflr r0 0x50235248 <+4>: stw r0,4(r1) 0x5023524c <+8>: stwu r1,-80(r1) 0x50235250 <+12>: stw r30,72(r1) 0x50235254 <+16>: stw r21,36(r1) 0x50235258 <+20>: stw r22,40(r1) 0x5023525c <+24>: stw r23,44(r1) 0x50235260 <+28>: stw r24,48(r1) 0x50235264 <+32>: stw r25,52(r1) 0x50235268 <+36>: stw r26,56(r1) 0x5023526c <+40>: stw r27,60(r1) 0x50235270 <+44>: stw r28,64(r1) 0x50235274 <+48>: stw r29,68(r1) 0x50235278 <+52>: bl 0x5023527c <__je_free_default+56> 0x5023527c <+56>: mr r28,r3 0x50235280 <+60>: mflr r30 0x50235284 <+64>: addis r30,r30,14 0x50235288 <+68>: addi r30,r30,-20816 0x5023528c <+72>: lwz r4,64(r30) 0x50235290 <+76>: lwz r5,6188(r30) 0x50235294 <+80>: lwz r4,0(r4) 0x50235298 <+84>: stw r4,32(r1) 0x5023529c <+88>: lbz r4,0(r5) 0x502352a0 <+92>: cmplwi r4,0 0x502352a4 <+96>: bne 0x502353c4 <__je_free_default+384> 0x502352a8 <+100>: cmplwi r28,0 0x502352ac <+104>: beq 0x50235378 <__je_free_default+308> 0x502352b0 <+108>: addi r3,r30,4332 0x502352b4 <+112>: rlwinm r24,r28,0,0,9 0x502352b8 <+116>: bl 0x502f06b4 = <00000000.plt_pic32.__tls_get_addr> 0x502352bc <+120>: rlwinm r26,r28,13,25,28 0x502352c0 <+124>: mr r29,r3 0x502352c4 <+128>: lbz r3,0(r3) 0x502352c8 <+132>: cmplwi r3,0 0x502352cc <+136>: bne 0x502353fc <__je_free_default+440> 0x502352d0 <+140>: add r25,r29,r26 0x502352d4 <+144>: lwz r3,44(r25) 0x502352d8 <+148>: addi r27,r29,44 0x502352dc <+152>: cmplw r3,r24 0x502352e0 <+156>: bne 0x50235578 <__je_free_default+820> 0x502352e4 <+160>: lwz r3,48(r25) 0x502352e8 <+164>: rlwinm r4,r28,20,22,31 0x502352ec <+168>: mulli r4,r4,12 0x502352f0 <+172>: add r3,r3,r4 =3D> 0x502352f4 <+176>: lwz r6,4(r3) 0x502352f8 <+180>: lwz r5,4368(r30) 0x502352fc <+184>: addi r26,r29,288 0x50235300 <+188>: lbz r4,8(r3) 0x50235304 <+192>: rlwinm r3,r6,2,0,29 0x50235308 <+196>: lwz r7,28(r29) 0x5023530c <+200>: lwzx r5,r5,r3 0x50235310 <+204>: lwz r8,24(r29) 0x50235314 <+208>: andi. r4,r4,1 0x50235318 <+212>: addc r4,r7,r5 0x5023531c <+216>: addze r5,r8 0x50235320 <+220>: stw r5,24(r29) 0x50235324 <+224>: stw r4,28(r29) 0x50235328 <+228>: ble 0x50235534 <__je_free_default+752> . . . (gdb) info reg r0 0x50235c04 1344494596 r1 0xffffcfb0 4294954928 r2 0x5009b018 1342812184 r3 0x2448 9288 r4 0x500940ac 1342783660 r5 0x2448 9288 r6 0x500940cc 1342783692 r7 0x1 1 r8 0x0 0 r9 0x80808080 2155905152 r10 0xc 12 r11 0x502e3b50 1345207120 r12 0x500491a0 1342476704 r13 0x0 0 r14 0x1 1 r15 0x10040000 268697600 r16 0x0 0 r17 0x10040000 268697600 r18 0x2 2 r19 0x0 0 r20 0x1 1 r21 0x5007b164 1342681444 r22 0xffffd2dc 4294955740 r23 0x80 128 r24 0x6f400000 1866465280 r25 0x50094080 1342783616 r26 0x68 104 r27 0x50094044 1342783556 r28 0x6f706261 1869636193 r29 0x50094018 1342783512 r30 0x5031012c 1345388844 r31 0x10040000 268697600 pc 0x502352f4 0x502352f4 <__je_free_default+176> msr cr 0x242008a4 606079140 lr 0x50235c04 0x50235c04 <__je_free_default+2496> ctr 0x0 0 xer 0x0 0 fpscr 0x0 0 vscr vrsave Then rpcbind : # gdb rpcbind /rpcbind.core=20 GNU gdb (GDB) 9.1 [GDB v9.1 for FreeBSD] Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later = . . . Reading symbols from rpcbind... Reading symbols from /usr/lib/debug//usr/sbin/rpcbind.debug... [New LWP 100098] Core was generated by `/usr/sbin/rpcbind'. Program terminated with signal SIGSEGV, Segmentation fault. #0 __xdrrec_setnonblock (xdrs=3D0x500472d8, maxrec=3D9000) at = /usr/src/lib/libc/xdr/xdr_rec.c:607 607 rstrm->nonblock =3D TRUE; (gdb) bt #0 __xdrrec_setnonblock (xdrs=3D0x500472d8, maxrec=3D9000) at = /usr/src/lib/libc/xdr/xdr_rec.c:607 #1 0x502440d4 in rendezvous_request (xprt=3D, = msg=3D) at /usr/src/lib/libc/rpc/svc_vc.c:348 #2 0x50245588 in svc_getreq_common (fd=3D) at = /usr/src/lib/libc/rpc/svc.c:640 #3 0x5024580c in svc_getreq_poll (pfdp=3D, pollretval=3D1)= at /usr/src/lib/libc/rpc/svc.c:739 #4 0x10018568 in my_svc_run () at = /usr/src/usr.sbin/rpcbind/rpcb_svc_com.c:1167 #5 0x10014ad8 in main (argc=3D, argv=3D) = at /usr/src/usr.sbin/rpcbind/rpcbind.c:250 (gdb) disass Dump of assembler code for function __xdrrec_setnonblock: 0x50250468 <+0>: lwz r5,12(r3) 0x5025046c <+4>: li r6,1 0x50250470 <+8>: cmplwi r4,0 =3D> 0x50250474 <+12>: stw r6,64(r5) 0x50250478 <+16>: bne 0x50250480 <__xdrrec_setnonblock+24> 0x5025047c <+20>: lwz r4,60(r5) 0x50250480 <+24>: li r3,1 0x50250484 <+28>: stw r4,92(r5) 0x50250488 <+32>: blr End of assembler dump. (gdb) info reg r0 0x5c 92 r1 0xffffb400 4294947840 r2 0x500a1018 1342836760 r3 0x500472d8 1342468824 r4 0x2328 9000 r5 0x2020 8224 r6 0x1 1 r7 0xffffb364 4294947684 r8 0x500472f4 1342468852 r9 0x0 0 r10 0x20 32 r11 0x502d8ea0 1345162912 r12 0x24200880 606079104 r13 0x0 0 r14 0x0 0 r15 0xffffbc28 4294949928 r16 0x10002848 268445768 r17 0x10040000 268697600 r18 0x2 2 r19 0x0 0 r20 0x1 1 r21 0x5004c044 1342488644 r22 0xffffb63c 4294948412 r23 0x80 128 r24 0x50048010 1342472208 r25 0x14 20 r26 0xffffb630 4294948400 r27 0x500472d0 1342468816 r28 0xe 14 r29 0x50047220 1342468640 r30 0x5030112c 1345327404 r31 0x10040000 268697600 pc 0x50250474 0x50250474 <__xdrrec_setnonblock+12> msr cr 0x44200080 1142947968 lr 0x502440d4 0x502440d4 ctr 0x502d8ea0 1345162912 xer 0x0 0 fpscr 0x0 0 vscr vrsave dhclient and sendmail have notices of signal 11's but I do not find any .core files around for them. Prior to this upgrade I was having no such problems with the 32-bit powerpc PowerMac. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Thu Apr 30 04:29:36 2020 Return-Path: Delivered-To: freebsd-hackers@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 D94912CF148 for ; Thu, 30 Apr 2020 04:29:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84]) (using TLSv1.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 49CMq33pk3z4GCt for ; Thu, 30 Apr 2020 04:29:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: Z4.Ae34VM1nCsJFbJN2uvHhoifVHjFdTkK9eNqxMn6Nzb83d1VjJ7EoDkcb1.hU FgXPvOFMjM3zg23Rt1o9npMj491fWhdT4zXK7tK_Bas4xjN9zWyTH20ZFkGmS7SPvOckORnna2k6 In..Xu2HCjh_SD8uWNGu72cCDS3wNUPzNblc3_nycVXvYvH1ZKxIe5J23fb2r3_RSiyIqZyB_6da MiAaekYx7Q99EvXmh2Q5ZCeV8tpdwZo2tkPqvS294XdjaaE7.yOhiK9jry.R5X8q6qbQfiTA8L7z opZVJtcuLmT9Ev2RNIvAvjqllnuekqrkHSKIK.2Y8SC5YJGw52009EeczbWfarU8hfCjuHJ4F9iK rRm6BEVR.moFmRMDPGOYuBqq2PjFqPFXEM.KEorYSQRV_HgqNuMwbXan5bx7W3KNrsuzRZU5gydF T4kl6pvJeKe.JWIGcoJOzhEc4ZUAwpxUsWsaiBYZxOAWJQqQ_aTywNlxUNHUBSMvj6gdNLXomak3 9q6Z_zYPBoiZRTNrgyiNttpZ0I5RbpUokJv7jyuOKnj3CqA94dDC0R65L3ta_x4RUO1MgbWuwsEc GdjkUQM2uZPWNgxgUnqgNDVZYON8MHw_Bvn2.YNxoUL6v_0jqdufHtAWJRMrDQV2GoGVE8hf75kV fS6RcDREycUVSKaLn1d05zKpqC12bMWqVFMflUI.p6fnrUkssl547M_nSRGbOPSLpyihLTZkSXuv S_AwUVphbFKsWf4HJFHZBhE5JC7.x6cjVg7weLCHykCWmPCTUGg_N54D0zXuIDo1XZCPyn9X_4Fh 4QeYOQF1rSK9xDKCHBa66XPysQaXxFTNpNWGd3jmt846IqGcOd39qT_cHzPsOLsZ9bc_9NJ4hoFx SLoDUqTlGhZfCyW_f3wglv3Ysa2.hJgc1t7JiZhT6hw6ynDGSmPHEFfdDhe1vD0f2uPZmGxMPhvw qHhUEHBWrdo2yQUCXegEd6wjVbZyZ3Trdegv3D1kOwHJcSNfG3rBOwVzYOQaPbJGPxDCqp49u4D4 33xdiifDiAAEbiuwNm59UWR5In6RG4hGf9HNCVY7o6u6UjrML0mfznvVr2RtD9SFj9RKCsKp2qnR KY6n3IbDa6_sRu1t4fFDCU3I11cqapVcBr.V8LqBa7z8CkRBDMgt5rG0oZ7iPF3ia68CTFuTdf6X SMP7AKd8BXvdskoVdcZcxWdDGhOA9KVeStUfHPXF4Rgmx9CldgdNHx1PAshLVZxQWlhZbfoZbsV1 V9YRk7VNNk2UziyWxqarhkVaGbEtl95r90cUYLHUcqBqVnKAx.sh5w_jdSlpw9EsfD9sTZbP5MG0 HKdRDOWJ1mbMf0c4.DEudbj1uSAf6_vi2ahy4ZqvIixRwcgIxPDUqgCLMT9XuETzl0UGnRDKhlg0 ilwJhX7I6oYxSkS7FowcSibM- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Thu, 30 Apr 2020 04:29:33 +0000 Received: by smtp408.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 68cf0fcb3bf0aff9535bdacf2555ea45; Thu, 30 Apr 2020 04:29:32 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: 32-bit powerpc head -r360311 has signal 11 process crashes with rendezvous_request involved (old PowerMac dual-socket, 1 core each) Date: Wed, 29 Apr 2020 21:29:31 -0700 References: <76D3A482-98BC-44C3-B84D-504A012CA8D8@yahoo.com> To: FreeBSD PowerPC ML , FreeBSD Hackers In-Reply-To: <76D3A482-98BC-44C3-B84D-504A012CA8D8@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49CMq33pk3z4GCt X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.36 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.90)[-0.901,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.96)[-0.959,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (1.37), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[84.65.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[84.65.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 04:29:36 -0000 [Notes on using the artifact.ci head -3260311 debug-kernel added.] On 2020-Apr-29, at 02:27, Mark Millard wrote: > Since updating from head -r359427 based to head -r360311 base > (my own non-debug builds), various things report segmentation > faults. It appears that rendezvous_request may always be > involved. I've not had time (yet) to deal with substituting a > debug kernel from: >=20 > https://artifact.ci.freebsd.org/snapshot/head/r360311/powerpc/powerpc/ >=20 > I expect to do so at some point. >=20 >=20 > I give 2 examples below (mountd and rpcbind). Both involve > rendezvous_request and svc_getreq_common . >=20 > First mountd : >=20 > # gdb mountd /mountd.core=20 > GNU gdb (GDB) 9.1 [GDB v9.1 for FreeBSD] > Copyright (C) 2020 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later = > . . . > Reading symbols from mountd... > Reading symbols from /usr/lib/debug//usr/sbin/mountd.debug... > [New LWP 100105] > Core was generated by `/usr/sbin/mountd -r'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 atomic_load_u (a=3D, mo=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/atomic.h:70 >=20 > warning: Source file is more recent than executable. > 70 JEMALLOC_GENERATE_INT_ATOMICS(unsigned, u, LG_SIZEOF_INT) > (gdb) bt > #0 atomic_load_u (a=3D, mo=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/atomic.h:70 > #1 rtree_leaf_elm_szind_read (tsdn=3D, = rtree=3D, elm=3D, dependent=3D) at /usr/src/contrib/jemalloc/include/jemalloc/internal/rtree.h:230 > #2 rtree_szind_slab_read (tsdn=3D0x50094018, rtree=3D, = rtree_ctx=3D0x50094044, key=3D1869636193, dependent=3Dtrue, = r_szind=3D, r_slab=3D) > at /usr/src/contrib/jemalloc/include/jemalloc/internal/rtree.h:504 > #3 ifree (tsd=3D, ptr=3D0x6f706261, tcache=3D, slow_path=3Dfalse) at jemalloc_jemalloc.c:2574 > #4 __je_free_default (ptr=3D0x6f706261) at jemalloc_jemalloc.c:2775 > #5 0x50235db0 in __free (ptr=3D0x6f706261) at = jemalloc_jemalloc.c:2852 > #6 0x5026525c in freenetconfigent (netconfigp=3D0x50049170) at = /usr/src/lib/libc/rpc/getnetconfig.c:540 > #7 0x50260d8c in __rpc_sockinfo2netid (sip=3D, = netid=3D) at /usr/src/lib/libc/rpc/rpc_generic.c:573 > #8 0x502521f0 in makefd_xprt (fd=3D10, sendsize=3D9000, = recvsize=3D9000) at /usr/src/lib/libc/rpc/svc_vc.c:270 > #9 0x50252fa4 in rendezvous_request (xprt=3D0x5007b120, = msg=3D) at /usr/src/lib/libc/rpc/svc_vc.c:315 > #10 0x50254588 in svc_getreq_common (fd=3D) at = /usr/src/lib/libc/rpc/svc.c:640 > #11 0x502543d0 in svc_getreqset (readfds=3D) at = /usr/src/lib/libc/rpc/svc.c:611 > #12 0x1001434c in main (argc=3D, argv=3D0xffffde3c) at = /usr/src/usr.sbin/mountd/mountd.c:683 >=20 > (gdb) disass > Dump of assembler code for function __je_free_default: > 0x50235244 <+0>: mflr r0 > 0x50235248 <+4>: stw r0,4(r1) > 0x5023524c <+8>: stwu r1,-80(r1) > 0x50235250 <+12>: stw r30,72(r1) > 0x50235254 <+16>: stw r21,36(r1) > 0x50235258 <+20>: stw r22,40(r1) > 0x5023525c <+24>: stw r23,44(r1) > 0x50235260 <+28>: stw r24,48(r1) > 0x50235264 <+32>: stw r25,52(r1) > 0x50235268 <+36>: stw r26,56(r1) > 0x5023526c <+40>: stw r27,60(r1) > 0x50235270 <+44>: stw r28,64(r1) > 0x50235274 <+48>: stw r29,68(r1) > 0x50235278 <+52>: bl 0x5023527c <__je_free_default+56> > 0x5023527c <+56>: mr r28,r3 > 0x50235280 <+60>: mflr r30 > 0x50235284 <+64>: addis r30,r30,14 > 0x50235288 <+68>: addi r30,r30,-20816 > 0x5023528c <+72>: lwz r4,64(r30) > 0x50235290 <+76>: lwz r5,6188(r30) > 0x50235294 <+80>: lwz r4,0(r4) > 0x50235298 <+84>: stw r4,32(r1) > 0x5023529c <+88>: lbz r4,0(r5) > 0x502352a0 <+92>: cmplwi r4,0 > 0x502352a4 <+96>: bne 0x502353c4 <__je_free_default+384> > 0x502352a8 <+100>: cmplwi r28,0 > 0x502352ac <+104>: beq 0x50235378 <__je_free_default+308> > 0x502352b0 <+108>: addi r3,r30,4332 > 0x502352b4 <+112>: rlwinm r24,r28,0,0,9 > 0x502352b8 <+116>: bl 0x502f06b4 = <00000000.plt_pic32.__tls_get_addr> > 0x502352bc <+120>: rlwinm r26,r28,13,25,28 > 0x502352c0 <+124>: mr r29,r3 > 0x502352c4 <+128>: lbz r3,0(r3) > 0x502352c8 <+132>: cmplwi r3,0 > 0x502352cc <+136>: bne 0x502353fc <__je_free_default+440> > 0x502352d0 <+140>: add r25,r29,r26 > 0x502352d4 <+144>: lwz r3,44(r25) > 0x502352d8 <+148>: addi r27,r29,44 > 0x502352dc <+152>: cmplw r3,r24 > 0x502352e0 <+156>: bne 0x50235578 <__je_free_default+820> > 0x502352e4 <+160>: lwz r3,48(r25) > 0x502352e8 <+164>: rlwinm r4,r28,20,22,31 > 0x502352ec <+168>: mulli r4,r4,12 > 0x502352f0 <+172>: add r3,r3,r4 > =3D> 0x502352f4 <+176>: lwz r6,4(r3) > 0x502352f8 <+180>: lwz r5,4368(r30) > 0x502352fc <+184>: addi r26,r29,288 > 0x50235300 <+188>: lbz r4,8(r3) > 0x50235304 <+192>: rlwinm r3,r6,2,0,29 > 0x50235308 <+196>: lwz r7,28(r29) > 0x5023530c <+200>: lwzx r5,r5,r3 > 0x50235310 <+204>: lwz r8,24(r29) > 0x50235314 <+208>: andi. r4,r4,1 > 0x50235318 <+212>: addc r4,r7,r5 > 0x5023531c <+216>: addze r5,r8 > 0x50235320 <+220>: stw r5,24(r29) > 0x50235324 <+224>: stw r4,28(r29) > 0x50235328 <+228>: ble 0x50235534 <__je_free_default+752> > . . . >=20 > (gdb) info reg > r0 0x50235c04 1344494596 > r1 0xffffcfb0 4294954928 > r2 0x5009b018 1342812184 > r3 0x2448 9288 > r4 0x500940ac 1342783660 > r5 0x2448 9288 > r6 0x500940cc 1342783692 > r7 0x1 1 > r8 0x0 0 > r9 0x80808080 2155905152 > r10 0xc 12 > r11 0x502e3b50 1345207120 > r12 0x500491a0 1342476704 > r13 0x0 0 > r14 0x1 1 > r15 0x10040000 268697600 > r16 0x0 0 > r17 0x10040000 268697600 > r18 0x2 2 > r19 0x0 0 > r20 0x1 1 > r21 0x5007b164 1342681444 > r22 0xffffd2dc 4294955740 > r23 0x80 128 > r24 0x6f400000 1866465280 > r25 0x50094080 1342783616 > r26 0x68 104 > r27 0x50094044 1342783556 > r28 0x6f706261 1869636193 > r29 0x50094018 1342783512 > r30 0x5031012c 1345388844 > r31 0x10040000 268697600 > pc 0x502352f4 0x502352f4 <__je_free_default+176> > msr > cr 0x242008a4 606079140 > lr 0x50235c04 0x50235c04 <__je_free_default+2496> > ctr 0x0 0 > xer 0x0 0 > fpscr 0x0 0 > vscr > vrsave >=20 >=20 > Then rpcbind : >=20 > # gdb rpcbind /rpcbind.core=20 > GNU gdb (GDB) 9.1 [GDB v9.1 for FreeBSD] > Copyright (C) 2020 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later = > . . . > Reading symbols from rpcbind... > Reading symbols from /usr/lib/debug//usr/sbin/rpcbind.debug... > [New LWP 100098] > Core was generated by `/usr/sbin/rpcbind'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 __xdrrec_setnonblock (xdrs=3D0x500472d8, maxrec=3D9000) at = /usr/src/lib/libc/xdr/xdr_rec.c:607 > 607 rstrm->nonblock =3D TRUE; > (gdb) bt > #0 __xdrrec_setnonblock (xdrs=3D0x500472d8, maxrec=3D9000) at = /usr/src/lib/libc/xdr/xdr_rec.c:607 > #1 0x502440d4 in rendezvous_request (xprt=3D, = msg=3D) at /usr/src/lib/libc/rpc/svc_vc.c:348 > #2 0x50245588 in svc_getreq_common (fd=3D) at = /usr/src/lib/libc/rpc/svc.c:640 > #3 0x5024580c in svc_getreq_poll (pfdp=3D, = pollretval=3D1) at /usr/src/lib/libc/rpc/svc.c:739 > #4 0x10018568 in my_svc_run () at = /usr/src/usr.sbin/rpcbind/rpcb_svc_com.c:1167 > #5 0x10014ad8 in main (argc=3D, argv=3D) at /usr/src/usr.sbin/rpcbind/rpcbind.c:250 >=20 > (gdb) disass > Dump of assembler code for function __xdrrec_setnonblock: > 0x50250468 <+0>: lwz r5,12(r3) > 0x5025046c <+4>: li r6,1 > 0x50250470 <+8>: cmplwi r4,0 > =3D> 0x50250474 <+12>: stw r6,64(r5) > 0x50250478 <+16>: bne 0x50250480 <__xdrrec_setnonblock+24> > 0x5025047c <+20>: lwz r4,60(r5) > 0x50250480 <+24>: li r3,1 > 0x50250484 <+28>: stw r4,92(r5) > 0x50250488 <+32>: blr > End of assembler dump. >=20 > (gdb) info reg > r0 0x5c 92 > r1 0xffffb400 4294947840 > r2 0x500a1018 1342836760 > r3 0x500472d8 1342468824 > r4 0x2328 9000 > r5 0x2020 8224 > r6 0x1 1 > r7 0xffffb364 4294947684 > r8 0x500472f4 1342468852 > r9 0x0 0 > r10 0x20 32 > r11 0x502d8ea0 1345162912 > r12 0x24200880 606079104 > r13 0x0 0 > r14 0x0 0 > r15 0xffffbc28 4294949928 > r16 0x10002848 268445768 > r17 0x10040000 268697600 > r18 0x2 2 > r19 0x0 0 > r20 0x1 1 > r21 0x5004c044 1342488644 > r22 0xffffb63c 4294948412 > r23 0x80 128 > r24 0x50048010 1342472208 > r25 0x14 20 > r26 0xffffb630 4294948400 > r27 0x500472d0 1342468816 > r28 0xe 14 > r29 0x50047220 1342468640 > r30 0x5030112c 1345327404 > r31 0x10040000 268697600 > pc 0x50250474 0x50250474 = <__xdrrec_setnonblock+12> > msr > cr 0x44200080 1142947968 > lr 0x502440d4 0x502440d4 > ctr 0x502d8ea0 1345162912 > xer 0x0 0 > fpscr 0x0 0 > vscr > vrsave >=20 >=20 > dhclient and sendmail have notices of signal 11's > but I do not find any .core files around for them. >=20 > Prior to this upgrade I was having no such problems > with the 32-bit powerpc PowerMac. I substituted the debug-kernel from: = https://artifact.ci.freebsd.org/snapshot/head/r360311/powerpc/powerpc/kern= el.txz and with it there is no evidence so far of the problem(s) occurring. Since the same world build is in use in both contexts, it looks like the kernel is what makes the difference for the problem(s). With the debug-kernel avoiding the problem, I've yet to figure out how to gather evidence. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Thu Apr 30 19:16:05 2020 Return-Path: Delivered-To: freebsd-hackers@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 B99212C608A for ; Thu, 30 Apr 2020 19:16:05 +0000 (UTC) (envelope-from kuku@kukulies.org) Received: from mail.kukulies.org (mail.kukulies.org [116.203.115.43]) by mx1.freebsd.org (Postfix) with ESMTP id 49ClTw69fsz3wht for ; Thu, 30 Apr 2020 19:16:04 +0000 (UTC) (envelope-from kuku@kukulies.org) Received: from localhost (localhost [127.0.0.1]) by mail.kukulies.org (Postfix) with ESMTP id 6DD7B10276A for ; Thu, 30 Apr 2020 21:16:03 +0200 (CEST) Received: from mail.kukulies.org ([127.0.0.1]) by localhost (mail.kukulies.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlNgbbCv9r6G for ; Thu, 30 Apr 2020 21:16:03 +0200 (CEST) Received: from christophs-mbp.fritz.box (p57A1FCC2.dip0.t-ipconnect.de [87.161.252.194]) by mail.kukulies.org (Postfix) with ESMTPSA id D2022102769 for ; Thu, 30 Apr 2020 21:16:02 +0200 (CEST) From: Christoph Kukulies Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Building x11 port fails (12.1 Release) Message-Id: <4EAE257B-A60B-465F-8502-66B1DB9C8FFF@kukulies.org> Date: Thu, 30 Apr 2020 21:16:02 +0200 To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49ClTw69fsz3wht X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of kuku@kukulies.org has no SPF policy when checking 116.203.115.43) smtp.mailfrom=kuku@kukulies.org X-Spamd-Result: default: False [4.69 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; URI_COUNT_ODD(1.00)[5]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[kukulies.org]; NEURAL_SPAM_MEDIUM(0.89)[0.892,0]; NEURAL_SPAM_LONG(1.00)[0.998,0]; R_SPF_NA(0.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:24940, ipnet:116.203.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.30)[ipnet: 116.203.0.0/16(3.06), asn: 24940(-1.54), country: DE(-0.02)]; RECEIVED_SPAMHAUS_PBL(0.00)[194.252.161.87.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2020 19:16:05 -0000 I installed a FreeBSD 12.1 from the distribution today and was trying to = build the x11 port. Here is the failure: =3D=3D=3D> 3ddesktop =3D=3D=3D> 3ddesktop-0.2.9_14 depends on file: = /usr/local/libdata/pkgconfig/xmu.pc - not found =3D=3D=3D> libXmu-1.1.3,1 depends on package: pkgconf>=3D1.3.0_1 - = found =3D=3D=3D> libXmu-1.1.3,1 depends on package: xorgproto>=3D0 - found =3D=3D=3D> libXmu-1.1.3,1 depends on file: = /usr/local/libdata/pkgconfig/xorg-macros.pc - found =3D=3D=3D> libXmu-1.1.3,1 depends on file: = /usr/local/libdata/pkgconfig/x11.pc - not found =3D=3D=3D> libX11-1.6.8,1 depends on package: pkgconf>=3D1.3.0_1 - = found =3D=3D=3D> libX11-1.6.8,1 depends on package: perl5>=3D5.30.r1<5.31 - = found =3D=3D=3D> libX11-1.6.8,1 depends on file: = /usr/local/libdata/pkgconfig/xtrans.pc - found =3D=3D=3D> libX11-1.6.8,1 depends on package: xorgproto>=3D0 - found =3D=3D=3D> libX11-1.6.8,1 depends on file: = /usr/local/libdata/pkgconfig/xorg-macros.pc - found =3D=3D=3D> libX11-1.6.8,1 depends on file: = /usr/local/libdata/pkgconfig/xau.pc - found =3D=3D=3D> libX11-1.6.8,1 depends on file: = /usr/local/libdata/pkgconfig/xdmcp.pc - found =3D=3D=3D> libX11-1.6.8,1 depends on file: = /usr/local/libdata/pkgconfig/xcb.pc - not found =3D=3D=3D> libxcb-1.13.1 depends on file: /usr/local/lib/libcheck.a - = not found =3D=3D=3D> check-0.12.0_1 depends on executable: makeinfo - not found =3D=3D=3D> texinfo-6.6_4,1 depends on executable: help2man - not found =3D=3D=3D> Building for help2man-1.47.11 gmake[13]: Entering directory = '/usr/ports/misc/help2man/work/help2man-1.47.11' ./config.status config.status: creating Makefile perl help2man.PL --with-gettext gmake help2man help2man.h2m gmake[14]: Entering directory = '/usr/ports/misc/help2man/work/help2man-1.47.11' ./config.status Extracting help2man (with variable substitutions) build-aux/missing makeinfo help2man.texi -o help2man.info config.status: creating Makefile perl help2man.PL --with-gettext perl help2man.h2m.PL Extracting help2man (with variable substitutions) Extracting help2man.h2m gmake[14]: Leaving directory = '/usr/ports/misc/help2man/work/help2man-1.47.11' ./help2man --include=3Dhelp2man.h2m --output=3Dhelp2man.1 ./help2man gmake[13]: Leaving directory = '/usr/ports/misc/help2man/work/help2man-1.47.11' =3D=3D=3D> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the = failure to the maintainer. *** Error code 1 Stop. make[12]: stopped in /usr/ports/misc/help2man *** Error code 1 Stop. make[11]: stopped in /usr/ports/misc/help2man *** Error code 1 =E2=80=94=E2=80=94=E2=80=94=E2=80=94 =E2=80=94 Christoph From owner-freebsd-hackers@freebsd.org Fri May 1 01:30:42 2020 Return-Path: Delivered-To: freebsd-hackers@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 C96A12CDFD7 for ; Fri, 1 May 2020 01:30:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (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 49Cvp94dZ0z4JVy for ; Fri, 1 May 2020 01:30:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: YoXzhRAVM1m6l5cbsH4mpYh9ydcQvlJXCLQC1DXWGJLHH6Un23cDGl.UFLPiOUg C6xxzS47Q5TGo3gMMWvM8wF2PHm_bxyjLDQenH4a0B8VndJ27r.bu9.KQl7GO1q6gJA.V35zmNZl rauohBG34yZXAoAYWqOJ6PfpMSXGjTWFvZLV9ru8MBusO7vupfaOwwMzma8x90qOpZw0Ey5gBf8J XxSip4EyKb1QsuTIWUYAjQFAUQapE8PobqB9iDaq3cEq0KLvlCzBZTMAgzrvYb5MRNK6z90x2Zp2 rym8jy5uoBpmx0TkGDMcZxZPcztrdNHfJadZSYNSa5YpLtQ4Tl67w7kvocPXx1w92rdj9yi53jYZ 1VSBnm0N0rRFUwcAZeb40SVfz4rkrNhYhYWvZiNAwN0Ct1iT3Mb7rN2VnqgJTqD5ldfQiYIdfAoz Ad7ZjzBmet86hciLgTtG38dmldmqD3eUfmzlzkWh90eWxJo_KVx9zomaOckRQ4SEpxiD5Wd8rWl0 6C6WZARD.TjpkZ7A3WB6J6qGSEo.fqkIQGQMy4hRaVwvkj1TqjFMj9FTPVrsxbt4aPBKE5ZJEjKZ Nl_zAcfQ3EFcKhF20Qyy8ZHh4fdsZ2nWcx.4pakH2WF7.xO0joOVBDUGaGLoT7S_Wpb9MEvDcc7J QUtaVlxqsuame7CdPShNcPo2Mm.W_rdIrKf1PbF80dLPMp1w4L4U1Wn2vRYUSLeqUvcA6j.ulAQH Wokd_i.OS4TAPMrvo4Hcm.4.z79cH.y0w0SkNLWssqsnul2BDyEt.c.FdfTXQWR6YxR295_T3qk2 z6E8FF3MbniTnB4e8PkvN_A18RIUmlT0mGmm0ZpAxj.k31im19T0R.4KM4CmSfjBUm_d7DRub2VX Dg5UBpF8UoPifmpu1hi3knfn6rHj9GJyQaOZdgYM6ygG6uzHwavlnaDDpkaBQHp7wFFhremDzKS5 K7nRzJuEqldNLVekRyeCk1_yATRiOrFTECEAuSoYjHptwM7XbWW9c7KMDySTAGaIegtz2HwHLVOI BzplKvSaqD9CIUtLTKMXT17OAsonl5QEQkfFO3BOC8hSs_MFc6pDVrQNROS1IGDgYjBYdnQHwQf_ WDmnEEV9Wf5MIz8mVpu3Xgly69BW85vaoa67DKNW57pDT2ywg.GCIjxQITRx9ZK2bMMgw0K7_0Tq PSN.nzNYminzHUVH0uSG0IuWVoX6BhuLuZX016dcB3oAAcdcqh2QkLf2sHEIyfbXdS6.yLWEAL7F g0BauJbFvFyFcit8ONGAwKDy7XoJgpNwsll6m3HIrNO_748mtqoYFHFqhEUMA4XYMRatoUpc44M. qhqRaLVABR7cy8LcYizbK95DXtfZ6oov5OJWQuSMNb2vlnTZLRJUhlv5ynKjFtjEu4_pcGfhXX16 6f2kO2dQ56hA5J9YACWaYYQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 1 May 2020 01:30:38 +0000 Received: by smtp427.mail.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ddc9e98b8927279a210808e2a470f866; Fri, 01 May 2020 01:30:33 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: 32-bit powerpc head -r360311: lock order reversal between: "PROC (UMA zone)" and "kernelpmap (kernelpmap)": Is this expected? Message-Id: <013FB43E-7DB1-4A66-A6ED-12A891539788@yahoo.com> Date: Thu, 30 Apr 2020 18:30:33 -0700 To: FreeBSD PowerPC ML , FreeBSD Hackers , FreeBSD Current X-Mailer: Apple Mail (2.3608.80.23.2.2) References: <013FB43E-7DB1-4A66-A6ED-12A891539788.ref@yahoo.com> X-Rspamd-Queue-Id: 49Cvp94dZ0z4JVy X-Spamd-Bar: / X-Spamd-Result: default: False [0.03 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(0.00)[ip: (2.25), ipnet: 98.137.64.0/21(0.83), asn: 36647(0.66), country: US(-0.05)]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.49)[-0.488,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.02)[0.018,0]; RCVD_IN_DNSWL_NONE(0.00)[31.65.137.98.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[31.65.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 01:30:42 -0000 Using artifact.ci's head -r360311 debug-kernel materials: = https://artifact.ci.freebsd.org/snapshot/head/r360311/powerpc/powerpc/kern= el*.txz I got the following notice: lock order reversal: 1st 0x1cbb680 PROC (UMA zone) @ /usr/src/sys/vm/uma_core.c:4387 2nd 0x113c99c kernelpmap (kernelpmap) @ = /usr/src/sys/powerpc/aim/mmu_oea.c:1524 stack backtrace: #0 0x5d1e5c at witness_debugger+0x94 #1 0x5d1b34 at witness_checkorder+0xb50 #2 0x51d774 at __mtx_lock_flags+0xcc #3 0x90902c at moea_kextract+0x5c #4 0x9462ac at pmap_kextract+0x98 #5 0x8a417c at zone_release+0xf0 #6 0x8abc14 at bucket_drain+0x2f0 #7 0x8ab64c at bucket_free+0x54 #8 0x8ab8bc at bucket_cache_reclaim+0x1bc #9 0x8ab3c4 at zone_reclaim+0x128 #10 0x8a7e60 at uma_reclaim+0x1d0 #11 0x8d96ac at vm_pageout_worker+0x4d8 #12 0x8d91c0 at vm_pageout+0x1b0 #13 0x4f67a0 at fork_exit+0xb0 #14 0x94892c at fork_trampoline+0xc Is the above interesting or is it one of the known-safe lock order reversals that should be ignored? (The notice is from something like 4.5 hours before I noticed it.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Fri May 1 02:41:10 2020 Return-Path: Delivered-To: freebsd-hackers@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 DEDC52CF8D4 for ; Fri, 1 May 2020 02:41:10 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (using TLSv1.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 49CxMT0vkrz4Mgq for ; Fri, 1 May 2020 02:41:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: IZXnkPQVM1n2FtUz7GeerFhNx7kDkrN3qZilfhCHoFoOHXF720WM8uTC9FaOdoh 610z1GkAZ_ep8VwE.LbZI7cJfmw1FraMbIf.oOAobKpL_YexRl1yb3Lh8TgjOMKRonScSR9jcKW6 D1uy7u_YxYGYUMi2ujeCgLf5dO5KoNKvzONvoOtZ1uuRClmalnI5v6kd53YvOzM0LcnNm.9EsQwb HxE6RpVjypGicKo54s99Fa1qlO0b9L4V1yXZMbevnYd37OuVpYu3xodZyRlt9mXbmfMv8ezk7zT_ 0MfHd_RvCLKbF86fupEsVopzNiS.aifBsywUniNXvfjaSG_YDoXjEsBKHJaSGb3Tmi.f3RRugJtn 2HYCqLEDvFE22WZykayFD1IuLUasIB_.ZkxsdyrZL4ZE1Bpjtkt1OAknnD2WHwqZBFsiMzTud0m4 2nqJr.YLI_3Hp.M267BIfOL73ksRyMvjnds5ZZoGeZXye6Utz_6OBy2EgmRc4.BfB64OTbNtrmUJ ViknHGR8te5HfxMBmMHK3w4hXXqzCt740NeLt9.VqMuw4JkW_yN1SGy51WqhbUPuR1qqmGp3aDXn 3fJBCIHMu9myodNK7kX7hIs9hJhY_hqxdXPia42ihYoTWc2SfH1saxJEY1v8ib3obuDB3EUxu_8B yeZfBVfmQKd5IlaiwcoequHD4e2qYXD0NEW9ZpcPKxhmov4uh8AfLJel9jzznHhTQ0Gu1hOKdUH5 823nUaU0fLsZR4x11i1Maitctq1o3JFjt.mEj5UKjNPmkhLZH71.a3NI_JooW9hHODSN8dpXkFGV q2GF7NEjK0lGyhtXJkOBL4HpZK2C5WH885UzoY2izGw_KOeIvIzGzdUL7EdFiSJZX3oAgIdmIFp9 rxJ6emuuqDCi_NxpC2.EJ_bFY6fxGAJyhL2.n3YqYB_hyPewF2R2RxG9dVWM16esJQG7UQFGxLUi rECWtqCuHyL8MDVi8hqPAI2qoI9YG1sPcaTAfHGkdFr1D81lVfGtKzyfMZ1sxRbt2z3mEuAv3UNZ 4tO9ogn9qqxIEFQMhc.yhj9hJ5FERhhdT5r4bLFqjFNih.xuJw6DLI1mAl2Hf.CX7GTffvqVK3tE cmy8lcaac8.CdkUpsnNMyoY9fiSziIVyv.EEGeT05N6r9J1FK9gCT1m0j8Nglp1v9fHmaxXA65F3 3g7QqJEN3XHG3Jr7AcZJvTobve1L5TOe345MNGzfWCPyX2joHlmZFlxZlr7JQExs8FwB0bksZjbN v4aQ5EwNlFJCtCPxuG3GbYDeOt5aRxJ54hqSBL4w.EFtt51pDAPwg6fGmrschuBWQ9PQgy0FF5Sh 1ofP9LpNQftztLjI8Llp5kWZVrCMPg6jU.XEdjgO2AXEkVGuo6y51p0G55gXarrFaOfw6nyf.h.l 8NsQnQWDQkIJQqRn5ea2eHN0- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Fri, 1 May 2020 02:41:06 +0000 Received: by smtp413.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2a53e3b74aaf11553f38d5ce95aad27d; Fri, 01 May 2020 02:41:01 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: 32-bit powerpc head -r360311 has signal 11 process crashes with rendezvous_request involved (old PowerMac dual-socket, 1 core each) Date: Thu, 30 Apr 2020 19:41:00 -0700 References: <76D3A482-98BC-44C3-B84D-504A012CA8D8@yahoo.com> To: FreeBSD PowerPC ML , FreeBSD Hackers In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49CxMT0vkrz4Mgq X-Spamd-Bar: - X-Spamd-Result: default: False [-1.62 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.59)[-0.594,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.53)[-0.527,0]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (3.98), ipnet: 98.137.64.0/21(0.82), asn: 36647(0.66), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[147.66.137.98.list.dnswl.org : 127.0.5.0]; RWL_MAILSPIKE_POSSIBLE(0.00)[147.66.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 02:41:10 -0000 [After some time dhclient and sendmail did have the problem despite the debug-kernel being in use.] On 2020-Apr-29, at 21:29, Mark Millard wrote: > [Notes on using the artifact.ci head -3260311 debug-kernel added.] >=20 > On 2020-Apr-29, at 02:27, Mark Millard wrote: >=20 >> Since updating from head -r359427 based to head -r360311 base >> (my own non-debug builds), various things report segmentation >> faults. It appears that rendezvous_request may always be >> involved. I've not had time (yet) to deal with substituting a >> debug kernel from: >>=20 >> = https://artifact.ci.freebsd.org/snapshot/head/r360311/powerpc/powerpc/ >>=20 >> I expect to do so at some point. >>=20 >>=20 >> I give 2 examples below (mountd and rpcbind). Both involve >> rendezvous_request and svc_getreq_common . >>=20 >> First mountd : >>=20 >> # gdb mountd /mountd.core=20 >> GNU gdb (GDB) 9.1 [GDB v9.1 for FreeBSD] >> Copyright (C) 2020 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later = >> . . . >> Reading symbols from mountd... >> Reading symbols from /usr/lib/debug//usr/sbin/mountd.debug... >> [New LWP 100105] >> Core was generated by `/usr/sbin/mountd -r'. >> Program terminated with signal SIGSEGV, Segmentation fault. >> #0 atomic_load_u (a=3D, mo=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/atomic.h:70 >>=20 >> warning: Source file is more recent than executable. >> 70 JEMALLOC_GENERATE_INT_ATOMICS(unsigned, u, LG_SIZEOF_INT) >> (gdb) bt >> #0 atomic_load_u (a=3D, mo=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/atomic.h:70 >> #1 rtree_leaf_elm_szind_read (tsdn=3D, = rtree=3D, elm=3D, dependent=3D) at /usr/src/contrib/jemalloc/include/jemalloc/internal/rtree.h:230 >> #2 rtree_szind_slab_read (tsdn=3D0x50094018, rtree=3D, rtree_ctx=3D0x50094044, key=3D1869636193, dependent=3Dtrue, = r_szind=3D, r_slab=3D) >> at /usr/src/contrib/jemalloc/include/jemalloc/internal/rtree.h:504 >> #3 ifree (tsd=3D, ptr=3D0x6f706261, tcache=3D, slow_path=3Dfalse) at jemalloc_jemalloc.c:2574 >> #4 __je_free_default (ptr=3D0x6f706261) at jemalloc_jemalloc.c:2775 >> #5 0x50235db0 in __free (ptr=3D0x6f706261) at = jemalloc_jemalloc.c:2852 >> #6 0x5026525c in freenetconfigent (netconfigp=3D0x50049170) at = /usr/src/lib/libc/rpc/getnetconfig.c:540 >> #7 0x50260d8c in __rpc_sockinfo2netid (sip=3D, = netid=3D) at /usr/src/lib/libc/rpc/rpc_generic.c:573 >> #8 0x502521f0 in makefd_xprt (fd=3D10, sendsize=3D9000, = recvsize=3D9000) at /usr/src/lib/libc/rpc/svc_vc.c:270 >> #9 0x50252fa4 in rendezvous_request (xprt=3D0x5007b120, = msg=3D) at /usr/src/lib/libc/rpc/svc_vc.c:315 >> #10 0x50254588 in svc_getreq_common (fd=3D) at = /usr/src/lib/libc/rpc/svc.c:640 >> #11 0x502543d0 in svc_getreqset (readfds=3D) at = /usr/src/lib/libc/rpc/svc.c:611 >> #12 0x1001434c in main (argc=3D, argv=3D0xffffde3c) at = /usr/src/usr.sbin/mountd/mountd.c:683 >>=20 >> (gdb) disass >> Dump of assembler code for function __je_free_default: >> 0x50235244 <+0>: mflr r0 >> 0x50235248 <+4>: stw r0,4(r1) >> 0x5023524c <+8>: stwu r1,-80(r1) >> 0x50235250 <+12>: stw r30,72(r1) >> 0x50235254 <+16>: stw r21,36(r1) >> 0x50235258 <+20>: stw r22,40(r1) >> 0x5023525c <+24>: stw r23,44(r1) >> 0x50235260 <+28>: stw r24,48(r1) >> 0x50235264 <+32>: stw r25,52(r1) >> 0x50235268 <+36>: stw r26,56(r1) >> 0x5023526c <+40>: stw r27,60(r1) >> 0x50235270 <+44>: stw r28,64(r1) >> 0x50235274 <+48>: stw r29,68(r1) >> 0x50235278 <+52>: bl 0x5023527c <__je_free_default+56> >> 0x5023527c <+56>: mr r28,r3 >> 0x50235280 <+60>: mflr r30 >> 0x50235284 <+64>: addis r30,r30,14 >> 0x50235288 <+68>: addi r30,r30,-20816 >> 0x5023528c <+72>: lwz r4,64(r30) >> 0x50235290 <+76>: lwz r5,6188(r30) >> 0x50235294 <+80>: lwz r4,0(r4) >> 0x50235298 <+84>: stw r4,32(r1) >> 0x5023529c <+88>: lbz r4,0(r5) >> 0x502352a0 <+92>: cmplwi r4,0 >> 0x502352a4 <+96>: bne 0x502353c4 <__je_free_default+384> >> 0x502352a8 <+100>: cmplwi r28,0 >> 0x502352ac <+104>: beq 0x50235378 <__je_free_default+308> >> 0x502352b0 <+108>: addi r3,r30,4332 >> 0x502352b4 <+112>: rlwinm r24,r28,0,0,9 >> 0x502352b8 <+116>: bl 0x502f06b4 = <00000000.plt_pic32.__tls_get_addr> >> 0x502352bc <+120>: rlwinm r26,r28,13,25,28 >> 0x502352c0 <+124>: mr r29,r3 >> 0x502352c4 <+128>: lbz r3,0(r3) >> 0x502352c8 <+132>: cmplwi r3,0 >> 0x502352cc <+136>: bne 0x502353fc <__je_free_default+440> >> 0x502352d0 <+140>: add r25,r29,r26 >> 0x502352d4 <+144>: lwz r3,44(r25) >> 0x502352d8 <+148>: addi r27,r29,44 >> 0x502352dc <+152>: cmplw r3,r24 >> 0x502352e0 <+156>: bne 0x50235578 <__je_free_default+820> >> 0x502352e4 <+160>: lwz r3,48(r25) >> 0x502352e8 <+164>: rlwinm r4,r28,20,22,31 >> 0x502352ec <+168>: mulli r4,r4,12 >> 0x502352f0 <+172>: add r3,r3,r4 >> =3D> 0x502352f4 <+176>: lwz r6,4(r3) >> 0x502352f8 <+180>: lwz r5,4368(r30) >> 0x502352fc <+184>: addi r26,r29,288 >> 0x50235300 <+188>: lbz r4,8(r3) >> 0x50235304 <+192>: rlwinm r3,r6,2,0,29 >> 0x50235308 <+196>: lwz r7,28(r29) >> 0x5023530c <+200>: lwzx r5,r5,r3 >> 0x50235310 <+204>: lwz r8,24(r29) >> 0x50235314 <+208>: andi. r4,r4,1 >> 0x50235318 <+212>: addc r4,r7,r5 >> 0x5023531c <+216>: addze r5,r8 >> 0x50235320 <+220>: stw r5,24(r29) >> 0x50235324 <+224>: stw r4,28(r29) >> 0x50235328 <+228>: ble 0x50235534 <__je_free_default+752> >> . . . >>=20 >> (gdb) info reg >> r0 0x50235c04 1344494596 >> r1 0xffffcfb0 4294954928 >> r2 0x5009b018 1342812184 >> r3 0x2448 9288 >> r4 0x500940ac 1342783660 >> r5 0x2448 9288 >> r6 0x500940cc 1342783692 >> r7 0x1 1 >> r8 0x0 0 >> r9 0x80808080 2155905152 >> r10 0xc 12 >> r11 0x502e3b50 1345207120 >> r12 0x500491a0 1342476704 >> r13 0x0 0 >> r14 0x1 1 >> r15 0x10040000 268697600 >> r16 0x0 0 >> r17 0x10040000 268697600 >> r18 0x2 2 >> r19 0x0 0 >> r20 0x1 1 >> r21 0x5007b164 1342681444 >> r22 0xffffd2dc 4294955740 >> r23 0x80 128 >> r24 0x6f400000 1866465280 >> r25 0x50094080 1342783616 >> r26 0x68 104 >> r27 0x50094044 1342783556 >> r28 0x6f706261 1869636193 >> r29 0x50094018 1342783512 >> r30 0x5031012c 1345388844 >> r31 0x10040000 268697600 >> pc 0x502352f4 0x502352f4 <__je_free_default+176> >> msr >> cr 0x242008a4 606079140 >> lr 0x50235c04 0x50235c04 = <__je_free_default+2496> >> ctr 0x0 0 >> xer 0x0 0 >> fpscr 0x0 0 >> vscr >> vrsave >>=20 >>=20 >> Then rpcbind : >>=20 >> # gdb rpcbind /rpcbind.core=20 >> GNU gdb (GDB) 9.1 [GDB v9.1 for FreeBSD] >> Copyright (C) 2020 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later = >> . . . >> Reading symbols from rpcbind... >> Reading symbols from /usr/lib/debug//usr/sbin/rpcbind.debug... >> [New LWP 100098] >> Core was generated by `/usr/sbin/rpcbind'. >> Program terminated with signal SIGSEGV, Segmentation fault. >> #0 __xdrrec_setnonblock (xdrs=3D0x500472d8, maxrec=3D9000) at = /usr/src/lib/libc/xdr/xdr_rec.c:607 >> 607 rstrm->nonblock =3D TRUE; >> (gdb) bt >> #0 __xdrrec_setnonblock (xdrs=3D0x500472d8, maxrec=3D9000) at = /usr/src/lib/libc/xdr/xdr_rec.c:607 >> #1 0x502440d4 in rendezvous_request (xprt=3D, = msg=3D) at /usr/src/lib/libc/rpc/svc_vc.c:348 >> #2 0x50245588 in svc_getreq_common (fd=3D) at = /usr/src/lib/libc/rpc/svc.c:640 >> #3 0x5024580c in svc_getreq_poll (pfdp=3D, = pollretval=3D1) at /usr/src/lib/libc/rpc/svc.c:739 >> #4 0x10018568 in my_svc_run () at = /usr/src/usr.sbin/rpcbind/rpcb_svc_com.c:1167 >> #5 0x10014ad8 in main (argc=3D, argv=3D) at /usr/src/usr.sbin/rpcbind/rpcbind.c:250 >>=20 >> (gdb) disass >> Dump of assembler code for function __xdrrec_setnonblock: >> 0x50250468 <+0>: lwz r5,12(r3) >> 0x5025046c <+4>: li r6,1 >> 0x50250470 <+8>: cmplwi r4,0 >> =3D> 0x50250474 <+12>: stw r6,64(r5) >> 0x50250478 <+16>: bne 0x50250480 <__xdrrec_setnonblock+24> >> 0x5025047c <+20>: lwz r4,60(r5) >> 0x50250480 <+24>: li r3,1 >> 0x50250484 <+28>: stw r4,92(r5) >> 0x50250488 <+32>: blr >> End of assembler dump. >>=20 >> (gdb) info reg >> r0 0x5c 92 >> r1 0xffffb400 4294947840 >> r2 0x500a1018 1342836760 >> r3 0x500472d8 1342468824 >> r4 0x2328 9000 >> r5 0x2020 8224 >> r6 0x1 1 >> r7 0xffffb364 4294947684 >> r8 0x500472f4 1342468852 >> r9 0x0 0 >> r10 0x20 32 >> r11 0x502d8ea0 1345162912 >> r12 0x24200880 606079104 >> r13 0x0 0 >> r14 0x0 0 >> r15 0xffffbc28 4294949928 >> r16 0x10002848 268445768 >> r17 0x10040000 268697600 >> r18 0x2 2 >> r19 0x0 0 >> r20 0x1 1 >> r21 0x5004c044 1342488644 >> r22 0xffffb63c 4294948412 >> r23 0x80 128 >> r24 0x50048010 1342472208 >> r25 0x14 20 >> r26 0xffffb630 4294948400 >> r27 0x500472d0 1342468816 >> r28 0xe 14 >> r29 0x50047220 1342468640 >> r30 0x5030112c 1345327404 >> r31 0x10040000 268697600 >> pc 0x50250474 0x50250474 = <__xdrrec_setnonblock+12> >> msr >> cr 0x44200080 1142947968 >> lr 0x502440d4 0x502440d4 = >> ctr 0x502d8ea0 1345162912 >> xer 0x0 0 >> fpscr 0x0 0 >> vscr >> vrsave >>=20 >>=20 >> dhclient and sendmail have notices of signal 11's >> but I do not find any .core files around for them. >>=20 >> Prior to this upgrade I was having no such problems >> with the 32-bit powerpc PowerMac. >=20 > I substituted the debug-kernel from: >=20 > = https://artifact.ci.freebsd.org/snapshot/head/r360311/powerpc/powerpc/kern= el.txz >=20 > and with it there is no evidence so far of the > problem(s) occurring. Since the same world build is > in use in both contexts, it looks like the kernel > is what makes the difference for the problem(s). >=20 > With the debug-kernel avoiding the problem, I've yet > to figure out how to gather evidence. >=20 About 8.5 hours later than the boot completing it got a: kernel: pid 659 (dhclient), jid 0, uid 65: exited on signal 11 About 7 hours later it started getting sendmail messaged similar to: kernel: pid 3722 (sendmail), jid 0, uid 25: exited on signal 11 These seem to be 0.5 hours part. Between the 3rd and 4th is a lock order reversal notice that I've separately submitted to the lists (but that do not yet appear there, last I checked). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Fri May 1 03:10:30 2020 Return-Path: Delivered-To: freebsd-hackers@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 128C82D0521 for ; Fri, 1 May 2020 03:10:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32]) (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 49Cy1J56sVz4PXc for ; Fri, 1 May 2020 03:10:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: DI6KMC4VM1kxKVCSWhnCR67BZ28gPPvda9zxIxuIU_gDEdSGDbwVzm5AFVRdGGW .IsoFz3kUWRxhzHIBhg99b.491BhmrwH3Gw8Xe7CYbPTbQQsOZcyEymUkO_wqdb.ZIPE3yKaQnkQ pFlit9sd4gz8BtrLIdyth1WLkpY2F5RT_IvUs33Ir2HmdLJZLELZGzYeQ6eIFu3BEQ3lNQuVhhl2 0GBZBXEC82T_vxpOBUC4jwbZKvTDBMj9QQ3nrmSO.2cYawnQGnLzeA4_CK.OAQ2t2YWJxIIrCAne 9IZ_So3cYLiLHcUTPtrNzo8yN1tmQR.seb56IX6HZp9He2NL.RitMAGFXw4A8hVW3QCG_vZBo8Fc U8FUi9OLUJnQB7gHZ.XFneX_y_klfo4mYFZ34VJlHiH_LKMbLD6RrxHgynN6Vsj5rQhGt2WlBAkE .vXdnVBXaf9kf5ZsUrTT5IkIYazvvKYhFV9a4u4CvRm4Z0au10iZWxAYYEM.OnGq71rBwtQr3PRc DYI1fqsYWcZIroxp6cMlFgLRO9J9ks8z7iq9RZ6DHet8lTHf9i9f04rQWvafLAYEL.yC9gb4PX3z .9AGJZEX5abE2okQkJO5buoPPYYX5jnm5tn.LISimaa2uRuXahBfW3.xLvO748lhv6hqrL3a_OOg WELSgyCAuSTdLh8sL2vVZRY4YnYwKSKXkGP4PpkpcNWo65YXBHfJhb__d_rS8L.sGBl.exl5NuSO nYOCq_mbRG5gAvPYtVjY2.J0AcsgmktNmOypypVdPeZh7Ho30bXyyeFU6cAb_RCpCSzi73LjJaLH fQBPsUp.NeQn5FgCTLG_FAjpTci5.xdpNdBG1HwS1wcxTQGSbxLTlRlqsskF4QHNl.zWTvVzlglC ATASGHfz_Xq23tmRyA63AuQKPnBZtkt9u8gV.dSLXcy9Lj2OW.hyob.cTr7r9Dg1DmSy75WBrkS6 8I0oca1EI3yQtmgYMklRrLu3_yA9lPgKgQeDx6_qjIK.8PVkZy8g9BxKtIv5kTP79Nol23Q8CnAq bNgOoHZYr4.2KUh2CWboXvrUwozhf.Rgr519FX.9aKpANbh3OpAKtydi80gaHF1uRK8Uv5wNSbla Tov2hTZ9U5WupeR1P44gTUDxRyW1JRqX89uKKeGKQiSrsyT2mo9k5irAbrXyIj7dHJqy_BuZoxvN FnW_H2GiPUanqrNPAFobj_NhlSFsxqlBA4I.2_evgYQxHtxzvfbUZSL3mSN_9KuWyCmAcgHOuI0C N4Za.ADu54AG7Sflhd1AJfVJfE8iWIbXK8jKcGE8ur6EiEAnKNAGgj2co_wtEel5w73ftaUmZyvQ rHtNlyQuBSQ0acqgiHoAAeJRAdtTPIhylWU6CvA4mjvcGC0vwaOmcF4Ilvyyz5pA7sqWVm5ab_1r L6Pkoktxm32WuNJDQViTqbA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Fri, 1 May 2020 03:10:27 +0000 Received: by smtp431.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 830c4bc3c4cb612231800e45fe4163bf; Fri, 01 May 2020 03:10:21 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: 32-bit powerpc head -r360311 has signal 11 process crashes (old PowerMac dual-socket, 1 core each) Date: Thu, 30 Apr 2020 20:10:20 -0700 References: <76D3A482-98BC-44C3-B84D-504A012CA8D8@yahoo.com> To: FreeBSD PowerPC ML , FreeBSD Hackers In-Reply-To: Message-Id: <7ACAC4BB-AFAB-4048-9F27-26B2115F183E@yahoo.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49Cy1J56sVz4PXc X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.46 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; SH_EMAIL_ZRD(0.00)[0.0.0.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.970,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.0]; NEURAL_HAM_LONG(-0.99)[-0.985,0]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[32.68.137.98.list.dnswl.org : 127.0.5.0]; IP_SCORE(0.00)[ip: (0.42), ipnet: 98.137.64.0/21(0.82), asn: 36647(0.66), country: US(-0.05)]; RWL_MAILSPIKE_POSSIBLE(0.00)[32.68.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 03:10:30 -0000 [Turns out one sendmail left a sendmail.core behind. rendezvous_request is not on the call stack.] > On 2020-Apr-30, at 19:41, Mark Millard wrote: >=20 > [After some time dhclient and sendmail did have the problem > despite the debug-kernel being in use.] >=20 > On 2020-Apr-29, at 21:29, Mark Millard wrote: >=20 >> [Notes on using the artifact.ci head -3260311 debug-kernel added.] >>=20 >> On 2020-Apr-29, at 02:27, Mark Millard wrote: >>=20 >>> Since updating from head -r359427 based to head -r360311 base >>> (my own non-debug builds), various things report segmentation >>> faults. It appears that rendezvous_request may always be >>> involved. I've not had time (yet) to deal with substituting a >>> debug kernel from: >>>=20 >>> = https://artifact.ci.freebsd.org/snapshot/head/r360311/powerpc/powerpc/ >>>=20 >>> I expect to do so at some point. >>>=20 >>>=20 >>> I give 2 examples below (mountd and rpcbind). Both involve >>> rendezvous_request and svc_getreq_common . >>>=20 >>> First mountd : >>>=20 >>> # gdb mountd /mountd.core=20 >>> GNU gdb (GDB) 9.1 [GDB v9.1 for FreeBSD] >>> Copyright (C) 2020 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later = >>> . . . >>> Reading symbols from mountd... >>> Reading symbols from /usr/lib/debug//usr/sbin/mountd.debug... >>> [New LWP 100105] >>> Core was generated by `/usr/sbin/mountd -r'. >>> Program terminated with signal SIGSEGV, Segmentation fault. >>> #0 atomic_load_u (a=3D, mo=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/atomic.h:70 >>>=20 >>> warning: Source file is more recent than executable. >>> 70 JEMALLOC_GENERATE_INT_ATOMICS(unsigned, u, LG_SIZEOF_INT) >>> (gdb) bt >>> #0 atomic_load_u (a=3D, mo=3D) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/atomic.h:70 >>> #1 rtree_leaf_elm_szind_read (tsdn=3D, = rtree=3D, elm=3D, dependent=3D) at /usr/src/contrib/jemalloc/include/jemalloc/internal/rtree.h:230 >>> #2 rtree_szind_slab_read (tsdn=3D0x50094018, rtree=3D, rtree_ctx=3D0x50094044, key=3D1869636193, dependent=3Dtrue, = r_szind=3D, r_slab=3D) >>> at /usr/src/contrib/jemalloc/include/jemalloc/internal/rtree.h:504 >>> #3 ifree (tsd=3D, ptr=3D0x6f706261, = tcache=3D, slow_path=3Dfalse) at jemalloc_jemalloc.c:2574 >>> #4 __je_free_default (ptr=3D0x6f706261) at jemalloc_jemalloc.c:2775 >>> #5 0x50235db0 in __free (ptr=3D0x6f706261) at = jemalloc_jemalloc.c:2852 >>> #6 0x5026525c in freenetconfigent (netconfigp=3D0x50049170) at = /usr/src/lib/libc/rpc/getnetconfig.c:540 >>> #7 0x50260d8c in __rpc_sockinfo2netid (sip=3D, = netid=3D) at /usr/src/lib/libc/rpc/rpc_generic.c:573 >>> #8 0x502521f0 in makefd_xprt (fd=3D10, sendsize=3D9000, = recvsize=3D9000) at /usr/src/lib/libc/rpc/svc_vc.c:270 >>> #9 0x50252fa4 in rendezvous_request (xprt=3D0x5007b120, = msg=3D) at /usr/src/lib/libc/rpc/svc_vc.c:315 >>> #10 0x50254588 in svc_getreq_common (fd=3D) at = /usr/src/lib/libc/rpc/svc.c:640 >>> #11 0x502543d0 in svc_getreqset (readfds=3D) at = /usr/src/lib/libc/rpc/svc.c:611 >>> #12 0x1001434c in main (argc=3D, argv=3D0xffffde3c) = at /usr/src/usr.sbin/mountd/mountd.c:683 >>>=20 >>> (gdb) disass >>> Dump of assembler code for function __je_free_default: >>> 0x50235244 <+0>: mflr r0 >>> 0x50235248 <+4>: stw r0,4(r1) >>> 0x5023524c <+8>: stwu r1,-80(r1) >>> 0x50235250 <+12>: stw r30,72(r1) >>> 0x50235254 <+16>: stw r21,36(r1) >>> 0x50235258 <+20>: stw r22,40(r1) >>> 0x5023525c <+24>: stw r23,44(r1) >>> 0x50235260 <+28>: stw r24,48(r1) >>> 0x50235264 <+32>: stw r25,52(r1) >>> 0x50235268 <+36>: stw r26,56(r1) >>> 0x5023526c <+40>: stw r27,60(r1) >>> 0x50235270 <+44>: stw r28,64(r1) >>> 0x50235274 <+48>: stw r29,68(r1) >>> 0x50235278 <+52>: bl 0x5023527c <__je_free_default+56> >>> 0x5023527c <+56>: mr r28,r3 >>> 0x50235280 <+60>: mflr r30 >>> 0x50235284 <+64>: addis r30,r30,14 >>> 0x50235288 <+68>: addi r30,r30,-20816 >>> 0x5023528c <+72>: lwz r4,64(r30) >>> 0x50235290 <+76>: lwz r5,6188(r30) >>> 0x50235294 <+80>: lwz r4,0(r4) >>> 0x50235298 <+84>: stw r4,32(r1) >>> 0x5023529c <+88>: lbz r4,0(r5) >>> 0x502352a0 <+92>: cmplwi r4,0 >>> 0x502352a4 <+96>: bne 0x502353c4 <__je_free_default+384> >>> 0x502352a8 <+100>: cmplwi r28,0 >>> 0x502352ac <+104>: beq 0x50235378 <__je_free_default+308> >>> 0x502352b0 <+108>: addi r3,r30,4332 >>> 0x502352b4 <+112>: rlwinm r24,r28,0,0,9 >>> 0x502352b8 <+116>: bl 0x502f06b4 = <00000000.plt_pic32.__tls_get_addr> >>> 0x502352bc <+120>: rlwinm r26,r28,13,25,28 >>> 0x502352c0 <+124>: mr r29,r3 >>> 0x502352c4 <+128>: lbz r3,0(r3) >>> 0x502352c8 <+132>: cmplwi r3,0 >>> 0x502352cc <+136>: bne 0x502353fc <__je_free_default+440> >>> 0x502352d0 <+140>: add r25,r29,r26 >>> 0x502352d4 <+144>: lwz r3,44(r25) >>> 0x502352d8 <+148>: addi r27,r29,44 >>> 0x502352dc <+152>: cmplw r3,r24 >>> 0x502352e0 <+156>: bne 0x50235578 <__je_free_default+820> >>> 0x502352e4 <+160>: lwz r3,48(r25) >>> 0x502352e8 <+164>: rlwinm r4,r28,20,22,31 >>> 0x502352ec <+168>: mulli r4,r4,12 >>> 0x502352f0 <+172>: add r3,r3,r4 >>> =3D> 0x502352f4 <+176>: lwz r6,4(r3) >>> 0x502352f8 <+180>: lwz r5,4368(r30) >>> 0x502352fc <+184>: addi r26,r29,288 >>> 0x50235300 <+188>: lbz r4,8(r3) >>> 0x50235304 <+192>: rlwinm r3,r6,2,0,29 >>> 0x50235308 <+196>: lwz r7,28(r29) >>> 0x5023530c <+200>: lwzx r5,r5,r3 >>> 0x50235310 <+204>: lwz r8,24(r29) >>> 0x50235314 <+208>: andi. r4,r4,1 >>> 0x50235318 <+212>: addc r4,r7,r5 >>> 0x5023531c <+216>: addze r5,r8 >>> 0x50235320 <+220>: stw r5,24(r29) >>> 0x50235324 <+224>: stw r4,28(r29) >>> 0x50235328 <+228>: ble 0x50235534 <__je_free_default+752> >>> . . . >>>=20 >>> (gdb) info reg >>> r0 0x50235c04 1344494596 >>> r1 0xffffcfb0 4294954928 >>> r2 0x5009b018 1342812184 >>> r3 0x2448 9288 >>> r4 0x500940ac 1342783660 >>> r5 0x2448 9288 >>> r6 0x500940cc 1342783692 >>> r7 0x1 1 >>> r8 0x0 0 >>> r9 0x80808080 2155905152 >>> r10 0xc 12 >>> r11 0x502e3b50 1345207120 >>> r12 0x500491a0 1342476704 >>> r13 0x0 0 >>> r14 0x1 1 >>> r15 0x10040000 268697600 >>> r16 0x0 0 >>> r17 0x10040000 268697600 >>> r18 0x2 2 >>> r19 0x0 0 >>> r20 0x1 1 >>> r21 0x5007b164 1342681444 >>> r22 0xffffd2dc 4294955740 >>> r23 0x80 128 >>> r24 0x6f400000 1866465280 >>> r25 0x50094080 1342783616 >>> r26 0x68 104 >>> r27 0x50094044 1342783556 >>> r28 0x6f706261 1869636193 >>> r29 0x50094018 1342783512 >>> r30 0x5031012c 1345388844 >>> r31 0x10040000 268697600 >>> pc 0x502352f4 0x502352f4 = <__je_free_default+176> >>> msr >>> cr 0x242008a4 606079140 >>> lr 0x50235c04 0x50235c04 = <__je_free_default+2496> >>> ctr 0x0 0 >>> xer 0x0 0 >>> fpscr 0x0 0 >>> vscr >>> vrsave >>>=20 >>>=20 >>> Then rpcbind : >>>=20 >>> # gdb rpcbind /rpcbind.core=20 >>> GNU gdb (GDB) 9.1 [GDB v9.1 for FreeBSD] >>> Copyright (C) 2020 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later = >>> . . . >>> Reading symbols from rpcbind... >>> Reading symbols from /usr/lib/debug//usr/sbin/rpcbind.debug... >>> [New LWP 100098] >>> Core was generated by `/usr/sbin/rpcbind'. >>> Program terminated with signal SIGSEGV, Segmentation fault. >>> #0 __xdrrec_setnonblock (xdrs=3D0x500472d8, maxrec=3D9000) at = /usr/src/lib/libc/xdr/xdr_rec.c:607 >>> 607 rstrm->nonblock =3D TRUE; >>> (gdb) bt >>> #0 __xdrrec_setnonblock (xdrs=3D0x500472d8, maxrec=3D9000) at = /usr/src/lib/libc/xdr/xdr_rec.c:607 >>> #1 0x502440d4 in rendezvous_request (xprt=3D, = msg=3D) at /usr/src/lib/libc/rpc/svc_vc.c:348 >>> #2 0x50245588 in svc_getreq_common (fd=3D) at = /usr/src/lib/libc/rpc/svc.c:640 >>> #3 0x5024580c in svc_getreq_poll (pfdp=3D, = pollretval=3D1) at /usr/src/lib/libc/rpc/svc.c:739 >>> #4 0x10018568 in my_svc_run () at = /usr/src/usr.sbin/rpcbind/rpcb_svc_com.c:1167 >>> #5 0x10014ad8 in main (argc=3D, argv=3D) at /usr/src/usr.sbin/rpcbind/rpcbind.c:250 >>>=20 >>> (gdb) disass >>> Dump of assembler code for function __xdrrec_setnonblock: >>> 0x50250468 <+0>: lwz r5,12(r3) >>> 0x5025046c <+4>: li r6,1 >>> 0x50250470 <+8>: cmplwi r4,0 >>> =3D> 0x50250474 <+12>: stw r6,64(r5) >>> 0x50250478 <+16>: bne 0x50250480 <__xdrrec_setnonblock+24> >>> 0x5025047c <+20>: lwz r4,60(r5) >>> 0x50250480 <+24>: li r3,1 >>> 0x50250484 <+28>: stw r4,92(r5) >>> 0x50250488 <+32>: blr >>> End of assembler dump. >>>=20 >>> (gdb) info reg >>> r0 0x5c 92 >>> r1 0xffffb400 4294947840 >>> r2 0x500a1018 1342836760 >>> r3 0x500472d8 1342468824 >>> r4 0x2328 9000 >>> r5 0x2020 8224 >>> r6 0x1 1 >>> r7 0xffffb364 4294947684 >>> r8 0x500472f4 1342468852 >>> r9 0x0 0 >>> r10 0x20 32 >>> r11 0x502d8ea0 1345162912 >>> r12 0x24200880 606079104 >>> r13 0x0 0 >>> r14 0x0 0 >>> r15 0xffffbc28 4294949928 >>> r16 0x10002848 268445768 >>> r17 0x10040000 268697600 >>> r18 0x2 2 >>> r19 0x0 0 >>> r20 0x1 1 >>> r21 0x5004c044 1342488644 >>> r22 0xffffb63c 4294948412 >>> r23 0x80 128 >>> r24 0x50048010 1342472208 >>> r25 0x14 20 >>> r26 0xffffb630 4294948400 >>> r27 0x500472d0 1342468816 >>> r28 0xe 14 >>> r29 0x50047220 1342468640 >>> r30 0x5030112c 1345327404 >>> r31 0x10040000 268697600 >>> pc 0x50250474 0x50250474 = <__xdrrec_setnonblock+12> >>> msr >>> cr 0x44200080 1142947968 >>> lr 0x502440d4 0x502440d4 = >>> ctr 0x502d8ea0 1345162912 >>> xer 0x0 0 >>> fpscr 0x0 0 >>> vscr >>> vrsave >>>=20 >>>=20 >>> dhclient and sendmail have notices of signal 11's >>> but I do not find any .core files around for them. >>>=20 >>> Prior to this upgrade I was having no such problems >>> with the 32-bit powerpc PowerMac. >>=20 >> I substituted the debug-kernel from: >>=20 >> = https://artifact.ci.freebsd.org/snapshot/head/r360311/powerpc/powerpc/kern= el.txz >>=20 >> and with it there is no evidence so far of the >> problem(s) occurring. Since the same world build is >> in use in both contexts, it looks like the kernel >> is what makes the difference for the problem(s). >>=20 >> With the debug-kernel avoiding the problem, I've yet >> to figure out how to gather evidence. >>=20 >=20 > About 8.5 hours later than the boot completing > it got a: >=20 > kernel: pid 659 (dhclient), jid 0, uid 65: exited on signal 11 >=20 > About 7 hours later it started getting sendmail messaged > similar to: >=20 > kernel: pid 3722 (sendmail), jid 0, uid 25: exited on signal 11 >=20 > These seem to be 0.5 hours part. Between the 3rd and 4th > is a lock order reversal notice that I've separately > submitted to the lists (but that do not yet appear there, > last I checked). I found that there was a sendmail.core around: # gdb /usr/libexec/sendmail/sendmail = /var/spool/clientmqueue/sendmail.core=20 GNU gdb (GDB) 9.1 [GDB v9.1 for FreeBSD] Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later = . . . Reading symbols from /usr/libexec/sendmail/sendmail... Reading symbols from = /usr/lib/debug//usr/libexec/sendmail/sendmail.debug... [New LWP 100163] Core was generated by `sendmail: running queue: = /var/spool/clientmqueue'. Program terminated with signal SIGSEGV, Segmentation fault. #0 bitmap_unset (bitmap=3D0x50a0af68, binfo=3D, = bit=3D167949476) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/bitmap.h:341 warning: Source file is more recent than executable. 341 g =3D *gp; (gdb) bt -full #0 bitmap_unset (bitmap=3D0x50a0af68, binfo=3D, = bit=3D167949476) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/bitmap.h:341 goff =3D gp =3D propagate =3D g =3D i =3D #1 arena_slab_reg_dalloc (slab=3D0x50a0af40, slab_data=3D0x50a0af68, = ptr=3D0x5015a520) at jemalloc_arena.c:368 bin_info =3D binind =3D regind =3D 167949476 #2 arena_dalloc_bin_locked_impl (tsdn=3D0x50144018, arena=3D, bin=3D, binind=3D, slab=3D, ptr=3D, junked=3D) at jemalloc_arena.c:1695 bin_info =3D slab_data =3D 0x50a0af68 nfree =3D #3 0x506a1148 in __je_arena_dalloc_bin_junked_locked (tsdn=3D, arena=3D, bin=3D, binind=3D, extent=3D, ptr=3D) at jemalloc_arena.c:1714 No locals. #4 0x50656080 in __je_tcache_bin_flush_small (tsd=3D0x50144018, = tcache=3D, tbin=3D0x501441d8, binind=3D6, rem=3D25) at = jemalloc_tcache.c:189 ptr =3D i =3D 0 extent =3D bin_arena_ind =3D 0 bin_arena =3D 0x50a00380 bin =3D 0x50a02e08 ndeferred =3D 0 binshard =3D 0 merged_stats =3D arena =3D 0x50a00380 nflush =3D 71 __vla_expr0 =3D item_extent =3D 0xffffb940 #5 0x50655bb8 in __je_tcache_event_hard (tsd=3D, = tcache=3D0x50144138) at jemalloc_tcache.c:55 tbin_info =3D binind =3D 6 tbin =3D 0x501441d8 #6 0x506ab5bc in __je_free_default (ptr=3D0x5012b480) at = /usr/src/contrib/jemalloc/include/jemalloc/internal/rtree.h:374 tcache =3D tsd =3D #7 0x506abdb0 in __free (ptr=3D0x5012b480) at jemalloc_jemalloc.c:2852 log_var =3D log_var =3D #8 0x5074f170 in __clean_env (freeVars=3D255) at = /usr/src/lib/libc/stdlib/getenv.c:243 envNdx =3D 0 #9 __clean_env_destructor () at /usr/src/lib/libc/stdlib/getenv.c:409 No locals. #10 0x5010d45c in objlist_call_fini (list=3D, root=3D0x0, = lockstate=3D0xffffc0a8) at /usr/src/libexec/rtld-elf/rtld.c:2694 saved_msg =3D 0x5013e144 "Undefined symbol = \"_nss_cache_cycle_prevention_function\"" elm =3D fini_addr =3D index =3D #11 0x50105b24 in rtld_exit () at /usr/src/libexec/rtld-elf/rtld.c:3081 lockstate =3D {lockstate =3D 2, env =3D {{_sjb =3D {269512264, = 0, 269484032, 269514775, 269615104, 269510192, 0, 0, -16280, 1343500292, = 1343400236, 0 , 2, 1348094285, 904808974,=20 1143081540, 1, 269512264, 1343411584, 269463008, 0, = 269514775, 269512264, 1, 1350263456, 269407312, 2, 269407852, 269407296, = -15868, -15888, -15808, 1343400236, 0, -15872,=20 1343238092, 1350066476, 0, -15840, 1349172772, = 1350897796, 1343434832, 4, 1343434752, 1350066476, 269235216, -15792, = 1349700248, 269615104, 269514775, 0, 1350263400, 0, 1349699420}}}} #12 0x50732448 in __cxa_finalize (dso=3D0x0) at = /usr/src/lib/libc/stdlib/atexit.c:240 phdr_info =3D {dlpi_addr =3D 1343533080, dlpi_name =3D = 0xffffc2e0 "\377\377\310\260\020\006@\f", dlpi_phdr =3D 0x0, dlpi_phnum = =3D 20500, dlpi_adds =3D 1, dlpi_subs =3D 1157546361094329728,=20 dlpi_tls_modid =3D 269463008, dlpi_tls_data =3D 0x0} has_phdr =3D p =3D 0x507b6268 n =3D fn =3D {fn_type =3D 1, fn_ptr =3D {std_func =3D 0x50105ad4 = , cxa_func =3D 0x50105ad4 }, fn_arg =3D 0x0, = fn_dso =3D } #13 0x506b62e8 in exit (status=3D0) at = /usr/src/lib/libc/stdlib/exit.c:74 No locals. #14 0x1006400c in finis (drop=3D, cleanup=3D1, = exitstat=3D0) at /usr/src/contrib/sendmail/src/main.c:3105 _h =3D {eh_value =3D 0x0, eh_context =3D {{_sjb =3D {0, 0, 0, 0, = 0, 1343533080, -15648, 268844484, 610404932, 0, 1, 269512264, = 1343411584, 269463008, 0, 269514775, 269512264, 0, 269484032,=20 269514775, 269615104, 269510192, 0, -15632, -15628, 1, = 1, 0 , 184, 268523004, 0, -13888, 1343356928, = 1350589132, 904808974, 0, -8184, 3, 268500992, 268566528,=20 268566528, 23, 1343489540, 0, 0, 0, 0, 1, 1, 0, 1224, 0, = 0, 0, 0, 771751936, 0, 0, 0, 0, 0, 0, 0, 0, 0}}}, eh_parent =3D 0x0, = eh_state =3D 2} pidpath =3D '\000' ... pid =3D #15 0x10085d6c in run_work_group (wgrp=3D, = flags=3D) at /usr/src/contrib/sendmail/src/queue.c:2276 sequenceno =3D 1 now =3D rpool =3D 0x5012d580 e =3D 0x10106e48 endgrp =3D 0 qdir =3D qgrp =3D i =3D h =3D full =3D more =3D njobs =3D #16 0x10084a18 in runqueue (forkflag=3D, = verbose=3D, persistent=3D269484032, runall=3D0) at = /usr/src/contrib/sendmail/src/queue.c:1545 rwgflags =3D 1 wasblocked =3D curnum =3D 0 oldgroup =3D 0 ret =3D 1 cursh =3D i =3D 0 #17 0x100628e4 in main (argc=3D, argv=3D, = envp=3D) at /usr/src/contrib/sendmail/src/main.c:2555 qtype =3D "Queue runner@00:30:00 for /var/spool/clientmqueue", = '\000' , "\377\370", '\000' , = "\377\377\314`", '\000' , = "\377\377\327\060\000\000\000\000\000\000\000\000g\247\220+\000\350\067\36= 4\377\377\314\210P\024\060\004PW\337\330\377\377\315\000P\022\251,\000\000= \000\000\377\377\314\360P\020\206\344" dtype =3D "+queueing@00:30:00\000\060D = \f\240\000\000\000\000Pcl\240Pcl\250\000\000\360\062\000\000\f\000P\017\36= 0\000B", '\000' starttime =3D 1588220070 rnamebuf =3D "root", '\000' traf_st =3D {st_dev =3D 0, st_ino =3D 1, st_nlink =3D 0, st_mode = =3D 0, st_padding0 =3D 0, st_uid =3D 0, st_gid =3D 0, st_padding1 =3D 0, = st_rdev =3D 0, st_atim =3D {tv_sec =3D 0, tv_nsec =3D 0}, st_mtim =3D { tv_sec =3D 0, tv_nsec =3D 0}, st_ctim =3D {tv_sec =3D 0, = tv_nsec =3D 0}, st_birthtim =3D {tv_sec =3D 0, tv_nsec =3D 0}, st_size =3D= 1343500292, st_blocks =3D 0, st_blksize =3D 0, st_flags =3D 0, st_gen =3D= 0,=20 st_spare =3D {25769795072, 18446706793393422336, = 18446706485499010232, 1073743008, 1153877804845105152, = 5769342402355519307, 18446708107653414912, 5769342402355519472, = 34359738372,=20 1343489540}} buf =3D "[IPv6:0:0:0:0:0:0:0:1]", '\000' ... jbuf =3D "localhost.my.domain", '\000' emptyenviron =3D {0x0} foregroundqueue =3D queuepersistent =3D quarantining =3D queuegroup =3D conffile =3D 0x0 sysloglabel =3D authinfo =3D nullserver =3D 0x0 debug =3D queuerun =3D run_in_foreground =3D warn_f_flag =3D warn_C_flag =3D 0 p_flags =3D 0x0 safecf =3D 1 qgrp =3D extraprivs =3D 606210628 cftype =3D 2 fill_errno =3D 0 smdebug =3D i =3D dp =3D av =3D p =3D j =3D pw =3D from =3D hp =3D negate =3D ep =3D new =3D forged =3D 0 st =3D tls_ok =3D save_val =3D e =3D (gdb) disass Dump of assembler code for function arena_dalloc_bin_locked_impl: 0x506a1158 <+0>: mflr r0 0x506a115c <+4>: stw r0,4(r1) 0x506a1160 <+8>: stwu r1,-48(r1) 0x506a1164 <+12>: stw r30,40(r1) 0x506a1168 <+16>: stw r23,12(r1) 0x506a116c <+20>: stw r24,16(r1) 0x506a1170 <+24>: stw r25,20(r1) 0x506a1174 <+28>: stw r26,24(r1) 0x506a1178 <+32>: stw r27,28(r1) 0x506a117c <+36>: stw r28,32(r1) 0x506a1180 <+40>: stw r29,36(r1) 0x506a1184 <+44>: bl 0x506a1188 = 0x506a1188 <+48>: mr r26,r3 0x506a118c <+52>: mflr r30 0x506a1190 <+56>: addis r30,r30,14 0x506a1194 <+60>: addi r30,r30,20388 0x506a1198 <+64>: mr r27,r4 0x506a119c <+68>: lwz r3,6040(r30) 0x506a11a0 <+72>: andi. r4,r9,1 0x506a11a4 <+76>: mr r25,r8 0x506a11a8 <+80>: mr r28,r7 0x506a11ac <+84>: mr r29,r5 0x506a11b0 <+88>: lbz r3,0(r3) 0x506a11b4 <+92>: addi r23,r7,40 0x506a11b8 <+96>: mulli r24,r6,48 0x506a11bc <+100>: cmpwi cr1,r3,0 0x506a11c0 <+104>: cror 4*cr5+lt,4*cr1+eq,gt 0x506a11c4 <+108>: bge cr5,0x506a14e4 = 0x506a11c8 <+112>: lwz r3,4(r28) 0x506a11cc <+116>: lwz r4,6264(r30) 0x506a11d0 <+120>: lwz r5,8(r28) 0x506a11d4 <+124>: li r8,1 0x506a11d8 <+128>: rlwinm r6,r3,16,23,29 0x506a11dc <+132>: lwzx r6,r4,r6 0x506a11e0 <+136>: subf r5,r5,r25 0x506a11e4 <+140>: lwz r4,0(r28) 0x506a11e8 <+144>: mulhwu r6,r6,r5 0x506a11ec <+148>: rlwinm r5,r6,29,3,29 =3D> 0x506a11f0 <+152>: lwzx r7,r23,r5 0x506a11f4 <+156>: clrlwi r9,r6,27 0x506a11f8 <+160>: slw r8,r8,r9 0x506a11fc <+164>: xor r8,r8,r7 0x506a1200 <+168>: cmplwi r7,0 0x506a1204 <+172>: stwx r8,r23,r5 0x506a1208 <+176>: bne 0x506a1280 = 0x506a120c <+180>: lwz r5,4440(r30) 0x506a1210 <+184>: rlwinm r7,r3,14,25,31 0x506a1214 <+188>: mulli r7,r7,48 0x506a1218 <+192>: add r5,r5,r7 0x506a121c <+196>: lwz r5,20(r5) 0x506a1220 <+200>: cmplwi r5,2 0x506a1224 <+204>: blt 0x506a1280 = 0x506a1228 <+208>: lwz r8,4440(r30) 0x506a122c <+212>: rlwinm r6,r6,27,5,31 0x506a1230 <+216>: li r9,2 0x506a1234 <+220>: add r7,r8,r7 0x506a1238 <+224>: addi r7,r7,24 0x506a123c <+228>: li r8,1 . . . (gdb) info reg r0 0x506a1148 1349128520 r1 0xffffb8f0 4294949104 r2 0x5014b018 1343533080 r3 0x0 0 r4 0x0 0 r5 0x1405694 20993684 r6 0xa02b4a4 167949476 r7 0x50a0af40 1352707904 r8 0x1 1 r9 0x1 1 r10 0xffffc2e0 4294951648 r11 0x50102f94 1343238036 r12 0x84220a44 2216823364 r13 0x0 0 r14 0x0 0 r15 0x0 0 r16 0x47 71 r17 0x47 71 r18 0x0 0 r19 0xffffb940 4294949184 r20 0x18 24 r21 0x0 0 r22 0xffffb940 4294949184 r23 0x50a0af68 1352707944 r24 0x120 288 r25 0x5015a520 1343595808 r26 0x50144018 1343504408 r27 0x50a00380 1352663936 r28 0x50a0af40 1352707904 r29 0x50a02e08 1352674824 r30 0x5078612c 1350066476 r31 0xffffba50 4294949456 pc 0x506a11f0 0x506a11f0 = msr cr 0x424a0a44 1112148548 lr 0x506a1188 0x506a1188 = ctr 0x50102f94 1343238036 xer 0x0 0 fpscr 0x82024000 -2113781760 vscr vrsave =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Fri May 1 08:16:12 2020 Return-Path: Delivered-To: freebsd-hackers@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 2327B2CDDE2 for ; Fri, 1 May 2020 08:16:12 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) 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 49D4p332kpz4Cb7 for ; Fri, 1 May 2020 08:16:11 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.nyi.freebsd.org (Postfix) id 667A42CDDE1; Fri, 1 May 2020 08:16:11 +0000 (UTC) Delivered-To: hackers@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 664172CDDE0 for ; Fri, 1 May 2020 08:16:11 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49D4p12PCMz4Cb6 for ; Fri, 1 May 2020 08:16:08 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=To:Date:Message-Id:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:From; bh=RPqUyv0wF64C5p2F2JTLVYuw0RXxdn7lraig5A7Yc80=; b=uiE4ms3prIT5xYInEe/sy74hILIDjoer3rbwoKtOlbeUqPP52WjuVkHUhHYu10wNKpF43AWxxetQKalR1d4InHD6J+8fxY++mWcbAtKwobKwh+OOaRDPalbuK9cZjxXSYrO74CgUaB4XTz9oXZJVObX6IR8v7JyGKHNguadgFAMIeMflEonc67cAOFGF97x+cq40kafAsh6sYcRrTQ6TtDqERmw0D9z0J5UqleIxWUOnlq0PABWRf4fwL8mMDn6FdSHqCI1atJdf5h1/p0087X0hlYoPSzZXcydkZgROF2XKuGzmznhsO+DHgbRy3b2hK0EMHKrM62c5BwL1tIKm6w==; Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1jUQq6-0001rM-ET for hackers@freebsd.org; Fri, 01 May 2020 11:16:06 +0300 From: Daniel Braniss Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: efi boot question Message-Id: <8B798F61-783C-4A1C-AEED-4B42E88E5010@cs.huji.ac.il> Date: Fri, 1 May 2020 11:16:06 +0300 To: hackers@freebsd.org X-Mailer: Apple Mail (2.3445.9.1) X-Rspamd-Queue-Id: 49D4p12PCMz4Cb6 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=uiE4ms3p; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-4.66 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-2.36)[ip: (-6.12), ipnet: 132.64.0.0/13(-3.19), asn: 378(-2.55), country: IL(0.05)]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; RCVD_IN_DNSWL_NONE(0.00)[210.116.65.132.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/13, country:IL]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 08:16:12 -0000 hi, I have none efi boot that: - the bios is set to do network boot/pxe - if the dhcpd.conf is configured with filename set to pxeboot, = it loads as diskless,=20 or if set to =E2=80=9Cpmbr=E2=80=9D then goes and boots off = the hard disk. (this is faster than changing the bios boot order) so now i'm experimenting with efi boot,=20 the GPT is: =3D> 40 5857345456 mfid0 GPT (2.7T) 40 409600 1 efi (200M) 409640 8388608 2 freebsd-ufs ( 4.0G) 8798248 100663296 3 freebsd-swap (48G) 109461544 5747883952 4 freebsd-zfs (2.7T) but am at loss figuring out what boot file to download. any insight is appreciated, thanks, danny From owner-freebsd-hackers@freebsd.org Fri May 1 08:42:47 2020 Return-Path: Delivered-To: freebsd-hackers@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 20E6B2CEAE9 for ; Fri, 1 May 2020 08:42:47 +0000 (UTC) (envelope-from trond.endrestol@ximalas.info) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49D5Nk4hSBz4F54 for ; Fri, 1 May 2020 08:42:46 +0000 (UTC) (envelope-from trond.endrestol@ximalas.info) Received: by mailman.nyi.freebsd.org (Postfix) id A0FA02CEAE8; Fri, 1 May 2020 08:42:46 +0000 (UTC) Delivered-To: hackers@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 A0C292CEAE7 for ; Fri, 1 May 2020 08:42:46 +0000 (UTC) (envelope-from trond.endrestol@ximalas.info) Received: from enterprise.ximalas.info (enterprise.ximalas.info [IPv6:2001:700:1100:1::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ximalas.info", Issuer "Hostmaster ximalas.info" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49D5Nj2lhhz4F53 for ; Fri, 1 May 2020 08:42:44 +0000 (UTC) (envelope-from trond.endrestol@ximalas.info) Received: from enterprise.ximalas.info (Ximalas@localhost [127.0.0.1]) by enterprise.ximalas.info (8.15.2/8.15.2) with ESMTPS id 0418gMAm021901 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 1 May 2020 10:42:22 +0200 (CEST) (envelope-from trond.endrestol@ximalas.info) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ximalas.info; s=default; t=1588322543; bh=A9jt+jtunQbHmrFuJ4B6uBS1Sj6DaydRZzQGcq+HzPM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=KGv0T9rvHRXkh59t+Yn/B48SA38QChUFG1oWzng6z8yUbwK1ycW4kNZBCJ5RTFx15 qos+uLVkKPQD4quQI2LDre3rNGTcAdrFy0A4oRIm8EE5iJNs5nHbgR5HrKU+5pdcly RSsW1gAAarnNfsw1Ska2VqChSGXfrZFZLuki+P5oRbaaehuqtKXoMFGnMqLdlqkgOc tji7OVUkbcHQKU+4nqT0GLRimeQgIZUDdxitKLBg943zSKy8cLHBKheo6aFLHKWTvy 7pkn7PnrZ3M4yfbD+BFclKLdDu9SOM3eUXoXWQK6+fAdPzubn6RJoGH1y4DabUpvPU PX+YwkkgzgGHQ== Received: from localhost (trond@localhost) by enterprise.ximalas.info (8.15.2/8.15.2/Submit) with ESMTP id 0418gLu7021890; Fri, 1 May 2020 10:42:21 +0200 (CEST) (envelope-from trond.endrestol@ximalas.info) X-Authentication-Warning: enterprise.ximalas.info: trond owned process doing -bs Date: Fri, 1 May 2020 10:42:21 +0200 (CEST) From: =?UTF-8?Q?Trond_Endrest=C3=B8l?= Sender: Trond.Endrestol@ximalas.info To: Daniel Braniss cc: hackers@freebsd.org Subject: Re: efi boot question In-Reply-To: <8B798F61-783C-4A1C-AEED-4B42E88E5010@cs.huji.ac.il> Message-ID: References: <8B798F61-783C-4A1C-AEED-4B42E88E5010@cs.huji.ac.il> User-Agent: Alpine 2.22 (BSF 395 2020-01-19) OpenPGP: url=http://ximalas.info/about/tronds-openpgp-public-key MIME-Version: 1.0 X-Spam-Status: No, score=-1.2 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on enterprise.ximalas.info X-Rspamd-Queue-Id: 49D5Nj2lhhz4F53 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ximalas.info header.s=default header.b=KGv0T9rv; dmarc=pass (policy=none) header.from=ximalas.info; spf=pass (mx1.freebsd.org: domain of trond.endrestol@ximalas.info designates 2001:700:1100:1::8 as permitted sender) smtp.mailfrom=trond.endrestol@ximalas.info X-Spamd-Result: default: False [-4.08 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[ximalas.info:s=default]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; HAS_XAW(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[ximalas.info:+]; CTYPE_MIXED_BOGUS(1.00)[]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[ximalas.info,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:224, ipnet:2001:700::/32, country:NO]; IP_SCORE(-2.08)[ip: (-8.44), ipnet: 2001:700::/32(-1.26), asn: 224(-0.71), country: NO(-0.02)] Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 08:42:47 -0000 On Fri, 1 May 2020 11:16+0300, Daniel Braniss wrote: > hi, > I have none efi boot that: > - the bios is set to do network boot/pxe > - if the dhcpd.conf is configured with filename set to pxeboot, it loads as diskless, > or if set to “pmbr” then goes and boots off the hard disk. > (this is faster than changing the bios boot order) > > > so now i'm experimenting with efi boot, > the GPT is: > > => 40 5857345456 mfid0 GPT (2.7T) > 40 409600 1 efi (200M) > 409640 8388608 2 freebsd-ufs ( 4.0G) > 8798248 100663296 3 freebsd-swap (48G) > 109461544 5747883952 4 freebsd-zfs (2.7T) > > but am at loss figuring out what boot file to download. > any insight is appreciated, You can try this: gpart bootcode -p /boot/boot1.efifat -i 1 mfid0 This will populate /dev/mdid0p1 with a FAT filesystem containing /boot/boot1.efi, saved as efi/boot/BOOTx64.efi. You may later replace the latter file with /boot/loader.efi. You will also find efi/boot/startup.nsh which simple instructs the boot firmware to load and run BOOTx64.efi. I haven't worked out how you can grow the small 800K FAT filesystem to take advantage of your 200M partition. And indeed, we will need an ESP of more than 800K in the near future. This fstab entry might be handy: # Device Mountpoint FStype Options Dump Pass# /dev/mfid0p1 /esp msdosfs rw,-l,-m=664,-M=775,noauto 0 0 -- Trond. From owner-freebsd-hackers@freebsd.org Fri May 1 09:36:20 2020 Return-Path: Delivered-To: freebsd-hackers@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 364BA2CFECE for ; Fri, 1 May 2020 09:36:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-20.consmr.mail.gq1.yahoo.com (sonic309-20.consmr.mail.gq1.yahoo.com [98.137.65.146]) (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 49D6ZV3lZMz4HVw for ; Fri, 1 May 2020 09:36:18 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: mFbs9jcVM1lEtlj9E6lWHtV7NCqoBOwb_BGR8Tp.RuYTiuKbIZdgXQbuSGAtcfL iBLJkuJk.THvflagmlUrPFZa7vWWAPWQLYjjlDdPbdCJGllyt6AQ48MUWDDYIeYa0bvveealjIkx jbLt.Xpk3FfYsUFNcvVrpkddndLPoAkcSkVR2QvirvZP1GMlVq3Wb_mktfkWTEDKBFVaz6lXC9fL KS71isEn0tB6ISaofcQITvW6XFOcXHdcku6WkBfSpLYvCCh5DhxT9xDyyt4YTc7yy8KpvJlTIGrC 8ZVrUUW4NjjO16vQWyE8kf2.wME8qosvK7Cv2zDS80tEdnLNNHNfjUFkpYKVzX63Pzfe9TrWc8YZ hBtSqK1uQtJFiX6WZVfL7hhSE.IkpZtSCGwIoOgM7KrQtaLgxx6fTRd47gUi4CxI64mGsXj9xf0W 1wSiI_G7dpnxjEd844PBApFc3TigKsJG.92_lllk78hkeJ2U7FqLROIOh6rDDtPYGI0u5CaBSCiU 0jMyXaRR1rkydeSFnl0d4hMJGxm7_xXZq7zJb17iqJ2KpT2W5_vknLYkpsDz67kTrcyY5ySqvFq9 Qz.GfEAqHnSaTj7dwJvr_84o6fdlIPBE1i3fyZpSCq1D8Gd.TwmLw_9qwjR955drGqIiqzXPHLwY zCpUIc6jjPQUq_reGr0aupgTvjb8d1puc.Qbl3uAhkLOd1RFPSFyU5dCsmR2E2mOV6HSrIonkVZu tYDnaJ3rot6OK3Or.aa4sL9vchi40EzhQtGv9GHmJ7hfzr5i0jCydfDwZPrj91tZtq6R9.6jes_4 jw7TWyQr.8OD0qXBMGZqKxanSFMhiXDv1IgDhmFX2Jb2pafnWAOI3WfjFBP4aNTv4VI105ibDs9n 9E0gr5_32lhtdexz4GCcIxOEYFwUgFMuWelHwrDlwpGjVnwpLHAD5A6m8Jqu0GRZI0F1py_xdcMZ .9E95A_mT4.Q3_aM9hEV_oVMEsLdtQV3i45xGTEAC2nLgHokrTdz8YZl5XqHTHWBfg9yBNAEXALB .xZ0nRma9zeKePUQDdloGUX6LEit_Y4kBvDR7fo6hZm16i_XA4X5qc0i1KZBgAOxUwCVasZEtgI8 dOseoo7piqeBEt5G6nHJQ33q0TJeoqyqlVF5SLOeAdxgJrDQZTcsa2smkHGn93uvW5svdvQZCbZs zI.W4hyz3bHwzH5G1hlg5kQrTmQpa26GqvkyGZ46z_LTcINHOdUNlFAmC_wJA5.Ln95LK.kjBYdK RHzX3JcQ4WF7fWrEUbgJUDoW4QEI1NXCn.frBq3xUMMByQeYoZ_NncJjeasfK84J7q8C_xdkMAFh Vyzy56TQaM6w_N9OkJLUruwgAUCp_7jI_BVwtrAd8tldUiBSDWcDZ0nVxYOE_C5bL8goNKqTYrwn SFQOphvPooVps0JyocnTnPg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Fri, 1 May 2020 09:36:16 +0000 Received: by smtp410.mail.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 682561493c4a7b8ff05a7d1b98a098d2; Fri, 01 May 2020 09:36:13 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: 32-bit powerpc head -r360311: lock order reversal between: "PROC (UMA zone)" and "kernelpmap (kernelpmap)": Is this expected? Date: Fri, 1 May 2020 02:36:12 -0700 References: <013FB43E-7DB1-4A66-A6ED-12A891539788@yahoo.com> To: FreeBSD PowerPC ML , FreeBSD Hackers , FreeBSD Current In-Reply-To: <013FB43E-7DB1-4A66-A6ED-12A891539788@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49D6ZV3lZMz4HVw X-Spamd-Bar: + X-Spamd-Result: default: False [1.79 / 15.00]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (6.64), ipnet: 98.137.64.0/21(0.82), asn: 36647(0.66), country: US(-0.05)]; NEURAL_SPAM_MEDIUM(0.41)[0.413,0]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.87)[0.873,0]; RCVD_IN_DNSWL_NONE(0.00)[146.65.137.98.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[146.65.137.98.rep.mailspike.net : 127.0.0.17]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 09:36:20 -0000 On 2020-Apr-30, at 18:30, Mark Millard wrote: > Using artifact.ci's head -r360311 debug-kernel materials: >=20 > = https://artifact.ci.freebsd.org/snapshot/head/r360311/powerpc/powerpc/kern= el*.txz >=20 > I got the following notice: >=20 > lock order reversal: > 1st 0x1cbb680 PROC (UMA zone) @ /usr/src/sys/vm/uma_core.c:4387 > 2nd 0x113c99c kernelpmap (kernelpmap) @ = /usr/src/sys/powerpc/aim/mmu_oea.c:1524 > stack backtrace: > #0 0x5d1e5c at witness_debugger+0x94 > #1 0x5d1b34 at witness_checkorder+0xb50 > #2 0x51d774 at __mtx_lock_flags+0xcc > #3 0x90902c at moea_kextract+0x5c > #4 0x9462ac at pmap_kextract+0x98 > #5 0x8a417c at zone_release+0xf0 > #6 0x8abc14 at bucket_drain+0x2f0 > #7 0x8ab64c at bucket_free+0x54 > #8 0x8ab8bc at bucket_cache_reclaim+0x1bc > #9 0x8ab3c4 at zone_reclaim+0x128 > #10 0x8a7e60 at uma_reclaim+0x1d0 > #11 0x8d96ac at vm_pageout_worker+0x4d8 > #12 0x8d91c0 at vm_pageout+0x1b0 > #13 0x4f67a0 at fork_exit+0xb0 > #14 0x94892c at fork_trampoline+0xc >=20 > Is the above interesting or is it one of the > known-safe lock order reversals that should > be ignored? >=20 > (The notice is from something like 4.5 hours > before I noticed it.) >=20 While running kyua to see what it might run into . . . lock order reversal: 1st 0x1c34800 filedesc0 (UMA zone) @ /usr/src/sys/vm/uma_core.c:4387 2nd 0x113c99c kernelpmap (kernelpmap) @ = /usr/src/sys/powerpc/aim/mmu_oea.c:1524 stack backtrace: #0 0x5d1e5c at witness_debugger+0x94 #1 0x5d1b34 at witness_checkorder+0xb50 #2 0x51d774 at __mtx_lock_flags+0xcc #3 0x90902c at moea_kextract+0x5c #4 0x9462ac at pmap_kextract+0x98 #5 0x8a417c at zone_release+0xf0 #6 0x8abc14 at bucket_drain+0x2f0 #7 0x8ab64c at bucket_free+0x54 #8 0x8ab8bc at bucket_cache_reclaim+0x1bc #9 0x8ab3c4 at zone_reclaim+0x128 #10 0x8a7d58 at uma_reclaim+0xc8 #11 0x656d24 at vnlru_proc+0x908 #12 0x4f67a0 at fork_exit+0xb0 #13 0x94892c at fork_trampoline+0xc witness_debugger through zone_reclaim look the same as the prior report. uma_reclaim has different associated figures. There is also: lock order reversal: 1st 0xfbed24 allprison (allprison) @ /usr/src/sys/kern/kern_jail.c:984 2nd 0x10706c4 vnet_sysinit_sxlock (vnet_sysinit_sxlock) @ = /usr/src/sys/net/vnet.c:577 stack backtrace: #0 0x5d1e5c at witness_debugger+0x94 #1 0x5d1b34 at witness_checkorder+0xb50 #2 0x555300 at _sx_slock_int+0xa0 #3 0x555b10 at _sx_slock+0x28 #4 0x6b7d84 at vnet_alloc+0xf4 #5 0x4fd09c at kern_jail_set+0x1868 #6 0x4fe938 at sys_jail_set+0x70 #7 0x9492fc at trap+0x748 #8 0x93d1c0 at powerpc_interrupt+0x178 And: lock order reversal: 1st 0x106f5d8 ifnet_sx (ifnet_sx) @ /usr/src/sys/netinet/in.c:914 2nd 0x107071c in_control (in_control) @ /usr/src/sys/netinet/in.c:243 stack backtrace: #0 0x5d1e5c at witness_debugger+0x94 #1 0x5d1b34 at witness_checkorder+0xb50 #2 0x553ca4 at _sx_xlock+0x98 #3 0x6c45b8 at in_ifscrub_all+0xec #4 0x6dbbc4 at ip_destroy+0xb0 #5 0x6b81c0 at vnet_destroy+0x154 #6 0x4fefb0 at prison_deref+0x2cc #7 0x5007dc at prison_remove_one+0x148 #8 0x500658 at sys_jail_remove+0x2a4 #9 0x9492fc at trap+0x748 #10 0x93d1c0 at powerpc_interrupt+0x178 I also do not know about the below GEOM topology related lock order reversals . . . lock order reversal: 1st 0xfbca1c GEOM topology (GEOM topology) @ = /usr/src/sys/geom/eli/g_eli.c:746 2nd 0xd49000 allproc (allproc) @ /usr/src/sys/kern/kern_fork.c:382 stack backtrace: #0 0x5d1e5c at witness_debugger+0x94 #1 0x5d1b34 at witness_checkorder+0xb50 #2 0x553ca4 at _sx_xlock+0x98 #3 0x4f4fb4 at fork1+0x7dc #4 0x5041c8 at kproc_create+0xd4 #5 0xdd27c390 at g_eli_create+0x774 #6 0xdd281048 at g_eli_config+0x23fc #7 0x499188 at g_ctl_req+0x154 #8 0x49e784 at g_run_events+0x194 #9 0x4a1580 at g_event_procbody+0x74 #10 0x4f67a0 at fork_exit+0xb0 #11 0x94892c at fork_trampoline+0xc lock order reversal: 1st 0xfbca1c GEOM topology (GEOM topology) @ = /usr/src/sys/geom/eli/g_eli.c:746 2nd 0xd2baccc8 filedesc structure (filedesc structure) @ = /usr/src/sys/kern/kern_descrip.c:2064 stack backtrace: #0 0x5d1e5c at witness_debugger+0x94 #1 0x5d1b34 at witness_checkorder+0xb50 #2 0x555300 at _sx_slock_int+0xa0 #3 0x555b10 at _sx_slock+0x28 #4 0x4dc128 at fdinit+0xe8 #5 0x4dc638 at fdcopy+0x68 #6 0x4f52ac at fork1+0xad4 #7 0x5041c8 at kproc_create+0xd4 #8 0xdd27c390 at g_eli_create+0x774 #9 0xdd281048 at g_eli_config+0x23fc #10 0x499188 at g_ctl_req+0x154 #11 0x49e784 at g_run_events+0x194 #12 0x4a1580 at g_event_procbody+0x74 #13 0x4f67a0 at fork_exit+0xb0 #14 0x94892c at fork_trampoline+0xc lock order reversal: 1st 0xfbca1c GEOM topology (GEOM topology) @ = /usr/src/sys/geom/eli/g_eli.c:746 2nd 0xd49080 proctree (proctree) @ /usr/src/sys/kern/kern_fork.c:557 stack backtrace: #0 0x5d1e5c at witness_debugger+0x94 #1 0x5d1b34 at witness_checkorder+0xb50 #2 0x553ca4 at _sx_xlock+0x98 #3 0x4f5650 at fork1+0xe78 #4 0x5041c8 at kproc_create+0xd4 #5 0xdd27c390 at g_eli_create+0x774 #6 0xdd281048 at g_eli_config+0x23fc #7 0x499188 at g_ctl_req+0x154 #8 0x49e784 at g_run_events+0x194 #9 0x4a1580 at g_event_procbody+0x74 #10 0x4f67a0 at fork_exit+0xb0 #11 0x94892c at fork_trampoline+0xc =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Fri May 1 09:54:00 2020 Return-Path: Delivered-To: freebsd-hackers@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 18DA22D08DE for ; Fri, 1 May 2020 09:54:00 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49D6yv2Fk6z4K0l for ; Fri, 1 May 2020 09:53:59 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.nyi.freebsd.org (Postfix) id 4B7AF2D08DD; Fri, 1 May 2020 09:53:59 +0000 (UTC) Delivered-To: hackers@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 4B3492D08DC for ; Fri, 1 May 2020 09:53:59 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49D6yt3qmCz4K0k for ; Fri, 1 May 2020 09:53:58 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type:Message-Id:From; bh=G+NYUzNEASnSysYWN/HDAFB7w6eQrf9TGHgyQMs59LE=; b=Ki07krcx7enFxZNyykkX/xWqZNsc8Vzb4r11+QYf9iCDbYdW8/8s4f8Cv4paEFFaU7KM9eQJ7UATtv6rHEu1igTa4QiCXVVCLrpf+OHhfYqHg7SwTjWJwF7dBpyXQHX7GE65Rmm7JsQQFLNyPJFEw0izQXdnhkH8GmE14qvJoC93xIpRYxOU9dSuKLxglT3QPmgjzbvgktP52nveLPwliXVwWwJO3L/Vx5YR/ExuPUhc5dDJO8lxBWxUCmsM8Wz8XK2Kz+nHtYP3q3xVLkM/VIg3dt5TFQPCkr4sGJL/KioGAQaFfdOk/h5JaBw3IDFEKmc4EDM6yW5HQdmgUoFMqQ==; Received: from macmini.bk.cs.huji.ac.il ([132.65.179.19]) by kabab.cs.huji.ac.il with esmtp id 1jUSMl-0007EX-Oy; Fri, 01 May 2020 12:53:55 +0300 From: Daniel Braniss Message-Id: <9FAAF98B-77D1-4D39-8E8E-D20F2B4C2E5C@cs.huji.ac.il> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: efi boot question Date: Fri, 1 May 2020 12:53:48 +0300 In-Reply-To: Cc: hackers@freebsd.org To: =?utf-8?Q?Trond_Endrest=C3=B8l?= References: <8B798F61-783C-4A1C-AEED-4B42E88E5010@cs.huji.ac.il> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49D6yt3qmCz4K0k X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=Ki07krcx; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-4.70 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; IP_SCORE(-2.40)[ip: (-6.24), ipnet: 132.64.0.0/13(-3.24), asn: 378(-2.59), country: IL(0.05)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[210.116.65.132.list.dnswl.org : 127.0.10.0]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/13, country:IL]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 09:54:00 -0000 > On 1 May 2020, at 11:42, Trond Endrest=C3=B8l = wrote: >=20 > On Fri, 1 May 2020 11:16+0300, Daniel Braniss wrote: >=20 >> hi, >> I have none efi boot that: >> - the bios is set to do network boot/pxe >> - if the dhcpd.conf is configured with filename set to pxeboot, = it loads as diskless,=20 >> or if set to =E2=80=9Cpmbr=E2=80=9D then goes and boots off = the hard disk. >> (this is faster than changing the bios boot order) >>=20 >>=20 >> so now i'm experimenting with efi boot,=20 >> the GPT is: >>=20 >> =3D> 40 5857345456 mfid0 GPT (2.7T) >> 40 409600 1 efi (200M) >> 409640 8388608 2 freebsd-ufs ( 4.0G) >> 8798248 100663296 3 freebsd-swap (48G) >> 109461544 5747883952 4 freebsd-zfs (2.7T) >>=20 >> but am at loss figuring out what boot file to download. >> any insight is appreciated, >=20 > You can try this: >=20 > gpart bootcode -p /boot/boot1.efifat -i 1 mfid0 >=20 > This will populate /dev/mdid0p1 with a FAT filesystem containing=20 > /boot/boot1.efi, saved as efi/boot/BOOTx64.efi. You may later replace=20= > the latter file with /boot/loader.efi. You will also find=20 > efi/boot/startup.nsh which simple instructs the boot firmware to load=20= > and run BOOTx64.efi. >=20 > I haven't worked out how you can grow the small 800K FAT filesystem to=20= > take advantage of your 200M partition. And indeed, we will need an ESP=20= > of more than 800K in the near future. >=20 > This fstab entry might be handy: >=20 > # Device Mountpoint FStype Options = Dump Pass# > /dev/mfid0p1 /esp msdosfs rw,-l,-m=3D664,-M=3D775,noauto = 0 0 >=20 > --=20 > Trond. the fat partition is fine, has all that is needed, but I need the right bootblock instead of pmbr, and there are many *efi* in = /boot and I don=E2=80=99t know which one to use :-( thanks, danny From owner-freebsd-hackers@freebsd.org Fri May 1 15:34:44 2020 Return-Path: Delivered-To: freebsd-hackers@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 CA3E52D876C for ; Fri, 1 May 2020 15:34:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49DGX43ZS0z3DNT for ; Fri, 1 May 2020 15:34:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.nyi.freebsd.org (Postfix) id 788A72D876B; Fri, 1 May 2020 15:34:44 +0000 (UTC) Delivered-To: hackers@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 7842F2D876A for ; Fri, 1 May 2020 15:34:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) 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 49DGX25VL6z3DNS for ; Fri, 1 May 2020 15:34:42 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72d.google.com with SMTP id k81so6857025qke.5 for ; Fri, 01 May 2020 08:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qhNCaw4DXB7Vj0cBrrVEtLJUDeZqVVHqqhG/gxaBpE0=; b=OA3dAwCDwBfgdveb99E3UA29yeF/QUwop7Rw71ruPPFkb5lyuJNt8b3NJHqDMZbQCl yEHqW5m+4CiwdYI51dne2oQCS8sZg3ibDvcB65zhkftWSArH2S4YaIoYdFG5NefJb/YZ EXCngcbMhBg6AL8/ntM3bZfUt5Q8P75/th/muL9fvco+ooHZyaCLzL+7RPsKLn4xT2l9 IUmONMqR423xVCG6MWMfsdGg/Smkz5m9dRwuSWxF95pvEqW8bzlzCOBRrZz5vj26NFIa pSahyM6YCZcrbyIGFZRNrg7lj57YI/6V+ITsDsusa6iwNXQpkpbmlwZlDa9W9DMy9+t/ 9S2g== 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=qhNCaw4DXB7Vj0cBrrVEtLJUDeZqVVHqqhG/gxaBpE0=; b=PujvdJ2hIuaI6Dho0Js1H/sWk3YAXDNOodM4Vs7Lry7++FqMXMg/Na3RZtzr5JyGPD XDT2QvBx8enQ7tPsZCBM1xzYetuePMC69ncNqkMo2dZbJpH9i99mOcpA8vqbUMgONSsB iAzTQEq5B1RO4jh4AvSKbILxkmrVhHiblt6yxFzSd3t6odncBaAK45FpcyuC+TudNC8Y OGu+xBsQajklwHciKZW1JVYDOkC6ZQjGBrMMwpj4Z/zOu/eAj0phWwMOrpQ8GjD1A58T 34eHeZMSZd8PObJozYsn3XuPBotAAaD5n0JvzEgKzIAg6pUYfDfEnpOxS1pXzZmAwuXs vGRA== X-Gm-Message-State: AGi0PuZbjtRru7jh1guZS4shKxu3G+pzogr7PcZ8uNUfcLAbh8AEpZTn 4DhLDLf1FZH4tFxwhIpMXEIGgld7OVICfjYTJ//40A== X-Google-Smtp-Source: APiQypLEjO0xSIs480sl4e1hhLRKLUaMIz5iGPtHlc/kSTA6MTpLJnLuDUkLPjaDcZifWtXQh3W/VoPfzg473ngCDus= X-Received: by 2002:a37:6ce:: with SMTP id 197mr4024781qkg.495.1588347281270; Fri, 01 May 2020 08:34:41 -0700 (PDT) MIME-Version: 1.0 References: <8B798F61-783C-4A1C-AEED-4B42E88E5010@cs.huji.ac.il> <9FAAF98B-77D1-4D39-8E8E-D20F2B4C2E5C@cs.huji.ac.il> In-Reply-To: <9FAAF98B-77D1-4D39-8E8E-D20F2B4C2E5C@cs.huji.ac.il> From: Warner Losh Date: Fri, 1 May 2020 09:34:30 -0600 Message-ID: Subject: Re: efi boot question To: Daniel Braniss Cc: =?UTF-8?Q?Trond_Endrest=C3=B8l?= , "freebsd-hackers@freebsd.org" X-Rspamd-Queue-Id: 49DGX25VL6z3DNS X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=OA3dAwCD; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::72d) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[hackers@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:+]; RCVD_IN_DNSWL_NONE(0.00)[d.2.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.00)[ip: (-9.19), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 15:34:44 -0000 On Fri, May 1, 2020 at 3:54 AM Daniel Braniss wrote: > > > > On 1 May 2020, at 11:42, Trond Endrest=C3=B8l > wrote: > > > > On Fri, 1 May 2020 11:16+0300, Daniel Braniss wrote: > > > >> hi, > >> I have none efi boot that: > >> - the bios is set to do network boot/pxe > >> - if the dhcpd.conf is configured with filename set to pxeboot, i= t > loads as diskless, > >> or if set to =E2=80=9Cpmbr=E2=80=9D then goes and boots off the= hard disk. > >> (this is faster than changing the bios boot order) > >> > >> > >> so now i'm experimenting with efi boot, > >> the GPT is: > >> > >> =3D> 40 5857345456 mfid0 GPT (2.7T) > >> 40 409600 1 efi (200M) > >> 409640 8388608 2 freebsd-ufs ( 4.0G) > >> 8798248 100663296 3 freebsd-swap (48G) > >> 109461544 5747883952 4 freebsd-zfs (2.7T) > >> > >> but am at loss figuring out what boot file to download. > >> any insight is appreciated, > > > > You can try this: > > > > gpart bootcode -p /boot/boot1.efifat -i 1 mfid0 > > > > This will populate /dev/mdid0p1 with a FAT filesystem containing > > /boot/boot1.efi, saved as efi/boot/BOOTx64.efi. You may later replace > > the latter file with /boot/loader.efi. You will also find > > efi/boot/startup.nsh which simple instructs the boot firmware to load > > and run BOOTx64.efi. > > > > I haven't worked out how you can grow the small 800K FAT filesystem to > > take advantage of your 200M partition. And indeed, we will need an ESP > > of more than 800K in the near future. > > > > This fstab entry might be handy: > > > > # Device Mountpoint FStype Options > Dump Pass# > > /dev/mfid0p1 /esp msdosfs rw,-l,-m=3D664,-M=3D775,noauto = 0 > 0 > > > > -- > > Trond. > > > the fat partition is fine, has all that is needed, but > I need the right bootblock instead of pmbr, and there are many *efi* in > /boot and I don=E2=80=99t > know which one to use :-( > You don't need boot blocks in UEFI. Create the FAT partition, use newfs_msdos to initialize it. mount it and create a top-level directory named EFI. There are several options from here: (1) use the 'old style' of putting boot1.efi or loader.efi into EFI/BOOT/BOOTX64.EFI. If you have a really simple setup, this is likely the easiest. It usually works (though there are exceptions for some crazy BIOSes). This works because the UEFI BIOS looks for removable devices with a ESP that has /EFI/BOOT/BOOTxxx.EFI (where xxx varies on architecture, for AMD64 its X64). It loads this. Both boot1.efi and loader.efi know what to do from here if your root filesystem is on the same disk as the ESP. boot1.efi searches a little harder for things, while loader.efi is more disciplined in what it searches for to allow for predictable behavior. This option works great for a FreeBSD only machine. (2) Use the new style. mount the esp somewhere, say /boot/efi. Put loader.efi into /boot/efi/EFI/FreeBSD and use the following command: efibootmgr --create --loader /boot/efi/efi/freebsd/loader.efi --kernel /boot/kernel/kernel --label "FreeBSD Rocks" --activate --verbose which creates and activates a UEFI boot variable, that tells it to load loader.efi first and have it load the default kernel and to label it "FreeBSD Rocks". This also works well for FreeBSD only machines and gives you more control if you are doing things like having redundant partitions and you want to nail down exactly the right one. This also works for people that want to have multiple versions of FreeBSD on the machine (though 11 and older works less well than 12 and newer). (3) There are a number of 3rd party chain loaders rEFInd is likely the most popular. I don't use those, so I can't comment on them further. These work well when you have multiple OSes that each have their own fussy notion of the proper early boot setup. Warner From owner-freebsd-hackers@freebsd.org Fri May 1 16:45:47 2020 Return-Path: Delivered-To: freebsd-hackers@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 05B7D2D9F2C for ; Fri, 1 May 2020 16:45:47 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) 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 49DJ622xWcz3JC6 for ; Fri, 1 May 2020 16:45:46 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.nyi.freebsd.org (Postfix) id 631022D9F29; Fri, 1 May 2020 16:45:46 +0000 (UTC) Delivered-To: hackers@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 62CF32D9F28 for ; Fri, 1 May 2020 16:45:46 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49DJ606Glhz3JC5 for ; Fri, 1 May 2020 16:45:44 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.huji.ac.il; s=57791128; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type:Message-Id:From; bh=K15BdRScFOXyiEyTiSjrYvUsdm1xHrH8fCrIivfeG/g=; b=rFd9uQWV0iZVOfPTEGCpHV03ZqCeZhFs4/udJulhXkbYo25ztlTPr9R51WKmbL+fDCBbOV21X7IfSdUEbV6gfQn0rfxACnIqNC95Zc7HC3SIifJANRJntS3tk8alvi5sVKpXCjMZKYaQgYDwlbgjvI0e2qW/WbmkwGh016wontVJ/9RscpR78ChIXR+3USx4x4QqgSwE3i1iKl2mqc0PCye/yMBzNgz5g85MXvUegsdbd9LRHNwU5UTrJZeWz9ggzdaNBMTR9AKSItL8nJGgG55kvuR7kvVkEJ4nkOEScqbv165W6vUQxosqpibPnOPvx4ThdZkU9c+1dS7pH/rrhw==; Received: from macmini.bk.cs.huji.ac.il ([132.65.179.19]) by kabab.cs.huji.ac.il with esmtp id 1jUYnE-0003Nj-Mt; Fri, 01 May 2020 19:45:40 +0300 From: Daniel Braniss Message-Id: Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: efi boot question Date: Fri, 1 May 2020 19:45:40 +0300 In-Reply-To: Cc: =?utf-8?Q?Trond_Endrest=C3=B8l?= , "freebsd-hackers@freebsd.org" To: Warner Losh References: <8B798F61-783C-4A1C-AEED-4B42E88E5010@cs.huji.ac.il> <9FAAF98B-77D1-4D39-8E8E-D20F2B4C2E5C@cs.huji.ac.il> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49DJ606Glhz3JC5 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cs.huji.ac.il header.s=57791128 header.b=rFd9uQWV; dmarc=pass (policy=none) header.from=huji.ac.il; spf=none (mx1.freebsd.org: domain of danny@cs.huji.ac.il has no SPF policy when checking 132.65.116.210) smtp.mailfrom=danny@cs.huji.ac.il X-Spamd-Result: default: False [-4.74 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[cs.huji.ac.il:s=57791128]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; IP_SCORE(-2.44)[ip: (-6.35), ipnet: 132.64.0.0/13(-3.29), asn: 378(-2.63), country: IL(0.05)]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cs.huji.ac.il:+]; DMARC_POLICY_ALLOW(-0.50)[huji.ac.il,none]; RCVD_IN_DNSWL_NONE(0.00)[210.116.65.132.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:378, ipnet:132.64.0.0/13, country:IL]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 16:45:47 -0000 > On 1 May 2020, at 18:34, Warner Losh wrote: >=20 >=20 >=20 > On Fri, May 1, 2020 at 3:54 AM Daniel Braniss > wrote: >=20 >=20 > > On 1 May 2020, at 11:42, Trond Endrest=C3=B8l = > = wrote: > >=20 > > On Fri, 1 May 2020 11:16+0300, Daniel Braniss wrote: > >=20 > >> hi, > >> I have none efi boot that: > >> - the bios is set to do network boot/pxe > >> - if the dhcpd.conf is configured with filename set to = pxeboot, it loads as diskless,=20 > >> or if set to =E2=80=9Cpmbr=E2=80=9D then goes and boots off = the hard disk. > >> (this is faster than changing the bios boot order) > >>=20 > >>=20 > >> so now i'm experimenting with efi boot,=20 > >> the GPT is: > >>=20 > >> =3D> 40 5857345456 mfid0 GPT (2.7T) > >> 40 409600 1 efi (200M) > >> 409640 8388608 2 freebsd-ufs ( 4.0G) > >> 8798248 100663296 3 freebsd-swap (48G) > >> 109461544 5747883952 4 freebsd-zfs (2.7T) > >>=20 > >> but am at loss figuring out what boot file to download. > >> any insight is appreciated, > >=20 > > You can try this: > >=20 > > gpart bootcode -p /boot/boot1.efifat -i 1 mfid0 > >=20 > > This will populate /dev/mdid0p1 with a FAT filesystem containing=20 > > /boot/boot1.efi, saved as efi/boot/BOOTx64.efi. You may later = replace=20 > > the latter file with /boot/loader.efi. You will also find=20 > > efi/boot/startup.nsh which simple instructs the boot firmware to = load=20 > > and run BOOTx64.efi. > >=20 > > I haven't worked out how you can grow the small 800K FAT filesystem = to=20 > > take advantage of your 200M partition. And indeed, we will need an = ESP=20 > > of more than 800K in the near future. > >=20 > > This fstab entry might be handy: > >=20 > > # Device Mountpoint FStype Options = Dump Pass# > > /dev/mfid0p1 /esp msdosfs rw,-l,-m=3D664,-M=3D775,noauto = 0 0 > >=20 > > --=20 > > Trond. >=20 >=20 > the fat partition is fine, has all that is needed, but > I need the right bootblock instead of pmbr, and there are many *efi* = in /boot and I don=E2=80=99t > know which one to use :-( >=20 > You don't need boot blocks in UEFI. >=20 > Create the FAT partition, use newfs_msdos to initialize it. mount it = and create a top-level directory named EFI. >=20 > There are several options from here: >=20 > (1) use the 'old style' of putting boot1.efi or loader.efi into = EFI/BOOT/BOOTX64.EFI. If you have a really simple setup, this is likely = the easiest. It usually works (though there are exceptions for some = crazy BIOSes). This works because the UEFI BIOS looks for removable = devices with a ESP that has /EFI/BOOT/BOOTxxx.EFI (where xxx varies on = architecture, for AMD64 its X64). It loads this. Both boot1.efi and = loader.efi know what to do from here if your root filesystem is on the = same disk as the ESP. boot1.efi searches a little harder for things, = while loader.efi is more disciplined in what it searches for to allow = for predictable behavior. This option works great for a FreeBSD only = machine. >=20 > (2) Use the new style. mount the esp somewhere, say /boot/efi. Put = loader.efi into /boot/efi/EFI/FreeBSD and use the following command: > efibootmgr --create --loader /boot/efi/efi/freebsd/loader.efi --kernel = /boot/kernel/kernel --label "FreeBSD Rocks" --activate --verbose >=20 > which creates and activates a UEFI boot variable, that tells it to = load loader.efi first and have it load the default kernel and to label = it "FreeBSD Rocks". >=20 > This also works well for FreeBSD only machines and gives you more = control if you are doing things like having redundant partitions and you = want to nail down exactly the right one. This also works for people that = want to have multiple versions of FreeBSD on the machine (though 11 and = older works less well than 12 and newer). >=20 > (3) There are a number of 3rd party chain loaders rEFInd is likely the = most popular. I don't use those, so I can't comment on them further. = These work well when you have multiple OSes that each have their own = fussy notion of the proper early boot setup. >=20 > Warner my problem is that the bios is set to network boot/pxe. In such case the dhcp responds with =E2=80=98filename=E2=80=99. With no efi = partition, just freebsd-boot, setting file to pmbr - which get loaded = via tftp , it works fine, it boots from the disk =E2=80=99s freebd-ufs partition - if there are several, setting = bootme does the trick. my problem is that using pmbr it failed when the partition is efi (fat = and all the files are there) with no boot found - or something similar. so im wondering if there is some other file tat can be loaded via tftp = that will load the right stuff from the efi/fat partition. danny From owner-freebsd-hackers@freebsd.org Fri May 1 16:57:35 2020 Return-Path: Delivered-To: freebsd-hackers@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 8520B2DA3A1 for ; Fri, 1 May 2020 16:57:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 49DJMg1Smmz3KBh for ; Fri, 1 May 2020 16:57:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.nyi.freebsd.org (Postfix) id 307352DA3A0; Fri, 1 May 2020 16:57:35 +0000 (UTC) Delivered-To: hackers@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 302A92DA39F for ; Fri, 1 May 2020 16:57:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) 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 49DJMf3CrXz3KBg for ; Fri, 1 May 2020 16:57:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x834.google.com with SMTP id x12so8353125qts.9 for ; Fri, 01 May 2020 09:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=86s9UsiN4CqKb3ropsaXjmsxqnjntADf1zshRW66bxY=; b=rX8f56viqiHAVCt8vM7kaK8MfNoukk8DWNUi5uRnGew6O5ToP7sFWtNHgH7b4Ym+2r WieI7hb6PYVE/P5LVsEmWj4BxnFUMrAmCIbQ+TC5PyVgwxxyST/rgiqURAw3Sk7NP5x1 EKIxhQxIWE+P38iH8jJPZPc2FNzwSnyRjclQU7MHnFZbMEmE4VrXsfPEqor46N5j9nRE mY8zRqv2pruc5rI5dhFZLDeEhocI3HcLt+1CeQ+bvrWXIP/axOP1UVqoOHAYAh2YOzV9 rpDyNfVRkeUXv0sHW3qmRopGh1cQ6Awm+IzgWJ5zsUwm9sr3qRZqqppxIe9d9cH/SMnK R9UQ== 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=86s9UsiN4CqKb3ropsaXjmsxqnjntADf1zshRW66bxY=; b=Yjtn1hbNjXCX49fxaKf6/lEblPiLSUgOoTsRxOmwuIeiWwpn+vzfdg+eIVwLterArK vVjseujL/uidWpCco0yUvg9fO40Yc5AW1gp5qq7nM9WsgRSHnmD8QTewJJb1SZVWFLG7 A+Q5OXVSWOmMeHhiXC1EjYvkLPA+FcE/zllGKQXO/R9tm84iEm/phs7WdCT/9cxcfmSy 6XoU99W0YhDc4KcIt25BM/Zh9OhUGumpQiLemeRnxXfAfABPE+A2IexM9ZS07vjfM+Si 3jIMauKIq4IocCG/+7PpBqEOpNdmBLFHbaZZ1xfbgZj3Nv0YftJwfJekcYLoPzYng52N YYfA== X-Gm-Message-State: AGi0PuZtokDSMNnnXWT9D9hamO71OzRFDseBGW/YCpWuBWep1ozGjmNi nFCueoGx+nv+DkurglpV4mtZ06JIlAPNkf8IMxlp7xk1xJ0= X-Google-Smtp-Source: APiQypJYZKI/6RnAmQH1TVv0xqlkBT06vUkBDX4G8yfmk76sN+ts8DO4bZysH3Lv3X8UmpufF68M0rS2IdN1D5HFhMg= X-Received: by 2002:ac8:3844:: with SMTP id r4mr4652936qtb.32.1588352253261; Fri, 01 May 2020 09:57:33 -0700 (PDT) MIME-Version: 1.0 References: <8B798F61-783C-4A1C-AEED-4B42E88E5010@cs.huji.ac.il> <9FAAF98B-77D1-4D39-8E8E-D20F2B4C2E5C@cs.huji.ac.il> In-Reply-To: From: Warner Losh Date: Fri, 1 May 2020 10:57:22 -0600 Message-ID: Subject: Re: efi boot question To: Daniel Braniss Cc: =?UTF-8?Q?Trond_Endrest=C3=B8l?= , "freebsd-hackers@freebsd.org" X-Rspamd-Queue-Id: 49DJMf3CrXz3KBg X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=rX8f56vi; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::834) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-4.02 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[hackers@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:+]; RCVD_IN_DNSWL_NONE(0.00)[4.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.02)[ip: (-9.28), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 16:57:35 -0000 On Fri, May 1, 2020 at 10:45 AM Daniel Braniss wrote: > > > On 1 May 2020, at 18:34, Warner Losh wrote: > > > > On Fri, May 1, 2020 at 3:54 AM Daniel Braniss wrote= : > >> >> >> > On 1 May 2020, at 11:42, Trond Endrest=C3=B8l >> wrote: >> > >> > On Fri, 1 May 2020 11:16+0300, Daniel Braniss wrote: >> > >> >> hi, >> >> I have none efi boot that: >> >> - the bios is set to do network boot/pxe >> >> - if the dhcpd.conf is configured with filename set to pxeboot, >> it loads as diskless, >> >> or if set to =E2=80=9Cpmbr=E2=80=9D then goes and boots off th= e hard disk. >> >> (this is faster than changing the bios boot order) >> >> >> >> >> >> so now i'm experimenting with efi boot, >> >> the GPT is: >> >> >> >> =3D> 40 5857345456 mfid0 GPT (2.7T) >> >> 40 409600 1 efi (200M) >> >> 409640 8388608 2 freebsd-ufs ( 4.0G) >> >> 8798248 100663296 3 freebsd-swap (48G) >> >> 109461544 5747883952 4 freebsd-zfs (2.7T) >> >> >> >> but am at loss figuring out what boot file to download. >> >> any insight is appreciated, >> > >> > You can try this: >> > >> > gpart bootcode -p /boot/boot1.efifat -i 1 mfid0 >> > >> > This will populate /dev/mdid0p1 with a FAT filesystem containing >> > /boot/boot1.efi, saved as efi/boot/BOOTx64.efi. You may later replace >> > the latter file with /boot/loader.efi. You will also find >> > efi/boot/startup.nsh which simple instructs the boot firmware to load >> > and run BOOTx64.efi. >> > >> > I haven't worked out how you can grow the small 800K FAT filesystem to >> > take advantage of your 200M partition. And indeed, we will need an ESP >> > of more than 800K in the near future. >> > >> > This fstab entry might be handy: >> > >> > # Device Mountpoint FStype Options >> Dump Pass# >> > /dev/mfid0p1 /esp msdosfs rw,-l,-m=3D664,-M=3D775,noauto >> 0 0 >> > >> > -- >> > Trond. >> >> >> the fat partition is fine, has all that is needed, but >> I need the right bootblock instead of pmbr, and there are many *efi* in >> /boot and I don=E2=80=99t >> know which one to use :-( >> > > You don't need boot blocks in UEFI. > > Create the FAT partition, use newfs_msdos to initialize it. mount it and > create a top-level directory named EFI. > > There are several options from here: > > (1) use the 'old style' of putting boot1.efi or loader.efi into > EFI/BOOT/BOOTX64.EFI. If you have a really simple setup, this is likely t= he > easiest. It usually works (though there are exceptions for some crazy > BIOSes). This works because the UEFI BIOS looks for removable devices wit= h > a ESP that has /EFI/BOOT/BOOTxxx.EFI (where xxx varies on architecture, f= or > AMD64 its X64). It loads this. Both boot1.efi and loader.efi know what to > do from here if your root filesystem is on the same disk as the ESP. > boot1.efi searches a little harder for things, while loader.efi is more > disciplined in what it searches for to allow for predictable behavior. Th= is > option works great for a FreeBSD only machine. > > (2) Use the new style. mount the esp somewhere, say /boot/efi. Put > loader.efi into /boot/efi/EFI/FreeBSD and use the following command: > efibootmgr --create --loader /boot/efi/efi/freebsd/loader.efi --kernel > /boot/kernel/kernel --label "FreeBSD Rocks" --activate --verbose > > which creates and activates a UEFI boot variable, that tells it to load > loader.efi first and have it load the default kernel and to label it > "FreeBSD Rocks". > > This also works well for FreeBSD only machines and gives you more control > if you are doing things like having redundant partitions and you want to > nail down exactly the right one. This also works for people that want to > have multiple versions of FreeBSD on the machine (though 11 and older wor= ks > less well than 12 and newer). > > (3) There are a number of 3rd party chain loaders rEFInd is likely the > most popular. I don't use those, so I can't comment on them further. Thes= e > work well when you have multiple OSes that each have their own fussy noti= on > of the proper early boot setup. > > Warner > > > my problem is that the bios is set to network boot/pxe. In such case > the dhcp responds with =E2=80=98filename=E2=80=99. With no efi partition,= just > freebsd-boot, setting file to pmbr - which get loaded via tftp , it works > fine, it boots from the > disk =E2=80=99s freebd-ufs partition - if there are several, setting boot= me does > the trick. > If pmbr is working, you aren't booting with UEFI... > my problem is that using pmbr it failed when the partition is efi (fat an= d > all the files are there) with no boot found - or something similar. > so im wondering if there is some other file tat can be loaded via tftp > that will load the right stuff from the efi/fat partition. > If pmbr is failing, you may be booting with UEFI, in which case just load loader.efi. If you have several partitions, and want to use the bootme trick, gptboot.efi may be better. Warner