From owner-freebsd-stable@freebsd.org Sun Apr 12 04:41:10 2020 Return-Path: Delivered-To: freebsd-stable@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 BA78A2B107B; Sun, 12 Apr 2020 04:41:10 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 490Jwj6h5Nz4bDK; Sun, 12 Apr 2020 04:41:09 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 03C4fXj7013328 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 11 Apr 2020 21:41:40 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: freebsd-stable From: Chris Reply-To: bsd-lists@BSDforge.com To: freebsd-current Subject: Why is the console a graphic/bitmapped console, and not text/character by default Date: Sat, 11 Apr 2020 21:41:40 -0700 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 490Jwj6h5Nz4bDK X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.60 / 15.00]; NEURAL_HAM_MEDIUM(-0.78)[-0.784,0]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81]; NEURAL_HAM_LONG(-0.82)[-0.821,0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 04:41:10 -0000 Sorry for the ling title=2E But wasn't sure how make my question more concise=2E Why did we begin making an initial console "graphics mode" by default=2E My understanding has always been that (Free)BSD has been a "Server by default", and a Desktop after an initial install if that's one chosen target=2E It's near impossible to perform initial configuration in graphics mode, using a mouse to cut/copy/paste does *not* work as intended=2E Which requires one to make the necessary changes "breaking to the new system" after install completes to change initiation to test-mode before bouncing the box=2E While this "works" for long-time users=2E It's an *extra*, and seemingly *unnecessary* step=2E It is also likely to behoove first-time/new users -- except those already targeting a Desktop=2E Thanks for any insight into this! :) --Chris From owner-freebsd-stable@freebsd.org Sun Apr 12 05:53:45 2020 Return-Path: Delivered-To: freebsd-stable@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 EC6962B3374 for ; Sun, 12 Apr 2020 05:53:45 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 490LXS48W8z4fhK for ; Sun, 12 Apr 2020 05:53:43 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 03C5mI7F046514 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 12 Apr 2020 05:48:21 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: cross+freebsd@distal.com Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id 03C5mCCL000847 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 12 Apr 2020 12:48:12 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: ZFS server has gone crazy slow To: Chris Ross References: <2182C27C-A5D3-41BF-9CE9-7C6883E43074@distal.com> <68328a40-0e3d-f9cf-510b-9cbfd7cb8acd@grosbein.net> <654D00F8-DBEC-49BD-B871-7EB830F49D50@distal.com> Cc: freebsd-stable@freebsd.org From: Eugene Grosbein Message-ID: <89932f19-6aac-5b45-646a-04ceecaaa19d@grosbein.net> Date: Sun, 12 Apr 2020 12:48:06 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <654D00F8-DBEC-49BD-B871-7EB830F49D50@distal.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 490LXS48W8z4fhK X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-3.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[freebsd]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-1.89)[ip: (-5.22), ipnet: 2a01:4f8::/29(-2.61), asn: 24940(-1.58), country: DE(-0.02)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 05:53:46 -0000 12.04.2020 2:25, Chris Ross пишет: > >> On Apr 11, 2020, at 14:33, Eugene Grosbein wrote: >> >> 12.04.2020 0:36, Chris Ross wrote: >> >>> I have a FreeBSD 11.3-STABLE server that is my router, using a ZFS mirror (of two GPT disks) as it’s disk. It’s many years old, and has only been misbehaving like this for a day or so. I’m trying to figure out what’s wrong. >>> >>> […] >>> >>> I _think_ this is a filesystem problem. It’s very hard to diagnose because logging in, and doing anything, takes many seconds per command. zpool status shows my mirror as online, so I’m not sure where I should check. >>> >>> I’d appreciate any help! Thanks much… >> >> First of all you should check if any of your ZFS pools is low on space. > > Wow. I’m so embarrassed that I didn’t notice that myself. You mentioned it, and now I look back at df output and see that the filesystems are all very nearly full! > > It’s very slowly booting now, but assumedly after it comes online, I’ll be able to rectify that situation and hopefully that will be the issue. Thanks, and sorry that I hadn’t seen that myself! There is very simple way to prevent such problem, use: zfs set reservation=1G for single "root" file system of the pool. This way ZFS won't allow applications to fill the pool to the point it starts crawling. Instead, writing applications would obtain ENOSPC error when pool's free space hits the limit. From owner-freebsd-stable@freebsd.org Sun Apr 12 05:56:02 2020 Return-Path: Delivered-To: freebsd-stable@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 9CE132B34E8 for ; Sun, 12 Apr 2020 05:56:02 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 490Lb56WzLz4fqC for ; Sun, 12 Apr 2020 05:56:01 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 03C5ttmx046622 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sun, 12 Apr 2020 05:55:56 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id 03C5trQJ000947 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 12 Apr 2020 12:55:53 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Why is the console a graphic/bitmapped console, and not text/character by default References: From: Eugene Grosbein To: freebsd-stable Message-ID: <548297b0-d720-c3fc-2bca-01025f581515@grosbein.net> Date: Sun, 12 Apr 2020 12:55:47 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 490Lb56WzLz4fqC X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-3.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[grosbein.net]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-1.89)[ip: (-5.22), ipnet: 2a01:4f8::/29(-2.61), asn: 24940(-1.58), country: DE(-0.02)]; TO_DN_ALL(0.00)[]; R_SPF_PERMFAIL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 05:56:02 -0000 12.04.2020 11:41, Chris wrote: > Sorry for the ling title. But wasn't sure how make my > question more concise. > Why did we begin making an initial console "graphics mode" > by default. My understanding has always been that (Free)BSD > has been a "Server by default", and a Desktop after an initial > install if that's one chosen target. > It's near impossible to perform initial configuration > in graphics mode, using a mouse to cut/copy/paste does *not* > work as intended. Which requires one to make the necessary > changes "breaking to the new system" after install completes > to change initiation to test-mode before bouncing the box. > While this "works" for long-time users. It's an *extra*, and > seemingly *unnecessary* step. It is also likely to behoove > first-time/new users -- except those already targeting a > Desktop. > > Thanks for any insight into this! :) There are now many new hardware incapable of booting in legacy mode. It runs in UEFI mode only that needs newer console driver vt(4) that defaults to pixel rendering mode but supports text mode, too. Sadly, some UEFI-based hardware does not support text mode even with vt(4) and there is no option other than using pixel mode then. From owner-freebsd-stable@freebsd.org Sun Apr 12 06:49:59 2020 Return-Path: Delivered-To: freebsd-stable@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 812962B46C0 for ; Sun, 12 Apr 2020 06:49:59 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 490MnM0pZ5z3Dh2 for ; Sun, 12 Apr 2020 06:49:58 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 03C6oNSk058295 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 11 Apr 2020 23:50:30 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: freebsd-stable In-Reply-To: <548297b0-d720-c3fc-2bca-01025f581515@grosbein.net> From: Chris Reply-To: bsd-lists@BSDforge.com To: Eugene Grosbein Subject: Re: Why is the console a graphic/bitmapped console, and not text/character by default Date: Sat, 11 Apr 2020 23:50:29 -0700 Message-Id: <0945b3b641401e1b7c50590169cc5265@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 490MnM0pZ5z3Dh2 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.67 / 15.00]; NEURAL_HAM_MEDIUM(-0.76)[-0.760,0]; NEURAL_HAM_LONG(-0.91)[-0.912,0]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 06:49:59 -0000 On Sun, 12 Apr 2020 12:55:47 +0700 Eugene Grosbein eugen@grosbein=2Enet said > 12=2E04=2E2020 11:41, Chris wrote: >=20 > > Sorry for the ling title=2E But wasn't sure how make my > > question more concise=2E > > Why did we begin making an initial console "graphics mode" > > by default=2E My understanding has always been that (Free)BSD > > has been a "Server by default", and a Desktop after an initial > > install if that's one chosen target=2E > > It's near impossible to perform initial configuration > > in graphics mode, using a mouse to cut/copy/paste does *not* > > work as intended=2E Which requires one to make the necessary > > changes "breaking to the new system" after install completes > > to change initiation to test-mode before bouncing the box=2E > > While this "works" for long-time users=2E It's an *extra*, and > > seemingly *unnecessary* step=2E It is also likely to behoove > > first-time/new users -- except those already targeting a > > Desktop=2E > >=20 > > Thanks for any insight into this! :) >=20 > There are now many new hardware incapable of booting in legacy mode=2E > It runs in UEFI mode only that needs newer console driver vt(4) > that defaults to pixel rendering mode but supports text mode, too=2E > Sadly, some UEFI-based hardware does not support text mode even with vt(4= ) > and there is no option other than using pixel mode then=2E >=20 That explains it=2E Thanks Eugene! :) Even if the answer is a bit disappointing=2E ;) --Chris From owner-freebsd-stable@freebsd.org Sun Apr 12 13:20:25 2020 Return-Path: Delivered-To: freebsd-stable@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 857A62BDD51 for ; Sun, 12 Apr 2020 13:20:25 +0000 (UTC) (envelope-from bounces+13739864-b44a-freebsd-stable=freebsd.org@em848.distal.com) Received: from xtrwsqdf.outbound-mail.sendgrid.net (xtrwsqdf.outbound-mail.sendgrid.net [167.89.100.223]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 490XRr2lDrz478w for ; Sun, 12 Apr 2020 13:20:23 +0000 (UTC) (envelope-from bounces+13739864-b44a-freebsd-stable=freebsd.org@em848.distal.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=distal.com; h=content-type:mime-version:subject:from:in-reply-to: content-transfer-encoding:references:to:cc; s=s1; bh=WYqxpc1adOll+mtuDwxovREymLQos3B+wD6ACe2U3Ck=; b=pkafHskaxmtykKMShvg99PqDiNQENOLQ9DJcMV/U0Yc8aDiHe/XljOXX7inNo40v5hKp dumzzvETazBsA68AbLe10B+GEfRMFRCelgdKpbbhHPyX9reTF0dkhsN6bJUzEonxx84va5 mt+xElHHcbjWphhXp1K9aFT/76RpiOFWU= Received: by filterdrecv-p3iad2-8ddf98858-f4h4l with SMTP id filterdrecv-p3iad2-8ddf98858-f4h4l-19-5E931596-27 2020-04-12 13:20:22.507713452 +0000 UTC m=+1512775.826945572 Received: from mail.distal.com (unknown) by ismtpd0025p1iad2.sendgrid.net (SG) with ESMTP id PjDEVoWgQhSsgK5MrtNgFg Sun, 12 Apr 2020 13:20:22.476 +0000 (UTC) Received: from magrathea.distal.com (magrathea.distal.com [2001:470:e24c:200:14a4:6888:ae02:b3bb]) by tristain.distal.com (OpenSMTPD) with ESMTPSA id 6b1cb353 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Sun, 12 Apr 2020 09:20:21 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: ZFS server has gone crazy slow From: Chris Ross In-Reply-To: <89932f19-6aac-5b45-646a-04ceecaaa19d@grosbein.net> Date: Sun, 12 Apr 2020 13:20:22 +0000 (UTC) Content-Transfer-Encoding: quoted-printable Message-Id: <1B88FA01-D6F5-43BC-9351-9076079DC62D@distal.com> References: <2182C27C-A5D3-41BF-9CE9-7C6883E43074@distal.com> <68328a40-0e3d-f9cf-510b-9cbfd7cb8acd@grosbein.net> <654D00F8-DBEC-49BD-B871-7EB830F49D50@distal.com> <89932f19-6aac-5b45-646a-04ceecaaa19d@grosbein.net> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SG-EID: =?us-ascii?Q?gDj=2Futz1vvM0Gg5Dx3C984MHE5rSknXbUiMX+7YYKy8H35YTA3nJpmg1IQ5mw9?= =?us-ascii?Q?RS2bD=2FH4Uluvnmedtzs9ncXZeNzx2s3PcCGHPFc?= =?us-ascii?Q?E6Y8lnSeWGLBN8tUpm6t6RbW6HAjtWjUN+i5ukY?= =?us-ascii?Q?SlnlrviL99ML3FfFoXgb5xRhUMfmg2zx74kiuOa?= =?us-ascii?Q?NKm00+BKqddYCLmkdbezLj0n2fZDU7REV5NCb2e?= =?us-ascii?Q?B15rsQKbGJ5PepOHWy6L4sKCtljvCZAbqMDvYfs?= =?us-ascii?Q?gOT=2FP7cuBSB5Ft5r8yarQ=3D=3D?= To: Eugene Grosbein Cc: freebsd-stable@freebsd.org X-Rspamd-Queue-Id: 490XRr2lDrz478w X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=distal.com header.s=s1 header.b=pkafHska; dmarc=pass (policy=none) header.from=distal.com; spf=pass (mx1.freebsd.org: domain of bounces@em848.distal.com designates 167.89.100.223 as permitted sender) smtp.mailfrom=bounces@em848.distal.com X-Spamd-Result: default: False [-5.04 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[distal.com:s=s1]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:167.89.0.0/17]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(-2.84)[ip: (-5.87), ipnet: 167.89.96.0/20(-4.61), asn: 11377(-3.67), country: US(-0.05)]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[distal.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[distal.com,none]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FORGED_SENDER(0.30)[cross@distal.com,bounces@em848.distal.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[223.100.89.167.rep.mailspike.net : 127.0.0.17]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:11377, ipnet:167.89.96.0/20, country:US]; TAGGED_FROM(0.00)[13739864-b44a-freebsd-stable=freebsd.org,freebsd]; FROM_NEQ_ENVFROM(0.00)[cross@distal.com,bounces@em848.distal.com] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 13:20:25 -0000 > On Apr 12, 2020, at 01:48, Eugene Grosbein wrote: >=20 > There is very simple way to prevent such problem, use: zfs set reservatio= n=3D1G > for single "root" file system of the pool. >=20 > This way ZFS won't allow applications to fill the pool to the point it st= arts crawling. > Instead, writing applications would obtain ENOSPC error when pool's free = space hits the limit. Done. Thank you for that good advice! In case this system develops the same issue in another year or three and I=E2=80=99ve forgotten this, it wil= l yell at me before getting so logged down. - Chris From owner-freebsd-stable@freebsd.org Sun Apr 12 14:37:17 2020 Return-Path: Delivered-To: freebsd-stable@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 A11052BF512 for ; Sun, 12 Apr 2020 14:37:17 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2a00:14b0:4200:32e0::1ea]) (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 "gilb.zs64.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 490Z8X2X8pz4ByB for ; Sun, 12 Apr 2020 14:37:16 +0000 (UTC) (envelope-from stb@lassitu.de) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 3B12C2082FD for ; Sun, 12 Apr 2020 14:37:08 +0000 (UTC) From: Stefan Bethke Content-Type: multipart/signed; boundary="Apple-Mail=_E513D02F-4583-41C2-834C-6C9356AEB099"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: make kernel ignore broken SATA disk Message-Id: Date: Sun, 12 Apr 2020 16:37:06 +0200 To: freebsd-stable X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 490Z8X2X8pz4ByB X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of stb@lassitu.de designates 2a00:14b0:4200:32e0::1ea as permitted sender) smtp.mailfrom=stb@lassitu.de X-Spamd-Result: default: False [-4.98 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[lassitu.de]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-1.08)[ip: (-2.93), ipnet: 2a00:14b0::/32(-1.50), asn: 13135(-0.93), country: DE(-0.02)]; TO_DN_ALL(0.00)[]; MV_CASE(0.50)[]; SIGNED_PGP(-2.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; ASN(0.00)[asn:13135, ipnet:2a00:14b0::/32, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 14:37:17 -0000 --Apple-Mail=_E513D02F-4583-41C2-834C-6C9356AEB099 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have a server I don't have physical access to right now, which has a = broken SATA disk that produces mostly errors (but not entirely). The disk has two partitions that are part of a zpool each. I can't bring = the system up with this disk being online, because ZFS is trying its = darndest to use it. I already renamed the GPT partitions in the hope that ZFS would not find = them anymore, but it does. I can't gpart destroy -f ada1 because "device busy". Is there a way, ideally in the loader, to tell the kernel to ignore ada1 = and/or ahcich5? Or can I force ZFS some other way to ignore the disk? I = do have a spare disk I can use to replace the failed one, but I can't = get the machine into a state where I could even issue the zpool replace = command. Stefan -- Stefan Bethke Fon +49 151 14070811 --Apple-Mail=_E513D02F-4583-41C2-834C-6C9356AEB099 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEJ+hF98o4r3eU/HiPD885WK4W4sEFAl6TJ5IACgkQD885WK4W 4sF50gf9G3t46VRvzrSuAbyerf6y3hg8Mls8/s+DWIgzBSuGDE2NNJZv7SQKEq0+ n3fIKvc6C0P6dAMYjSFUxGaqKlEiQuwflEXjxAKcgEH7zYtNoZysiMPRI9bhuy59 K4Znn/poSyjFQWgCUzHAwM63I73dTMysDYiNYIADYCNoxh8eDN6nmC3Kmt6FrDux IuBxn6kWBCTImRfEDjXww9FhPmd/6OddbQBaK1OeinYbMBIPCSb3dV2+I0wiQGW+ rBTiXZG4+MPXkeP0ScmAf4ob6oDyr8FT1gl+dXZeGKAk3HXhRc8Pf6/XcB4agMfO Yzlf7MP9dA6ipqO2h0A4oniQruXSfg== =zwnU -----END PGP SIGNATURE----- --Apple-Mail=_E513D02F-4583-41C2-834C-6C9356AEB099-- From owner-freebsd-stable@freebsd.org Sun Apr 12 14:45:43 2020 Return-Path: Delivered-To: freebsd-stable@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 20D912BF84E for ; Sun, 12 Apr 2020 14:45:43 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 490ZLG0hTyz4CMg for ; Sun, 12 Apr 2020 14:45:41 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 03CEjYbB054317 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 12 Apr 2020 14:45:35 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: stb@lassitu.de Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id 03CEjXpH005247 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 12 Apr 2020 21:45:33 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: make kernel ignore broken SATA disk To: Stefan Bethke , freebsd-stable References: From: Eugene Grosbein Message-ID: <14aeff4a-9241-20ef-2827-5a5282d08a94@grosbein.net> Date: Sun, 12 Apr 2020 21:45:26 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 490ZLG0hTyz4CMg X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-3.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-1.89)[ip: (-5.23), ipnet: 2a01:4f8::/29(-2.61), asn: 24940(-1.58), country: DE(-0.02)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 14:45:43 -0000 12.04.2020 21:37, Stefan Bethke wrote: > I have a server I don't have physical access to right now, which has a broken SATA disk that produces mostly errors (but not entirely). > > The disk has two partitions that are part of a zpool each. I can't bring the system up with this disk being online, because ZFS is trying its darndest to use it. > > I already renamed the GPT partitions in the hope that ZFS would not find them anymore, but it does. > > I can't gpart destroy -f ada1 because "device busy". > > Is there a way, ideally in the loader, to tell the kernel to ignore ada1 and/or ahcich5? Or can I force ZFS some other way to ignore the disk? I do have a spare disk I can use to replace the failed one, but I can't get the machine into a state where I could even issue the zpool replace command. It depends on the HDD controller the disk is attached to. What controller and driver does it have? From owner-freebsd-stable@freebsd.org Sun Apr 12 14:57:10 2020 Return-Path: Delivered-To: freebsd-stable@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 0D1DB2BFC01 for ; Sun, 12 Apr 2020 14:57:10 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2a00:14b0:4200:32e0::1ea]) (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 CN "gilb.zs64.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 490ZbS6Vv8z4CxC for ; Sun, 12 Apr 2020 14:57:08 +0000 (UTC) (envelope-from stb@lassitu.de) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 713A02083F0; Sun, 12 Apr 2020 14:57:07 +0000 (UTC) From: Stefan Bethke Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_49CA8FB0-6B6F-4047-879C-86F9F6A65A05"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: make kernel ignore broken SATA disk Date: Sun, 12 Apr 2020 16:57:06 +0200 In-Reply-To: <14aeff4a-9241-20ef-2827-5a5282d08a94@grosbein.net> Cc: freebsd-stable To: Eugene Grosbein References: <14aeff4a-9241-20ef-2827-5a5282d08a94@grosbein.net> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 490ZbS6Vv8z4CxC X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of stb@lassitu.de designates 2a00:14b0:4200:32e0::1ea as permitted sender) smtp.mailfrom=stb@lassitu.de X-Spamd-Result: default: False [-5.23 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MV_CASE(0.50)[]; HAS_ATTACHMENT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; DMARC_NA(0.00)[lassitu.de]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; SIGNED_PGP(-2.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; ASN(0.00)[asn:13135, ipnet:2a00:14b0::/32, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-1.33)[ip: (-3.70), ipnet: 2a00:14b0::/32(-1.81), asn: 13135(-1.14), country: DE(-0.02)] X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 14:57:10 -0000 --Apple-Mail=_49CA8FB0-6B6F-4047-879C-86F9F6A65A05 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Am 12.04.2020 um 16:45 schrieb Eugene Grosbein : >=20 > 12.04.2020 21:37, Stefan Bethke wrote: >=20 >> I have a server I don't have physical access to right now, which has = a broken SATA disk that produces mostly errors (but not entirely). >>=20 >> The disk has two partitions that are part of a zpool each. I can't = bring the system up with this disk being online, because ZFS is trying = its darndest to use it. >>=20 >> I already renamed the GPT partitions in the hope that ZFS would not = find them anymore, but it does. >>=20 >> I can't gpart destroy -f ada1 because "device busy". >>=20 >> Is there a way, ideally in the loader, to tell the kernel to ignore = ada1 and/or ahcich5? Or can I force ZFS some other way to ignore the = disk? I do have a spare disk I can use to replace the failed one, but I = can't get the machine into a state where I could even issue the zpool = replace command. >=20 > It depends on the HDD controller the disk is attached to. What = controller and driver does it have? This is from an identlical machine without disk issues: # camcontrol devlist at scbus4 target 0 lun 0 (ada0,pass0) at scbus5 target 0 lun 0 (ada1,pass1) at scbus6 target 0 lun 0 (ada2,pass2) at scbus8 target 0 lun 0 (pass3) # pciconf -lv ... ahci0@pci0:0:23:0: class=3D0x010601 card=3D0x088415d9 = chip=3D0xa1028086 rev=3D0x31 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Q170/Q150/B150/H170/H110/Z170/CM236 Chipset SATA = Controller [AHCI Mode]' class =3D mass storage subclass =3D SATA ... dmesg: ahci0: port = 0xf050-0xf057,0xf040-0xf043,0xf020-0xf03f mem = 0xdf410000-0xdf411fff,0xdf41e000-0xdf4 1e0ff,0xdf41d000-0xdf41d7ff irq 16 at device 23.0 on pci0 ahci0: AHCI v1.31 with 8 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ahcich6: at channel 6 on ahci0 ahcich7: at channel 7 on ahci0 ahciem0: on ahci0 ada0 at ahcich4 bus 0 scbus4 target 0 lun 0 ada0: ACS-2 ATA SATA 3.x device ada0: Serial Number Z1F4GVC3 ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 2861588MB (5860533168 512 byte sectors) ada0: quirks=3D0x1<4K> ada1 at ahcich5 bus 0 scbus5 target 0 lun 0 ada1: ACS-2 ATA SATA 3.x device ada1: Serial Number W1F5180B ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 2861588MB (5860533168 512 byte sectors) ada1: quirks=3D0x1<4K> ada2 at ahcich6 bus 0 scbus6 target 0 lun 0 ada2: ACS-2 ATA SATA 3.x device ada2: Serial Number Z1F4EJEQ ada2: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled ada2: 2861588MB (5860533168 512 byte sectors) ada2: quirks=3D0x1<4K> Stefan -- Stefan Bethke Fon +49 151 14070811 --Apple-Mail=_49CA8FB0-6B6F-4047-879C-86F9F6A65A05 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEJ+hF98o4r3eU/HiPD885WK4W4sEFAl6TLEIACgkQD885WK4W 4sHgZAgApzX77Z16dPiGMEDU6B0CYDYFRIVgzgzFYv8he9bkj2hPN0loRBdxh4Fw xwGOAIaCGmw4Md79j7839WNpU+o5VnKWKIbltW1FWSD04JOSfXn9hIPI8NVMJW+h PajLtmQw70V18zbgN1/yBhvT6taaDuB15arF3NapAOnqEryDRJvukyCbj/RU/BKZ VEW9potzxK1XLWH8m2CxDXYZ+3NOXOhnIPihnwZ/Xg4CLOxiPnYlYPrCb1qwiKqt 1OODHjwtJSP9OgU6cW8cmnzHF96riXn1TCiRc8LVhZbQNXmvZPYkMZM/jn6Tj0xf xdwHLEp1mHb8nHvDAdQkxDAek2kMWQ== =UCIi -----END PGP SIGNATURE----- --Apple-Mail=_49CA8FB0-6B6F-4047-879C-86F9F6A65A05-- From owner-freebsd-stable@freebsd.org Sun Apr 12 15:43:30 2020 Return-Path: Delivered-To: freebsd-stable@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 1BEE42C105B for ; Sun, 12 Apr 2020 15:43:30 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 490bcx1SVrz4GnJ for ; Sun, 12 Apr 2020 15:43:28 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1jNelT-00098m-Eg; Sun, 12 Apr 2020 18:43:19 +0300 Date: Sun, 12 Apr 2020 18:43:19 +0300 From: Slawa Olhovchenkov To: Stefan Bethke Cc: freebsd-stable Subject: Re: make kernel ignore broken SATA disk Message-ID: <20200412154319.GO8028@zxy.spb.ru> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-Rspamd-Queue-Id: 490bcx1SVrz4GnJ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of slw@zxy.spb.ru has no SPF policy when checking 195.70.199.98) smtp.mailfrom=slw@zxy.spb.ru X-Spamd-Result: default: False [0.44 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.23)[-0.229,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.31)[-0.313,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[zxy.spb.ru]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5495, ipnet:195.70.192.0/19, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.08)[asn: 5495(0.38), country: RU(0.01)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 15:43:30 -0000 On Sun, Apr 12, 2020 at 04:37:06PM +0200, Stefan Bethke wrote: > I have a server I don't have physical access to right now, which has a broken SATA disk that produces mostly errors (but not entirely). > > The disk has two partitions that are part of a zpool each. I can't bring the system up with this disk being online, because ZFS is trying its darndest to use it. > > I already renamed the GPT partitions in the hope that ZFS would not find them anymore, but it does. > > I can't gpart destroy -f ada1 because "device busy". > > Is there a way, ideally in the loader, to tell the kernel to ignore ada1 and/or ahcich5? Or can I force ZFS some other way to ignore the disk? I do have a spare disk I can use to replace the failed one, but I can't get the machine into a state where I could even issue the zpool replace command. `zpool offline pool device` if you have enoght redundancy? From owner-freebsd-stable@freebsd.org Sun Apr 12 16:24:16 2020 Return-Path: Delivered-To: freebsd-stable@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 131B12C1D6F for ; Sun, 12 Apr 2020 16:24:16 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [212.12.50.234]) (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 "gilb.zs64.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 490cWx6kRZz4KQS for ; Sun, 12 Apr 2020 16:24:13 +0000 (UTC) (envelope-from stb@lassitu.de) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 923F3208732; Sun, 12 Apr 2020 16:24:11 +0000 (UTC) From: Stefan Bethke Message-Id: <9D60946A-6D81-444B-B6D0-36202B3BE5C6@lassitu.de> Content-Type: multipart/signed; boundary="Apple-Mail=_A775B64F-4150-456D-B93F-2AA51091F7B7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: make kernel ignore broken SATA disk Date: Sun, 12 Apr 2020 18:24:09 +0200 In-Reply-To: <20200412154319.GO8028@zxy.spb.ru> Cc: freebsd-stable To: Slawa Olhovchenkov References: <20200412154319.GO8028@zxy.spb.ru> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 490cWx6kRZz4KQS X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of stb@lassitu.de designates 212.12.50.234 as permitted sender) smtp.mailfrom=stb@lassitu.de X-Spamd-Result: default: False [-4.17 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MV_CASE(0.50)[]; HAS_ATTACHMENT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; DMARC_NA(0.00)[lassitu.de]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[234.50.12.212.list.dnswl.org : 127.0.10.0]; SIGNED_PGP(-2.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; ASN(0.00)[asn:13135, ipnet:212.12.48.0/21, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-0.27)[asn: 13135(-1.34), country: DE(-0.02)] X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 16:24:16 -0000 --Apple-Mail=_A775B64F-4150-456D-B93F-2AA51091F7B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Am 12.04.2020 um 17:43 schrieb Slawa Olhovchenkov : >=20 > On Sun, Apr 12, 2020 at 04:37:06PM +0200, Stefan Bethke wrote: >=20 >> I have a server I don't have physical access to right now, which has = a broken SATA disk that produces mostly errors (but not entirely). >>=20 >> The disk has two partitions that are part of a zpool each. I can't = bring the system up with this disk being online, because ZFS is trying = its darndest to use it. >>=20 >> I already renamed the GPT partitions in the hope that ZFS would not = find them anymore, but it does. >>=20 >> I can't gpart destroy -f ada1 because "device busy". >>=20 >> Is there a way, ideally in the loader, to tell the kernel to ignore = ada1 and/or ahcich5? Or can I force ZFS some other way to ignore the = disk? I do have a spare disk I can use to replace the failed one, but I = can't get the machine into a state where I could even issue the zpool = replace command. >=20 > `zpool offline pool device` if you have enoght redundancy? I do, but the command doesn't return. Instead, I'm getting loads of sata = error message. -- Stefan Bethke Fon +49 151 14070811 --Apple-Mail=_A775B64F-4150-456D-B93F-2AA51091F7B7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEJ+hF98o4r3eU/HiPD885WK4W4sEFAl6TQKkACgkQD885WK4W 4sHhmwf+Nco2VbIYWnAg8ed9pY27p9u1orH7qZE3WLH1HgaDlpHun1Wnf8rFmMoX Va2qkc5r/vNx0SdSZYBs+EYcgpc31wxs0VhGOokaVZdvjOYDn6c5g4ZKvV3U2iXs 33i/DNUOiXk8ytjaR2c//9n9EddWyngDVPYCSKjRBERh94qN8+556gh8EKkogEva 4RWZdgSSR8uut+tz9fyuqOxwNDLT3DakZm1IFw3LNxtW6o2tQrqtuO7es6NU0edL tzUTxhEiipQoYfgs7yglNZEWPuME/ol9VySpzaGTqRe/4b5b8YKyWb1K9bdu4FJu qZkqx50WSp2gS0xXqXScIRDwRKjgVA== =zWCW -----END PGP SIGNATURE----- --Apple-Mail=_A775B64F-4150-456D-B93F-2AA51091F7B7-- From owner-freebsd-stable@freebsd.org Sun Apr 12 16:29:21 2020 Return-Path: Delivered-To: freebsd-stable@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 DF64A2C1EEE for ; Sun, 12 Apr 2020 16:29:21 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 490cdr3TDqz4KfQ for ; Sun, 12 Apr 2020 16:29:20 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 03CGTDPo055629 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 12 Apr 2020 16:29:14 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: stb@lassitu.de Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id 03CGTCDt006110 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 12 Apr 2020 23:29:12 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: make kernel ignore broken SATA disk To: Stefan Bethke References: <14aeff4a-9241-20ef-2827-5a5282d08a94@grosbein.net> Cc: freebsd-stable From: Eugene Grosbein Message-ID: Date: Sun, 12 Apr 2020 23:29:06 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 490cdr3TDqz4KfQ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-3.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-1.89)[ip: (-5.23), ipnet: 2a01:4f8::/29(-2.61), asn: 24940(-1.58), country: DE(-0.02)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 16:29:21 -0000 12.04.2020 21:57, Stefan Bethke wrote: >>> Is there a way, ideally in the loader, to tell the kernel to ignore ada1 and/or ahcich5? Or can I force ZFS some other way to ignore the disk? I do have a spare disk I can use to replace the failed one, but I can't get the machine into a state where I could even issue the zpool replace command. >> >> It depends on the HDD controller the disk is attached to. What controller and driver does it have? > > This is from an identlical machine without disk issues: > > # camcontrol devlist > at scbus4 target 0 lun 0 (ada0,pass0) > at scbus5 target 0 lun 0 (ada1,pass1) > at scbus6 target 0 lun 0 (ada2,pass2) > at scbus8 target 0 lun 0 (pass3) > # pciconf -lv > ... > ahci0@pci0:0:23:0:class=0x010601 card=0x088415d9 chip=0xa1028086 rev=0x31 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Q170/Q150/B150/H170/H110/Z170/CM236 Chipset SATA Controller [AHCI Mode]' > class = mass storage > subclass = SATA And your FreeBSD version? From owner-freebsd-stable@freebsd.org Sun Apr 12 16:30:30 2020 Return-Path: Delivered-To: freebsd-stable@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 20F872C2011 for ; Sun, 12 Apr 2020 16:30:30 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [212.12.50.234]) (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 CN "gilb.zs64.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 490cg90WQjz4Kn2 for ; Sun, 12 Apr 2020 16:30:28 +0000 (UTC) (envelope-from stb@lassitu.de) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id A68DC2089D5; Sun, 12 Apr 2020 16:30:27 +0000 (UTC) From: Stefan Bethke Message-Id: <822985BC-3EB3-4B38-84B1-9F248A76D94E@lassitu.de> Content-Type: multipart/signed; boundary="Apple-Mail=_1E55B1B7-5A90-4C8C-B09F-EF49520714A2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: make kernel ignore broken SATA disk Date: Sun, 12 Apr 2020 18:30:27 +0200 In-Reply-To: Cc: freebsd-stable To: Eugene Grosbein References: <14aeff4a-9241-20ef-2827-5a5282d08a94@grosbein.net> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 490cg90WQjz4Kn2 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of stb@lassitu.de designates 212.12.50.234 as permitted sender) smtp.mailfrom=stb@lassitu.de X-Spamd-Result: default: False [-4.21 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; MV_CASE(0.50)[]; HAS_ATTACHMENT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; DMARC_NA(0.00)[lassitu.de]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[234.50.12.212.list.dnswl.org : 127.0.10.0]; SIGNED_PGP(-2.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; ASN(0.00)[asn:13135, ipnet:212.12.48.0/21, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-0.31)[asn: 13135(-1.52), country: DE(-0.02)] X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 16:30:30 -0000 --Apple-Mail=_1E55B1B7-5A90-4C8C-B09F-EF49520714A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Am 12.04.2020 um 18:29 schrieb Eugene Grosbein : >=20 > 12.04.2020 21:57, Stefan Bethke wrote: >=20 >>>> Is there a way, ideally in the loader, to tell the kernel to ignore = ada1 and/or ahcich5? Or can I force ZFS some other way to ignore the = disk? I do have a spare disk I can use to replace the failed one, but I = can't get the machine into a state where I could even issue the zpool = replace command. >>>=20 >>> It depends on the HDD controller the disk is attached to. What = controller and driver does it have? >>=20 >> This is from an identlical machine without disk issues: >>=20 >> # camcontrol devlist >> at scbus4 target 0 lun 0 = (ada0,pass0) >> at scbus5 target 0 lun 0 = (ada1,pass1) >> at scbus6 target 0 lun 0 = (ada2,pass2) >> at scbus8 target 0 lun 0 (pass3) >> # pciconf -lv >> ... >> ahci0@pci0:0:23:0:class=3D0x010601 card=3D0x088415d9 chip=3D0xa1028086 = rev=3D0x31 hdr=3D0x00 >> vendor =3D 'Intel Corporation' >> device =3D 'Q170/Q150/B150/H170/H110/Z170/CM236 Chipset SATA = Controller [AHCI Mode]' >> class =3D mass storage >> subclass =3D SATA >=20 > And your FreeBSD version? FreeBSD 12.1-STABLE r358833 amd64 Stefan -- Stefan Bethke Fon +49 151 14070811 --Apple-Mail=_1E55B1B7-5A90-4C8C-B09F-EF49520714A2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEJ+hF98o4r3eU/HiPD885WK4W4sEFAl6TQiMACgkQD885WK4W 4sHEwAf8DG0deE1qd5m2D5owxkQpQfauU9IU8RoIBpNMdHPAjmOvVfi103J/w7nk WoFXx+mQqtLRbWy1KhHNgROA2gYBdu0I/zXbAkJyqVtZCmwxYth7jqXgHXUnH+O/ ADwmj1LX03pBH09onePWwXhaHA8kHk1PIcnQFVV9dhdVE8/oZ7iSMqxUYYWjGr5h 9JXaWpp2H8gZBwYL+ehT2lwi1QN8rLvNe7yjowCNLELVmJwga5tKnd47Tco/uJpN 0vbL7ywYxbHvzwS1errqinjwHQuuB5Bc1mHUMwP8VFFAv4xNf3xuzeEptgCqCJ5t 10X72CDSBUkNEhAd7DBE/huwF6rrOw== =6A+R -----END PGP SIGNATURE----- --Apple-Mail=_1E55B1B7-5A90-4C8C-B09F-EF49520714A2-- From owner-freebsd-stable@freebsd.org Sun Apr 12 16:31:07 2020 Return-Path: Delivered-To: freebsd-stable@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 4B2742C2216 for ; Sun, 12 Apr 2020 16:31:07 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 490cgt2d6Zz4Kwb for ; Sun, 12 Apr 2020 16:31:06 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1jNfVg-0009Q1-JB; Sun, 12 Apr 2020 19:31:04 +0300 Date: Sun, 12 Apr 2020 19:31:04 +0300 From: Slawa Olhovchenkov To: Stefan Bethke Cc: freebsd-stable Subject: Re: make kernel ignore broken SATA disk Message-ID: <20200412163104.GI8012@zxy.spb.ru> References: <20200412154319.GO8028@zxy.spb.ru> <9D60946A-6D81-444B-B6D0-36202B3BE5C6@lassitu.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9D60946A-6D81-444B-B6D0-36202B3BE5C6@lassitu.de> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-Rspamd-Queue-Id: 490cgt2d6Zz4Kwb X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of slw@zxy.spb.ru has no SPF policy when checking 195.70.199.98) smtp.mailfrom=slw@zxy.spb.ru X-Spamd-Result: default: False [0.61 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.15)[-0.153,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.22)[-0.215,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[zxy.spb.ru]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5495, ipnet:195.70.192.0/19, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.08)[asn: 5495(0.37), country: RU(0.01)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 16:31:07 -0000 On Sun, Apr 12, 2020 at 06:24:09PM +0200, Stefan Bethke wrote: > Am 12.04.2020 um 17:43 schrieb Slawa Olhovchenkov : > > > > On Sun, Apr 12, 2020 at 04:37:06PM +0200, Stefan Bethke wrote: > > > >> I have a server I don't have physical access to right now, which has a broken SATA disk that produces mostly errors (but not entirely). > >> > >> The disk has two partitions that are part of a zpool each. I can't bring the system up with this disk being online, because ZFS is trying its darndest to use it. > >> > >> I already renamed the GPT partitions in the hope that ZFS would not find them anymore, but it does. > >> > >> I can't gpart destroy -f ada1 because "device busy". > >> > >> Is there a way, ideally in the loader, to tell the kernel to ignore ada1 and/or ahcich5? Or can I force ZFS some other way to ignore the disk? I do have a spare disk I can use to replace the failed one, but I can't get the machine into a state where I could even issue the zpool replace command. > > > > `zpool offline pool device` if you have enoght redundancy? > > I do, but the command doesn't return. Instead, I'm getting loads of sata error message. What you zpool configuration? From owner-freebsd-stable@freebsd.org Sun Apr 12 16:38:13 2020 Return-Path: Delivered-To: freebsd-stable@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 B0B512C256E for ; Sun, 12 Apr 2020 16:38:13 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [212.12.50.234]) (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 CN "gilb.zs64.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 490cr44FkVz4Lbj for ; Sun, 12 Apr 2020 16:38:12 +0000 (UTC) (envelope-from stb@lassitu.de) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id EEFBA208879; Sun, 12 Apr 2020 16:38:10 +0000 (UTC) From: Stefan Bethke Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_F68B62EB-405E-4D32-91E1-71C70B237AB7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: make kernel ignore broken SATA disk Date: Sun, 12 Apr 2020 18:38:10 +0200 In-Reply-To: <20200412163104.GI8012@zxy.spb.ru> Cc: freebsd-stable To: Slawa Olhovchenkov References: <20200412154319.GO8028@zxy.spb.ru> <9D60946A-6D81-444B-B6D0-36202B3BE5C6@lassitu.de> <20200412163104.GI8012@zxy.spb.ru> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 490cr44FkVz4Lbj X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of stb@lassitu.de designates 212.12.50.234 as permitted sender) smtp.mailfrom=stb@lassitu.de X-Spamd-Result: default: False [-4.24 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; MV_CASE(0.50)[]; HAS_ATTACHMENT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; DMARC_NA(0.00)[lassitu.de]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[234.50.12.212.list.dnswl.org : 127.0.10.0]; SIGNED_PGP(-2.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; ASN(0.00)[asn:13135, ipnet:212.12.48.0/21, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-0.34)[asn: 13135(-1.68), country: DE(-0.02)] X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 16:38:13 -0000 --Apple-Mail=_F68B62EB-405E-4D32-91E1-71C70B237AB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Am 12.04.2020 um 18:31 schrieb Slawa Olhovchenkov : >=20 > On Sun, Apr 12, 2020 at 06:24:09PM +0200, Stefan Bethke wrote: >=20 >> Am 12.04.2020 um 17:43 schrieb Slawa Olhovchenkov : >>>=20 >>> On Sun, Apr 12, 2020 at 04:37:06PM +0200, Stefan Bethke wrote: >>>=20 >>>> I have a server I don't have physical access to right now, which = has a broken SATA disk that produces mostly errors (but not entirely). >>>>=20 >>>> The disk has two partitions that are part of a zpool each. I can't = bring the system up with this disk being online, because ZFS is trying = its darndest to use it. >>>>=20 >>>> I already renamed the GPT partitions in the hope that ZFS would not = find them anymore, but it does. >>>>=20 >>>> I can't gpart destroy -f ada1 because "device busy". >>>>=20 >>>> Is there a way, ideally in the loader, to tell the kernel to ignore = ada1 and/or ahcich5? Or can I force ZFS some other way to ignore the = disk? I do have a spare disk I can use to replace the failed one, but I = can't get the machine into a state where I could even issue the zpool = replace command. >>>=20 >>> `zpool offline pool device` if you have enoght redundancy? >>=20 >> I do, but the command doesn't return. Instead, I'm getting loads of = sata error message. >=20 > What you zpool configuration? This is from the working system. The identifiers are slightly different, = but the structure is identical. # zpool status pool: data state: ONLINE status: Some supported features are not enabled on the pool. The pool = can still be used, but some features are unavailable. action: Enable all features using 'zpool upgrade'. Once this is done, the pool may no longer be accessible by software that does not = support the features. See zpool-features(7) for details. scan: resilvered 176K in 0 days 00:01:28 with 0 errors on Sun May 26 = 21:24:54 2019 config: NAME STATE READ WRITE CKSUM data ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/ls0data ONLINE 0 0 0 gpt/ls1data ONLINE 0 0 0 logs gpt/data0log ONLINE 0 0 0 cache gpt/data0cache ONLINE 0 0 0 errors: No known data errors pool: ls-host state: ONLINE status: Some supported features are not enabled on the pool. The pool = can still be used, but some features are unavailable. action: Enable all features using 'zpool upgrade'. Once this is done, the pool may no longer be accessible by software that does not = support the features. See zpool-features(7) for details. scan: scrub repaired 0 in 0 days 00:06:33 with 0 errors on Sun Apr 12 = 11:46:25 2020 config: NAME STATE READ WRITE CKSUM ls-host ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/ls0host ONLINE 0 0 0 gpt/ls1host ONLINE 0 0 0 logs gpt/host0log ONLINE 0 0 0 cache gpt/host0cache ONLINE 0 0 0 errors: No known data errors -- Stefan Bethke Fon +49 151 14070811 --Apple-Mail=_F68B62EB-405E-4D32-91E1-71C70B237AB7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEJ+hF98o4r3eU/HiPD885WK4W4sEFAl6TQ/IACgkQD885WK4W 4sGJvwgApdeUd8d1h4Xvur4rPeCQmhD02CXvPZml6x6nlBK5fF3hjd1gk3sdTIru yVehvZQft7Jxwj1GvN2foVqvvWkuCTb/2Ye3HmdL8XFE1uBmSaQ1AgljaslnVHC1 jlU09JlDvAAhwSkmFht0DmqA0gYuxwIjVnrfaEIHYGh/O4oMeUmbvacQYcKiFlkf deDTAR24ziUNtdgSeTx5d0GxnJ65h9XcTY9IMVT261TSk519Icykyfq1cVhvjeDj Kii1ytZ4rrJdLIQ1j65Pvib4gfo1DnATwTlHpasfxWt4aG6Ov7ZxJCDxMRemKYBB JzpvM1RBdAw6qmtMM1uTxZcCcrJxXg== =NFVA -----END PGP SIGNATURE----- --Apple-Mail=_F68B62EB-405E-4D32-91E1-71C70B237AB7-- From owner-freebsd-stable@freebsd.org Sun Apr 12 16:53:29 2020 Return-Path: Delivered-To: freebsd-stable@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 87D932C2B2B for ; Sun, 12 Apr 2020 16:53:29 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2k.ore.mailhop.org (outbound2k.ore.mailhop.org [54.148.219.64]) (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 490d9j0Q89z4MTw for ; Sun, 12 Apr 2020 16:53:28 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1586710407; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=iVlp28CjVQcXwfNVZ4Ccvn7K2L0LSAC7EBfnn8W7bOdt8uVINHCy5PTm1tB+xiCHIWaVORKMBkDbA FoC+fdtk/FuUVkE6CxpcyfLHtk1sLGM0od33KBJgjFJgCbe6JAMoT/bMkJFbfKO4Y62aDPuLms+/gR hy5gPc+Gd1EI3vx0l0Nv4kP3lf276kNZzHHuzygu+T6z1x2t3OSvqV8wd1j2vmRsfMrRYPE5CjVMVn dj/UrDHWUwyWcnhItW88g07t9qItDjH2gZEIBMvU53VJ89qIJKGJ7Fm9Y5RxMyrdRN0afLaSXvIYUi 4hFMoWSzVbB+hIwLJE+8Wwy+DBv3neQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=62/0DlZd2nLqvWsNLCKPg222kGzNp8ZpJWoN30r4iH4=; b=kt9ADW6sGnmFtQCQyK1XL9O9eQZBwD1J9vuqKCXuVYshNj0LFOxsxXSrJ2mOPOhLXzAUh0VRbf84w DFh7et8E+lRxqg1MwUmh6+HTxAu2cUX8A8B4uwxy+1z1vKYRrzgFAU6jbN1q8eL63ejBJQpLD+Bnrn S/sUBrVvUV+xYb2SUqvOJ8WynAdWJRIwYa14BgwzaMXrUpO2PGrGAWdUXyi+mvqMXOV35+iJaQoGTr lL8SSJ/R1SPFP6NS+h1iq7ExARfq9QgXwQFqpa58meBAxcZYdLeXNy7crfp1EjoBk+dzQ5k1aacH5B RIVzIUwRwR/EaC0ENVDX+f2Vgdeo6vg== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=62/0DlZd2nLqvWsNLCKPg222kGzNp8ZpJWoN30r4iH4=; b=N+0RiAGDhbyUOnIIKs38cDhaQ2RBPQ+eIXRX7o/IEGGZh4yLCqkcAJF9uf+Lmgm5Sn/T2BFXxD1Tb qyqYWChSGGOHPXGRemxUFqYHXZhUgtj+EpUu5gXXVpA3+gEEYiJWxuDF5opU2USTV2gQ1oaKrUVfvz XtQPL+EImapaE5Cra9YS7AzgsVUvTpAQ5V06iEg/mg4c0f//4dzK6vVRIiF73uwyroaLoxDgSfAdAf HCD2HxHb7GMk4YKC9pSrft8I4+a8v+IauetYMqhmbgBDoVkpNlTdeOgNfPE25vT3JI/FyOhD44kl4D DS8jx4V64DdHDAJyPxGA7HtoRUEfOwQ== X-MHO-RoutePath: aGlwcGll X-MHO-User: 1febc9c9-7cde-11ea-a065-6d02e42e573a X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 1febc9c9-7cde-11ea-a065-6d02e42e573a; Sun, 12 Apr 2020 16:53:26 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 03CGrOsg059134; Sun, 12 Apr 2020 10:53:24 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <36793c9efb905968508e94690b59d926f30af36b.camel@freebsd.org> Subject: Re: make kernel ignore broken SATA disk From: Ian Lepore To: Stefan Bethke , freebsd-stable Date: Sun, 12 Apr 2020 10:53:24 -0600 In-Reply-To: References: Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 490d9j0Q89z4MTw X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.85 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.89)[-0.894,0]; NEURAL_HAM_LONG(-0.96)[-0.960,0]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 16:53:29 -0000 On Sun, 2020-04-12 at 16:37 +0200, Stefan Bethke wrote: > I have a server I don't have physical access to right now, which has > a broken SATA disk that produces mostly errors (but not entirely). > > The disk has two partitions that are part of a zpool each. I can't > bring the system up with this disk being online, because ZFS is > trying its darndest to use it. > > I already renamed the GPT partitions in the hope that ZFS would not > find them anymore, but it does. > > I can't gpart destroy -f ada1 because "device busy". > > Is there a way, ideally in the loader, to tell the kernel to ignore > ada1 and/or ahcich5? Or can I force ZFS some other way to ignore the > disk? I do have a spare disk I can use to replace the failed one, but > I can't get the machine into a state where I could even issue the > zpool replace command. > > The the loader prompt (or in loader.conf without 'set'): set hint.ada.1.disabled=1 -- Ian From owner-freebsd-stable@freebsd.org Sun Apr 12 17:03:42 2020 Return-Path: Delivered-To: freebsd-stable@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 AD4E92C2F04 for ; Sun, 12 Apr 2020 17:03:42 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 490dPT74yhz4N4B for ; Sun, 12 Apr 2020 17:03:41 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1jNg1C-0009Zs-FH; Sun, 12 Apr 2020 20:03:38 +0300 Date: Sun, 12 Apr 2020 20:03:38 +0300 From: Slawa Olhovchenkov To: Stefan Bethke Cc: freebsd-stable Subject: Re: make kernel ignore broken SATA disk Message-ID: <20200412170338.GJ8012@zxy.spb.ru> References: <20200412154319.GO8028@zxy.spb.ru> <9D60946A-6D81-444B-B6D0-36202B3BE5C6@lassitu.de> <20200412163104.GI8012@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-Rspamd-Queue-Id: 490dPT74yhz4N4B X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of slw@zxy.spb.ru has no SPF policy when checking 195.70.199.98) smtp.mailfrom=slw@zxy.spb.ru X-Spamd-Result: default: False [0.81 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.07)[-0.072,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.10)[-0.099,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[zxy.spb.ru]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5495, ipnet:195.70.192.0/19, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.08)[asn: 5495(0.37), country: RU(0.01)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 17:03:42 -0000 On Sun, Apr 12, 2020 at 06:38:10PM +0200, Stefan Bethke wrote: > > > > Am 12.04.2020 um 18:31 schrieb Slawa Olhovchenkov : > > > > On Sun, Apr 12, 2020 at 06:24:09PM +0200, Stefan Bethke wrote: > > > >> Am 12.04.2020 um 17:43 schrieb Slawa Olhovchenkov : > >>> > >>> On Sun, Apr 12, 2020 at 04:37:06PM +0200, Stefan Bethke wrote: > >>> > >>>> I have a server I don't have physical access to right now, which has a broken SATA disk that produces mostly errors (but not entirely). > >>>> > >>>> The disk has two partitions that are part of a zpool each. I can't bring the system up with this disk being online, because ZFS is trying its darndest to use it. > >>>> > >>>> I already renamed the GPT partitions in the hope that ZFS would not find them anymore, but it does. > >>>> > >>>> I can't gpart destroy -f ada1 because "device busy". > >>>> > >>>> Is there a way, ideally in the loader, to tell the kernel to ignore ada1 and/or ahcich5? Or can I force ZFS some other way to ignore the disk? I do have a spare disk I can use to replace the failed one, but I can't get the machine into a state where I could even issue the zpool replace command. > >>> > >>> `zpool offline pool device` if you have enoght redundancy? > >> > >> I do, but the command doesn't return. Instead, I'm getting loads of sata error message. > > > > What you zpool configuration? > > This is from the working system. The identifiers are slightly different, but the structure is identical. what about `zpool detach ` ? > # zpool status > pool: data > state: ONLINE > status: Some supported features are not enabled on the pool. The pool can > still be used, but some features are unavailable. > action: Enable all features using 'zpool upgrade'. Once this is done, > the pool may no longer be accessible by software that does not support > the features. See zpool-features(7) for details. > scan: resilvered 176K in 0 days 00:01:28 with 0 errors on Sun May 26 21:24:54 2019 > config: > > NAME STATE READ WRITE CKSUM > data ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > gpt/ls0data ONLINE 0 0 0 > gpt/ls1data ONLINE 0 0 0 > logs > gpt/data0log ONLINE 0 0 0 > cache > gpt/data0cache ONLINE 0 0 0 > > errors: No known data errors > > pool: ls-host > state: ONLINE > status: Some supported features are not enabled on the pool. The pool can > still be used, but some features are unavailable. > action: Enable all features using 'zpool upgrade'. Once this is done, > the pool may no longer be accessible by software that does not support > the features. See zpool-features(7) for details. > scan: scrub repaired 0 in 0 days 00:06:33 with 0 errors on Sun Apr 12 11:46:25 2020 > config: > > NAME STATE READ WRITE CKSUM > ls-host ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > gpt/ls0host ONLINE 0 0 0 > gpt/ls1host ONLINE 0 0 0 > logs > gpt/host0log ONLINE 0 0 0 > cache > gpt/host0cache ONLINE 0 0 0 > > errors: No known data errors > > > -- > Stefan Bethke Fon +49 151 14070811 > From owner-freebsd-stable@freebsd.org Sun Apr 12 17:08:11 2020 Return-Path: Delivered-To: freebsd-stable@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 10FF22C305C for ; Sun, 12 Apr 2020 17:08:11 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [212.12.50.234]) (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 CN "gilb.zs64.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 490dVf1CRNz4NDV for ; Sun, 12 Apr 2020 17:08:09 +0000 (UTC) (envelope-from stb@lassitu.de) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 651E620896A; Sun, 12 Apr 2020 17:08:08 +0000 (UTC) From: Stefan Bethke Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1A7534D8-3B11-4FA3-8B9A-1C91C2851AA3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: make kernel ignore broken SATA disk Date: Sun, 12 Apr 2020 19:08:06 +0200 In-Reply-To: <20200412170338.GJ8012@zxy.spb.ru> Cc: freebsd-stable To: Slawa Olhovchenkov References: <20200412154319.GO8028@zxy.spb.ru> <9D60946A-6D81-444B-B6D0-36202B3BE5C6@lassitu.de> <20200412163104.GI8012@zxy.spb.ru> <20200412170338.GJ8012@zxy.spb.ru> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 490dVf1CRNz4NDV X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of stb@lassitu.de designates 212.12.50.234 as permitted sender) smtp.mailfrom=stb@lassitu.de X-Spamd-Result: default: False [-6.66 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MV_CASE(0.50)[]; HAS_ATTACHMENT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; DMARC_NA(0.00)[lassitu.de]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[234.50.12.212.list.dnswl.org : 127.0.10.0]; SIGNED_PGP(-2.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; ASN(0.00)[asn:13135, ipnet:212.12.48.0/21, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-2.76)[ip: (-7.96), ipnet: 212.12.48.0/21(-3.98), asn: 13135(-1.83), country: DE(-0.02)] X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 17:08:11 -0000 --Apple-Mail=_1A7534D8-3B11-4FA3-8B9A-1C91C2851AA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Am 12.04.2020 um 19:03 schrieb Slawa Olhovchenkov : >=20 > On Sun, Apr 12, 2020 at 06:38:10PM +0200, Stefan Bethke wrote: >=20 >>=20 >>=20 >>> Am 12.04.2020 um 18:31 schrieb Slawa Olhovchenkov : >>>=20 >>> On Sun, Apr 12, 2020 at 06:24:09PM +0200, Stefan Bethke wrote: >>>=20 >>>> Am 12.04.2020 um 17:43 schrieb Slawa Olhovchenkov : >>>>>=20 >>>>> On Sun, Apr 12, 2020 at 04:37:06PM +0200, Stefan Bethke wrote: >>>>>=20 >>>>>> I have a server I don't have physical access to right now, which = has a broken SATA disk that produces mostly errors (but not entirely). >>>>>>=20 >>>>>> The disk has two partitions that are part of a zpool each. I = can't bring the system up with this disk being online, because ZFS is = trying its darndest to use it. >>>>>>=20 >>>>>> I already renamed the GPT partitions in the hope that ZFS would = not find them anymore, but it does. >>>>>>=20 >>>>>> I can't gpart destroy -f ada1 because "device busy". >>>>>>=20 >>>>>> Is there a way, ideally in the loader, to tell the kernel to = ignore ada1 and/or ahcich5? Or can I force ZFS some other way to ignore = the disk? I do have a spare disk I can use to replace the failed one, = but I can't get the machine into a state where I could even issue the = zpool replace command. >>>>>=20 >>>>> `zpool offline pool device` if you have enoght redundancy? >>>>=20 >>>> I do, but the command doesn't return. Instead, I'm getting loads of = sata error message. >>>=20 >>> What you zpool configuration? >>=20 >> This is from the working system. The identifiers are slightly = different, but the structure is identical. >=20 > what about `zpool detach ` ? Now I can't boot into single user mode anymore, ZFS just waits forever, = and the kernel is printing an endless chain of SATA error messages. I really need a way to remove the broken disk before ZFS tries to access = it, or a way to stop ZFS from try to access the disk. Stefan -- Stefan Bethke Fon +49 151 14070811 --Apple-Mail=_1A7534D8-3B11-4FA3-8B9A-1C91C2851AA3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEJ+hF98o4r3eU/HiPD885WK4W4sEFAl6TSvYACgkQD885WK4W 4sHhFwf9E1AvXWx81Y9RceEK1NkxQQ0kKrfBYuOv2YqQm6X04NqjwDmkogrhXdfG t4jo6qVaZskcnyHPdYj37QZBS5Imw2/j652qixVQ0T9R5yvgCnqt+g6L0Bk3L4O6 n1UVvn3+rgJhdiH7fh0+OAGsmUvZrj6xsjo7osfr7TvFNnMWLrcOk6O0FTa8Cxfw XWEsZ1p8RcX4Rho+R3C4VJUxwy4XacLSpCDCBjiQutqlQCfxgk54aO4Q5ijIZmSg ncXFZggoVo4Q7cEhF2/uSDMbxNzPiNyqsTgpMXaSV8ghs27yw0daGBA8iUgLOTPQ S8yLzZrATA+mOiyWNerfkUXjMaVFYA== =KQBw -----END PGP SIGNATURE----- --Apple-Mail=_1A7534D8-3B11-4FA3-8B9A-1C91C2851AA3-- From owner-freebsd-stable@freebsd.org Sun Apr 12 17:12:53 2020 Return-Path: Delivered-To: freebsd-stable@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 DCFE42C3338 for ; Sun, 12 Apr 2020 17:12:53 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) (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 490dc44kCnz4Nf9 for ; Sun, 12 Apr 2020 17:12:52 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wm1-x341.google.com with SMTP id c195so8617740wme.1 for ; Sun, 12 Apr 2020 10:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=XZFlQUGsI22dY3N1AHYVjSQYRboDmcuV51d5DvhkHxw=; b=Y8MaVo9u8jdZ6ZjAn2Z4tI13D5v87rEPzxjAzAmGPQ1KajXdpwiXOGjWcVgT1MXagz FTpPnPCt8I6VlH0SNNxQ5C5lvfxQQicyjVavsvCmXzNyrj5FGyLLwsmdtqsE9iW6wOy7 E6IvkWhIgvPwf4yT0ERoY0+X2taHRA3AvClfNijSt9/AP7lmaRywIxsypaF3MoW+voFV PMXNvygapBqSAg2PnJTvSxUiTqVwEQTAOlbfVUA9PpLR9pW/1sV7dxYLcIg0bvVFKSTZ QzD4rmzG2Ug15WA8/ud2m9BWVHF6P7PoyC+rXwrRFVzGrJRpQxKZuSpeE8x3vQdJ51pb o8/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=XZFlQUGsI22dY3N1AHYVjSQYRboDmcuV51d5DvhkHxw=; b=PfgEAMqNBbNP6yRBszVvJlMihk5rnnjxvhrFax90yr3AokNnajmYF7qCZXkBp2RYDu TIO6fqUoTHXv4/doNl21K9iKYRkj+Ygw7YoOyB4RGgWnndCCbQrpUG/9t0YByZnCegAC 8RChCaOnE+bD26WnpVHq0B8bH7kx337KlxqZGSHQ/IFO2npFxKmng0USrlweOKUBJOwH zd4NRXkpgstwMLALEPEfiqIhar8hCWGZqvT6SRqeKx+bNz+/RovpLR9KsR8269aSRrQM CLK4PySYYL7OdzbqOT+iTbHexzHVIuHIdyZ/76KHx2h9iSZpC+pIwkM1ceG+F8QqVUS3 74qg== X-Gm-Message-State: AGi0PubAst9bPmmi5EHdD37HVJWksfmC4vP5Wg2sjTsqAGEynCHOgWvU zpSQmka8l9QWJ9r7f72D89h2j1893M4= X-Google-Smtp-Source: APiQypJB1ufe8xaIBl8PDn+BImEWoFy8QRZOMyUPkDwZoH0COHGCRgArcp8WxWNZXwy7ZZ+ewsKxAQ== X-Received: by 2002:a1c:7d4b:: with SMTP id y72mr15210232wmc.11.1586711570052; Sun, 12 Apr 2020 10:12:50 -0700 (PDT) Received: from [10.44.128.75] ([193.117.175.106]) by smtp.gmail.com with ESMTPSA id f83sm11413831wmf.42.2020.04.12.10.12.48 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 12 Apr 2020 10:12:49 -0700 (PDT) Subject: Re: make kernel ignore broken SATA disk To: freebsd-stable@freebsd.org References: <20200412154319.GO8028@zxy.spb.ru> <9D60946A-6D81-444B-B6D0-36202B3BE5C6@lassitu.de> <20200412163104.GI8012@zxy.spb.ru> <20200412170338.GJ8012@zxy.spb.ru> From: Steven Hartland Message-ID: <0f414436-9e4d-d290-bb4b-d590ef67af70@multiplay.co.uk> Date: Sun, 12 Apr 2020 18:12:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Rspamd-Queue-Id: 490dc44kCnz4Nf9 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=multiplay-co-uk.20150623.gappssmtp.com header.s=20150623 header.b=Y8MaVo9u; dmarc=pass (policy=none) header.from=multiplay.co.uk; spf=pass (mx1.freebsd.org: domain of killing@multiplay.co.uk designates 2a00:1450:4864:20::341 as permitted sender) smtp.mailfrom=killing@multiplay.co.uk X-Spamd-Result: default: False [-3.05 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[multiplay-co-uk.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[multiplay-co-uk.20150623.gappssmtp.com:+]; DMARC_POLICY_ALLOW(-0.50)[multiplay.co.uk,none]; RCVD_IN_DNSWL_NONE(0.00)[1.4.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-0.05)[ip: (2.58), ipnet: 2a00:1450::/32(-2.35), asn: 15169(-0.43), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 17:12:53 -0000 On 12/04/2020 18:08, Stefan Bethke wrote: > Am 12.04.2020 um 19:03 schrieb Slawa Olhovchenkov : > > Now I can't boot into single user mode anymore, ZFS just waits forever, and the kernel is printing an endless chain of SATA error messages. > > I really need a way to remove the broken disk before ZFS tries to access it, or a way to stop ZFS from try to access the disk. > > Might be a silly suggestion but unplug it? From owner-freebsd-stable@freebsd.org Sun Apr 12 17:13:19 2020 Return-Path: Delivered-To: freebsd-stable@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 081A22C339D for ; Sun, 12 Apr 2020 17:13:19 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2a00:14b0:4200:32e0::1ea]) (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 "gilb.zs64.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 490dcZ1GsGz4NkS; Sun, 12 Apr 2020 17:13:18 +0000 (UTC) (envelope-from stb@lassitu.de) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 73040208A23; Sun, 12 Apr 2020 17:13:15 +0000 (UTC) From: Stefan Bethke Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_0DF36CDA-6283-496E-A5B1-9968ABAF3E4E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: make kernel ignore broken SATA disk Date: Sun, 12 Apr 2020 19:13:14 +0200 In-Reply-To: <36793c9efb905968508e94690b59d926f30af36b.camel@freebsd.org> Cc: freebsd-stable To: Ian Lepore References: <36793c9efb905968508e94690b59d926f30af36b.camel@freebsd.org> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 490dcZ1GsGz4NkS X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of stb@lassitu.de designates 2a00:14b0:4200:32e0::1ea as permitted sender) smtp.mailfrom=stb@lassitu.de X-Spamd-Result: default: False [-5.59 / 15.00]; ARC_NA(0.00)[]; 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)[]; HAS_ATTACHMENT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; DMARC_NA(0.00)[lassitu.de]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-1.69)[ip: (-4.37), ipnet: 2a00:14b0::/32(-2.10), asn: 13135(-1.97), country: DE(-0.02)]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; SIGNED_PGP(-2.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; ASN(0.00)[asn:13135, ipnet:2a00:14b0::/32, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 17:13:19 -0000 --Apple-Mail=_0DF36CDA-6283-496E-A5B1-9968ABAF3E4E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Am 12.04.2020 um 18:53 schrieb Ian Lepore : >=20 > On Sun, 2020-04-12 at 16:37 +0200, Stefan Bethke wrote: >> I have a server I don't have physical access to right now, which has >> a broken SATA disk that produces mostly errors (but not entirely). >>=20 >> The disk has two partitions that are part of a zpool each. I can't >> bring the system up with this disk being online, because ZFS is >> trying its darndest to use it. >>=20 >> I already renamed the GPT partitions in the hope that ZFS would not >> find them anymore, but it does. >>=20 >> I can't gpart destroy -f ada1 because "device busy". >>=20 >> Is there a way, ideally in the loader, to tell the kernel to ignore >> ada1 and/or ahcich5? Or can I force ZFS some other way to ignore the >> disk? I do have a spare disk I can use to replace the failed one, but >> I can't get the machine into a state where I could even issue the >> zpool replace command. >=20 > The the loader prompt (or in loader.conf without 'set'): >=20 > set hint.ada.1.disabled=3D1 Doesn't seem to have any effect. ada1 still probed, and still prints = error messages to the console. Stefan -- Stefan Bethke Fon +49 151 14070811 --Apple-Mail=_0DF36CDA-6283-496E-A5B1-9968ABAF3E4E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEJ+hF98o4r3eU/HiPD885WK4W4sEFAl6TTCoACgkQD885WK4W 4sFGzgf/dTUeAUKgTpnEyyYsBjWvyewSZ4klsoVUCIvOdeqy0t2NGgh/ntiTJIF2 ttIzdvFLdroaVvVRv+X++ziKyE+iBK4Jr7TrhYjG5C1zGTNDXkLAiWlXxDcYAVsj HVYLOXfpxqB9ZqlHs5OX+vqoDr//tJy492594pCfvRy6uSVtA3xJqBF2XhK6qmeZ TZmo4ZywUkOFR75f2tHfX/y07tjRba8erwVe5bjUoOl+ZIrd87P64G5Bf0O2yzIG Jk0SOoRzp2AMvTSEeTdeaX6kjS0U9c3xalBxoidoT8x5YAsppepBxurjTPQiYQhr wCa6AXbn/vyu4OfSbJigbFf1cz/dCA== =9xFt -----END PGP SIGNATURE----- --Apple-Mail=_0DF36CDA-6283-496E-A5B1-9968ABAF3E4E-- From owner-freebsd-stable@freebsd.org Sun Apr 12 17:25:06 2020 Return-Path: Delivered-To: freebsd-stable@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 8735F2C3B1A for ; Sun, 12 Apr 2020 17:25:06 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 490dt92SZvz4PTw for ; Sun, 12 Apr 2020 17:25:04 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 03CHOv38056578 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 12 Apr 2020 17:24:58 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: stb@lassitu.de Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id 03CHOuoq006585 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 13 Apr 2020 00:24:56 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: make kernel ignore broken SATA disk To: Stefan Bethke References: <14aeff4a-9241-20ef-2827-5a5282d08a94@grosbein.net> <822985BC-3EB3-4B38-84B1-9F248A76D94E@lassitu.de> Cc: freebsd-stable From: Eugene Grosbein Message-ID: <67927c81-1e11-ddbc-3cce-e3e9589b47e5@grosbein.net> Date: Mon, 13 Apr 2020 00:24:49 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <822985BC-3EB3-4B38-84B1-9F248A76D94E@lassitu.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 490dt92SZvz4PTw X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-3.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-1.89)[ip: (-5.24), ipnet: 2a01:4f8::/29(-2.61), asn: 24940(-1.58), country: DE(-0.02)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 17:25:06 -0000 12.04.2020 23:30, Stefan Bethke пишет: > Am 12.04.2020 um 18:29 schrieb Eugene Grosbein >: >> >> 12.04.2020 21:57, Stefan Bethke wrote: >> >>>>> Is there a way, ideally in the loader, to tell the kernel to ignore ada1 and/or ahcich5? Or can I force ZFS some other way to ignore the disk? I do have a spare disk I can use to replace the failed one, but I can't get the machine into a state where I could even issue the zpool replace command. >>>> >>>> It depends on the HDD controller the disk is attached to. What controller and driver does it have? >>> >>> This is from an identlical machine without disk issues: >>> >>> # camcontrol devlist >>> at scbus4 target 0 lun 0 (ada0,pass0) >>> at scbus5 target 0 lun 0 (ada1,pass1) >>> at scbus6 target 0 lun 0 (ada2,pass2) >>> at scbus8 target 0 lun 0 (pass3) >>> # pciconf -lv >>> ... >>> ahci0@pci0:0:23:0:class=0x010601 card=0x088415d9 chip=0xa1028086 rev=0x31 hdr=0x00 >>> vendor = 'Intel Corporation' >>> device = 'Q170/Q150/B150/H170/H110/Z170/CM236 Chipset SATA Controller [AHCI Mode]' >>> class = mass storage >>> subclass = SATA >> >> And your FreeBSD version? > > FreeBSD 12.1-STABLE r358833 amd64 Try something like this at loader prompt: set hint.ahcich.5.disabled=1 or set hint.ada.1.disabled=1 From owner-freebsd-stable@freebsd.org Sun Apr 12 17:27:58 2020 Return-Path: Delivered-To: freebsd-stable@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 D93352C3CAC for ; Sun, 12 Apr 2020 17:27:58 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2a00:14b0:4200:32e0::1ea]) (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 CN "gilb.zs64.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 490dxT4Vpyz4Pjn for ; Sun, 12 Apr 2020 17:27:57 +0000 (UTC) (envelope-from stb@lassitu.de) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 24398208C59; Sun, 12 Apr 2020 17:27:56 +0000 (UTC) From: Stefan Bethke Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C0197F23-99BB-4BEF-8520-862C4157CBBF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: make kernel ignore broken SATA disk Date: Sun, 12 Apr 2020 19:27:55 +0200 In-Reply-To: <67927c81-1e11-ddbc-3cce-e3e9589b47e5@grosbein.net> Cc: freebsd-stable To: Eugene Grosbein References: <14aeff4a-9241-20ef-2827-5a5282d08a94@grosbein.net> <822985BC-3EB3-4B38-84B1-9F248A76D94E@lassitu.de> <67927c81-1e11-ddbc-3cce-e3e9589b47e5@grosbein.net> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 490dxT4Vpyz4Pjn X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of stb@lassitu.de designates 2a00:14b0:4200:32e0::1ea as permitted sender) smtp.mailfrom=stb@lassitu.de X-Spamd-Result: default: False [-5.79 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MV_CASE(0.50)[]; HAS_ATTACHMENT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; DMARC_NA(0.00)[lassitu.de]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; SIGNED_PGP(-2.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; ASN(0.00)[asn:13135, ipnet:2a00:14b0::/32, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-1.89)[ip: (-4.96), ipnet: 2a00:14b0::/32(-2.35), asn: 13135(-2.10), country: DE(-0.02)] X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 17:27:58 -0000 --Apple-Mail=_C0197F23-99BB-4BEF-8520-862C4157CBBF Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Am 12.04.2020 um 19:24 schrieb Eugene Grosbein : > > Try something like this at loader prompt: > > set hint.ahcich.5.disabled=1 Thank you, that did the trick! Stefan -- Stefan Bethke Fon +49 151 14070811 --Apple-Mail=_C0197F23-99BB-4BEF-8520-862C4157CBBF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEJ+hF98o4r3eU/HiPD885WK4W4sEFAl6TT5sACgkQD885WK4W 4sEhiwgAvaR/tYHESTu5Evfj/3ZhhlELt6FelltJI6aFuHxHKK9LU7MnJza0iMxj qzXvKvf//oCNNZmd3BLQUkd/2b2XeOMGzVDnOVYss6UG08MgH0+KH8rkKlezkoR8 RU9v8bvkCqnr9g5OewDCSzIw2o85g6DKRsZ3KGhD9lHtQAMEjHZ1t1l8dilX3o5K hEJCetMkZp0HSV3svB7iLz2yl/LP0qbTpanAx3EsL1VdaSgRWV92/XlBI1RMJCeL 0hW52FpgIK/xcGYYPYZQ0bANjT3HUlK42DRJVoBEtg+eOixCJstvaRidjZxhPA5k k/UAC5HbOcfqf57yv2hyeo84wMVklQ== =Sh9s -----END PGP SIGNATURE----- --Apple-Mail=_C0197F23-99BB-4BEF-8520-862C4157CBBF-- From owner-freebsd-stable@freebsd.org Sun Apr 12 17:30:30 2020 Return-Path: Delivered-To: freebsd-stable@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 98EB92C3E93 for ; Sun, 12 Apr 2020 17:30:30 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 490f0P5T9Gz4Pw8 for ; Sun, 12 Apr 2020 17:30:29 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1jNgR9-0009iP-Um; Sun, 12 Apr 2020 20:30:27 +0300 Date: Sun, 12 Apr 2020 20:30:27 +0300 From: Slawa Olhovchenkov To: Stefan Bethke Cc: freebsd-stable Subject: Re: make kernel ignore broken SATA disk Message-ID: <20200412173027.GK8012@zxy.spb.ru> References: <20200412154319.GO8028@zxy.spb.ru> <9D60946A-6D81-444B-B6D0-36202B3BE5C6@lassitu.de> <20200412163104.GI8012@zxy.spb.ru> <20200412170338.GJ8012@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-Rspamd-Queue-Id: 490f0P5T9Gz4Pw8 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of slw@zxy.spb.ru has no SPF policy when checking 195.70.199.98) smtp.mailfrom=slw@zxy.spb.ru X-Spamd-Result: default: False [0.59 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.16)[-0.161,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.23)[-0.227,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[zxy.spb.ru]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5495, ipnet:195.70.192.0/19, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.08)[asn: 5495(0.37), country: RU(0.01)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 17:30:30 -0000 On Sun, Apr 12, 2020 at 07:08:06PM +0200, Stefan Bethke wrote: > Am 12.04.2020 um 19:03 schrieb Slawa Olhovchenkov : > > > > On Sun, Apr 12, 2020 at 06:38:10PM +0200, Stefan Bethke wrote: > > > >> > >> > >>> Am 12.04.2020 um 18:31 schrieb Slawa Olhovchenkov : > >>> > >>> On Sun, Apr 12, 2020 at 06:24:09PM +0200, Stefan Bethke wrote: > >>> > >>>> Am 12.04.2020 um 17:43 schrieb Slawa Olhovchenkov : > >>>>> > >>>>> On Sun, Apr 12, 2020 at 04:37:06PM +0200, Stefan Bethke wrote: > >>>>> > >>>>>> I have a server I don't have physical access to right now, which has a broken SATA disk that produces mostly errors (but not entirely). > >>>>>> > >>>>>> The disk has two partitions that are part of a zpool each. I can't bring the system up with this disk being online, because ZFS is trying its darndest to use it. > >>>>>> > >>>>>> I already renamed the GPT partitions in the hope that ZFS would not find them anymore, but it does. > >>>>>> > >>>>>> I can't gpart destroy -f ada1 because "device busy". > >>>>>> > >>>>>> Is there a way, ideally in the loader, to tell the kernel to ignore ada1 and/or ahcich5? Or can I force ZFS some other way to ignore the disk? I do have a spare disk I can use to replace the failed one, but I can't get the machine into a state where I could even issue the zpool replace command. > >>>>> > >>>>> `zpool offline pool device` if you have enoght redundancy? > >>>> > >>>> I do, but the command doesn't return. Instead, I'm getting loads of sata error message. > >>> > >>> What you zpool configuration? > >> > >> This is from the working system. The identifiers are slightly different, but the structure is identical. > > > > what about `zpool detach ` ? > > Now I can't boot into single user mode anymore, ZFS just waits forever, and the kernel is printing an endless chain of SATA error messages. > > I really need a way to remove the broken disk before ZFS tries to access it, or a way to stop ZFS from try to access the disk. This disk only part of mirror? ZIL is OK? From owner-freebsd-stable@freebsd.org Sun Apr 12 18:00:08 2020 Return-Path: Delivered-To: freebsd-stable@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 BE3592C47B1 for ; Sun, 12 Apr 2020 18:00:08 +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 490ffc07pLz4RC0 for ; Sun, 12 Apr 2020 18:00:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72d.google.com with SMTP id l25so7460088qkk.3 for ; Sun, 12 Apr 2020 11:00:07 -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=FRi9Zt/u7WwqyDeWAUEQ5Fb0yfGV/b7z+ZQnEE7Vreg=; b=MJhsyZSkBwFiqFSrIYxPYb8h0hWvirrjyPUcG4dJYf3ljRPRQLNvzuRMRlzvtoLNBZ szvCAezfxNXdxlbLDtyDR67zVJ5/yvVw6wG2gjOmvTRU9P80SezNQ2xCaxg6FMPdrV2C Cpknwy2JvfrmXaZzgF+bnVLjwoknQ/C6n1JcNeBAUbAq1vQWlhvBbneNgGT3GLtIth4D 5n7S3XHYLwRd5pQDeKVH9GOdNYh9IpAc9RrzoFvaLO6zMK3K24jNvznSZsx4PJI7cy7L zMP9kNZnR8aOrEjUZ8Yl38FUQMu8RHjHXy8bXEDacT1bGuMr3JJGnke+KeTt/QyRlsEr zNYQ== 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=FRi9Zt/u7WwqyDeWAUEQ5Fb0yfGV/b7z+ZQnEE7Vreg=; b=bqWP+8geiorF7n7u0AUjXHepF3hzT4Ukj2M8maRQrqfCjX0+2qjCeuwQmA28yNR3q2 BuEdVdiKDwyAG0jlkcUkfPDgyNahh35Zpfbu+n0CC0PRdKD1UYaKOH07G/iUcLxL4Iym p6SIXrZsqki/ZF3hJyaOSY8TZJv80PpsoKty5EfUPZezhWj895MVUQzgUwcifwA+166m ouox6r5urpV06iUb1WTpEI+1l/sv/0B4MSqafzEkJdUrakD8nV8vIZRp/MnAZOSk90ne NDgJ26Fl9WwaBzwdJQyiGL62DyoTubjYnmce7tjrmi006dlMYIr2XWkaZ9BQObAR0uOc jORg== X-Gm-Message-State: AGi0PuYNk8h7Fj2pH+IF12fwoTvmXvNpZfsMjF5UcFMhc+PMzRa7p3KT dKQAjL7gCGQ5uRSRoMyvjD/ts8dspb8QlsWRplzM9g== X-Google-Smtp-Source: APiQypLs/OTDUnt1VBYKnoqNGNVHsvGPReWjjcZcEGl+TnIw1t5TArrMD4U0g/3dhQtEfVIX+X1pwt0T3d5xUwilId4= X-Received: by 2002:a37:5a02:: with SMTP id o2mr12964715qkb.380.1586714406792; Sun, 12 Apr 2020 11:00:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sun, 12 Apr 2020 11:59:55 -0600 Message-ID: Subject: Re: make kernel ignore broken SATA disk To: Stefan Bethke Cc: freebsd-stable X-Rspamd-Queue-Id: 490ffc07pLz4RC0 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=MJhsyZSk; 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.01 / 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)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[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.01)[ip: (-9.22), 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" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 18:00:08 -0000 Boot single user. Zfs won't import and you can do what you need. Warner On Sun, Apr 12, 2020, 8:37 AM Stefan Bethke wrote: > I have a server I don't have physical access to right now, which has a > broken SATA disk that produces mostly errors (but not entirely). > > The disk has two partitions that are part of a zpool each. I can't bring > the system up with this disk being online, because ZFS is trying its > darndest to use it. > > I already renamed the GPT partitions in the hope that ZFS would not find > them anymore, but it does. > > I can't gpart destroy -f ada1 because "device busy". > > Is there a way, ideally in the loader, to tell the kernel to ignore ada1 > and/or ahcich5? Or can I force ZFS some other way to ignore the disk? I do > have a spare disk I can use to replace the failed one, but I can't get the > machine into a state where I could even issue the zpool replace command. > > > Stefan > > -- > Stefan Bethke Fon +49 151 14070811 > > From owner-freebsd-stable@freebsd.org Sun Apr 12 18:44:26 2020 Return-Path: Delivered-To: freebsd-stable@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 D3F492C5785 for ; Sun, 12 Apr 2020 18:44:26 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 490gdk4hbKz4Tlw for ; Sun, 12 Apr 2020 18:44:26 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 03CIiqJU074142 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 12 Apr 2020 11:44:59 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: freebsd-stable In-Reply-To: From: Chris Reply-To: bsd-lists@BSDforge.com To: Stefan Bethke Subject: Re: make kernel ignore broken SATA disk Date: Sun, 12 Apr 2020 11:44:58 -0700 Message-Id: <07a08db448daa9dd32b187330666f852@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 490gdk4hbKz4Tlw X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.72 / 15.00]; NEURAL_HAM_MEDIUM(-0.79)[-0.795,0]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81]; NEURAL_HAM_LONG(-0.93)[-0.930,0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 18:44:26 -0000 On Sun, 12 Apr 2020 16:37:06 +0200 Stefan Bethke stb@lassitu=2Ede said > I have a server I don't have physical access to right now, which has a br= oken > SATA disk that produces mostly errors (but not entirely)=2E >=20 > The disk has two partitions that are part of a zpool each=2E I can't bring = the > system up with this disk being online, because ZFS is trying its darndest= to > use it=2E >=20 > I already renamed the GPT partitions in the hope that ZFS would not find = them > anymore, but it does=2E >=20 > I can't gpart destroy -f ada1 because "device busy"=2E FTR it's gpart destroy -F (note the case difference) :-) >=20 > Is there a way, ideally in the loader, to tell the kernel to ignore ada1 > and/or ahcich5? Or can I force ZFS some other way to ignore the disk? I d= o > have a spare disk I can use to replace the failed one, but I can't get th= e > machine into a state where I could even issue the zpool replace command=2E >=20 >=20 > Stefan >=20 --Chris From owner-freebsd-stable@freebsd.org Sun Apr 12 19:01:36 2020 Return-Path: Delivered-To: freebsd-stable@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 0D1042C5D4C for ; Sun, 12 Apr 2020 19:01:36 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2a00:14b0:4200:32e0::1ea]) (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 "gilb.zs64.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 490h1V6XDKz4VVx for ; Sun, 12 Apr 2020 19:01:34 +0000 (UTC) (envelope-from stb@lassitu.de) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 069A3208ECD; Sun, 12 Apr 2020 19:01:30 +0000 (UTC) From: Stefan Bethke Message-Id: <69AA1579-DB09-40C1-A90B-CE17BA0B77DB@lassitu.de> Content-Type: multipart/signed; boundary="Apple-Mail=_F22195E7-FA22-4209-B365-938475450916"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: make kernel ignore broken SATA disk Date: Sun, 12 Apr 2020 21:01:30 +0200 In-Reply-To: Cc: freebsd-stable To: Warner Losh References: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 490h1V6XDKz4VVx X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of stb@lassitu.de designates 2a00:14b0:4200:32e0::1ea as permitted sender) smtp.mailfrom=stb@lassitu.de X-Spamd-Result: default: False [-5.96 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MV_CASE(0.50)[]; HAS_ATTACHMENT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; DMARC_NA(0.00)[lassitu.de]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; SIGNED_PGP(-2.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; ASN(0.00)[asn:13135, ipnet:2a00:14b0::/32, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-2.06)[ip: (-5.47), ipnet: 2a00:14b0::/32(-2.57), asn: 13135(-2.22), country: DE(-0.02)] X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 19:01:36 -0000 --Apple-Mail=_F22195E7-FA22-4209-B365-938475450916 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Am 12.04.2020 um 19:59 schrieb Warner Losh : > > Boot single user. Zfs won't import and you can do what you need. Not if you have root on ZFS, and it's on the affected pool. Stefan -- Stefan Bethke Fon +49 151 14070811 --Apple-Mail=_F22195E7-FA22-4209-B365-938475450916 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEJ+hF98o4r3eU/HiPD885WK4W4sEFAl6TZYoACgkQD885WK4W 4sExFgf/Z88GuMKuslxXt6I90kR8QD3k514Mtcfq8vEIVg+/NTO/aEW2r62/hi/E CYZpWbmBo81U7sPEEdeayNzn5GQcxXOkHvHHIZdLo4RRqv/vs1/nNAbDBTh2F+yn Tws9e07NMcuw7tde8qfyB07in+XOgHNn56w5VD0vYkRggx+Ig524P/+qA3r09Njh lesaaEuqZxbEOcSaiQ1Mp2F01ZEST+hhSG6OY+x0ZL7puDPYdZ9QuPmYqqHzZt9p U3Ta3EhBUSA7xCFiassYWSloJlOj6jrElEYHfzazyl8eUnV0ZSoPCQ182nobXcKQ 9II4uxuwwH13dB9eU8h320iCe2w9+Q== =0l/t -----END PGP SIGNATURE----- --Apple-Mail=_F22195E7-FA22-4209-B365-938475450916-- From owner-freebsd-stable@freebsd.org Sun Apr 12 19:02:25 2020 Return-Path: Delivered-To: freebsd-stable@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 D03832C5E74 for ; Sun, 12 Apr 2020 19:02:25 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [212.12.50.234]) (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 "gilb.zs64.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 490h2S6dndz4VhF for ; Sun, 12 Apr 2020 19:02:24 +0000 (UTC) (envelope-from stb@lassitu.de) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 788BB209121; Sun, 12 Apr 2020 19:02:22 +0000 (UTC) From: Stefan Bethke Message-Id: <0A3D11B8-23ED-4435-80D6-904E29F119F4@lassitu.de> Content-Type: multipart/signed; boundary="Apple-Mail=_1AFC4AC2-7AC7-4F1A-9D00-A6B59F9CC495"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: make kernel ignore broken SATA disk Date: Sun, 12 Apr 2020 21:02:22 +0200 In-Reply-To: <07a08db448daa9dd32b187330666f852@udns.ultimatedns.net> Cc: freebsd-stable To: "bsd-lists@bsdforge.com" References: <07a08db448daa9dd32b187330666f852@udns.ultimatedns.net> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 490h2S6dndz4VhF X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of stb@lassitu.de designates 212.12.50.234 as permitted sender) smtp.mailfrom=stb@lassitu.de X-Spamd-Result: default: False [-6.90 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; MV_CASE(0.50)[]; HAS_ATTACHMENT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; DMARC_NA(0.00)[lassitu.de]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[234.50.12.212.list.dnswl.org : 127.0.10.0]; SIGNED_PGP(-2.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; ASN(0.00)[asn:13135, ipnet:212.12.48.0/21, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-3.00)[ip: (-8.44), ipnet: 212.12.48.0/21(-4.22), asn: 13135(-2.33), country: DE(-0.02)] X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 19:02:25 -0000 --Apple-Mail=_1AFC4AC2-7AC7-4F1A-9D00-A6B59F9CC495 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Am 12.04.2020 um 20:44 schrieb Chris : >=20 > On Sun, 12 Apr 2020 16:37:06 +0200 Stefan Bethke stb@lassitu.de said >=20 >> I have a server I don't have physical access to right now, which has = a broken >> SATA disk that produces mostly errors (but not entirely). >> The disk has two partitions that are part of a zpool each. I can't = bring the >> system up with this disk being online, because ZFS is trying its = darndest to >> use it. >> I already renamed the GPT partitions in the hope that ZFS would not = find them >> anymore, but it does. >> I can't gpart destroy -f ada1 because "device busy". > FTR it's gpart destroy -F (note the case difference) :-) Sorry, that was a typo in the transcription. Even when using -F, it = won't delete the table. Stefan -- Stefan Bethke Fon +49 151 14070811 --Apple-Mail=_1AFC4AC2-7AC7-4F1A-9D00-A6B59F9CC495 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEJ+hF98o4r3eU/HiPD885WK4W4sEFAl6TZb4ACgkQD885WK4W 4sGW7gf9F6hvtr5YIX8JEzr5XFMaL//uN6GLVQtDCZjBTAtt3uQY78w8OG123ZaW YmmcbDUyN2i/uZTsjIwq1OTErkLRN+exR6ERcLEj9OFSS8YzD6P3LwXiBt3oFv75 Dd7dvJzEdKSeZcPtP6cMiuDplcFOecklnFEjsxcb3U8PCF80LnJVRxXk+voDKPe5 DsfVDiMBfD8P/0UbpY1+Br2+IcUZMIhyn2MGOxIyvhAHU5TMsuPzbiGl0EhVFBOf RaBpGp/YV0pF44qwl/rCzcj2+FLNwBy9xC02lrDGs8zTEYFy3eM1QRJqoDuptmBA tJEsIsw9myfWQ4XMgbVvEyDyqaXa0Q== =WO/B -----END PGP SIGNATURE----- --Apple-Mail=_1AFC4AC2-7AC7-4F1A-9D00-A6B59F9CC495-- From owner-freebsd-stable@freebsd.org Sun Apr 12 20:14:12 2020 Return-Path: Delivered-To: freebsd-stable@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 C52152C79EF for ; Sun, 12 Apr 2020 20:14:12 +0000 (UTC) (envelope-from oscar@prutt.party) Received: from ester.prutt.party (ester.prutt.party [95.216.168.48]) (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 "ester.prutt.party", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 490jdH1Vwtz4bJQ for ; Sun, 12 Apr 2020 20:14:10 +0000 (UTC) (envelope-from oscar@prutt.party) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 506E73EF7E for ; Sun, 12 Apr 2020 22:14:05 +0200 (CEST) References: <20200412154319.GO8028@zxy.spb.ru> <9D60946A-6D81-444B-B6D0-36202B3BE5C6@lassitu.de> <20200412163104.GI8012@zxy.spb.ru> <20200412170338.GJ8012@zxy.spb.ru> <0f414436-9e4d-d290-bb4b-d590ef67af70@multiplay.co.uk> User-agent: mu4e 1.3.3; emacs 26.3 From: Oscar Carlsson To: freebsd-stable@freebsd.org Subject: Re: make kernel ignore broken SATA disk In-reply-to: <0f414436-9e4d-d290-bb4b-d590ef67af70@multiplay.co.uk> Date: Sun, 12 Apr 2020 22:13:58 +0200 Message-ID: <87zhbgzcl5.fsf@prutt.party> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Last-TLS-Session-Version: TLSv1.3 X-Rspamd-Queue-Id: 490jdH1Vwtz4bJQ X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.03 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[prutt.party:s=mail]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:95.216.168.48]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; DKIM_TRACE(0.00)[prutt.party:+]; DMARC_POLICY_ALLOW(-0.50)[prutt.party,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-0.04)[ipnet: 95.216.0.0/16(1.42), asn: 24940(-1.58), country: DE(-0.02)]; ASN(0.00)[asn:24940, ipnet:95.216.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 20:14:12 -0000 Steven Hartland writes: > Might be a silly suggestion but unplug it? Quoting the first message: > I have a server I don't have physical access to right now, which > has a > broken SATA disk that produces mostly errors (but not entirely). :( Oscar From owner-freebsd-stable@freebsd.org Sun Apr 12 22:05:48 2020 Return-Path: Delivered-To: freebsd-stable@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 916A12AB11B; Sun, 12 Apr 2020 22:05:48 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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 "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 490m6437Lgz3GD4; Sun, 12 Apr 2020 22:05:48 +0000 (UTC) (envelope-from salvadore@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1472) id 61957D411; Sun, 12 Apr 2020 22:05:48 +0000 (UTC) To: freebsd-hackers@FreeBSD.org Subject: FreeBSD Quarterly Status Report - First Quarter 2020 Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Message-Id: <20200412220548.61957D411@freefall.freebsd.org> Date: Sun, 12 Apr 2020 22:05:48 +0000 (UTC) From: Lorenzo Salvadore X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2020 22:05:48 -0000 FreeBSD Project Quarterly Status Report - First Quarter 2020 Introduction Welcome, to the quarterly reports, of the future! Well, at least the first quarterly report from 2020. The new timeline, mentioned in the last few reports, still holds, which brings us to this report, which covers the period of January 2020 - March 2020. As you will see from this report, we've had quite an active quarter with big changes to both kernel, userland, documentation, ports, and third-party projects in the form of everything from bug and security fixes over new features to speed improvements and optimizations. As this report also covers the start of the epidemic, it's also interesting to note that a quick glance at the svn logs reveal that there has been no overall drop in number of source commits, that docs commits have also stayed constant, and that ports have seen an upwards trend. We hope that all of you are and yours are as safe as can be managed, and that we get through this together by working together. -- Daniel Ebdrup Jensen, debdrup@freebsd.org __________________________________________________________________ FreeBSD Team Reports * FreeBSD Foundation * FreeBSD Core Team * FreeBSD Release Engineering Team * Cluster Administration Team * Continuous Integration * Ports Collection * FreeBSD Graphics Team status report Projects * NFS over TLS implementation * Import of the Kyua test framework * Linux compatibility layer update * syzkaller on FreeBSD Kernel * if_bridge * sigfastblock(2) * arm64 LSE atomic instructions * FreeBSD on Microsoft HyperV and Azure * FreeBSD on the ARM Morello platform * NXP ARM64 SoC support * ENA FreeBSD Driver Update Architectures * FreeBSD/powerpc Project * FreeBSD/RISC-V Project Userland Programs * GCC 4.2.1 Retirement * elfctl utility * ELF Tool Chain Ports * KDE on FreeBSD * XFCE * Wine on FreeBSD * Go on freebsd/arm64 * sysctlmibinfo2 API Documentation * FreeBSD Translations on Weblate * FreeBSD Manpages overhaul Third-Party Projects * pot and the nomad pot driver * NomadBSD __________________________________________________________________ FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. FreeBSD Foundation Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Funding comes from individual and corporate donations and is used to fund and manage software development projects, conferences and developer summits, and provide travel grants to FreeBSD contributors. The Foundation purchases and supports hardware to improve and maintain FreeBSD infrastructure and provides resources to improve security, quality assurance, and release engineering efforts; publishes marketing material to promote, educate, and advocate for the FreeBSD Project; facilitates collaboration between commercial vendors and FreeBSD developers; and finally, represents the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. Here are some highlights of what we did to help FreeBSD last quarter: General We moved! Our new address is: The FreeBSD Foundation 3980 Broadway St. STE #103-107 Boulder, CO 80304 USA In February, the board of directors had an all-day board meeting in Berkely, CA, where FreeBSD began! We put together our strategic plans for the next 2 years, which includes software developments projects we want to support and some educational initiatives. COVID-19 impacts the Foundation. We put policies in place for all of our staff members to work from home. We also put a temporary ban on travel for staff members. We are continuing our work supporting the community and Project, but some of our work and responses are delayed because of changes in some of our priorities and the impact of limited childcare for a few of our staff members. Partnerships and Commercial User Support We help facilitate collaboration between commercial users and FreeBSD developers. We also meet with companies to discuss their needs and bring that information back to the Project. In Q1, Deb Goodkin met with commercial users at LinuxConfAu in Australia, FOSDEM in Belgium, and SCALE18x in the US. These venues provide an excellent opportunity to meet with commercial and individual users and contributors to FreeBSD. It's not only beneficial for the above, but it also helps us understand some of the applications where FreeBSD is used. In addition to meeting with commercial users at conferences, we continued discussions over email or on calls over the quarter. Fundraising Efforts Last quarter we raised $57,000! Thank you to everyone who came through, especially in this economic crisis we have found ourselves in. It heartens us deeply that individuals and organizations have supported our efforts, when there are so many people, animals, and businesses in need right now. We also want to extend a big thank you to Tarsnap, VMWare, and Stormshield for leading the way with Silver level donations. We hope other organizations will follow their lead and give back to help us continue supporting FreeBSD. We are 100% funded by donations, and those funds go towards software development work to improve FreeBSD, FreeBSD advocacy around the world, keeping FreeBSD secure, continuous integration improvements, sponsoring BSD-related and computing conferences, legal support for the Project, and many other areas. Please consider making a donation to help us continue and increase our support for FreeBSD: https://www.FreeBSDfoundation.org/donate/. We also have the Partnership Program, to provide more benefits for our larger commercial donors. Find out more information at https://www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/ and share with your companies! OS Improvements The Foundation supports software development projects to improve the FreeBSD operating system through our full time technical staff, contractors, and project grant recipients. They maintain and improve critical kernel subsystems, add new features and functionality, and fix problems. Over the last quarter there were 273 commits to the FreeBSD base system source repository tagged with FreeBSD Foundation sponsorship, about 12% of base system commits over the quarter. Many of these are part of sponsored or staff projects that have their own entries in this FreeBSD Quarterly Report, but Foundation staff and contractors (Ed Maste, Konstantin Belousov, Mark Johnston, Li-Wen Hsu) also support the project with an ongoing series of bug fixes, build fixes, and miscellaneous improvements that don't warrant a separate entry. Ed committed miscellaneous improvements to various parts of FreeBSD's build infrastructure, largely prompted by the work to retire the obsolete GCC 4.2.1. This included removal of the LLVM_LIBUNWIND option (now always set), and the removal of unused gperf, gcov, and the GPL devicetree compiler (dtc). Ed committed sendfile support for the Linuxulator, submitted by previous intern Bora Özarslan, and tested and committed a number of submitted bug fixes for the Microchip USB-Ethernet controller if_muge driver. Ed also updated the copy of OpenSSH in the base system to 7.9p1, with additional updates in progress, and worked on a number of security advisories released during the quarter. Konstantin Belousov and Mark Johnston both performed a large number of code reviews during the quarter under Foundation sponsorship. This work helps developers in the FreeBSD community and those working at companies using FreeBSD to integrate their work into FreeBSD. In addition to work described elsewhere in this report Konstantin also continued his usual series of bug fixes and improvements. This quarter this included low-level x86 support, fixing sendfile bugs, file system and vfs bug fixes, and dozens of other miscellaneous improvements. Additional work included a variety of commits to support Hygon x86 CPUs and improvements to the runtime linker (rtld)'s direct execution mode. Mark Johnston continued his work on the Syzkaller system-call fuzzer, and committed fixes for many issues reported by Syzkaller. Mark triaged a large number of submitted bug reports and in many cases committed attached patches or developed fixes. Mark also addressed dozens of Coverity Scan reports. Mark's other changes included arm64 Large System Extensions (LSE) atomic operations, low-level arm64 and x86 work, virtual memory (VM) work, and bug fixes or other improvements to syslog, the lagg(4) link aggregation driver, and build reproducibility. Li-Wen Hsu committed many changes to tests in the base system, such as turning off known failing tests tracked by PRs, test-related pkgbase fixes, and other improvements. Continuous Integration and Quality Assurance The Foundation provides a full-time staff member who is working on improving our automated testing, continuous integration, and overall quality assurance efforts. During the first quarter of 2020, Foundation staff continued to improve the Project's CI infrastructure, worked with contributors to fix the failing build and test cases. The building of a CI staging environment is in progress on the new machine purchased by the Foundation. We are also working with other teams in the Project for their testing needs. For example, we added a new job for running LTP (Linux Testing Project) on the Linuxulator, to validate improvements in the Foundation's sponsored Linux emulation work. We are also working with many external projects and companies to improve their support of FreeBSD. See the FreeBSD CI section of this report for completed work items and detailed information. Supporting FreeBSD Infrastructure The Foundation provides hardware and support to improve the FreeBSD infrastructure. Last quarter, we continued supporting FreeBSD hardware located around the world. We purchased one server for a mirror in Malaysia, and signed the MOU for the new NYI colocation facility in Illinois. NYI generously provides this as an in-kind donation to the Project. FreeBSD Advocacy and Education A large part of our efforts are dedicated to advocating for the Project. This includes promoting work being done by others with FreeBSD; producing advocacy literature to teach people about FreeBSD and help make the path to starting using FreeBSD or contributing to the Project easier; and attending and getting other FreeBSD contributors to volunteer to run FreeBSD events, staff FreeBSD tables, and give FreeBSD presentations. The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology events geared towards underrepresented groups. We support the FreeBSD-focused events to help provide a venue for sharing knowledge, to work together on projects, and to facilitate collaboration between developers and commercial users. This all helps provide a healthy ecosystem. We support the non-FreeBSD events to promote and raise awareness of FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project. Check out some of the advocacy and education work we did last quarter: * Organized and presented at the first ever FreeBSD Mini-Conf LinuxConfAu 2020, in Gold Coast, Australia in addition to sponsoring the conference itself. The recap can be found here. * Presented BSD Dev Room at FOSDEM '20, in Brussels, Belgium and represented FreeBSD at a stand along with other members of the community. Find out more here: https://www.freebsdfoundation.org/blog/fosdem-2020-conference-recap/ * Represented FreeBSD at Apricot 2020 in Melbourne, Australia and sponsored the event. * Industry Partner Sponsor for USENIX FAST '20 in Santa Clara, CA * Sponsored FOSSASIA 2020, in Singapore * Committed to hold FreeBSD Day at SCALE 18x, in Pasadena, CA * Held a "Getting Started with FreeBSD Workshop" at SCALE 18x in addition to giving a talk, representing FreeBSD at the Expo and holding a "Why FreeBSD is Me" BoF. Check out the conference recap. We continued producing FreeBSD advocacy material to help people promote FreeBSD. Learn more about our efforts in 2019 to advocate for FreeBSD. In addition to the information found in the Development Projects update section of this report, take a minute to check out the latest update blogs: * POWER to the People: Making FreeBSD a First Class Citizen on POWER. * Development Project Update: Toolchain Modernization. Read more about our conference adventures in the conference recaps and trip reports in our monthly newsletters. We help educate the world about FreeBSD by publishing the professionally produced FreeBSD Journal. As we mentioned previously, the FreeBSD Journal is now a free publication. Find out more and access the latest issues. You can find out more about events we attended and upcoming events here. As is the case for most of us in this industry, SCALE was the last event we will be attending for a few months. However, we're already working on how we can make more on-line tutorials and how-to guides available to facilitate getting more folks to try out FreeBSD. In the meantime, please check out the how-to guides we already have available! We have continued our work with a new website developer to help us improve our website. Work has begun to make it easier for community members to find information more easily and to make the site more efficient. Legal/FreeBSD IP The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise. Go to http://www.FreeBSDfoundation.org/ to find out how we support FreeBSD and how we can help you! __________________________________________________________________ FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team is the governing body of FreeBSD. * Core approved a source commit bit for Alfredo Dal'Ava Júnior. Alfredo has been working on powerpc64 support. Justin Hibbits (jhibbits) will mentor Alfredo. * Core approved a source commit bit for Ryan Moeller. Ryan has been working on porting ZoL to FreeBSD. Alexander Motin (mav) and Matt Macy (mmacy) will mentor Ryan. * Core approved a source commit bit for Nick O'Brien. Nick has been working on RISC-V at Axiado. Kristof Provost (kp) and Philip Paeps (philip) will mentor Nick. * Core approved a source commit bit for Richard Scheffenegger. Richard has been contributing TCP work. Michael Tuexen (tuexen) will mentor Richard and Rodney Grimes (rgrimes) will act as co-mentor. * Core approved a source commit bit for Aleksandr Fedorov. Aleksandr has been testing and reviewing bhyve networking code. Vincenzo Maffione (vmaffione) will mentor Aleksandr and John Baldwin (jhb) will act as co-mentor. * Core requested that the freebsd-mobile@ list be retired as it was almost exclusively receiving spam. postmaster@ completed core's request. * Core approved third party authentication for some project services with certain conditions. For example, for authentication with Google, users must be using a FreeBSD.org account with two-factor authentication enabled. For GitHub, we will enable and force multi-factor authentication for our organization. * The Core-initiated Git Transition Working Group continued to meet over the first quarter of 2020. Their report is still forthcoming. __________________________________________________________________ FreeBSD Release Engineering Team Links FreeBSD 11.4-RELEASE schedule URL: https://www.freebsd.org/releases/11.4R/schedule.html FreeBSD 12.2-RELEASE schedule URL: https://www.freebsd.org/releases/12.2R/schedule.html FreeBSD development snapshots URL: https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things. The FreeBSD Release Engineering Team published the schedules for the upcoming 11.4-RELEASE and 12.2-RELEASE cycles. Much time was spent by Glen Barber working on updates to the various build tools adding support for builds from both Subversion and Git. This is very much a work in progress, as there are a number of inter-connected moving parts. Additionally throughout the quarter, several development snapshots builds were released for the head, stable/12, and stable/11 branches. Much of this work was sponsored by Rubicon Communications, LLC (netgate.com) and the FreeBSD Foundation. __________________________________________________________________ Cluster Administration Team Links Cluster Administration Team members URL: https://www.freebsd.org/administration.html#t-clusteradm Contact: Cluster Administration Team The FreeBSD Cluster Administration Team consists of the people responsible for administering the machines that the Project relies on for its distributed work and communications to be synchronised. In this quarter, the team has worked on the following: * Upgrade all ref- and universe- machines * South Africa mirror (JINX) is online * Package service of Seattle, USA mirror (TUK) is online * Ongoing systems administration work: + Creating accounts for new committers. + Backups of critical infrastructure. + Keeping up with security updates in 3rd party software. Work in progress: * Setup Malaysia (KUL) mirror * Setup Brazil (BRA) mirror * Setup Amsterdam (PKT) mirror * Review the service jails and service administrators operation. * Infrastructure of building aarch64 and powerpc64 packages + NVME issues on PowerPC64 Power9 blocking dual socket machine from being used as pkg builder. + Drive upgrade test for pkg builders (SSDs) courtesy of the FreeBSD Foundation. + Boot issues with Aarch64 reference machines. * New NYI.net sponsored colocation space in Chicago-land area. * Prepare resource for git working group * Searching for more mirror providers + https://wiki.freebsd.org/Teams/clusteradm/generic-mirror-layout + https://wiki.freebsd.org/Teams/clusteradm/tiny-mirror __________________________________________________________________ Continuous Integration Links FreeBSD Jenkins Instance URL: https://ci.FreeBSD.org FreeBSD Hardware Testing Lab URL: https://ci.FreeBSD.org/hwlab FreeBSD CI artifact archive URL: https://artifact.ci.FreeBSD.org FreeBSD CI weekly report URL: https://hackmd.io/@FreeBSD-CI FreeBSD Jenkins wiki URL: https://wiki.freebsd.org/Jenkins Hosted CI wiki URL: https://wiki.freebsd.org/HostedCI 3rd Party Software CI URL: https://wiki.freebsd.org/3rdPartySoftwareCI Tickets related to freebsd-testing@ URL: https://preview.tinyurl.com/y9maauwg FreeBSD CI Repository URL: https://github.com/freebsd/freebsd-ci Contact: Jenkins Admin Contact: Li-Wen Hsu Contact: freebsd-testing Mailing List Contact: IRC #freebsd-ci channel on EFNet The FreeBSD CI team maintains the continuous integration system and related tasks for the FreeBSD project. The CI system regularly checks the committed changes can be successfully built, then performs various tests and analysis of the results. The artifacts from the build jobs are archived in the artifact server for further testing and debugging needs. The CI team members examine the failing builds and unstable tests and work with the experts in that area to fix the codes or adjust test infrastructure. The details of these efforts are available in the weekly CI reports. During the first quarter of 2020, we continue working with the contributors and developers in the project for their testing needs and also keep working with external projects and companies to improve their support of FreeBSD. Important changes: * All the -head jobs are using clang/lld toolchain * All the -head test are using kyua in the base * RISC-V jobs now generate full disk image and run tests in QEMU with OpenSBI * freebsd-doc job also checks building of www.freebsd.org New jobs added: * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_ltp/ * https://ci.freebsd.org/job/FreeBSD-head-powerpc64-images/ * https://ci.freebsd.org/job/FreeBSD-head-powerpc64-testvm/ Work in progress: * Collecting and sorting CI tasks and ideas here * Setup the CI stage environment and put the experimental jobs on it * Implementing automatic tests on bare metal hardware * Adding drm ports building test against -CURRENT * Testing and merging pull requests in the FreeBSD-ci repo * Planning for running ztest and network stack tests * Helping more 3rd software get CI on FreeBSD through a hosted CI solution * Adding non-x86 test jobs. * Adding external toolchain related jobs. * Adding more hardware to the hardware lab Please see freebsd-testing@ related tickets for more WIP information, and join the efforts Sponsor: The FreeBSD Foundation __________________________________________________________________ Ports Collection Links About FreeBSD Ports URL: https://www.FreeBSD.org/ports/ Contributing to Ports URL: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/ports-contributing.html FreeBSD Ports Monitoring URL: http://portsmon.freebsd.org/index.html Ports Management Team URL: https://www.freebsd.org/portmgr/index.html Contact: René Ladan Contact: FreeBSD Ports Management Team The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages, and personnel matters. Below is what happened in the last quarter. During the last quarter the number of ports settled in at 39,000. There are currently just over 2,400 open PRs of which 640 are unassigned. The last quarter saw 8146 commits by 173 committers to the HEAD branch and 357 commits by 52 committers to the 2020Q1 branch. This means the number of PRs grew although the committer activity remained more or less constant. As always, people come and go. This time we welcomed Loïc Bartoletti (lbartoletti@), Mikael Urankar (mikael@), Kyle Evans (kevans@, who is already a src committer), and Lorenzo Salvadore (salvadore@, who we already know for compiling these reports you are reading right now). We said goodbye to dbn@ and theraven@, who we hope to see back in the future. On the infrastructure side, USES=qca was added and USES=zope was removed. The latter was also due to it was incompatible with Python 3, and portmgr is in the process of removing Python 2.7 from the Ports Tree. This means that all ports that currently rely on Python 2.7 need to be updated to work with Python 3 or be removed. After a long period of work by multiple people, Xorg got updated from the 1.18 to the 1.20 release series. Also, the web browsers were updated: Firefox to version 75.0, Firefox ESR to 68.7.0, and Chromium to 80.0.3987.149. The package manager itself got updated to version 1.13.2. antoine@ ran 29 exp-runs during the last quarter for various updates to KDE, poppler, pkg and build tools; and test compatibility with src changes: removing procfs-based debugging, fixing TLS alignment, and only including libssp_nonshared.a in libc for the i386 and Power architectures. __________________________________________________________________ FreeBSD Graphics Team status report Links Project GitHub page URL: https://github.com/FreeBSDDesktop Contact: FreeBSD Graphics Team Contact: Niclas Zeising The FreeBSD X11/Graphics team maintains the lower levels of the FreeBSD graphics stack. This includes graphics drivers, graphics libraries such as the MESA OpenGL implementation, the X.org xserver with related libraries and applications, and Wayland with related libraries and applications. The biggest highlight by far during the previous quarter was the long awaited update of xorg-server to version 1.20. After years of work by many people, this update finally landed in the form of xorg-server 1.20.7. With this update came a couple of new things, most notably, FreeBSD 12 and later was switched to use the udev/evdev backend by default for handling input devices, such as mice and keyboards. Together with this release, the OpenGL library implementation mesa was switched to use DRI3 by default, instead of the older DRI2. These updates caused some fallout when they first were comitted, most notably issues with keyboards. But with help from Michael Gmelin and others on the mailing lists, most issues were sorted fast. Unfortunately version 304 of the nVidia graphics driver is no longer supported as of this release. Since this update, xorg-server has also been bumped to 1.20.8, which is the latest upstream release. Apart from this update, there has also been ongoing work to keep the various drm-kmod ports and packages up to date, mostly in response to changes in FreeBSD CURRENT and to security issues found in the Intel i915 driver. We have also done updates as needed to keep the graphics and input stack up to date and working, and deprecated and removed several old and no longer used drivers, applications and libraries. We have also continued our regularly scheduled bi-weekly meetings. People who are interested in helping out can find us on the x11@FreeBSD.org mailing list, or on our gitter chat: (https://gitter.im/FreeBSDDesktop/Lobby). We are also available in #freebsd-xorg on EFNet. We also have a team area on GitHub where our work repositories can be found: https://github.com/FreeBSDDesktop __________________________________________________________________ Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. NFS over TLS implementation Contact: Rick Macklem In an effort to improve NFS security, an internet draft which I expect will become and RFC soon specifies the use of TLS 1.3 to encrypt all data traffic on a Sun RPC connection used for NFS. Although NFS has been able to use sec=krb5p to encrypt data on the wire, this requires a Kerberos environment and, as such, has not been widely adopted. It also required that encryption/decryption be done in software, since only the RPC message NFS arguments are encrypted. Since Kernel TLS is capable of using hardware assist to improve performance and does not require Kerberos, NFS over TLS may be more widely adopted, once implementations are available. Since FreeBSD's kernel TLS requires that data be in ext_pgs mbufs for transmission, most of the work so far has been modifying the NFS code that builds the protocol arguments to optionally use ext_pgs mbufs. Coding changes to handle received ext_pgs mbufs has also been done, although this may not be required by the receive kernel TLS. The kernel RPC has also been modified to do the STARTTLS Null RPC and to do upcalls to userland daemons that perform the SSL_connect()/SSL_accept(), since the kernel TLS does not do this initial handshake. So far only a self signed certificate on the server, with no requirement for the client to have a certificate has been implemented. Work is still needed to be done for the case where the NFS client is expected to have a signed certificate. In particular, it is not obvious to me what the correct solution is for clients that do not have a fixed IP address/DNS name. The code now is about ready for testing, but requires that the kernel TLS be able to support receive as well as transmit. Patches to the kernel TLS for receive are being worked on by jhb@freebsd.org. Once receive side kernel TLS becomes available, the code in subversion under base/projects/nfs-over-tls will need third party testing and a security evaluation by someone familiar with TLS. __________________________________________________________________ Import of the Kyua test framework Links The FreeBSD Test Suite URL: https://wiki.freebsd.org/TestSuite Contact: Brooks Davis The FreeBSD test suite uses the Kyua test framework to run tests. Historically Kyua has been installed from the ports collection (devel/kyua). While this is fine for mainstream architectures, it can pose bootstrapping issues on new architectures and package installation is quite slow under emulation or on FPGA based systems. By including it in the FreeBSD base system we can avoid these issues. We hope that this inclusion will spur testing of embedded platforms and simplify the process of testing within continuous integration systems. We currently plan to retain the devel/kyua port to serve FreeBSD versions without and to serve as a development version. Sponsor: DARPA __________________________________________________________________ Linux compatibility layer update Contact: Edward Tomasz Napierala Work during this quarter focused on source code cleanup and making it easier to debug missing functionality. There were, however, some user-visible changes: added support for TCP_CORK as required by Nginx, added support MAP_32BIT flag, which fixes Mono binaries from Ubuntu Bionic, and a fix for DNS resolution with glibc newer than 2.30, which affected CentOS 8. The Linux Test Project tests that are being run as part of the the FreeBSD Continuous Integration infrastructure now include the Open POSIX test suite. There's still a lot to do: * There are pending reviews for patches that add extended attributes support, and fexecve(2) syscall, and they require wrapping up and committing * There are over 400 failing LTP tests. Some of them are false positives, some are easy to fix bugs, and some require adding new system calls. Any help is welcome. Sponsor: The FreeBSD Foundation __________________________________________________________________ syzkaller on FreeBSD Contact: Mark Johnston Contact: Michael Tuexen See the syzkaller entry in the 2019q1 quarterly report for an introduction to syzkaller. A number of kernel bugs have been found by syzkaller and fixed this quarter, mostly in the network stack and file descriptor table code. Bug investigations have led to improvements in debugging facilities and assertions, for example in the SCTP stack. Syzkaller reproducers have been added to Peter Holm's stress2 suite, helping ensure that regressions are found quickly. The syzkaller instance hosted by backtrace.io (see the 2019q3 report) has been very useful in testing syzkaller improvements and finding bugs. Though Google runs a dedicated syzkaller instance targeting FreeBSD, it has proved fruitful to run multiple instances since they end up building different corpuses and thus discover different, though overlapping, sets of bugs. Support for fuzzing a number of new system calls has been added, including the new copy_file_range() and __realpathat() system calls, and the Capsicum system calls. Some work was also done to audit existing system call definitions to ensure that FreeBSD-specific extensions of POSIX system calls are covered. Work is ongoing to target the Linux emulation layer, and to collect kernel dumps so that one-off crashes with no reproducer have a chance at being diagnosed and fixed. Sponsor: backtrace.io Sponsor: The FreeBSD Foundation __________________________________________________________________ Kernel Updates to kernel subsystems/features, driver support, filesystems, and more. if_bridge Contact: Kristof Provost The current implementation of if_bridge uses a single mutex to protect its internal data structures. As a result it's nowhere near as fast as it could be. This is relevant for users who want to run many vnet jails or virtual machines bridged together, for example. As part of this project several new tests have already been added for if_bridge. These are generally very useful for validating any locking changes, and will also help to prevent regressions for other future changes. These tests live in /usr/tests/sys/net/if_bridge_test. The current work is concentrating on investigating if it's possible to leverage the ConcurrencyKit epoch code for the datapath (i.e. bridge_input(), bridge_output(), bridge_forward(), ...). Sponsor: The FreeBSD Foundation __________________________________________________________________ sigfastblock(2) Contact: Konstantin Belousov Rtld services need to be async signal safe. This is needed, for instance, to provide working symbol bindings in signal handlers. For threaded processes, libthr interposes all user-installed signal handlers and saves the signals and related context if signal is delivered while rtld or libthr are in protected section of code. In non-threaded processes, the async safety is provided by changing signal mask for the thread. It is actually better than the interposing done by libthr, since signals are delivered in the right context, instead of libthr attempt of recreate it later. But the unfortunate side-effect is that each rtld entry requires two syscalls, one to set mask, and one to restore it. Typically this adds around 40 or more syscalls on each process startup. Worse, rtld services used by typical language runtime exception handling systems also have the cost of signal mask manipulation. The new sigfastblock(2) syscall was added that allows thread to designate a memory location as fast signal block. If this word contains non-zero value, kernel interprets the thread state same as if all blockable signals are blocked. The facility drastically improves exception handling speed on FreeBSD. Since signals might abort interruptible sleeps, initial implementation read the blocking word on each syscall entry. This is needed to ensure that userspace does not see spurious EINTR/ERESTART if the signals are blocked by the word. Since if kernel cached outdated value for the block word, it would abort sleep, but then ast sees the correct mask and does not deliver the pending signal. There were concerns that this read of the word causes slowdown in syscalls microbenchmarks, esp. on machines with SMAP. The reason is that SMAP requires all userspace access bracketed by STAC/CLAC pair of instructions, which are de-facto serializing (this is not architectural, but all current microarchitectures do it). The decision was made to eliminate the word read, at the cost of possibly returning spurious EINTR. The impact should be minimal, since sigfastblock(2) is not supposed to be the service available to users, it is only assumed for rtld and libthr implementations. Sponsor: The FreeBSD Foundation __________________________________________________________________ arm64 LSE atomic instructions Contact: Mark Johnston An investigation of some performance oddities on EC2 Graviton 2 instances resulted in support for the use of Large System Extension (LSE) atomic instructions in the FreeBSD kernel. LSE is an mandatory ISA extension specified in ARMv8.1. It consists of a number of new atomic instructions, superseding the Load-Linked/Store-Conditional (LL/SC) instruction pairs use when LSE is not implemented. The extension is present in a number of ARMv8 server platforms, including the Cavium ThunderX2 and AWS Graviton 2. The new instructions provide significantly better scalability. A recent set of patches modified the FreeBSD kernel to detect support for LSE and dynamically select an atomic(9) implementation based on the new instructions when all CPUs implement the extension. The initial atomic(9) implementations were provided by Ali Saidi. Some benchmarking on a 64-vCPU Graviton 2 instance shows a ~4% reduction in wall clock time for a kernel build, and a ~15% reduction in system CPU time. Some ARMv8 multi-processor systems implement a heterogenous CPU architecture, referred to as big.LITTLE, in which multiple processor types are used. Surprisingly, such systems may implement the LSE on only a subset of its CPUs, in which case LSE instructions cannot be used by the kernel. As a result, FreeBSD currently waits until all processors are online before selecting the atomic(9) implementation, which precludes the use of ifuncs to provide dynamic selection. Currently atomic(9)'s use of LSE is limited to the kernel. A future project would extend this to userspace, so that FreeBSD system libraries can leverage the LSE instructions when they are available. Sponsor: The FreeBSD Foundation Sponsor: Amazon __________________________________________________________________ FreeBSD on Microsoft HyperV and Azure Links FreeBSD on MicrosoftAzure wiki URL: https://wiki.freebsd.org/MicrosoftAzure FreeBSD on Microsoft HyperV URL: https://wiki.freebsd.org/HyperV Contact: FreeBSD Integration Services Team Contact: Wei Hu Contact: Li-Wen Hsu Wei is working on HyperV Socket support for FreeBSD. HyperV Socket provides a way for the HyperV host and guest to communicate using a common socket interface without networking required. Some features in Azure require HyperV Socket support in the guest. Details of HyperV Socket is available here. The work-in-progress is available here This project is sponsored by Microsoft. Li-Wen is working on the FreeBSD release code related to Azure for the -CURRENT and 12-STABLE branches. The release of 12.1-RELEASE on Azure is also in progress. The work-in-progress is available here This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ FreeBSD on the ARM Morello platform Links The Arm Morello Board URL: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-morello.html The CHERI Project URL: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ Contact: Andrew Turner Contact: Ruslan Bukin Contact: Brooks Davis Contact: John Baldwin Contact: Robert Watson CHERI (Capability Hardware Enhanced RISC Instructions) extends conventional hardware Instruction-Set Architectures (ISAs) with new architectural features to enable fine-grained memory protection and highly scalable software compartmentalization. The CHERI memory-protection features allow historically memory-unsafe programming languages such as C and C++ to be adapted to provide strong, compatible, and efficient protection against many currently widely exploited vulnerabilities. The CHERI scalable compartmentalization features enable the fine-grained decomposition of operating-system (OS) and application code, to limit the effects of security vulnerabilities in ways that are not supported by current architectures. CHERI is a hybrid capability architecture in that it is able to blend architectural capabilities with conventional MMU-based architectures and microarchitectures, and with conventional software stacks based on virtual memory and C/C++. This approach allows incremental deployment within existing ecosystems, which we have demonstrated through hardware and software prototyping. On 18 October 2019, Arm announced Morello, an experimental CHERI-extended, multicore, superscalar ARMv8-A processor, System-on-Chip (SoC), and prototype board to be available from late 2021. Morello is a part of the UKRI £187M Digital Security by Design Challenge (DSbD) supported by the UK Industrial Strategy Challenge Fund, including a commitment of over £50M commitment by Arm. The aim is to test and validate CHERI extensions to the Arm ISA at scale with the idea that "successful concepts are expected to be carried forward into the architecture." The Morello board is scheduled to ship in the third quarter of 2021. Over the past decade we have developed CheriBSD, a version of FreeBSD supporting CHERI. Our public facing work has been performed on MIPS64 and more recently on RISC-V. Andrew has also developed a port to an earlier version of the Morello ISA which we will be merging into our public repository as simulators and compilers become available. The Morello board is based on the Arm Neoverse N1 platform and derived from the N1SDP development platform. (The AWS Graviton2 systems are also based on the N1 core.) Ruslan and Andrew are currently working to enable all relevant features of the N1 and the N1SDP to give us a solid baseline for work on Morello. These features include the PCI root complex, system memory management unit (SMMU), and CoreSight. To the extent practical we are upstreaming these features to FreeBSD. Sponsor: DARPA, UKRI __________________________________________________________________ NXP ARM64 SoC support Contact: Marcin Wojtas Contact: Artur Rojek Contact: Dawid Gorecki The Semihalf team initiated working on FreeBSD support for the NXP LS1046A SoC LS1046A are quad-core 64-bit ARMv8 Cortex-A72 processors with integrated packet processing acceleration and high speed peripherals including 10 Gb Ethernet, PCIe 3.0, SATA 3.0 and USB 3.0 for a wide range of networking, storage, security and industrial applications. Completed since the last update: * Clean-up and rebase support on top of FreeBSD-HEAD. Prepare features for the upstream submission: + QorIQ platform clockgen driver + LS1046A clockgen driver + GPIO support for QorIQ boards + QorIQ LS10xx AHCI driver + VF610 I2C controller support + TCA6416 GPIO expander + Epson RX-8803 RTC + QorIQ LS10xx SDHCI driver Todo: * Upstreaming of developed features. This work is expected to be submitted/merged to HEAD in the Q2 of 2020. Sponsor: Alstom Group __________________________________________________________________ ENA FreeBSD Driver Update Links ENA README URL: https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ena/README Contact: Michal Krawczyk Contact: Maciej Bielski Contact: Marcin Wojtas ENA (Elastic Network Adapter) is the smart NIC available in the virtualized environment of Amazon Web Services (AWS). The ENA driver supports multiple transmit and receive queues and can handle up to 100 Gb/s of network traffic, depending on the instance type on which it is used. Completed since the last update: * Upstream of the driver to v2.1.1, introducing: + Bug fix for LLQ mode which was causing race when multiple IO queues were used Work in progress: * Last touches for ENA v2.2.0 release, introducing: + Add driver support for the upcoming HW features (like Rx offsets, reporting Tx drops) + Add sysctl tuneables for IO queue number + Create IO queues with optional size backoff + Rework the way of configration of drbr and Rx ring size to be more robust and stable + New HAL version + Other minor fixes and improvements Sponsor: Amazon.com Inc __________________________________________________________________ Architectures Updating platform-specific features and bringing in support for new hardware platforms. FreeBSD/powerpc Project Contact: Mark Linimon Contact: Justin Hibbits Contact: Piotr Kubaj The FreeBSD/powerpc project continues to mature. In addition to the above listed people, we want to acknowledge contributions from adalava, bdragon, luporl, and mikael, among others. Key points: * On -CURRENT, all platforms have been switched to the LLVM 10.0 compiler and lld10. Thus, ld.bfd has been removed from base. * On powerpc64, -CURRENT has been switched to the ELFv2 ABI. Older versions of -CURRENT that either used GCC, or LLVM with the ELFv1 ABI, are no longer supported. * On powerpc64 FreeBSD-STABLE (11 and 12), the platforms still remain on the antique gcc4.2.1 in base. Note: that version of GCC has been removed from the -CURRENT src tree. Support for this configuration is now a "best-effort" status. * On powerpc (32-bit), the ABI did not change as with powerpc64, so upgrading should be easier than with powerpc64. Hardware status: * The aacraid(4) driver has been been fixed for big-endian, thanks to luporl. This means that Talos customers who got the SAS option can now use the onboard SAS. * The ixl(4) driver has also been fixed for big-endian, also thanks to luporl. Software status: * As a result of -CURRENT switching to LLVM/ELFv2, ifuncs became available, meaning that we now have optimized memcpy/bcopy and strncpy functions when running on processors that supports VSX instructions. * powerpc64 is now able to run on QEMU without the need of Huge Pages support. * The virtio drivers have been fixed. * kernel minidump has been fixed. Package status: * A FreeBSD.org package set is available for powerpc64/12 (quarterly). The -quarterly build has just been rebased from 12.0 to 12.1, per the desupport of the older 12.0. The first rebased build has been completed, with 29776 packages being available. * We are currently working on the upgrade of the package builder to a recent -CURRENT. Therefore, the available packages for -CURRENT are still ELFv1, which are not useful. Please contact Mark Linimon for more information. * mesa has been switched to llvm90, which fixes certain problems. * Work continues on firefox and related ports. * More ports fixes are being committed every day. The team would like to thank IBM for the loan of two POWER8 and one POWER9 machines, and Oregon State University (OSU) for providing the hosting. As well, we would like to thank the clusteradm team for keeping the Tyan POWER8 machines online that are hosted at NYI. Also, Piotr would like to thank the FreeBSD Foundation for funding his personal Talos, and Raptor (via its IntegriCloud subsidiary) for loaning a server on which talos.anongoth.pl runs. __________________________________________________________________ FreeBSD/RISC-V Project Links Wiki URL: https://wiki.freebsd.org/riscv Contact: Ruslan Bukin Contact: Mitchell Horne Contact: John Baldwin Contact: Kristof Provost Contact: Philip Paeps Contact: freebsd-riscv Mailing List Contact: IRC #freebsd-riscv channel on freenode It has been a year since the RISC-V project's last status report. In that time, the RISC-V port has benefited from increased attention, and received improvements of all kinds. The RISC-V project has brought in two new src committers. We'd like to welcome Jessica Clarke (jrtc27@), who is a member of CheriBSD, and Nick O'Brien (nick@) of Axiado to the team. Some highlights from last year: * Bring-up on SiFive's Hifive Unleashed board * Support for the OpenSBI firmware and version 0.2 of the SBI specification * Addition of the UART, SPI, and PRCI device drivers for the HiFive Unleashed Last quarter, the default compiler and linker was switched to clang/lld. This required a small number of integration changes on our side, but was mainly enabled by the upstream improvements to the RISC-V LLVM back-end. LLVM's RISC-V support became "official" with LLVM 9, and LLVM 10 has brought further improvements. The LLVM back-end is expected to continue to mature, as there are now many parties actively involved in its development. GCC remains supported as an external toolchain for RISC-V. The CI job for HEAD has been updated to use the clang/lld toolchain, and a GCC job will be added in the future. The RISC-V disk image built in the CI system now contains the full base system and is available on the CI artifact server for further testing. The CI test job was updated to use OpenSBI in qemu. Work on running the FreeBSD test suite for RISC-V in the CI system is in progress. Some progress has been made on supporting the ports framework on RISC-V, which was mostly untested until recently. First, emulators/qemu-user-static-devel received an update adding support for the RISC-V 64-bit ABI, allowing ports to be cross-compiled via poudiere(8). Second, improvements were made to the detection of the soft-float ABI, riscv64sf. Systems running either of the hard-float or soft-float ABIs can now compile and run ports natively. At the moment a small subset of ports can be built successfully, and in the coming months we will look to improve that to include a base set of crucial ports (e.g. python or perl). The CheriBSD project saw an initial port to RISC-V this quarter. Preliminary support for the CHERI ISA has been added to the Spike and QEMU emulators, as well as the necessary changes on the CheriBSD side. Currently, the CheriBSD RISC-V kernel boots, and most statically compiled CHERI binaries run without issue. Although real RISC-V hardware is still scarce, any users with an interest trying out or contributing to the RISC-V port are encouraged to do so. Please visit the recently updated wiki page for information on getting set up, or check out "Getting Started with FreeBSD/RISC-V" in the January/February edition of The FreeBSD Journal. Sponsor: DARPA, AFRL, Axiado, the FreeBSD Foundation __________________________________________________________________ Userland Programs Changes affecting the base system and programs in it. GCC 4.2.1 Retirement Contact: Ed Maste Contact: Warner Losh In 2007 the GNU Compiler Collection (GCC) migrated to GPLv3, which prompted discussions about the future of the FreeBSD tool chain. We held a Tool Chain Summit at BSDCan 2010. Roman Divacky gave an update on the ClangBSD project, building FreeBSD using the new and rapidly improving Clang compiler. Since that time Clang was imported into the FreeBSD base system and was used more and more widely - first being installed but not the default cc, then used by default on i386 and amd64, and later used on more and more targets. In the years since Dimitry Andric has been keeping our copy of Clang up-to-date. GCC 4.2.1 was kept in the tree for a few FreeBSD targets that hadn't migrated to Clang, such as MIPS and Sparc64. By early this year all remaning targets had migrated to external toolchain (contemporary GCC from ports or packages), or had been deprecated. With no in-tree consumers remaining, GCC 4.2.1 was removed from FreeBSD in r358454 on February 29, 2020. Sponsor: The FreeBSD Foundation __________________________________________________________________ elfctl utility Contact: Ed Maste In r340076 Ed added the NT_FREEBSD_FEATURE_CTL ELF note, used to allow binaries to opt out of, or in to, vulnerability mitigation and other features. FreeBSD Foundation intern Bora Özarslan later added a tool to decode and modify the ELF note, but it had yet to be installed by default. In the previous quarter Ed renamed the tool to elfctl, and installed it in /usr/bin. Ed also committed a number of minor bug fixes, code style improvements, etc. Usage examples - list known feature flags: $ elfctl -l Known features are: aslr Disable ASLR protmax Disable implicit PROT_MAX stackgap Disable stack gap wxneeded Requires W+X mappings List feature tags set on a binary: $ elfctl /bin/ls File '/bin/ls' features: aslr 'Disable ASLR' is unset. protmax 'Disable implicit PROT_MAX' is unset. stackgap 'Disable stack gap' is unset. wxneeded 'Requires W+X mappings' is unset. Indicate that a binary requests to opt-out of address randomization: $ elfctl -e +aslr binary Sponsor: The FreeBSD Foundation __________________________________________________________________ ELF Tool Chain Contact: Ed Maste A number of performance and functional improvements were committed to ELF Tool Chain tools over the last quarter. FreeBSD Foundation intern Tiger Gao added DWARF Debug Information Entry (DIE) caching to addr2line which provided a substantial improvement when translating many entries (even surpassing GNU addr2line with a large list). Tiger also rebased and updated an upstream ELF Tool Chain submission to handle DW_AT_ranges and addressed two elfcopy/objcopy bugs: setting the OS/ABI field correctly when converting a binary file to ELF, and correctly adding new sections when there is no .shstrtab section. Ed committed several readelf improvements, including decoding the PROTMAX_DISABLE, STKGAP_DISABLE, and WXNEEDED ELF feature control flags, decoding Xen and GNU Build-ID ELF notes, and improved input validation. Mark Johnston addressed many memory and file descriptor leaks and similar issues reported by Coverity Scan. Sponsor: The FreeBSD Foundation __________________________________________________________________ Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. KDE on FreeBSD Links KDE FreeBSD URL: https://freebsd.kde.org/ KDE Community FreeBSD URL: https://community.kde.org/FreeBSD Contact: Adriaan de Groot The KDE on FreeBSD project packages the software produced by the KDE Community for FreeBSD. The software includes a full desktop environment KDE Plasma, the art application Krita, video editor Kdenlive and hundreds of other applications that can be used on any FreeBSD desktop machine. The quarter opened with a new kstars (amateur astronomy application) release landing in ports, and then had the usual regular updates: * three KDE Frameworks releases (on a monthly schedule), * three bugfix releases to the collection of KDE software from the KDE release service (formerly KDE Applications, but it was always more that only-applications), * three bugfix releases to the KDE Plasma desktop. There were no substantial Qt updates but four bugfix releases for devel/cmake, and regular work all over the ports tree. The SDDM login manager was updated to a much newer -- by over a year -- release and patched to support more FreeBSD features. One update to devel/qca dropped compatibility with FreeBSD 11 because upstream no longer supports older OpenSSL versions. There is infrastructure in the ports tree now that adds a USES=qca for Qt applications needing crypto support. The open bugs list remains stable around 28 open issues, with some interesting xkb issues as a highlight. We welcome detailed bug reports and patches. KDE packaging updates are prepared in a copy of the ports repository on GitHub and then merged in SVN. We welcome pull requests there as well. __________________________________________________________________ XFCE Contact: Guido Falsi After the XFCE update to 4.14 a regression was observed in the XFCE window manager xfwm4. It caused window decorations to be drawn wrong or missing with certain graphic hardware setups. It has been reported that the recent update to Xorg server in the ports tree fixes this issue. The updated Xorg server will be available in the next qurterly branch. __________________________________________________________________ Wine on FreeBSD Links Wine homepage URL: https://www.winehq.org Contact: Gerald Pfeifer Contact: Lorenzo Salvadore The standard Wine port has moved from Wine 4.0.3 to Wine 5.0 which represents over 7,400 individual changes including built-in modules in PE format, multi-monitor support, Vulkan 1.1 support, and an XAudio2 re-implementation. After our request for help in the last quarterly report the i386 wine ports have been adopted by salvadore who immediately started resolving existing bugs and improving the ports. Most of this work is ready and we began committing first pieces in March. Since it takes more time than initially expected, we will also update the i386-wine-devel port during this process so that users needing a more recent version can easily get it from the ports tree (or binary packages). On the other hand, we plan on backporting these improvements to i386-wine after i386-wine-devel is done and only then update that port, so that we always guarantee a stable version of i386-wine. __________________________________________________________________ Go on freebsd/arm64 Links Go 1.14 Release Notes URL: https://golang.org/doc/go1.14#freebsd Contact: Mikaël Urankar Contact: Dmitri Goutnik Starting from the recently released version 1.14, Go now officially supports 64-bit ARM architecture on FreeBSD 12.0 or later. This porting effort was initially started by Greg V (aka myfreeweb) and resumed by Shigeru Yamamoto, Dmitri Goutnik and Mikaël Urankar. Dmitry has set up a CI builder to catch regression on FreeBSD aarch64 (it's required by the golang policy for adding a new port to the main Go repository) Work in progress: * a lot of ports use an old version of golang.org/x/sys or golang.org/x/net (to name a few) that doesn't contain the FreeBSD aarch64 bits, work is being done to fix these ports (details are in the bug tracker entry __________________________________________________________________ sysctlmibinfo2 API Links sysctlmibinfo2 URL: https://gitlab.com/alfix/sysctlmibinfo2 Contact: Alfonso Sabato Siciliano In the previous third and fouth quarterly status reports 2019, the sysctlinfo interface and an extension to improve the sysctlbyname() syscall were described, they can access to the sysctl MIB and pass the properties of an object to the userland, but both are quite low level and kernel related. The sysctlmibinfo2 library provides an API to explore the sysctl MIB, to convert an object name in its corresponding Object Identifier and to find an object to get its properties, therefore it is useful to handle an object correctly and to build a sysctl-like utility. Primarily sysctlmibinfo2 wraps the low level interface to provide an easy API, some example: sysctlmif_desc() retrieves the description of an object, sysctlmif_kind() gets the type (string, integer, etc) and sysctlmif_fmt() specifies the format (an integer could represent a deciKelvin, milliKelvin, etc), then it is possible to print properly an object value. Moreover sysctlmibinfo2 provides a high level API: a struct sysctlmif_object definition and functions to build data structures of objects. Example, let's say we want to manage the sound system, sysctlmif_grouplistbyname("hw.snd") returns the list of the Sound Driver objects and sysctlmif_treebyname("dev.pcm") returns a tree where "dev.pcm" is the root node and each subtree represents an audio device. Obviously sysctlmibinfo2 benefits of the features of sysctlinfo: handles OIDs up to CTL_MAXNAME levels, supports capability mode, can seek an object by its name (avoiding to explore the MIB just to find the corresponding OID), gets all info about an object in a time, manages a name with a NULL level or expanded with an input for the sysctl handler. The library can be installed via the devel/libsysctlmibinfo2 port, a manual page and examples in the Public Domain are available for getting started your projects. __________________________________________________________________ Documentation Noteworthy changes in the documentation tree, in manpages, or in external books/documents. FreeBSD Translations on Weblate Links Translate FreeBSD on Weblate wiki URL: https://wiki.freebsd.org/DocTranslationOnWeblate FreeBSD Weblate Instance URL: https://translate-dev.freebsd.org/ Contact: Danilo G. Baio Contact: Edson Brandi As announced on January, The FreeBSD Project is adopting Weblate as its web-based continuous localization platform. We are getting new volunteers to the effort and so far these are the numbers: Q1 2020 Status * 10 languages * 47 registered users Languages * Chinese (Simplified) (zh_CN) * Chinese (Traditional) (zh_TW) - Added * French (fr_FR) - Added * German (de_DE) - Added * Italian (it_IT) - Added * Norwegian Bokmål - Added - New language on FreeBSD * Persian (fa_IR) - Added - New language on FreeBSD * Portuguese (Brazil) * Spanish * Turkish (tr-TR) [1] - Added - New language on FreeBSD 1 - Already had an effort in the past. We want to thank everyone that contributed, translating or reviewing documents. And please, help promote this effort on your local user group, we always need more volunteers. __________________________________________________________________ FreeBSD Manpages overhaul Contact: Gordon Bergling I am currently working on an overhaul for the FreeBSD manpages by updating the HISTORY and STANDARDS sections and while here creating new manpages for parts of the system that missing documentation. FreeBSD has already one of the best documentation available for an UNIX-like operation system, but there are parts that could be improved. For the parts that have been already improved you can have a look at my Phabricator account. If you would like to help on improving the documentation effort, please contact Benedict Reuschling bcr@freebsd.org or me at gbergling@gmail.com. __________________________________________________________________ Third-Party Projects Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions. pot and the nomad pot driver Links pot project URL: https://pot.pizzamig.dev pot on github URL: https://github.com/pizzamig/pot Nomad pot driver URL: https://github.com/trivago/nomad-pot-driver minipot URL: https://github.com/pizzamig/minipot Contact: Luca Pizzamiglio Contact: Esteban Barrios An initial effort to write proper documentation and guides for the pot project has started. The documentation, even if incomplete, is available at here. A F.A.Q. page is available and waiting for users to submit their questions. During the last quarter, some bugs were reported on pot and on the nomad-pot-driver. Both projects released a new bug fix version. Many thanks to 'grembo' and 'Crest' that reported issues, tested and tried our solutions. Thanks also to Mateusz (0mp) for his Pull Requests! pot will have a new release soon (0.11.0), focused on network: * network stack support: ipv4 only, ipv6 only, dual stack. * flexible network setup for alias: adding the ability to use an arbitrary network setup for alias network type Contributions are welcome! Label "good first issue" has been added to issues to invite newcomers to contribute to the project! __________________________________________________________________ NomadBSD Links NomadBSD Website URL: https://www.nomadbsd.org/ NomadBSD Github URL: https://www.github.com/NomadBSD/NomadBSD NomadBSD Forum URL: https://forum.NomadBSD.org/ Contact: NomadBSD Team NomadBSD is a persistent live system for USB flash drives, based on FreeBSD. Together with automatic hardware detection and setup, it is configured to be used as a desktop system that works out of the box, but can also be used for data recovery, for educational purposes, or testing FreeBSD's hardware compatibility. In March we released a new minor version 1.3.1 which improves the configuration of the network interfaces, fixed some bugs and added nomadbsd-chusr and nomadbsd-sysinfo. Further some new features found their way into the release. Some days later the channel explainingcomputers on YouTube released a review video of NomadBSD. The explainingcomputers has almost 600,000 followers and the review was positive so we saw the highest peak in downloads ever! Along with it came a lot of people looking for help on our mailing list and on Twitter so we decided to set up a new support forum. We are looking for people to help the project. Help is much appreciated in all areas: * Translation of program interfaces * Design artwork * Programming new tools, extend existing ones * Tests and Bug reports / UX and feature suggestions * Mirrors outside of Europe Open tasks: * Support installation on disk partitions and add a partition editor GUI. * Complete disk encryption * Add a user-friendly network manager From owner-freebsd-stable@freebsd.org Tue Apr 14 09:53:18 2020 Return-Path: Delivered-To: freebsd-stable@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 5B36E2BB3CE for ; Tue, 14 Apr 2020 09:53:18 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 491gly1WMkz3x2k for ; Tue, 14 Apr 2020 09:53:18 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 163427EC1 for ; Tue, 14 Apr 2020 09:53:18 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id D9A55CAD4; Tue, 14 Apr 2020 11:53:16 +0200 (CEST) From: "Kristof Provost" To: freebsd-stable@freebsd.org Subject: CFT: if_bridge performance improvements Date: Tue, 14 Apr 2020 11:53:16 +0200 X-Mailer: MailMate (1.13.1r5671) Message-ID: <5E5BAA7D-8FDE-4163-997A-29D68F5FC642@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2020 09:53:18 -0000 Hi, Thanks to support from The FreeBSD Foundation I’ve been able to work on improving the throughput of if_bridge. It changes the (data path) locking to use the NET_EPOCH infrastructure. Benchmarking shows substantial improvements (x5 in test setups). This work is ready for wider testing now. It’s under review here: https://reviews.freebsd.org/D24250 Patch for CURRENT: https://reviews.freebsd.org/D24250?download=true Patches for stable/12: https://people.freebsd.org/~kp/if_bridge/stable_12/ I’m not currently aware of any panics or issues resulting from these patches. Do note that if you run a Bhyve + tap on bridges setup the tap code suffers from a similar bottleneck and you will likely not see major improvements in single VM to host throughput. I would expect, but have not tested, improvements in overall throughput (i.e. when multiple VMs send traffic at the same time). Best regards, Kristof From owner-freebsd-stable@freebsd.org Tue Apr 14 21:48:51 2020 Return-Path: Delivered-To: freebsd-stable@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 3E9CC2CA7E6 for ; Tue, 14 Apr 2020 21:48:51 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nsstlmta37p.bpe.bigpond.com (nsstlmta37p.bpe.bigpond.com [203.38.21.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "Openwave Messaging Inc." (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 491zdW5hnvz3L4F for ; Tue, 14 Apr 2020 21:48:46 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from smtp.telstra.com ([10.10.24.4]) by nsstlfep09p-svc.bpe.nexus.telstra.com.au with ESMTP id <20200414213553.BMXC9202.nsstlfep09p-svc.bpe.nexus.telstra.com.au@smtp.telstra.com> for ; Wed, 15 Apr 2020 07:35:53 +1000 X-RG-Spam: Unknown X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduhedrfedugdduieegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuuffpveftpgfvgffnuffvtfetpdfqfgfvnecuuegrihhlohhuthemucegtddtnecunecujfgurhephfgtgfgguffkfffvofesthhqmhdthhdtvdenucfhrhhomheptehnughrvgifucftvghilhhlhicuoegrrhgvihhllhihsegsihhgphhonhgurdhnvghtrdgruheqnecuffhomhgrihhnpegsihhgphhonhgurdgtohhmpdhtvghlshhtrhgrrdgtohhmnecukfhppeeitddrvddvjedrvddvtddrudehkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopegluddtrddtrddtrdeingdpihhnvghtpeeitddrvddvjedrvddvtddrudehkedpmhgrihhlfhhrohhmpeeorghrvghilhhlhiessghighhpohhnugdrnhgvthdrrghuqedprhgtphhtthhopeeofhhrvggvsghsugdqshhtrggslhgvsehfrhgvvggsshgurdhorhhgqe X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-RG-VS-CLASS: clean X-Authentication-Info: Submitted using ID areilly@bigpond.net.au Received: from [10.0.0.6] (60.227.220.158) by smtp.telstra.com (5.8.420) (authenticated as areilly@bigpond.net.au) id 5E854B1704AEF49D for freebsd-stable@freebsd.org; Wed, 15 Apr 2020 07:35:53 +1000 From: Andrew Reilly 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: Curl giving (27) Out of memory error where it didn't before Message-Id: <93AF62DD-3638-4326-BDAC-0054793FAB07@bigpond.net.au> Date: Wed, 15 Apr 2020 07:35:50 +1000 To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 491zdW5hnvz3L4F X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=bigpond.net.au; spf=pass (mx1.freebsd.org: domain of areilly@bigpond.net.au designates 203.38.21.37 as permitted sender) smtp.mailfrom=areilly@bigpond.net.au X-Spamd-Result: default: False [-2.40 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:203.38.21.0/24]; FREEMAIL_FROM(0.00)[bigpond.net.au]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_DN_NONE(0.00)[]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[bigpond.net.au,none]; MV_CASE(0.50)[]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[37.21.38.203.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[bigpond.net.au]; ASN(0.00)[asn:1221, ipnet:203.36.0.0/14, country:AU]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.00)[ipnet: 203.36.0.0/14(-4.01), asn: 1221(-2.65), country: AU(0.01)]; RECEIVED_SPAMHAUS_PBL(0.00)[158.220.227.60.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2020 21:48:51 -0000 Hi there, I have a cron job that is supposed to email me at a backup email account = if my ISP ever changes my IP address. It doesn't happen very often, but = it happened again this morning, and I was disappointed to find that the = script that does the notification failed. Sending e-mail in this way requires SSL connection to my ISP's mail = server (smtp.bigpond.com) and authentication, and I was pleased to = discover, a while back, that curl can handle both of those details, as = well as sending email. So I use this script (edited to elide passwords = and addresses): email-myself.sh: #!/bin/sh /usr/local/bin/curl -v -T- --ssl-reqd smtps://smtp.bigpond.com = --mail-from areilly@bigpond.net.au --mail-rcpt backup_address@me.com = --mail-auth areilly@bigpond.net.au --user = areilly@bigpond.net.au:password < To: Andrew Reilly Subject: $1 Date: $(date -R) $2 END As I said, previously that has worked perfectly, but today I'm getting = the following in my logs (thanks to having verbose output turned on): % Total % Received % Xferd Average Speed Time Time Time = Current Dload Upload Total Spent Left = Speed 0 0 0 0 0 0 0 0 --:--:-- 0:00:05 --:--:-- = 0* Trying 203.36.137.240:465... * Connected to smtp.bigpond.com (203.36.137.240) port 465 (#0) * successfully set certificate verify locations: * CAfile: /usr/local/share/certs/ca-root-nss.crt CApath: none } [5 bytes data] * TLSv1.3 (OUT), TLS handshake, Client hello (1): } [512 bytes data] * TLSv1.3 (IN), TLS handshake, Server hello (2): { [91 bytes data] * TLSv1.2 (IN), TLS handshake, Certificate (11): { [4836 bytes data] * TLSv1.2 (IN), TLS handshake, Server key exchange (12): { [333 bytes data] * TLSv1.2 (IN), TLS handshake, Server finished (14): { [4 bytes data] * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): } [70 bytes data] * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): } [1 bytes data] * TLSv1.2 (OUT), TLS handshake, Finished (20): } [16 bytes data] * TLSv1.2 (IN), TLS handshake, Finished (20): { [16 bytes data] * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 * Server certificate: * subject: C=3DAU; ST=3DVictoria; L=3DMelbourne; O=3DTelstra = Corporation Limited; OU=3DTechnology Product Ownership CH10; = CN=3Dmail.bigpond.com * start date: Jan 23 03:57:06 2020 GMT * expire date: Jan 23 04:07:00 2022 GMT * subjectAltName: host "smtp.bigpond.com" matched cert's = "smtp.bigpond.com" * issuer: C=3DBM; O=3DQuoVadis Limited; CN=3DQuoVadis Global SSL ICA G2 * SSL certificate verify ok. { [5 bytes data] < 220 smtp.telstra.com ESMTP Service ready } [5 bytes data] > EHLO Zen { [5 bytes data] < 250-smtp.telstra.com < 250-8BITMIME < 250-PIPELINING < 250-HELP < 250-AUTH=3DLOGIN < 250-AUTH LOGIN PLAIN < 250-DELIVERBY 300 < 250 SIZE 30000000 } [5 bytes data] > AUTH PLAIN { [5 bytes data] < 334 ? } [5 bytes data] > AGFyZWlsbHlAYmlncG9uZC5uZXQuYXUARnJhaGFuMHc=3D { [5 bytes data] < 235 PLAIN authentication successful 0 0 0 0 0 0 0 0 --:--:-- 0:00:05 --:--:-- = 0 } [5 bytes data] > QUIT { [5 bytes data] < 221 smtp.telstra.com QUIT * Closing connection 0 } [5 bytes data] * TLSv1.2 (OUT), TLS alert, close notify (256): } [2 bytes data] curl: (27) Out of memory That looks to me as though the SSL setup worked fine, then the AUTH = fine, then the message transfer all fine, and quitting too. So = everything was fine, but then curl crashed with error 27 "out of = memory", and I haven't received any messages. The web thinks that the two most likely ways for an out-of-date shared = library linkage or a not-thread-safe programming bug. So I used = portmaster -f to rebuild curl and all its dependencies, and it still = crashes exactly as shown. The computer in question is running: (uname -a) FreeBSD Zen.local 12.1-STABLE FreeBSD 12.1-STABLE r359760 GENERIC amd64 and has 32G of RAM and eight two-thread AMD 1700 cores. Any suggestions? Andrew Reilly M: 0409-824-272 areilly@bigpond.net.au From owner-freebsd-stable@freebsd.org Tue Apr 14 22:35:19 2020 Return-Path: Delivered-To: freebsd-stable@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 DD5492CB305; Tue, 14 Apr 2020 22:35:19 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (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 "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4920gC5Vj1z3NMG; Tue, 14 Apr 2020 22:35:19 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1129) id 96ADF16895; Tue, 14 Apr 2020 22:35:19 +0000 (UTC) Date: Tue, 14 Apr 2020 22:35:19 +0000 From: Li-Wen Hsu To: freebsd-testing@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD CI Weekly Report 2020-04-05 Message-ID: <20200414223519.GA33328@freefall.freebsd.org> Reply-To: freebsd-testing@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2020 22:35:19 -0000 (Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2020-04-05 =================================== Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-03-30 to 2020-04-05. During this period, we have: * 1715 builds (93.6% (+0.1) passed, 6.4% (-0.1) failed) of buildworld and buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 274 test runs (49.7% (-4.6) passed, 19.3% (-24.4) unstable, 31.0% (+29.0) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 26 doc and www builds (84.6 (-10.6) passed, 15.4% (+10.6) failed) Test case status (on 2020-04-05 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | ------------------- | --------- | --------- | ------- | -------- | | head/amd64 | 7740 (+4) | 7619 (-6) | 9 (+4) | 112 (+6) | | head/i386 | 7738 (+4) | 7613 (-4) | 11 (+6) | 114 (+2) | | 12-STABLE/amd64 | 7508 (+2) | 7452 (+2) | 0 (0) | 56 (0) | | 12-STABLE/i386 | 7506 (+2) | 7442 (-1) | 0 (0) | 64 (+3) | | 11-STABLE/amd64 | 6882 (+2) | 6835 (+5) | 0 (0) | 47 (-3) | | 11-STABLE/i386 | 6880 (+2) | 6831 (+5) | 0 (0) | 49 (-3) | (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/@FreeBSD-CI/report-20200405 and archive is available at https://hackmd.io/@FreeBSD-CI/ , any help is welcome. ## News * New armv6 job is added: * FreeBSD-head-armv6-testvm The images are available at https://artifact.ci.freebsd.org ## Failing jobs * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ * See console log for the error details. ## Failing tests * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/ Some test cases not correctly skipped because test env loads the wrong kyua.conf after kyua imported to the base. * lib.libproc.proc_test.symbol_lookup * lib.msun.ctrig_test.test_inf_inputs * local.kyua.integration.cmd_about_test.topic__authors__installed * sys.kern.ptrace_test.ptrace__parent_wait_after_attach * sys.netipsec.tunnel.empty.v4 * sys.netipsec.tunnel.empty.v6 * sys.opencrypto.blake2_test.blake2b_vectors_x86 * sys.opencrypto.blake2_test.blake2s_vectors_x86 * usr.bin.calendar.legacy_test.main * https://ci.freebsd.org/job/FreeBSD-head-i386-test/ All amd64 failures and: * sys.kern.ptrace_test.ptrace__parent_exits_before_child * sys.net.if_lagg_test.witness ## Regressions * 3 tests start failing after llvm10 import * lib.libproc.proc_test.symbol_lookup * lib.msun.ctrig_test.test_inf_inputs https://bugs.freebsd.org/244732 * (DTrace) common.pid.t_dtrace_contrib.err_D_PROC_OFF_toobig_d https://bugs.freebsd.org/244823 * fusefs tests fail when mac_bsdextended.ko is loaded https://bugs.freebsd.org/244229 * `dtrace -c` causes program dumps core after somewhere between (r357694, r357701] https://bugs.freebsd.org/244053 * Lock-order reversals triggered by tests under sys.net.if_lagg_test.* on i386 https://bugs.freebsd.org/244163 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) * sys.net.if_lagg_test.lacp_linkstate_destroy_stress panics i386 kernel https://bugs.freebsd.org/244168 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) * (test case) sys.geom.class.multipath.misc.fail_on_error (on 12-STABLE) https://bugs.freebsd.org/244158 ## Failing and Flaky tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * cddl.usr.sbin.dtrace.common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237641 * cddl.usr.sbin.dtrace.common.pid.t_dtrace_contrib.err_D_PROC_OFF_toobig_d * https://bugs.freebsd.org/244823 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~13 failing and ~109 skipped cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details * Work for cleaning these failing cass are in progress * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_ltp/ * Total 3670 tests (0), 2285 success (-5), 579 failures (+5), 806 skipped (0) ## Disabled Tests * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * sys.kern.ptrace_test.ptrace__PT_KILL_competing_stop https://bugs.freebsd.org/220841 * lib.libc.regex.exhaust_test.regcomp_too_big (i386 only) https://bugs.freebsd.org/237450 * sys.netinet.socket_afinet.socket_afinet_bind_zero https://bugs.freebsd.org/238781 * sys.netpfil.pf.names.names * sys.netpfil.pf.synproxy.synproxy https://bugs.freebsd.org/238870 * sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger https://bugs.freebsd.org/239292 * sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger https://bugs.freebsd.org/239397 * sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger https://bugs.freebsd.org/239399 * sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger https://bugs.freebsd.org/239425 * lib.libc.gen.getmntinfo_test.getmntinfo_test https://bugs.freebsd.org/240049 * sys.sys.qmath_test.qdivq_s64q https://bugs.freebsd.org/240219 * sys.kern.ptrace_test.ptrace__getppid https://bugs.freebsd.org/240510 * lib.libc.sys.stat_test.stat_socket https://bugs.freebsd.org/240621 * lib.libarchive.functional_test.test_write_filter_zstd https://bugs.freebsd.org/240683 * lib.libcasper.services.cap_dns.dns_test.main https://bugs.freebsd.org/241435 * local.kyua.* (31 cases) & local.lutok.* (3 cases) on 11-i386 https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/2278/testReport/ * sys.geom.class.multipath.failloop.failloop https://bugs.freebsd.org/242689 * sys.kern.ptrace_test.ptrace__procdesc_reparent_wait_child https://bugs.freebsd.org/243605 * skip sys.geom.class.multipath.failloop.failloop https://bugs.freebsd.org/244053 * sys.kern.ptrace_test.ptrace__parent_wait_after_attach https://bugs.freebsd.org/244055 * sys.kern.ptrace_test.ptrace__parent_exits_before_child https://bugs.freebsd.org/244056 * sys.geom.class.multipath.misc.fail_on_error (12-STABLE) https://bugs.freebsd.org/244158 * sys.net.if_lagg_test.witness (i386) https://bugs.freebsd.org/244163 * PipePdfork.WildcardWait in sys.capsicum.capsicum-test.main https://bugs.freebsd.org/244165 * sys.net.if_lagg_test.lacp_linkstate_destroy_stress (i386) https://bugs.freebsd.org/244168 * sys.netinet6.frag6.frag6_07.frag6_07 https://bugs.freebsd.org/244170 * sys.netinet.fibs_test.udp_dontroute6 https://bugs.freebsd.org/244172 * sys.netpfil.pf.nat.exhaust https://bugs.freebsd.org/244703 * sys.geom.class.gate.ggate_test.ggated https://bugs.freebsd.org/244737 ## Issues ### Cause build fails * https://bugs.freebsd.org/233735 Possible build race: genoffset.o /usr/src/sys/sys/types.h: error: machine/endian.h: No such file or directory * https://bugs.freebsd.org/233769 Possible build race: ld: error: unable to find library -lgcc_s ### Cause kernel panics * https://bugs.freebsd.org/238870 sys.netpfil.pf.names.names and sys.netpfil.pf.synproxy.synproxy cause panic Patch exists: * https://reviews.freebsd.org/D20868 * https://reviews.freebsd.org/D20869 ### Open * https://bugs.freebsd.org/237403 Tests in sys/opencrypto should be converted to Python3 * https://bugs.freebsd.org/237641 Flakey test case: common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237656 "Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of memory." seen when running sys/netipsec tests * https://bugs.freebsd.org/238781 sys.netinet.socket_afinet.socket_afinet_bind_zero does not work when mac_portacl(4) loaded * https://bugs.freebsd.org/239292 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger * https://bugs.freebsd.org/239397 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger * https://bugs.freebsd.org/239399 Flakey test case: sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger * https://bugs.freebsd.org/239425 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger * https://bugs.freebsd.org/241662 Flakey test case: lib.libarchive.functional_test.test_fuzz_iso9660 ### Others * [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg) From owner-freebsd-stable@freebsd.org Tue Apr 14 22:37:10 2020 Return-Path: Delivered-To: freebsd-stable@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 D1D772CB631; Tue, 14 Apr 2020 22:37:10 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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 "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4920jL5CmXz3Nhv; Tue, 14 Apr 2020 22:37:10 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1129) id A440116A26; Tue, 14 Apr 2020 22:37:10 +0000 (UTC) Date: Tue, 14 Apr 2020 22:37:10 +0000 From: Li-Wen Hsu To: freebsd-testing@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD CI Weekly Report 2020-04-12 Message-ID: <20200414223710.GB33328@freefall.freebsd.org> Reply-To: freebsd-testing@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2020 22:37:10 -0000 (Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2020-04-12 =================================== Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-04-06 to 2020-04-12. During this period, we have: * 1801 builds (94.0% (+0.4) passed, 6.0% (-0.4) failed) of buildworld and buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 288 test runs (25.1% (-24.6) passed, 29.9% (+10.6) unstable, 45.1% (+14.1) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 30 doc and www builds (83.3% (-1.3) passed, 16.7% (+1.3) failed) Test case status (on 2020-04-12 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | ------------------- | --------- | ---------- | -------- | -------- | | head/amd64 | 7744 (+4) | 7638 (+19) | 14 (+5) | 92 (-20) | | head/i386 | 7742 (+4) | 7628 (+15) | 16 (+5) | 98 (-16) | | 12-STABLE/amd64 | 7508 (0) | 7449 (-3) | 1 (+1) | 58 (+2) | | 12-STABLE/i386 | 7506 (0) | 7425 (-17) | 2 (+2) | 79 (+15) | | 11-STABLE/amd64 | 6882 (0) | 6829 (-6) | 1 (+1) | 52 (+5) | | 11-STABLE/i386 | 6880 (0) | 6749 (-82) | 80 (+80) | 51 (+2) | (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/@FreeBSD-CI/report-20200412 and archive is available at https://hackmd.io/@FreeBSD-CI/ , any help is welcome. ## News * The test env now loads the required module for firewall tests. * New armv7 job is added (to replace armv6 one): * FreeBSD-head-armv7-testvm The images are available at https://artifact.ci.freebsd.org FreeBSD-head-armv7-test is ready but needs test env update. ## Failing jobs * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ * See console log for the error details. ## Failing tests * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/ * local.kyua.integration.cmd_about_test.topic__authors__installed * sys.netipsec.tunnel.empty.v4 * sys.netipsec.tunnel.empty.v6 * sys.netpfil.common.forward.ipf_v4 * sys.netpfil.common.forward.ipfw_v4 * sys.netpfil.common.forward.pf_v4 * sys.netpfil.common.tos.ipfw_tos * sys.netpfil.common.tos.pf_tos * sys.netpfil.pf.forward.v4 * sys.netpfil.pf.set_tos.v4 * sys.opencrypto.blake2_test.blake2b_vectors_x86 * sys.opencrypto.blake2_test.blake2s_vectors_x86 * sbin.nvmecontrol.basic.__test_cases_list__ Fixed in r359903 * usr.bin.calendar.legacy_test.main Fixed in r359862 * https://ci.freebsd.org/job/FreeBSD-head-i386-test/ All amd64 failures and: * sys.netinet.divert.ipdivert_ip_input_local_success * sys.netinet.divert.ipdivert_ip_output_remote_success * https://ci.freebsd.org/job/FreeBSD-stable-12-amd64-test/ * usr.bin.calendar.legacy_test.main Fixed in r359863 * sbin.nvmecontrol.basic.__test_cases_list__ Fixed in r359904 * https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/ * usr.bin.calendar.legacy_test.main Fixed in r359863 * https://ci.freebsd.org/job/FreeBSD-stable-11-amd64-test/ * usr.bin.calendar.legacy_test.main Fixed in r359864 * https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/ Many failure all due to kyua.conf issue. Already fixed on 2020-04-13. ## Regressions * 3 tests start failing after llvm10 import * lib.libproc.proc_test.symbol_lookup * lib.msun.ctrig_test.test_inf_inputs https://bugs.freebsd.org/244732 * (DTrace) common.pid.t_dtrace_contrib.err_D_PROC_OFF_toobig_d https://bugs.freebsd.org/244823 * fusefs tests fail when mac_bsdextended.ko is loaded https://bugs.freebsd.org/244229 * `dtrace -c` causes program dumps core after somewhere between (r357694, r357701] https://bugs.freebsd.org/244053 * Lock-order reversals triggered by tests under sys.net.if_lagg_test.* on i386 https://bugs.freebsd.org/244163 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) * sys.net.if_lagg_test.lacp_linkstate_destroy_stress panics i386 kernel https://bugs.freebsd.org/244168 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) * (test case) sys.geom.class.multipath.misc.fail_on_error (on 12-STABLE) https://bugs.freebsd.org/244158 ## Failing and Flaky tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * cddl.usr.sbin.dtrace.common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237641 * cddl.usr.sbin.dtrace.common.pid.t_dtrace_contrib.err_D_PROC_OFF_toobig_d * https://bugs.freebsd.org/244823 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~13 failing and ~109 skipped cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details * Work for cleaning these failing cass are in progress * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_ltp/ * Total 3670 tests (0), 2285 success (-5), 579 failures (+5), 806 skipped (0) ## Disabled Tests * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * sys.kern.ptrace_test.ptrace__PT_KILL_competing_stop https://bugs.freebsd.org/220841 * lib.libc.regex.exhaust_test.regcomp_too_big (i386 only) https://bugs.freebsd.org/237450 * sys.netinet.socket_afinet.socket_afinet_bind_zero https://bugs.freebsd.org/238781 * sys.netpfil.pf.names.names * sys.netpfil.pf.synproxy.synproxy https://bugs.freebsd.org/238870 * sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger https://bugs.freebsd.org/239292 * sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger https://bugs.freebsd.org/239397 * sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger https://bugs.freebsd.org/239399 * sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger https://bugs.freebsd.org/239425 * lib.libc.gen.getmntinfo_test.getmntinfo_test https://bugs.freebsd.org/240049 * sys.sys.qmath_test.qdivq_s64q https://bugs.freebsd.org/240219 * sys.kern.ptrace_test.ptrace__getppid https://bugs.freebsd.org/240510 * lib.libc.sys.stat_test.stat_socket https://bugs.freebsd.org/240621 * lib.libarchive.functional_test.test_write_filter_zstd https://bugs.freebsd.org/240683 * lib.libcasper.services.cap_dns.dns_test.main https://bugs.freebsd.org/241435 * local.kyua.* (31 cases) & local.lutok.* (3 cases) on 11-i386 https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/2278/testReport/ * sys.geom.class.multipath.failloop.failloop https://bugs.freebsd.org/242689 * sys.kern.ptrace_test.ptrace__procdesc_reparent_wait_child https://bugs.freebsd.org/243605 * skip sys.geom.class.multipath.failloop.failloop https://bugs.freebsd.org/244053 * sys.kern.ptrace_test.ptrace__parent_wait_after_attach https://bugs.freebsd.org/244055 * sys.kern.ptrace_test.ptrace__parent_exits_before_child https://bugs.freebsd.org/244056 * sys.geom.class.multipath.misc.fail_on_error (12-STABLE) https://bugs.freebsd.org/244158 * sys.net.if_lagg_test.witness (i386) https://bugs.freebsd.org/244163 * PipePdfork.WildcardWait in sys.capsicum.capsicum-test.main https://bugs.freebsd.org/244165 * sys.net.if_lagg_test.lacp_linkstate_destroy_stress (i386) https://bugs.freebsd.org/244168 * sys.netinet6.frag6.frag6_07.frag6_07 https://bugs.freebsd.org/244170 * sys.netinet.fibs_test.udp_dontroute6 https://bugs.freebsd.org/244172 * sys.netpfil.pf.nat.exhaust https://bugs.freebsd.org/244703 * sys.geom.class.gate.ggate_test.ggated https://bugs.freebsd.org/244737 ## Issues ### Cause build fails * https://bugs.freebsd.org/233735 Possible build race: genoffset.o /usr/src/sys/sys/types.h: error: machine/endian.h: No such file or directory * https://bugs.freebsd.org/233769 Possible build race: ld: error: unable to find library -lgcc_s ### Cause kernel panics * https://bugs.freebsd.org/238870 sys.netpfil.pf.names.names and sys.netpfil.pf.synproxy.synproxy cause panic Patch exists: * https://reviews.freebsd.org/D20868 * https://reviews.freebsd.org/D20869 ### Open * https://bugs.freebsd.org/237403 Tests in sys/opencrypto should be converted to Python3 * https://bugs.freebsd.org/237641 Flakey test case: common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237656 "Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of memory." seen when running sys/netipsec tests * https://bugs.freebsd.org/238781 sys.netinet.socket_afinet.socket_afinet_bind_zero does not work when mac_portacl(4) loaded * https://bugs.freebsd.org/239292 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger * https://bugs.freebsd.org/239397 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger * https://bugs.freebsd.org/239399 Flakey test case: sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger * https://bugs.freebsd.org/239425 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger * https://bugs.freebsd.org/241662 Flakey test case: lib.libarchive.functional_test.test_fuzz_iso9660 ### Others * [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg) From owner-freebsd-stable@freebsd.org Tue Apr 14 22:55:23 2020 Return-Path: Delivered-To: freebsd-stable@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 4F4342CC13D for ; Tue, 14 Apr 2020 22:55:23 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nsstlmta18p.bpe.bigpond.com (nsstlmta18p.bpe.bigpond.com [203.38.21.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "Openwave Messaging Inc." (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49216J1m6Lz3Qck for ; Tue, 14 Apr 2020 22:55:19 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from smtp.telstra.com ([10.10.24.4]) by nsstlfep18p-svc.bpe.nexus.telstra.com.au with ESMTP id <20200414225514.FHBL11751.nsstlfep18p-svc.bpe.nexus.telstra.com.au@smtp.telstra.com> for ; Wed, 15 Apr 2020 08:55:14 +1000 X-RG-Spam: Unknown X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduhedrfedvgdduvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfupfevtfgpvffgnffuvffttedpqfgfvfenuceurghilhhouhhtmecugedttdenucenucfjughrpefhtggguffffhfvjgfkofesrgdtmherhhdtvdenucfhrhhomheptehnughrvgifucftvghilhhlhicuoegrrhgvihhllhihsegsihhgphhonhgurdhnvghtrdgruheqnecuffhomhgrihhnpegsihhgphhonhgurdgtohhmpdhtvghlshhtrhgrrdgtohhmpdhfrhgvvggsshgurdhorhhgnecukfhppeeitddrvddvjedrvddvtddrudehkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopegluddtrddtrddtrdeingdpihhnvghtpeeitddrvddvjedrvddvtddrudehkedpmhgrihhlfhhrohhmpeeorghrvghilhhlhiessghighhpohhnugdrnhgvthdrrghuqedprhgtphhtthhopeeofhhrvggvsghsugdqshhtrggslhgvsehfrhgvvggsshgurdhorhhgqe X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-RG-VS-CLASS: clean X-Authentication-Info: Submitted using ID areilly@bigpond.net.au Received: from [10.0.0.6] (60.227.220.158) by smtp.telstra.com (5.8.420) (authenticated as areilly@bigpond.net.au) id 5E7BBFAF07A90B04 for freebsd-stable@freebsd.org; Wed, 15 Apr 2020 08:55:14 +1000 From: Andrew Reilly Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Curl giving (27) Out of memory error where it didn't before Date: Wed, 15 Apr 2020 08:55:12 +1000 References: <93AF62DD-3638-4326-BDAC-0054793FAB07@bigpond.net.au> To: freebsd-stable@freebsd.org In-Reply-To: <93AF62DD-3638-4326-BDAC-0054793FAB07@bigpond.net.au> Message-Id: <446EDF4B-E736-4297-A132-C67EEC682785@bigpond.net.au> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49216J1m6Lz3Qck X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=bigpond.net.au; spf=pass (mx1.freebsd.org: domain of areilly@bigpond.net.au designates 203.38.21.18 as permitted sender) smtp.mailfrom=areilly@bigpond.net.au X-Spamd-Result: default: False [-2.40 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:203.38.21.0/24]; FREEMAIL_FROM(0.00)[bigpond.net.au]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_DN_NONE(0.00)[]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; MIME_TRACE(0.00)[0:+,1:+,2:~]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[bigpond.net.au,none]; MV_CASE(0.50)[]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[18.21.38.203.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[bigpond.net.au]; ASN(0.00)[asn:1221, ipnet:203.36.0.0/14, country:AU]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.00)[ipnet: 203.36.0.0/14(-4.08), asn: 1221(-2.68), country: AU(0.01)]; RECEIVED_SPAMHAUS_PBL(0.00)[158.220.227.60.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2020 22:55:23 -0000 Bother. Password leaked. Password changed. Thanks for the warning! Cheers, Andrew Reilly M: 0409-824-272 areilly@bigpond.net.au > On 15 Apr 2020, at 07:35 , Andrew Reilly = wrote: >=20 > Hi there, >=20 > I have a cron job that is supposed to email me at a backup email = account if my ISP ever changes my IP address. It doesn't happen very = often, but it happened again this morning, and I was disappointed to = find that the script that does the notification failed. >=20 > Sending e-mail in this way requires SSL connection to my ISP's mail = server (smtp.bigpond.com) and authentication, and I was pleased to = discover, a while back, that curl can handle both of those details, as = well as sending email. So I use this script (edited to elide passwords = and addresses): > email-myself.sh: > #!/bin/sh > /usr/local/bin/curl -v -T- --ssl-reqd smtps://smtp.bigpond.com = --mail-from areilly@bigpond.net.au --mail-rcpt backup_address@me.com = --mail-auth areilly@bigpond.net.au --user = areilly@bigpond.net.au:password < From: Andrew Reilly > To: Andrew Reilly > Subject: $1 > Date: $(date -R) >=20 > $2 > END >=20 > As I said, previously that has worked perfectly, but today I'm getting = the following in my logs (thanks to having verbose output turned on): >=20 > % Total % Received % Xferd Average Speed Time Time Time = Current > Dload Upload Total Spent Left = Speed > 0 0 0 0 0 0 0 0 --:--:-- 0:00:05 = --:--:-- 0* Trying 203.36.137.240:465... > * Connected to smtp.bigpond.com (203.36.137.240) port 465 (#0) > * successfully set certificate verify locations: > * CAfile: /usr/local/share/certs/ca-root-nss.crt > CApath: none > } [5 bytes data] > * TLSv1.3 (OUT), TLS handshake, Client hello (1): > } [512 bytes data] > * TLSv1.3 (IN), TLS handshake, Server hello (2): > { [91 bytes data] > * TLSv1.2 (IN), TLS handshake, Certificate (11): > { [4836 bytes data] > * TLSv1.2 (IN), TLS handshake, Server key exchange (12): > { [333 bytes data] > * TLSv1.2 (IN), TLS handshake, Server finished (14): > { [4 bytes data] > * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): > } [70 bytes data] > * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): > } [1 bytes data] > * TLSv1.2 (OUT), TLS handshake, Finished (20): > } [16 bytes data] > * TLSv1.2 (IN), TLS handshake, Finished (20): > { [16 bytes data] > * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 > * Server certificate: > * subject: C=3DAU; ST=3DVictoria; L=3DMelbourne; O=3DTelstra = Corporation Limited; OU=3DTechnology Product Ownership CH10; = CN=3Dmail.bigpond.com > * start date: Jan 23 03:57:06 2020 GMT > * expire date: Jan 23 04:07:00 2022 GMT > * subjectAltName: host "smtp.bigpond.com" matched cert's = "smtp.bigpond.com" > * issuer: C=3DBM; O=3DQuoVadis Limited; CN=3DQuoVadis Global SSL ICA = G2 > * SSL certificate verify ok. > { [5 bytes data] > < 220 smtp.telstra.com ESMTP Service ready > } [5 bytes data] >> EHLO Zen > { [5 bytes data] > < 250-smtp.telstra.com > < 250-8BITMIME > < 250-PIPELINING > < 250-HELP > < 250-AUTH=3DLOGIN > < 250-AUTH LOGIN PLAIN > < 250-DELIVERBY 300 > < 250 SIZE 30000000 > } [5 bytes data] >> AUTH PLAIN > { [5 bytes data] > < 334 ? > } [5 bytes data] >> AGFyZWlsbHlAYmlncG9uZC5uZXQuYXUARnJhaGFuMHc=3D > { [5 bytes data] > < 235 PLAIN authentication successful > 0 0 0 0 0 0 0 0 --:--:-- 0:00:05 = --:--:-- 0 > } [5 bytes data] >> QUIT > { [5 bytes data] > < 221 smtp.telstra.com QUIT > * Closing connection 0 > } [5 bytes data] > * TLSv1.2 (OUT), TLS alert, close notify (256): > } [2 bytes data] > curl: (27) Out of memory >=20 > That looks to me as though the SSL setup worked fine, then the AUTH = fine, then the message transfer all fine, and quitting too. So = everything was fine, but then curl crashed with error 27 "out of = memory", and I haven't received any messages. >=20 > The web thinks that the two most likely ways for an out-of-date shared = library linkage or a not-thread-safe programming bug. So I used = portmaster -f to rebuild curl and all its dependencies, and it still = crashes exactly as shown. >=20 > The computer in question is running: (uname -a) > FreeBSD Zen.local 12.1-STABLE FreeBSD 12.1-STABLE r359760 GENERIC = amd64 >=20 > and has 32G of RAM and eight two-thread AMD 1700 cores. >=20 > Any suggestions? >=20 > Andrew Reilly > M: 0409-824-272 > areilly@bigpond.net.au >=20 >=20 >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Wed Apr 15 13:34:17 2020 Return-Path: Delivered-To: freebsd-stable@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 D46692B65FB; Wed, 15 Apr 2020 13:34:17 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 492NcT4tFSz3M1b; Wed, 15 Apr 2020 13:34:17 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 74F9514BAF; Wed, 15 Apr 2020 13:34:17 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id BF7DBEA1B; Wed, 15 Apr 2020 15:34:15 +0200 (CEST) From: "Kristof Provost" To: freebsd-testing@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: FreeBSD CI Weekly Report 2020-04-12 Date: Wed, 15 Apr 2020 15:34:12 +0200 X-Mailer: MailMate (1.13.1r5671) Message-ID: In-Reply-To: <20200414223710.GB33328@freefall.freebsd.org> References: <20200414223710.GB33328@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 13:34:17 -0000 On 15 Apr 2020, at 0:37, Li-Wen Hsu wrote: > (Please send the followup to freebsd-testing@ and note Reply-To is > set.) > > FreeBSD CI Weekly Report 2020-04-12 > =================================== > > Here is a summary of the FreeBSD Continuous Integration results for > the period > from 2020-04-06 to 2020-04-12. > > During this period, we have: > > * 1801 builds (94.0% (+0.4) passed, 6.0% (-0.4) failed) of buildworld > and > buildkernel (GENERIC and LINT) were executed on aarch64, amd64, > armv6, > armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, > sparc64 architectures for head, stable/12, stable/11 branches. > * 288 test runs (25.1% (-24.6) passed, 29.9% (+10.6) unstable, 45.1% > (+14.1) > exception) were executed on amd64, i386, riscv64 architectures for > head, > stable/12, stable/11 branches. > * 30 doc and www builds (83.3% (-1.3) passed, 16.7% (+1.3) failed) > > Test case status (on 2020-04-12 23:59): > | Branch/Architecture | Total | Pass | Fail | Skipped | > | ------------------- | --------- | ---------- | -------- | -------- | > | head/amd64 | 7744 (+4) | 7638 (+19) | 14 (+5) | 92 (-20) | > | head/i386 | 7742 (+4) | 7628 (+15) | 16 (+5) | 98 (-16) | > | 12-STABLE/amd64 | 7508 (0) | 7449 (-3) | 1 (+1) | 58 (+2) | > | 12-STABLE/i386 | 7506 (0) | 7425 (-17) | 2 (+2) | 79 (+15) | > | 11-STABLE/amd64 | 6882 (0) | 6829 (-6) | 1 (+1) | 52 (+5) | > | 11-STABLE/i386 | 6880 (0) | 6749 (-82) | 80 (+80) | 51 (+2) | > > (The statistics from experimental jobs are omitted) > > If any of the issues found by CI are in your area of interest or > expertise > please investigate the PRs listed below. > > The latest web version of this report is available at > https://hackmd.io/@FreeBSD-CI/report-20200412 and archive is available > at > https://hackmd.io/@FreeBSD-CI/ , any help is welcome. > > ## News > > * The test env now loads the required module for firewall tests. > > * New armv7 job is added (to replace armv6 one): > * FreeBSD-head-armv7-testvm > The images are available at https://artifact.ci.freebsd.org > FreeBSD-head-armv7-test is ready but needs test env update. > > ## Failing jobs > > * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ > * See console log for the error details. > > ## Failing tests > > * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/ > * local.kyua.integration.cmd_about_test.topic__authors__installed > * sys.netipsec.tunnel.empty.v4 > * sys.netipsec.tunnel.empty.v6 > * sys.netpfil.common.forward.ipf_v4 > * sys.netpfil.common.forward.ipfw_v4 > * sys.netpfil.common.forward.pf_v4 > * sys.netpfil.common.tos.ipfw_tos > * sys.netpfil.common.tos.pf_tos > * sys.netpfil.pf.forward.v4 I can’t actually reproduce this failure in my test VM, but with the ci test VM I can reproduce the problem. It’s not related to pf, because the sanity check ping we do before we set up pf already fails. Or rather pft_ping.py sends an incorrect packet, because `ping` does get the packet to go where it’s supposed to go. Scapy seems to fail to find the source IP address, so we get this: 12:12:22.152652 IP 0.0.0.0 > 198.51.100.3: ICMP echo request, id 0, seq 0, length 12 I have a vague recollection that we’ve seem this problem before, but I can’t remember what we did about it. In all likelihood most of the other netpfil tests fail for exactly the same reason. Best regards, Kristof From owner-freebsd-stable@freebsd.org Wed Apr 15 14:09:57 2020 Return-Path: Delivered-To: freebsd-stable@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 BFF8B2B7FD3; Wed, 15 Apr 2020 14:09:57 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 492PPd53FVz3PW8; Wed, 15 Apr 2020 14:09:57 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 7A9EE14F66; Wed, 15 Apr 2020 14:09:57 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 20857EAAA; Wed, 15 Apr 2020 16:09:56 +0200 (CEST) From: "Kristof Provost" To: freebsd-testing@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, bofh@freebsd.org, "Alexander V. Chernikov" Subject: Re: FreeBSD CI Weekly Report 2020-04-12 Date: Wed, 15 Apr 2020 16:09:55 +0200 X-Mailer: MailMate (1.13.1r5671) Message-ID: In-Reply-To: References: <20200414223710.GB33328@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 14:09:57 -0000 On 15 Apr 2020, at 15:34, Kristof Provost wrote: > On 15 Apr 2020, at 0:37, Li-Wen Hsu wrote: >> (Please send the followup to freebsd-testing@ and note Reply-To is >> set.) >> >> FreeBSD CI Weekly Report 2020-04-12 >> =================================== >> >> Here is a summary of the FreeBSD Continuous Integration results for >> the period >> from 2020-04-06 to 2020-04-12. >> >> During this period, we have: >> >> * 1801 builds (94.0% (+0.4) passed, 6.0% (-0.4) failed) of buildworld >> and >> buildkernel (GENERIC and LINT) were executed on aarch64, amd64, >> armv6, >> armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, >> sparc64 architectures for head, stable/12, stable/11 branches. >> * 288 test runs (25.1% (-24.6) passed, 29.9% (+10.6) unstable, 45.1% >> (+14.1) >> exception) were executed on amd64, i386, riscv64 architectures for >> head, >> stable/12, stable/11 branches. >> * 30 doc and www builds (83.3% (-1.3) passed, 16.7% (+1.3) failed) >> >> Test case status (on 2020-04-12 23:59): >> | Branch/Architecture | Total | Pass | Fail | Skipped >> | >> | ------------------- | --------- | ---------- | -------- | -------- >> | >> | head/amd64 | 7744 (+4) | 7638 (+19) | 14 (+5) | 92 (-20) >> | >> | head/i386 | 7742 (+4) | 7628 (+15) | 16 (+5) | 98 (-16) >> | >> | 12-STABLE/amd64 | 7508 (0) | 7449 (-3) | 1 (+1) | 58 (+2) >> | >> | 12-STABLE/i386 | 7506 (0) | 7425 (-17) | 2 (+2) | 79 (+15) >> | >> | 11-STABLE/amd64 | 6882 (0) | 6829 (-6) | 1 (+1) | 52 (+5) >> | >> | 11-STABLE/i386 | 6880 (0) | 6749 (-82) | 80 (+80) | 51 (+2) >> | >> >> (The statistics from experimental jobs are omitted) >> >> If any of the issues found by CI are in your area of interest or >> expertise >> please investigate the PRs listed below. >> >> The latest web version of this report is available at >> https://hackmd.io/@FreeBSD-CI/report-20200412 and archive is >> available at >> https://hackmd.io/@FreeBSD-CI/ , any help is welcome. >> >> ## News >> >> * The test env now loads the required module for firewall tests. >> >> * New armv7 job is added (to replace armv6 one): >> * FreeBSD-head-armv7-testvm >> The images are available at https://artifact.ci.freebsd.org >> FreeBSD-head-armv7-test is ready but needs test env update. >> >> ## Failing jobs >> >> * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ >> * See console log for the error details. >> >> ## Failing tests >> >> * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/ >> * local.kyua.integration.cmd_about_test.topic__authors__installed >> * sys.netipsec.tunnel.empty.v4 >> * sys.netipsec.tunnel.empty.v6 >> * sys.netpfil.common.forward.ipf_v4 >> * sys.netpfil.common.forward.ipfw_v4 >> * sys.netpfil.common.forward.pf_v4 >> * sys.netpfil.common.tos.ipfw_tos >> * sys.netpfil.common.tos.pf_tos >> * sys.netpfil.pf.forward.v4 > I can’t actually reproduce this failure in my test VM, but with the > ci test VM I can reproduce the problem. > It’s not related to pf, because the sanity check ping we do before > we set up pf already fails. > Or rather pft_ping.py sends an incorrect packet, because `ping` does > get the packet to go where it’s supposed to go. > > Scapy seems to fail to find the source IP address, so we get this: > > 12:12:22.152652 IP 0.0.0.0 > 198.51.100.3: ICMP echo request, id 0, > seq 0, length 12 > > I have a vague recollection that we’ve seem this problem before, but > I can’t remember what we did about it. > > In all likelihood most of the other netpfil tests fail for exactly the > same reason. The problem appears to be that /usr/local/lib/python3.7/site-packages/scapy/arch/unix.py is misparsing the `netstat -rnW` output. For reference, this is the output in the test VM: Routing tables Internet: Destination Gateway Flags Nhop# Mtu Netif Expire 127.0.0.1 link#2 UH 1 16384 lo0 192.0.2.0/24 link#4 U 2 1500 epair0a 192.0.2.1 link#4 UHS 1 16384 lo0 198.51.100.0/24 192.0.2.2 UGS 3 1500 epair0a Internet6: Destination Gateway Flags Nhop# Mtu Netif Expire ::/96 ::1 UGRS 4 16384 lo0 ::1 link#2 UH 1 16384 lo0 ::ffff:0.0.0.0/96 ::1 UGRS 4 16384 lo0 fe80::/10 ::1 UGRS 4 16384 lo0 fe80::%lo0/64 link#2 U 3 16384 lo0 fe80::1%lo0 link#2 UHS 2 16384 lo0 fe80::%epair0a/64 link#4 U 5 1500 epair0a fe80::3d:9dff:fe7c:d70a%epair0a link#4 UHS 1 16384 lo0 fe80::%epair1a/64 link#6 U 6 1500 epair1a fe80::37:9eff:fe03:250a%epair1a link#6 UHS 1 16384 lo0 ff02::/16 ::1 UGRS 4 16384 lo0 The parsing code seems to think that the netif for the 198.51.100.0/24 route is 1500 rather than epair0a. This may be related to the difference in netstat output, because on my VM it looks like this: Routing tables Internet: Destination Gateway Flags Use Mtu Netif Expire default 172.16.2.1 UGS 319 1500 vtnet0 127.0.0.1 link#2 UH 0 16384 lo0 172.16.2.0/24 link#1 U 14 1500 vtnet0 172.16.2.2 link#1 UHS 0 16384 lo0 Internet6: Destination Gateway Flags Use Mtu Netif Expire ::/96 ::1 UGRS 0 16384 lo0 ::1 link#2 UH 0 16384 lo0 ::ffff:0.0.0.0/96 ::1 UGRS 0 16384 lo0 fe80::/10 ::1 UGRS 0 16384 lo0 fe80::%vtnet0/64 link#1 U 0 1500 vtnet0 fe80::5a9c:fcff:fe02:a95e%vtnet0 link#1 UHS 0 16384 lo0 fe80::%lo0/64 link#2 U 0 16384 lo0 fe80::1%lo0 link#2 UHS 0 16384 lo0 ff02::/16 ::1 UGRS 0 16384 lo0 I suspect that this change was introduced in r359823 (Introduce nexthop objects and new routing KPI). Best regards, Kristof From owner-freebsd-stable@freebsd.org Wed Apr 15 15:28:18 2020 Return-Path: Delivered-To: freebsd-stable@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 D5E5D2BA023; Wed, 15 Apr 2020 15:28:18 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 492R825Nhvz40DN; Wed, 15 Apr 2020 15:28:18 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 9A0EA175E8; Wed, 15 Apr 2020 15:28:18 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 35C53ED27; Wed, 15 Apr 2020 17:28:17 +0200 (CEST) From: "Kristof Provost" To: "Olivier =?utf-8?q?Cochard-Labb=C3=A9?=" Cc: freebsd-testing@freebsd.org, freebsd-current , Stable , bofh@freebsd.org, "Alexander V. Chernikov" Subject: Re: FreeBSD CI Weekly Report 2020-04-12 Date: Wed, 15 Apr 2020 17:28:13 +0200 X-Mailer: MailMate (1.13.1r5671) Message-ID: In-Reply-To: References: <20200414223710.GB33328@freefall.freebsd.org> MIME-Version: 1.0 Embedded-HTML: [{"HTML":[362, 854], "plain":[58, 303], "uuid":"C83DB664-8363-477B-9B11-992FD4A5E8E1"}] Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 15:28:18 -0000 On 15 Apr 2020, at 16:49, Olivier Cochard-Labbé wrote: > On Wed, Apr 15, 2020 at 4:10 PM Kristof Provost > wrote: > >> >> The problem appears to be that >> /usr/local/lib/python3.7/site-packages/scapy/arch/unix.py is >> misparsing >> the `netstat -rnW` output. >> > > Shouldn't scapy use the libxo output of netstat to mitigate this > regression > ? That would likely help, yes. I’m going to leave that decision up to the maintainer, because I’m not going to do the work :) I’m also not sure how “stable” we want the netstat output to be. Best regards, Kristof From owner-freebsd-stable@freebsd.org Wed Apr 15 17:08:14 2020 Return-Path: Delivered-To: freebsd-stable@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 DD1E52BC45E for ; Wed, 15 Apr 2020 17:08:14 +0000 (UTC) (envelope-from raul.munoz@custos.es) Received: from mail3.custos.es (mail3.custos.es [5.2.90.130]) by mx1.freebsd.org (Postfix) with ESMTP id 492TMH1hJMz46VJ for ; Wed, 15 Apr 2020 17:08:10 +0000 (UTC) (envelope-from raul.munoz@custos.es) Received: from plank.b2n.org (plank.b2n.org [213.37.4.13]) by mail3.custos.es (Postfix) with ESMTP id 002F9125EE2 for ; Wed, 15 Apr 2020 19:08:08 +0200 (CEST) Received: from [10.10.10.15] (4.191.94.90.dynamic.jazztel.es [90.94.191.4]) by plank.b2n.org (Postfix) with ESMTPSA id 8DE293F32 for ; Wed, 15 Apr 2020 19:08:07 +0200 (CEST) Subject: Re: CFT: if_bridge performance improvements To: freebsd-stable@freebsd.org References: <5E5BAA7D-8FDE-4163-997A-29D68F5FC642@FreeBSD.org> From: =?UTF-8?B?UmHDumwgTXXDsW96IC0gQ1VTVE9T?= Autocrypt: addr=raul.munoz@custos.es; prefer-encrypt=mutual; keydata= mQINBFns2ZIBEAC7xWTucmdvscBLlryw1xv2opUqexkdusr4cR8lzRn+KOUmpDoibIK4C0In PPY157sWviEwCx24Hs+e664vwx6xD7zQ7ttVE30t+bm4iVqdxyIDMdgEbWOcTpYRjhRIGGpX BeBt+eYw+uE519bXHJZJJGcIzUU6Wk9fghx8RHMb5IEg4+9rsyCnEznE8u8AfJTgeOdA4h0h EweHjOFJdn6i+3r1KZlwFMIUFBo+q8ldHVzjPZGGSjguW62GgYMFn5uiYxpqTkKqD9FwrRlz n41QIOzE8o6jJfF/r4py1EiHwOTfvrrCNOA5cJXFrTsmCTj8dAySEThlxfSKQED0uPZVaegL 8KDvJ56oR9U6YE86fTdn713TvukVWeK58ZjgF/kQMymTjFFbe2IeG/QkxjWbcHb8EpLNXtIL HFX0+sezFnhKJrfGyq4jqWqWp8suzzhgQBNSQxkHNuQADabHJ13VH6qqIeC0UGUtUjEwxznh 51uyh0APK+7xhSc4+JKcVZcK7xkhY04wPT4x/dn2IbwCXewTMHROqo4oWP2ajN4bTOte1tot ZUbeLgPdr9iZrTSdt63lnTTbAxnXAxxBc/q8hVsiWM9SfOIkZ0kGeNA8NlrubcuXQzTJHy2h JhmLSuLfUaGZcr+F/3KtohTvshy2291/ruM8ExMUSDd3wb96fwARAQABtCxSYcO6bCBNdcOx b3ogLSBDVVNUT1MgPHJhdWwubXVub3pAY3VzdG9zLmVzPokCPwQTAQIAKQUCWezZkgIbIwUJ CWYBgAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJELKl4+9JDtBb750P/1d/rU1Ngc94 rVL2vqDEijJdFYEZbzE96MugnwCEdJ8Al/6mWbD4vaPIuuuW+TE8dMPItcUv1vq8D/wX8NSs OS5FNu7XfGpjjxOKdUpLLoiGbJC4AbhMZhvdpvWQQAk5szCzGT+nYPve7Ut6SyWtZPYwWM+K o5CNyRu838jfGhm6G8CvaLJHcrMBlA87OBkQi4tzT+NIBBp0U8vGXV8z6LlpI/EGXLgSJPnO pFn8PL6tXZ1uiI+AXVJT+emdB68InejcHgFrwoowZBLzXllGPH4pYVZ1h9pPARoPCmSlCe4x g+ELKvkogatQM4BXuzRGiYCVJDBqgFoRDDd/dnmsCb5DV0xWSlmpWPy06e9C8PwCI3NmukCh mq2ic74mAo9lKTv8VVc9czushKagVQhYPT3o6DHOCFJeoXvaQWIOprpAkcf5nz15SjeZWFqW EzF8+0LUocGLDLMaDkWBBruJuQfz8V3ktDdXkEv55sgrbf/98sGdIz3aOSrLy3Rop3m3shnM Uua1XpE6Fv+6g8owSI15k8bd0lmsq83/YYW2hN0vQWn/HR7xTwpA9fZh4stxJRJAHAJ7nQ/u SJkp2+NVOn9ZImKqegqqmn+amnkRsSunM1fe/i2GVsgKzkOlyDiLotUk8JU6t741kIJscGfW 8y1uC2Cf7T1tHdQsG4Hq1+C/uQINBFns2ZIBEACv+REqRGM1e6CuNil4Kim3Bi5RTXXx2/JJ dCC5W0ZsEoynoQ31RJ+3nu9OGDGzmEL+2fMVxvKiomXnwq6xZmhb6HFw03e/lOfYEEMm1hjj 23Dw9gNO3Dy5j1o3vzOWPOQwZpsE2vG0XE3ZfZ+Rg1b3SIe1R7w0nnzDAjznpYuG6WEYGFr9 r7IDouLqgBeR1i4B4M+7E8FLql06pyxF4plcJ1KSf++SNZf0arFuLzGZh9aA6L4OQ3eIqBg0 VqId8GiO6cz1t68dpOuwlt/HEcA3tCL15IIhKxQyWAU3S4yM/KBSXXGW2OI+EebFrBxYXySA IByYogpq795uiZ6gBDtQDvx1A8WHMy/7nDnXwJ9XTKzpjIFjKH0Gi/IpvxD1Aci/JbCzB76w iTA4Hbdw0iiZFUN3Wby5eVvkOBA5G+uaLJH10nyIZAe1IszaCxK+3sad6bVd2FsD7qmVHovq iLrjEa+p36kZB/Aeqm+Xwnwss32cOT3GZ6Cgs3ZYBwLJcPo+hhV9JXn7j8nt4tfJr5wm/HDN 4LgUKhUxTWrTS+iTbMtQ9NQdY4QrnB8Qa5E9mEeuZgorZCIrQm1D6MaoEX6fJ8yTru82EavX 9geX58VlFNcK32Ys1Ox0gsg6bX3CRRdAX42X4byuGGkkFwANULSCtepqbm9HO7FbGjkzNtO/ TQARAQABiQIlBBgBAgAPBQJZ7NmSAhsMBQkJZgGAAAoJELKl4+9JDtBbHaYP+wXvUGqFdxea O3Ec2WAFDzSS7EnLWAxrEHkKCIpVKYQ0TlYTd9HS2aGZ0oVJA3vNezJ3j8yusylNO9wWWIdX JQ5hrgzvEYzvb1hpo65CUsK954scz8lmh+Wh2bx728PssQsbL2gCiUJsLD6IDm9Q7374Ztsb sd1Qg+G7TmU2VQrVMo7eA3hGeNCcmiZH3zxHF8L2q1IEbo11/GaDzg9E53/lkd2+gizSD2PG OabRmIRAY7pUDjn54trQy/5fxNq0idyUUZYe6UbhE7UhpWAEdnU2Hp8bVyeJDMM6HiV7Apqg SuGcmGMYfBlNd+itjJk4MFYoIij+UiryCHfWwO8+bELyffDgHEcoVsgbL7Nn6TXoH6QjuMD2 cjGXoKplCV5jxTQJAd5/vnczlTbDA30UOwcje02r4mMh3vLaYeLNJ0Z8RCh09o7IeGskmwy4 849V5LoX3/TRKDnCf+rK7v08SEhb5QeUZ2GUwyEEby67TEmKE5LmQRj1gPnrH3Wlx2BkS/pS Y3k2cGEtoSYF3gUIec2VvzG52VSMJIOZZDcgscwvubJdRdvNPhGApWPgT8ZDfeafgJz/tRg/ hj6Zeln2xKBxgVKY/dJJouCJZdTOE6lB9vRJyCveVSi+uDu3G8idTON5cRLEy/acpBE8n0Ve noPvPYKoN8z5Hsw8DRyWVkxU Message-ID: <5205f036-eb96-d1ea-e0b8-d79876855fc3@custos.es> Date: Wed, 15 Apr 2020 19:08:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <5E5BAA7D-8FDE-4163-997A-29D68F5FC642@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 492TMH1hJMz46VJ X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.60 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[custos.es:s=dkim]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:5.2.90.130]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[custos.es]; DKIM_TRACE(0.00)[custos.es:+]; RCVD_IN_DNSWL_NONE(0.00)[130.90.2.5.list.dnswl.org : 127.0.10.0]; IP_SCORE(-3.20)[ip: (-9.23), ipnet: 5.2.88.0/21(-4.61), asn: 198432(-2.18), country: ES(0.04)]; RCVD_NO_TLS_LAST(0.10)[]; RECEIVED_SPAMHAUS_PBL(0.00)[13.4.37.213.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11,4.191.94.90.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:198432, ipnet:5.2.88.0/21, country:ES]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 17:08:15 -0000 El 14/4/20 a las 11:53, Kristof Provost escribió: > Patches for stable/12: https://people.freebsd.org/~kp/if_bridge/stable_12/ Bridges and taps here, r359859 with your if_bridge patches, happily running for more than two days ;). Regards, Raúl From owner-freebsd-stable@freebsd.org Wed Apr 15 17:17:01 2020 Return-Path: Delivered-To: freebsd-stable@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 DA5782BC9BF for ; Wed, 15 Apr 2020 17:17:01 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 492TYS5VKNz47HT for ; Wed, 15 Apr 2020 17:17:00 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-qk1-x731.google.com with SMTP id l25so18109258qkk.3 for ; Wed, 15 Apr 2020 10:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:in-reply-to:to; bh=Mp4OvklHX8KmGCtd+bw8j7UdSDaovIulPpFhhTB7yxE=; b=RE7sXTOOqpcrHQfmIbVDaeX57hM/1KXhYgeUZdDMgngxPbmL7XxTJMTvw4fTa5b4f6 +Gp7w5lJI2vHbK2r5UYEmtPOZIbZU+OVZg5J6XNlasP8+HnaHcFm0VYKV0pdXPKpPUR+ LATv4CVfxeXj/tQ5h4Pof91BvTExRTgczSseRH3SbLb4gs6uB7iyYSuZh9+1BK2D/04j ZG3UZShi+6e7HcAfZltXBcXJPdMFYcKLiN4riOLzKdROuP4tl8GIl5GXaWwsoJeNxAer 71nmXZ/VmEwr9F3HDPAQ6gkH40ok1JH/gGFJTBvHsbryaFPN+Pqsfha4GrYkmKF9jpJy fosQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:in-reply-to:to; bh=Mp4OvklHX8KmGCtd+bw8j7UdSDaovIulPpFhhTB7yxE=; b=atHaf37hM37NXVVIqdH+o7ya4mKgC2+QaTxtXjbM6pjUPw2QcmF9tXA65FF6zHWB5O xyqqUCoQbdEonZr9XlHGc78ib+nCz6oRuGDhScG43Bs/oujxSpi2DPfBbB4CLyvjRUDv gPnm0BehTAdf4MeC8h4vUeshStN2lMp81KMqKkohDoKRIsWNm6xAPejiD6d6yWVGZh8a iaK9HYCwJ7csKDvsBPegkMW8bvI7RzA/qG0i0mzKT3qC53ou3B6gIof/sOmyrKdfhhKL nbc9Shj6L6vwqR5SH+kLcYGGicOxMykcTN8ZIFH/Skb/5MhHhiU6JA1dgXPylfjEMdSk ox7Q== X-Gm-Message-State: AGi0PuY0EhHn9vOzSZJ4tWsMcIoQNSbF8EYMkDvBPJ4gRQeT2Dy+N4DS CZoPDv3mgdq9DZ5BIdlaLW8mqRmGMju7/A== X-Google-Smtp-Source: APiQypJSLzvwijTg9IyQv4X4ETfx5s6Udd/qrpyeGa8KKO9bEmDT87VrkISQXtZ4U4Ho6FLC/8Kozg== X-Received: by 2002:a37:2e44:: with SMTP id u65mr27767450qkh.42.1586971019406; Wed, 15 Apr 2020 10:16:59 -0700 (PDT) Received: from [192.168.1.31] (ool-457b63be.dyn.optonline.net. [69.123.99.190]) by smtp.gmail.com with ESMTPSA id o68sm1768304qka.110.2020.04.15.10.16.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Apr 2020 10:16:58 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Mark Saad Mime-Version: 1.0 (1.0) Subject: Re: CFT: if_bridge performance improvements Date: Wed, 15 Apr 2020 13:16:57 -0400 Message-Id: <97CA57D5-9315-42AE-B058-1FCB31A677EC@longcount.org> References: <5205f036-eb96-d1ea-e0b8-d79876855fc3@custos.es> In-Reply-To: <5205f036-eb96-d1ea-e0b8-d79876855fc3@custos.es> To: freebsd-stable@freebsd.org X-Mailer: iPhone Mail (17D50) X-Rspamd-Queue-Id: 492TYS5VKNz47HT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=longcount-org.20150623.gappssmtp.com header.s=20150623 header.b=RE7sXTOO; dmarc=none; spf=none (mx1.freebsd.org: domain of nonesuch@longcount.org has no SPF policy when checking 2607:f8b0:4864:20::731) smtp.mailfrom=nonesuch@longcount.org X-Spamd-Result: default: False [-3.79 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[longcount-org.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[longcount.org]; DKIM_TRACE(0.00)[longcount-org.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[1.3.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)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-1.99)[ip: (-9.14), 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]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[190.99.123.69.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 17:17:01 -0000 All Should this improve wifi to wired bridges in some way ? Has this been tes= ted ?=20 --- Mark Saad | nonesuch@longcount.org > On Apr 15, 2020, at 1:08 PM, Ra=C3=BAl Mu=C3=B1oz - CUSTOS via freebsd-sta= ble wrote: >=20 > =EF=BB=BFEl 14/4/20 a las 11:53, Kristof Provost escribi=C3=B3: >=20 >> Patches for stable/12: https://people.freebsd.org/~kp/if_bridge/stable_12= / >=20 > Bridges and taps here, r359859 with your if_bridge patches, happily > running for more than two days ;). >=20 > Regards, > Ra=C3=BAl > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Wed Apr 15 17:37:13 2020 Return-Path: Delivered-To: freebsd-stable@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 9076F2BD236 for ; Wed, 15 Apr 2020 17:37:13 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 492V0n3Ljmz48QT; Wed, 15 Apr 2020 17:37:13 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 55318185D4; Wed, 15 Apr 2020 17:37:13 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id CD7AAEF8D; Wed, 15 Apr 2020 19:37:11 +0200 (CEST) From: "Kristof Provost" To: "Mark Saad" Cc: freebsd-stable@freebsd.org Subject: Re: CFT: if_bridge performance improvements Date: Wed, 15 Apr 2020 19:37:11 +0200 X-Mailer: MailMate (1.13.1r5671) Message-ID: <0C115843-FB05-40D7-B1D7-F9B7842E9B54@FreeBSD.org> In-Reply-To: <97CA57D5-9315-42AE-B058-1FCB31A677EC@longcount.org> References: <5205f036-eb96-d1ea-e0b8-d79876855fc3@custos.es> <97CA57D5-9315-42AE-B058-1FCB31A677EC@longcount.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 17:37:13 -0000 On 15 Apr 2020, at 19:16, Mark Saad wrote: > All > Should this improve wifi to wired bridges in some way ? Has this > been tested ? > What sort of setup do you have to bridge wired and wireless? Is the FreeBSD box also a wifi AP? I’ve not done any tests involving wifi. Best regards, Kristof From owner-freebsd-stable@freebsd.org Wed Apr 15 18:35:47 2020 Return-Path: Delivered-To: freebsd-stable@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 D0DB62BE6A9 for ; Wed, 15 Apr 2020 18:35:47 +0000 (UTC) (envelope-from ian@dijix.com) Received: from relay1.stackmail.com (relay1.stackmail.com [185.151.28.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 492WJL67sGz4CvZ for ; Wed, 15 Apr 2020 18:35:46 +0000 (UTC) (envelope-from ian@dijix.com) Received: from smtp2.mail.stackcp.net ([10.4.72.76] helo=smtp2.n4.stackcp.net) by relay1.stackmail.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jOmst-0008Ac-BX for freebsd-stable@freebsd.org; Wed, 15 Apr 2020 19:35:39 +0100 Received: from 156.91.90.146.dyn.plus.net ([146.90.91.156] helo=[10.0.1.33]) by smtp2.n4.stackcp.net with esmtpa (Exim 4.92.3) (envelope-from ) id 1jOmss-0001f1-T5 for freebsd-stable@freebsd.org; Wed, 15 Apr 2020 19:35:39 +0100 From: ian@dijix.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Subject: Issue with gpart "Device Busy" Message-Id: <3BF9F702-81FD-4156-B6A2-E32C549ACA90@dijix.com> Date: Wed, 15 Apr 2020 19:35:30 +0100 To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.3445.104.14) X-Authenticated-Sender: ian@dijix.com X-Scan-Signature: 75756f6eedebadc553e53682dba89094 X-Rspamd-Queue-Id: 492WJL67sGz4CvZ X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of ian@dijix.com has no SPF policy when checking 185.151.28.65) smtp.mailfrom=ian@dijix.com X-Spamd-Result: default: False [4.05 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dijix.com]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(0.76)[ipnet: 185.151.28.0/24(1.75), asn: 31727(2.14), country: GB(-0.07)]; NEURAL_SPAM_MEDIUM(0.91)[0.914,0]; NEURAL_SPAM_LONG(0.97)[0.968,0]; FROM_NO_DN(0.00)[]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:31727, ipnet:185.151.28.0/24, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; HAS_X_AS(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[156.91.90.146.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 18:35:47 -0000 I have an issue with gpart, it will not let me delete partition ada0p2 = responding with =E2=80=9CDevice Busy=E2=80=9D The man page gpart(8) says this may be shown if a partition exists but I = cannot seem to delete partition 2 in my case via gpart delete or gpart = destroy=20 This is a used disk but new to the machine, I can modify the partition = type and create partitions before and after partition 2 but I cannot = delete it. Here=E2=80=99s what I have tried so far: root@beastie:~ # gpart show =3D> 34 1250263661 ada0 GPT (596G) 34 409606 - free - (200M) 409640 1249591904 2 freebsd-ufs (596G) 1250001544 262151 - free - (128M) =3D> 40 976773088 ada1 GPT (466G) 40 1024 1 freebsd-boot (512K) 1064 984 - free - (492K) 2048 4194304 2 freebsd-swap (2.0G) 4196352 972576768 3 freebsd-zfs (464G) 976773120 8 - free - (4.0K) root@beastie:~ # gpart delete -i2 ada0 gpart: Device busy root@beastie:~ # gpart add -t freebsd-boot ada0 ada0p1 added root@beastie:~ # gpart show =3D> 34 1250263661 ada0 GPT (596G) 34 409606 1 freebsd-boot (200M) 409640 1249591904 2 freebsd-ufs (596G) 1250001544 262151 - free - (128M) =3D> 40 976773088 ada1 GPT (466G) 40 1024 1 freebsd-boot (512K) 1064 984 - free - (492K) 2048 4194304 2 freebsd-swap (2.0G) 4196352 972576768 3 freebsd-zfs (464G) 976773120 8 - free - (4.0K) root@beastie:~ # gpart delete -i2 ada0 gpart: Device busy root@beastie:~ # gpart delete -i1 ada0 ada0p1 deleted root@beastie:~ # gpart show =3D> 34 1250263661 ada0 GPT (596G) 34 409606 - free - (200M) 409640 1249591904 2 freebsd-ufs (596G) 1250001544 262151 - free - (128M) =3D> 40 976773088 ada1 GPT (466G) 40 1024 1 freebsd-boot (512K) 1064 984 - free - (492K) 2048 4194304 2 freebsd-swap (2.0G) 4196352 972576768 3 freebsd-zfs (464G) 976773120 8 - free - (4.0K) root@beastie:~ # gpart destroy -F ada0 gpart: Device busy root@beastie:~ # gpart modify -i2 -t freebsd-boot ada0 ada0p2 modified root@beastie:~ # gpart show =3D> 34 1250263661 ada0 GPT (596G) 34 409606 - free - (200M) 409640 1249591904 2 freebsd-boot (596G) 1250001544 262151 - free - (128M) =3D> 40 976773088 ada1 GPT (466G) 40 1024 1 freebsd-boot (512K) 1064 984 - free - (492K) 2048 4194304 2 freebsd-swap (2.0G) 4196352 972576768 3 freebsd-zfs (464G) 976773120 8 - free - (4.0K) I=E2=80=99m not sure where to go from here, I=E2=80=99m tempted to pull = the drive and reformat elsewhere I have all tried dd=E2=80=99ing the disk as root but dd /dev/ada0 errors = with unauthorised. Am I missing something obvious? From owner-freebsd-stable@freebsd.org Wed Apr 15 20:21:32 2020 Return-Path: Delivered-To: freebsd-stable@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 4467A2C1022; Wed, 15 Apr 2020 20:21:32 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward103o.mail.yandex.net (forward103o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::606]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 492YfK5H1Wz4Lyl; Wed, 15 Apr 2020 20:21:29 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward501o.mail.yandex.net (forward501o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::611]) by forward103o.mail.yandex.net (Yandex) with ESMTP id 4208D5F8320A; Wed, 15 Apr 2020 23:21:11 +0300 (MSK) Received: from mxback24o.mail.yandex.net (mxback24o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::75]) by forward501o.mail.yandex.net (Yandex) with ESMTP id 3EACF1E80002; Wed, 15 Apr 2020 23:21:11 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback24o.mail.yandex.net (mxback/Yandex) with ESMTP id DIwk9NYhfE-LA2S1Nra; Wed, 15 Apr 2020 23:21:10 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfw.ru; s=mail; t=1586982070; bh=pcnmyfi5q3HAMA53d7VJPHEH6EjFCQiuew2bY/lFFC8=; h=Message-Id:Cc:Subject:In-Reply-To:Date:References:To:From; b=cKmyl/jtOeyU7W0titJHlwzJpZoXtxvNdNC+PcrsWiw84mXhxbY4PhcnXFas3sUM0 hdfN1pj4ZFMHWU/2I4LZ9B/pWwFiwMbeRj0CIeN9vYSOumPm5e8S5X86FnqzQ2aWYc GA0fNVnuk6de2MIPE3itCUSd7V3zGnPVvUDvANEc= Received: by myt2-c3952fd46804.qloud-c.yandex.net with HTTP; Wed, 15 Apr 2020 23:21:10 +0300 From: Alexander V. Chernikov To: Kristof Provost , "freebsd-testing@freebsd.org" Cc: "freebsd-current@freebsd.org" , "freebsd-stable@freebsd.org" , "bofh@freebsd.org" , =?utf-8?B?T2xpdmllciBDb2NoYXJkLUxhYmLDqQ==?= In-Reply-To: References: <20200414223710.GB33328@freefall.freebsd.org> Subject: Re: FreeBSD CI Weekly Report 2020-04-12 MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Wed, 15 Apr 2020 21:21:10 +0100 Message-Id: <885331586982061@myt5-bc0f9d8e5f27.qloud-c.yandex.net> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 X-Rspamd-Queue-Id: 492YfK5H1Wz4Lyl X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ipfw.ru header.s=mail header.b=cKmyl/jt; dmarc=none; spf=pass (mx1.freebsd.org: domain of melifaro@ipfw.ru designates 2a02:6b8:0:1a2d::606 as permitted sender) smtp.mailfrom=melifaro@ipfw.ru X-Spamd-Result: default: False [-6.16 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[ipfw.ru:s=mail]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a02:6b8:0:1000::/52]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[ipfw.ru]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_FIVE(0.00)[6]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; DKIM_TRACE(0.00)[ipfw.ru:+]; RCVD_IN_DNSWL_NONE(0.00)[6.0.6.0.0.0.0.0.0.0.0.0.0.0.0.0.d.2.a.1.0.0.0.0.8.b.6.0.2.0.a.2.list.dnswl.org : 127.0.5.0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:13238, ipnet:2a02:6b8::/32, country:RU]; IP_SCORE(-3.66)[ip: (-9.72), ipnet: 2a02:6b8::/32(-4.76), asn: 13238(-3.85), country: RU(0.01)] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 20:21:32 -0000 15.04.2020, 15:10, "Kristof Provost" : > On 15 Apr 2020, at 15:34, Kristof Provost wrote: >>  On 15 Apr 2020, at 0:37, Li-Wen Hsu wrote: >>>  (Please send the followup to freebsd-testing@ and note Reply-To is >>>  set.) >>> >>>  FreeBSD CI Weekly Report 2020-04-12 >>>  =================================== >>> >>>  Here is a summary of the FreeBSD Continuous Integration results for >>>  the period >>>  from 2020-04-06 to 2020-04-12. >>> >>>  During this period, we have: >>> >>>  * 1801 builds (94.0% (+0.4) passed, 6.0% (-0.4) failed) of buildworld >>>  and >>>    buildkernel (GENERIC and LINT) were executed on aarch64, amd64, >>>  armv6, >>>    armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, >>>    sparc64 architectures for head, stable/12, stable/11 branches. >>>  * 288 test runs (25.1% (-24.6) passed, 29.9% (+10.6) unstable, 45.1% >>>  (+14.1) >>>    exception) were executed on amd64, i386, riscv64 architectures for >>>  head, >>>    stable/12, stable/11 branches. >>>  * 30 doc and www builds (83.3% (-1.3) passed, 16.7% (+1.3) failed) >>> >>>  Test case status (on 2020-04-12 23:59): >>>  | Branch/Architecture | Total | Pass | Fail | Skipped >>>  | >>>  | ------------------- | --------- | ---------- | -------- | -------- >>>  | >>>  | head/amd64 | 7744 (+4) | 7638 (+19) | 14 (+5) | 92 (-20) >>>  | >>>  | head/i386 | 7742 (+4) | 7628 (+15) | 16 (+5) | 98 (-16) >>>  | >>>  | 12-STABLE/amd64 | 7508 (0) | 7449 (-3) | 1 (+1) | 58 (+2) >>>  | >>>  | 12-STABLE/i386 | 7506 (0) | 7425 (-17) | 2 (+2) | 79 (+15) >>>  | >>>  | 11-STABLE/amd64 | 6882 (0) | 6829 (-6) | 1 (+1) | 52 (+5) >>>  | >>>  | 11-STABLE/i386 | 6880 (0) | 6749 (-82) | 80 (+80) | 51 (+2) >>>  | >>> >>>  (The statistics from experimental jobs are omitted) >>> >>>  If any of the issues found by CI are in your area of interest or >>>  expertise >>>  please investigate the PRs listed below. >>> >>>  The latest web version of this report is available at >>>  https://hackmd.io/@FreeBSD-CI/report-20200412 and archive is >>>  available at >>>  https://hackmd.io/@FreeBSD-CI/ , any help is welcome. >>> >>>  ## News >>> >>>  * The test env now loads the required module for firewall tests. >>> >>>  * New armv7 job is added (to replace armv6 one): >>>    * FreeBSD-head-armv7-testvm >>>    The images are available at https://artifact.ci.freebsd.org >>>    FreeBSD-head-armv7-test is ready but needs test env update. >>> >>>  ## Failing jobs >>> >>>  * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ >>>    * See console log for the error details. >>> >>>  ## Failing tests >>> >>>  * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/ >>>    * local.kyua.integration.cmd_about_test.topic__authors__installed >>>    * sys.netipsec.tunnel.empty.v4 >>>    * sys.netipsec.tunnel.empty.v6 >>>    * sys.netpfil.common.forward.ipf_v4 >>>    * sys.netpfil.common.forward.ipfw_v4 >>>    * sys.netpfil.common.forward.pf_v4 >>>    * sys.netpfil.common.tos.ipfw_tos >>>    * sys.netpfil.common.tos.pf_tos >>>    * sys.netpfil.pf.forward.v4 >>  I can’t actually reproduce this failure in my test VM, but with the >>  ci test VM I can reproduce the problem. >>  It’s not related to pf, because the sanity check ping we do before >>  we set up pf already fails. >>  Or rather pft_ping.py sends an incorrect packet, because `ping` does >>  get the packet to go where it’s supposed to go. >> >>  Scapy seems to fail to find the source IP address, so we get this: >> >>          12:12:22.152652 IP 0.0.0.0 > 198.51.100.3: ICMP echo request, id 0, >>  seq 0, length 12 >> >>  I have a vague recollection that we’ve seem this problem before, but >>  I can’t remember what we did about it. >> >>  In all likelihood most of the other netpfil tests fail for exactly the >>  same reason. > > The problem appears to be that > /usr/local/lib/python3.7/site-packages/scapy/arch/unix.py is misparsing > the `netstat -rnW` output. Thanks for the analysis! Sorry for breaking the tests. I should have run tests with userland changes installed. I'll revert the netstat output changes shortly to unbreak the tests. Re longer-term: parsing textual output for the routes does not seem to be a good habit, especially in these days. Structural (libxo) approach looks better, however I guess this will make scapy unusable on the routers with full-view. So far light-weight sysctl-route reader looks like the best option. What do you folks think? > > For reference, this is the output in the test VM: > >         Routing tables > >         Internet: >         Destination Gateway Flags Nhop# Mtu Netif > Expire >         127.0.0.1 link#2 UH 1 16384 lo0 >         192.0.2.0/24 link#4 U 2 1500 epair0a >         192.0.2.1 link#4 UHS 1 16384 lo0 >         198.51.100.0/24 192.0.2.2 UGS 3 1500 epair0a > >         Internet6: >         Destination Gateway Flags > Nhop# Mtu Netif Expire >         ::/96 ::1 UGRS >      4 16384 lo0 >         ::1 link#2 UH >      1 16384 lo0 >         ::ffff:0.0.0.0/96 ::1 UGRS >      4 16384 lo0 >         fe80::/10 ::1 UGRS >      4 16384 lo0 >         fe80::%lo0/64 link#2 U >      3 16384 lo0 >         fe80::1%lo0 link#2 UHS >      2 16384 lo0 >         fe80::%epair0a/64 link#4 U >      5 1500 epair0a >         fe80::3d:9dff:fe7c:d70a%epair0a link#4 UHS >      1 16384 lo0 >         fe80::%epair1a/64 link#6 U >      6 1500 epair1a >         fe80::37:9eff:fe03:250a%epair1a link#6 UHS >      1 16384 lo0 >         ff02::/16 ::1 UGRS >      4 16384 lo0 > > The parsing code seems to think that the netif for the 198.51.100.0/24 > route is 1500 rather than epair0a. > This may be related to the difference in netstat output, because on my > VM it looks like this: > >         Routing tables > >         Internet: >         Destination Gateway Flags Use Mtu Netif > Expire >         default 172.16.2.1 UGS 319 1500 vtnet0 >         127.0.0.1 link#2 UH 0 16384 lo0 >         172.16.2.0/24 link#1 U 14 1500 vtnet0 >         172.16.2.2 link#1 UHS 0 16384 lo0 > >         Internet6: >         Destination Gateway Flags >      Use Mtu Netif Expire >         ::/96 ::1 UGRS >        0 16384 lo0 >         ::1 link#2 UH >        0 16384 lo0 >         ::ffff:0.0.0.0/96 ::1 UGRS >        0 16384 lo0 >         fe80::/10 ::1 UGRS >        0 16384 lo0 >         fe80::%vtnet0/64 link#1 U >        0 1500 vtnet0 >         fe80::5a9c:fcff:fe02:a95e%vtnet0 link#1 UHS >        0 16384 lo0 >         fe80::%lo0/64 link#2 U >        0 16384 lo0 >         fe80::1%lo0 link#2 UHS >        0 16384 lo0 >         ff02::/16 ::1 UGRS >        0 16384 lo0 > > I suspect that this change was introduced in r359823 (Introduce nexthop > objects and new routing KPI). > > Best regards, > Kristof > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Thu Apr 16 01:56:49 2020 Return-Path: Delivered-To: freebsd-stable@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 CCB282AA768 for ; Thu, 16 Apr 2020 01:56:49 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 492j5D0tJQz3Gj8 for ; Thu, 16 Apr 2020 01:56:47 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-qk1-x72b.google.com with SMTP id b62so19802361qkf.6 for ; Wed, 15 Apr 2020 18:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=qfXvIEzqCYsRvLDAgjy8g+MA8wS2QTaP0iopW1ULNSo=; b=AbO7N/AIF7kpN+r+cM8/2Mfu6lbSS8siJx8GKDsQW5ESkDRxqYnQu98/oSN/ONha45 nTacqFkrSF9HL+njt6HqX4zzkoLMQwQ2yX5wB2duc26aqkLK7jAh5hus/qRxkrvBH/Rw 0+eXBdIBlHshBqQGvLJ8utZwq/5UvL2cazxgAhzqI8Vze09BGhcYW0kbKnD7EETsbTPz KMeYDb4vM5BukQ0ZrqntVsGqRWDk/n/CS3xllUa0upgSG7Mv9P5exLs05shYHMiyRo5p Zonl1GLHz6bHt9U8C6kBEcG8kybx3IYwkes72BUzuLX8AbbtOZSPbazyvcBL6BLo+4vx 2S9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=qfXvIEzqCYsRvLDAgjy8g+MA8wS2QTaP0iopW1ULNSo=; b=Hv3bLxUz+5OOW97vZbiMabRnDAsjrLXn0HwERncHTADAId6qLbIdpDrE1Zm/Nuf8+O QIWVtXsKwygH1VWT/aB0Ek0sQGMLZHV0ztlFXTnzR0GBWxTQRB/vKdOrWNC8CN1CKrOA H/o2ewG+kjqQzy9VspbaLe7kJ/VmXXwkdRw2Jw3FhRl5a1dGfsifr2lj6b32lxsYumr8 aQpojQZRXZqfgRnKv0DOwsmrYTiWhApvSZSOwRcOwmiok+mNVoCNLRHKsOydNPCXG6ah n21uRkiXFed8+2NWCnifY/H/EqukEsXxIv1oSDhsC9ygw7Lk/NLeP0qQVLdMem7BFA1c 2yaw== X-Gm-Message-State: AGi0Puaws38I21DAn2ux8Am3S76sAPV6GeHkgEVb5r4NTD9CQtHN2bMo /lSfeMX99HmTPVUyOYlz5x8GWALKs6FSjA== X-Google-Smtp-Source: APiQypKkxPGpQvB28ziIczA4Z3uAWjfZo+HKoxUAeDzyf2TFzDmXv3MJ9dpB9mIsK+sagMT3eeC2Jw== X-Received: by 2002:a05:620a:cc6:: with SMTP id b6mr22117974qkj.275.1587002205600; Wed, 15 Apr 2020 18:56:45 -0700 (PDT) Received: from [192.168.1.31] (ool-457b63be.dyn.optonline.net. [69.123.99.190]) by smtp.gmail.com with ESMTPSA id h63sm14005112qkf.125.2020.04.15.18.56.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Apr 2020 18:56:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Mark Saad Mime-Version: 1.0 (1.0) Subject: Re: CFT: if_bridge performance improvements Date: Wed, 15 Apr 2020 21:56:43 -0400 Message-Id: <467E538C-05C3-45B7-935B-FB20F6E20B01@longcount.org> References: <0C115843-FB05-40D7-B1D7-F9B7842E9B54@FreeBSD.org> Cc: freebsd-stable@freebsd.org In-Reply-To: <0C115843-FB05-40D7-B1D7-F9B7842E9B54@FreeBSD.org> To: Kristof Provost X-Mailer: iPhone Mail (17D50) X-Rspamd-Queue-Id: 492j5D0tJQz3Gj8 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=longcount-org.20150623.gappssmtp.com header.s=20150623 header.b=AbO7N/AI; dmarc=none; spf=none (mx1.freebsd.org: domain of nonesuch@longcount.org has no SPF policy when checking 2607:f8b0:4864:20::72b) smtp.mailfrom=nonesuch@longcount.org X-Spamd-Result: default: False [-3.82 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[longcount-org.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; 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)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[longcount.org]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[longcount-org.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[b.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)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-2.02)[ip: (-9.32), 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]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[190.99.123.69.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 01:56:49 -0000 Kristof=20 Up until a month ago I ran a set of FreeBSD based ap in my house and even l= ong ago at work . They were Pc engines apu =E2=80=98s or Alix=E2=80=99s with= one em/igb nic and one ath nic in a bridge . They worked well for a long t= ime however the need for more robust wifi setup caused me to swap them out w= ith cots aps from tp-link . The major issues were the lack of WiFi features= and standards that work oob on Linux based aps .=20 So I always wanted to experiment with ng_bridge vs if_bridge for the same ta= sk . But I never got around to it . Do you have any insight into using one v= s the other . Imho if_bridge is easier to setup and get working .=20 --- Mark Saad | nonesuch@longcount.org > On Apr 15, 2020, at 1:37 PM, Kristof Provost wrote: >=20 > =EF=BB=BFOn 15 Apr 2020, at 19:16, Mark Saad wrote: >> All >> Should this improve wifi to wired bridges in some way ? Has this been t= ested ? >>=20 > What sort of setup do you have to bridge wired and wireless? Is the FreeBS= D box also a wifi AP? >=20 > I=E2=80=99ve not done any tests involving wifi. >=20 > Best regards, > Kristof From owner-freebsd-stable@freebsd.org Thu Apr 16 06:34:54 2020 Return-Path: Delivered-To: freebsd-stable@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 047AE2B24DC; Thu, 16 Apr 2020 06:34:54 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 492qG46pXPz432X; Thu, 16 Apr 2020 06:34:52 +0000 (UTC) (envelope-from timp87@gmail.com) Received: by mail-wr1-x42c.google.com with SMTP id d27so3481431wra.1; Wed, 15 Apr 2020 23:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LPfmQUu0UfMQ1rR7YSThHDfoUkMef4LciOt0qUf53q0=; b=IGMb66aKbgpm5FADjd4DGNZX2t/fMKOXlSKQimI7jfve9Zx2NUeP96bnfm4eqsicLn L0ZoYANppc6Yagu6oHE1jvF3IX8EBNfpoQ4JFjs32KX5eXQR07ezuirVP63xaXapLijw 4fCT92PRh1lCcWtzOP3GRV4j4OaJe5WeNc/qLPMaIKhkM5q8ppTXMGLNkg53so9w8aCJ +YLsqBWGCCbYYJNoZF/G3z1WYpaNTpN6vAUk3Nix8FzU61kDks9oVGXuWKrYS9HXILAZ jOjOIUcDRHAjkvPO44cCS4jseowSq8MbiNwW0UCehgpyABL9RSeyOvI30U+gemI3uQsU nKWA== 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=LPfmQUu0UfMQ1rR7YSThHDfoUkMef4LciOt0qUf53q0=; b=GQEo/fV6jld56hvzViDnHOlU2L6mzp8NRopFEqJTs3EuR9kgC+RDmkAAEeTiKn9WCY OvSQr6g/4jwL5rHVsi8jutj1QOZ/IA/Q9S/k3CrBf7T++XtHVPlv3bioplfFoud1nIC6 mzpNJJvosRto03g7ugnMQjtGK7rdWmngdAS6+s2FHUsF8f/FV3djKQ83HV9Jxob3AupZ oNycaMBa0d7pBTwLrOM2zIOgLqcUBYe4jg9EmGkgp894kOTQE+4VfwsMqhbzYekkhSr+ 5wUOIlrCgGbZZTelXwu3sEmENOsOCceI84TP+ButRYknaS5z8CmRXd32jPmi64f/RkXw XB/g== X-Gm-Message-State: AGi0PuZx3IPGxSErdcc0zdIWuUbLCRLHBJwQ3MpuXj4UOh0kNs2gVtXI kOcgAs7JPuwP6E19SqLPzRWhXaNy2B1JP9Rp9Jfh9Q== X-Google-Smtp-Source: APiQypLCld7jAqOuX7lAP2nkn/81Spqa1jocBofXLPrTldVfhoS5zWO1HdPch1P1oLP21Jw658g7cAYrnY0t/SWKNJk= X-Received: by 2002:a5d:474b:: with SMTP id o11mr25202855wrs.391.1587018890418; Wed, 15 Apr 2020 23:34:50 -0700 (PDT) MIME-Version: 1.0 References: <5377E42E-4C01-4BCC-B934-011AC3448B54@FreeBSD.org> In-Reply-To: <5377E42E-4C01-4BCC-B934-011AC3448B54@FreeBSD.org> From: Pavel Timofeev Date: Thu, 16 Apr 2020 09:34:41 +0300 Message-ID: Subject: Re: CFT: if_bridge performance improvements To: Kristof Provost Cc: freebsd-current , freebsd-stable stable X-Rspamd-Queue-Id: 492qG46pXPz432X X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=IGMb66aK; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of timp87@gmail.com designates 2a00:1450:4864:20::42c as permitted sender) smtp.mailfrom=timp87@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; URI_COUNT_ODD(1.00)[9]; IP_SCORE(0.00)[ip: (-9.12), ipnet: 2a00:1450::/32(-2.35), asn: 15169(-0.43), country: US(-0.05)]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[c.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 06:34:54 -0000 =D0=B2=D1=82, 14 =D0=B0=D0=BF=D1=80. 2020 =D0=B3., 12:51 Kristof Provost : > Hi, > > Thanks to support from The FreeBSD Foundation I=E2=80=99ve been able to w= ork > on improving the throughput of if_bridge. > It changes the (data path) locking to use the NET_EPOCH infrastructure. > Benchmarking shows substantial improvements (x5 in test setups). > > This work is ready for wider testing now. > > It=E2=80=99s under review here: https://reviews.freebsd.org/D24250 > > Patch for CURRENT: https://reviews.freebsd.org/D24250?download=3Dtrue > Patches for stable/12: > https://people.freebsd.org/~kp/if_bridge/stable_12/ > > I=E2=80=99m not currently aware of any panics or issues resulting from th= ese > patches. > > Do note that if you run a Bhyve + tap on bridges setup the tap code > suffers from a similar bottleneck and you will likely not see major > improvements in single VM to host throughput. I would expect, but have > not tested, improvements in overall throughput (i.e. when multiple VMs > send traffic at the same time). > > Best regards, > Kristof > Hi! Thank you for your work! Do you know if epair suffers from the same issue as tap? > From owner-freebsd-stable@freebsd.org Thu Apr 16 07:41:52 2020 Return-Path: Delivered-To: freebsd-stable@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 288002B4365; Thu, 16 Apr 2020 07:41:52 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 492rlN0LQpz478X; Thu, 16 Apr 2020 07:41:52 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id E65781F43F; Thu, 16 Apr 2020 07:41:51 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 7331FF9F9; Thu, 16 Apr 2020 09:41:49 +0200 (CEST) From: "Kristof Provost" To: "Pavel Timofeev" Cc: freebsd-current , "freebsd-stable stable" Subject: Re: CFT: if_bridge performance improvements Date: Thu, 16 Apr 2020 09:41:48 +0200 X-Mailer: MailMate (1.13.1r5671) Message-ID: <5D021E5B-8B7C-4DF2-ABC7-415A1D0F0B62@FreeBSD.org> In-Reply-To: References: <5377E42E-4C01-4BCC-B934-011AC3448B54@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 07:41:52 -0000 On 16 Apr 2020, at 8:34, Pavel Timofeev wrote: > Hi! > Thank you for your work! > Do you know if epair suffers from the same issue as tap? > I’ve not tested it, but I believe that epair scales significantly better than tap. It has a per-cpu mutex (or more accurately, a mutex in each of its per-cpu structures), so I’d expect much better throughput from epair than you’d see from tap. Best regards, Kristof From owner-freebsd-stable@freebsd.org Thu Apr 16 07:44:54 2020 Return-Path: Delivered-To: freebsd-stable@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 B33FD2B48EC for ; Thu, 16 Apr 2020 07:44:54 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 492rpt4Jydz47gh; Thu, 16 Apr 2020 07:44:54 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 75B771F440; Thu, 16 Apr 2020 07:44:54 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 3EE15F97C; Thu, 16 Apr 2020 09:44:53 +0200 (CEST) From: "Kristof Provost" To: "Mark Saad" Cc: freebsd-stable@freebsd.org Subject: Re: CFT: if_bridge performance improvements Date: Thu, 16 Apr 2020 09:44:52 +0200 X-Mailer: MailMate (1.13.1r5671) Message-ID: <26AE78A9-551E-4118-9955-DABD9745B380@FreeBSD.org> In-Reply-To: <467E538C-05C3-45B7-935B-FB20F6E20B01@longcount.org> References: <0C115843-FB05-40D7-B1D7-F9B7842E9B54@FreeBSD.org> <467E538C-05C3-45B7-935B-FB20F6E20B01@longcount.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 07:44:54 -0000 Hi Mark, I wouldn’t expect these changes to make a difference in the performance of this setup. My work mostly affects setups with multi-core systems that see a lot of traffic. Even before these changes I’d expect the if_bridge code to saturate a wifi link easily. I also wouldn’t expect ng_bridge vs. if_bridge to make a significant difference in wifi features. Best regards, Kristof On 16 Apr 2020, at 3:56, Mark Saad wrote: > Kristof > Up until a month ago I ran a set of FreeBSD based ap in my house and > even long ago at work . They were Pc engines apu ‘s or Alix’s with > one em/igb nic and one ath nic in a bridge . They worked well for a > long time however the need for more robust wifi setup caused me to > swap them out with cots aps from tp-link . The major issues were the > lack of WiFi features and standards that work oob on Linux based aps . > > So I always wanted to experiment with ng_bridge vs if_bridge for the > same task . But I never got around to it . Do you have any insight > into using one vs the other . Imho if_bridge is easier to setup and > get working . > > > --- > Mark Saad | nonesuch@longcount.org > >> On Apr 15, 2020, at 1:37 PM, Kristof Provost wrote: >> >> On 15 Apr 2020, at 19:16, Mark Saad wrote: >>> All >>> Should this improve wifi to wired bridges in some way ? Has this >>> been tested ? >>> >> What sort of setup do you have to bridge wired and wireless? Is the >> FreeBSD box also a wifi AP? >> >> I’ve not done any tests involving wifi. >> >> Best regards, >> Kristof From owner-freebsd-stable@freebsd.org Thu Apr 16 08:38:56 2020 Return-Path: Delivered-To: freebsd-stable@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 4125D2B66F4 for ; Thu, 16 Apr 2020 08:38:56 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from smtpq5.tb.mail.iss.as9143.net (smtpq5.tb.mail.iss.as9143.net [212.54.42.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 492t1C511Sz4CM6 for ; Thu, 16 Apr 2020 08:38:55 +0000 (UTC) (envelope-from peter.blok@bsd4all.org) Received: from [212.54.42.135] (helo=smtp11.tb.mail.iss.as9143.net) by smtpq5.tb.mail.iss.as9143.net with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jP02w-0005ZL-8T for freebsd-stable@freebsd.org; Thu, 16 Apr 2020 10:38:54 +0200 Received: from 94-209-85-88.cable.dynamic.v4.ziggo.nl ([94.209.85.88] helo=wan0.bsd4all.org) by smtp11.tb.mail.iss.as9143.net with esmtp (Exim 4.90_1) (envelope-from ) id 1jP02w-0002c4-4H for freebsd-stable@freebsd.org; Thu, 16 Apr 2020 10:38:54 +0200 Received: from newnas.bsd4all.local (localhost [127.0.0.1]) by wan0.bsd4all.org (Postfix) with ESMTP id BFFE5212 for ; Thu, 16 Apr 2020 10:38:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at bsd4all.org Received: from wan0.bsd4all.org ([127.0.0.1]) by newnas.bsd4all.local (newnas.bsd4all.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XU0s40zXBTJt for ; Thu, 16 Apr 2020 10:38:52 +0200 (CEST) Received: from [192.168.1.65] (unknown [192.168.1.65]) by wan0.bsd4all.org (Postfix) with ESMTPSA id B7711211 for ; Thu, 16 Apr 2020 10:38:52 +0200 (CEST) From: peter.blok@bsd4all.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Subject: Re: CFT: if_bridge performance improvements Date: Thu, 16 Apr 2020 10:38:52 +0200 In-Reply-To: <26AE78A9-551E-4118-9955-DABD9745B380@FreeBSD.org> Cc: FreeBSD Stable References: <0C115843-FB05-40D7-B1D7-F9B7842E9B54@FreeBSD.org> <467E538C-05C3-45B7-935B-FB20F6E20B01@longcount.org> <26AE78A9-551E-4118-9955-DABD9745B380@FreeBSD.org> Message-Id: <95EF05A2-5193-4BF0-A775-021819ABD961@bsd4all.org> X-Mailer: Apple Mail (2.3445.104.14) X-SourceIP: 94.209.85.88 X-Ziggo-spambar: / X-Ziggo-spamscore: 0.0 X-Ziggo-spamreport: CMAE Analysis: v=2.3 cv=du1A92o4 c=1 sm=1 tr=0 a=LYXyOGYQqFYBMgK+Y6iqTg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=9cW_t1CCXrUA:10 a=IkcTkHD0fZMA:10 a=cl8xLZFz6L8A:10 a=6I5d2MoRAAAA:8 a=AJXH2NDoAAAA:8 a=u47AiZt3kLW6PT0XFisA:9 a=QEXdDO2ut3YA:10 a=IjZwj45LgO3ly-622nXo:22 a=uCuhrRYJh29-2kTIydwK:22 X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No X-Rspamd-Queue-Id: 492t1C511Sz4CM6 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of peter.blok@bsd4all.org designates 212.54.42.168 as permitted sender) smtp.mailfrom=peter.blok@bsd4all.org X-Spamd-Result: default: False [-2.76 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; RECEIVED_SPAMHAUS_PBL(0.00)[88.85.209.94.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; RCVD_TLS_LAST(0.00)[]; R_SPF_ALLOW(-0.20)[+a:smtp.ziggo.nl/16]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[bsd4all.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.99)[-0.992,0]; IP_SCORE(-2.90)[ip: (-8.00), ipnet: 212.54.32.0/20(-4.07), asn: 33915(-2.44), country: NL(0.03)]; TO_DN_ALL(0.00)[]; FROM_NO_DN(0.00)[]; MISSING_TO(2.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.975,0]; RCVD_IN_DNSWL_LOW(-0.10)[168.42.54.212.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:33915, ipnet:212.54.32.0/20, country:NL]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 08:38:56 -0000 Hi Mark/Kristof, I have been using ng_bridge for more than a year. It was very stable and = it allowed to have members with different MTU. My jails were using jng = to setup the bridge and I changed iohyve to use ng_bridge. But I recently switched to if_bridge. I needed to have pf work on a = member interface, which wasn=E2=80=99t easy with ng_bridge. It was not = easy to make it work due to two members (VLAN) coming frome the same = trunk.The behavior was erratic. I have a trusted VLAN bridged to an untrusted physical and Wifi network. = All members are on the same IP segment, but with pf I can make sure that = the untrusted IOT devices are only able to go outside towards the = internet. The untrusted devices can=E2=80=99t create connections to the = trusted devices, but the trusted devices can create connections to the = untrusted devices. Another issue I found with pf was with "set skip on bridge=E2=80=9D. It = doesn=E2=80=99t work on the interface group, unless a bridge exists = prior to enabling pf. Makes sense, but I didn=E2=80=99t think of it. = Other rules work fine with interface groups. My jails and bhyve now runs fine with if_bridge, which is easier to = setup and I don=E2=80=99t need any changes in iohyve. Peter=20 > On 16 Apr 2020, at 09:44, Kristof Provost wrote: >=20 > Hi Mark, >=20 > I wouldn=E2=80=99t expect these changes to make a difference in the = performance of this setup. > My work mostly affects setups with multi-core systems that see a lot = of traffic. Even before these changes I=E2=80=99d expect the if_bridge = code to saturate a wifi link easily. >=20 > I also wouldn=E2=80=99t expect ng_bridge vs. if_bridge to make a = significant difference in wifi features. >=20 > Best regards, > Kristof >=20 > On 16 Apr 2020, at 3:56, Mark Saad wrote: >=20 >> Kristof >> Up until a month ago I ran a set of FreeBSD based ap in my house and = even long ago at work . They were Pc engines apu =E2=80=98s or Alix=E2=80=99= s with one em/igb nic and one ath nic in a bridge . They worked well = for a long time however the need for more robust wifi setup caused me to = swap them out with cots aps from tp-link . The major issues were the = lack of WiFi features and standards that work oob on Linux based aps . >>=20 >> So I always wanted to experiment with ng_bridge vs if_bridge for the = same task . But I never got around to it . Do you have any insight into = using one vs the other . Imho if_bridge is easier to setup and get = working . >>=20 >>=20 >> --- >> Mark Saad | nonesuch@longcount.org >>=20 >>> On Apr 15, 2020, at 1:37 PM, Kristof Provost wrote: >>>=20 >>> =EF=BB=BFOn 15 Apr 2020, at 19:16, Mark Saad wrote: >>>> All >>>> Should this improve wifi to wired bridges in some way ? Has this = been tested ? >>>>=20 >>> What sort of setup do you have to bridge wired and wireless? Is the = FreeBSD box also a wifi AP? >>>=20 >>> I=E2=80=99ve not done any tests involving wifi. >>>=20 >>> Best regards, >>> Kristof > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Thu Apr 16 08:42:06 2020 Return-Path: Delivered-To: freebsd-stable@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 8EE372B6A0D for ; Thu, 16 Apr 2020 08:42:06 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 492t4t391Rz4CkX; Thu, 16 Apr 2020 08:42:06 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 530C31FBA8; Thu, 16 Apr 2020 08:42:06 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id E4286FCE5; Thu, 16 Apr 2020 10:42:04 +0200 (CEST) From: "Kristof Provost" To: "Peter Blok" Cc: "Mark Saad" , "FreeBSD Stable" Subject: Re: CFT: if_bridge performance improvements Date: Thu, 16 Apr 2020 10:42:04 +0200 X-Mailer: MailMate (1.13.1r5671) Message-ID: <1221DD1E-2E38-4C25-88EF-CE911E7C32AF@FreeBSD.org> In-Reply-To: References: <0C115843-FB05-40D7-B1D7-F9B7842E9B54@FreeBSD.org> <467E538C-05C3-45B7-935B-FB20F6E20B01@longcount.org> <26AE78A9-551E-4118-9955-DABD9745B380@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 08:42:06 -0000 On 16 Apr 2020, at 10:36, Peter Blok wrote: > Another issue I found with pf was with "set skip on bridge”. It > doesn’t work on the interface group, unless a bridge exists prior to > enabling pf. Makes sense, but I didn’t think of it. Other rules work > fine with interface groups. > I am aware of this problem and have unfinished work to fix it. No promises about a timeline though. Best regards, Kristof From owner-freebsd-stable@freebsd.org Thu Apr 16 09:31:51 2020 Return-Path: Delivered-To: freebsd-stable@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 93C6B2B7B58 for ; Thu, 16 Apr 2020 09:31:51 +0000 (UTC) (envelope-from david.marec@davenulle.org) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 492vBG3v9Bz4G6h for ; Thu, 16 Apr 2020 09:31:50 +0000 (UTC) (envelope-from david.marec@davenulle.org) X-Originating-IP: 86.201.44.116 Received: from llanura.davidmarec.ddns.net (lfbn-tou-1-196-116.w86-201.abo.wanadoo.fr [86.201.44.116]) (Authenticated sender: david@dmarec.fr) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id CCC9FFF811 for ; Thu, 16 Apr 2020 09:31:46 +0000 (UTC) To: freebsd-stable@freebsd.org From: David Marec Subject: What was the intention about "jail -e" in the first place ? Message-ID: <158a9402-eac6-90ed-7931-3477f1374c3e@davenulle.org> Date: Thu, 16 Apr 2020 11:31:46 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------E1354458253F9E35C3C68FF2" Content-Language: en-US X-Rspamd-Queue-Id: 492vBG3v9Bz4G6h X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of david.marec@davenulle.org has no SPF policy when checking 217.70.183.199) smtp.mailfrom=david.marec@davenulle.org X-Spamd-Result: default: False [-1.31 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_XOIP(0.00)[]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[116.44.201.86.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; IP_SCORE(-1.35)[ip: (-3.91), ipnet: 217.70.176.0/20(-1.56), asn: 29169(-1.26), country: FR(0.00)]; R_DKIM_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[199.183.70.217.list.dnswl.org : 127.0.5.1]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.94)[-0.943,0]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.82)[-0.823,0]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DMARC_NA(0.00)[davenulle.org]; R_SPF_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 09:31:51 -0000 This is a multi-part message in MIME format. --------------E1354458253F9E35C3C68FF2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit The manpage and usage output doesn't match. The manpage tells us that this option should be used alone on the command line, as any other command will be discarded. The usage ouput does not mention the "-r" flag but "cmr" (with a typo). Both suggest that the user can request information about one single jail, or all the jails using a wildcard or no other argument. Well, looking at the code, it sounds that the only way to make it work is to use it alone on the command line, and their is no way get information about a single jail. Attached is a short patch to get information about one single jail or all jails (wildcards or empty). But,how was "jail -e" intending to be used, actually ? -- David Marec https://lapinbilly.eu/ --------------E1354458253F9E35C3C68FF2 Content-Type: text/x-patch; charset=UTF-8; name="jail.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="jail.patch" Index: jail.c =================================================================== --- jail.c (revision 359745) +++ jail.c (working copy) @@ -282,16 +282,12 @@ ? NULL : "false"); } } - } else if (op == JF_STOP || op == JF_SHOW) { - /* Just print list of all configured non-wildcard jails */ - if (op == JF_SHOW) { - load_config(); - show_jails(); - exit(0); - } + } else if (op == JF_STOP ) { + /* Jail remove, perhaps using the config file */ if (!docf || argc == 0) usage(); + if (!Rflag) for (i = 0; i < argc; i++) if (strchr(argv[i], '=')) @@ -300,6 +296,17 @@ (!strcmp(cfname, "-") || stat(cfname, &st) == 0))) load_config(); note_remove = docf || argc > 1 || wild_jail_name(argv[0]); + } else if(op == JF_SHOW) { + /* Just print list of all configured non-wildcard jails */ + if (op == JF_SHOW && (argc==0|| wild_jail_name(argv[0]))) { + load_config(); + show_jails(); + exit(0); + } + + if(argc>1) + usage(); + load_config(); } else if (argc > 1 || (argc == 1 && strchr(argv[0], '='))) { /* Single jail specified on the command line */ if (Rflag) @@ -474,6 +481,9 @@ dep_done(j, 0); break; + case JF_SHOW: + print_jail(stdout, j, 0, 0); + break; case JF_STOP: case JF_RESTART: if (j->comparam == NULL) { @@ -1040,8 +1050,8 @@ (void)fprintf(stderr, "usage: jail [-dhilqv] [-J jid_file] [-u username] [-U username]\n" " -[cmr] param=value ... [command=command ...]\n" - " jail [-dqv] [-f file] [-e separator] -[cmr] [jail]\n" - " jail [-qv] [-f file] -[rR] ['*' | jail ...]\n" + " jail [-dqv] [-f file] [-e separator] [-cmr] [jail]\n" + " jail [-qv] [-f file] [-rR] ['*' | jail ...]\n" " jail [-dhilqv] [-J jid_file] [-u username] [-U username]\n" " [-n jailname] [-s securelevel]\n" " path hostname [ip[,...]] command ...\n"); Index: jailp.h =================================================================== --- jailp.h (revision 359745) +++ jailp.h (working copy) @@ -69,7 +69,7 @@ #define JF_FROM_RUNQ 0x0800 /* Has already been on the run queue */ #define JF_SHOW 0x1000 /* -e Exhibit list of configured jails */ -#define JF_OP_MASK (JF_START | JF_SET | JF_STOP) +#define JF_OP_MASK (JF_START | JF_SET | JF_STOP | JF_SHOW) #define JF_RESTART (JF_START | JF_STOP) #define JF_START_SET (JF_START | JF_SET) #define JF_SET_RESTART (JF_SET | JF_STOP) --------------E1354458253F9E35C3C68FF2-- From owner-freebsd-stable@freebsd.org Thu Apr 16 14:22:46 2020 Return-Path: Delivered-To: freebsd-stable@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 5EE2F2BDC60 for ; Thu, 16 Apr 2020 14:22:46 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4931dw6t7Sz4X9t for ; Thu, 16 Apr 2020 14:22:44 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 03GEMWlO042192 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Apr 2020 14:22:33 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: david.marec@davenulle.org Received: from [10.58.0.10] (dadv@dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id 03GEMRa6008829 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Apr 2020 21:22:27 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: What was the intention about "jail -e" in the first place ? To: David Marec , freebsd-stable@freebsd.org References: <158a9402-eac6-90ed-7931-3477f1374c3e@davenulle.org> From: Eugene Grosbein Message-ID: Date: Thu, 16 Apr 2020 21:22:22 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <158a9402-eac6-90ed-7931-3477f1374c3e@davenulle.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4931dw6t7Sz4X9t X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-2.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-1.89)[ip: (-5.21), ipnet: 2a01:4f8::/29(-2.62), asn: 24940(-1.59), country: DE(-0.02)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 14:22:46 -0000 16.04.2020 16:31, David Marec wrote: > The manpage and usage output doesn't match. > > The manpage tells us that this option should be used alone on the command line, as any other command will be discarded. > > The usage ouput does not mention the "-r" flag but "cmr" (with a typo). > > Both suggest that the user can request information about one single jail, or all the jails using a wildcard or no other argument. > > Well, looking at the code, it sounds that the only way to make it work is to use it alone on the command line, and their is no way get information about a single jail. > > Attached is a short patch to get information about one single jail or all jails (wildcards or empty). > > > But,how was "jail -e" intending to be used, actually ? "jail -e" mode is used by periodic/weekly/340.noid script to differentiate parts of mounted file trees belonging to the host and to the configured full-blown jails, no matter started or not. This is documentation ambiguity as "jail -e" was not intended to take jail name as additional argument. Do you have any real use case this addition? From owner-freebsd-stable@freebsd.org Thu Apr 16 15:02:20 2020 Return-Path: Delivered-To: freebsd-stable@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 6FC2B2BEB82 for ; Thu, 16 Apr 2020 15:02:20 +0000 (UTC) (envelope-from david.marec@davenulle.org) Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4932Wb0g28z4bBP for ; Thu, 16 Apr 2020 15:02:18 +0000 (UTC) (envelope-from david.marec@davenulle.org) X-Originating-IP: 86.201.44.116 Received: from llanura.davidmarec.ddns.net (lfbn-tou-1-196-116.w86-201.abo.wanadoo.fr [86.201.44.116]) (Authenticated sender: david@dmarec.fr) by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id 9A3F9240010 for ; Thu, 16 Apr 2020 15:02:16 +0000 (UTC) Subject: Re: What was the intention about "jail -e" in the first place ? To: freebsd-stable@freebsd.org References: <158a9402-eac6-90ed-7931-3477f1374c3e@davenulle.org> From: David Marec Message-ID: Date: Thu, 16 Apr 2020 17:02:16 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4932Wb0g28z4bBP X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of david.marec@davenulle.org has no SPF policy when checking 217.70.183.193) smtp.mailfrom=david.marec@davenulle.org X-Spamd-Result: default: False [-1.24 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_XOIP(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[193.183.70.217.rep.mailspike.net : 127.0.0.18]; TO_DN_NONE(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[116.44.201.86.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; IP_SCORE(-1.19)[ip: (-3.12), ipnet: 217.70.176.0/20(-1.56), asn: 29169(-1.26), country: FR(0.00)]; R_DKIM_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[193.183.70.217.list.dnswl.org : 127.0.5.1]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.961,0]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.89)[-0.890,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[davenulle.org]; R_SPF_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 15:02:20 -0000 Le 16/04/2020 16:22, Eugene Grosbein a crit : >> But,how was "jail -e" intending to be used, actually ? > > "jail -e" mode is used by periodic/weekly/340.noid script to differentiate parts of mounted file trees > belonging to the host and to the configured full-blown jails, no matter started or not. > > This is documentation ambiguity as "jail -e" was not intended to take jail name as additional argument. Oh, I had a deeper look at the "-e" section of the man page where this statement is clear enough.Thanks. > Do you have any real use case this addition? No, not a case in the real world. I was just playing around with jails on a server and tried to get the ip4 field of a specific one to make sure it was set to 'inherit'. P.-S.: However, I had time to write a short patch (attached to the email) to make it work with a jail list as arguments. ( and that do not change the header file anymore ) This one also add a dedicated line for the "-e" command and fix few typos in the usage() output. // To improve the lookup in the nested loop, I first called "TAILQ REMOVE" on jailnames when found but this would produce errors if the user add more than once the same name in the list .// Regards, -- David Marec https://diablotins.lapinbilly.eu/doku.php?id=jails:zfs From owner-freebsd-stable@freebsd.org Thu Apr 16 17:44:50 2020 Return-Path: Delivered-To: freebsd-stable@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 A7AA02C2FD8 for ; Thu, 16 Apr 2020 17:44:50 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (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 4936746k3Gz3LHc for ; Thu, 16 Apr 2020 17:44:48 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id 03GHiaUv049319; Thu, 16 Apr 2020 19:44:36 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 384BADF8; Thu, 16 Apr 2020 19:44:36 +0200 (CEST) Subject: Re: Issue with gpart "Device Busy" To: ian@dijix.com, "freebsd-stable@freebsd.org >> freebsd-stable" References: <3BF9F702-81FD-4156-B6A2-E32C549ACA90@dijix.com> From: Harry Schmalzbauer Organization: OmniLAN Message-ID: <2a7532fd-6fee-deb6-c133-6150aaf1b8c2@omnilan.de> Date: Thu, 16 Apr 2020 19:44:35 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <3BF9F702-81FD-4156-B6A2-E32C549ACA90@dijix.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Thu, 16 Apr 2020 19:44:36 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-Rspamd-Queue-Id: 4936746k3Gz3LHc X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@omnilan.de designates 2a00:e10:2800::a130 as permitted sender) smtp.mailfrom=freebsd@omnilan.de X-Spamd-Result: default: False [-4.69 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[omnilan.de]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-2.39)[ip: (-9.21), ipnet: 2a00:e10:2800::/38(-4.58), asn: 61157(1.87), country: DE(-0.02)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:61157, ipnet:2a00:e10:2800::/38, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 17:44:50 -0000 Am 15.04.2020 um 20:35 schrieb ian@dijix.com: > I have an issue with gpart, it will not let me delete partition ada0p2 responding with “Device Busy” > The man page gpart(8) says this may be shown if a partition exists but I cannot seem to delete partition 2 in my case via gpart delete or gpart destroy > > This is a used disk but new to the machine, I can modify the partition type and create partitions before and after partition 2 but I cannot delete it. > > Here’s what I have tried so far: > > > root@beastie:~ # gpart show > => 34 1250263661 ada0 GPT (596G) > 34 409606 - free - (200M) > 409640 1249591904 2 freebsd-ufs (596G) > 1250001544 262151 - free - (128M) > > => 40 976773088 ada1 GPT (466G) > 40 1024 1 freebsd-boot (512K) > 1064 984 - free - (492K) > 2048 4194304 2 freebsd-swap (2.0G) > 4196352 972576768 3 freebsd-zfs (464G) > 976773120 8 - free - (4.0K) > > root@beastie:~ # gpart delete -i2 ada0 > gpart: Device busy : : > : > root@beastie:~ # gpart destroy -F ada0 > gpart: Device busy There might still be situations where 'sysctl kern.geom.debugflags=16' helps, but I never needed it in the last years (since 7.x I guess). Are you sure p2 (-i2) of ada0, most likely home for a ufs filesystem, isn't mounted anymore? Was it a mountpoint inside a jail?  Stopping the jail might leave network related active sockets blocking the filesystem (reboot without starting the jail before deleteing the partition should work in that case). -harry From owner-freebsd-stable@freebsd.org Thu Apr 16 17:47:09 2020 Return-Path: Delivered-To: freebsd-stable@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 2BAB32C3125 for ; Thu, 16 Apr 2020 17:47:09 +0000 (UTC) (envelope-from SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49369l74bgz3LSF for ; Thu, 16 Apr 2020 17:47:07 +0000 (UTC) (envelope-from SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 9141428433 for ; Thu, 16 Apr 2020 19:47:04 +0200 (CEST) Received: from illbsd.quip.test (ip-62-24-92-232.net.upcbroadband.cz [62.24.92.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id C5C2B28416 for ; Thu, 16 Apr 2020 19:47:03 +0200 (CEST) To: freebsd-stable@freebsd.org From: Miroslav Lachman <000.fbsd@quip.cz> Subject: support of PCIe NVME drives Message-ID: <5a20f111-b2f5-c1a1-acdf-86df43d79ace@quip.cz> Date: Thu, 16 Apr 2020 19:47:03 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49369l74bgz3LSF X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz has no SPF policy when checking 94.124.105.4) smtp.mailfrom=SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz X-Spamd-Result: default: False [3.97 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; IP_SCORE(0.83)[ip: (0.28), ipnet: 94.124.104.0/21(0.14), asn: 42000(3.61), country: CZ(0.09)]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_MEDIUM(0.94)[0.942,0]; NEURAL_SPAM_LONG(1.00)[0.999,0]; RCVD_IN_DNSWL_NONE(0.00)[4.105.124.94.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz]; DMARC_NA(0.00)[quip.cz]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 17:47:09 -0000 I was requested to install FreeBSD 11.3 on a new Dell machine with only 2 NVME drives in ZFS mirror. The problem is that installer does not see the drives. Are there any special procedure to use NVME drives for installation a later for booting? Drives are described in iDRAC: Device Description: PCIe SSD in Slot 1 in Bay 1 Device Protocol: NVMe-MI1.0 Model: Dell Express Flash NVMe P4510 1TB SFF Bus: 130 Manufacturer: INTEL Product ID: a54 Revision: VDV1DP23 Enclosure: PCIe SSD Backplane 1 There is no special HW RAID card. I switched to a shell in an installer and NVME drives are not listen in dmesg.boot. I tried to manually load nvme and nvd modules but the error messages says they are already in the installer kernel. How can I make it work? Kind regards Miroslav Lachman From owner-freebsd-stable@freebsd.org Thu Apr 16 18:12:40 2020 Return-Path: Delivered-To: freebsd-stable@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 2C9AC2C3C4C for ; Thu, 16 Apr 2020 18:12:40 +0000 (UTC) (envelope-from SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4936lC2q8Vz3NHy; Thu, 16 Apr 2020 18:12:39 +0000 (UTC) (envelope-from SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id E972E28432; Thu, 16 Apr 2020 20:12:37 +0200 (CEST) Received: from illbsd.quip.test (ip-62-24-92-232.net.upcbroadband.cz [62.24.92.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 2F64D28434; Thu, 16 Apr 2020 20:12:37 +0200 (CEST) Subject: Re: support of PCIe NVME drives To: Kurt Jaeger Cc: freebsd-stable@freebsd.org References: <5a20f111-b2f5-c1a1-acdf-86df43d79ace@quip.cz> <20200416180705.GB39563@home.opsec.eu> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <36c9c502-f9b6-fd3d-3ac2-80ab18f8d420@quip.cz> Date: Thu, 16 Apr 2020 20:12:36 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <20200416180705.GB39563@home.opsec.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4936lC2q8Vz3NHy X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz has no SPF policy when checking 94.124.105.4) smtp.mailfrom=SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz X-Spamd-Result: default: False [3.99 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[quip.cz]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.96)[0.964,0]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(0.82)[ip: (0.28), ipnet: 94.124.104.0/21(0.14), asn: 42000(3.61), country: CZ(0.09)]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[4.105.124.94.list.dnswl.org : 127.0.10.0]; NEURAL_SPAM_LONG(1.00)[0.999,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 18:12:40 -0000 Kurt Jaeger wrote on 04/16/2020 20:07: > Hi! > >> I was requested to install FreeBSD 11.3 on a new Dell machine with only 2 >> NVME drives in ZFS mirror. The problem is that installer does not see the >> drives. Are there any special procedure to use NVME drives for >> installation a later for booting? > > I use 2 NVMe drives as zfs mirror to boot from on my testbox, > but it runs CURRENT, since approx. November 2018. > > So maybe try it with 12.1 ? I know, that does not help if you are asked > to install 11.3, but at least it gives you an idea... > I tried 12.1 few minutes ago but the result is the same - no NVME drives listed. Should I try something with kernel modules, some sysctl tweaks? Should I try UEFI boot? (I never did) Kind regards Miroslav Lachman From owner-freebsd-stable@freebsd.org Thu Apr 16 18:23:50 2020 Return-Path: Delivered-To: freebsd-stable@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 6EBDE2C43C8 for ; Thu, 16 Apr 2020 18:23:50 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [174.136.98.114]) (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 "mail.nomadlogic.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4937051jj8z3PVy; Thu, 16 Apr 2020 18:23:48 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.206] (cpe-23-243-162-239.socal.res.rr.com [23.243.162.239]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id d2a42068 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 16 Apr 2020 18:23:42 +0000 (UTC) Subject: Re: support of PCIe NVME drives To: Miroslav Lachman <000.fbsd@quip.cz>, Kurt Jaeger Cc: freebsd-stable@freebsd.org References: <5a20f111-b2f5-c1a1-acdf-86df43d79ace@quip.cz> <20200416180705.GB39563@home.opsec.eu> <36c9c502-f9b6-fd3d-3ac2-80ab18f8d420@quip.cz> From: Pete Wright Message-ID: <37408503-c462-97fa-e702-f23fed366f83@nomadlogic.org> Date: Thu, 16 Apr 2020 11:23:41 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <36c9c502-f9b6-fd3d-3ac2-80ab18f8d420@quip.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 4937051jj8z3PVy X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 174.136.98.114 as permitted sender) smtp.mailfrom=pete@nomadlogic.org X-Spamd-Result: default: False [-5.06 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[239.162.243.23.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[nomadlogic.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; IP_SCORE(-2.76)[ip: (-9.23), ipnet: 174.136.96.0/20(-4.13), asn: 25795(-0.41), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:25795, ipnet:174.136.96.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 18:23:50 -0000 On 4/16/20 11:12 AM, Miroslav Lachman wrote: > Kurt Jaeger wrote on 04/16/2020 20:07: >> Hi! >> >>> I was requested to install FreeBSD 11.3 on a new Dell machine with >>> only 2 >>> NVME drives in ZFS mirror. The problem is that installer does not >>> see the >>> drives. Are there any special procedure to use NVME drives for >>> installation a later for booting? >> >> I use 2 NVMe drives as zfs mirror to boot from on my testbox, >> but it runs CURRENT, since approx. November 2018. >> >> So maybe try it with 12.1 ? I know, that does not help if you are asked >> to install 11.3, but at least it gives you an idea... >> > > I tried 12.1 few minutes ago but the result is the same - no NVME > drives listed. > Should I try something with kernel modules, some sysctl tweaks? > Should I try UEFI boot? (I never did) > I would try booting via UEFI if you can.  I just installed a laptop yesterday which has a nvme root device, it was detected by the 12-STABLE snapshot I used to boot from.  no other modifications were necessary on my end. -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-stable@freebsd.org Thu Apr 16 18:25:40 2020 Return-Path: Delivered-To: freebsd-stable@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 8BC022C454C for ; Thu, 16 Apr 2020 18:25:40 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49372C34KHz3PgH for ; Thu, 16 Apr 2020 18:25:39 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id A47F22110A5 for ; Thu, 16 Apr 2020 14:25:03 -0400 (EDT) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 7370F15E309 for ; Thu, 16 Apr 2020 13:25:03 -0500 (CDT) Subject: Re: support of PCIe NVME drives To: freebsd-stable@freebsd.org References: <5a20f111-b2f5-c1a1-acdf-86df43d79ace@quip.cz> <20200416180705.GB39563@home.opsec.eu> <36c9c502-f9b6-fd3d-3ac2-80ab18f8d420@quip.cz> <37408503-c462-97fa-e702-f23fed366f83@nomadlogic.org> From: Karl Denninger Autocrypt: addr=karl@denninger.net; prefer-encrypt=mutual; keydata= xsFNBF1Rd+gBEACmLAH7SAzdQq57ZN56QQEy0jDFfH5BvGOMZgCaP+Y5lJQ5u9WphCoCALMs Rg0o1Q9DRNWgUmy/cgsxioXAEzZFXXzOHPJhwplVOgfjxnoByD5KQhWG8Owm9QmATdtiZPSV 4UYVNUIbZv7btSnnAXysG2OUHajYS5PVeFQxFbhNFq/SS8VaXr1WEVTFa8NFKp2W3/KY1A+U KKDUlYwnOauK3fnY9chF2IRSoxAbBJFrJ4lPGz04HtzNos4Q9CBfTphKcdFjcPntNS9wrqs3 sm+7hLNTH9B2Kj6aekG5UhD03eyP+gevTgBy51RL6ULzI13Kc4aeyOByuBXrA8D2m2Ee67iy 4+ZSxM9Wn1gQce5624OWzCYIGBH2r75Bshp1KHKu36N2rN//kyKYnwl/z6UZB/S9cMUFKZgL gFx7QxpFX/HvSiBcPfcGS0meModpg6qma7/2jRoQAXacslpiT+uOfRGspNbnglkbw435RzX/ kMUclJQNZBBBUpPiGjVCjeBTiAfN8TyjS+pWzwxNCUZWbYO5xVaS0gbIhgVNoBOGn1rdTsdA PP65SRjaoL5KY6bzkkzrXLB2Djx8/p4vr0qIqxIQWbewJq3xKyKGiqI46ae77BF7k0B++Ndx g9K9UeWKl/iJ0eoI0ftR+xH3aIHTU1Or3j/tj4j8Z0tnVSyt1wARAQABzSNLYXJsIERlbm5p bmdlciA8a2FybEBkZW5uaW5nZXIubmV0PsLBfwQTAQgAKQUCXVF36AIbIwUJCWYBgAcLCQgH AwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEG8twBXrj1l4swkP/3uOzRxW16K6H4JIEIRMUEbt nxDhmk+gR/7H9phg7HtvR7i22QejZX1N1NHcGRNmBwLshWVjJkHKhCE/AM8Cf9XyaV2ft6qn g1xK6NuhapxVuaaMeCVPUzsPkTcR+JMl72ZR4Q+mJMVQButCITekmr7aIzIZ80fF0t86rnq+ O74ZGt0SAMsLV/GAKlIw8fGMi9Xj4OKDgqmxTnIoV4+0mpo26W957pnlOrjN3/6VqWUyAdHH DkyqsuP/9jx2f5pZCcD7X04+93GI+sGb1s6BOFRHq2oJgs6W0z0nPx5Ks9MDDgSQlxXAryje 17WphTR7DWn1BeF3Y8AhRkzc2+Mgc5s1i2fPe6YwvksDNOEyNXIvFV7chwDQYb0Q3I8XsoHu 2WUjXp0kVokobJPdVdY55nbY+brezweRJMiEpFtGOmoUekQWlI5KS1kE8+Xuqpm+MSxEpqY8 5ncPt0lekOrICGajlOotkUK86iVemlW1rMzMc5Xwp9j8oxa+bRtGD6u1rYz4i+qIdE+GSCBy 1nnHN/my0nefhQyHXr8wGVEbyiMZCten9fm1iXpBr0jY+tvtbo8XqZQG7Lr+3kSO6VUgc8kW IPf2HxIV7AnGUN+ddZGCcPPhb2mY/Yy7si54wJFj6YoG+/+rNjF9F5d8WeLoeUWczgHTvZmS o6F7UhjjuwzgzsFNBF1Rd+gBEADNVFS8nQ+kpKOpgtP+f3bCVxHAm7eHMbX6oew5yZiQwfD+ 1RWNWLVOMeTt7G2e5HsHpJOUwFUJhbDb0omB0r38xTSVSAig9kmUfb7tTMJG2bG7WfWykBOM WIZ4OhCf+ISv9dUkjNgx4ionWotFxwDiPRwWumVQ7WYZmRZlhDWMiaHgKvBrjJ7Y6GKPRbQc 5/0Qz9xGhXKlFxDQrrSMkyRThIOxXqdfD9z3rEsV3ZwOojzNsnkIImnQMKyIAR0FBQop34G9 wDQi7fxk8wGIfDszwfR4oAdDdPGq4gcAvE7Fd3xKyNpGyjSED5szoaFjldaZSXQIffquSUvy sFCTTLRIso5Dn9uQgi57gIv+5mnyKBfm2Z2P6pEQPSt073TED9rS0+JpniJL7rKRVpO5niqw sQJS6ht+JF88rXro+SiwxD/KeDpTuuJ10+ohLVi1Y+X82X7BIQEhqtFp9FVJSds4o/eNyaHd SoqfoeWMy3EV+rdJ3DneXcPS1BgxO57Rko5Hx3NUSVK83ovFb+Ofes9SLNdqNu3xAUcfpRdS DyxzpVbCq6Y2CIojiaweiYe5BOBhmR9OPGhqP8YD7GukYmQufAVuOrIVyctBlVPHgMBb+UX+ ItYXuX4weSJWLOsmM45xd/EYvBq2DWFpKlyihoktNzTGqxGsNeG7gCOEUTAnUwARAQABwsFl BBgBCAAPBQJdUXfoAhsMBQkJZgGAAAoJEG8twBXrj1l4Dm0P/iEx2gIHSOnvgpG799Vf2RM0 7gPbDWzDaw8YTV49H+VTOqq7RlT52aO0QfNAmtppX0V1/5f30fuSCF46NWnYGu35P/LvOAPb sLbeWCyJy4GOPN4cjsBMbgmooGdl24RdcvGMmY177o7oOSWBqXfhAj+YA6r+hEar1qxqLgwB Gy8wAId4qYSQhN/FxiQbyUs2tPAI6Wn/41pI7Hu6WgmRGpZrBv8HhVV9Gl7jallSsS/g+fhu WRbDKCknUS5SX3+w2AUFr4kf62gSSxXBxd075KnViV9c0sraAPI31XbM5QUc0Xssfaqs6Srr z4MjKaLhb7GD8C1JwI23PuGdFvk9WK996UvIyjdWIE99VSlg/5gEKkXzwx7oysrSG9BqkfGf I4addK55xRQPul0V3s2LtDoQTxg3VHrL6wrvGhYUcTHLmlsvNx1EOb5a3xBT+SUK/Ltq08LW YcmNbU/G217MlfvDJYHCb0uOtxqJFm8RiZGj2eEcLgvyWnlWCD2rfP4EqCxmpr3Ic725FiQR cBbdTV3clTgclhBG3TA9dxVjfZDcatz5cFBwXP8k5Yn9tNl90T2r79V4SNh1mCHtGTSEf449 qz9tm7EguLchjmoirJTuiipZKcalcHAHtz4VPUykdXsrfEJTzdEcujzqF6v/9CY+DjpAd3et Z0vw7xC5tS+b Message-ID: Date: Thu, 16 Apr 2020 13:25:02 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <37408503-c462-97fa-e702-f23fed366f83@nomadlogic.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms090503040800000006020807" X-Rspamd-Queue-Id: 49372C34KHz3PgH X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=denninger.net; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net X-Spamd-Result: default: False [-7.52 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_DN_NONE(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; RCVD_TLS_LAST(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; IP_SCORE(-2.62)[ip: (-9.85), ipnet: 104.236.64.0/18(-4.47), asn: 14061(1.27), country: US(-0.05)]; RECEIVED_SPAMHAUS_PBL(0.00)[197.57.1.68.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 18:25:40 -0000 This is a cryptographically signed message in MIME format. --------------ms090503040800000006020807 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/16/2020 13:23, Pete Wright wrote: > > > On 4/16/20 11:12 AM, Miroslav Lachman wrote: >> Kurt Jaeger wrote on 04/16/2020 20:07: >>> Hi! >>> >>>> I was requested to install FreeBSD 11.3 on a new Dell machine with >>>> only 2 >>>> NVME drives in ZFS mirror. The problem is that installer does not >>>> see the >>>> drives. Are there any special procedure to use NVME drives for >>>> installation a later for booting? >>> >>> I use 2 NVMe drives as zfs mirror to boot from on my testbox, >>> but it runs CURRENT, since approx. November 2018. >>> >>> So maybe try it with 12.1 ? I know, that does not help if you are ask= ed >>> to install 11.3, but at least it gives you an idea... >>> >> >> I tried 12.1 few minutes ago but the result is the same - no NVME >> drives listed. >> Should I try something with kernel modules, some sysctl tweaks? >> Should I try UEFI boot? (I never did) >> > > I would try booting via UEFI if you can.=C2=A0 I just installed a lapto= p > yesterday which has a nvme root device, it was detected by the > 12-STABLE snapshot I used to boot from.=C2=A0 no other modifications we= re > necessary on my end. > > -pete > Yeah my Lenovo Carbon X1 has an nVME drive in it, and nothing else - 12-Stable found it immediately and works fine. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms090503040800000006020807 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNDE2MTgyNTAy WjBPBgkqhkiG9w0BCQQxQgRAHIiqAYzAu3e+RULGcKvpWxJx6Ww9ph9mZej22vVbalws40lo 0I8XFbmhCo+x05kUk1cceEO/nMqW3DGm2oFjMzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgAyulIWwGee++RaqogZ2gmo72ZXsY5EjLkSlQUIiqbiMwbYyr36gIdTbWuGGNhCeus8 66uNduU1O46ZwaF3EGEUAyd56ddIbJKKMC8eMfNXfutVbwIxpvtnL7vv3wNa4uvaPL79zMIJ dEeHVsiyw+QuNyhDLc0R2PnqHpjf5BfnvYoKryRvDqHxO2VDBUYEWlzP3icsvGN15ys5W2S6 R6xf/TXJ7x8/yBjn6rUYvmEM7XsCNDZXR9R9PZ8GuXQifsjHc2DxLaLsZeSrSN64JX/Ocack r+aAdsXscjZ7bmD4Nj2eKirFgrk/Tzh7fi5OUvmFI0/7utUQHsooqEGGVE/b6u0P3TK8JrRH QhizgE6aIjfx9c9pNXO0cZxS1A9fea/GZTmS1U0qsoX9/w+MkSZ2Qp5TatUl6YBMsJVIpbl7 WG0DoUWgCA3cH+NNrfLlPLBBCQcwxX3JxUFZ4DcWUVo43iqmN16NlyGFTuY+gQVEvi16YuTD ZFXq4NPtLyKr8ORpIQRoT3FB+eigs/q0jBHnRHoe4udqb27B9r+0MAzLAp02iANGp/IpcHn6 Q5a6GWdrUvd67QuStBk5p54rhtx7mu9nG+pZ9ZWkKa3h+ueJBqxsKDky+nhF2hPWHGwok7Jz b2TR2lDyqXoEMLLgKM8u9hV2/3p6bSfzLSJSip88bgAAAAAAAA== --------------ms090503040800000006020807-- From owner-freebsd-stable@freebsd.org Thu Apr 16 18:44:15 2020 Return-Path: Delivered-To: freebsd-stable@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 F408D2C4C8B for ; Thu, 16 Apr 2020 18:44:14 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from echo.brtsvcs.net (echo.brtsvcs.net [IPv6:2607:f740:c::4ae]) (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 4937Rf1Qxjz3R1n; Thu, 16 Apr 2020 18:44:13 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from chombo.houseloki.net (unknown [IPv6:2602:41:642b:600::6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "chombo.houseloki.net", Issuer "brtsvcs.net CA" (verified OK)) by echo.brtsvcs.net (Postfix) with ESMTPS id 746E938D28; Thu, 16 Apr 2020 18:44:07 +0000 (UTC) Received: from [IPv6:2602:41:642b:630:94ee:76e4:bf6e:dd28] (unknown [IPv6:2602:41:642b:630:94ee:76e4:bf6e:dd28]) by chombo.houseloki.net (Postfix) with ESMTPSA id 8318112BF; Thu, 16 Apr 2020 11:44:06 -0700 (PDT) Subject: Re: support of PCIe NVME drives To: Miroslav Lachman <000.fbsd@quip.cz>, Kurt Jaeger Cc: freebsd-stable@freebsd.org References: <5a20f111-b2f5-c1a1-acdf-86df43d79ace@quip.cz> <20200416180705.GB39563@home.opsec.eu> <36c9c502-f9b6-fd3d-3ac2-80ab18f8d420@quip.cz> From: Mel Pilgrim Message-ID: Date: Thu, 16 Apr 2020 11:44:06 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <36c9c502-f9b6-fd3d-3ac2-80ab18f8d420@quip.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4937Rf1Qxjz3R1n X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of list_freebsd@bluerosetech.com designates 2607:f740:c::4ae as permitted sender) smtp.mailfrom=list_freebsd@bluerosetech.com X-Spamd-Result: default: False [-5.59 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; 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]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[bluerosetech.com]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-3.29)[ip: (-8.46), ipnet: 2607:f740:c::/48(-4.16), asn: 36236(-3.81), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36236, ipnet:2607:f740:c::/48, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 18:44:15 -0000 On 2020-04-16 11:12, Miroslav Lachman wrote: > Kurt Jaeger wrote on 04/16/2020 20:07: >> Hi! >> >>> I was requested to install FreeBSD 11.3 on a new Dell machine with >>> only 2 >>> NVME drives in ZFS mirror. The problem is that installer does not see >>> the >>> drives. Are there any special procedure to use NVME drives for >>> installation a later for booting? >> >> I use 2 NVMe drives as zfs mirror to boot from on my testbox, >> but it runs CURRENT, since approx. November 2018. >> >> So maybe try it with 12.1 ? I know, that does not help if you are asked >> to install 11.3, but at least it gives you an idea... >> > > I tried 12.1 few minutes ago but the result is the same - no NVME drives > listed. > Should I try something with kernel modules, some sysctl tweaks? > Should I try UEFI boot? (I never did) Make sure the UEFI BIOS can see them and enable dual-mode or UEFI-only boot. IIRC I couldn't legacy boot from the NVME drives. My home and work servers have UEFI-boot gptzfsboot/root-on-zfs NVME drives that initially started with 11.2 and now run 12.1. From owner-freebsd-stable@freebsd.org Thu Apr 16 18:49:25 2020 Return-Path: Delivered-To: freebsd-stable@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 DB0032C4F11 for ; Thu, 16 Apr 2020 18:49:25 +0000 (UTC) (envelope-from rebecca@bsdio.com) Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4937Yc2MSZz3wdL; Thu, 16 Apr 2020 18:49:24 +0000 (UTC) (envelope-from rebecca@bsdio.com) Received: from in02.mta.xmission.com ([166.70.13.52]) by out01.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jP9Zh-0006Rs-2y; Thu, 16 Apr 2020 12:49:21 -0600 Received: from mta4.zcs.xmission.com ([166.70.13.68]) by in02.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1jP9Zg-0001i5-9m; Thu, 16 Apr 2020 12:49:20 -0600 Received: from localhost (localhost [127.0.0.1]) by mta4.zcs.xmission.com (Postfix) with ESMTP id 0DE5350087C; Thu, 16 Apr 2020 12:49:19 -0600 (MDT) X-Amavis-Modified: Mail body modified (using disclaimer) - mta4.zcs.xmission.com Received: from mta4.zcs.xmission.com ([127.0.0.1]) by localhost (mta4.zcs.xmission.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id s9iJL3gKrDlF; Thu, 16 Apr 2020 12:49:18 -0600 (MDT) Received: from graviton.local (c-174-52-16-57.hsd1.ut.comcast.net [174.52.16.57]) by mta4.zcs.xmission.com (Postfix) with ESMTPSA id A73A550037C; Thu, 16 Apr 2020 12:49:18 -0600 (MDT) To: Pete Wright , Miroslav Lachman <000.fbsd@quip.cz>, Kurt Jaeger Cc: freebsd-stable@freebsd.org References: <5a20f111-b2f5-c1a1-acdf-86df43d79ace@quip.cz> <20200416180705.GB39563@home.opsec.eu> <36c9c502-f9b6-fd3d-3ac2-80ab18f8d420@quip.cz> <37408503-c462-97fa-e702-f23fed366f83@nomadlogic.org> From: Rebecca Cran Message-ID: Date: Thu, 16 Apr 2020 12:49:18 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <37408503-c462-97fa-e702-f23fed366f83@nomadlogic.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-XM-SPF: eid=1jP9Zg-0001i5-9m; ; ; mid=; ; ; hst=in02.mta.xmission.com; ; ; ip=166.70.13.68; ; ; frm=rebecca@bsdio.com; ; ; spf=pass X-SA-Exim-Connect-IP: 166.70.13.68 X-SA-Exim-Mail-From: rebecca@bsdio.com X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on sa08.xmission.com X-Spam-Level: X-Spam-Status: No, score=0.6 required=8.0 tests=ALL_TRUSTED,BAYES_50, DCC_CHECK_NEGATIVE,T_TM2_M_HEADER_IN_MSG,TooManyTo_001,TooManyTo_002, XM_B_Unicode autolearn=disabled version=3.4.2 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5050] * 0.5 TooManyTo_002 Multiple "To" Header Recipients 3x (uncommon) * 0.3 TooManyTo_001 Multiple "To" Header Recipients 2x (uncommon) * 0.0 XM_B_Unicode BODY: Testing for specific types of unicode * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa08 1397; IP=ok Body=1 Fuz1=1] [Fuz2=1] X-Spam-DCC: XMission; sa08 1397; IP=ok Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Pete Wright , Miroslav Lachman <000.fbsd@quip.cz>, Kurt Jaeger X-Spam-Relay-Country: X-Spam-Timing: total 568 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 15 (2.6%), b_tie_ro: 13 (2.2%), parse: 1.29 (0.2%), extract_message_metadata: 4.8 (0.8%), get_uri_detail_list: 0.47 (0.1%), tests_pri_-1000: 3.1 (0.5%), tests_pri_-950: 1.72 (0.3%), tests_pri_-900: 1.36 (0.2%), tests_pri_-90: 180 (31.6%), check_bayes: 177 (31.2%), b_tokenize: 4.8 (0.8%), b_tok_get_all: 10 (1.7%), b_comp_prob: 2.4 (0.4%), b_tok_touch_all: 155 (27.3%), b_finish: 1.44 (0.3%), tests_pri_0: 350 (61.6%), check_dkim_signature: 0.61 (0.1%), check_dkim_adsp: 151 (26.6%), poll_dns_idle: 145 (25.5%), tests_pri_10: 2.0 (0.4%), tests_pri_500: 6 (1.1%), rewrite_mail: 0.00 (0.0%) Subject: Re: support of PCIe NVME drives X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) X-Rspamd-Queue-Id: 4937Yc2MSZz3wdL X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rebecca@bsdio.com designates 166.70.13.231 as permitted sender) smtp.mailfrom=rebecca@bsdio.com X-Spamd-Result: default: False [-2.52 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; RECEIVED_SPAMHAUS_PBL(0.00)[57.16.52.174.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:166.70.13.0/24]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[bsdio.com]; RWL_MAILSPIKE_GOOD(0.00)[231.13.70.166.rep.mailspike.net : 127.0.0.18]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; IP_SCORE(-0.12)[ip: (-3.04), ipnet: 166.70.0.0/16(1.38), asn: 6315(1.10), country: US(-0.05)]; RCVD_IN_DNSWL_LOW(-0.10)[231.13.70.166.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6315, ipnet:166.70.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 18:49:25 -0000 On 4/16/20 12:23 PM, Pete Wright wrote: > I would try booting via UEFI if you can.  I just installed a laptop > yesterday which has a nvme root device, it was detected by the > 12-STABLE snapshot I used to boot from.  no other modifications were > necessary on my end. I can confirm, NVMe drives tend to not have any support under the traditional/legacy BIOS, and require UEFI. -- Rebecca Cran From owner-freebsd-stable@freebsd.org Thu Apr 16 19:30:20 2020 Return-Path: Delivered-To: freebsd-stable@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 08D1F2C5C20 for ; Thu, 16 Apr 2020 19:30:20 +0000 (UTC) (envelope-from SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4938Sp5Kn2z404C; Thu, 16 Apr 2020 19:30:18 +0000 (UTC) (envelope-from SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 6D13828434; Thu, 16 Apr 2020 21:30:15 +0200 (CEST) Received: from illbsd.quip.test (ip-62-24-92-232.net.upcbroadband.cz [62.24.92.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id A2B6428432; Thu, 16 Apr 2020 21:30:13 +0200 (CEST) Subject: Re: support of PCIe NVME drives To: Pete Wright , Kurt Jaeger Cc: freebsd-stable@freebsd.org References: <5a20f111-b2f5-c1a1-acdf-86df43d79ace@quip.cz> <20200416180705.GB39563@home.opsec.eu> <36c9c502-f9b6-fd3d-3ac2-80ab18f8d420@quip.cz> <37408503-c462-97fa-e702-f23fed366f83@nomadlogic.org> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: Date: Thu, 16 Apr 2020 21:30:13 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <37408503-c462-97fa-e702-f23fed366f83@nomadlogic.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4938Sp5Kn2z404C X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz has no SPF policy when checking 94.124.105.4) smtp.mailfrom=SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz X-Spamd-Result: default: False [4.00 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; IP_SCORE(0.82)[ip: (0.28), ipnet: 94.124.104.0/21(0.14), asn: 42000(3.60), country: CZ(0.09)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[quip.cz]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.97)[0.974,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000,0]; RCVD_IN_DNSWL_NONE(0.00)[4.105.124.94.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 19:30:20 -0000 Pete Wright wrote on 04/16/2020 20:23: > > > On 4/16/20 11:12 AM, Miroslav Lachman wrote: >> Kurt Jaeger wrote on 04/16/2020 20:07: > I would try booting via UEFI if you can.  I just installed a laptop > yesterday which has a nvme root device, it was detected by the 12-STABLE > snapshot I used to boot from.  no other modifications were necessary on > my end. I changed BIOS settings to use UEFI boot method, booted 12.1 installer ISO but without luck. Still no NVME disks :( You can see it on printscreen from iDRAC https://ibb.co/tPnymL7 Anything more I can test? Kind regards Miroslav Lachman From owner-freebsd-stable@freebsd.org Thu Apr 16 19:51:08 2020 Return-Path: Delivered-To: freebsd-stable@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 1CCDF2C65AC for ; Thu, 16 Apr 2020 19:51:08 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 4938wq0cnyz41my for ; Thu, 16 Apr 2020 19:51:06 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by mail-pl1-x62b.google.com with SMTP id y22so17553pll.4 for ; Thu, 16 Apr 2020 12:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=9wWqpcKO4W8BqBK/8Lq+Yj447lxOyiIECYxmvfn2V+E=; b=X8TcA81vWxE2zwNIwH+HFuNdGcwtqUi2CtJ5YSaEUxt0oii+4qmAkA/o9EVQX0ThSD uJjzsGvHun4toKFxpeGwtyBEzSfw/n+nRJBct8uGYEbXXb0kPi7/ngJkQdEfIO7AYrcG lGtT9hbPVK2/3f6MosSTgeuL7de3txVzJtZp653OOafvarrcEfFBh5ebcqLnrVXlaF+n PFe1t8i5ZXzYbzW8L5ymv3FpVBJk7Zvn5BqxoDJqESfE8uMW/dhX3HGdGBJ+zFJ0DI3V drQzyCG1vlJI87g1Cy9e1k5dXPD6X0JFdYOZwu8udbF5LBmfuSwODj5q9ngn5eW9/55D suvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9wWqpcKO4W8BqBK/8Lq+Yj447lxOyiIECYxmvfn2V+E=; b=oOSPdiFoNswqiuGidMm2B+8aWkHy/WyjO6MSIuKtH6SRX1IJrQmKWtVl7I1Y3d0tpE iLO88E5jon/bjgMxJI5IiwidWcaRda3DcjOCRuPAPWC7ugPzMFJKhtVoQss/G2Vb7ygZ ZJqP+oifD0E5duRJOyGeSvNIRehYh3M77kzti369Ed2a5kt9V8131Oz4wPWSMoCsJFa6 jckhjdAWyjHFU0MkXJIQtbfwBxcZLGNS9GnSgF8m7SoR4+3TeWEehCGivtP1EFqQC7m4 si7m5ZDpNSlbZuHsA0Y685Ldyq+jbG7RzePl0U7GKBbT5nu6/wKp6I8tQ54clrJv7QZ/ xcjQ== X-Gm-Message-State: AGi0Pubvu906ebjrBoKNoEeycXxKi+AyUf5JxYgRFAB++qlV+R7cvjhA KDXCJdsmWu+ck//GADhDW0bKoSjv X-Google-Smtp-Source: APiQypKeaEbEHBgB09xviBQ/q6v5yFxYOAkraCK4C13dkL8dWnEJsOXZ9lJooBrhXa/Zc7tYpFi7Ww== X-Received: by 2002:a17:90b:1b01:: with SMTP id nu1mr6944663pjb.129.1587066664918; Thu, 16 Apr 2020 12:51:04 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [12.32.117.8]) by smtp.googlemail.com with ESMTPSA id c4sm16495210pgg.17.2020.04.16.12.51.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Apr 2020 12:51:04 -0700 (PDT) Subject: Re: support of PCIe NVME drives To: Miroslav Lachman <000.fbsd@quip.cz> Cc: freebsd-stable@freebsd.org References: <5a20f111-b2f5-c1a1-acdf-86df43d79ace@quip.cz> <20200416180705.GB39563@home.opsec.eu> <36c9c502-f9b6-fd3d-3ac2-80ab18f8d420@quip.cz> <37408503-c462-97fa-e702-f23fed366f83@nomadlogic.org> From: Navdeep Parhar Message-ID: <77bf59bf-7023-0896-d560-e7644ccaa87f@gmail.com> Date: Thu, 16 Apr 2020 12:51:02 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4938wq0cnyz41my X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=X8TcA81v; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of nparhar@gmail.com designates 2607:f8b0:4864:20::62b as permitted sender) smtp.mailfrom=nparhar@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-9.16), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[b.2.6.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]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 19:51:08 -0000 On 4/16/20 12:30 PM, Miroslav Lachman wrote: > Pete Wright wrote on 04/16/2020 20:23: >> >> >> On 4/16/20 11:12 AM, Miroslav Lachman wrote: >>> Kurt Jaeger wrote on 04/16/2020 20:07: >=20 >> I would try booting via UEFI if you can.=C2=A0 I just installed a lapt= op >> yesterday which has a nvme root device, it was detected by the >> 12-STABLE snapshot I used to boot from.=C2=A0 no other modifications w= ere >> necessary on my end. >=20 > I changed BIOS settings to use UEFI boot method, booted 12.1 installer > ISO but without luck. Still no NVME disks :( >=20 > You can see it on printscreen from iDRAC https://ibb.co/tPnymL7 >=20 > Anything more I can test? Does the nvme controller show up in pciconf -l? # pciconf -l | grep nvme Regards, Navdeep From owner-freebsd-stable@freebsd.org Thu Apr 16 19:53:21 2020 Return-Path: Delivered-To: freebsd-stable@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 85F122C6876 for ; Thu, 16 Apr 2020 19:53:21 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.70]) (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 "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4938zN3mgsz42Js for ; Thu, 16 Apr 2020 19:53:20 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from mather.gromit23.net (c-98-244-101-97.hsd1.va.comcast.net [98.244.101.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id D52DD35B; Thu, 16 Apr 2020 15:53:13 -0400 (EDT) Content-Type: text/plain; charset=utf-8; delsp=yes; format=flowed Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Subject: Re: Issue with gpart "Device Busy" From: Paul Mather In-Reply-To: <3BF9F702-81FD-4156-B6A2-E32C549ACA90@dijix.com> Date: Thu, 16 Apr 2020 15:53:12 -0400 Cc: freebsd-stable@freebsd.org Content-Transfer-Encoding: 8bit Message-Id: References: <3BF9F702-81FD-4156-B6A2-E32C549ACA90@dijix.com> To: ian@dijix.com X-Mailer: Apple Mail (2.3445.104.14) X-Rspamd-Queue-Id: 4938zN3mgsz42Js X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=vt.edu (policy=none); spf=none (mx1.freebsd.org: domain of paul@gromit.dlib.vt.edu has no SPF policy when checking 128.173.49.70) smtp.mailfrom=paul@gromit.dlib.vt.edu X-Spamd-Result: default: False [-1.99 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[vt.edu : No valid SPF, No valid DKIM,none]; RECEIVED_SPAMHAUS_PBL(0.00)[97.101.244.98.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; IP_SCORE(-0.49)[ip: (-1.25), ipnet: 128.173.0.0/16(-0.62), asn: 1312(-0.56), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-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:1312, ipnet:128.173.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 19:53:21 -0000 On Apr 15, 2020, at 2:35 PM, ian@dijix.com wrote: > I have an issue with gpart, it will not let me delete partition ada0p2 > responding with “Device Busy” > The man page gpart(8) says this may be shown if a partition exists but I > cannot seem to delete partition 2 in my case via gpart delete or gpart > destroy > > This is a used disk but new to the machine, I can modify the partition > type and create partitions before and after partition 2 but I cannot > delete it. > > Here’s what I have tried so far: > > > root@beastie:~ # gpart show > => 34 1250263661 ada0 GPT (596G) > 34 409606 - free - (200M) > 409640 1249591904 2 freebsd-ufs (596G) > 1250001544 262151 - free - (128M) > > => 40 976773088 ada1 GPT (466G) > 40 1024 1 freebsd-boot (512K) > 1064 984 - free - (492K) > 2048 4194304 2 freebsd-swap (2.0G) > 4196352 972576768 3 freebsd-zfs (464G) > 976773120 8 - free - (4.0K) > > root@beastie:~ # gpart delete -i2 ada0 > gpart: Device busy > > root@beastie:~ # gpart add -t freebsd-boot ada0 > ada0p1 added > > root@beastie:~ # gpart show > => 34 1250263661 ada0 GPT (596G) > 34 409606 1 freebsd-boot (200M) > 409640 1249591904 2 freebsd-ufs (596G) > 1250001544 262151 - free - (128M) > > => 40 976773088 ada1 GPT (466G) > 40 1024 1 freebsd-boot (512K) > 1064 984 - free - (492K) > 2048 4194304 2 freebsd-swap (2.0G) > 4196352 972576768 3 freebsd-zfs (464G) > 976773120 8 - free - (4.0K) > > root@beastie:~ # gpart delete -i2 ada0 > gpart: Device busy > > root@beastie:~ # gpart delete -i1 ada0 > ada0p1 deleted > > root@beastie:~ # gpart show > => 34 1250263661 ada0 GPT (596G) > 34 409606 - free - (200M) > 409640 1249591904 2 freebsd-ufs (596G) > 1250001544 262151 - free - (128M) > > => 40 976773088 ada1 GPT (466G) > 40 1024 1 freebsd-boot (512K) > 1064 984 - free - (492K) > 2048 4194304 2 freebsd-swap (2.0G) > 4196352 972576768 3 freebsd-zfs (464G) > 976773120 8 - free - (4.0K) > > root@beastie:~ # gpart destroy -F ada0 > gpart: Device busy > > root@beastie:~ # gpart modify -i2 -t freebsd-boot ada0 > ada0p2 modified > root@beastie:~ # gpart show > => 34 1250263661 ada0 GPT (596G) > 34 409606 - free - (200M) > 409640 1249591904 2 freebsd-boot (596G) > 1250001544 262151 - free - (128M) > > => 40 976773088 ada1 GPT (466G) > 40 1024 1 freebsd-boot (512K) > 1064 984 - free - (492K) > 2048 4194304 2 freebsd-swap (2.0G) > 4196352 972576768 3 freebsd-zfs (464G) > 976773120 8 - free - (4.0K) > > > I’m not sure where to go from here, I’m tempted to pull the drive and > reformat elsewhere > > I have all tried dd’ing the disk as root but dd /dev/ada0 errors with > unauthorised. > > Am I missing something obvious? I don't know whether it can be considered obvious, but, in my experience, this sort of inability to delete a partition can happen because another GEOM layer has that partition open under some other guise. Typical culprits are the various "label" classes and other GEOM classes that "autodetect" things belonging to them. A case in point that happened to me recently: I was trying to install on what I thought were two empty drives. Unfortunately, when it came to actually partitioning ada0 and ada1 it failed. It turned out that the drives were previously used in a "fake RAID" setup and GEOM_RAID was detecting an old RAID volume on the drives because the RAID metadata/label was being detected. This meant I couldn't directly access the underlying devices, ada0 and ada1. My solution was to use graid to destroy the errant RAID volume, after which I was able to write/partition ada0 and ada1 directly. Sometimes it is sufficient to disable autodetection of various label classes in /boot/loader.conf to be able to access the lower devices. Cheers, Paul. From owner-freebsd-stable@freebsd.org Thu Apr 16 20:19:35 2020 Return-Path: Delivered-To: freebsd-stable@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 741172C7120 for ; Thu, 16 Apr 2020 20:19:35 +0000 (UTC) (envelope-from SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4939Yf2b0Nz43wX for ; Thu, 16 Apr 2020 20:19:33 +0000 (UTC) (envelope-from SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 7515128432; Thu, 16 Apr 2020 22:19:32 +0200 (CEST) Received: from illbsd.quip.test (ip-62-24-92-232.net.upcbroadband.cz [62.24.92.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 4D64D28416; Thu, 16 Apr 2020 22:19:31 +0200 (CEST) Subject: Re: support of PCIe NVME drives To: Navdeep Parhar Cc: freebsd-stable@freebsd.org References: <5a20f111-b2f5-c1a1-acdf-86df43d79ace@quip.cz> <20200416180705.GB39563@home.opsec.eu> <36c9c502-f9b6-fd3d-3ac2-80ab18f8d420@quip.cz> <37408503-c462-97fa-e702-f23fed366f83@nomadlogic.org> <77bf59bf-7023-0896-d560-e7644ccaa87f@gmail.com> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <12576baf-7305-e562-92e2-76fffda1c683@quip.cz> Date: Thu, 16 Apr 2020 22:19:30 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <77bf59bf-7023-0896-d560-e7644ccaa87f@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4939Yf2b0Nz43wX X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz has no SPF policy when checking 94.124.105.4) smtp.mailfrom=SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz X-Spamd-Result: default: False [3.97 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; IP_SCORE(0.82)[ip: (0.28), ipnet: 94.124.104.0/21(0.14), asn: 42000(3.60), country: CZ(0.09)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[quip.cz]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.95)[0.953,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[4.105.124.94.list.dnswl.org : 127.0.10.0]; NEURAL_SPAM_LONG(1.00)[0.999,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz]; FREEMAIL_TO(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 20:19:35 -0000 Navdeep Parhar wrote on 04/16/2020 21:51: > On 4/16/20 12:30 PM, Miroslav Lachman wrote: >> Pete Wright wrote on 04/16/2020 20:23: >>> >>> >>> On 4/16/20 11:12 AM, Miroslav Lachman wrote: >>>> Kurt Jaeger wrote on 04/16/2020 20:07: >> >>> I would try booting via UEFI if you can.  I just installed a laptop >>> yesterday which has a nvme root device, it was detected by the >>> 12-STABLE snapshot I used to boot from.  no other modifications were >>> necessary on my end. >> >> I changed BIOS settings to use UEFI boot method, booted 12.1 installer >> ISO but without luck. Still no NVME disks :( >> >> You can see it on printscreen from iDRAC https://ibb.co/tPnymL7 >> >> Anything more I can test? > > Does the nvme controller show up in pciconf -l? > > # pciconf -l | grep nvme Empty result. pciconf -l show many things, tome of them are named "noneN@pci..." The machine is Dell PowerEdge R6515 with AMD EPYC 7302P Is it possible that the controller is not recognized? Miroslav Lachman From owner-freebsd-stable@freebsd.org Thu Apr 16 20:30:06 2020 Return-Path: Delivered-To: freebsd-stable@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 8B5222C74FD for ; Thu, 16 Apr 2020 20:30:06 +0000 (UTC) (envelope-from ctuffli@gmail.com) Received: from mail-pl1-x642.google.com (mail-pl1-x642.google.com [IPv6:2607:f8b0:4864:20::642]) (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 4939nn4MNQz44WB; Thu, 16 Apr 2020 20:30:05 +0000 (UTC) (envelope-from ctuffli@gmail.com) Received: by mail-pl1-x642.google.com with SMTP id ay1so63374plb.0; Thu, 16 Apr 2020 13:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/z26LoEnEkdSVnaiNy7VJQRbeGWtfiPdxEyJbQRfczw=; b=OaqlLJTV2uoDM33RiuNACTJzElUtIMECqrXxRli8Mx1SJr0A1E/2YWfvowYBIL9pnf Bcwbo+HeqKGVGOMcl07ras+UTuLj9udHtyOLHIgHhMYpRvaZdl5EMHkJ+mG2frGuna61 hVD0riG6+mgygKqF34uRU2n7UVZDpT0pcFG1e74tWng07VZVaVwWu2s7aZboUY994z1t nTldcykHcIjemHrgZ5/P5ehzowX+WnRTFWnYPkI5xi3k7vijcEN8sLP65puA3xEsB4ex CA2FILGCyozrXQdD07XsfANYLIAbxRsM2nl9x4m1BLQ3wmtDEw7oAZjE19g1bpQGQiAU XguA== 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=/z26LoEnEkdSVnaiNy7VJQRbeGWtfiPdxEyJbQRfczw=; b=aCyIX6ZT5LO2qRnEVLWhHP8FV1o0rlwVlg0li7fmIZ8MXLm6aIMlg7gTa5wyZhrIdI K0TZuTL9XhRxuvTVVTTib4KiVD7KQtMYCxqKtFmOa1MuBMwC5QE0GMwnyERGJe6tmJXT yZJ/ji7qSyrXC8xIQLjlNit2XPj7tnUZpsPQkdZ6ipI9nPBwZtVKzvuiqsciVzatIxgo IOixeKBBg+5EDFyJc1a0b/WmoL7N6nELTgc4DRFcV0XJ2X/x85inIvOT9CwvSrBUqbOG Tz+7887bn7hRwEvhmQhbFob/+xqu1x/AJLBgR/2Fb1mb+YbV9I6cfFe5rI/6CWDDWKtN KoCQ== X-Gm-Message-State: AGi0PuaX65dHHIjB75h+RNw1GyI3NVSX1uOWplAomfKp0r9Ei9i7lg94 1n6HuKghiEgYsVzyek6LUcgRZ8vT/BiP7zMYUmdFuTh6 X-Google-Smtp-Source: APiQypJYfELSb62VRnwd5pwuqWNwQ8rsm1+ZOrqVjjPakTZw5vx31fU+/s4VYZSI+SmA8oAT28kU9Qbj/hxxMhQ6h70= X-Received: by 2002:a17:902:ac8d:: with SMTP id h13mr11621137plr.267.1587069004206; Thu, 16 Apr 2020 13:30:04 -0700 (PDT) MIME-Version: 1.0 References: <5a20f111-b2f5-c1a1-acdf-86df43d79ace@quip.cz> <20200416180705.GB39563@home.opsec.eu> <36c9c502-f9b6-fd3d-3ac2-80ab18f8d420@quip.cz> <37408503-c462-97fa-e702-f23fed366f83@nomadlogic.org> In-Reply-To: From: Chuck Tuffli Date: Thu, 16 Apr 2020 13:29:52 -0700 Message-ID: Subject: Re: support of PCIe NVME drives To: Miroslav Lachman <000.fbsd@quip.cz> Cc: Pete Wright , Kurt Jaeger , freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4939nn4MNQz44WB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=OaqlLJTV; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ctuffli@gmail.com designates 2607:f8b0:4864:20::642 as permitted sender) smtp.mailfrom=ctuffli@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (-0.02), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2.4.6.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]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 20:30:06 -0000 On Thu, Apr 16, 2020 at 12:30 PM Miroslav Lachman <000.fbsd@quip.cz> wrote: > > Pete Wright wrote on 04/16/2020 20:23: > > > > > > On 4/16/20 11:12 AM, Miroslav Lachman wrote: > >> Kurt Jaeger wrote on 04/16/2020 20:07: > > > I would try booting via UEFI if you can. I just installed a laptop > > yesterday which has a nvme root device, it was detected by the 12-STABLE > > snapshot I used to boot from. no other modifications were necessary on > > my end. > > I changed BIOS settings to use UEFI boot method, booted 12.1 installer > ISO but without luck. Still no NVME disks :( > > You can see it on printscreen from iDRAC https://ibb.co/tPnymL7 > > Anything more I can test? Fair warning, I don't deal much with Dell, but it's curious that iDrac lists the device protocol as MI > Device Protocol: NVMe-MI1.0 MI or the Management Interface is defined by NVMe, but it isn't the same as a block interface. MI typically uses SMBUS and not PCIe to communicate with the device. So it's possible that the device is visible to iDrac via SMBUS but may not be on the PCIe bus for $reasons. Does iDrac have any tools to interact with the device via MI? --chuck From owner-freebsd-stable@freebsd.org Thu Apr 16 20:57:16 2020 Return-Path: Delivered-To: freebsd-stable@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 7F46C2C804C for ; Thu, 16 Apr 2020 20:57:16 +0000 (UTC) (envelope-from SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 493BP72b9nz46cg; Thu, 16 Apr 2020 20:57:15 +0000 (UTC) (envelope-from SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id BAC3728436; Thu, 16 Apr 2020 22:57:13 +0200 (CEST) Received: from illbsd.quip.test (ip-62-24-92-232.net.upcbroadband.cz [62.24.92.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 7B55F28433; Thu, 16 Apr 2020 22:57:12 +0200 (CEST) Subject: Re: support of PCIe NVME drives To: Chuck Tuffli Cc: Pete Wright , freebsd-stable@freebsd.org, Kurt Jaeger References: <5a20f111-b2f5-c1a1-acdf-86df43d79ace@quip.cz> <20200416180705.GB39563@home.opsec.eu> <36c9c502-f9b6-fd3d-3ac2-80ab18f8d420@quip.cz> <37408503-c462-97fa-e702-f23fed366f83@nomadlogic.org> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: Date: Thu, 16 Apr 2020 22:57:10 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 493BP72b9nz46cg X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz has no SPF policy when checking 94.124.105.4) smtp.mailfrom=SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz X-Spamd-Result: default: False [3.97 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; IP_SCORE(0.82)[ip: (0.28), ipnet: 94.124.104.0/21(0.14), asn: 42000(3.60), country: CZ(0.09)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[quip.cz]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.95)[0.954,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000,0]; RCVD_IN_DNSWL_NONE(0.00)[4.105.124.94.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz]; FREEMAIL_TO(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 20:57:16 -0000 Chuck Tuffli wrote on 04/16/2020 22:29: > On Thu, Apr 16, 2020 at 12:30 PM Miroslav Lachman <000.fbsd@quip.cz> wrote: >> >> Pete Wright wrote on 04/16/2020 20:23: >>> >>> >>> On 4/16/20 11:12 AM, Miroslav Lachman wrote: >>>> Kurt Jaeger wrote on 04/16/2020 20:07: >> >>> I would try booting via UEFI if you can. I just installed a laptop >>> yesterday which has a nvme root device, it was detected by the 12-STABLE >>> snapshot I used to boot from. no other modifications were necessary on >>> my end. >> >> I changed BIOS settings to use UEFI boot method, booted 12.1 installer >> ISO but without luck. Still no NVME disks :( >> >> You can see it on printscreen from iDRAC https://ibb.co/tPnymL7 >> >> Anything more I can test? > > Fair warning, I don't deal much with Dell, but it's curious that iDrac > lists the device protocol as MI >> Device Protocol: NVMe-MI1.0 > > MI or the Management Interface is defined by NVMe, but it isn't the > same as a block interface. MI typically uses SMBUS and not PCIe to > communicate with the device. So it's possible that the device is > visible to iDrac via SMBUS but may not be on the PCIe bus for > $reasons. Does iDrac have any tools to interact with the device via > MI? iDRAC does not allow me to do anything with the drives. But I booted Linux SystemRescueCd and nvme devices are there visible in /dev/ printscreen https://ibb.co/sj22Nwg So I think the HW is OK, but FreeBSD does not recognize the controller? Kind regards Miroslav Lachman From owner-freebsd-stable@freebsd.org Thu Apr 16 21:06:31 2020 Return-Path: Delivered-To: freebsd-stable@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 9D5962C83CB for ; Thu, 16 Apr 2020 21:06:31 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [174.136.98.114]) (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 "mail.nomadlogic.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 493Bbp1WLdz47GR; Thu, 16 Apr 2020 21:06:29 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.206] (cpe-23-243-162-239.socal.res.rr.com [23.243.162.239]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 72695470 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Thu, 16 Apr 2020 21:06:28 +0000 (UTC) Subject: Re: support of PCIe NVME drives To: Miroslav Lachman <000.fbsd@quip.cz>, Chuck Tuffli Cc: freebsd-stable@freebsd.org, Kurt Jaeger References: <5a20f111-b2f5-c1a1-acdf-86df43d79ace@quip.cz> <20200416180705.GB39563@home.opsec.eu> <36c9c502-f9b6-fd3d-3ac2-80ab18f8d420@quip.cz> <37408503-c462-97fa-e702-f23fed366f83@nomadlogic.org> From: Pete Wright Message-ID: Date: Thu, 16 Apr 2020 14:06:28 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 493Bbp1WLdz47GR X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 174.136.98.114 as permitted sender) smtp.mailfrom=pete@nomadlogic.org X-Spamd-Result: default: False [-5.07 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[239.162.243.23.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[nomadlogic.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; IP_SCORE(-2.77)[ip: (-9.23), ipnet: 174.136.96.0/20(-4.14), asn: 25795(-0.42), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:25795, ipnet:174.136.96.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 21:06:31 -0000 On 4/16/20 1:57 PM, Miroslav Lachman wrote: > Chuck Tuffli wrote on 04/16/2020 22:29: >> On Thu, Apr 16, 2020 at 12:30 PM Miroslav Lachman <000.fbsd@quip.cz> >> wrote: >>> >>> Pete Wright wrote on 04/16/2020 20:23: >>>> >>>> >>>> On 4/16/20 11:12 AM, Miroslav Lachman wrote: >>>>> Kurt Jaeger wrote on 04/16/2020 20:07: >>> >>>> I would try booting via UEFI if you can.  I just installed a laptop >>>> yesterday which has a nvme root device, it was detected by the >>>> 12-STABLE >>>> snapshot I used to boot from.  no other modifications were >>>> necessary on >>>> my end. >>> >>> I changed BIOS settings to use UEFI boot method, booted 12.1 installer >>> ISO but without luck. Still no NVME disks :( >>> >>> You can see it on printscreen from iDRAC https://ibb.co/tPnymL7 >>> >>> Anything more I can test? >> >> Fair warning, I don't deal much with Dell, but it's curious that iDrac >> lists the device protocol as MI >>> Device Protocol:      NVMe-MI1.0 >> >> MI or the Management Interface is defined by NVMe, but it isn't the >> same as a block interface. MI typically uses SMBUS and not PCIe to >> communicate with the device. So it's possible that the device is >> visible to iDrac via SMBUS but may not be on the PCIe bus for >> $reasons. Does iDrac have any tools to interact with the device via >> MI? > > iDRAC does not allow me to do anything with the drives. > But I booted Linux SystemRescueCd and nvme devices are there visible > in /dev/ > printscreen https://ibb.co/sj22Nwg > > So I think the HW is OK, but FreeBSD does not recognize the controller? > might be interesting to see what the dmesg buffer and lspci output for this device is under linux.  that should give pointers to how the device is being presented to the kernel. -p -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-stable@freebsd.org Thu Apr 16 21:07:55 2020 Return-Path: Delivered-To: freebsd-stable@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 3CBE82C84FF for ; Thu, 16 Apr 2020 21:07:55 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 493BdQ63Lrz47PR for ; Thu, 16 Apr 2020 21:07:54 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 03GL8Ull043603 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 16 Apr 2020 14:08:37 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: Pete Wright , , Chuck Tuffli In-Reply-To: From: Chris Reply-To: bsd-lists@BSDforge.com To: Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: support of PCIe NVME drives Date: Thu, 16 Apr 2020 14:08:37 -0700 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 493BdQ63Lrz47PR X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.97 / 15.00]; NEURAL_HAM_MEDIUM(-0.98)[-0.981,0]; NEURAL_HAM_LONG(-0.99)[-0.991,0]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 21:07:55 -0000 On Thu, 16 Apr 2020 22:57:10 +0200 Miroslav Lachman 000=2Efbsd@quip=2Ecz said > Chuck Tuffli wrote on 04/16/2020 22:29: > > On Thu, Apr 16, 2020 at 12:30 PM Miroslav Lachman <000=2Efbsd@quip=2Ecz> wr= ote: > >> > >> Pete Wright wrote on 04/16/2020 20:23: > >>> > >>> > >>> On 4/16/20 11:12 AM, Miroslav Lachman wrote: > >>>> Kurt Jaeger wrote on 04/16/2020 20:07: > >> > >>> I would try booting via UEFI if you can=2E I just installed a laptop > >>> yesterday which has a nvme root device, it was detected by the 12-STA= BLE > >>> snapshot I used to boot from=2E no other modifications were necessary = on > >>> my end=2E > >> > >> I changed BIOS settings to use UEFI boot method, booted 12=2E1 installer > >> ISO but without luck=2E Still no NVME disks :( > >> > >> You can see it on printscreen from iDRAC https://ibb=2Eco/tPnymL7 > >> > >> Anything more I can test? > >=20 > > Fair warning, I don't deal much with Dell, but it's curious that iDrac > > lists the device protocol as MI > >> Device Protocol: NVMe-MI1=2E0 > >=20 > > MI or the Management Interface is defined by NVMe, but it isn't the > > same as a block interface=2E MI typically uses SMBUS and not PCIe to > > communicate with the device=2E So it's possible that the device is > > visible to iDrac via SMBUS but may not be on the PCIe bus for > > $reasons=2E Does iDrac have any tools to interact with the device via > > MI? >=20 > iDRAC does not allow me to do anything with the drives=2E > But I booted Linux SystemRescueCd and nvme devices are there visible in= =20 > /dev/ > printscreen https://ibb=2Eco/sj22Nwg >=20 > So I think the HW is OK, but FreeBSD does not recognize the controller? Does mps(4) or any of the other (often Dell) rebranded LSI drivers expose a= nything? >=20 > Kind regards > Miroslav Lachman --Chris From owner-freebsd-stable@freebsd.org Thu Apr 16 21:30:09 2020 Return-Path: Delivered-To: freebsd-stable@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 175412C8AB9 for ; Thu, 16 Apr 2020 21:30:09 +0000 (UTC) (envelope-from SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 493C740RMhz48P6; Thu, 16 Apr 2020 21:30:07 +0000 (UTC) (envelope-from SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 52ECD28432; Thu, 16 Apr 2020 23:30:06 +0200 (CEST) Received: from illbsd.quip.test (ip-62-24-92-232.net.upcbroadband.cz [62.24.92.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 4E9B528433; Thu, 16 Apr 2020 23:30:02 +0200 (CEST) Subject: Re: support of PCIe NVME drives To: Pete Wright , Chuck Tuffli Cc: freebsd-stable@freebsd.org, Kurt Jaeger References: <5a20f111-b2f5-c1a1-acdf-86df43d79ace@quip.cz> <20200416180705.GB39563@home.opsec.eu> <36c9c502-f9b6-fd3d-3ac2-80ab18f8d420@quip.cz> <37408503-c462-97fa-e702-f23fed366f83@nomadlogic.org> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <497c359b-e8d3-3d18-2d64-3b487983d1f4@quip.cz> Date: Thu, 16 Apr 2020 23:30:01 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 493C740RMhz48P6 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz has no SPF policy when checking 94.124.105.4) smtp.mailfrom=SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz X-Spamd-Result: default: False [3.99 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; IP_SCORE(0.82)[ip: (0.28), ipnet: 94.124.104.0/21(0.14), asn: 42000(3.60), country: CZ(0.09)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[quip.cz]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.97)[0.966,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.999,0]; RCVD_IN_DNSWL_NONE(0.00)[4.105.124.94.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=OZKT=6A=quip.cz=000.fbsd@elsa.codelab.cz]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 21:30:09 -0000 Pete Wright wrote on 04/16/2020 23:06: >> >> iDRAC does not allow me to do anything with the drives. >> But I booted Linux SystemRescueCd and nvme devices are there visible >> in /dev/ >> printscreen https://ibb.co/sj22Nwg >> >> So I think the HW is OK, but FreeBSD does not recognize the controller? >> > might be interesting to see what the dmesg buffer and lspci output for > this device is under linux.  that should give pointers to how the device > is being presented to the kernel. There is verbose output of lspci https://ibb.co/dPZTwV1 dmesg contains: nvme nvme0: pci function 0000:81:00.0 nvme nvme1: pci function 0000:82:00.0 nvme nvme0: 32/0/0 default/read/poll queues nvme nvme1: 32/0/0 default/read/poll queues Kind regards Miroslav Lachman From owner-freebsd-stable@freebsd.org Thu Apr 16 23:00:37 2020 Return-Path: Delivered-To: freebsd-stable@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 6FA972CAB3C for ; Thu, 16 Apr 2020 23:00:37 +0000 (UTC) (envelope-from ian@dijix.com) Received: from relay1.stackmail.com (relay1.stackmail.com [185.151.28.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 493F7R5nBBz4FNJ for ; Thu, 16 Apr 2020 23:00:35 +0000 (UTC) (envelope-from ian@dijix.com) Received: from smtp1.mail.stackcp.net ([10.4.72.75] helo=smtp1.n4.stackcp.net) by relay1.stackmail.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jPDUi-0007OW-0W for freebsd-stable@freebsd.org; Fri, 17 Apr 2020 00:00:28 +0100 Received: from 156.91.90.146.dyn.plus.net ([146.90.91.156] helo=[10.0.1.33]) by smtp1.n4.stackcp.net with esmtpa (Exim 4.92.3) (envelope-from ) id 1jPDUh-0005tB-Ng for freebsd-stable@freebsd.org; Fri, 17 Apr 2020 00:00:27 +0100 From: ian@dijix.com Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Subject: Re: Issue with gpart "Device Busy" Date: Fri, 17 Apr 2020 00:00:27 +0100 References: <3BF9F702-81FD-4156-B6A2-E32C549ACA90@dijix.com> <2a7532fd-6fee-deb6-c133-6150aaf1b8c2@omnilan.de> To: freebsd-stable@freebsd.org In-Reply-To: <2a7532fd-6fee-deb6-c133-6150aaf1b8c2@omnilan.de> Message-Id: <49390CCC-7687-41C8-BACD-C24D103EFFFF@dijix.com> X-Mailer: Apple Mail (2.3445.104.14) X-Authenticated-Sender: ian@dijix.com X-Scan-Signature: 7bde076138f319ff309658b0ab0f67c9 X-Rspamd-Queue-Id: 493F7R5nBBz4FNJ X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of ian@dijix.com has no SPF policy when checking 185.151.28.65) smtp.mailfrom=ian@dijix.com X-Spamd-Result: default: False [3.57 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dijix.com]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(0.76)[ipnet: 185.151.28.0/24(1.74), asn: 31727(2.13), country: GB(-0.07)]; NEURAL_SPAM_MEDIUM(0.43)[0.431,0]; NEURAL_SPAM_LONG(0.98)[0.981,0]; FROM_NO_DN(0.00)[]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:31727, ipnet:185.151.28.0/24, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; HAS_X_AS(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[156.91.90.146.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-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 23:00:37 -0000 Thank you for the advices, however it turns out it was user error.. I = swapped the drive in from an apple machine, the new drive took ada0 and = my existing drive moved to ada1. I=E2=80=99m just playing with ZFS at the moment and what I didn=E2=80=99t = realise is that the system swap was still assigned to ada0p2 but of = course instead of being on my new ZFS drive was instead pointing to an = apple-hfs data partition on the freshly added drive. For some reason I assumed it was something to do with HFSFUSE and gpart = when in actual fact it was just me not paying attention to the basics! > On 16 Apr 2020, at 18:44, Harry Schmalzbauer > wrote: >=20 > Am 15.04.2020 um 20:35 schrieb ian@dijix.com : >> I have an issue with gpart, it will not let me delete partition = ada0p2 responding with =E2=80=9CDevice Busy=E2=80=9D >> The man page gpart(8) says this may be shown if a partition exists = but I cannot seem to delete partition 2 in my case via gpart delete or = gpart destroy >>=20 >> This is a used disk but new to the machine, I can modify the = partition type and create partitions before and after partition 2 but I = cannot delete it. >>=20 >> Here=E2=80=99s what I have tried so far: >>=20 >>=20 >> root@beastie:~ # gpart show >> =3D> 34 1250263661 ada0 GPT (596G) >> 34 409606 - free - (200M) >> 409640 1249591904 2 freebsd-ufs (596G) >> 1250001544 262151 - free - (128M) >>=20 >> =3D> 40 976773088 ada1 GPT (466G) >> 40 1024 1 freebsd-boot (512K) >> 1064 984 - free - (492K) >> 2048 4194304 2 freebsd-swap (2.0G) >> 4196352 972576768 3 freebsd-zfs (464G) >> 976773120 8 - free - (4.0K) >>=20 >> root@beastie:~ # gpart delete -i2 ada0 >> gpart: Device busy > : > : >> : >> root@beastie:~ # gpart destroy -F ada0 >> gpart: Device busy >=20 > There might still be situations where 'sysctl kern.geom.debugflags=3D16'= helps, but I never needed it in the last years (since 7.x I guess). > Are you sure p2 (-i2) of ada0, most likely home for a ufs filesystem, = isn't mounted anymore? Was it a mountpoint inside a jail? Stopping the = jail might leave network related active sockets blocking the filesystem = (reboot without starting the jail before deleteing the partition should = work in that case). >=20 > -harry From owner-freebsd-stable@freebsd.org Fri Apr 17 02:57:26 2020 Return-Path: Delivered-To: freebsd-stable@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 87E742CF349 for ; Fri, 17 Apr 2020 02:57:26 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from echo.brtsvcs.net (echo.brtsvcs.net [IPv6:2607:f740:c::4ae]) (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 493LNj2sDYz4RWF; Fri, 17 Apr 2020 02:57:25 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from chombo.houseloki.net (unknown [IPv6:2602:41:642b:600::6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "chombo.houseloki.net", Issuer "brtsvcs.net CA" (verified OK)) by echo.brtsvcs.net (Postfix) with ESMTPS id 7C1F838D21; Fri, 17 Apr 2020 02:57:23 +0000 (UTC) Received: from [IPv6:2602:41:642b:630:94ee:76e4:bf6e:dd28] (unknown [IPv6:2602:41:642b:630:94ee:76e4:bf6e:dd28]) by chombo.houseloki.net (Postfix) with ESMTPSA id 7745D1340; Thu, 16 Apr 2020 19:57:22 -0700 (PDT) Subject: Re: support of PCIe NVME drives To: Miroslav Lachman <000.fbsd@quip.cz>, Pete Wright , Kurt Jaeger Cc: freebsd-stable@freebsd.org References: <5a20f111-b2f5-c1a1-acdf-86df43d79ace@quip.cz> <20200416180705.GB39563@home.opsec.eu> <36c9c502-f9b6-fd3d-3ac2-80ab18f8d420@quip.cz> <37408503-c462-97fa-e702-f23fed366f83@nomadlogic.org> From: Mel Pilgrim Message-ID: <85c15e61-160d-36a4-1ea8-3544ae09703c@bluerosetech.com> Date: Thu, 16 Apr 2020 19:57:21 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 493LNj2sDYz4RWF X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of list_freebsd@bluerosetech.com designates 2607:f740:c::4ae as permitted sender) smtp.mailfrom=list_freebsd@bluerosetech.com X-Spamd-Result: default: False [-5.62 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[bluerosetech.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-3.32)[ip: (-8.54), ipnet: 2607:f740:c::/48(-4.19), asn: 36236(-3.81), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36236, ipnet:2607:f740:c::/48, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 02:57:26 -0000 On 2020-04-16 12:30, Miroslav Lachman wrote: > Pete Wright wrote on 04/16/2020 20:23: >> >> >> On 4/16/20 11:12 AM, Miroslav Lachman wrote: >>> Kurt Jaeger wrote on 04/16/2020 20:07: > >> I would try booting via UEFI if you can.  I just installed a laptop >> yesterday which has a nvme root device, it was detected by the >> 12-STABLE snapshot I used to boot from.  no other modifications were >> necessary on my end. > > I changed BIOS settings to use UEFI boot method, booted 12.1 installer > ISO but without luck. Still no NVME disks :( > > You can see it on printscreen from iDRAC https://ibb.co/tPnymL7 > > Anything more I can test? Looking at server specs, the R6515's NVME support is only through the PERC S150 RAID controller. If that's the case, I'm pretty sure you're out of luck. The PERC S-series controllers are software-based RAID that require Dell's Windows or Linux drivers. You'd need a PERC H-series card to get support in FreeBSD. Someone please correct me if I'm wrong? From owner-freebsd-stable@freebsd.org Fri Apr 17 03:50:48 2020 Return-Path: Delivered-To: freebsd-stable@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 749882A8505 for ; Fri, 17 Apr 2020 03:50:48 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 493MZJ0V8Dz4Txn for ; Fri, 17 Apr 2020 03:50:47 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 03H3pLa5022500 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 16 Apr 2020 20:51:28 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: , Miroslav Lachman <000.fbsd@quip.cz>, Pete Wright In-Reply-To: <85c15e61-160d-36a4-1ea8-3544ae09703c@bluerosetech.com> From: Chris Reply-To: bsd-lists@BSDforge.com To: Mel Pilgrim Subject: Re: support of PCIe NVME drives Date: Thu, 16 Apr 2020 20:51:27 -0700 Message-Id: <1ef63241ec8774a39c92b2584c0c2410@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 493MZJ0V8Dz4Txn X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.96 / 15.00]; NEURAL_HAM_MEDIUM(-0.97)[-0.969,0]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81]; NEURAL_HAM_LONG(-0.99)[-0.991,0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 03:50:48 -0000 On Thu, 16 Apr 2020 19:57:21 -0700 Mel Pilgrim list_freebsd@bluerosetech=2Eco= m said > On 2020-04-16 12:30, Miroslav Lachman wrote: > > Pete Wright wrote on 04/16/2020 20:23: > >> > >> > >> On 4/16/20 11:12 AM, Miroslav Lachman wrote: > >>> Kurt Jaeger wrote on 04/16/2020 20:07: > >=20 > >> I would try booting via UEFI if you can=2E=C2=A0 I just installed a lapt= op=20 > >> yesterday which has a nvme root device, it was detected by the=20 > >> 12-STABLE snapshot I used to boot from=2E=C2=A0 no other modifications w= ere=20 > >> necessary on my end=2E > >=20 > > I changed BIOS settings to use UEFI boot method, booted 12=2E1 installer= =20 > > ISO but without luck=2E Still no NVME disks :( > >=20 > > You can see it on printscreen from iDRAC https://ibb=2Eco/tPnymL7 > >=20 > > Anything more I can test? >=20 > Looking at server specs, the R6515's NVME support is only through the=20 > PERC S150 RAID controller=2E If that's the case, I'm pretty sure you're=20 > out of luck=2E The PERC S-series controllers are software-based RAID that= =20 > require Dell's Windows or Linux drivers=2E You'd need a PERC H-series=20 > card to get support in FreeBSD=2E >=20 > Someone please correct me if I'm wrong? As I mentioned=2E I was suspicious of this=2E He should be able to flash the ca= rd, making it a pass=2E I do a lot of them=2E If someone doesn't beat me to it=2E I'l= l dig through what I have, and see if I can't find the right image(s), and pr= ogram(s)=2E --Chris From owner-freebsd-stable@freebsd.org Fri Apr 17 06:18:01 2020 Return-Path: Delivered-To: freebsd-stable@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 6505A2AB8AF for ; Fri, 17 Apr 2020 06:18:01 +0000 (UTC) (envelope-from SRS0=00MP=6B=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 493Qr83N15z4d64 for ; Fri, 17 Apr 2020 06:18:00 +0000 (UTC) (envelope-from SRS0=00MP=6B=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 9201028432; Fri, 17 Apr 2020 08:17:58 +0200 (CEST) Received: from illbsd.quip.test (ip-62-24-92-232.net.upcbroadband.cz [62.24.92.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 1EB2428434; Fri, 17 Apr 2020 08:17:56 +0200 (CEST) Subject: Re: support of PCIe NVME drives To: bsd-lists@BSDforge.com, Mel Pilgrim Cc: freebsd-stable@freebsd.org, Pete Wright References: <1ef63241ec8774a39c92b2584c0c2410@udns.ultimatedns.net> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <66e4b922-8484-aac7-7281-d45baf78366f@quip.cz> Date: Fri, 17 Apr 2020 08:17:56 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <1ef63241ec8774a39c92b2584c0c2410@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 493Qr83N15z4d64 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of SRS0=00MP=6B=quip.cz=000.fbsd@elsa.codelab.cz has no SPF policy when checking 94.124.105.4) smtp.mailfrom=SRS0=00MP=6B=quip.cz=000.fbsd@elsa.codelab.cz X-Spamd-Result: default: False [3.99 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; IP_SCORE(0.82)[ip: (0.27), ipnet: 94.124.104.0/21(0.14), asn: 42000(3.59), country: CZ(0.09)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[quip.cz]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.97)[0.974,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.999,0]; RCVD_IN_DNSWL_NONE(0.00)[4.105.124.94.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=00MP=6B=quip.cz=000.fbsd@elsa.codelab.cz]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=00MP=6B=quip.cz=000.fbsd@elsa.codelab.cz]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 06:18:01 -0000 Chris wrote on 04/17/2020 05:51: > On Thu, 16 Apr 2020 19:57:21 -0700 Mel Pilgrim > list_freebsd@bluerosetech.com said > >> On 2020-04-16 12:30, Miroslav Lachman wrote: >> > Pete Wright wrote on 04/16/2020 20:23: >> >> >> >> >> >> On 4/16/20 11:12 AM, Miroslav Lachman wrote: >> >>> Kurt Jaeger wrote on 04/16/2020 20:07: >> > >> I would try booting via UEFI if you can.  I just installed a >> laptop >> yesterday which has a nvme root device, it was detected by >> the >> 12-STABLE snapshot I used to boot from.  no other modifications >> were >> necessary on my end. >> > > I changed BIOS settings to use UEFI boot method, booted 12.1 >> installer > ISO but without luck. Still no NVME disks :( >> > > You can see it on printscreen from iDRAC https://ibb.co/tPnymL7 >> > > Anything more I can test? >> >> Looking at server specs, the R6515's NVME support is only through the >> PERC S150 RAID controller.  If that's the case, I'm pretty sure you're >> out of luck.  The PERC S-series controllers are software-based RAID >> that require Dell's Windows or Linux drivers.  You'd need a PERC >> H-series card to get support in FreeBSD. That's something I didn't expect at all. So there is nothing which can be fixed on FreeBSD side? :( >> Someone please correct me if I'm wrong? > As I mentioned. I was suspicious of this. He should be able to flash the > card, > making it a pass. I do a lot of them. If someone doesn't beat me to it. > I'll > dig through what I have, and see if I can't find the right image(s), and > program(s). This is rented dedicated machine. I cannot flash anything on it. I can ask the provider if they can install some card. Do you have some recommendation? What is supported by Dell and FreeBSD for ZFS? I really appreciate your help! Kind regards Miroslav Lachman From owner-freebsd-stable@freebsd.org Fri Apr 17 06:41:53 2020 Return-Path: Delivered-To: freebsd-stable@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 1F5AE2ACA76 for ; Fri, 17 Apr 2020 06:41:53 +0000 (UTC) (envelope-from SRS0=00MP=6B=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 493RMh1BvDz4fyK for ; Fri, 17 Apr 2020 06:41:51 +0000 (UTC) (envelope-from SRS0=00MP=6B=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id C165928416; Fri, 17 Apr 2020 08:41:50 +0200 (CEST) Received: from illbsd.quip.test (ip-62-24-92-232.net.upcbroadband.cz [62.24.92.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 7D30628432; Fri, 17 Apr 2020 08:41:49 +0200 (CEST) Subject: Re: support of PCIe NVME drives From: Miroslav Lachman <000.fbsd@quip.cz> To: bsd-lists@BSDforge.com, Mel Pilgrim Cc: Pete Wright , freebsd-stable@freebsd.org References: <1ef63241ec8774a39c92b2584c0c2410@udns.ultimatedns.net> <66e4b922-8484-aac7-7281-d45baf78366f@quip.cz> Message-ID: Date: Fri, 17 Apr 2020 08:41:49 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <66e4b922-8484-aac7-7281-d45baf78366f@quip.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 493RMh1BvDz4fyK X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of SRS0=00MP=6B=quip.cz=000.fbsd@elsa.codelab.cz has no SPF policy when checking 94.124.105.4) smtp.mailfrom=SRS0=00MP=6B=quip.cz=000.fbsd@elsa.codelab.cz X-Spamd-Result: default: False [3.97 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; IP_SCORE(0.82)[ip: (0.27), ipnet: 94.124.104.0/21(0.14), asn: 42000(3.59), country: CZ(0.09)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[quip.cz]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.95)[0.952,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.998,0]; RCVD_IN_DNSWL_NONE(0.00)[4.105.124.94.list.dnswl.org : 127.0.10.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=00MP=6B=quip.cz=000.fbsd@elsa.codelab.cz]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=00MP=6B=quip.cz=000.fbsd@elsa.codelab.cz]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 06:41:53 -0000 Miroslav Lachman wrote on 04/17/2020 08:17: >>> Looking at server specs, the R6515's NVME support is only through the >>> PERC S150 RAID controller.  If that's the case, I'm pretty sure >>> you're out of luck.  The PERC S-series controllers are software-based >>> RAID that require Dell's Windows or Linux drivers.  You'd need a PERC >>> H-series card to get support in FreeBSD. > > That's something I didn't expect at all. So there is nothing which can > be fixed on FreeBSD side? :( > >>> Someone please correct me if I'm wrong? >> As I mentioned. I was suspicious of this. He should be able to flash >> the card, >> making it a pass. I do a lot of them. If someone doesn't beat me to >> it. I'll >> dig through what I have, and see if I can't find the right image(s), >> and program(s). > > This is rented dedicated machine. I cannot flash anything on it. > > I can ask the provider if they can install some card. Do you have some > recommendation? What is supported by Dell and FreeBSD for ZFS? > > I really appreciate your help! I tried to find info about controller in the iDRAC. I walk through the System / Inventory / Hardware Inventory and found nothing about S130 I found this informations PCIe SSD in Slot 1 in Bay 1 Bus: 82 BusProtocol: PCIE Device: 0 DeviceDescription: PCIe SSD in Slot 1 in Bay 1 DeviceProtocol: NVMe-MI1.0 DeviceType: PCIeSSD DriveFormFactor: 2.5 inch FailurePredicted: NO FQDD: Disk.Bay.1:Enclosure.Internal.0-1 FreeSizeInBytes: Information Not Available Function: 0 HotSpareStatus: Information Not Available InstanceID: Disk.Bay.1:Enclosure.Internal.0-1 Manufacturer: INTEL MaximumCapableSpeed: 8 GT/s MediaType: Solid State Drive Model: Dell Express Flash NVMe P4510 1TB SFF NegotiatedSpeed: 8 GT/s PCIeCapableLinkWidth: x4 PCIeNegotiatedLinkWidth: x4 PrimaryStatus: Ok ProductID: a54 RaidStatus: Information Not Available RAIDType: Unknown RemainingRatedWriteEndurance: 100 % Revision: VDV1DP23 SerialNumber: PHLJxxxxxxWF1PxxxxN SizeInBytes: 1000204886016 Slot: 1 State: Ready SystemEraseCapability: CryptographicErasePD PCIe SSD in Slot 1 in Bay 1 - PCI Device BusNumber: 130 DataBusWidth: 4x or x4 Description: Express Flash NVMe 1.0 TB 2.5" U.2 (P4510) DeviceDescription: PCIe SSD in Slot 1 in Bay 1 DeviceNumber: 0 DeviceType: PCIDevice FQDD: Disk.Bay.1:Enclosure.Internal.0-1 FunctionNumber: 0 InstanceID: Disk.Bay.1:Enclosure.Internal.0-1 LastSystemInventoryTime: 2020-04-17T03:21:39 LastUpdateTime: 2020-03-31T13:55:06 Manufacturer: Intel Corporation PCIDeviceID: 0A54 PCISubDeviceID: 2003 PCISubVendorID: 1028 PCIVendorID: 8086 SlotLength: 2.5 Inch Drive Form Factor SlotType: PCI Express Gen 3 SFF-8639 When I go in to menu Configuration / Controllers there is empty list. Is this expected in case of S130? I would really like to fulfil the client needs and run FreeBSD on it. But These R6515 are too new too me. The last PowerEdge I have in hand was R610 / T20. Both working fine with FreeBSD. Miroslav Lachman From owner-freebsd-stable@freebsd.org Fri Apr 17 07:05:15 2020 Return-Path: Delivered-To: freebsd-stable@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 311342AD593 for ; Fri, 17 Apr 2020 07:05:15 +0000 (UTC) (envelope-from mattik@bigpond.net.au) Received: from nsstlmta09p.bpe.bigpond.com (nsstlmta09p.bpe.bigpond.com [203.38.21.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "Openwave Messaging Inc." (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 493Rtb6Lmfz4hj7 for ; Fri, 17 Apr 2020 07:05:11 +0000 (UTC) (envelope-from mattik@bigpond.net.au) Received: from smtp.telstra.com ([10.10.24.4]) by nsstlfep09p-svc.bpe.nexus.telstra.com.au with ESMTP id <20200417070506.QMRP9202.nsstlfep09p-svc.bpe.nexus.telstra.com.au@smtp.telstra.com>; Fri, 17 Apr 2020 17:05:06 +1000 X-RG-Spam: Unknown X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduhedrfeeigdduudehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuuffpveftpgfvgffnuffvtfetpdfqfgfvnecuuegrihhlohhuthemucegtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkjghfofggtgfgsehtjeertdertddvnecuhfhrohhmpehmrghtthhiuchkuceomhgrthhtihhksegsihhgphhonhgurdhnvghtrdgruheqnecuffhomhgrihhnpeguvghllhdrtghomhenucfkphepuddtuddrudeigedruddvrddvfeeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghlohepfihsuddrfihosggslhihsghoohhtrdhnvghtpdhinhgvthepuddtuddrudeigedruddvrddvfeeipdhmrghilhhfrhhomhepoehmrghtthhikhessghighhpohhnugdrnhgvthdrrghuqedprhgtphhtthhopeeotddttddrfhgsshgusehquhhiphdrtgiiqedprhgtphhtthhopeeosghsugdqlhhishhtshesuefuffhfohhrghgvrdgtohhmqedprhgtphhtthhopeeofhhrvggvsghsugdqshhtrggslhgvsehfrhgvvggsshgurdhorhhgqedprhgtphhtthhopeeolhhishhtpghfrhgvvggsshgusegslhhuvghrohhsvghtvggthhdrtghomheqpdhrtghpthhtohepoehpvghtvgesnhhomhgrughlohhgihgtrdhorhhgqe X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-RG-VS-CLASS: clean X-Authentication-Info: Submitted using ID mattik@bigpond.net.au Received: from ws1.wobblyboot.net (101.164.12.236) by smtp.telstra.com (5.8.420) (authenticated as mattik@bigpond.net.au) id 5E7BBFAF0876B54D; Fri, 17 Apr 2020 17:05:06 +1000 Date: Fri, 17 Apr 2020 17:04:54 +1000 From: matti k To: Miroslav Lachman <000.fbsd@quip.cz> Cc: bsd-lists@BSDforge.com, Mel Pilgrim , Pete Wright , freebsd-stable@freebsd.org Subject: Re: support of PCIe NVME drives Message-ID: <20200417170454.6505c465@ws1.wobblyboot.net> In-Reply-To: References: <1ef63241ec8774a39c92b2584c0c2410@udns.ultimatedns.net> <66e4b922-8484-aac7-7281-d45baf78366f@quip.cz> X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; amd64-portbld-freebsd12.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 493Rtb6Lmfz4hj7 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=bigpond.net.au; spf=pass (mx1.freebsd.org: domain of mattik@bigpond.net.au designates 203.38.21.9 as permitted sender) smtp.mailfrom=mattik@bigpond.net.au X-Spamd-Result: default: False [-2.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:203.38.21.0/24]; FREEMAIL_FROM(0.00)[bigpond.net.au]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[bigpond.net.au,none]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[9.21.38.203.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[bigpond.net.au]; ASN(0.00)[asn:1221, ipnet:203.36.0.0/14, country:AU]; IP_SCORE(0.00)[ipnet: 203.36.0.0/14(-4.16), asn: 1221(-2.71), country: AU(0.01)]; RECEIVED_SPAMHAUS_PBL(0.00)[236.12.164.101.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 07:05:15 -0000 On Fri, 17 Apr 2020 08:41:49 +0200 Miroslav Lachman <000.fbsd@quip.cz> wrote: > Miroslav Lachman wrote on 04/17/2020 08:17: > > > When I go in to menu Configuration / Controllers there is empty list. > Is this expected in case of S130? > > I would really like to fulfil the client needs and run FreeBSD on it. > But These R6515 are too new too me. The last PowerEdge I have in hand > was R610 / T20. Both working fine with FreeBSD. > can you look up the hardware using dell support? using my local one https://www.dell.com/support/home/au/en/aubsd1 and enter asset tag or serial number. It will help identify parts that were shipped. I suspect if you add an extra PCIe card it may or may not be able to boot from it? cheers, matti From owner-freebsd-stable@freebsd.org Fri Apr 17 18:35:42 2020 Return-Path: Delivered-To: freebsd-stable@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 486B82C4549; Fri, 17 Apr 2020 18:35:42 +0000 (UTC) (envelope-from freqlabs@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 493lCL1Fwdz4QnB; Fri, 17 Apr 2020 18:35:42 +0000 (UTC) (envelope-from freqlabs@FreeBSD.org) Received: from [IPv6:2600:1700:358a:c660:305b:9aa6:7c2d:c818] (unknown [IPv6:2600:1700:358a:c660:305b:9aa6:7c2d:c818]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: freqlabs/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 0A026FBFF; Fri, 17 Apr 2020 18:35:42 +0000 (UTC) (envelope-from freqlabs@FreeBSD.org) From: Ryan Moeller Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: OpenZFS port updated Message-Id: Date: Fri, 17 Apr 2020 14:35:41 -0400 To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 18:35:42 -0000 FreeBSD support has been merged into the master branch of the = openzfs/zfs repository, and the FreeBSD ports have been switched to this = branch. OpenZFS brings many exciting features to FreeBSD, including: * native encryption * improved TRIM implementation * most recently, persistent L2ARC Of course, avoid upgrading your pools if you want to keep the option to = go back to the base ZFS. OpenZFS can be installed alongside the base ZFS. Change your loader.conf = entry to openzfs_load=3D=E2=80=9CYES=E2=80=9D to load the OpenZFS module = at boot, and set PATH to find the tools in /usr/local/sbin before /sbin. = The base zfs tools are still basically functional with the OpenZFS = module, so changing PATH in rc is not strictly necessary. The FreeBSD loader can boot from pools with the encryption feature = enabled, but the root/bootenv datasets must not be encrypted themselves. The FreeBSD platform support in OpenZFS does not yet include all = features present in FreeBSD=E2=80=99s ZFS. Some notable changes/missing = features include: * many sysctl names have changed (legacy compat sysctls should be added = at some point)=20 * zfs send progress reporting in process title via setproctitle * extended 'zfs holds -r' = (https://svnweb.freebsd.org/base?view=3Drevision&revision=3D290015) * vdev ashift optimizations = (https://svnweb.freebsd.org/base?view=3Drevision&revision=3D254591) * pre-mountroot zpool.cache loading (for automatic pool imports) To the last point, this mainly effects the case where / is on ZFS and = /boot is not or is on a different pool. OpenZFS cannot handle this case = yet, but work is in progress to cover that use case. Booting directly = from ZFS does work. If there are pools that need to be imported at boot other than the boot = pool, OpenZFS does not automatically import yet, and it uses = /etc/zfs/zpool.cache rather than /boot/zfs/zpool.cache to keep track of = imported pools. To ensure all pool imports occur automatically, a = simple edit to /etc/rc.d/zfs will suffice: diff --git a/libexec/rc/rc.d/zfs b/libexec/rc/rc.d/zfs index 2d35f9b5464..8e4aef0b1b3 100755 --- a/libexec/rc/rc.d/zfs +++ b/libexec/rc/rc.d/zfs @@ -25,6 +25,13 @@ zfs_start_jail() =20 zfs_start_main() { + local cachefile + + for cachefile in /boot/zfs/zpool.cache /etc/zfs/zpool.cache; do + if [ -f $cachefile ]; then + zpool import -c $cachefile -a + fi + done zfs mount -va zfs share -a if [ ! -r /etc/zfs/exports ]; then This will probably not be needed long-term. It is not necessary if the = boot pool is the only pool. Happy testing :) - Ryan= From owner-freebsd-stable@freebsd.org Fri Apr 17 20:14:45 2020 Return-Path: Delivered-To: freebsd-stable@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 01C812C7AD6; Fri, 17 Apr 2020 20:14:45 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from echo.brtsvcs.net (echo.brtsvcs.net [IPv6:2607:f740:c::4ae]) (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 493nPc1sGXz4cJM; Fri, 17 Apr 2020 20:14:44 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from chombo.houseloki.net (unknown [IPv6:2602:41:642b:600::6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "chombo.houseloki.net", Issuer "brtsvcs.net CA" (verified OK)) by echo.brtsvcs.net (Postfix) with ESMTPS id 9C6BC38D28; Fri, 17 Apr 2020 20:14:37 +0000 (UTC) Received: from [IPv6:2602:41:642b:630:6c16:8993:6207:3a64] (unknown [IPv6:2602:41:642b:630:6c16:8993:6207:3a64]) by chombo.houseloki.net (Postfix) with ESMTPSA id B9C9F17B7; Fri, 17 Apr 2020 13:14:36 -0700 (PDT) Subject: Re: OpenZFS port updated To: Ryan Moeller , freebsd-current@freebsd.org, freebsd-stable@freebsd.org References: From: Mel Pilgrim Message-ID: Date: Fri, 17 Apr 2020 13:14:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 493nPc1sGXz4cJM X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of list_freebsd@bluerosetech.com designates 2607:f740:c::4ae as permitted sender) smtp.mailfrom=list_freebsd@bluerosetech.com X-Spamd-Result: default: False [-5.64 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; 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]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[bluerosetech.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-3.34)[ip: (-8.60), ipnet: 2607:f740:c::/48(-4.22), asn: 36236(-3.81), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36236, ipnet:2607:f740:c::/48, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 20:14:45 -0000 On 2020-04-17 11:35, Ryan Moeller wrote: > The FreeBSD platform support in OpenZFS does not yet include all > features present in FreeBSD’s ZFS. Some notable changes/missing > features include: [...] > * pre-mountroot zpool.cache loading (for automatic pool imports) > > To the last point, this mainly effects the case where / is on ZFS and > /boot is not or is on a different pool. OpenZFS cannot handle this > case yet, but work is in progress to cover that use case. Booting > directly from ZFS does work. To be clear, this means OpenZFS currently does not support / on GELI-encrypted disks, correct? From owner-freebsd-stable@freebsd.org Fri Apr 17 20:15:48 2020 Return-Path: Delivered-To: freebsd-stable@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 676712C7D36; Fri, 17 Apr 2020 20:15:48 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 493nQq4Sfyz4cd5; Fri, 17 Apr 2020 20:15:47 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 1493475A; Fri, 17 Apr 2020 16:15:46 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 17 Apr 2020 16:15:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsco.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=I 5DOPajtPdJLr1Ijxwf3nO45bOWxaNJ6kZwdUHpMZrs=; b=ldBChjFnzttkQ4Xra xIfqV6sM3hvXVY/Tttjgncj0R3Nbgf8fQxyni3baZ+9rz72x8tHEWlxyfBCyyyoE IilEtXwwLL3LEmuaLqFzScIN+Gd1O3tgpF7abIowqiGxkOe7XX7KY8RqAjlJLBro EzdK/KQy5W9D28sJhzQyRzXJqBEKLln5EhnuXRCyWFfdpnGWhnyzxfYf49b2pAE5 HfOP8uAlOLQlOpeDh4xZJkX0pgAJ1wRKjytiZZdoub7wE8/sIcdbmpix+JdKsthG +OyEr5CDGTF2OV+2BqB7f7WpA1hHaTGJY99lW3wHBK57T6eRQOXSsllhtd9XTjJJ bqJEg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=I5DOPajtPdJLr1Ijxwf3nO45bOWxaNJ6kZwdUHpMZ rs=; b=GQhwX/fYHVD16GtJ0i+5QaKUOQatwfToeaN5I/jmFumj+LZGIVKyPeo7d RiteIs5wXm166bfjzVDdswFVDZXnxMtcoRMEU0cKUDTEWW92dYkhYUP+ggVzaUku UxgeqVTLEkInipKs20aJ/wHemNSg/ursjq1oKBOXdjE7fNOV6RGSCu0y05zNqf5+ 53YZh5yBl5mIeV3ois1LXx0zTmXsrqUUpCW6tSA0i1UL2n5XzuD2VC+Bb+5y9UTp ONVjK8WrDQimg/0kCNQtNwxNdCLCg2a99n1Os7XjqLAfl44YDQq/TJhP67Ad4pEE hUUDjZxRlsFVSOekTPAFo9ILZmAcg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrfeejgddugeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfuhfgjfffgkfhfvffosehtqh hmtdhhtdejnecuhfhrohhmpefutghothhtucfnohhnghcuoehstghothhtlhesshgrmhhs tghordhorhhgqeenucffohhmrghinhepfhhrvggvsghsugdrohhrghenucfkphepkedrge eirdekledrvddufeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpehstghothhtlhesshgrmhhstghordhorhhg X-ME-Proxy: Received: from [192.168.0.114] (unknown [8.46.89.213]) by mail.messagingengine.com (Postfix) with ESMTPA id 3D8A13280069; Fri, 17 Apr 2020 16:15:45 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Subject: Re: OpenZFS port updated From: Scott Long In-Reply-To: Date: Fri, 17 Apr 2020 14:15:44 -0600 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6333818E-63DA-4851-8496-9B0CE82145A3@samsco.org> References: To: Ryan Moeller X-Mailer: Apple Mail (2.3601.0.10) X-Rspamd-Queue-Id: 493nQq4Sfyz4cd5 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=samsco.org header.s=fm3 header.b=ldBChjFn; dkim=pass header.d=messagingengine.com header.s=fm2 header.b=GQhwX/fY; dmarc=none; spf=pass (mx1.freebsd.org: domain of scottl@samsco.org designates 64.147.123.21 as permitted sender) smtp.mailfrom=scottl@samsco.org X-Spamd-Result: default: False [-5.60 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[samsco.org:s=fm3,messagingengine.com:s=fm2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.21:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MV_CASE(0.50)[]; DMARC_NA(0.00)[samsco.org]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[4]; IP_SCORE(-3.50)[ip: (-9.86), ipnet: 64.147.123.0/24(-4.92), asn: 11403(-2.69), country: US(-0.05)]; DKIM_TRACE(0.00)[samsco.org:+,messagingengine.com:+]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:11403, ipnet:64.147.123.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[21.123.147.64.list.dnswl.org : 127.0.5.1] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 20:15:48 -0000 Is the intention to eventually replace the zfs code in src/ ? What will = be the long-term relationship between src/ and ports/ for this? Scott > On Apr 17, 2020, at 12:35 PM, Ryan Moeller = wrote: >=20 > FreeBSD support has been merged into the master branch of the = openzfs/zfs repository, and the FreeBSD ports have been switched to this = branch. >=20 > OpenZFS brings many exciting features to FreeBSD, including: > * native encryption > * improved TRIM implementation > * most recently, persistent L2ARC >=20 > Of course, avoid upgrading your pools if you want to keep the option = to go back to the base ZFS. >=20 > OpenZFS can be installed alongside the base ZFS. Change your = loader.conf entry to openzfs_load=3D=E2=80=9CYES=E2=80=9D to load the = OpenZFS module at boot, and set PATH to find the tools in = /usr/local/sbin before /sbin. The base zfs tools are still basically = functional with the OpenZFS module, so changing PATH in rc is not = strictly necessary. >=20 > The FreeBSD loader can boot from pools with the encryption feature = enabled, but the root/bootenv datasets must not be encrypted themselves. >=20 > The FreeBSD platform support in OpenZFS does not yet include all = features present in FreeBSD=E2=80=99s ZFS. Some notable changes/missing = features include: > * many sysctl names have changed (legacy compat sysctls should be = added at some point)=20 > * zfs send progress reporting in process title via setproctitle > * extended 'zfs holds -r' = (https://svnweb.freebsd.org/base?view=3Drevision&revision=3D290015) > * vdev ashift optimizations = (https://svnweb.freebsd.org/base?view=3Drevision&revision=3D254591) > * pre-mountroot zpool.cache loading (for automatic pool imports) >=20 > To the last point, this mainly effects the case where / is on ZFS and = /boot is not or is on a different pool. OpenZFS cannot handle this case = yet, but work is in progress to cover that use case. Booting directly = from ZFS does work. >=20 > If there are pools that need to be imported at boot other than the = boot pool, OpenZFS does not automatically import yet, and it uses = /etc/zfs/zpool.cache rather than /boot/zfs/zpool.cache to keep track of = imported pools. To ensure all pool imports occur automatically, a = simple edit to /etc/rc.d/zfs will suffice: >=20 > diff --git a/libexec/rc/rc.d/zfs b/libexec/rc/rc.d/zfs > index 2d35f9b5464..8e4aef0b1b3 100755 > --- a/libexec/rc/rc.d/zfs > +++ b/libexec/rc/rc.d/zfs > @@ -25,6 +25,13 @@ zfs_start_jail() >=20 > zfs_start_main() > { > + local cachefile > + > + for cachefile in /boot/zfs/zpool.cache /etc/zfs/zpool.cache; do > + if [ -f $cachefile ]; then > + zpool import -c $cachefile -a > + fi > + done > zfs mount -va > zfs share -a > if [ ! -r /etc/zfs/exports ]; then >=20 > This will probably not be needed long-term. It is not necessary if the = boot pool is the only pool. >=20 > Happy testing :) >=20 > - Ryan > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Fri Apr 17 20:31:24 2020 Return-Path: Delivered-To: freebsd-stable@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 CF23D2A8B5D; Fri, 17 Apr 2020 20:31:24 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 493nmr5CxTz4fY0; Fri, 17 Apr 2020 20:31:24 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id A65A810ABA; Fri, 17 Apr 2020 20:31:24 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f181.google.com with SMTP id c16so3167079qtv.1; Fri, 17 Apr 2020 13:31:24 -0700 (PDT) X-Gm-Message-State: AGi0PuYIQMdkyALY4uIyTlX70FwpdSjRzBYfYLVsiXUXW2swYT9Y+uaN am+P2SZrLafuyLTzbSZsWbokT+HVRl45AvNewpQ= X-Google-Smtp-Source: APiQypImNWurV+3om2JQHeW4BQLPqd6ythV5w88KW8URIuD3X/v16/MWlyk3a480GvbCSeGEbF2aFl8tVm6P2+aurns= X-Received: by 2002:ac8:4254:: with SMTP id r20mr4711204qtm.211.1587155484292; Fri, 17 Apr 2020 13:31:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kyle Evans Date: Fri, 17 Apr 2020 15:31:10 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: OpenZFS port updated To: Mel Pilgrim Cc: Ryan Moeller , FreeBSD Current , FreeBSD-STABLE Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 20:31:24 -0000 On Fri, Apr 17, 2020 at 3:14 PM Mel Pilgrim wrote: > > On 2020-04-17 11:35, Ryan Moeller wrote: > > The FreeBSD platform support in OpenZFS does not yet include all > > features present in FreeBSD=E2=80=99s ZFS. Some notable changes/missing > > features include: > [...] > > * pre-mountroot zpool.cache loading (for automatic pool imports) > > > > To the last point, this mainly effects the case where / is on ZFS and > > /boot is not or is on a different pool. OpenZFS cannot handle this > > case yet, but work is in progress to cover that use case. Booting > > directly from ZFS does work. > > To be clear, this means OpenZFS currently does not support / on > GELI-encrypted disks, correct? If you have a legacy setup with a bootpool, that is correct. Since 12.0+ the bootpool is almost completely redundant except for some odd setup that I can never remember. For legacy setups, the bootpool can/should be merged into your root pool if it's feasible. Thanks, Kyle Evans From owner-freebsd-stable@freebsd.org Fri Apr 17 20:34:52 2020 Return-Path: Delivered-To: freebsd-stable@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 2986B2A921B; Fri, 17 Apr 2020 20:34:52 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 493nrq1TGtz4gKm; Fri, 17 Apr 2020 20:34:50 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from [194.32.164.30] ([194.32.164.30]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id 03HKYnkC014447; Fri, 17 Apr 2020 21:34:49 +0100 (BST) (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: OpenZFS port updated From: Bob Bishop In-Reply-To: Date: Fri, 17 Apr 2020 21:34:49 +0100 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ryan Moeller X-Mailer: Apple Mail (2.3273) X-Rspamd-Queue-Id: 493nrq1TGtz4gKm X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rb@gid.co.uk designates 194.32.164.250 as permitted sender) smtp.mailfrom=rb@gid.co.uk X-Spamd-Result: default: False [-2.21 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; MV_CASE(0.50)[]; DMARC_NA(0.00)[gid.co.uk]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(-0.51)[ip: (-1.85), ipnet: 194.32.164.0/24(-0.93), asn: 42831(0.29), country: GB(-0.07)]; RCVD_IN_DNSWL_NONE(0.00)[250.164.32.194.list.dnswl.org : 127.0.10.0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42831, ipnet:194.32.164.0/24, country:GB]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 20:34:52 -0000 Hi, > On 17 Apr 2020, at 19:35, Ryan Moeller wrote: >=20 > FreeBSD support has been merged into the master branch of the = openzfs/zfs repository, and the FreeBSD ports have been switched to this = branch. >=20 > OpenZFS brings many exciting features to FreeBSD, including: > * native encryption > * improved TRIM implementation [etc] Note that unlike native ZFS, OpenZFS doesn=E2=80=99t (last time I = looked) support autotrim by default - you have to enable it explicitly. -- Bob Bishop rb@gid.co.uk From owner-freebsd-stable@freebsd.org Fri Apr 17 20:56:45 2020 Return-Path: Delivered-To: freebsd-stable@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 382442AA1A1; Fri, 17 Apr 2020 20:56:45 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [174.136.98.114]) (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 "mail.nomadlogic.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 493pL34DY3z3DhS; Fri, 17 Apr 2020 20:56:43 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.206] (cpe-23-243-162-239.socal.res.rr.com [23.243.162.239]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 8cf77812 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Fri, 17 Apr 2020 20:56:36 +0000 (UTC) Subject: Re: OpenZFS port updated To: Ryan Moeller , freebsd-current@freebsd.org, freebsd-stable@freebsd.org References: From: Pete Wright Message-ID: <6b25375d-0945-f01e-264e-ee410195fa97@nomadlogic.org> Date: Fri, 17 Apr 2020 13:56:31 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 493pL34DY3z3DhS X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 174.136.98.114 as permitted sender) smtp.mailfrom=pete@nomadlogic.org X-Spamd-Result: default: False [-5.07 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[239.162.243.23.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[nomadlogic.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; IP_SCORE(-2.77)[ip: (-9.24), ipnet: 174.136.96.0/20(-4.15), asn: 25795(-0.42), country: US(-0.05)]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:25795, ipnet:174.136.96.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 20:56:45 -0000 On 4/17/20 11:35 AM, Ryan Moeller wrote: > FreeBSD support has been merged into the master branch of the openzfs/zfs repository, and the FreeBSD ports have been switched to this branch. Congratulations on this effort - big milestone! > OpenZFS brings many exciting features to FreeBSD, including: > * native encryption Is there a good doc reference on available for using this?  I believe this is zfs filesystem level encryption and not a replacement for our existing full-disk-encryption scheme that currently works? thanks again! -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-stable@freebsd.org Fri Apr 17 21:40:26 2020 Return-Path: Delivered-To: freebsd-stable@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 4A5342ABFE5; Fri, 17 Apr 2020 21:40:26 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from echo.brtsvcs.net (echo.brtsvcs.net [IPv6:2607:f740:c::4ae]) (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 493qJT1Lbjz3KF0; Fri, 17 Apr 2020 21:40:25 +0000 (UTC) (envelope-from list_freebsd@bluerosetech.com) Received: from chombo.houseloki.net (65-100-43-2.dia.static.qwest.net [65.100.43.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "chombo.houseloki.net", Issuer "brtsvcs.net CA" (verified OK)) by echo.brtsvcs.net (Postfix) with ESMTPS id AA49638D28; Fri, 17 Apr 2020 21:40:23 +0000 (UTC) Received: from [IPv6:2602:41:642b:630:6c16:8993:6207:3a64] (unknown [IPv6:2602:41:642b:630:6c16:8993:6207:3a64]) by chombo.houseloki.net (Postfix) with ESMTPSA id 2AF9017F4; Fri, 17 Apr 2020 14:40:23 -0700 (PDT) Subject: Re: OpenZFS port updated To: Kyle Evans Cc: FreeBSD Current , FreeBSD-STABLE Mailing List , Ryan Moeller References: From: Mel Pilgrim Message-ID: <8abb14b2-7426-559d-af7e-c339fa130515@bluerosetech.com> Date: Fri, 17 Apr 2020 14:40:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 493qJT1Lbjz3KF0 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of list_freebsd@bluerosetech.com designates 2607:f740:c::4ae as permitted sender) smtp.mailfrom=list_freebsd@bluerosetech.com X-Spamd-Result: default: False [-5.65 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+mx:relay3.brtsvcs.net]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[bluerosetech.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(-3.35)[ip: (-8.66), ipnet: 2607:f740:c::/48(-4.25), asn: 36236(-3.81), country: US(-0.05)]; TO_DN_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36236, ipnet:2607:f740:c::/48, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 21:40:26 -0000 On 2020-04-17 13:31, Kyle Evans wrote: > On Fri, Apr 17, 2020 at 3:14 PM Mel Pilgrim > wrote: >> >> On 2020-04-17 11:35, Ryan Moeller wrote: >>> The FreeBSD platform support in OpenZFS does not yet include all >>> features present in FreeBSD’s ZFS. Some notable changes/missing >>> features include: >> [...] >>> * pre-mountroot zpool.cache loading (for automatic pool imports) >>> >>> To the last point, this mainly effects the case where / is on ZFS and >>> /boot is not or is on a different pool. OpenZFS cannot handle this >>> case yet, but work is in progress to cover that use case. Booting >>> directly from ZFS does work. >> >> To be clear, this means OpenZFS currently does not support / on >> GELI-encrypted disks, correct? > > If you have a legacy setup with a bootpool, that is correct. Since > 12.0+ the bootpool is almost completely redundant except for some odd > setup that I can never remember. For legacy setups, the bootpool > can/should be merged into your root pool if it's feasible. Yes, these are the "legacy" configuration with a small, unecrypted pool containing /boot and the keys to attach the encrypted root pool. Could the case you're thinking of be avoiding manual entry of a password at boot? From owner-freebsd-stable@freebsd.org Fri Apr 17 21:54:15 2020 Return-Path: Delivered-To: freebsd-stable@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 016422ACEFE; Fri, 17 Apr 2020 21:54:15 +0000 (UTC) (envelope-from freqlabs@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 493qcQ5yKmz3Lk6; Fri, 17 Apr 2020 21:54:14 +0000 (UTC) (envelope-from freqlabs@FreeBSD.org) Received: from [IPv6:2600:1700:358a:c660:305b:9aa6:7c2d:c818] (unknown [IPv6:2600:1700:358a:c660:305b:9aa6:7c2d:c818]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: freqlabs/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id A4B87114B0; Fri, 17 Apr 2020 21:54:14 +0000 (UTC) (envelope-from freqlabs@FreeBSD.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: OpenZFS port updated From: Ryan Moeller In-Reply-To: <6b25375d-0945-f01e-264e-ee410195fa97@nomadlogic.org> Date: Fri, 17 Apr 2020 17:54:14 -0400 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0ED41E6B-9C57-405B-84BE-1161F012A974@FreeBSD.org> References: <6b25375d-0945-f01e-264e-ee410195fa97@nomadlogic.org> To: Pete Wright X-Mailer: Apple Mail (2.3608.80.23.2.2) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 21:54:15 -0000 > On Apr 17, 2020, at 4:56 PM, Pete Wright wrote: >=20 > On 4/17/20 11:35 AM, Ryan Moeller wrote: >> FreeBSD support has been merged into the master branch of the = openzfs/zfs repository, and the FreeBSD ports have been switched to this = branch. > Congratulations on this effort - big milestone! >> OpenZFS brings many exciting features to FreeBSD, including: >> * native encryption > Is there a good doc reference on available for using this? I believe = this is zfs filesystem level encryption and not a replacement for our = existing full-disk-encryption scheme that currently works? I=E2=80=99m not aware of a good current doc for this. If anyone = finds/writes something, please post it! There are some old resources you can find with a quick search that do a = pretty good job of covering the basic ideas, but I think the exact = syntax of commands may be slightly changed in the final implementation. The encryption is performed at a filesystem level (per-dataset). > thanks again! > -pete >=20 > --=20 > Pete Wright > pete@nomadlogic.org > @nomadlogicLA >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@freebsd.org Fri Apr 17 22:12:07 2020 Return-Path: Delivered-To: freebsd-stable@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 B22962AD7C5; Fri, 17 Apr 2020 22:12:07 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 493r134MhGz3N96; Fri, 17 Apr 2020 22:12:07 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id 5A7F81171B; Fri, 17 Apr 2020 22:12:07 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-lf1-f42.google.com with SMTP id w145so3054736lff.3; Fri, 17 Apr 2020 15:12:07 -0700 (PDT) X-Gm-Message-State: AGi0PubQFsc0rTSk1oHuxbshJiwDEEt5Xg7vuQzCqlghmKi+y7xvcdAk DBHrOKKDrxI+05pNkiQrCysOfZbWvXUdieOQZ1w= X-Google-Smtp-Source: APiQypLnNI/LTN5vPsgpaQ8E77N++Wun83bLgFb5pPilrKLNPrBEmTJ7d9CAzUMoJUwJqt7LkyHIvehohYZYhdQdxgI= X-Received: by 2002:a19:c602:: with SMTP id w2mr211775lff.74.1587161525910; Fri, 17 Apr 2020 15:12:05 -0700 (PDT) MIME-Version: 1.0 References: <6333818E-63DA-4851-8496-9B0CE82145A3@samsco.org> In-Reply-To: <6333818E-63DA-4851-8496-9B0CE82145A3@samsco.org> From: Matthew Macy Date: Fri, 17 Apr 2020 15:11:54 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: OpenZFS port updated To: Scott Long Cc: Ryan Moeller , freebsd-current , freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 22:12:07 -0000 On Fri, Apr 17, 2020 at 1:16 PM Scott Long wrote: > > Is the intention to eventually replace the zfs code in src/ ? Yes. Once the feature gap is filled in and most of the potential POLA violations are fixed. > What will be the long-term relationship between src/ and ports/ for this? OpenZFS users on 12 will use the port indefinitely. HEAD will presumably be updated whenever a point release is created upstream. Ultimately I can see two versions of the port, one that tracks master for HEAD and 12 and one that tracks only the latest release for 12 users. -M > > Scott > > > > On Apr 17, 2020, at 12:35 PM, Ryan Moeller wrote= : > > > > FreeBSD support has been merged into the master branch of the openzfs/z= fs repository, and the FreeBSD ports have been switched to this branch. > > > > OpenZFS brings many exciting features to FreeBSD, including: > > * native encryption > > * improved TRIM implementation > > * most recently, persistent L2ARC > > > > Of course, avoid upgrading your pools if you want to keep the option to= go back to the base ZFS. > > > > OpenZFS can be installed alongside the base ZFS. Change your loader.con= f entry to openzfs_load=3D=E2=80=9CYES=E2=80=9D to load the OpenZFS module = at boot, and set PATH to find the tools in /usr/local/sbin before /sbin. Th= e base zfs tools are still basically functional with the OpenZFS module, so= changing PATH in rc is not strictly necessary. > > > > The FreeBSD loader can boot from pools with the encryption feature enab= led, but the root/bootenv datasets must not be encrypted themselves. > > > > The FreeBSD platform support in OpenZFS does not yet include all featur= es present in FreeBSD=E2=80=99s ZFS. Some notable changes/missing features = include: > > * many sysctl names have changed (legacy compat sysctls should be added= at some point) > > * zfs send progress reporting in process title via setproctitle > > * extended 'zfs holds -r' (https://svnweb.freebsd.org/base?view=3Drevis= ion&revision=3D290015) > > * vdev ashift optimizations (https://svnweb.freebsd.org/base?view=3Drev= ision&revision=3D254591) > > * pre-mountroot zpool.cache loading (for automatic pool imports) > > > > To the last point, this mainly effects the case where / is on ZFS and /= boot is not or is on a different pool. OpenZFS cannot handle this case yet,= but work is in progress to cover that use case. Booting directly from ZFS = does work. > > > > If there are pools that need to be imported at boot other than the boot= pool, OpenZFS does not automatically import yet, and it uses /etc/zfs/zpoo= l.cache rather than /boot/zfs/zpool.cache to keep track of imported pools. = To ensure all pool imports occur automatically, a simple edit to /etc/rc.d= /zfs will suffice: > > > > diff --git a/libexec/rc/rc.d/zfs b/libexec/rc/rc.d/zfs > > index 2d35f9b5464..8e4aef0b1b3 100755 > > --- a/libexec/rc/rc.d/zfs > > +++ b/libexec/rc/rc.d/zfs > > @@ -25,6 +25,13 @@ zfs_start_jail() > > > > zfs_start_main() > > { > > + local cachefile > > + > > + for cachefile in /boot/zfs/zpool.cache /etc/zfs/zpool.cache; do > > + if [ -f $cachefile ]; then > > + zpool import -c $cachefile -a > > + fi > > + done > > zfs mount -va > > zfs share -a > > if [ ! -r /etc/zfs/exports ]; then > > > > This will probably not be needed long-term. It is not necessary if the = boot pool is the only pool. > > > > Happy testing :) > > > > - Ryan > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-stable@freebsd.org Sat Apr 18 02:33:06 2020 Return-Path: Delivered-To: freebsd-stable@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 148DD2B5126 for ; Sat, 18 Apr 2020 02:33:06 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 493xp91qfrz4F9Z for ; Sat, 18 Apr 2020 02:33:04 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 03I2Xh5U091567 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 17 Apr 2020 19:33:50 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: In-Reply-To: <66e4b922-8484-aac7-7281-d45baf78366f@quip.cz> From: Chris Reply-To: bsd-lists@BSDforge.com To: Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: support of PCIe NVME drives Date: Fri, 17 Apr 2020 19:33:49 -0700 Message-Id: <35795c0723caa631c6fcb33b4c95e029@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 493xp91qfrz4F9Z X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.91 / 15.00]; NEURAL_HAM_MEDIUM(-0.92)[-0.922,0]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81]; NEURAL_HAM_LONG(-0.99)[-0.986,0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2020 02:33:06 -0000 On Fri, 17 Apr 2020 08:17:56 +0200 Miroslav Lachman 000=2Efbsd@quip=2Ecz said > Chris wrote on 04/17/2020 05:51: > > On Thu, 16 Apr 2020 19:57:21 -0700 Mel Pilgrim=20 > > list_freebsd@bluerosetech=2Ecom said > >=20 > >> On 2020-04-16 12:30, Miroslav Lachman wrote: > >> > Pete Wright wrote on 04/16/2020 20:23: > >> >> > >> >> > >> >> On 4/16/20 11:12 AM, Miroslav Lachman wrote: > >> >>> Kurt Jaeger wrote on 04/16/2020 20:07: > >> > >> I would try booting via UEFI if you can=2E=C2=A0 I just installed a= =20 > >> laptop >> yesterday which has a nvme root device, it was detected by= =20 > >> the >> 12-STABLE snapshot I used to boot from=2E=C2=A0 no other modifica= tions=20 > >> were >> necessary on my end=2E > >> > > I changed BIOS settings to use UEFI boot method, booted 12=2E1=20 > >> installer > ISO but without luck=2E Still no NVME disks :( > >> > > You can see it on printscreen from iDRAC https://ibb=2Eco/tPnymL7 > >> > > Anything more I can test? > >> > >> Looking at server specs, the R6515's NVME support is only through the= =20 > >> PERC S150 RAID controller=2E=C2=A0 If that's the case, I'm pretty sure y= ou're=20 > >> out of luck=2E=C2=A0 The PERC S-series controllers are software-based RA= ID=20 > >> that require Dell's Windows or Linux drivers=2E=C2=A0 You'd need a PERC= =20 > >> H-series card to get support in FreeBSD=2E >=20 > That's something I didn't expect at all=2E So there is nothing which can=20 > be fixed on FreeBSD side? :( >=20 > >> Someone please correct me if I'm wrong? > > As I mentioned=2E I was suspicious of this=2E He should be able to flash th= e=20 > > card, > > making it a pass=2E I do a lot of them=2E If someone doesn't beat me to it=2E= =20 > > I'll > > dig through what I have, and see if I can't find the right image(s), an= d=20 > > program(s)=2E >=20 > This is rented dedicated machine=2E I cannot flash anything on it=2E Apologies for the late reply=2E Unfortunately $JOB requires me to $WORK=2E :( OK Given these are rentals=2E Probably the most I could supply for your needs are images that allow you to poll, and change settings of the controller(s)=2E I have cd9660, and USB flash images of the utilities for the 100-300 series HBAs as provided by LSI/AvGO=2E They boot to (MS)DOS, or to an (U)EFI prompt=2E Having read what I can; the S150 controller is Software controlled (likely explaining the "S" in it's model number), and a= s I understand it *shouldn't* require any flashing=2E As I also understand you *should* be able to access control of it through UEFI configs=2E I *think* accessed via F2=2E Apologies if this comes too late, or you've already solved this=2E If you're still interested in the management software I have for the 100-30= 0 series=2E Let me know, and I'll attach a copy, or provide a link for you as needed=2E --Chris >=20 > I can ask the provider if they can install some card=2E Do you have some=20 > recommendation? What is supported by Dell and FreeBSD for ZFS? >=20 > I really appreciate your help! >=20 > Kind regards > Miroslav Lachman > _______________________________________________ > freebsd-stable@freebsd=2Eorg mailing list > https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd=2Eorg" From owner-freebsd-stable@freebsd.org Sat Apr 18 04:01:04 2020 Return-Path: Delivered-To: freebsd-stable@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 BF5622B88ED; Sat, 18 Apr 2020 04:01:04 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [174.136.98.114]) (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 "mail.nomadlogic.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 493zlh2td0z4NR3; Sat, 18 Apr 2020 04:01:04 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.216] (cpe-23-243-162-239.socal.res.rr.com [23.243.162.239]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id f8384a92 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sat, 18 Apr 2020 04:01:03 +0000 (UTC) Subject: Re: OpenZFS port updated To: Ryan Moeller Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org References: <6b25375d-0945-f01e-264e-ee410195fa97@nomadlogic.org> <0ED41E6B-9C57-405B-84BE-1161F012A974@FreeBSD.org> From: Pete Wright Message-ID: <679853e2-6113-1daa-3353-d9c5a1123a0f@nomadlogic.org> Date: Fri, 17 Apr 2020 21:01:03 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <0ED41E6B-9C57-405B-84BE-1161F012A974@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 493zlh2td0z4NR3 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2020 04:01:04 -0000 On 4/17/20 2:54 PM, Ryan Moeller wrote: >> On Apr 17, 2020, at 4:56 PM, Pete Wright wrote: >> >> On 4/17/20 11:35 AM, Ryan Moeller wrote: >>> FreeBSD support has been merged into the master branch of the openzfs/zfs repository, and the FreeBSD ports have been switched to this branch. >> Congratulations on this effort - big milestone! >>> OpenZFS brings many exciting features to FreeBSD, including: >>> * native encryption >> Is there a good doc reference on available for using this? I believe this is zfs filesystem level encryption and not a replacement for our existing full-disk-encryption scheme that currently works? > I’m not aware of a good current doc for this. If anyone finds/writes something, please post it! > There are some old resources you can find with a quick search that do a pretty good job of covering the basic ideas, but I think the exact syntax of commands may be slightly changed in the final implementation. > > The encryption is performed at a filesystem level (per-dataset). thanks for the clarification Ryan.  I may try to test this out in the near future and will try to record my findings in a wiki or somewhere.  being able to do filesystem level encryption is something i have several immediate use cases for. thanks! -p -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-stable@freebsd.org Sat Apr 18 08:03:02 2020 Return-Path: Delivered-To: freebsd-stable@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 BC8DC2C0E04 for ; Sat, 18 Apr 2020 08:03:02 +0000 (UTC) (envelope-from SRS0=FWDs=6C=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49456s6tdSz3G5X for ; Sat, 18 Apr 2020 08:03:01 +0000 (UTC) (envelope-from SRS0=FWDs=6C=quip.cz=000.fbsd@elsa.codelab.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 4ED0228434; Sat, 18 Apr 2020 10:02:59 +0200 (CEST) Received: from illbsd.quip.test (ip-62-24-92-232.net.upcbroadband.cz [62.24.92.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 8679628432; Sat, 18 Apr 2020 10:02:55 +0200 (CEST) Subject: Re: support of PCIe NVME drives To: bsd-lists@BSDforge.com Cc: freebsd-stable@freebsd.org References: <35795c0723caa631c6fcb33b4c95e029@udns.ultimatedns.net> From: Miroslav Lachman <000.fbsd@quip.cz> Message-ID: <3e9ff104-bc09-bb50-a745-cb1e38e0984b@quip.cz> Date: Sat, 18 Apr 2020 10:02:55 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <35795c0723caa631c6fcb33b4c95e029@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 49456s6tdSz3G5X X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of SRS0=FWDs=6C=quip.cz=000.fbsd@elsa.codelab.cz has no SPF policy when checking 94.124.105.4) smtp.mailfrom=SRS0=FWDs=6C=quip.cz=000.fbsd@elsa.codelab.cz X-Spamd-Result: default: False [4.00 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[quip.cz]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.99)[0.989,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(0.81)[ip: (0.26), ipnet: 94.124.104.0/21(0.13), asn: 42000(3.56), country: CZ(0.09)]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[4.105.124.94.list.dnswl.org : 127.0.10.0]; NEURAL_SPAM_LONG(1.00)[0.999,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[000.fbsd@quip.cz,SRS0=FWDs=6C=quip.cz=000.fbsd@elsa.codelab.cz]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42000, ipnet:94.124.104.0/21, country:CZ]; FROM_NEQ_ENVFROM(0.00)[000.fbsd@quip.cz,SRS0=FWDs=6C=quip.cz=000.fbsd@elsa.codelab.cz]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2020 08:03:02 -0000 Chris wrote on 04/18/2020 04:33: > On Fri, 17 Apr 2020 08:17:56 +0200 Miroslav Lachman 000.fbsd@quip.cz said > >> Chris wrote on 04/17/2020 05:51: >> > On Thu, 16 Apr 2020 19:57:21 -0700 Mel Pilgrim > >> list_freebsd@bluerosetech.com said >> > >> On 2020-04-16 12:30, Miroslav Lachman wrote: >> >> > Pete Wright wrote on 04/16/2020 20:23: >> >> >> >> >> >> >> >> >> On 4/16/20 11:12 AM, Miroslav Lachman wrote: >> >> >>> Kurt Jaeger wrote on 04/16/2020 20:07: >> >> > >> I would try booting via UEFI if you can.  I just installed a >> >> laptop >> yesterday which has a nvme root device, it was detected >> by >> the >> 12-STABLE snapshot I used to boot from.  no other >> modifications >> were >> necessary on my end. >> >> > > I changed BIOS settings to use UEFI boot method, booted 12.1 >> >> installer > ISO but without luck. Still no NVME disks :( >> >> > > You can see it on printscreen from iDRAC https://ibb.co/tPnymL7 >> >> > > Anything more I can test? >> >> >> >> Looking at server specs, the R6515's NVME support is only through >> the >> PERC S150 RAID controller.  If that's the case, I'm pretty sure >> you're >> out of luck.  The PERC S-series controllers are >> software-based RAID >> that require Dell's Windows or Linux drivers. >> You'd need a PERC >> H-series card to get support in FreeBSD. >> >> That's something I didn't expect at all. So there is nothing which can >> be fixed on FreeBSD side? :( >> >> >> Someone please correct me if I'm wrong? >> > As I mentioned. I was suspicious of this. He should be able to flash >> the > card, >> > making it a pass. I do a lot of them. If someone doesn't beat me to >> it. > I'll >> > dig through what I have, and see if I can't find the right image(s), >> and > program(s). >> >> This is rented dedicated machine. I cannot flash anything on it. > Apologies for the late reply. Unfortunately $JOB requires me to $WORK. :( > OK Given these are rentals. Probably the most I could supply for your > needs are images that allow you to poll, and change settings of the > controller(s). I have cd9660, and USB flash images of the utilities > for the 100-300 series HBAs as provided by LSI/AvGO. They boot to (MS)DOS, > or to an (U)EFI prompt. Having read what I can; the S150 controller is > Software controlled (likely explaining the "S" in it's model number), > and as > I understand it *shouldn't* require any flashing. As I also understand you > *should* be able to access control of it through UEFI configs. I *think* > accessed via F2. > Apologies if this comes too late, or you've already solved this. > If you're still interested in the management software I have for the > 100-300 > series. Let me know, and I'll attach a copy, or provide a link for you as > needed. As you already noticed Scott Long is helping me in current@ list. He thinks some devices are not probed during boot. I hope this problem can be solved by some "easy" patch. Thank you for your help! Miroslav Lachman From owner-freebsd-stable@freebsd.org Sat Apr 18 18:00:43 2020 Return-Path: Delivered-To: freebsd-stable@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 0662E2A8C4B for ; Sat, 18 Apr 2020 18:00:43 +0000 (UTC) (envelope-from eu9gu4@gmail.com) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 494LNT4wkGz4cxx for ; Sat, 18 Apr 2020 18:00:41 +0000 (UTC) (envelope-from eu9gu4@gmail.com) Received: by mail-ua1-x933.google.com with SMTP id a10so1964283uad.7 for ; Sat, 18 Apr 2020 11:00:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=5/IzFB/O6SCKmW27vL+HvtgQgII3nWVUw0RK/QnnAdc=; b=o27xLhRmIAgEuxCR0crk+E8wvspl3vg42TYagf+HNGywrMYysnqU/hDHt+mqy4oJ82 lvghPx69QABCvtSnBMChhs7iFKO81aQyOZoNq5ttiMfjj8NRqxFkggios5XrH08y6BS0 62E/HXPOMZ/2yUAYxBRnehFoaITtanZaYOMGW7Q18bUuz/erCPKRBZn0Jk7qFdM9Xn9f 0qhzxazaPXmGKwKu/TkTV+dGo8mV5YmUoAiP3g5z3jcveD/AZN4OGeAbvfhLc1iJ3gLt tQVbUF9Q9jmEC4EGySunZ3/nZ1EzhPymH7eZSXxFemJVT3CwI0mOwIBR/eridyndKRoz hEAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5/IzFB/O6SCKmW27vL+HvtgQgII3nWVUw0RK/QnnAdc=; b=TbqokkA7yA0hvNrYNNFtQbBKuVbghKgmqMVco2Pfu9ngLH8+hUjSTz/AF0V9Sd7HxS OHQtjeqIwCNooZzxycZiNhZO7jfiMwb3rn5+Vlc7Y01s59tgYYWpSWxIx53y45/vFg0p a8G0iFzbkV6CQwIoOtRnic76AkOhQzHEImr/2raacOODKej6H2e3Y7DxryKWv1TLqVRN 0jc2kwYZ0CPw0qJtlo5u+DaxMNPVnYkcG+vm7lbu/6/CgS7dMBiG0ZIo3yHyqT9h5xYW CV6naCvMsBwvxUEn2QrqbY1fb5mx9ZjxA51eA5ePXMkdPeIf4f1ABcJXo2yFtMK61X/d Mqog== X-Gm-Message-State: AGi0Pub2oQxNLVTFI/hf2kKTGaeNgJDk5BkXyugjYkiFz41+vdnPrCRd W3xNesEOEHXUevuPfQtqAuZYc9SYsjOvLZQez5PYNMGu3kE= X-Google-Smtp-Source: APiQypIPyMliUiFfLvvjLy0ith5aNjRGSjwg47Gy3jVkWo4a+/NopiF4DewLQQWJS5MqfugUVigS5nwyW0gLxGg78UA= X-Received: by 2002:ab0:63cd:: with SMTP id i13mr2834285uap.82.1587232840005; Sat, 18 Apr 2020 11:00:40 -0700 (PDT) MIME-Version: 1.0 From: Eugen Date: Sat, 18 Apr 2020 11:00:29 -0700 Message-ID: Subject: openzfs module fails to load To: freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 494LNT4wkGz4cxx X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=o27xLhRm; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of eu9gu4@gmail.com designates 2607:f8b0:4864:20::933 as permitted sender) smtp.mailfrom=eu9gu4@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_DN_NONE(0.00)[]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(0.00)[ip: (-9.12), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[3.3.9.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]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2020 18:00:43 -0000 Freebsd 12.1 STABLE 360074 openzfs-kmod and openzfs ports build just fine. /boot/loader.conf: zfs_load="NO" openzfs_load="YES" /etc/rc.conf: zfs_enable="NO" (or "YES", it doesn't matter) With above settings openzfs.ko module does not load at boot. zfs.ko module is loaded instead. kldstat: Id Refs Address Size Name 1 40 0xffffffff80200000 1143a00 kernel 2 1 0xffffffff81345000 37add8 zfs.ko 3 2 0xffffffff816c0000 a240 opensolaris.ko 4 1 0xffffffff816cb000 29f0 coretemp.ko 5 1 0xffffffff816ce000 ec08 aesni.ko 6 1 0xffffffff81e90000 c6a0 fuse.ko 7 1 0xffffffff81e9d000 f2890 nvidia-modeset.ko 8 1 0xffffffff81f90000 11f7ca0 nvidia.ko 9 1 0xffffffff83188000 e20 cpuctl.ko 10 1 0xffffffff83189000 1440 uhid.ko 11 1 0xffffffff8318b000 2078 ums.ko 12 1 0xffffffff8318e000 7f80 tmpfs.ko 13 1 0xffffffff83196000 1990 fdescfs.ko 14 1 0xffffffff83198000 16078 ext2fs.ko 15 1 0xffffffff831af000 3c74 geom_linux_lvm.ko After: kldunload zfs kldload openzfs dmesg shows this: [98] link_elf_obj: symbol sdt_probe_func undefined [98] linker_load_file: /boot/modules/openzfs.ko - unsupported file type Any ideas why openzfs module does not load? Thanks, Eugen From owner-freebsd-stable@freebsd.org Sat Apr 18 18:25:46 2020 Return-Path: Delivered-To: freebsd-stable@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 433342A9B7F for ; Sat, 18 Apr 2020 18:25:46 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 494LxQ16ftz4gFq for ; Sat, 18 Apr 2020 18:25:46 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com [209.85.208.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id D61101CEB2 for ; Sat, 18 Apr 2020 18:25:45 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-lj1-f171.google.com with SMTP id u15so5522181ljd.3 for ; Sat, 18 Apr 2020 11:25:45 -0700 (PDT) X-Gm-Message-State: AGi0PuYNPtddAVs8tW/xEiREZ73AJ3vECy31LCKu7ZCQCs8+LcnMDZ2W JR07coxA1o5bh37pZn5FAORL+JqqjMDN6fdZ5yM= X-Google-Smtp-Source: APiQypKq4wiHALeq4l2XOdK6uGmBofMvhXWaZMEuKkp1ZfE+6b25hscM6wwCpSJ8/Qhb90n38aXsyjpz0chfStFdUbI= X-Received: by 2002:a2e:5746:: with SMTP id r6mr5253658ljd.15.1587234344157; Sat, 18 Apr 2020 11:25:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Matthew Macy Date: Sat, 18 Apr 2020 11:25:33 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: openzfs module fails to load To: Eugen Cc: freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2020 18:25:46 -0000 It looks like you=E2=80=99ve built your kernel without KDTRACE_HOOKS On Sat, Apr 18, 2020 at 11:00 Eugen wrote: > Freebsd 12.1 STABLE 360074 > > openzfs-kmod and openzfs ports build just fine. > > /boot/loader.conf: > zfs_load=3D"NO" > openzfs_load=3D"YES" > > /etc/rc.conf: > zfs_enable=3D"NO" (or "YES", it doesn't matter) > > With above settings openzfs.ko module does not load at boot. > zfs.ko module is loaded instead. kldstat: > > Id Refs Address Size Name > 1 40 0xffffffff80200000 1143a00 kernel > 2 1 0xffffffff81345000 37add8 zfs.ko > 3 2 0xffffffff816c0000 a240 opensolaris.ko > 4 1 0xffffffff816cb000 29f0 coretemp.ko > 5 1 0xffffffff816ce000 ec08 aesni.ko > 6 1 0xffffffff81e90000 c6a0 fuse.ko > 7 1 0xffffffff81e9d000 f2890 nvidia-modeset.ko > 8 1 0xffffffff81f90000 11f7ca0 nvidia.ko > 9 1 0xffffffff83188000 e20 cpuctl.ko > 10 1 0xffffffff83189000 1440 uhid.ko > 11 1 0xffffffff8318b000 2078 ums.ko > 12 1 0xffffffff8318e000 7f80 tmpfs.ko > 13 1 0xffffffff83196000 1990 fdescfs.ko > 14 1 0xffffffff83198000 16078 ext2fs.ko > 15 1 0xffffffff831af000 3c74 geom_linux_lvm.ko > > After: > kldunload zfs > kldload openzfs > > dmesg shows this: > > [98] link_elf_obj: symbol sdt_probe_func undefined > [98] linker_load_file: /boot/modules/openzfs.ko - unsupported file type > > Any ideas why openzfs module does not load? > > Thanks, > Eugen > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@freebsd.org Sat Apr 18 20:37:04 2020 Return-Path: Delivered-To: freebsd-stable@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 CEF082ACE66 for ; Sat, 18 Apr 2020 20:37:04 +0000 (UTC) (envelope-from eu9gu4@gmail.com) Received: from mail-vk1-xa42.google.com (mail-vk1-xa42.google.com [IPv6:2607:f8b0:4864:20::a42]) (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 494Prw59R5z3NQg; Sat, 18 Apr 2020 20:37:04 +0000 (UTC) (envelope-from eu9gu4@gmail.com) Received: by mail-vk1-xa42.google.com with SMTP id y129so1544074vkf.6; Sat, 18 Apr 2020 13:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=sXEm6JPO1BznxuJz3C+BBkEgZErlZnS5Zh489lzbxG4=; b=VgwtNOp1L+m5rsOR4VwdgVw0oHqaWIBXQfE+Tlnysc2wf7xs5PPA/29CKDWQ50OPGW 4q6E8rQBs/wSEKS8N4H/vs5VXhQCOsDequar37qh3mz8jP96bZtMVpNwe4JVDRvVRSfq fe5Wkc8WI9eaft+h9ZpWLPHZyRsbSWdCrd6m1IMFDzhepkvb12AgQMwmIPLo0WEBSQYV EXyBd20abAE7eFvJCq+I0UYi7xp5IH0IOIKYpV2mksbhUxGIKv8Pd+lPCfQZ5toJGo/1 aNme2KliaJqQIuVeIvSDy6zVo+Y0NeMsNaNAkwfPt0sEu7WRDGXo0Mp2SV097Ia2dxkJ yhoQ== 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:content-transfer-encoding; bh=sXEm6JPO1BznxuJz3C+BBkEgZErlZnS5Zh489lzbxG4=; b=Q8C/5tlDjJzrR4JHTqYF47tf8d+yIUM2r4k/DUhMrjMNzT836x6Ux0toH4DAZGw8Pm yzUQ/EdZGP7FHmMNUa8PbiRGNdh0cSnDtYL3UUttrwG9BLYbC467qnW9CEkSXrR3FbWp wDnvTWCsqgQdokIz847oUFalRVo+KVPhlhZje8b1rTQL0k83N4rQvkGVNhzswqKW88mL 6b+hO2iHC3ZO51WCBOx8xmVVYwyu7Vs1cT5tRUnlecLAzy+AQ3dUjf8HphJ849AuEhDq m7PysbHbkN3TyhmqW7HSNNTiT8Eb6DctpbwgFQgRGAHKDRwaInrNMdKMlaqIIBrHCStQ shwQ== X-Gm-Message-State: AGi0PuZ2faeTge4QytqC+1kHOyM3q18lUsl0tJ5xpZXUHQW4tFcprDd9 eNkE9MlfGmuzPPYVWVlJJ0w7cTm8pd2spUa5sf01a7OL X-Google-Smtp-Source: APiQypLnpmRccEIFTFbGUr3yNh4cJRzIvdG3Ic+UkVv3G27mzhD/849WtBf40/TlqkDccDBf3DFFgYDjSu+1oKWoG2s= X-Received: by 2002:a1f:1255:: with SMTP id 82mr6820292vks.80.1587242223166; Sat, 18 Apr 2020 13:37:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eugen Date: Sat, 18 Apr 2020 13:36:52 -0700 Message-ID: Subject: Re: openzfs module fails to load To: Matthew Macy Cc: freebsd-stable@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 494Prw59R5z3NQg X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2020 20:37:04 -0000 Thanks Matthew! On Sat, Apr 18, 2020 at 11:25 AM Matthew Macy wrote: > > It looks like you=E2=80=99ve built your kernel without KDTRACE_HOOKS > > On Sat, Apr 18, 2020 at 11:00 Eugen wrote: >> >> Freebsd 12.1 STABLE 360074 >> >> openzfs-kmod and openzfs ports build just fine. >> >> /boot/loader.conf: >> zfs_load=3D"NO" >> openzfs_load=3D"YES" >> >> /etc/rc.conf: >> zfs_enable=3D"NO" (or "YES", it doesn't matter) >> >> With above settings openzfs.ko module does not load at boot. >> zfs.ko module is loaded instead. kldstat: >> >> Id Refs Address Size Name >> 1 40 0xffffffff80200000 1143a00 kernel >> 2 1 0xffffffff81345000 37add8 zfs.ko >> 3 2 0xffffffff816c0000 a240 opensolaris.ko >> 4 1 0xffffffff816cb000 29f0 coretemp.ko >> 5 1 0xffffffff816ce000 ec08 aesni.ko >> 6 1 0xffffffff81e90000 c6a0 fuse.ko >> 7 1 0xffffffff81e9d000 f2890 nvidia-modeset.ko >> 8 1 0xffffffff81f90000 11f7ca0 nvidia.ko >> 9 1 0xffffffff83188000 e20 cpuctl.ko >> 10 1 0xffffffff83189000 1440 uhid.ko >> 11 1 0xffffffff8318b000 2078 ums.ko >> 12 1 0xffffffff8318e000 7f80 tmpfs.ko >> 13 1 0xffffffff83196000 1990 fdescfs.ko >> 14 1 0xffffffff83198000 16078 ext2fs.ko >> 15 1 0xffffffff831af000 3c74 geom_linux_lvm.ko >> >> After: >> kldunload zfs >> kldload openzfs >> >> dmesg shows this: >> >> [98] link_elf_obj: symbol sdt_probe_func undefined >> [98] linker_load_file: /boot/modules/openzfs.ko - unsupported file type >> >> Any ideas why openzfs module does not load? >> >> Thanks, >> Eugen >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org= "