From owner-freebsd-stable@freebsd.org Sun Oct 21 01:30:51 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B1B7FFE6DD for ; Sun, 21 Oct 2018 01:30:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id DD581741B7 for ; Sun, 21 Oct 2018 01:30:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id A1C93FFE6D9; Sun, 21 Oct 2018 01:30:50 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 90AC7FFE6D8 for ; Sun, 21 Oct 2018 01:30:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 33281741B1 for ; Sun, 21 Oct 2018 01:30:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 693F31E406 for ; Sun, 21 Oct 2018 01:30:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9L1UnsN045736 for ; Sun, 21 Oct 2018 01:30:49 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9L1UnvM045735 for stable@FreeBSD.org; Sun, 21 Oct 2018 01:30:49 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 227654] [panic] repeatable crash with lagg+vlan+em Date: Sun, 21 Oct 2018 01:30:49 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: version Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.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, 21 Oct 2018 01:30:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227654 Eugene Grosbein changed: What |Removed |Added ---------------------------------------------------------------------------- Version|11.1-STABLE |CURRENT --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Sun Oct 21 01:24:32 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BDD2CFFE357 for ; Sun, 21 Oct 2018 01:24:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 5B6887407B for ; Sun, 21 Oct 2018 01:24:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 1FF37FFE355; Sun, 21 Oct 2018 01:24:32 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0EA51FFE354 for ; Sun, 21 Oct 2018 01:24:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 925DE74079 for ; Sun, 21 Oct 2018 01:24:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id DE6541E300 for ; Sun, 21 Oct 2018 01:24:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9L1OUPm035198 for ; Sun, 21 Oct 2018 01:24:30 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9L1OU4k035197 for stable@FreeBSD.org; Sun, 21 Oct 2018 01:24:30 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 227654] [panic] repeatable crash with lagg+vlan+em Date: Sun, 21 Oct 2018 01:24:30 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.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, 21 Oct 2018 01:24:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227654 --- Comment #5 from Eugene Grosbein --- I've added additional printf's to sys/net/if_ethersubr.c and found that it panices within ether_output_frame() function. I've added this just before PFIL_HOOKED(&V_link_pfil_hook) check: if (ifp->if_index =3D=3D 6) printf(""ether_output_frame: checking curvnet= =3D%p\n", curvnet); if (ifp->if_index =3D=3D 6) printf(""ether_output_frame: V_link_pfil_hook= =3D%p\n", V_link_pfil_hook); And last lines of dmesg buffer after panic are: ether_output_frame: checking curvnet=3D0 panic: vm_fault_hold: fault on nofault entry, addr: 0 So, curvnet is NULL here, hence the panic. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Sun Oct 21 05:33:07 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 31F2DFCECA4 for ; Sun, 21 Oct 2018 05:33:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA7707C66A for ; Sun, 21 Oct 2018 05:33:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe34.google.com with SMTP id w194so27634916vsc.11 for ; Sat, 20 Oct 2018 22:33:06 -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=kUKgelnR/9ZNnTV7CH73US5ATf0tjH9vz/9vHslTP4s=; b=Jub/DD5z1+K3SPrVE/1bisP+B65Kh885EtAXNIoWkpwS5wz74uPTgV1Zp4SndTdl18 Wi9drpon8oYe1nOl5LpwuJglFbviwY3+0/9Ad0QdhyI0duLFIbdLaB8jb09ZM6kyIR2o 4Ir8t29GwspATPzEnGPyCiexEVzlXQs9bTFFdvNIoKv/Y89x9i2fj8B65H685Z8wX+qU PhS/JAieNgFnQa6CCzB+UsYkvZZL5Vge4RWahM/JrTQef0CiQQTHeG/DVtmUj2IBQznA E27DWdGtPaKKbBUpOAsViNy24ysQUrtHwtuLD6xcVKg0RD0QFCGxYHzD+JiTuR18Le1k BhWA== 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=kUKgelnR/9ZNnTV7CH73US5ATf0tjH9vz/9vHslTP4s=; b=etBzK/VxyfEWhWGXMVCQ0BkI7OTwq9CpVRHcFf+H58XrEDa3i/22IFKUubimgJAxRt 0Oogej0Bhl0Ai+F9qLV9dZaqxhCu+GsxYflcR/7IfwjWy65imokPmZl7pP3PcVok9g5Q JK6NPUyxYTjUIwVIlYFRUxtWZ7+Jd+WKSoBshstLO9N8odyTATLQ+WIe3cRP7sVv07DL cov7BlpCQ+7K9Eq2tH+BeH/XM0H3k3Am6YOcHd9DRL7muTMcTFU14qulhoYArqZQ8aO7 esJseMYeyqF68lDqKTd9yE0YyS6isHw33z+TtBzWnGWt83WvMt5ngAZxMJ+H8ahznxjS pjrg== X-Gm-Message-State: ABuFfoiUF4E1Z0PTvdK5I41PH6jqyiKUug+9IWIhVIW2xRKZCtKlgnGQ XvIlJJ+9VNJQhB4bjj4rNN1zeTUiNuUM4yNeSG05dQ== X-Google-Smtp-Source: ACcGV62XNY/usfM1g+WiVbz5G80uCojTDwQsIkfJXzn4hCE7OQUOfHKFZjWZ//boenDL+0OsZ5AKG7lWgBV0cX3RhYo= X-Received: by 2002:a67:e86:: with SMTP id 128mr16550240vso.201.1540099985869; Sat, 20 Oct 2018 22:33:05 -0700 (PDT) MIME-Version: 1.0 References: <2A425DE4-2B5B-474D-8B95-81890DE4D8A1@yahoo.com> <9D2A6528-F888-4833-A52B-8F9B4D66592C@yahoo.com> In-Reply-To: <9D2A6528-F888-4833-A52B-8F9B4D66592C@yahoo.com> From: Warner Losh Date: Sat, 20 Oct 2018 23:32:54 -0600 Message-ID: Subject: Re: head -r339076's boot loader fails to boot threadripper 1950X system (BTX halted); an earlier version works [ -r336532 broke it ] To: Mark Millard Cc: FreeBSD Current , FreeBSD-STABLE Mailing List 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, 21 Oct 2018 05:33:07 -0000 On Sat, Oct 20, 2018 at 11:04 PM Mark Millard wrote: > [I found what change lead to the 1950X boot crashing > with BTX halted.] > > On 2018-Oct-20, at 12:44 PM, Mark Millard wrote: > > > [Adding some vintage information for a loader > > that allowed a native boot.] > > > > On 2018-Oct-20, at 4:00 AM, Mark Millard wrote: > > > >> I attempted to jump from head -r334014 to -r339076 > >> on a threadripper 1950X board and the native > >> FreeBSD boot failed very early. (Hyper-V use of > >> the same media did not have this issue.) > >> > >> But copying over an older /boot/loader from another > >> storage device with a FreeBSD head version that has > >> not been updated yet got past the problem being > >> reported here. (For other reasons, the kernel has > >> been moved back to -r338804 --and with that, > >> and the older /boot/loader, the 1950X native-boots > >> FreeBSD all the way just fine.) > > > > I found one /boot/loader.old that was dated > > in the update'd file system as 2018-May 20, > > instead of 2018-Apr-03 from the older file > > system. May 20 would apparently mean a little > > below -r334014 . It native-booted okay, as did > > the April one. > > > > [I do not know how to inspect a /boot/loader* > > to find out what -r?????? it is from.] > > > > Unfortunately, I had done more than one -r339076 > > install from -r334014 before rebooting and > > no -r334014 loaders were still present: > > the other *.old files from a few minutes before > > the ones I had the boot problem with. > > > > I might be able to extract loaders from various: > > > > https://artifact.ci.freebsd.org/snapshot/head/r*/amd64/amd64/base.txz > > > > materials and try substituting them in order to > > narrow the range for works -> fails. If I can, > > this likely would take a fair amount of time in > > my context. > > > > Other notes: > > > > It turns out that only Hyper-V based use needed > > a -r334804 kernel: Native booting with the older > > loaders and newer kernels works fine. > > > > Windows 10 Pro 64bit also has no problems > > booting and operating the machine. > > > > The native-boot problem does seem to be freeBSD > > loader-vintage specific. > > > >> For the BTX failure the display ends up with > >> (hand transcribed, ". . ." for an omission): > >> > >> BTX loader 1.00 BTX version is 1.02 > >> Console: internal video/keyboard > >> BIOS drive C: is disk0 > >> . . . > >> BIOS drive P: is disk13 > >> - > >> int=00000000 err=00000000 efl=00010246 eip=000096fd > >> eax=74d48000 ebx=74d4e5e0 ecx=00000011 edx=00000000 > >> esi=74d4e380 edi=74d4e5b0 ebp=00091da0 esp=00091d60 > >> cs=002b ds=0033 es=0033 fs=0033 gs=0033 ss=0033 > >> cs:eip=66 f7 77 04 0f b7 c0 89-44 24 0c 89 5c 24 04 8b > >> 45 08 89 04 24 83 64 24-10 00 c7 44 24 08 01 00 > >> ss:esp=00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 > >> 00 00 00 00 00 00 00 00-f0 1d 89 00 00 00 00 00 > >> BTX halted > > > > I've no clue what of that output might be loader vintage > > specific. It might not be of use without knowing the > > exact build of the loader. > > > >> The board is a GIGABYTE X399 AORUS Gaming 7 (rev 1.0). > >> It has 96 GiBytes of ECC RAM, just 6 DIMMs installed. > > > > For reference for the board's BIOS: > > > > Version: F11e > > Dated: 2018-Sep-17 > > Description: Update AGESA 1.1.0.1a > > Using: > > https://artifact.ci.freebsd.org/snapshot/head/r*/amd64/amd64/base.txz > > materials I found that: > > -r336492: worked (loader vs. zfsloader: not linked) > (no more amd64 builds until . . .) > -r336538: failed (loader vs. zfsloader: linked) > > (Later ones that I tried also failed.) > > Looks like this broke for booting the 1950X > system in question when the following was > checked in: > > Author: imp > Date: Fri Jul 20 05:17:37 2018 > New Revision: 336532 > URL: > https://svnweb.freebsd.org/changeset/base/336532 > > > Log: > Collapse zfsloader functionality back down into loader. > Yea, this shouldn't matter. It worked on all the systems I tried it on. So my first question: is this a ZFS system? Second, does it also have UFS? If yes to both, which one do you want it to boot off of? Warner From owner-freebsd-stable@freebsd.org Sun Oct 21 03:32:35 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 568421037102 for ; Sun, 21 Oct 2018 03:32:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E5A9E78EF5 for ; Sun, 21 Oct 2018 03:32:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id A77B91037100; Sun, 21 Oct 2018 03:32:34 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9651810370FF for ; Sun, 21 Oct 2018 03:32:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 36C9778EF2 for ; Sun, 21 Oct 2018 03:32:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 853391F4FD for ; Sun, 21 Oct 2018 03:32:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9L3WXEA011000 for ; Sun, 21 Oct 2018 03:32:33 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9L3WXa5010999 for stable@FreeBSD.org; Sun, 21 Oct 2018 03:32:33 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: stable@FreeBSD.org Subject: [Bug 227654] [panic] repeatable crash with lagg+vlan+em Date: Sun, 21 Oct 2018 03:32:33 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_severity cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.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, 21 Oct 2018 03:32:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227654 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Affects Only Me |Affects Some People CC|stable@FreeBSD.org | --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-stable@freebsd.org Sun Oct 21 07:05:21 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A057FD84FB for ; Sun, 21 Oct 2018 07:05:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-20.consmr.mail.ne1.yahoo.com (sonic306-20.consmr.mail.ne1.yahoo.com [66.163.189.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BCED57F4A3 for ; Sun, 21 Oct 2018 07:05:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: jWLG8HUVM1mwQQiCD1mwtXnbbtWv3JyPmvtM4mz9EQArlDvI4hOgczShz6a4n82 w6eGFdBoAznpMLcr34LE7cguXiHSo2Zubl9ymvEKSvXpAa9L5rvDSnimCsQo9oOAEbBPY63XQsJA tePee0rUzWPgwKY1_g7a7cK863Tx58y0VKJocceKfoZb8FZgyAujhzn1IATLbes80DgmcAyanTmw YsdUHXegsz_sBYE1bwW6p4MRiMq4Uavi.Elak03MfAMCPjRQiOseNY2Wc75iF54jeZV4Py0RXX4l oAjJo_bQGNy62jPxFGGoloE8PS1TM4DFqaF3FlR03iH4GaQkMJ75KHKVuCk_w7uu6f8k1b_nts1I 9kCRkFJi_kdZ.MfWbE9tcDQ63YLItz2lppadi.SnzBdFQV_vF_VR.DCUmPq2xEF.p5TC09HAqR2B A4yI.smMieV5dph9MgSvWJvLZm7d38aGb32NFtt1ejdO67C.t0kH0NU7luTx0J68WFz8fiNFolhN T9nfw756NN7cUC_KmHkGy3JzRy.U3lxyJbPiGdvcbZJ402m3E6m8UykI4up0cnWdFUlWN6EDlW7B YrGMpoSqGWJ6E2KlSp4nKIc_YXG.r8ZqR_yzNjFQsCKbYp8U4qQMTS4IilEp8WHPCg8S1zw0j3FF S1lgwz08AvOsQjQtZAo4yRW5MStWNqII0OtTJr3QltgzuKjGVTdgyG1bey4PR.TFSUolzVdRZn_c dujppwm3roKKRP1YlWU8faMNazV6c84ks2IcObd6v_XqsuWLMXII8Be0Kk4yQ9njdc_ZguJrXsNi _R5usNQkAvmDOs.gegkeMLTPL_0LEE4Wo3zdqMQQ2jePWRPJX3Lq3oUmlSLrmMKyBACeKucIwy1H 0uoO8rDo_dp96wCjv7gwNfrkC7mPZmxRE2MwqqkeG9.c64V3go7DNP1n9LQ8h99XIJCvZIzfNEns fVCah4kHJVMrZquLkMD5bFeuE6RGFT4FIdev.fm57O1V9_mwvJu_xj_SatbSsBmb3wL4OumXEBNQ 2bilcPQcTY4orQ4JjPyeLpxs0W164Ct5a9Xjtn9uuIo2np.Dz0orYsp2eXo_9zXGGhNdecwkkSrS p1LgkGEcSGor3 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Sun, 21 Oct 2018 07:05:13 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp430.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e89355a7d2acd1525effad1bfa37ced7; Sun, 21 Oct 2018 07:05:09 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r339076's boot loader fails to boot threadripper 1950X system (BTX halted); an earlier version works [ -r336532 broke it ] From: Mark Millard In-Reply-To: Date: Sun, 21 Oct 2018 00:05:07 -0700 Cc: FreeBSD Current , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <30DD2F47-C8CB-4CEC-8563-C7083D0EAEEF@yahoo.com> References: <2A425DE4-2B5B-474D-8B95-81890DE4D8A1@yahoo.com> <9D2A6528-F888-4833-A52B-8F9B4D66592C@yahoo.com> To: Warner Losh X-Mailer: Apple Mail (2.3445.9.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: Sun, 21 Oct 2018 07:05:21 -0000 On 2018-Oct-20, at 10:32 PM, Warner Losh wrote: > On Sat, Oct 20, 2018 at 11:04 PM Mark Millard = wrote: > [I found what change lead to the 1950X boot crashing > with BTX halted.] >=20 >> On 2018-Oct-20, at 12:44 PM, Mark Millard = wrote: >>=20 >> > [Adding some vintage information for a loader >> > that allowed a native boot.] >> >=20 >> > On 2018-Oct-20, at 4:00 AM, Mark Millard = wrote: >> >=20 >> >> I attempted to jump from head -r334014 to -r339076 >> >> on a threadripper 1950X board and the native >> >> FreeBSD boot failed very early. (Hyper-V use of >> >> the same media did not have this issue.) >> >>=20 >> >> But copying over an older /boot/loader from another >> >> storage device with a FreeBSD head version that has >> >> not been updated yet got past the problem being >> >> reported here. (For other reasons, the kernel has >> >> been moved back to -r338804 --and with that, >> >> and the older /boot/loader, the 1950X native-boots >> >> FreeBSD all the way just fine.) >> >=20 >> > I found one /boot/loader.old that was dated >> > in the update'd file system as 2018-May 20, >> > instead of 2018-Apr-03 from the older file >> > system. May 20 would apparently mean a little >> > below -r334014 . It native-booted okay, as did >> > the April one. >> >=20 >> > [I do not know how to inspect a /boot/loader* >> > to find out what -r?????? it is from.] >> >=20 >> > Unfortunately, I had done more than one -r339076 >> > install from -r334014 before rebooting and >> > no -r334014 loaders were still present: >> > the other *.old files from a few minutes before >> > the ones I had the boot problem with. >> >=20 >> > I might be able to extract loaders from various: >> >=20 >> > = https://artifact.ci.freebsd.org/snapshot/head/r*/amd64/amd64/base.txz >> >=20 >> > materials and try substituting them in order to >> > narrow the range for works -> fails. If I can, >> > this likely would take a fair amount of time in >> > my context. >> >=20 >> > Other notes: >> >=20 >> > It turns out that only Hyper-V based use needed >> > a -r334804 kernel: Native booting with the older >> > loaders and newer kernels works fine. >> >=20 >> > Windows 10 Pro 64bit also has no problems >> > booting and operating the machine. >> >=20 >> > The native-boot problem does seem to be freeBSD >> > loader-vintage specific. >> >=20 >> >> For the BTX failure the display ends up with >> >> (hand transcribed, ". . ." for an omission): >> >>=20 >> >> BTX loader 1.00 BTX version is 1.02 >> >> Console: internal video/keyboard >> >> BIOS drive C: is disk0 >> >> . . . >> >> BIOS drive P: is disk13 >> >> - >> >> int=3D00000000 err=3D00000000 efl=3D00010246 eip=3D000096fd >> >> eax=3D74d48000 ebx=3D74d4e5e0 ecx=3D00000011 edx=3D00000000 >> >> esi=3D74d4e380 edi=3D74d4e5b0 ebp=3D00091da0 esp=3D00091d60 >> >> cs=3D002b ds=3D0033 es=3D0033 fs=3D0033 gs=3D0033 ss=3D0033 >> >> cs:eip=3D66 f7 77 04 0f b7 c0 89-44 24 0c 89 5c 24 04 8b >> >> 45 08 89 04 24 83 64 24-10 00 c7 44 24 08 01 00 >> >> ss:esp=3D00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 >> >> 00 00 00 00 00 00 00 00-f0 1d 89 00 00 00 00 00 >> >> BTX halted >> >=20 >> > I've no clue what of that output might be loader vintage >> > specific. It might not be of use without knowing the >> > exact build of the loader. >> >=20 >> >> The board is a GIGABYTE X399 AORUS Gaming 7 (rev 1.0). >> >> It has 96 GiBytes of ECC RAM, just 6 DIMMs installed. >> >=20 >> > For reference for the board's BIOS: >> >=20 >> > Version: F11e >> > Dated: 2018-Sep-17 >> > Description: Update AGESA 1.1.0.1a >>=20 >> Using: >>=20 >> https://artifact.ci.freebsd.org/snapshot/head/r*/amd64/amd64/base.txz >>=20 >> materials I found that: >>=20 >> -r336492: worked (loader vs. zfsloader: not linked) >> (no more amd64 builds until . . .) >> -r336538: failed (loader vs. zfsloader: linked) >>=20 >> (Later ones that I tried also failed.) >>=20 >> Looks like this broke for booting the 1950X=20 >> system in question when the following was >> checked in: >>=20 >> Author: imp >> Date: Fri Jul 20 05:17:37 2018 >> New Revision: 336532 >> URL:=20 >> https://svnweb.freebsd.org/changeset/base/336532 >>=20 >>=20 >> Log: >> Collapse zfsloader functionality back down into loader. >>=20 > Yea, this shouldn't matter. It worked on all the systems I tried it = on. >=20 > So my first question: is this a ZFS system? Second, does it also have = UFS? If yes to both, which one do you want it to boot off of? No zfs in use at all. It has been years since I experimented with ZFS and reverted back to UFS. # gpart show -l =3D> 40 937703008 da0 GPT (447G) 40 1024 1 FBSDFSSDboot (512K) 1064 746586112 2 FBSDFSSDroot (356G) 746587176 31457280 3 FBSDFSSDswap (15G) 778044456 159383552 4 FBSDFSSDswap2 (76G) 937428008 275040 - free - (134M) . . . Doing: gpart bootcode -p /boot/gptboot -i 1 da0 and the trying a modern /boot/loader did not change anything: still "BTX halted" for a native boot. (No problem under Hyper-V.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-stable@freebsd.org Sun Oct 21 07:10:01 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EADCBFD85AF; Sun, 21 Oct 2018 07:10:00 +0000 (UTC) (envelope-from sneakywumpus@gmail.com) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 55E6A7F4CA; Sun, 21 Oct 2018 07:10:00 +0000 (UTC) (envelope-from sneakywumpus@gmail.com) Received: by mail-ed1-x52d.google.com with SMTP id r25-v6so221428edy.0; Sun, 21 Oct 2018 00:10:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=7u9iiALqAGP7k4Sjd+u+AtUNYyK03ExN/BAVWaA4TI4=; b=vA2lEseynr0jqgIE4Z8Wu/rC5ZEE4z315oXXbSXoxEZgupUVwazjc6nuak9G0uliFt mAkYbzcnf53RHu/lxraUCFU3Y/+AqTQ9aQLFwmdVRXRnq/fRgpcsQq2iEqXWiMllgdwV 84clow8hrSMseWWGgfjmYWXhSDd+JLbAJCMLCilKCdMTk5yXuE9fr31rnYKcjj8Tbo3f zHfgi6vmzTN3ApxgDEn+RqAofY5kP+Yys7rweeE88lWgd86Tcz7ikZaMAqKMz58IPgqb jfqG5pr9QmcWDEA2mlsF11ju/9DjWjvy6hl5buO5u5aAWcmVeTVhjdHQARwTQ4CUFtq/ xOrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=7u9iiALqAGP7k4Sjd+u+AtUNYyK03ExN/BAVWaA4TI4=; b=m6p+D7GNUql6/PVUbVGk+EeXnHlF/m7DVoy4FKaY4CMsxUNW44R6STEYQyV1B8D69X 9ZCwBR49dznPTV3E1b9D7gq1Igs1HROXd/V3Puwf27Bekp9ddGJ/ASusahyXTjmjfvTw mepJwHHr4zMLI0IqGj2HpJT2wVeGqF3WI/ah1idihwZbmbMlgjZOuM8X2vhN7OproZdZ q9DN5uTK1OdLbMXipM+XNL99VUmLg8w4iQnteOgZRjsd9Hwu14/hvpRPLUt82mqSpu5z y0papGH7EYPegI/2pZ+8rBzXyMJrfTB70W1z4c+T2/sTPEFVmRHZ+ljyo/dumzF2kcYU DoTA== X-Gm-Message-State: ABuFfojLmr1PxFi/Rs+XxtSnjZvj4y0r+d/yxx5BOOTZcdjJD0MlEf+m 0Ox4Sm3gwMSRA8Qr2Cz1rcYevnhL X-Google-Smtp-Source: ACcGV62xAdJVQV/vZxD4CK0xH4wyvrJWaFb4+SV9zIKivp4yIdqXo7GJrGdRRPcP83hrMXCObd/UFg== X-Received: by 2002:aa7:cf82:: with SMTP id z2-v6mr10399524edx.208.1540105798796; Sun, 21 Oct 2018 00:09:58 -0700 (PDT) Received: from ed209.ocp.lan (ip4d14e2e6.dynamic.kabel-deutschland.de. [77.20.226.230]) by smtp.gmail.com with ESMTPSA id 18-v6sm11029947edt.34.2018.10.21.00.09.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 21 Oct 2018 00:09:58 -0700 (PDT) From: Thomas Eberhardt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Subject: clang debugging code in stable/12 and current Message-Id: Date: Sun, 21 Oct 2018 09:09:57 +0200 To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.3445.100.39) 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, 21 Oct 2018 07:10:01 -0000 It looks like the enabling of debugging code in clang/llvm was flipped = around during the stable/12 branch. See the definition of NDEBUG in lib/clang/llvm.build.mk line 20: current before r339436: #CFLAGS+=3D -DNDEBUG after r339436: CFLAGS+=3D -DNDEBUG stable/12 at r339435: #CFLAGS+=3D -DNDEBUG i.e. debugging code is now disabled in current and enabled in stable/12. From owner-freebsd-stable@freebsd.org Sun Oct 21 05:04:45 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E0E39FCE022 for ; Sun, 21 Oct 2018 05:04:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-10.consmr.mail.gq1.yahoo.com (sonic315-10.consmr.mail.gq1.yahoo.com [98.137.65.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4A31E7BA35 for ; Sun, 21 Oct 2018 05:04:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: P3yGGcwVM1l_HSjX0D8ng5EdbqnEz9XguxC1nynD_9j3v9gc2PTuf.wR4vRq0Vl bRR5ZCC4_.q0cM5r_OaAP0VJgCcbXDk_gn.EAbayITR1Ze6YpanFVPkLIKRcCE4ThtUseVR2f34t 8HwLhF8zIICTYDfBiFnYbyZvFfE66VmQ9bZR.PJllavbBr8wF3NGUfIDmZt2X2fRELWfEL3xkkd9 AxFg6IRyyV81GjQhBV_y9nfAPgmcGGRFDfUarHWz4zueyVqDrC2zvAahWggwAEz_qYMazyaZK.KV sMRHjXa7Y16CeJWMw.X5CEBceWCQpH1KVQbTTAxLnlpqHl.m_.w_kDo.AalUgiY7O5kXFkuxeqNC Ca2kPRsNWVmUCOPjkbtJrZr7xYNpKzudiyD__0XhwnAzYvsF3q7H4_cDVlp.h6P67Eeb0yADod_Y R2b1GxIwjlWwCt1ser2QVNjHKmC7neA5MbrbMSa0ap2NeEnxawauyfBlsGtnsrBVBBkSyQKtO4ti fL4yqYZnPd9.f1kYNPxhEpPZ_VTwLnT3b5z1MDe8GVrph8bdq37k.JeBlDp2yWyIAFX61tGs8aoe IAovRvkQT9u.IcejPMIc683biLCjCafItptQ3ILO2c0.sw4M3ozYP3k1U2tQDHVVRQ67BZVlUtxN 8asdBujo.VVzXfOd2j1lUNXU_Yy1cgnbs3nYKiVyQkUHOgoDt2UkbKDDXyYoFhlIhaqGhGcjndXh BZpO31YeLSih8.tftX.rboEy_5nCreCkFlUzrsNIHdQh4bm0EFmgtyswtmAfvnMJ8wnNaXDp5JBR YptNvDpAmzwPKKAPH4RLtoTe5nZ.LxAo0PB_PicBc8u6.xEIP9IWN_mb.pxiRRrLGyQR_pzoRXG8 0d..cs8ZaKW2TV7RSsMuoj3ASnXBv6DfVtIwkGNAzYQiRSYpGJq90SK5yYDun4EJrmssr6uIYcum ZeAhfKtPfdkTC0rwZEFEU.UDOeBW9dQsC5vcPCGIkIwXXsGWzpxrMTDnwOhh5NB72yutP6ykaDJl EqEaym1GH5U.9AZMjdOa5fDQM1v6pxwWQhIKCVaj44vPYHBMj4nt6JaTjwjD8VmCrujO_piE1gU. 5YkxB_Z0. Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sun, 21 Oct 2018 05:04:42 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp428.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 5bc75eeb86c3ebe70c4e718968e9b5b0; Sun, 21 Oct 2018 05:04:37 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r339076's boot loader fails to boot threadripper 1950X system (BTX halted); an earlier version works [ -r336532 broke it ] Date: Sat, 20 Oct 2018 22:04:36 -0700 References: <2A425DE4-2B5B-474D-8B95-81890DE4D8A1@yahoo.com> To: Warner Losh , FreeBSD Current , freebsd-stable@freebsd.org In-Reply-To: <2A425DE4-2B5B-474D-8B95-81890DE4D8A1@yahoo.com> Message-Id: <9D2A6528-F888-4833-A52B-8F9B4D66592C@yahoo.com> X-Mailer: Apple Mail (2.3445.9.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: Sun, 21 Oct 2018 05:04:45 -0000 [I found what change lead to the 1950X boot crashing with BTX halted.] On 2018-Oct-20, at 12:44 PM, Mark Millard wrote: > [Adding some vintage information for a loader > that allowed a native boot.] > > On 2018-Oct-20, at 4:00 AM, Mark Millard wrote: > >> I attempted to jump from head -r334014 to -r339076 >> on a threadripper 1950X board and the native >> FreeBSD boot failed very early. (Hyper-V use of >> the same media did not have this issue.) >> >> But copying over an older /boot/loader from another >> storage device with a FreeBSD head version that has >> not been updated yet got past the problem being >> reported here. (For other reasons, the kernel has >> been moved back to -r338804 --and with that, >> and the older /boot/loader, the 1950X native-boots >> FreeBSD all the way just fine.) > > I found one /boot/loader.old that was dated > in the update'd file system as 2018-May 20, > instead of 2018-Apr-03 from the older file > system. May 20 would apparently mean a little > below -r334014 . It native-booted okay, as did > the April one. > > [I do not know how to inspect a /boot/loader* > to find out what -r?????? it is from.] > > Unfortunately, I had done more than one -r339076 > install from -r334014 before rebooting and > no -r334014 loaders were still present: > the other *.old files from a few minutes before > the ones I had the boot problem with. > > I might be able to extract loaders from various: > > https://artifact.ci.freebsd.org/snapshot/head/r*/amd64/amd64/base.txz > > materials and try substituting them in order to > narrow the range for works -> fails. If I can, > this likely would take a fair amount of time in > my context. > > Other notes: > > It turns out that only Hyper-V based use needed > a -r334804 kernel: Native booting with the older > loaders and newer kernels works fine. > > Windows 10 Pro 64bit also has no problems > booting and operating the machine. > > The native-boot problem does seem to be freeBSD > loader-vintage specific. > >> For the BTX failure the display ends up with >> (hand transcribed, ". . ." for an omission): >> >> BTX loader 1.00 BTX version is 1.02 >> Console: internal video/keyboard >> BIOS drive C: is disk0 >> . . . >> BIOS drive P: is disk13 >> - >> int=00000000 err=00000000 efl=00010246 eip=000096fd >> eax=74d48000 ebx=74d4e5e0 ecx=00000011 edx=00000000 >> esi=74d4e380 edi=74d4e5b0 ebp=00091da0 esp=00091d60 >> cs=002b ds=0033 es=0033 fs=0033 gs=0033 ss=0033 >> cs:eip=66 f7 77 04 0f b7 c0 89-44 24 0c 89 5c 24 04 8b >> 45 08 89 04 24 83 64 24-10 00 c7 44 24 08 01 00 >> ss:esp=00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 >> 00 00 00 00 00 00 00 00-f0 1d 89 00 00 00 00 00 >> BTX halted > > I've no clue what of that output might be loader vintage > specific. It might not be of use without knowing the > exact build of the loader. > >> The board is a GIGABYTE X399 AORUS Gaming 7 (rev 1.0). >> It has 96 GiBytes of ECC RAM, just 6 DIMMs installed. > > For reference for the board's BIOS: > > Version: F11e > Dated: 2018-Sep-17 > Description: Update AGESA 1.1.0.1a Using: https://artifact.ci.freebsd.org/snapshot/head/r*/amd64/amd64/base.txz materials I found that: -r336492: worked (loader vs. zfsloader: not linked) (no more amd64 builds until . . .) -r336538: failed (loader vs. zfsloader: linked) (Later ones that I tried also failed.) Looks like this broke for booting the 1950X system in question when the following was checked in: Author: imp Date: Fri Jul 20 05:17:37 2018 New Revision: 336532 URL: https://svnweb.freebsd.org/changeset/base/336532 Log: Collapse zfsloader functionality back down into loader. . . . === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-stable@freebsd.org Sun Oct 21 21:01:01 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 651CA10089D8 for ; Sun, 21 Oct 2018 21:01:01 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 03FC277ABB for ; Sun, 21 Oct 2018 21:01:01 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id BB5D810089D5; Sun, 21 Oct 2018 21:01:00 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A9E5610089D0 for ; Sun, 21 Oct 2018 21:01:00 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4933877AAE for ; Sun, 21 Oct 2018 21:01:00 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 7AC924FF for ; Sun, 21 Oct 2018 21:00:59 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9LL0xI7098887 for ; Sun, 21 Oct 2018 21:00:59 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9LL0xfa098875 for stable@FreeBSD.org; Sun, 21 Oct 2018 21:00:59 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201810212100.w9LL0xfa098875@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: stable@FreeBSD.org Subject: Problem reports for stable@FreeBSD.org that need special attention Date: Sun, 21 Oct 2018 21:00:59 +0000 MIME-Version: 1.0 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, 21 Oct 2018 21:01:01 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 230620 | "install -d" issue Open | 227213 | FreeBSD 10.4 kernel deadlocks on sysctlmemlock 2 problems total for which you should take action. From owner-freebsd-stable@freebsd.org Mon Oct 22 00:12:02 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A121B104C595 for ; Mon, 22 Oct 2018 00:12:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-10.consmr.mail.gq1.yahoo.com (sonic307-10.consmr.mail.gq1.yahoo.com [98.137.64.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 289BC7DCDD for ; Mon, 22 Oct 2018 00:12:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: oHF4aGwVM1kqQuodVW3ySR9ih7PdFliZKJX4ZJsAQPMFpmbCmxdcLz0TJiI67l6 eDnXQC0CRRKH5yzT52Uf9J3xp_5QHcLBaKhO8sCfYSgnPjnNBbG7AjovxmVtmslSTtyw_ZhB.0or OzRM4mVxdP0aXa39bXwrsOvFY3EiCrIyyOFNIn5bUZem5QZ3n6ul30_YS4UDPGNRH9Wr9eonsJyB L0uU0BEhX7yM8UNo8XsQMOJAUGtC.sU_1hJVJkEFzqa3F4gpfGkqNK.8TBgNxRT._S60H.pgvKLY b7Aukh8kJAHd8gi2gAnAL_ne8DQDcmBY3647EnpKcfEc6CUiMTG5uPCE_70FiUt2xpzgAh0_jxzK RvXQkkLfTX2Zu_lA9HoCzpDACUlyYZiBt0ytrPDwRw92IqOyQszKvSXCB2on5_tinh65c7PHK4QZ frdq9CDskV0EXIzwE8UA37qiJtTGUQ8l3ASnCv485xSurYMwXQzWRw5wZS_UCDYbc9FUfSmqais1 kt9j8UK0rGzAHUln0Xpvjz4ViMGpjhfaCTLFUhUEbRmatAKaoFk3b3ak77J75Jx7bg_tyq5NgHZ1 PreHvumKDf6DMDWN1NDiCB8vqjErjMU1UdOptfeW0Xwtm1V2KmTWG7WDuzLkXZvszj28zH0.O5nM zLnjlbdaGH7IHj1sd26ULiAIkt.HqsuiZpi3hqOLe0KnT3kIv0z.zSVz2KF5GA_eYEYsIXS6IlH4 qpIROozNAgyOg5jbpp981GYIMKo5l9e6P6XlPjb_jSUueXjtpf89D263joIYszX2UNRI2psh.ykk 8PwuWusqZGMVFY593Fj1q7pwkLmQBAFSYs_Rb69VJ5ESelpEluL12TUvgyuU95xHJtwGM4VZ0RAc YVX2XsT0AzvZxreRlWTyyguYpp4shSKGne7WVnanmlpx2eUMy48Tw1Ne0D6fXYtp1WWQHuqcTTyt R_vfoWuXklw1DRGAwQvsJjCe2TPdGr.gCGjN1p_dVzfAT_UH7T.c1kCDqYAGuHz8EUBLzh6APt4g q0CLNY2Soa1PiKOAlrLHNiEHAGuETUpcer0Hpxjc5zsjKCfKYgYnbig6J2khDNFngnUjBNCF4ro8 M1pFUurU- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Mon, 22 Oct 2018 00:11:54 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp422.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 06b8f75994a09b5d566b5f2a28055cc7; Mon, 22 Oct 2018 00:11:50 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r339076's boot loader fails to boot threadripper 1950X system (BTX halted); an earlier version works [ WITHOUT_ZFS= fixes it ] From: Mark Millard In-Reply-To: <30DD2F47-C8CB-4CEC-8563-C7083D0EAEEF@yahoo.com> Date: Sun, 21 Oct 2018 17:11:50 -0700 Cc: FreeBSD Current , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <83E0D72D-04AD-48A6-89B0-4E4D6B79D749@yahoo.com> References: <2A425DE4-2B5B-474D-8B95-81890DE4D8A1@yahoo.com> <9D2A6528-F888-4833-A52B-8F9B4D66592C@yahoo.com> <30DD2F47-C8CB-4CEC-8563-C7083D0EAEEF@yahoo.com> To: Warner Losh X-Mailer: Apple Mail (2.3445.9.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: Mon, 22 Oct 2018 00:12:03 -0000 [Building and installing based on WITHOUT_ZFS=3D allows the resulting loader to work correctly on the 1950X.] On 2018-Oct-21, at 12:05 AM, Mark Millard wrote: > On 2018-Oct-20, at 10:32 PM, Warner Losh wrote: >=20 >> On Sat, Oct 20, 2018 at 11:04 PM Mark Millard = wrote: >> [I found what change lead to the 1950X boot crashing >> with BTX halted.] >>=20 >>> On 2018-Oct-20, at 12:44 PM, Mark Millard = wrote: >>>=20 >>>> [Adding some vintage information for a loader >>>> that allowed a native boot.] >>>>=20 >>>> On 2018-Oct-20, at 4:00 AM, Mark Millard = wrote: >>>>=20 >>>>> I attempted to jump from head -r334014 to -r339076 >>>>> on a threadripper 1950X board and the native >>>>> FreeBSD boot failed very early. (Hyper-V use of >>>>> the same media did not have this issue.) >>>>>=20 >>>>> But copying over an older /boot/loader from another >>>>> storage device with a FreeBSD head version that has >>>>> not been updated yet got past the problem being >>>>> reported here. (For other reasons, the kernel has >>>>> been moved back to -r338804 --and with that, >>>>> and the older /boot/loader, the 1950X native-boots >>>>> FreeBSD all the way just fine.) >>>>=20 >>>> I found one /boot/loader.old that was dated >>>> in the update'd file system as 2018-May 20, >>>> instead of 2018-Apr-03 from the older file >>>> system. May 20 would apparently mean a little >>>> below -r334014 . It native-booted okay, as did >>>> the April one. >>>>=20 >>>> [I do not know how to inspect a /boot/loader* >>>> to find out what -r?????? it is from.] >>>>=20 >>>> Unfortunately, I had done more than one -r339076 >>>> install from -r334014 before rebooting and >>>> no -r334014 loaders were still present: >>>> the other *.old files from a few minutes before >>>> the ones I had the boot problem with. >>>>=20 >>>> I might be able to extract loaders from various: >>>>=20 >>>> = https://artifact.ci.freebsd.org/snapshot/head/r*/amd64/amd64/base.txz >>>>=20 >>>> materials and try substituting them in order to >>>> narrow the range for works -> fails. If I can, >>>> this likely would take a fair amount of time in >>>> my context. >>>>=20 >>>> Other notes: >>>>=20 >>>> It turns out that only Hyper-V based use needed >>>> a -r334804 kernel: Native booting with the older >>>> loaders and newer kernels works fine. >>>>=20 >>>> Windows 10 Pro 64bit also has no problems >>>> booting and operating the machine. >>>>=20 >>>> The native-boot problem does seem to be freeBSD >>>> loader-vintage specific. >>>>=20 >>>>> For the BTX failure the display ends up with >>>>> (hand transcribed, ". . ." for an omission): >>>>>=20 >>>>> BTX loader 1.00 BTX version is 1.02 >>>>> Console: internal video/keyboard >>>>> BIOS drive C: is disk0 >>>>> . . . >>>>> BIOS drive P: is disk13 >>>>> - >>>>> int=3D00000000 err=3D00000000 efl=3D00010246 eip=3D000096fd >>>>> eax=3D74d48000 ebx=3D74d4e5e0 ecx=3D00000011 edx=3D00000000 >>>>> esi=3D74d4e380 edi=3D74d4e5b0 ebp=3D00091da0 esp=3D00091d60 >>>>> cs=3D002b ds=3D0033 es=3D0033 fs=3D0033 gs=3D0033 ss=3D0033 >>>>> cs:eip=3D66 f7 77 04 0f b7 c0 89-44 24 0c 89 5c 24 04 8b >>>>> 45 08 89 04 24 83 64 24-10 00 c7 44 24 08 01 00 >>>>> ss:esp=3D00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 >>>>> 00 00 00 00 00 00 00 00-f0 1d 89 00 00 00 00 00 >>>>> BTX halted >>>>=20 >>>> I've no clue what of that output might be loader vintage >>>> specific. It might not be of use without knowing the >>>> exact build of the loader. >>>>=20 >>>>> The board is a GIGABYTE X399 AORUS Gaming 7 (rev 1.0). >>>>> It has 96 GiBytes of ECC RAM, just 6 DIMMs installed. >>>>=20 >>>> For reference for the board's BIOS: >>>>=20 >>>> Version: F11e >>>> Dated: 2018-Sep-17 >>>> Description: Update AGESA 1.1.0.1a >>>=20 >>> Using: >>>=20 >>> = https://artifact.ci.freebsd.org/snapshot/head/r*/amd64/amd64/base.txz >>>=20 >>> materials I found that: >>>=20 >>> -r336492: worked (loader vs. zfsloader: not linked) >>> (no more amd64 builds until . . .) >>> -r336538: failed (loader vs. zfsloader: linked) >>>=20 >>> (Later ones that I tried also failed.) >>>=20 >>> Looks like this broke for booting the 1950X=20 >>> system in question when the following was >>> checked in: >>>=20 >>> Author: imp >>> Date: Fri Jul 20 05:17:37 2018 >>> New Revision: 336532 >>> URL:=20 >>> https://svnweb.freebsd.org/changeset/base/336532 >>>=20 >>>=20 >>> Log: >>> Collapse zfsloader functionality back down into loader. >>>=20 >> Yea, this shouldn't matter. It worked on all the systems I tried it = on. >>=20 >> So my first question: is this a ZFS system? Second, does it also have = UFS? If yes to both, which one do you want it to boot off of? >=20 > No zfs in use at all. It has been years since > I experimented with ZFS and reverted back to > UFS. >=20 > # gpart show -l > =3D> 40 937703008 da0 GPT (447G) > 40 1024 1 FBSDFSSDboot (512K) > 1064 746586112 2 FBSDFSSDroot (356G) > 746587176 31457280 3 FBSDFSSDswap (15G) > 778044456 159383552 4 FBSDFSSDswap2 (76G) > 937428008 275040 - free - (134M) > . . . >=20 > Doing: >=20 > gpart bootcode -p /boot/gptboot -i 1 da0 >=20 > and the trying a modern /boot/loader > did not change anything: still "BTX halted" > for a native boot. (No problem under Hyper-V.) I added WITHOUT_ZFS=3D to my equivalents of src.conf files for targeting amd64, built, and installed. The result native-boots just fine. The crash is somehow specific to loader code tied to LOADER_ZFS_SUPPORT being defined. Of course, this leaves me unable to native-boot an official, modern, unmodified build on the 1950X machine. While I do not actively use ZFS these days, I'd always left it built and installed in case I decided to do something with it at some point. I do not normally try to minimize configurations. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-stable@freebsd.org Mon Oct 22 02:55:57 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E905DFD9A48 for ; Mon, 22 Oct 2018 02:55:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-20.consmr.mail.ne1.yahoo.com (sonic303-20.consmr.mail.ne1.yahoo.com [66.163.188.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 813E283D1F for ; Mon, 22 Oct 2018 02:55:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: VhEc3yYVM1k27JbELO4NkN7laW5z9kZeYwLQiUT6T.uyBpPw_0X33QJ0Y9exs52 yHjduUpNNJZ1Al4NKZh3p5drtqSW8Sxg92C6dVmaepk7IbYGz7e9xtO91p.S8OFSHkurb2xYQZ0. VbAeCfozjVG3uzidMiCmJ72bo7OhGdOiT.ESPt77Gp1GixbYXXZ7nnf0MloJxOsFLXoY_INH8Vke 4JBOCBWqAU.MSKevbmGbQnO3CSK0F_891BlvTT1Uu0PtWLZm70N6KEJUd_ByvH9iCw253VZ.73ch TuTNDsx1QVbmF67SOFuIIi5xrvB0YeF99w_wyxw3X5UXetArI0SoUqeNGXTRubzoUSUiPWP5FdB5 F7gJuLQWZh2xXRz8Il5O0ZxNeD.LjN4hW06X5MCyZG9lpKFwAW1v4uMRliaXfsYhz.55zIfqRhjC DFDThFihasvl5PtEP.eAXMDHEOT9_wLMlgjE_67pQ9Rk7t4i4dSBTsRfbcj891Fui5s_qptE28P. YgYc.LlB.zYxzoFpw6Lxzqj3Z4WRGN9MmMSAzawXkKNEc6Z7T0lfNgVw8Mq31n.Hhuen3VH_wAnB pWEQn_Q_tZJrGCQRwgDiJb9Y13EHDo77qClRxZmDeNSG9uae6U2oRdP2U9xM4YlIqaNiJZPEAkM3 BhvbVRqlDfB8V56Q0RWktd8gIgbEi70W13mon_A8WVlBC13G_nEI_Ib0hkoZ4OzqYWxnEdCbHsT1 voDYbKSUdp6TPNVv8b08i.t7fRwY.mEzU5STqw.psxCu1.DeA5ad5ifsDezXvk8uWc.DHIGFIGNF iXVCX7Zbx2xCSud2VGbYWhZCfkqsYU6_5hk3rCmfYS2L_7kGdPa32ywCWNnVLy4gQnr699hIKOw2 XzT.Iq.hpcC7fQoZcBC4JVEVtLAGRXw6qfyaQR5Y8TevBM_q4k3qW9OWD_GxO968F5KTJRoPGK2w PgwReTKid3O72BiDX.8EcUisQM.4e.GUWxiE6taro893QLR4eOWNEn4fyvppTjPptZSO0EXH7c_n EfCBx9Wkrarnxltpg9_XqJ59m.XN_3DYTXApZYPFIFFzBqKTnrRNhE9HkwGPDTMIq7aOd1mKfgq1 ._Z58 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Mon, 22 Oct 2018 02:55:49 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp404.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 804ecb38ee3d4126093554721b6b1f8d; Mon, 22 Oct 2018 02:55:46 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated Date: Sun, 21 Oct 2018 19:55:45 -0700 References: <79973E2B-F5C4-4E7C-B92B-1C8D4441C7D1@yahoo.com> To: Konstantin Belousov , FreeBSD Current , freebsd-stable@freebsd.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.9.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: Mon, 22 Oct 2018 02:55:57 -0000 [I built based on WITHOUT_ZFS=3D for other reasons. But, after installing the build, Hyper-V based boots are working.] On 2018-Oct-20, at 2:09 AM, Mark Millard wrote: > On 2018-Oct-20, at 1:39 AM, Mark Millard wrote: >=20 >> I attempted to jump from head -r334014 to -r339076 >> on a threadripper 1950X board and the boot fails. >> This is both native booting and under Hyper-V, >> same machine and root file system in both cases. >=20 > I did my investigation under Hyper-V after seeing > a boot failure native. >=20 > Looks like the native failure is even earlier, > before db> is even possible, possibly during > early loader activity. >=20 > So this report is really for running under > Hyper-V: -r338804 boots and -r338810 does > not. By contrast -r334804 does not boot native. > (But I've little information for that context.) >=20 > Sorry for the confusion. I rushed the report > in hopes of getting to sleep. It was not to be. >=20 >> It fails just after the FreeBSD/SMP lines, >> reporting "kernel trap 9 with interrupts disabled". >>=20 >> It fails in pmap_force_invaldiate_cache_range at >> a clflusl (%rax) instruction that produces a >> "Fatal trap 9: general protection fault while >> in kernel mode". cpudid=3D0 apic id=3D 00 >>=20 >> I used kernel.txz files from: >>=20 >> https://artifact.ci.freebsd.org/snapshot/head/r*/amd64/amd64/ >>=20 >> to narrow the range of kernel builds for working -> failing >> and got: >>=20 >> -r338804 boots fine >> (no amd64 kernel builds between to try) >> -r338810+ fails (any that I tried, anyway) >>=20 >> In that range is -r338807 : >>=20 >> QUOTE >> Author: kib >> Date: Wed Sep 19 19:35:02 2018 >> New Revision: 338807 >> URL:=20 >> https://svnweb.freebsd.org/changeset/base/338807 >>=20 >>=20 >> Log: >> Convert x86 cache invalidation functions to ifuncs. >>=20 >> This simplifies the runtime logic and reduces the number of >> runtime-constant branches. >>=20 >> Reviewed by: alc, markj >> Sponsored by: The FreeBSD Foundation >> Approved by: re (gjb) >> Differential revision:=09 >> https://reviews.freebsd.org/D16736 >>=20 >> Modified: >> head/sys/amd64/amd64/pmap.c >> head/sys/amd64/include/pmap.h >> head/sys/dev/drm2/drm_os_freebsd.c >> head/sys/dev/drm2/i915/intel_ringbuffer.c >> head/sys/i386/i386/pmap.c >> head/sys/i386/i386/vm_machdep.c >> head/sys/i386/include/pmap.h >> head/sys/x86/iommu/intel_utils.c >> END QUOTE >>=20 >> There do seem to be changes associated with >> clflush(...) use. Looking at: >>=20 >> = https://svnweb.freebsd.org/base/head/sys/amd64/amd64/pmap.c?annotate=3D339= 432 >>=20 >> it appears that pmap_force_invalidate_cache_range has not >> changed since -r338807. >>=20 >> It seems that -r338806 and -r3388810 would be unlikely >> contributors. >=20 I went after my native-boot loader problem first because I could switch kernels via the loader for booting FreeBSD under Hyper-V. Switching loaders is more of a problem. In order to avoid the loader-time crash I switched to building installing based on WITHOUT_ZFS=3D . I've had no active use of ZFS in years. (The old official-build loaders that worked were non-ZFS ones.) This took care of the native-boot loader-crash --and, to my surprise, also the Hyper-V-boot kernel-time crash. My private builds now boot the 1950X in both contexts just fine. During my early investigation I did pick up specific changes from after -r339076 that seemed to be tied to Ryzen and such. (They made no difference to the boot problems at the time but I saw no reason to remove them.) # uname -apKU FreeBSD FBSDFSSD 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #5 r339076:339432M: Sun = Oct 21 16:44:25 PDT 2018 = markmi@FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/G= ENERIC-NODBG amd64 amd64 1200084 1200084 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-stable@freebsd.org Mon Oct 22 03:29:03 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39863FE598A for ; Mon, 22 Oct 2018 03:29:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B12058514C for ; Mon, 22 Oct 2018 03:29:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe30.google.com with SMTP id m5so28678927vsk.6 for ; Sun, 21 Oct 2018 20:29:02 -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=9pm7BX5piXUzbLjtx4i7rZTJvhkWQAPzMzflVHKzHzA=; b=r7Bja/HtGDUwvRQk7RMVscP2SBVmbtinMhtyIWn/BAI/QFdiGW34DwakBZvOBO3TXh fwjggsbyS1kGGdfWzPU6V4DmKjfZ66rwbwnLA5AAa4XBs35+nJXdKnMcYaZlrwzsxXZF vdwZj7tmrlZgsKzA/czD4HGapxyankcBmqkfGtCGkNu4ixA7nbHBWdxkQh/aofUnTEA0 ZcVqx7gKukXfBNEXWHx5pNWdiPlfoDY7e4FWPR/0j3JIGLH67OD8xoSLqSLZ56uDPyYK XdoSJQ/aUZ1Hqg+YbDvH1EDOoeZyUcLKRTTBp5KwjOtB8/KypPqevZ0E0w5+3K3ShdCD 7XAg== 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=9pm7BX5piXUzbLjtx4i7rZTJvhkWQAPzMzflVHKzHzA=; b=gC9W79ZShFosEZpY7rwkw1hhcE4U6gxtyUrBiKdWT9DhmHJId91iJ2D9HU8Ihbg8Ig KSiAzvqKBACIFRJGPGxtAitJ3B1kk8Dhvdzniw1jonwUD7Gfh9eCpbNEsnWAvjG9PGps 1GSxsVzrSWXNhL0wu3MNCDp3FBWmyR+Xbjl2V/TxdqbaXmgBNFzWS++ENBN0JVJsKn5v LQEuqYVQfS/Mjcle/0UfP9NJQUD8vicQOSw+KotKKthzOGnIwoXgkMruRxzLyNVGsBWi ysuq1zijZw4nY2Lyz/jAcWjFlyJ9uDSGIs8bQAt/90qdkzXmo42ekdW90C1G/JevVA0l cRqg== X-Gm-Message-State: ABuFfohuCs91CQbVVe7iadQA/yWYYZvxbibX+CxXa0rt4hopL/2EgPUB tKLowDCD/Wkj6jjTcjvTkfF1Toi3vgYNQiemHsVhwQ== X-Google-Smtp-Source: ACcGV606LRAE5fUoQyP7pGPBP3ltaPXRBVSTKjYaqkORID371gRbPcsm5s8Tsfn2UVtrtu1/eafnbFdO/EK8mE6qfUE= X-Received: by 2002:a67:4dc7:: with SMTP id i68mr18183109vsg.46.1540178942064; Sun, 21 Oct 2018 20:29:02 -0700 (PDT) MIME-Version: 1.0 References: <79973E2B-F5C4-4E7C-B92B-1C8D4441C7D1@yahoo.com> In-Reply-To: From: Warner Losh Date: Sun, 21 Oct 2018 21:28:51 -0600 Message-ID: Subject: Re: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated To: Mark Millard Cc: Konstantin Belousov , FreeBSD Current , FreeBSD-STABLE Mailing List 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: Mon, 22 Oct 2018 03:29:03 -0000 On Sun, Oct 21, 2018 at 8:57 PM Mark Millard via freebsd-stable < freebsd-stable@freebsd.org> wrote: > [I built based on WITHOUT_ZFS= for other reasons. But, > after installing the build, Hyper-V based boots are > working.] > > On 2018-Oct-20, at 2:09 AM, Mark Millard wrote: > > > On 2018-Oct-20, at 1:39 AM, Mark Millard wrote: > > > >> I attempted to jump from head -r334014 to -r339076 > >> on a threadripper 1950X board and the boot fails. > >> This is both native booting and under Hyper-V, > >> same machine and root file system in both cases. > > > > I did my investigation under Hyper-V after seeing > > a boot failure native. > > > > Looks like the native failure is even earlier, > > before db> is even possible, possibly during > > early loader activity. > > > > So this report is really for running under > > Hyper-V: -r338804 boots and -r338810 does > > not. By contrast -r334804 does not boot native. > > (But I've little information for that context.) > > > > Sorry for the confusion. I rushed the report > > in hopes of getting to sleep. It was not to be. > > > >> It fails just after the FreeBSD/SMP lines, > >> reporting "kernel trap 9 with interrupts disabled". > >> > >> It fails in pmap_force_invaldiate_cache_range at > >> a clflusl (%rax) instruction that produces a > >> "Fatal trap 9: general protection fault while > >> in kernel mode". cpudid=0 apic id= 00 > >> > >> I used kernel.txz files from: > >> > >> https://artifact.ci.freebsd.org/snapshot/head/r*/amd64/amd64/ > >> > >> to narrow the range of kernel builds for working -> failing > >> and got: > >> > >> -r338804 boots fine > >> (no amd64 kernel builds between to try) > >> -r338810+ fails (any that I tried, anyway) > >> > >> In that range is -r338807 : > >> > >> QUOTE > >> Author: kib > >> Date: Wed Sep 19 19:35:02 2018 > >> New Revision: 338807 > >> URL: > >> https://svnweb.freebsd.org/changeset/base/338807 > >> > >> > >> Log: > >> Convert x86 cache invalidation functions to ifuncs. > >> > >> This simplifies the runtime logic and reduces the number of > >> runtime-constant branches. > >> > >> Reviewed by: alc, markj > >> Sponsored by: The FreeBSD Foundation > >> Approved by: re (gjb) > >> Differential revision: > >> https://reviews.freebsd.org/D16736 > >> > >> Modified: > >> head/sys/amd64/amd64/pmap.c > >> head/sys/amd64/include/pmap.h > >> head/sys/dev/drm2/drm_os_freebsd.c > >> head/sys/dev/drm2/i915/intel_ringbuffer.c > >> head/sys/i386/i386/pmap.c > >> head/sys/i386/i386/vm_machdep.c > >> head/sys/i386/include/pmap.h > >> head/sys/x86/iommu/intel_utils.c > >> END QUOTE > >> > >> There do seem to be changes associated with > >> clflush(...) use. Looking at: > >> > >> > https://svnweb.freebsd.org/base/head/sys/amd64/amd64/pmap.c?annotate=339432 > >> > >> it appears that pmap_force_invalidate_cache_range has not > >> changed since -r338807. > >> > >> It seems that -r338806 and -r3388810 would be unlikely > >> contributors. > > > > I went after my native-boot loader problem first because I > could switch kernels via the loader for booting FreeBSD under > Hyper-V. Switching loaders is more of a problem. > > In order to avoid the loader-time crash I switched to building > installing based on WITHOUT_ZFS= . I've had no active use of > ZFS in years. (The old official-build loaders that worked were > non-ZFS ones.) > > This took care of the native-boot loader-crash --and, to my > surprise, also the Hyper-V-boot kernel-time crash. > > My private builds now boot the 1950X in both contexts just > fine. > > During my early investigation I did pick up specific changes > from after -r339076 that seemed to be tied to Ryzen and such. > (They made no difference to the boot problems at the time > but I saw no reason to remove them.) > > # uname -apKU > FreeBSD FBSDFSSD 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #5 r339076:339432M: Sun > Oct 21 16:44:25 PDT 2018 markmi@FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG > amd64 amd64 1200084 1200084 > The phrase "no active use" bothers me. What does that mean? Are there any Warner From owner-freebsd-stable@freebsd.org Mon Oct 22 03:30:16 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0CFDEFE5A61 for ; Mon, 22 Oct 2018 03:30:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5560585329 for ; Mon, 22 Oct 2018 03:30:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe36.google.com with SMTP id c10so28710230vsk.2 for ; Sun, 21 Oct 2018 20:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:from:date:message-id:subject:to:cc; bh=Ht5DIerp556qK0YwFNRGn4D34h+CICXjOmHriUjRbMY=; b=jhOm6EgDYtSEDKy4mn2nndadRCMlAOO1f+TFYoAQNdNHfLx3yYHGsVGJ9TY++473fe fVDk5nwfgUU67NqMKhb7ox5XOvVitGAUUAeFAns5HKc8XsVk0Rm1Tj7oDl94ITc5QMxP biVO7ZddCzhgfGINPGh6piaKh7mTgxB5dJD8hCiVl/+ubknPNMW0+74T68mLDSIhGdbP B+MnJ6QQe7V5AijrwGhj98O8PH8CnGmUKgI0br+atUDb0U/C116pj9WRkMnNBc7qcy70 G/qxm/WzEr/Jqnads7IEBWSOg7bQPFch2mdkk7vo9KR03a1doFcMa8N5bnPlbR58k6g7 Yu1g== 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:from:date:message-id :subject:to:cc; bh=Ht5DIerp556qK0YwFNRGn4D34h+CICXjOmHriUjRbMY=; b=Sn/BXRCwXpST4rgPy8gdHTHdPusQecvy710F1mqJZXH2Noca4LESF3cvOR9AUCSZJJ LQwft5Q2/pR0Th1rU3uGg1TtSpPXfd2w3A0gRfY7I/DmzwuKHcotlSCmDn+LGVJwNJ7Y vjSd7OUgKjkMvTB6cphNyUFUZ6hCAHAj8rQ+BXOjCvf5OvD3uFdioA9CbMmqPQTuVp3c YWbmOZnKJdC1nw/b4oJ7VF79hhLKyQThLh1EW5+1YIJ5eTpOfEJZjKUhg/EyA7G+ADzp VBfFh21v4CyQ+P/OkB4cyhzwCeg/L0wCtJxGlBKP4CVaQPuVWFYM1lPsX/fgdmu3Y8g8 V1Mg== X-Gm-Message-State: ABuFfojfCkDePkIqJFV4bz9F+cjBwb4yEDXl72H0FROs7WwwmQ+8rMQ6 ORm525dqGUy/edehRzBvPc4KGi5FWTkwRJY7Yds6lQ== X-Google-Smtp-Source: ACcGV61ItgNznFjKRg5GoRmi7YvDINjSnwPzyRMxqliqgxGcug0W/UH/SIQuJC2ODSju2XM5pwb/aYjuBFtNm8GY3+c= X-Received: by 2002:a67:2704:: with SMTP id n4mr18714119vsn.209.1540179014632; Sun, 21 Oct 2018 20:30:14 -0700 (PDT) MIME-Version: 1.0 References: <79973E2B-F5C4-4E7C-B92B-1C8D4441C7D1@yahoo.com> From: Warner Losh Date: Sun, 21 Oct 2018 21:30:03 -0600 Message-ID: Subject: Re: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated To: Mark Millard Cc: Konstantin Belousov , FreeBSD Current , FreeBSD-STABLE Mailing List 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: Mon, 22 Oct 2018 03:30:16 -0000 On Sun, Oct 21, 2018 at 9:28 PM Warner Losh wrote: > > > On Sun, Oct 21, 2018 at 8:57 PM Mark Millard via freebsd-stable < > freebsd-stable@freebsd.org> wrote: > >> [I built based on WITHOUT_ZFS= for other reasons. But, >> after installing the build, Hyper-V based boots are >> working.] >> >> On 2018-Oct-20, at 2:09 AM, Mark Millard wrote: >> >> > On 2018-Oct-20, at 1:39 AM, Mark Millard wrote: >> > >> >> I attempted to jump from head -r334014 to -r339076 >> >> on a threadripper 1950X board and the boot fails. >> >> This is both native booting and under Hyper-V, >> >> same machine and root file system in both cases. >> > >> > I did my investigation under Hyper-V after seeing >> > a boot failure native. >> > >> > Looks like the native failure is even earlier, >> > before db> is even possible, possibly during >> > early loader activity. >> > >> > So this report is really for running under >> > Hyper-V: -r338804 boots and -r338810 does >> > not. By contrast -r334804 does not boot native. >> > (But I've little information for that context.) >> > >> > Sorry for the confusion. I rushed the report >> > in hopes of getting to sleep. It was not to be. >> > >> >> It fails just after the FreeBSD/SMP lines, >> >> reporting "kernel trap 9 with interrupts disabled". >> >> >> >> It fails in pmap_force_invaldiate_cache_range at >> >> a clflusl (%rax) instruction that produces a >> >> "Fatal trap 9: general protection fault while >> >> in kernel mode". cpudid=0 apic id= 00 >> >> >> >> I used kernel.txz files from: >> >> >> >> https://artifact.ci.freebsd.org/snapshot/head/r*/amd64/amd64/ >> >> >> >> to narrow the range of kernel builds for working -> failing >> >> and got: >> >> >> >> -r338804 boots fine >> >> (no amd64 kernel builds between to try) >> >> -r338810+ fails (any that I tried, anyway) >> >> >> >> In that range is -r338807 : >> >> >> >> QUOTE >> >> Author: kib >> >> Date: Wed Sep 19 19:35:02 2018 >> >> New Revision: 338807 >> >> URL: >> >> https://svnweb.freebsd.org/changeset/base/338807 >> >> >> >> >> >> Log: >> >> Convert x86 cache invalidation functions to ifuncs. >> >> >> >> This simplifies the runtime logic and reduces the number of >> >> runtime-constant branches. >> >> >> >> Reviewed by: alc, markj >> >> Sponsored by: The FreeBSD Foundation >> >> Approved by: re (gjb) >> >> Differential revision: >> >> https://reviews.freebsd.org/D16736 >> >> >> >> Modified: >> >> head/sys/amd64/amd64/pmap.c >> >> head/sys/amd64/include/pmap.h >> >> head/sys/dev/drm2/drm_os_freebsd.c >> >> head/sys/dev/drm2/i915/intel_ringbuffer.c >> >> head/sys/i386/i386/pmap.c >> >> head/sys/i386/i386/vm_machdep.c >> >> head/sys/i386/include/pmap.h >> >> head/sys/x86/iommu/intel_utils.c >> >> END QUOTE >> >> >> >> There do seem to be changes associated with >> >> clflush(...) use. Looking at: >> >> >> >> >> https://svnweb.freebsd.org/base/head/sys/amd64/amd64/pmap.c?annotate=339432 >> >> >> >> it appears that pmap_force_invalidate_cache_range has not >> >> changed since -r338807. >> >> >> >> It seems that -r338806 and -r3388810 would be unlikely >> >> contributors. >> > >> >> I went after my native-boot loader problem first because I >> could switch kernels via the loader for booting FreeBSD under >> Hyper-V. Switching loaders is more of a problem. >> >> In order to avoid the loader-time crash I switched to building >> installing based on WITHOUT_ZFS= . I've had no active use of >> ZFS in years. (The old official-build loaders that worked were >> non-ZFS ones.) >> >> This took care of the native-boot loader-crash --and, to my >> surprise, also the Hyper-V-boot kernel-time crash. >> >> My private builds now boot the 1950X in both contexts just >> fine. >> >> During my early investigation I did pick up specific changes >> from after -r339076 that seemed to be tied to Ryzen and such. >> (They made no difference to the boot problems at the time >> but I saw no reason to remove them.) >> >> # uname -apKU >> FreeBSD FBSDFSSD 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #5 r339076:339432M: Sun >> Oct 21 16:44:25 PDT 2018 markmi@FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG >> amd64 amd64 1200084 1200084 > > (stupid gmail) The phrase "no active use" bothers me. What does that mean? Are there any ZFS pools or any disks that any whiff of ZFSish thing on it at all? Clearly, there's something in the zfs boot loader that's freaking out by something on your system, but absent that information I can't help you. Warner From owner-freebsd-stable@freebsd.org Mon Oct 22 06:24:48 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97A7EFEB024 for ; Mon, 22 Oct 2018 06:24:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-20.consmr.mail.gq1.yahoo.com (sonic302-20.consmr.mail.gq1.yahoo.com [98.137.68.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 16BD38A949 for ; Mon, 22 Oct 2018 06:24:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ErJBlfwVM1lfgwU6ltYo8BAg0SJQD7.4XnuSdvhbbh6XYcvxnlNyIKEtDbthJkb 5WJYfDF3JzNMxa5s6mY3GwqWjMh4f7KgphAZh_bABXJWDllGuEKNBiVUZNT5aWOr2jt1a59lXeNc Rq5oRj6T0rsaKOPiUrgVDGiUU85IWiTUfCm8zdZuCITHoM8g8yGggNBBtiDoq2hfWIYQopN_odwE eOt6LyzkTsry0uw5.xKclpYo2atTdfwfoAyli66rITFq4OUvWs55gvTymD4nvkVJi2lRRNorp86v y8f.pfr9sijGagUexB35bmB.Oj_Apj45lzewZp_9xZsk9TOE_T3FBDew9EQ1KDY8kIvXl9hIKXbu 6MdeBPlHdVveyo0WdLEG3sNZ5f_TrC39lU7a5.wnqMn8dFxh4Cpat6ZPgWDWf_gPQkafaIrRX5fc 4n7rTTG2_5LQW3DrNIrMMKvRMZlyyYtQr1Uuhn01Ll7Sg_zDmLen9A_76pgFJBvgq3bZzopey_Fz zFo0So_05fM4vQmZCoRU_Kh5MjiMr6Q7LsmhPCVT7ZU7Vthn4ZzCicxSJd6vZHImKapyL8JixfK5 1xy_kPdvDI4N10.aDv2FRwFx.uEeWmaqhD7GWuZZpk7ofr0CzU9xJCjtx_Td76Y3aALc6WBnDr2O d9XswEmMqtpqx9M6fNxICiBEoHQIQteRXcTd1tTWpJqwO0ZVZn3eu5_I_5.0GhzLslQe6QKSsFUR iTpkyvVL8DQs3x7N8megRp1oRJYR2cLFixHDI4GI4_tXoxwkj2syr7exmgz8.wDIHECEGuHyAZNA 7FPDmmpHEEr61FdJUr9fF7q7GbJj3Ku7PWkohaIXa6CsuWcr3TOMZS2SKycqApPTlRtaja7yYxja Dp78XD3LXU2Vzb44o8yorgdvkNXC1aUtYrinrFdtgAmQKsLbjl18zb9DvbeZImcIXG7BvhWwPeQB jnO6YmLI8HoiG.W7YvM8HDOcjzU9cjfKOl6JyhkFDn9Nb8obJd84ppv139z6P5iVgGSW6wfHfcWB etiokcpLtKM_zw8mgXd4SzRXUar4dA1xD3GWHIXZMTHaRiPyUoPN1_7n8hLgzpNZLRtkecVUWKOn jqtHs8x4- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Mon, 22 Oct 2018 06:24:46 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp420.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID df388ffb0415382608330f6a339da29d; Mon, 22 Oct 2018 06:24:44 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated From: Mark Millard In-Reply-To: Date: Sun, 21 Oct 2018 23:24:43 -0700 Cc: Konstantin Belousov , FreeBSD Current , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <50C22D2F-0D72-4485-9AE2-E22EC336F8CB@yahoo.com> References: <79973E2B-F5C4-4E7C-B92B-1C8D4441C7D1@yahoo.com> To: Warner Losh X-Mailer: Apple Mail (2.3445.9.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: Mon, 22 Oct 2018 06:24:48 -0000 On 2018-Oct-21, at 8:30 PM, Warner Losh wrote: > On Sun, Oct 21, 2018 at 9:28 PM Warner Losh wrote: >=20 > On Sun, Oct 21, 2018 at 8:57 PM Mark Millard via freebsd-stable = wrote: >> [I built based on WITHOUT_ZFS=3D for other reasons. But, >> after installing the build, Hyper-V based boots are >> working.] >>=20 >> On 2018-Oct-20, at 2:09 AM, Mark Millard = wrote: >>=20 >> > On 2018-Oct-20, at 1:39 AM, Mark Millard = wrote: >> >=20 >> >> I attempted to jump from head -r334014 to -r339076 >> >> on a threadripper 1950X board and the boot fails. >> >> This is both native booting and under Hyper-V, >> >> same machine and root file system in both cases. >> >=20 >> > I did my investigation under Hyper-V after seeing >> > a boot failure native. >> >=20 >> > Looks like the native failure is even earlier, >> > before db> is even possible, possibly during >> > early loader activity. >> >=20 >> > So this report is really for running under >> > Hyper-V: -r338804 boots and -r338810 does >> > not. By contrast -r334804 does not boot native. >> > (But I've little information for that context.) >> >=20 >> > Sorry for the confusion. I rushed the report >> > in hopes of getting to sleep. It was not to be. >> >=20 >> >> It fails just after the FreeBSD/SMP lines, >> >> reporting "kernel trap 9 with interrupts disabled". >> >>=20 >> >> It fails in pmap_force_invaldiate_cache_range at >> >> a clflusl (%rax) instruction that produces a >> >> "Fatal trap 9: general protection fault while >> >> in kernel mode". cpudid=3D0 apic id=3D 00 >> >>=20 >> >> I used kernel.txz files from: >> >>=20 >> >> https://artifact.ci.freebsd.org/snapshot/head/r*/amd64/amd64/ >> >>=20 >> >> to narrow the range of kernel builds for working -> failing >> >> and got: >> >>=20 >> >> -r338804 boots fine >> >> (no amd64 kernel builds between to try) >> >> -r338810+ fails (any that I tried, anyway) >> >>=20 >> >> In that range is -r338807 : >> >>=20 >> >> QUOTE >> >> Author: kib >> >> Date: Wed Sep 19 19:35:02 2018 >> >> New Revision: 338807 >> >> URL:=20 >> >> https://svnweb.freebsd.org/changeset/base/338807 >> >>=20 >> >>=20 >> >> Log: >> >> Convert x86 cache invalidation functions to ifuncs. >> >>=20 >> >> This simplifies the runtime logic and reduces the number of >> >> runtime-constant branches. >> >>=20 >> >> Reviewed by: alc, markj >> >> Sponsored by: The FreeBSD Foundation >> >> Approved by: re (gjb) >> >> Differential revision: =20 >> >> https://reviews.freebsd.org/D16736 >> >>=20 >> >> Modified: >> >> head/sys/amd64/amd64/pmap.c >> >> head/sys/amd64/include/pmap.h >> >> head/sys/dev/drm2/drm_os_freebsd.c >> >> head/sys/dev/drm2/i915/intel_ringbuffer.c >> >> head/sys/i386/i386/pmap.c >> >> head/sys/i386/i386/vm_machdep.c >> >> head/sys/i386/include/pmap.h >> >> head/sys/x86/iommu/intel_utils.c >> >> END QUOTE >> >>=20 >> >> There do seem to be changes associated with >> >> clflush(...) use. Looking at: >> >>=20 >> >> = https://svnweb.freebsd.org/base/head/sys/amd64/amd64/pmap.c?annotate=3D339= 432 >> >>=20 >> >> it appears that pmap_force_invalidate_cache_range has not >> >> changed since -r338807. >> >>=20 >> >> It seems that -r338806 and -r3388810 would be unlikely >> >> contributors. >> >=20 >>=20 >> I went after my native-boot loader problem first because I >> could switch kernels via the loader for booting FreeBSD under >> Hyper-V. Switching loaders is more of a problem. >>=20 >> In order to avoid the loader-time crash I switched to building >> installing based on WITHOUT_ZFS=3D . I've had no active use of >> ZFS in years. (The old official-build loaders that worked were >> non-ZFS ones.) >>=20 >> This took care of the native-boot loader-crash --and, to my >> surprise, also the Hyper-V-boot kernel-time crash. >>=20 >> My private builds now boot the 1950X in both contexts just >> fine. >>=20 >> During my early investigation I did pick up specific changes >> from after -r339076 that seemed to be tied to Ryzen and such. >> (They made no difference to the boot problems at the time >> but I saw no reason to remove them.) >>=20 >> # uname -apKU >> FreeBSD FBSDFSSD 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #5 r339076:339432M: = Sun Oct 21 16:44:25 PDT 2018 = markmi@FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/G= ENERIC-NODBG amd64 amd64 1200084 1200084 >>=20 >> (stupid gmail)=20 >=20 > The phrase "no active use" bothers me. What does that mean? Are there = any ZFS pools or any disks that any whiff of ZFSish thing on it at all? = Clearly, there's something in the zfs boot loader that's freaking out by = something on your system, but absent that information I can't help you. No ZFS pools: Strictly UFS for FreeBSD file systems for the last few years, UFS before I had access to the 1950X system. I've never before bothered to use WITHOUT_ZFS=3D in my builds. So the system had the ZFS support, such as kernel modules, over all the time that this system had been in use. Prior to the recent versions I saw no such problems. But the default loader was not ZFS capable. As seen in the under-Hyper-V use-context: # gpart show -p =3D> 40 937703008 da0 GPT (447G) 40 1024 da0p1 freebsd-boot (512K) 1064 746586112 da0p2 freebsd-ufs (356G) 746587176 31457280 da0p3 freebsd-swap (15G) 778044456 159383552 da0p4 freebsd-swap (76G) 937428008 275040 - free - (134M) =3D> 40 937703008 da1 GPT (447G) 40 1024 da1p1 freebsd-boot (512K) 1064 369098752 da1p2 freebsd-ufs (176G) 369099816 406846424 da1p3 freebsd-swap (194G) 775946240 130024488 - free - (62G) 905970728 31457280 da1p4 freebsd-swap (15G) 937428008 275040 - free - (134M) =3D> 40 419430320 da2 GPT (200G) 40 4056 - free - (2.0M) 4096 419426263 da2p1 freebsd-ufs (200G) 419430359 1 - free - (512B) =3D> 40 2000409184 da3 GPT (954G) 40 1024 da3p1 freebsd-boot (512K) 1064 2000408159 da3p2 freebsd-ufs (954G) 2000409223 1 - free - (512B) So no ZFS pools. The above context never had the ZFS-capable loader problem but did have the kernel problem. I was booting the 356G freebsd-ufs partition: the only one that I have updated the FreeBSD version on so far. FreeBSD booted natively more drives are seen in gpart show, some not from/for FreeBSD. But the above drives are present and I was booting from the same partition of the same drive: the 356G freebsd-ufs partition. Still no ZFS pools anywhere: # gpart show -p =3D> 34 4000797293 nvd0 GPT (1.9T) 34 262144 nvd0p1 ms-reserved (128M) 262178 2014 - free - (1.0M) 264192 3600451584 nvd0p2 ms-basic-data (1.7T) 3600715776 400081551 - free - (191G) =3D> 40 937703008 nvd1 GPT (447G) 40 1024 nvd1p1 freebsd-boot (512K) 1064 746586112 nvd1p2 freebsd-ufs (356G) 746587176 31457280 nvd1p3 freebsd-swap (15G) 778044456 159383552 nvd1p4 freebsd-swap (76G) 937428008 275040 - free - (134M) =3D> 40 937703008 nvd2 GPT (447G) 40 1024 nvd2p1 freebsd-boot (512K) 1064 369098752 nvd2p2 freebsd-ufs (176G) 369099816 406846424 nvd2p3 freebsd-swap (194G) 775946240 130024488 - free - (62G) 905970728 31457280 nvd2p4 freebsd-swap (15G) 937428008 275040 - free - (134M) =3D> 34 2000409197 nvd3 GPT (954G) 34 2014 - free - (1.0M) 2048 1021952 nvd3p1 ms-recovery (499M) 1024000 202752 nvd3p2 efi (99M) 1226752 32768 nvd3p3 ms-reserved (16M) 1259520 1859119104 nvd3p4 ms-basic-data (886G) 1860378624 140030607 - free - (67G) =3D> 40 2000409184 nvd4 GPT (954G) 40 1024 nvd4p1 freebsd-boot (512K) 1064 2000408159 nvd4p2 freebsd-ufs (954G) 2000409223 1 - free - (512B) =3D> 63 2000409201 ada0 MBR (954G) 63 1985 - free - (993K) 2048 4096 ada0s1 linux-data (2.0M) 6144 2093056 - free - (1.0G) 2099200 1998309376 ada0s2 linux-lvm (953G) 2000408576 688 - free - (344K) =3D> 34 2000409197 ada1 GPT (954G) 34 262144 ada1p1 ms-reserved (128M) 262178 2000147053 - free - (954G) =3D> 34 2000409197 ada2 GPT (954G) 34 262144 ada2p1 ms-reserved (128M) 262178 2000147053 - free - (954G) =3D> 34 1953497022 da0 GPT (932G) 34 262144 da0p1 ms-reserved (128M) 262178 2014 - free - (1.0M) 264192 1953230848 da0p2 ms-basic-data (931G) 1953495040 2016 - free - (1.0M) =3D> 1 60062499 da1 MBR (29G) 1 31 - free - (16K) 32 60062468 da1s1 fat32lba (29G) The 356G freebsd-ufs partition is the only one of the freebsd-ufs partitions updated so far. This is the context that had the problem with the ZFS-capable loaders --but no later kernel problem when a not-ZFS-capable loader was used (via copying over an older one --until I did the WITHOUT_ZFS=3D build/install). As for the ZFS-capable loader: May it has problems when it sees one or more of: ms-reserved (on GPT) ms-basic-data (on GPT) (NTFS file system) ms-recovery (on GPT) efi (on GPT) linux-data (on MBR) linux-lvm (on MBR) fat32lba (on MBR) (given that none of these is available in the Hyper-V context as the virtual machine has been configured). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-stable@freebsd.org Mon Oct 22 09:28:24 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1215FF0F1B; Mon, 22 Oct 2018 09:28:23 +0000 (UTC) (envelope-from tsoome@me.com) Received: from pv33p00im-asmtp001.me.com (pv33p00im-asmtp001.me.com [17.142.194.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 56E3570B0D; Mon, 22 Oct 2018 09:28:23 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.pv33p00im-asmtp001.me.com by pv33p00im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) id <0PGZ00400U1AD700@pv33p00im-asmtp001.me.com>; Mon, 22 Oct 2018 09:28:11 +0000 (GMT) Received: from icloud.com ([127.0.0.1]) by pv33p00im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) with ESMTPSA id <0PGZ00FNHUA5JG20@pv33p00im-asmtp001.me.com>; Mon, 22 Oct 2018 09:27:46 +0000 (GMT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810220085 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-21_14:,, signatures=0 From: Toomas Soome Message-id: <3CA4C94F-A062-44FE-B507-948A6F88C83D@me.com> MIME-version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Subject: Re: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated Date: Mon, 22 Oct 2018 12:27:40 +0300 In-reply-to: Cc: Konstantin Belousov , FreeBSD Current , FreeBSD-STABLE Mailing List , Warner Losh To: Mark Millard References: <79973E2B-F5C4-4E7C-B92B-1C8D4441C7D1@yahoo.com> X-Mailer: Apple Mail (2.3445.100.39) 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: Mon, 22 Oct 2018 09:28:24 -0000 > On 22 Oct 2018, at 06:30, Warner Losh wrote: >=20 > On Sun, Oct 21, 2018 at 9:28 PM Warner Losh > wrote: >=20 >>=20 >>=20 >> On Sun, Oct 21, 2018 at 8:57 PM Mark Millard via freebsd-stable < >> freebsd-stable@freebsd.org> wrote: >>=20 >>> [I built based on WITHOUT_ZFS=3D for other reasons. But, >>> after installing the build, Hyper-V based boots are >>> working.] >>>=20 >>> On 2018-Oct-20, at 2:09 AM, Mark Millard = wrote: >>>=20 >>>> On 2018-Oct-20, at 1:39 AM, Mark Millard = wrote: >>>>=20 >>>>> I attempted to jump from head -r334014 to -r339076 >>>>> on a threadripper 1950X board and the boot fails. >>>>> This is both native booting and under Hyper-V, >>>>> same machine and root file system in both cases. >>>>=20 >>>> I did my investigation under Hyper-V after seeing >>>> a boot failure native. >>>>=20 >>>> Looks like the native failure is even earlier, >>>> before db> is even possible, possibly during >>>> early loader activity. >>>>=20 >>>> So this report is really for running under >>>> Hyper-V: -r338804 boots and -r338810 does >>>> not. By contrast -r334804 does not boot native. >>>> (But I've little information for that context.) >>>>=20 >>>> Sorry for the confusion. I rushed the report >>>> in hopes of getting to sleep. It was not to be. >>>>=20 >>>>> It fails just after the FreeBSD/SMP lines, >>>>> reporting "kernel trap 9 with interrupts disabled". >>>>>=20 >>>>> It fails in pmap_force_invaldiate_cache_range at >>>>> a clflusl (%rax) instruction that produces a >>>>> "Fatal trap 9: general protection fault while >>>>> in kernel mode". cpudid=3D0 apic id=3D 00 >>>>>=20 >>>>> I used kernel.txz files from: >>>>>=20 >>>>> https://artifact.ci.freebsd.org/snapshot/head/r*/amd64/amd64/ >>>>>=20 >>>>> to narrow the range of kernel builds for working -> failing >>>>> and got: >>>>>=20 >>>>> -r338804 boots fine >>>>> (no amd64 kernel builds between to try) >>>>> -r338810+ fails (any that I tried, anyway) >>>>>=20 >>>>> In that range is -r338807 : >>>>>=20 >>>>> QUOTE >>>>> Author: kib >>>>> Date: Wed Sep 19 19:35:02 2018 >>>>> New Revision: 338807 >>>>> URL: >>>>> https://svnweb.freebsd.org/changeset/base/338807 >>>>>=20 >>>>>=20 >>>>> Log: >>>>> Convert x86 cache invalidation functions to ifuncs. >>>>>=20 >>>>> This simplifies the runtime logic and reduces the number of >>>>> runtime-constant branches. >>>>>=20 >>>>> Reviewed by: alc, markj >>>>> Sponsored by: The FreeBSD Foundation >>>>> Approved by: re (gjb) >>>>> Differential revision: >>>>> https://reviews.freebsd.org/D16736 >>>>>=20 >>>>> Modified: >>>>> head/sys/amd64/amd64/pmap.c >>>>> head/sys/amd64/include/pmap.h >>>>> head/sys/dev/drm2/drm_os_freebsd.c >>>>> head/sys/dev/drm2/i915/intel_ringbuffer.c >>>>> head/sys/i386/i386/pmap.c >>>>> head/sys/i386/i386/vm_machdep.c >>>>> head/sys/i386/include/pmap.h >>>>> head/sys/x86/iommu/intel_utils.c >>>>> END QUOTE >>>>>=20 >>>>> There do seem to be changes associated with >>>>> clflush(...) use. Looking at: >>>>>=20 >>>>>=20 >>> = https://svnweb.freebsd.org/base/head/sys/amd64/amd64/pmap.c?annotate=3D339= 432 >>>>>=20 >>>>> it appears that pmap_force_invalidate_cache_range has not >>>>> changed since -r338807. >>>>>=20 >>>>> It seems that -r338806 and -r3388810 would be unlikely >>>>> contributors. >>>>=20 >>>=20 >>> I went after my native-boot loader problem first because I >>> could switch kernels via the loader for booting FreeBSD under >>> Hyper-V. Switching loaders is more of a problem. >>>=20 >>> In order to avoid the loader-time crash I switched to building >>> installing based on WITHOUT_ZFS=3D . I've had no active use of >>> ZFS in years. (The old official-build loaders that worked were >>> non-ZFS ones.) >>>=20 >>> This took care of the native-boot loader-crash --and, to my >>> surprise, also the Hyper-V-boot kernel-time crash. >>>=20 >>> My private builds now boot the 1950X in both contexts just >>> fine. >>>=20 >>> During my early investigation I did pick up specific changes >>> from after -r339076 that seemed to be tied to Ryzen and such. >>> (They made no difference to the boot problems at the time >>> but I saw no reason to remove them.) >>>=20 >>> # uname -apKU >>> FreeBSD FBSDFSSD 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #5 r339076:339432M: = Sun >>> Oct 21 16:44:25 PDT 2018 = markmi@FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/G= ENERIC-NODBG >>> amd64 amd64 1200084 1200084 >>=20 >>=20 > (stupid gmail) >=20 > The phrase "no active use" bothers me. What does that mean? Are there = any > ZFS pools or any disks that any whiff of ZFSish thing on it at all? > Clearly, there's something in the zfs boot loader that's freaking out = by > something on your system, but absent that information I can't help = you. >=20 It would help to get output from loader lsdev -v command. Also if you = could test boot loader with UEFI - for example get to loader prompt via = usb/cd boot and then get the same lsdev -v output. I would be interested = to see the sector size information and if the UEFI loader does also have = issues. If it does, I=E2=80=99d like to see the outputs from commands: zpool status zpool import thanks, toomas From owner-freebsd-stable@freebsd.org Mon Oct 22 10:58:24 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1367FF3F6A for ; Mon, 22 Oct 2018 10:58:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-21.consmr.mail.gq1.yahoo.com (sonic312-21.consmr.mail.gq1.yahoo.com [98.137.69.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 23B5473F87 for ; Mon, 22 Oct 2018 10:58:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: jmsiP_MVM1n8vGRln0v_NdtwvOGOFRVfqOjq_tK7FuCCkJE8xVpxRr0wZ1Xg81o QiAnwNQAvT7oBTqXdlPZ8gdOf0rAVJcTaEq7tAUj6n.h40F9UH0yZpc7E11zjw9fLdpbVI2IsJz9 UXMzIpNmMUyKFBU67JwmsidRgwS1h_Ser_t9mO21fvKBqaBdU3Ky0bg3xqdjMXCAby5y.OA7.TrC JhYKbCqzNJnkls5ybdcGzsWxBHju1_V0p4VehYHdqhX9b9snK1QrgrQqB1NhW8lY5O61w.9FHFI2 S.1ncyuH4oJeUYO0vh8vr4YYL0LLGF65i9vromKAhSVZW76aDyunkJuoitMiDlnpobUj9UNX0tqM .ftbqYXg4YFKwLwW4xtkIWoQZd7.IAFB1YSyHrqkZbRJokad_dqqVCeN.uESG0e0ZPVymFH7XKaU MY2DcMa7F.8ZJxvQOAb3XZQYsVZUOS9m49ZA5b9VmLS2kQ7DPSAtD6e3H9rd.AfjZZsRl.SJTCuE 4OMOELm.LNw2n2J5bmre8ejN.QW.fJuiXwlq5IYfgaAUzw71i7VQoodjAOxADjh3zZcCZ4reXC3o W_G51zQh5LlDUWRSxdwgNjFOMnUWrXdI9bYdqzUnEJeuX.yTH8rqfh67LycEhhwrnDgsMF3D2fjK WiwDnfzs.Pd.gNFmtGzFjNBAAGKsgXgZWwu4MNMfnYgmMtTrXmq5K.dtTCv_m_HDa1Yd8naQrmpA 8PUIqligyJXitB9THNSNJyE_Lhw02LeVUcEruOBho_S8MhRdYK7lprQ4W.9Ze2PBJqxYPK_yaeGF DIPWcEEFp0Ege.6KrcyD.JOXA5yW9ias.JjGlfsLYGQJ4b1mLpOWi2YF2fgMjwPNEZjzs55fjpaK 2DkwL0J5iJ6VH4i.7FEF.mPNxemspRX0EsVPNqIwSM4y25MwTT65WrPsFIGXA0mlip1jW683kzXT hjKKF7OKIvkOfm1JAbE9iARdflPgecVCf3H1GU9gXCB6BBOcl9Kq_TFtFu9lmO.FvOhza7hGuHwh XEKKuR3cXZC8CeU.Xv6TLcXlIi61VDYTM4xUp2eNkfWYj61yPpyI4iVxFkId9it4_rxrnhd0N.zg - Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 22 Oct 2018 10:58:17 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp421.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID bd82cf856c822e6019f6f9fc4922c776; Mon, 22 Oct 2018 10:58:12 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated From: Mark Millard In-Reply-To: <3CA4C94F-A062-44FE-B507-948A6F88C83D@me.com> Date: Mon, 22 Oct 2018 03:58:12 -0700 Cc: Konstantin Belousov , FreeBSD Current , FreeBSD-STABLE Mailing List , Warner Losh Content-Transfer-Encoding: quoted-printable Message-Id: <085BCA2B-4451-406C-9CEE-57D8B8008201@yahoo.com> References: <79973E2B-F5C4-4E7C-B92B-1C8D4441C7D1@yahoo.com> <3CA4C94F-A062-44FE-B507-948A6F88C83D@me.com> To: Toomas Soome X-Mailer: Apple Mail (2.3445.9.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: Mon, 22 Oct 2018 10:58:24 -0000 On 2018-Oct-22, at 2:27 AM, Toomas Soome wrote: >=20 >> On 22 Oct 2018, at 06:30, Warner Losh wrote: >>=20 >> On Sun, Oct 21, 2018 at 9:28 PM Warner Losh wrote: >>=20 >>>=20 >>>=20 >>> On Sun, Oct 21, 2018 at 8:57 PM Mark Millard via freebsd-stable < >>> freebsd-stable@freebsd.org> wrote: >>>=20 >>>> [I built based on WITHOUT_ZFS=3D for other reasons. But, >>>> after installing the build, Hyper-V based boots are >>>> working.] >>>>=20 >>>> On 2018-Oct-20, at 2:09 AM, Mark Millard = wrote: >>>>=20 >>>>> On 2018-Oct-20, at 1:39 AM, Mark Millard = wrote: >>>>>=20 >>>>>> I attempted to jump from head -r334014 to -r339076 >>>>>> on a threadripper 1950X board and the boot fails. >>>>>> This is both native booting and under Hyper-V, >>>>>> same machine and root file system in both cases. >>>>>=20 >>>>> I did my investigation under Hyper-V after seeing >>>>> a boot failure native. >>>>>=20 >>>>> Looks like the native failure is even earlier, >>>>> before db> is even possible, possibly during >>>>> early loader activity. >>>>>=20 >>>>> So this report is really for running under >>>>> Hyper-V: -r338804 boots and -r338810 does >>>>> not. By contrast -r334804 does not boot native. >>>>> (But I've little information for that context.) >>>>>=20 >>>>> Sorry for the confusion. I rushed the report >>>>> in hopes of getting to sleep. It was not to be. >>>>>=20 >>>>>> It fails just after the FreeBSD/SMP lines, >>>>>> reporting "kernel trap 9 with interrupts disabled". >>>>>>=20 >>>>>> It fails in pmap_force_invaldiate_cache_range at >>>>>> a clflusl (%rax) instruction that produces a >>>>>> "Fatal trap 9: general protection fault while >>>>>> in kernel mode". cpudid=3D0 apic id=3D 00 >>>>>>=20 >>>>>> I used kernel.txz files from: >>>>>>=20 >>>>>> https://artifact.ci.freebsd.org/snapshot/head/r*/amd64/amd64/ >>>>>>=20 >>>>>> to narrow the range of kernel builds for working -> failing >>>>>> and got: >>>>>>=20 >>>>>> -r338804 boots fine >>>>>> (no amd64 kernel builds between to try) >>>>>> -r338810+ fails (any that I tried, anyway) >>>>>>=20 >>>>>> In that range is -r338807 : >>>>>>=20 >>>>>> QUOTE >>>>>> Author: kib >>>>>> Date: Wed Sep 19 19:35:02 2018 >>>>>> New Revision: 338807 >>>>>> URL: >>>>>> https://svnweb.freebsd.org/changeset/base/338807 >>>>>>=20 >>>>>>=20 >>>>>> Log: >>>>>> Convert x86 cache invalidation functions to ifuncs. >>>>>>=20 >>>>>> This simplifies the runtime logic and reduces the number of >>>>>> runtime-constant branches. >>>>>>=20 >>>>>> Reviewed by: alc, markj >>>>>> Sponsored by: The FreeBSD Foundation >>>>>> Approved by: re (gjb) >>>>>> Differential revision: >>>>>> https://reviews.freebsd.org/D16736 >>>>>>=20 >>>>>> Modified: >>>>>> head/sys/amd64/amd64/pmap.c >>>>>> head/sys/amd64/include/pmap.h >>>>>> head/sys/dev/drm2/drm_os_freebsd.c >>>>>> head/sys/dev/drm2/i915/intel_ringbuffer.c >>>>>> head/sys/i386/i386/pmap.c >>>>>> head/sys/i386/i386/vm_machdep.c >>>>>> head/sys/i386/include/pmap.h >>>>>> head/sys/x86/iommu/intel_utils.c >>>>>> END QUOTE >>>>>>=20 >>>>>> There do seem to be changes associated with >>>>>> clflush(...) use. Looking at: >>>>>>=20 >>>>>>=20 >>>> = https://svnweb.freebsd.org/base/head/sys/amd64/amd64/pmap.c?annotate=3D339= 432 >>>>>>=20 >>>>>> it appears that pmap_force_invalidate_cache_range has not >>>>>> changed since -r338807. >>>>>>=20 >>>>>> It seems that -r338806 and -r3388810 would be unlikely >>>>>> contributors. >>>>>=20 >>>>=20 >>>> I went after my native-boot loader problem first because I >>>> could switch kernels via the loader for booting FreeBSD under >>>> Hyper-V. Switching loaders is more of a problem. >>>>=20 >>>> In order to avoid the loader-time crash I switched to building >>>> installing based on WITHOUT_ZFS=3D . I've had no active use of >>>> ZFS in years. (The old official-build loaders that worked were >>>> non-ZFS ones.) >>>>=20 >>>> This took care of the native-boot loader-crash --and, to my >>>> surprise, also the Hyper-V-boot kernel-time crash. >>>>=20 >>>> My private builds now boot the 1950X in both contexts just >>>> fine. >>>>=20 >>>> During my early investigation I did pick up specific changes >>>> from after -r339076 that seemed to be tied to Ryzen and such. >>>> (They made no difference to the boot problems at the time >>>> but I saw no reason to remove them.) >>>>=20 >>>> # uname -apKU >>>> FreeBSD FBSDFSSD 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #5 = r339076:339432M: Sun >>>> Oct 21 16:44:25 PDT 2018 = markmi@FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/G= ENERIC-NODBG >>>> amd64 amd64 1200084 1200084 >>>=20 >>>=20 >> (stupid gmail) >>=20 >> The phrase "no active use" bothers me. What does that mean? Are there = any >> ZFS pools or any disks that any whiff of ZFSish thing on it at all? >> Clearly, there's something in the zfs boot loader that's freaking out = by >> something on your system, but absent that information I can't help = you. >>=20 >=20 > It would help to get output from loader lsdev -v command. That turned out to be very interesting: The non-ZFS loader crashes during the listing, during disk8, which shows a x0 instead of a x512. Hand transcribed from pictures: OK lsdev -v disk devices disk0: BIOS drive C (937703088 x 512): disk0p1: FreeBSD boot 512K disk0p2: FreeBSD UFS 356G disk0p3: FreeBSD swap 15G disp0p4: FreeBSD swap 76G disk1: BIOS drive D (16514064 x 512): disk1s1: Linux 2048KB disk1s2: Unknown 952GB disk2: BIOS drive E (16514064 x 512): disk2p1: Unknown 128MB disk3: BIOS drive F (16514064 x 512): disk3p1: Unknown 128MB disk4: BIOS drive G (16434495 x 512): disk2p1: Unknown 128MB disk4p2: DOS/Windwos 1716GB disk5: BIOS drive H (16434495 x 512): disk5p1: FreeBSD boot 512K disk5p2: FreeBSD UFS 176G disk5p3: FreeBSD swap 193G disp5p4: FreeBSD swap 15G disk6: BIOS drive I (16434495 x 512): disk6p1: Unknown 499MB disk6p2: EFI 99MB disk6p3: Unknown 16MB disp6p4: DOS/Windows 886G dis7: BIOS drive H (16434495 x 512): disk7p1: FreeBSD boot 512K disk7p2: FreeBSD UFS 953G disk8: BIOS drive K (262144 x 0): int=3D00000000 err=3D00000000 efl=3D00010246 eip=3D000286bd eax=3D00000000 ebx=3D72b50430 ecx=3D00000000 edx=3D00000000 esi=3D00000000 edi=3D00092080 ebp=3D00091eec esp=3D00091ea8 cs=3D002b ds=3D0033 es=3D0033 fs=3D0033 gs=3D0033 ss=3D0033 cs:eip=3Df7 f1 89 c1 85 d2 0f 85-d8 01 00 00 6a 05 58 85 f6 0f 88 75 01 00 00 89-cb c1 fb 1f 89 ca 03 55 ss:esp=3D09 00 00 00 00 00 00 00-0a 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00-78 1f 09 00 33 45 04 00 BTX halted I expect that "disk8" is what gpart show -p from a native boot showed as: =3D> 1 60062499 da1 MBR (29G) 1 31 - free - (16K) 32 60062468 da1s1 fat32lba (29G) (That gpart show -p output is in another of the list messages.) > Also if you could test boot loader with UEFI - for example get to = loader prompt via usb/cd boot and then get the same lsdev -v output. Still true given the above crash? Or, going the other way, should "drive8" be left as it is in order to be sure to do this test with the drive present? If I do this test later, it will take a bit to get media to do it with. (It is about 4AM in the morning and I've yet to get to sleep.) Note: I've never tried a UEFI based boot of FreeBSD on this machine (but the Windows 10 Pro x64 is EFI based). The only FreeBSD context using a EFI partition to boot that I have used is on an arm aarch64 Cortex-A57 system. > I would be interested to see the sector size information and if the = UEFI loader does also have issues. Understood. > If it does, I=E2=80=99d like to see the outputs from commands: > zpool status > zpool import Independent of the UEFI test . . . I do have a -r331924 head version on another one of the devices and can native-boot that. It still has its ZFS software (but a default loader without ZFS). Trying from that context, hand transcribed: # zpool status ZFS filesystem version: 5 ZFS storage pool version: features support (5000) no pools available # zpool import # [That was based on the old (default) loader being a non-ZFS one.] =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-stable@freebsd.org Mon Oct 22 11:07:43 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5EC68FF56DF; Mon, 22 Oct 2018 11:07:42 +0000 (UTC) (envelope-from tsoome@me.com) Received: from pv33p00im-asmtp003.me.com (pv33p00im-asmtp003.me.com [17.142.194.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC715745F1; Mon, 22 Oct 2018 11:07:41 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.pv33p00im-asmtp003.me.com by pv33p00im-asmtp003.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) id <0PGZ00M00YLYQV00@pv33p00im-asmtp003.me.com>; Mon, 22 Oct 2018 11:07:40 +0000 (GMT) Received: from icloud.com ([127.0.0.1]) by pv33p00im-asmtp003.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) with ESMTPSA id <0PGZ00JOQYWKOS00@pv33p00im-asmtp003.me.com>; Mon, 22 Oct 2018 11:07:38 +0000 (GMT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810220099 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-21_14:,, signatures=0 From: Toomas Soome Message-id: <9AEF5EB3-C393-44D1-9BD4-D0E59FE97CCE@me.com> MIME-version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Subject: Re: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated Date: Mon, 22 Oct 2018 14:07:31 +0300 In-reply-to: <085BCA2B-4451-406C-9CEE-57D8B8008201@yahoo.com> Cc: Konstantin Belousov , FreeBSD Current , FreeBSD-STABLE Mailing List , Warner Losh To: Mark Millard References: <79973E2B-F5C4-4E7C-B92B-1C8D4441C7D1@yahoo.com> <3CA4C94F-A062-44FE-B507-948A6F88C83D@me.com> <085BCA2B-4451-406C-9CEE-57D8B8008201@yahoo.com> X-Mailer: Apple Mail (2.3445.100.39) 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: Mon, 22 Oct 2018 11:07:43 -0000 > On 22 Oct 2018, at 13:58, Mark Millard wrote: >=20 > On 2018-Oct-22, at 2:27 AM, Toomas Soome > wrote: >>=20 >>> On 22 Oct 2018, at 06:30, Warner Losh wrote: >>>=20 >>> On Sun, Oct 21, 2018 at 9:28 PM Warner Losh wrote: >>>=20 >>>>=20 >>>>=20 >>>> On Sun, Oct 21, 2018 at 8:57 PM Mark Millard via freebsd-stable < >>>> freebsd-stable@freebsd.org> wrote: >>>>=20 >>>>> [I built based on WITHOUT_ZFS=3D for other reasons. But, >>>>> after installing the build, Hyper-V based boots are >>>>> working.] >>>>>=20 >>>>> On 2018-Oct-20, at 2:09 AM, Mark Millard = wrote: >>>>>=20 >>>>>> On 2018-Oct-20, at 1:39 AM, Mark Millard = wrote: >>>>>>=20 >>>>>>> I attempted to jump from head -r334014 to -r339076 >>>>>>> on a threadripper 1950X board and the boot fails. >>>>>>> This is both native booting and under Hyper-V, >>>>>>> same machine and root file system in both cases. >>>>>>=20 >>>>>> I did my investigation under Hyper-V after seeing >>>>>> a boot failure native. >>>>>>=20 >>>>>> Looks like the native failure is even earlier, >>>>>> before db> is even possible, possibly during >>>>>> early loader activity. >>>>>>=20 >>>>>> So this report is really for running under >>>>>> Hyper-V: -r338804 boots and -r338810 does >>>>>> not. By contrast -r334804 does not boot native. >>>>>> (But I've little information for that context.) >>>>>>=20 >>>>>> Sorry for the confusion. I rushed the report >>>>>> in hopes of getting to sleep. It was not to be. >>>>>>=20 >>>>>>> It fails just after the FreeBSD/SMP lines, >>>>>>> reporting "kernel trap 9 with interrupts disabled". >>>>>>>=20 >>>>>>> It fails in pmap_force_invaldiate_cache_range at >>>>>>> a clflusl (%rax) instruction that produces a >>>>>>> "Fatal trap 9: general protection fault while >>>>>>> in kernel mode". cpudid=3D0 apic id=3D 00 >>>>>>>=20 >>>>>>> I used kernel.txz files from: >>>>>>>=20 >>>>>>> https://artifact.ci.freebsd.org/snapshot/head/r*/amd64/amd64/ >>>>>>>=20 >>>>>>> to narrow the range of kernel builds for working -> failing >>>>>>> and got: >>>>>>>=20 >>>>>>> -r338804 boots fine >>>>>>> (no amd64 kernel builds between to try) >>>>>>> -r338810+ fails (any that I tried, anyway) >>>>>>>=20 >>>>>>> In that range is -r338807 : >>>>>>>=20 >>>>>>> QUOTE >>>>>>> Author: kib >>>>>>> Date: Wed Sep 19 19:35:02 2018 >>>>>>> New Revision: 338807 >>>>>>> URL: >>>>>>> https://svnweb.freebsd.org/changeset/base/338807 >>>>>>>=20 >>>>>>>=20 >>>>>>> Log: >>>>>>> Convert x86 cache invalidation functions to ifuncs. >>>>>>>=20 >>>>>>> This simplifies the runtime logic and reduces the number of >>>>>>> runtime-constant branches. >>>>>>>=20 >>>>>>> Reviewed by: alc, markj >>>>>>> Sponsored by: The FreeBSD Foundation >>>>>>> Approved by: re (gjb) >>>>>>> Differential revision: >>>>>>> https://reviews.freebsd.org/D16736 >>>>>>>=20 >>>>>>> Modified: >>>>>>> head/sys/amd64/amd64/pmap.c >>>>>>> head/sys/amd64/include/pmap.h >>>>>>> head/sys/dev/drm2/drm_os_freebsd.c >>>>>>> head/sys/dev/drm2/i915/intel_ringbuffer.c >>>>>>> head/sys/i386/i386/pmap.c >>>>>>> head/sys/i386/i386/vm_machdep.c >>>>>>> head/sys/i386/include/pmap.h >>>>>>> head/sys/x86/iommu/intel_utils.c >>>>>>> END QUOTE >>>>>>>=20 >>>>>>> There do seem to be changes associated with >>>>>>> clflush(...) use. Looking at: >>>>>>>=20 >>>>>>>=20 >>>>> = https://svnweb.freebsd.org/base/head/sys/amd64/amd64/pmap.c?annotate=3D339= 432 >>>>>>>=20 >>>>>>> it appears that pmap_force_invalidate_cache_range has not >>>>>>> changed since -r338807. >>>>>>>=20 >>>>>>> It seems that -r338806 and -r3388810 would be unlikely >>>>>>> contributors. >>>>>>=20 >>>>>=20 >>>>> I went after my native-boot loader problem first because I >>>>> could switch kernels via the loader for booting FreeBSD under >>>>> Hyper-V. Switching loaders is more of a problem. >>>>>=20 >>>>> In order to avoid the loader-time crash I switched to building >>>>> installing based on WITHOUT_ZFS=3D . I've had no active use of >>>>> ZFS in years. (The old official-build loaders that worked were >>>>> non-ZFS ones.) >>>>>=20 >>>>> This took care of the native-boot loader-crash --and, to my >>>>> surprise, also the Hyper-V-boot kernel-time crash. >>>>>=20 >>>>> My private builds now boot the 1950X in both contexts just >>>>> fine. >>>>>=20 >>>>> During my early investigation I did pick up specific changes >>>>> from after -r339076 that seemed to be tied to Ryzen and such. >>>>> (They made no difference to the boot problems at the time >>>>> but I saw no reason to remove them.) >>>>>=20 >>>>> # uname -apKU >>>>> FreeBSD FBSDFSSD 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #5 = r339076:339432M: Sun >>>>> Oct 21 16:44:25 PDT 2018 = markmi@FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/G= ENERIC-NODBG >>>>> amd64 amd64 1200084 1200084 >>>>=20 >>>>=20 >>> (stupid gmail) >>>=20 >>> The phrase "no active use" bothers me. What does that mean? Are = there any >>> ZFS pools or any disks that any whiff of ZFSish thing on it at all? >>> Clearly, there's something in the zfs boot loader that's freaking = out by >>> something on your system, but absent that information I can't help = you. >>>=20 >>=20 >> It would help to get output from loader lsdev -v command. >=20 > That turned out to be very interesting: The non-ZFS loader > crashes during the listing, during disk8, which shows a > x0 instead of a x512. >=20 Yes, thats the root cause there. The non-zfs loader does only *read* the = boot disk, thats why the issue was not revealed there.=20 It would help to identify the sector size for that disk, at least from = OS, so we can compare with what we can get from INT13. I have pretty good idea what to look there, but I am afraid we need to = run few tests with you to understand why that disk is reporting sector = size 0 there. rgds, toomas > Hand transcribed from pictures: >=20 > OK lsdev -v > disk devices > disk0: BIOS drive C (937703088 x 512): > disk0p1: FreeBSD boot 512K > disk0p2: FreeBSD UFS 356G > disk0p3: FreeBSD swap 15G > disp0p4: FreeBSD swap 76G > disk1: BIOS drive D (16514064 x 512): > disk1s1: Linux 2048KB > disk1s2: Unknown 952GB > disk2: BIOS drive E (16514064 x 512): > disk2p1: Unknown 128MB > disk3: BIOS drive F (16514064 x 512): > disk3p1: Unknown 128MB > disk4: BIOS drive G (16434495 x 512): > disk2p1: Unknown 128MB > disk4p2: DOS/Windwos 1716GB > disk5: BIOS drive H (16434495 x 512): > disk5p1: FreeBSD boot 512K > disk5p2: FreeBSD UFS 176G > disk5p3: FreeBSD swap 193G > disp5p4: FreeBSD swap 15G > disk6: BIOS drive I (16434495 x 512): > disk6p1: Unknown 499MB > disk6p2: EFI 99MB > disk6p3: Unknown 16MB > disp6p4: DOS/Windows 886G > dis7: BIOS drive H (16434495 x 512): > disk7p1: FreeBSD boot 512K > disk7p2: FreeBSD UFS 953G > disk8: BIOS drive K (262144 x 0): >=20 > int=3D00000000 err=3D00000000 efl=3D00010246 eip=3D000286bd > eax=3D00000000 ebx=3D72b50430 ecx=3D00000000 edx=3D00000000 > esi=3D00000000 edi=3D00092080 ebp=3D00091eec esp=3D00091ea8 > cs=3D002b ds=3D0033 es=3D0033 fs=3D0033 gs=3D0033 ss=3D0033 > cs:eip=3Df7 f1 89 c1 85 d2 0f 85-d8 01 00 00 6a 05 58 85 > f6 0f 88 75 01 00 00 89-cb c1 fb 1f = 89 ca 03 55 > ss:esp=3D09 00 00 00 00 00 00 = 00-0a 00 00 00 02 00 00 00 > 00 00 00 00 00 00 00 = 00-78 1f 09 00 33 45 04 00 > BTX halted >=20 > I expect that "disk8" is what gpart show -p > from a native boot showed as: >=20 > =3D> 1 60062499 da1 MBR (29G) > 1 31 - free - (16K) > 32 =C2=A060062468 da1s1 fat32lba = (29G) >=20 > (That gpart show -p output is in another of the > list messages.) >=20 >> Also if you could test boot loader with UEFI - for example get to = loader prompt via usb/cd boot and then get the same lsdev -v output. >=20 > Still true given the above crash? Or, going the > other way, should "drive8" be left as it is in > order to be sure to do this test with the drive > present? >=20 > If I do this test later, it will take a bit to > get media to do it with. (It is about 4AM in the > morning and I've yet to get to sleep.) >=20 > Note: I've never tried a UEFI based boot of FreeBSD > on this machine (but the Windows 10 Pro x64 is EFI > based). The only FreeBSD context using a EFI partition > to boot that I have used is on an arm aarch64 > Cortex-A57 system. >=20 >> I would be interested to see the sector size information and if the = UEFI loader does also have issues. >=20 > Understood. >=20 >> If it does, I=E2=80=99d like to see the outputs from commands: >=20 >> zpool status >> zpool import >=20 > Independent of the UEFI test . . . >=20 > I do have a -r331924 head version on another one > of the devices and can native-boot that. It still > has its ZFS software (but a default loader without > ZFS). >=20 > Trying from that context, hand transcribed: >=20 > # zpool status > ZFS filesystem version: 5 > ZFS storage pool version: features support (5000) > no pools available > # zpool import > # >=20 > [That was based on the old (default) loader being > a non-ZFS one.] >=20 >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) From owner-freebsd-stable@freebsd.org Mon Oct 22 12:39:42 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D12C5FFAAE0 for ; Mon, 22 Oct 2018 12:39:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-36.consmr.mail.ne1.yahoo.com (sonic317-36.consmr.mail.ne1.yahoo.com [66.163.184.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 689197814C for ; Mon, 22 Oct 2018 12:39:42 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: nlUpYekVM1k8LPpTgXb9Li5gPeIldEl8aqVIdYJXYqvkVWIBy7JB5VFeM88wIj8 VpDBN7di71903oVbJ41QQR11rKqeXQxO9g6QIcOGGFQAeNJtZZvB6m0Gqi6jcxhQkk8b_xHBNdrU vao7NXBhHHqO_scUV8dNQLswK.Sa53CM6EWNaM5d05Y0wc5aHv9_4CYRc8q_Qh8ektVElCfrdooZ 4nUr_WlwcmN8IeSKCHDnOTMjXpnWq4eI4h.8F7K5c45gUZ5sm9r1PWerKVDvWTjdrX1qGZsnnpT. _x1vcLs_7QkshHdbQDAB1ii9E5yZyac_mawffk2v3hUUam8pRCJuZO5Qkica8E72NtSYWFHJ4O0Z 5ycn8OPGS7dzHyi4OVuaYY_KD1SPRKWkCIb5UCtlpwQeHqWJE_zJc4sMPtI2UURFWNsP_OGg.kyp CjsBt2wNvhy4UHjPCMl444RZW7esGCh1Td96QVq0uoBEWP2Hqe5EavdU5FZ28WhnY8xmY72pU01t JtgubyA0AvSobhDrjaXLMYv3S.ufB1cEnshlVo67vSmgNwv6gwEGbr4rrDZFrfq4roK6PTsodIkt jPGlT_BFzQ.xW1Ir9mC_0b.aCufA0kE5wwVQlKoArpf.Ha5YRWyJh4906SpfNfkJUMky2MbYwHVo u9T.AQj1wRFvTmhjrun6RYPFlXIRklMAY8UKKkCwjOcg6dPLcTd61PQyufGy78aYfVU27RduSrWZ mYEBvqvh6saC5.0KL7GelR0bb2O5Q0rEAZ8fPdLZtnUSIAr.GnFxNfHq2Vm5sOYxBZXKs9AgBjPO gqJ2a8FPcny60zVKhhl4jQLWLT0HONnKRtkS1AUpQdfVbki2UtrHW.kFJx99ACud3aWmCGGcthyP vBSJFTiBvifp2J4nwxNoS61n8p0ca1rHmBm4njv9sviREY2IY5rLOnZDkF5nyuDKdRTctgD1gH8S J6uliQl4f6Hn0lrzwOQWYPKgi.daBchxP_Cwt0PQJbAzWtRUU9Kkoohvb0T8tmhDkmgyo9Naqqj7 HCUQuO7WjUVf5SG90MZf9o35Q65xgXITfaPFUdCdfJ.bsWxuChJUc.TfBVTZKLMa19vaO9lgHPyI uQeA- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.ne1.yahoo.com with HTTP; Mon, 22 Oct 2018 12:39:41 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp422.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a3206d9ee5ade17a4a95cd6b0065b2c0; Mon, 22 Oct 2018 12:39:37 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated From: Mark Millard In-Reply-To: <9AEF5EB3-C393-44D1-9BD4-D0E59FE97CCE@me.com> Date: Mon, 22 Oct 2018 05:39:36 -0700 Cc: Konstantin Belousov , FreeBSD Current , FreeBSD-STABLE Mailing List , Warner Losh Content-Transfer-Encoding: quoted-printable Message-Id: <08B26F92-F1F5-4F51-8DC4-EDDC6DD493B2@yahoo.com> References: <79973E2B-F5C4-4E7C-B92B-1C8D4441C7D1@yahoo.com> <3CA4C94F-A062-44FE-B507-948A6F88C83D@me.com> <085BCA2B-4451-406C-9CEE-57D8B8008201@yahoo.com> <9AEF5EB3-C393-44D1-9BD4-D0E59FE97CCE@me.com> To: Toomas Soome X-Mailer: Apple Mail (2.3445.9.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: Mon, 22 Oct 2018 12:39:43 -0000 On 2018-Oct-22, at 4:07 AM, Toomas Soome wrote: > On 22 Oct 2018, at 13:58, Mark Millard wrote: >>=20 >> On 2018-Oct-22, at 2:27 AM, Toomas Soome wrote: >>>=20 >>>> On 22 Oct 2018, at 06:30, Warner Losh wrote: >>>>=20 >>>> On Sun, Oct 21, 2018 at 9:28 PM Warner Losh wrote: >>>>=20 >>>>>=20 >>>>>=20 >>>>> On Sun, Oct 21, 2018 at 8:57 PM Mark Millard via freebsd-stable < >>>>> freebsd-stable@freebsd.org> wrote: >>>>>=20 >>>>>> [I built based on WITHOUT_ZFS=3D for other reasons. But, >>>>>> after installing the build, Hyper-V based boots are >>>>>> working.] >>>>>>=20 >>>>>> On 2018-Oct-20, at 2:09 AM, Mark Millard = wrote: >>>>>>=20 >>>>>>> On 2018-Oct-20, at 1:39 AM, Mark Millard = wrote: >>>>>>> . . . >>>>=20 >>>=20 >>> It would help to get output from loader lsdev -v command. >>=20 >> That turned out to be very interesting: The non-ZFS loader >> crashes during the listing, during disk8, which shows a >> x0 instead of a x512. >>=20 >=20 > Yes, thats the root cause there. The non-zfs loader does only *read* = the boot disk, thats why the issue was not revealed there.=20 >=20 > It would help to identify the sector size for that disk, at least from = OS, so we can compare with what we can get from INT13. >=20 > I have pretty good idea what to look there, but I am afraid we need to = run few tests with you to understand why that disk is reporting sector = size 0 there. >=20 >=20 Looks like I guessed wrong about the device for "drive8". So I unplugged the only other external storage device, so the original drives 0-13 become 0-11 overall. The machine has a multi-LUN media card reader with no cards plugged in. It is built-in rather than one that I plugged into a port. It has 4 LUN's. So 8+4=3D12 and drives 0-7 show up with media before it tries any of the 4 LUN's with no card in place. I conclude that "drive8" is an empty LUN in a media card reader. I conclude that there is no sector size available for any of the empty LUNs in the media reader. >=20 >=20 >> Hand transcribed from pictures: >>=20 >> OK lsdev -v >> disk devices >> disk0: BIOS drive C (937703088 x 512): >> disk0p1: FreeBSD boot 512K >> disk0p2: FreeBSD UFS 356G >> disk0p3: FreeBSD swap 15G >> disp0p4: FreeBSD swap 76G >> disk1: BIOS drive D (16514064 x 512): >> disk1s1: Linux 2048KB >> disk1s2: Unknown 952GB >> disk2: BIOS drive E (16514064 x 512): >> disk2p1: Unknown 128MB >> disk3: BIOS drive F (16514064 x 512): >> disk3p1: Unknown 128MB >> disk4: BIOS drive G (16434495 x 512): >> disk2p1: Unknown 128MB >> disk4p2: DOS/Windwos 1716GB >> disk5: BIOS drive H (16434495 x 512): >> disk5p1: FreeBSD boot 512K >> disk5p2: FreeBSD UFS 176G >> disk5p3: FreeBSD swap 193G >> disp5p4: FreeBSD swap 15G >> disk6: BIOS drive I (16434495 x 512): >> disk6p1: Unknown 499MB >> disk6p2: EFI 99MB >> disk6p3: Unknown 16MB >> disp6p4: DOS/Windows 886G >> dis7: BIOS drive H (16434495 x 512): >> disk7p1: FreeBSD boot 512K >> disk7p2: FreeBSD UFS 953G >> disk8: BIOS drive K (262144 x 0): >>=20 >> int=3D00000000 err=3D00000000 efl=3D00010246 eip=3D000286bd >> eax=3D00000000 ebx=3D72b50430 ecx=3D00000000 edx=3D00000000 >> esi=3D00000000 edi=3D00092080 ebp=3D00091eec esp=3D00091ea8 >> cs=3D002b ds=3D0033 es=3D0033 fs=3D0033 gs=3D0033 ss=3D0033 >> cs:eip=3Df7 f1 89 c1 85 d2 0f 85-d8 01 00 00 6a 05 58 85 >> f6 0f 88 75 01 00 00 89-cb c1 fb 1f 89 ca 03 55 >> ss:esp=3D09 00 00 00 00 00 00 00-0a 00 00 00 02 00 00 00 >> 00 00 00 00 00 00 00 00-78 1f 09 00 33 45 04 00 >> BTX halted >>=20 >> I expect that "disk8" is what gpart show -p >> from a native boot showed as: >>=20 >> =3D> 1 60062499 da1 MBR (29G) >> 1 31 - free - (16K) >> 32 60062468 da1s1 fat32lba (29G) >>=20 >> (That gpart show -p output is in another of the >> list messages.) >>=20 >>> Also if you could test boot loader with UEFI - for example get to = loader prompt via usb/cd boot and then get the same lsdev -v output. >>=20 >> Still true given the above crash? Or, going the >> other way, should "drive8" be left as it is in >> order to be sure to do this test with the drive >> present? >>=20 >> If I do this test later, it will take a bit to >> get media to do it with. (It is about 4AM in the >> morning and I've yet to get to sleep.) >>=20 >> Note: I've never tried a UEFI based boot of FreeBSD >> on this machine (but the Windows 10 Pro x64 is EFI >> based). The only FreeBSD context using a EFI partition >> to boot that I have used is on an arm aarch64 >> Cortex-A57 system. >>=20 >>> I would be interested to see the sector size information and if the = UEFI loader does also have issues. >>=20 >> Understood. >>=20 >>> If it does, I=E2=80=99d like to see the outputs from commands: >>=20 >>> zpool status >>> zpool import >>=20 >> Independent of the UEFI test . . . >>=20 >> I do have a -r331924 head version on another one >> of the devices and can native-boot that. It still >> has its ZFS software (but a default loader without >> ZFS). >>=20 >> Trying from that context, hand transcribed: >>=20 >> # zpool status >> ZFS filesystem version: 5 >> ZFS storage pool version: features support (5000) >> no pools available >> # zpool import >> # >>=20 >> [That was based on the old (default) loader being >> a non-ZFS one.] >=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-stable@freebsd.org Mon Oct 22 13:59:18 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C82DFFCE0A for ; Mon, 22 Oct 2018 13:59:18 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:d12:604::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 10C697AFE4; Mon, 22 Oct 2018 13:59:17 +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 w9MDxAMt009594 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Oct 2018 15:59:11 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: avg@FreeBSD.org Received: from [10.58.0.4] (dadv@[10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w9MDxA0u074410 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 22 Oct 2018 20:59:10 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: krpc: unbootable ZFS-on-root after major upgrade to 11.2 To: Andriy Gapon , FreeBSD stable , Glen Barber References: <8517429b-9e3b-2ea3-80a6-12fc92106252@grosbein.net> <6627d159-fd52-2d10-2d45-97fd02725adc@FreeBSD.org> <5BC9A2E4.9010306@grosbein.net> <6c2f8adb-c0e7-550b-8595-e7a4768d5157@FreeBSD.org> From: Eugene Grosbein Message-ID: Date: Mon, 22 Oct 2018 20:59:10 +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: <6c2f8adb-c0e7-550b-8595-e7a4768d5157@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00, LOCAL_FROM, SPF_PASS, T_DATE_IN_FUTURE_96_Q autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 T_DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: * date * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net 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: Mon, 22 Oct 2018 13:59:18 -0000 19.10.2018 21:34, Andriy Gapon wrote: > It's strange that this is a 10.x vs 11.x issue. > I see that zfs has the krpc dependency since r193128. > And the call to xdrmem_create is there since r168404. You are right. I was mis-informed and have not verified enough a report from local user. Glen, maybe that errata record should be deleted. The problem is real but it is long-standing and present in 10.x too. From owner-freebsd-stable@freebsd.org Mon Oct 22 14:03:07 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39732FFD13D for ; Mon, 22 Oct 2018 14:03:07 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E411B7B55B; Mon, 22 Oct 2018 14:03:06 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id A6B89ED29; Mon, 22 Oct 2018 14:03:06 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Mon, 22 Oct 2018 14:03:04 +0000 From: Glen Barber To: Eugene Grosbein Cc: Andriy Gapon , FreeBSD stable Subject: Re: krpc: unbootable ZFS-on-root after major upgrade to 11.2 Message-ID: <20181022140304.GE13668@FreeBSD.org> References: <8517429b-9e3b-2ea3-80a6-12fc92106252@grosbein.net> <6627d159-fd52-2d10-2d45-97fd02725adc@FreeBSD.org> <5BC9A2E4.9010306@grosbein.net> <6c2f8adb-c0e7-550b-8595-e7a4768d5157@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SnV5plBeK2Ge1I9g" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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: Mon, 22 Oct 2018 14:03:07 -0000 --SnV5plBeK2Ge1I9g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 22, 2018 at 08:59:10PM +0700, Eugene Grosbein wrote: > 19.10.2018 21:34, Andriy Gapon wrote: >=20 > > It's strange that this is a 10.x vs 11.x issue. > > I see that zfs has the krpc dependency since r193128. > > And the call to xdrmem_create is there since r168404. >=20 > You are right. I was mis-informed and have not verified enough a report f= rom local user. >=20 > Glen, maybe that errata record should be deleted. The problem is real but= it is long-standing > and present in 10.x too. >=20 Could you elaborate more on the failure case you originally reported first? If the problem is real, my feeling is that the errata entry should stay, just worded differently to reflect the failure case here. Glen --SnV5plBeK2Ge1I9g Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAlvN2JgACgkQAxRYpUeP 4pPFqw//SuLbTZsV91dpsdNXJGyXB9ZD267ttfQTbfQNeZGfBvtYUewb+lQaUzok 96rOT6JRFfn7mn7UoG5gXvYjN7+1VOYqS01O/GWtV6f04oLrMOaIQSPLAdWFR/vk zciN4kszjEYU1ecvFZY6tChhQRK6n6WmLfdkr7DIW89LIHT9+3gN8r9OUsWtk3Wk vPKPJ+Zr7aeuAzLwAhsj7cfO4rfk50aqQxxDj+XM+Az/zaO5Q0CaNiYPJc7C3GCG zCoEXSYl270nyDGTJnEsVaUre3TpxDGpab2kHVj67NQRKW5a7VgbzoxxEz+HaEKe qHWFGZgulohYj1hVrD13ea91WLGIaBfLo9kd8EvjA7dbGwYm5qFY2B4xl4M9ftrK jVleAliXCRD3vutt7xUgjTstupY4/U8qRjjJ7t4xLdKMln30NjMFFHEdTdME+JW6 2RpWCo0MFpQcTKrnEwY/yKVCRcwbEOpH8VYqL3+31bw/cN90+hVrCVUpRcyhvklP +cOFnV2edZTcZrYqH8vBvd0R+S1cN5SeoSQyjWRnuT1g25Wow2UeUT+BSrLTQprb mHpUOwImc4VT7NSA3ZIBn2U771LFefCNV0XpWo3JQz+qXuoued5QNKMo5OCU7j39 ZP96xUuHQh6y3SvgWKuJFK7QgRBx6rSuIFUIMPysjFzOYE8/ta8= =otQo -----END PGP SIGNATURE----- --SnV5plBeK2Ge1I9g-- From owner-freebsd-stable@freebsd.org Mon Oct 22 14:09:27 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0B52FFD5E9 for ; Mon, 22 Oct 2018 14:09:27 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:d12:604::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 272507BACA; Mon, 22 Oct 2018 14:09:27 +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 w9ME9Jv4009698 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Oct 2018 16:09:20 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: gjb@freebsd.org Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w9ME9Jwi074588 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 22 Oct 2018 21:09:19 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: krpc: unbootable ZFS-on-root after major upgrade to 11.2 To: Glen Barber References: <8517429b-9e3b-2ea3-80a6-12fc92106252@grosbein.net> <6627d159-fd52-2d10-2d45-97fd02725adc@FreeBSD.org> <5BC9A2E4.9010306@grosbein.net> <6c2f8adb-c0e7-550b-8595-e7a4768d5157@FreeBSD.org> <20181022140304.GE13668@FreeBSD.org> Cc: Andriy Gapon , FreeBSD stable From: Eugene Grosbein Message-ID: <1d5236b8-0269-5dce-3f2e-e7b1910836c6@grosbein.net> Date: Mon, 22 Oct 2018 21:09:14 +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: <20181022140304.GE13668@FreeBSD.org> 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_PASS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net 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: Mon, 22 Oct 2018 14:09:27 -0000 22.10.2018 21:03, Glen Barber wrote: t's strange that this is a 10.x vs 11.x issue. >>> I see that zfs has the krpc dependency since r193128. >>> And the call to xdrmem_create is there since r168404. >> >> You are right. I was mis-informed and have not verified enough a report from local user. >> >> Glen, maybe that errata record should be deleted. The problem is real but it is long-standing >> and present in 10.x too. >> > > Could you elaborate more on the failure case you originally reported > first? If the problem is real, my feeling is that the errata entry > should stay, just worded differently to reflect the failure case here. zfs.ko depends on krpc.ko. The KRPC code in compiled in GENERIC kernel as dependency of NFS client/server code. The problem arises if all of these are true: 1) a system uses custom kernel with NFS options removed; 2) there is no krpc.ko available due to MODULES_OVERRIDE excluding it; 3) the system boots off ZFS pool. In such case, loader cannot resolve dependency and fails to load zfs.ko and kernel fails to mount root breaking boot sequence. From owner-freebsd-stable@freebsd.org Mon Oct 22 14:15:30 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2CC36FFD99F for ; Mon, 22 Oct 2018 14:15:30 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D67F87BF76; Mon, 22 Oct 2018 14:15:29 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 974F6F0FB; Mon, 22 Oct 2018 14:15:29 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Mon, 22 Oct 2018 14:15:27 +0000 From: Glen Barber To: Eugene Grosbein Cc: Andriy Gapon , FreeBSD stable Subject: Re: krpc: unbootable ZFS-on-root after major upgrade to 11.2 Message-ID: <20181022141527.GF13668@FreeBSD.org> References: <8517429b-9e3b-2ea3-80a6-12fc92106252@grosbein.net> <6627d159-fd52-2d10-2d45-97fd02725adc@FreeBSD.org> <5BC9A2E4.9010306@grosbein.net> <6c2f8adb-c0e7-550b-8595-e7a4768d5157@FreeBSD.org> <20181022140304.GE13668@FreeBSD.org> <1d5236b8-0269-5dce-3f2e-e7b1910836c6@grosbein.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Sw7tCqrGA+HQ0/zt" Content-Disposition: inline In-Reply-To: <1d5236b8-0269-5dce-3f2e-e7b1910836c6@grosbein.net> User-Agent: Mutt/1.10.1 (2018-07-13) 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: Mon, 22 Oct 2018 14:15:30 -0000 --Sw7tCqrGA+HQ0/zt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 22, 2018 at 09:09:14PM +0700, Eugene Grosbein wrote: > 22.10.2018 21:03, Glen Barber wrote: >=20 > t's strange that this is a 10.x vs 11.x issue. > >>> I see that zfs has the krpc dependency since r193128. > >>> And the call to xdrmem_create is there since r168404. > >> > >> You are right. I was mis-informed and have not verified enough a repor= t from local user. > >> > >> Glen, maybe that errata record should be deleted. The problem is real = but it is long-standing > >> and present in 10.x too. > >> > >=20 > > Could you elaborate more on the failure case you originally reported > > first? If the problem is real, my feeling is that the errata entry > > should stay, just worded differently to reflect the failure case here. >=20 > zfs.ko depends on krpc.ko. The KRPC code in compiled in GENERIC kernel as= dependency > of NFS client/server code. The problem arises if all of these are true: >=20 > 1) a system uses custom kernel with NFS options removed; > 2) there is no krpc.ko available due to MODULES_OVERRIDE excluding it; > 3) the system boots off ZFS pool. >=20 > In such case, loader cannot resolve dependency and fails to load zfs.ko > and kernel fails to mount root breaking boot sequence. >=20 >=20 So, if I understand correctly (and please correct me if I am wrong), the majority of the text in the errata note is correct, however needs to be tweaked to remove "upgrading from 10.x...". Is this generally correct? Glen --Sw7tCqrGA+HQ0/zt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAlvN238ACgkQAxRYpUeP 4pMl5g/9FJ15APPdi/UMSY9eZ+GOO4KHyGcZS9KlTwRAhTX//i8Ec702PgaApqGH 4VhX4yIocrXOfEWRoSGsEQaUNlRPyxZo49vu19ujC6o9pBWLZpfYogvKnfXsHAsy GtYEInpR7uWCCATnAbPxYviYkKmcMKXOu4CMRbbfNe+RNRjW2pCpk9YrQva1vGrI cBy2SJ6L1LyQPvhj86Kj+XE+6XVIuOoDTygk5sCDPnIed9TWh67yO8zHnqsb3Qxp GYJ9tcGbhdz6o8IjtlB1c4+dsKKW8ClzvaOTrXrlPJAkYCXxp8Dek6SLppFq15oo dfwHbvl4CynuGkHat6Rkwhmx/l3lBVP1dkNFLyPqlF8+L52MqYRjNoiX+377nq/K FvksnoalUkukhsdGQl3BurgXwG5Qaddc6P6kpwFpFNPA3GP2G0NWhAA4aXcRl5Dw YhSLKmgNx1QwZsDsOWosWTTVp2C/nOYj86EhkdqghVM8giyFpv3rEtYklkmZtHdO 6/VLYebOt0fPL6YwHMzP1nb/vvjukjYEtghIgmUs/BAKPT6SRDP+idYMtQaLeRcC 7a1VeoDOO90PQsrFGg1WU+sWjrh8jCPLcnJbOCL2Hk+jAVgqYOgGtFUcZ/xHRliZ 9cud9uX8zDMYUoDzLFxBScU1WcZg1LPwDkOmF2l2TKojApIMn1Y= =K8ne -----END PGP SIGNATURE----- --Sw7tCqrGA+HQ0/zt-- From owner-freebsd-stable@freebsd.org Mon Oct 22 14:29:46 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9041EFFDF1F for ; Mon, 22 Oct 2018 14:29:46 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com [209.85.167.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E8ED27C644; Mon, 22 Oct 2018 14:29:45 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf1-f66.google.com with SMTP id c24-v6so4085636lfi.12; Mon, 22 Oct 2018 07:29:45 -0700 (PDT) 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:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=C2/0kb/xlwDAT4Ifndnjm11+iHYTMsqi1iQHC51tcuY=; b=l7pLGXlPq7a8HArBABDcp6iJt8hYYzCRaU0DQJdwKIV1nT1UTGimoGcG31Ofw9IhLC HTtDho/TnvJE7plgfenPvCJtgI32q0Mbc0JM7a25SxGFGayKevKfT6TG7/sMEcHGaE2f cNNqqX8MVDfc0gnL0Ys6xk51jK+FobbFr8JzSGzYYn0ZpvcUYZXTBVMkxXO7XBr2K4ux A859qaOSqY6RfFZt7BjOrv8ee10Y4MuxncoteZKoljtyY4vQ9KgmVU0IwG5MHpDDSG5W TTlLyfWfhEMxTZM8fGps72QvuCPmZPyeiUl8ZWqUnu3bKwdXi2XFXVIxCeoUc2gnIa3s n4/Q== X-Gm-Message-State: ABuFfohVLVSCsG6iSf43OAdmUqGQit1fmW/0uGG5k1+gsJbBqQAbDyhy GhAfNV4E3fHZ/OaqRSPGEAux6aTj X-Google-Smtp-Source: ACcGV60nqgdK6dFfM54vSanjS7o7ElPZ7Es3foqkiUSEII0bZ37p7YYI6QE9hkWo7AVwrmwe/csgsg== X-Received: by 2002:a19:c203:: with SMTP id l3mr4214016lfc.113.1540218105862; Mon, 22 Oct 2018 07:21:45 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id n192-v6sm1388451lfn.0.2018.10.22.07.21.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Oct 2018 07:21:44 -0700 (PDT) Subject: Re: krpc: unbootable ZFS-on-root after major upgrade to 11.2 To: Glen Barber , Eugene Grosbein Cc: FreeBSD stable References: <8517429b-9e3b-2ea3-80a6-12fc92106252@grosbein.net> <6627d159-fd52-2d10-2d45-97fd02725adc@FreeBSD.org> <5BC9A2E4.9010306@grosbein.net> <6c2f8adb-c0e7-550b-8595-e7a4768d5157@FreeBSD.org> <20181022140304.GE13668@FreeBSD.org> <1d5236b8-0269-5dce-3f2e-e7b1910836c6@grosbein.net> <20181022141527.GF13668@FreeBSD.org> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: Date: Mon, 22 Oct 2018 17:21:43 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20181022141527.GF13668@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Mon, 22 Oct 2018 14:29:46 -0000 On 22/10/2018 17:15, Glen Barber wrote: > On Mon, Oct 22, 2018 at 09:09:14PM +0700, Eugene Grosbein wrote: >> 22.10.2018 21:03, Glen Barber wrote: >> >> t's strange that this is a 10.x vs 11.x issue. >>>>> I see that zfs has the krpc dependency since r193128. >>>>> And the call to xdrmem_create is there since r168404. >>>> >>>> You are right. I was mis-informed and have not verified enough a report from local user. >>>> >>>> Glen, maybe that errata record should be deleted. The problem is real but it is long-standing >>>> and present in 10.x too. >>>> >>> >>> Could you elaborate more on the failure case you originally reported >>> first? If the problem is real, my feeling is that the errata entry >>> should stay, just worded differently to reflect the failure case here. >> >> zfs.ko depends on krpc.ko. The KRPC code in compiled in GENERIC kernel as dependency >> of NFS client/server code. The problem arises if all of these are true: >> >> 1) a system uses custom kernel with NFS options removed; >> 2) there is no krpc.ko available due to MODULES_OVERRIDE excluding it; >> 3) the system boots off ZFS pool. >> >> In such case, loader cannot resolve dependency and fails to load zfs.ko >> and kernel fails to mount root breaking boot sequence. >> >> > > So, if I understand correctly (and please correct me if I am wrong), the > majority of the text in the errata note is correct, however needs to be > tweaked to remove "upgrading from 10.x...". Is this generally correct? This is just a typical foot-shooting (and a shortcoming of the kernel build system that allows such foot-shooting to happen). I think that there can be other ways in which you can specify inconsistent kernel options and/or an incorrect subset of modules in MODULES_OVERRIDE to create missing dependencies for critical modules. Do we want to issue an errata for each possible misconfiguration? -- Andriy Gapon From owner-freebsd-stable@freebsd.org Mon Oct 22 14:31:24 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43AC1FFDF7D for ; Mon, 22 Oct 2018 14:31:24 +0000 (UTC) (envelope-from bounce@junisbusiness.in.net) Received: from xqt.vtq004.minitechglobal.us (xqt.vtq004.minitechglobal.us [151.80.242.51]) by mx1.freebsd.org (Postfix) with ESMTP id D5A9F7C881 for ; Mon, 22 Oct 2018 14:31:23 +0000 (UTC) (envelope-from bounce@junisbusiness.in.net) To: freebsd-stable@freebsd.org Subject: The Globe for your office desk Message-ID: Date: Mon, 22 Oct 2018 20:48:33 +0800 From: "Magnetic Floating Globe" Reply-To: mailer@junisbusiness.in.net Complaint-To: abuse@junisbusiness.in.net Priority: 3 Precedence: bulk MIME-Version: 1.0 X-Mailer-LID: 77,78 X-Mailer-RecptId: 5261779 X-Mailer-SID: 74 X-Abuse-Reports-To: abuse@junisbusiness.in.net X-Mailer-Sent-By: 1 Content-Type: text/plain; format=flowed; charset="UTF-8" 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 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 14:31:24 -0000 Your email client cannot read this email. To view it online, please go here: http://server1.junisbusiness.in.net/junisbusiness/display.php?M=5261779&C=b76ac1aa82141311fcdcc94b315da069&S=74&L=77&N=2 To stop receiving these emails:http://server1.junisbusiness.in.net/junisbusiness/unsubscribe.php?M=5261779&C=b76ac1aa82141311fcdcc94b315da069&L=77&N=74 From owner-freebsd-stable@freebsd.org Mon Oct 22 14:32:59 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6850FFE161 for ; Mon, 22 Oct 2018 14:32:59 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:d12:604::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 2C6EB7CA3D; Mon, 22 Oct 2018 14:32:59 +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 w9MEWqS1009876 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Oct 2018 16:32:53 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: avg@FreeBSD.org Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w9MEWofw074763 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 22 Oct 2018 21:32:50 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: krpc: unbootable ZFS-on-root after major upgrade to 11.2 To: Andriy Gapon , Glen Barber References: <8517429b-9e3b-2ea3-80a6-12fc92106252@grosbein.net> <6627d159-fd52-2d10-2d45-97fd02725adc@FreeBSD.org> <5BC9A2E4.9010306@grosbein.net> <6c2f8adb-c0e7-550b-8595-e7a4768d5157@FreeBSD.org> <20181022140304.GE13668@FreeBSD.org> <1d5236b8-0269-5dce-3f2e-e7b1910836c6@grosbein.net> <20181022141527.GF13668@FreeBSD.org> Cc: FreeBSD stable From: Eugene Grosbein Message-ID: <8b31ed45-eddb-e93e-57f6-4bc1387d18ff@grosbein.net> Date: Mon, 22 Oct 2018 21:32:45 +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_PASS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net 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: Mon, 22 Oct 2018 14:32:59 -0000 22.10.2018 21:21, Andriy Gapon wrote: >>>>> Glen, maybe that errata record should be deleted. The problem is real but it is long-standing >>>>> and present in 10.x too. >>>>> >>>> >>>> Could you elaborate more on the failure case you originally reported >>>> first? If the problem is real, my feeling is that the errata entry >>>> should stay, just worded differently to reflect the failure case here. >>> >>> zfs.ko depends on krpc.ko. The KRPC code in compiled in GENERIC kernel as dependency >>> of NFS client/server code. The problem arises if all of these are true: >>> >>> 1) a system uses custom kernel with NFS options removed; >>> 2) there is no krpc.ko available due to MODULES_OVERRIDE excluding it; >>> 3) the system boots off ZFS pool. >>> >>> In such case, loader cannot resolve dependency and fails to load zfs.ko >>> and kernel fails to mount root breaking boot sequence. >>> >>> >> >> So, if I understand correctly (and please correct me if I am wrong), the >> majority of the text in the errata note is correct, however needs to be >> tweaked to remove "upgrading from 10.x...". Is this generally correct? Yes. > This is just a typical foot-shooting (and a shortcoming of the kernel build > system that allows such foot-shooting to happen). > I think that there can be other ways in which you can specify inconsistent > kernel options and/or an incorrect subset of modules in MODULES_OVERRIDE to > create missing dependencies for critical modules. > Do we want to issue an errata for each possible misconfiguration? OTOH, we have option krpc in sys/conf/options but it is not mentioned elsewhere: not in the Handbook nor in the sys/conf/NOTES or GENERIC. Not a bit of our documentation mentions that ZFS requires KRPC for last 10 years. One can call it foot-shooting if it is against documentation but that's not the case. From owner-freebsd-stable@freebsd.org Mon Oct 22 14:36:01 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB5DCFFE33E for ; Mon, 22 Oct 2018 14:36:01 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6FD0B7CC21; Mon, 22 Oct 2018 14:36:01 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 32B7BF516; Mon, 22 Oct 2018 14:36:01 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Mon, 22 Oct 2018 14:35:59 +0000 From: Glen Barber To: Andriy Gapon Cc: Eugene Grosbein , FreeBSD stable Subject: Re: krpc: unbootable ZFS-on-root after major upgrade to 11.2 Message-ID: <20181022143559.GG13668@FreeBSD.org> References: <8517429b-9e3b-2ea3-80a6-12fc92106252@grosbein.net> <6627d159-fd52-2d10-2d45-97fd02725adc@FreeBSD.org> <5BC9A2E4.9010306@grosbein.net> <6c2f8adb-c0e7-550b-8595-e7a4768d5157@FreeBSD.org> <20181022140304.GE13668@FreeBSD.org> <1d5236b8-0269-5dce-3f2e-e7b1910836c6@grosbein.net> <20181022141527.GF13668@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Uu2n37VG4rOBDVuR" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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: Mon, 22 Oct 2018 14:36:02 -0000 --Uu2n37VG4rOBDVuR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 22, 2018 at 05:21:43PM +0300, Andriy Gapon wrote: > On 22/10/2018 17:15, Glen Barber wrote: > > On Mon, Oct 22, 2018 at 09:09:14PM +0700, Eugene Grosbein wrote: > >> 22.10.2018 21:03, Glen Barber wrote: > >> > >> t's strange that this is a 10.x vs 11.x issue. > >>>>> I see that zfs has the krpc dependency since r193128. > >>>>> And the call to xdrmem_create is there since r168404. > >>>> > >>>> You are right. I was mis-informed and have not verified enough a rep= ort from local user. > >>>> > >>>> Glen, maybe that errata record should be deleted. The problem is rea= l but it is long-standing > >>>> and present in 10.x too. > >>>> > >>> > >>> Could you elaborate more on the failure case you originally reported > >>> first? If the problem is real, my feeling is that the errata entry > >>> should stay, just worded differently to reflect the failure case here. > >> > >> zfs.ko depends on krpc.ko. The KRPC code in compiled in GENERIC kernel= as dependency > >> of NFS client/server code. The problem arises if all of these are true: > >> > >> 1) a system uses custom kernel with NFS options removed; > >> 2) there is no krpc.ko available due to MODULES_OVERRIDE excluding it; > >> 3) the system boots off ZFS pool. > >> > >> In such case, loader cannot resolve dependency and fails to load zfs.ko > >> and kernel fails to mount root breaking boot sequence. > >> > >> > >=20 > > So, if I understand correctly (and please correct me if I am wrong), the > > majority of the text in the errata note is correct, however needs to be > > tweaked to remove "upgrading from 10.x...". Is this generally correct? >=20 > This is just a typical foot-shooting (and a shortcoming of the kernel bui= ld > system that allows such foot-shooting to happen). > I think that there can be other ways in which you can specify inconsistent > kernel options and/or an incorrect subset of modules in MODULES_OVERRIDE = to > create missing dependencies for critical modules. > Do we want to issue an errata for each possible misconfiguration? >=20 Not necessarily. I think it is a matter of how common the edge case is, for example. I am perfectly fine removing the errata entry if this is an extreme edge case. Meaning, I think it would be excessive to document the fallout from adding 'nodevice mem' to the configuration file. Glen --Uu2n37VG4rOBDVuR Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAlvN4E8ACgkQAxRYpUeP 4pP0nQ/+P1teIIE73mnhsyS8OTWPSV8wiVVFLmNI7khecaF7R0C7mZxK6I+Rbge2 jzTNrY3OgLXod3roxECYMg73N4vvZpnosN4CTA2k54sfjrMmHZukkaq2M3XboYGr ozzVluuGnXS5RDzsCDvb+xWMJVW4fj+fa+81WguerXei0FEfzG4rGK60AjwayLEC kuZCPG/7+qnucwsUmS2vmM8pcFxYajjR8JkFqGEnA7FGE32TxCFCK5Fsg5/Uf8Gn fhfBJYgY4iHEV0AgkR4sFJL3vO4PmYdPdNY2UG9gQkvVeVhlPZTqovjTLSknjXIm Vp++YTgEclcPaLKrxJ9vmKP/uexaCjMVw8eitJaeGf3FmecnKNZq+f5mLwEpSWsP HQdAiXSWrYNwCjrPQRtKessICs5iK8z9zcgW1MU8lmkSJvKeWJ2TSsF+ee4+wpF4 Ki5y/c2p0Azd35nG3jOflc5NLcGsX/D8DduYC9hcjQi4+v2S0lHkhJAK9ox+OCve XJAONfmofeVqP6EF7fOlSIZrAIsaEH+5Ky1CZdt7Cuz2mtXY1JLHRmtzKusph/o/ CPmf0QTQU4VhUlj9qAaF482/x54pzn7s4F9LlOjONeYNhYxFO08se3URu984H0n4 LdIY5kNwPUw9ocT+xqyhaSKBpQl+yqZKftDmeeLWzdqZ4YayBE4= =Bpln -----END PGP SIGNATURE----- --Uu2n37VG4rOBDVuR-- From owner-freebsd-stable@freebsd.org Mon Oct 22 14:43:04 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C094CFFE9B2 for ; Mon, 22 Oct 2018 14:43:04 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2AA077D306; Mon, 22 Oct 2018 14:43:04 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lj1-f176.google.com with SMTP id p1-v6so37226299ljg.6; Mon, 22 Oct 2018 07:43:04 -0700 (PDT) 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:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=s6egqj9YcHYeXmh12zxF9IGwWzefveX8GES67P+Z5u4=; b=MWcKA0TCciMbtuUW+8ivUtb9t4NPkK03WNWqOgk29C1451T0qlfndvszSIxk9aq7Uy Yq3WXAN6Yg9RG8uKuCtGYIDyzaAkQQGaYESCXpxXKMqaQSSFfQYjzulJaTfFFcoHmdsn uICcKZ5ysXE3RnRyY9XZPR82xJ6QRJUABrnBDr2cEZKoXcsxI2gDwQyNFk6Jh0Q4KfwC yHVrIsTtQZ+wZteGfDQsLOUt7ecELzJs+dbqDWb+tlZRiaStr3D342wUAED7PF5NHZOQ I0xbDdxYx/MU3tVyeow+siL6V1e1mNmw19C/XxY2REzl9iqtHH11AgQ9BrFObvcLFVry sesw== X-Gm-Message-State: ABuFfojtnR7Jyir/g4A6N529u4pccuvINM3HGbkES5mQigMmvl8SdG+b y7qmxuXs9dHKF7A9GeHPGpa276UJ X-Google-Smtp-Source: ACcGV617gJy+IvzL14ZNI9MEpWq204BfCB28zd0IghlcNnIop38Ql6W48M9h1jXd0f3N0ZePrSmv6A== X-Received: by 2002:a2e:6e08:: with SMTP id j8-v6mr32434004ljc.61.1540219377133; Mon, 22 Oct 2018 07:42:57 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id p21-v6sm6743775lfc.5.2018.10.22.07.42.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Oct 2018 07:42:56 -0700 (PDT) Subject: Re: krpc: unbootable ZFS-on-root after major upgrade to 11.2 To: Eugene Grosbein , Glen Barber Cc: FreeBSD stable References: <8517429b-9e3b-2ea3-80a6-12fc92106252@grosbein.net> <6627d159-fd52-2d10-2d45-97fd02725adc@FreeBSD.org> <5BC9A2E4.9010306@grosbein.net> <6c2f8adb-c0e7-550b-8595-e7a4768d5157@FreeBSD.org> <20181022140304.GE13668@FreeBSD.org> <1d5236b8-0269-5dce-3f2e-e7b1910836c6@grosbein.net> <20181022141527.GF13668@FreeBSD.org> <8b31ed45-eddb-e93e-57f6-4bc1387d18ff@grosbein.net> From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFm4LIgBEADNB/3lT7f15UKeQ52xCFQx/GqHkSxEdVyLFZTmY3KyNPQGBtyvVyBfprJ7 mAeXZWfhat6cKNRAGZcL5EmewdQuUfQfBdYmKjbw3a9GFDsDNuhDA2QwFt8BmkiVMRYyvI7l N0eVzszWCUgdc3qqM6qqcgBaqsVmJluwpvwp4ZBXmch5BgDDDb1MPO8AZ2QZfIQmplkj8Y6Z AiNMknkmgaekIINSJX8IzRzKD5WwMsin70psE8dpL/iBsA2cpJGzWMObVTtCxeDKlBCNqM1i gTXta1ukdUT7JgLEFZk9ceYQQMJJtUwzWu1UHfZn0Fs29HTqawfWPSZVbulbrnu5q55R4PlQ /xURkWQUTyDpqUvb4JK371zhepXiXDwrrpnyyZABm3SFLkk2bHlheeKU6Yql4pcmSVym1AS4 dV8y0oHAfdlSCF6tpOPf2+K9nW1CFA8b/tw4oJBTtfZ1kxXOMdyZU5fiG7xb1qDgpQKgHUX8 7Rd2T1UVLVeuhYlXNw2F+a2ucY+cMoqz3LtpksUiBppJhw099gEXehcN2JbUZ2TueJdt1FdS ztnZmsHUXLxrRBtGwqnFL7GSd6snpGIKuuL305iaOGODbb9c7ne1JqBbkw1wh8ci6vvwGlzx rexzimRaBzJxlkjNfMx8WpCvYebGMydNoeEtkWldtjTNVsUAtQARAQABzR5BbmRyaXkgR2Fw b24gPGF2Z0BGcmVlQlNELm9yZz7CwZQEEwEIAD4WIQS+LEO7ngQnXA4Bjr538m7TUc1yjwUC WbgsiAIbIwUJBaOagAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRB38m7TUc1yj+JAEACV l9AK/nOWAt/9cufV2fRj0hdOqB1aCshtSrwHk/exXsDa4/FkmegxXQGY+3GWX3deIyesbVRL rYdtdK0dqJyT1SBqXK1h3/at9rxr9GQA6KWOxTjUFURsU7ok/6SIlm8uLRPNKO+yq0GDjgaO LzN+xykuBA0FlhQAXJnpZLcVfPJdWv7sSHGedL5ln8P8rxR+XnmsA5TUaaPcbhTB+mG+iKFj GghASDSfGqLWFPBlX/fpXikBDZ1gvOr8nyMY9nXhgfXpq3B6QCRYKPy58ChrZ5weeJZ29b7/ QdEO8NFNWHjSD9meiLdWQaqo9Y7uUxN3wySc/YUZxtS0bhAd8zJdNPsJYG8sXgKjeBQMVGuT eCAJFEYJqbwWvIXMfVWop4+O4xB+z2YE3jAbG/9tB/GSnQdVSj3G8MS80iLS58frnt+RSEw/ psahrfh0dh6SFHttE049xYiC+cM8J27Aaf0i9RflyITq57NuJm+AHJoU9SQUkIF0nc6lfA+o JRiyRlHZHKoRQkIg4aiKaZSWjQYRl5Txl0IZUP1dSWMX4s3XTMurC/pnja45dge/4ESOtJ9R 8XuIWg45Oq6MeIWdjKddGhRj3OohsltKgkEU3eLKYtB6qRTQypHHUawCXz88uYt5e3w4V16H lCpSTZV/EVHnNe45FVBlvK7k7HFfDDkryM7BTQRZuCyIARAAlq0slcsVboY/+IUJdcbEiJRW be9HKVz4SUchq0z9MZPX/0dcnvz/gkyYA+OuM78dNS7Mbby5dTvOqfpLJfCuhaNYOhlE0wY+ 1T6Tf1f4c/uA3U/YiadukQ3+6TJuYGAdRZD5EqYFIkreARTVWg87N9g0fT9BEqLw9lJtEGDY EWUE7L++B8o4uu3LQFEYxcrb4K/WKmgtmFcm77s0IKDrfcX4doV92QTIpLiRxcOmCC/OCYuO jB1oaaqXQzZrCutXRK0L5XN1Y1PYjIrEzHMIXmCDlLYnpFkK+itlXwlE2ZQxkfMruCWdQXye syl2fynAe8hvp7Mms9qU2r2K9EcJiR5N1t1C2/kTKNUhcRv7Yd/vwusK7BqJbhlng5ZgRx0m WxdntU/JLEntz3QBsBsWM9Y9wf2V4tLv6/DuDBta781RsCB/UrU2zNuOEkSixlUiHxw1dccI 6CVlaWkkJBxmHX22GdDFrcjvwMNIbbyfQLuBq6IOh8nvu9vuItup7qemDG3Ms6TVwA7BD3j+ 3fGprtyW8Fd/RR2bW2+LWkMrqHffAr6Y6V3h5kd2G9Q8ZWpEJk+LG6Mk3fhZhmCnHhDu6CwN MeUvxXDVO+fqc3JjFm5OxhmfVeJKrbCEUJyM8ESWLoNHLqjywdZga4Q7P12g8DUQ1mRxYg/L HgZY3zfKOqcAEQEAAcLBfAQYAQgAJhYhBL4sQ7ueBCdcDgGOvnfybtNRzXKPBQJZuCyIAhsM BQkFo5qAAAoJEHfybtNRzXKPBVwQAKfFy9P7N3OsLDMB56A4Kf+ZT+d5cIx0Yiaf4n6w7m3i ImHHHk9FIetI4Xe54a2IXh4Bq5UkAGY0667eIs+Z1Ea6I2i27Sdo7DxGwq09Qnm/Y65ADvXs 3aBvokCcm7FsM1wky395m8xUos1681oV5oxgqeRI8/76qy0hD9WR65UW+HQgZRIcIjSel9vR XDaD2HLGPTTGr7u4v00UeTMs6qvPsa2PJagogrKY8RXdFtXvweQFz78NbXhluwix2Tb9ETPk LIpDrtzV73CaE2aqBG/KrboXT2C67BgFtnk7T7Y7iKq4/XvEdDWscz2wws91BOXuMMd4c/c4 OmGW9m3RBLufFrOag1q5yUS9QbFfyqL6dftJP3Zq/xe+mr7sbWbhPVCQFrH3r26mpmy841ym dwQnNcsbIGiBASBSKksOvIDYKa2Wy8htPmWFTEOPRpFXdGQ27awcjjnB42nngyCK5ukZDHi6 w0qK5DNQQCkiweevCIC6wc3p67jl1EMFY5+z+zdTPb3h7LeVnGqW0qBQl99vVFgzLxchKcl0 R/paSFgwqXCZhAKMuUHncJuynDOP7z5LirUeFI8qsBAJi1rXpQoLJTVcW72swZ42IdPiboqx NbTMiNOiE36GqMcTPfKylCbF45JNX4nF9ElM0E+Y8gi4cizJYBRr2FBJgay0b9Cp Message-ID: Date: Mon, 22 Oct 2018 17:42:54 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <8b31ed45-eddb-e93e-57f6-4bc1387d18ff@grosbein.net> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Mon, 22 Oct 2018 14:43:05 -0000 On 22/10/2018 17:32, Eugene Grosbein wrote: > 22.10.2018 21:21, Andriy Gapon wrote: >> This is just a typical foot-shooting (and a shortcoming of the kernel build >> system that allows such foot-shooting to happen). >> I think that there can be other ways in which you can specify inconsistent >> kernel options and/or an incorrect subset of modules in MODULES_OVERRIDE to >> create missing dependencies for critical modules. >> Do we want to issue an errata for each possible misconfiguration? > > OTOH, we have option krpc in sys/conf/options but it is not mentioned elsewhere: > not in the Handbook nor in the sys/conf/NOTES or GENERIC. Not a bit of our documentation mentions > that ZFS requires KRPC for last 10 years. > > One can call it foot-shooting if it is against documentation but that's not the case. I certainly agree that there is a lack of documentation. Still, this is a foot-shooting. Anyway, my point was about a need to create an erratum for this kind of issue. A documentation update would be much more appropriate. -- Andriy Gapon From owner-freebsd-stable@freebsd.org Mon Oct 22 15:21:20 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82F2EFFFB9C for ; Mon, 22 Oct 2018 15:21:20 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:d12:604::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 08F137EAC6; Mon, 22 Oct 2018 15:21:19 +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 w9MFLCGG010298 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Oct 2018 17:21:13 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: gjb@freebsd.org Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w9MFLBoJ075058 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 22 Oct 2018 22:21:11 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: krpc: unbootable ZFS-on-root after major upgrade to 11.2 To: Glen Barber , Andriy Gapon References: <8517429b-9e3b-2ea3-80a6-12fc92106252@grosbein.net> <6627d159-fd52-2d10-2d45-97fd02725adc@FreeBSD.org> <5BC9A2E4.9010306@grosbein.net> <6c2f8adb-c0e7-550b-8595-e7a4768d5157@FreeBSD.org> <20181022140304.GE13668@FreeBSD.org> <1d5236b8-0269-5dce-3f2e-e7b1910836c6@grosbein.net> <20181022141527.GF13668@FreeBSD.org> <20181022143559.GG13668@FreeBSD.org> Cc: FreeBSD stable From: Eugene Grosbein Message-ID: <80971314-a8f0-6539-e4cc-ce5774f3c1af@grosbein.net> Date: Mon, 22 Oct 2018 22:21: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: <20181022143559.GG13668@FreeBSD.org> 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_PASS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net 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: Mon, 22 Oct 2018 15:21:20 -0000 22.10.2018 21:35, Glen Barber wrote: >> This is just a typical foot-shooting (and a shortcoming of the kernel build >> system that allows such foot-shooting to happen). >> I think that there can be other ways in which you can specify inconsistent >> kernel options and/or an incorrect subset of modules in MODULES_OVERRIDE to >> create missing dependencies for critical modules. >> Do we want to issue an errata for each possible misconfiguration? > > Not necessarily. I think it is a matter of how common the edge case is, > for example. I am perfectly fine removing the errata entry if this is > an extreme edge case. Well, usage of stripped-down kernel instead of GENERIC may be less common than it was 10 years ago. But not extreme rare because of low-class virtual machines. Same with stripped-down installed set of files without full set of kernel modules but this may be more extreme as (virtual) disk space is more cheap than RAM. ZFS-on-root is definitely not so seldom. From owner-freebsd-stable@freebsd.org Mon Oct 22 16:26:36 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A386E1037811 for ; Mon, 22 Oct 2018 16:26:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B80382E1F for ; Mon, 22 Oct 2018 16:26:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x931.google.com with SMTP id o17so7438168uad.8 for ; Mon, 22 Oct 2018 09:26:36 -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=3jLHZnuVsyGnFbCHnV1R2lxzjTZ/hPnraRgZQVp1bCc=; b=vJysLy1SMgSRkKnbYwfhoGy1INLZ1GkISHpfTmlNMdB3frJhOe9sz6N9cV/6wSGe7/ cEoTvAvC4FeTZf0l0i7Fsari6Hg7Hsd9BUkXWVuVs9dSlNHp5lMS1GAAxxoUJVJxpBbZ +uyxhO2lFnjgB4w8LQEEcqN685V88b776FiS7gyCdvHQ7gts5c62vW5dqYKNaNuZedUE DlJJ/qymTPNScnnKAbp6UzqSJMY95OIOpNSIE5yOGVKwbr/ykYuGDyfibPpKsjsixC58 mWK0qwuHBKX5wLfL4h6xSu4VUE8PEMUBq+/Mr59+vgMh68FPZdC+YR9+H5UYZY3gAq/2 JpKg== 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=3jLHZnuVsyGnFbCHnV1R2lxzjTZ/hPnraRgZQVp1bCc=; b=eeWqGs1jHwMszFIjaCgM0okMZ/VD9NtgCOLlAwa6mrE3Dbu2TecSPYJ9r+m5jxSRwc Sm2alpgHtgKc7aAVeHOmBAwb6wCK6JWlm8wC7ChClPB5PvELIvyAe4Oh4K0i1HPd5Kms rv71hLESrmxlk9zIVnbaDfeKbi2Tl6b40swZSA/Al+2pXUhbSshlqh2rOuaVbgxV6nKm x7mKqbRy/5M6PbkF13/b+zACK8FBI8JZPL8d7kwp5CtEQ0umo3FUwzwb8P5hSOaDugqM sWPr2buVD1gcXXXXC1+lNfxvHtwAFU7RbqsAOzIojyseTRVc388JoHo9w/zgOb4Qx8oN alDw== X-Gm-Message-State: ABuFfoh7lZtM2AhZI/gWHKBmn3rfr5v2F3UpD/6VRVcuToYaLRy6ZmyN /f52g+Uqxp4Jq8BI7GwdeVADqBmBBIF0CN8ebR/gxA== X-Google-Smtp-Source: ACcGV60yZOoYwEZQ4zUIlMefVNPWacJ672/LwGVvso5LaIY+v5eKKwHXiEOS+BasZJcIIBAHT3DKwrETFsSOHYmMsRE= X-Received: by 2002:ab0:a97:: with SMTP id d23mr20230823uak.39.1540225595474; Mon, 22 Oct 2018 09:26:35 -0700 (PDT) MIME-Version: 1.0 References: <79973E2B-F5C4-4E7C-B92B-1C8D4441C7D1@yahoo.com> <3CA4C94F-A062-44FE-B507-948A6F88C83D@me.com> <085BCA2B-4451-406C-9CEE-57D8B8008201@yahoo.com> <9AEF5EB3-C393-44D1-9BD4-D0E59FE97CCE@me.com> <08B26F92-F1F5-4F51-8DC4-EDDC6DD493B2@yahoo.com> In-Reply-To: <08B26F92-F1F5-4F51-8DC4-EDDC6DD493B2@yahoo.com> From: Warner Losh Date: Mon, 22 Oct 2018 10:26:23 -0600 Message-ID: Subject: Re: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated To: Mark Millard Cc: Toomas Soome , Konstantin Belousov , FreeBSD Current , FreeBSD-STABLE Mailing List 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: Mon, 22 Oct 2018 16:26:36 -0000 On Mon, Oct 22, 2018 at 6:39 AM Mark Millard wrote: > On 2018-Oct-22, at 4:07 AM, Toomas Soome wrote: > > > On 22 Oct 2018, at 13:58, Mark Millard wrote: > >> > >> On 2018-Oct-22, at 2:27 AM, Toomas Soome wrote: > >>> > >>>> On 22 Oct 2018, at 06:30, Warner Losh wrote: > >>>> > >>>> On Sun, Oct 21, 2018 at 9:28 PM Warner Losh wrote: > >>>> > >>>>> > >>>>> > >>>>> On Sun, Oct 21, 2018 at 8:57 PM Mark Millard via freebsd-stable < > >>>>> freebsd-stable@freebsd.org> wrote: > >>>>> > >>>>>> [I built based on WITHOUT_ZFS=3D for other reasons. But, > >>>>>> after installing the build, Hyper-V based boots are > >>>>>> working.] > >>>>>> > >>>>>> On 2018-Oct-20, at 2:09 AM, Mark Millard > wrote: > >>>>>> > >>>>>>> On 2018-Oct-20, at 1:39 AM, Mark Millard > wrote: > >>>>>>> . . . > >>>> > >>> > >>> It would help to get output from loader lsdev -v command. > >> > >> That turned out to be very interesting: The non-ZFS loader > >> crashes during the listing, during disk8, which shows a > >> x0 instead of a x512. > >> > > > > Yes, thats the root cause there. The non-zfs loader does only *read* th= e > boot disk, thats why the issue was not revealed there. > > > > It would help to identify the sector size for that disk, at least from > OS, so we can compare with what we can get from INT13. > > > > I have pretty good idea what to look there, but I am afraid we need to > run few tests with you to understand why that disk is reporting sector si= ze > 0 there. > > > > > > Looks like I guessed wrong about the device > for "drive8". > > So I unplugged the only other external > storage device, so the original drives > 0-13 become 0-11 overall. > > The machine has a multi-LUN media card reader with > no cards plugged in. It is built-in rather than > one that I plugged into a port. It has 4 LUN's. > > So 8+4=3D12 and drives 0-7 show up with media before > it tries any of the 4 LUN's with no card in place. > > I conclude that "drive8" is an empty LUN in a media > card reader. > > I conclude that there is no sector size available for > any of the empty LUNs in the media reader. > I think you are probably right and we're hitting some divide by 0 error when we should just ignore the disk. Warner > > > > > >> Hand transcribed from pictures: > >> > >> OK lsdev -v > >> disk devices > >> disk0: BIOS drive C (937703088 x 512): > >> disk0p1: FreeBSD boot 512K > >> disk0p2: FreeBSD UFS 356G > >> disk0p3: FreeBSD swap 15G > >> disp0p4: FreeBSD swap 76G > >> disk1: BIOS drive D (16514064 x 512): > >> disk1s1: Linux 2048KB > >> disk1s2: Unknown 952GB > >> disk2: BIOS drive E (16514064 x 512): > >> disk2p1: Unknown 128MB > >> disk3: BIOS drive F (16514064 x 512): > >> disk3p1: Unknown 128MB > >> disk4: BIOS drive G (16434495 x 512): > >> disk2p1: Unknown 128MB > >> disk4p2: DOS/Windwos 1716GB > >> disk5: BIOS drive H (16434495 x 512): > >> disk5p1: FreeBSD boot 512K > >> disk5p2: FreeBSD UFS 176G > >> disk5p3: FreeBSD swap 193G > >> disp5p4: FreeBSD swap 15G > >> disk6: BIOS drive I (16434495 x 512): > >> disk6p1: Unknown 499MB > >> disk6p2: EFI 99MB > >> disk6p3: Unknown 16MB > >> disp6p4: DOS/Windows 886G > >> dis7: BIOS drive H (16434495 x 512): > >> disk7p1: FreeBSD boot 512K > >> disk7p2: FreeBSD UFS 953G > >> disk8: BIOS drive K (262144 x 0): > >> > >> int=3D00000000 err=3D00000000 efl=3D00010246 eip=3D000286bd > >> eax=3D00000000 ebx=3D72b50430 ecx=3D00000000 edx=3D00000000 > >> esi=3D00000000 edi=3D00092080 ebp=3D00091eec esp=3D00091ea8 > >> cs=3D002b ds=3D0033 es=3D0033 fs=3D0033 gs=3D0033 ss=3D0033 > >> cs:eip=3Df7 f1 89 c1 85 d2 0f 85-d8 01 00 00 6a 05 58 85 > >> f6 0f 88 75 01 00 00 89-cb c1 fb 1f 89 ca 03 55 > >> ss:esp=3D09 00 00 00 00 00 00 00-0a 00 00 00 02 00 00 00 > >> 00 00 00 00 00 00 00 00-78 1f 09 00 33 45 04 00 > >> BTX halted > >> > >> I expect that "disk8" is what gpart show -p > >> from a native boot showed as: > >> > >> =3D> 1 60062499 da1 MBR (29G) > >> 1 31 - free - (16K) > >> 32 60062468 da1s1 fat32lba (29G) > >> > >> (That gpart show -p output is in another of the > >> list messages.) > >> > >>> Also if you could test boot loader with UEFI - for example get to > loader prompt via usb/cd boot and then get the same lsdev -v output. > >> > >> Still true given the above crash? Or, going the > >> other way, should "drive8" be left as it is in > >> order to be sure to do this test with the drive > >> present? > >> > >> If I do this test later, it will take a bit to > >> get media to do it with. (It is about 4AM in the > >> morning and I've yet to get to sleep.) > >> > >> Note: I've never tried a UEFI based boot of FreeBSD > >> on this machine (but the Windows 10 Pro x64 is EFI > >> based). The only FreeBSD context using a EFI partition > >> to boot that I have used is on an arm aarch64 > >> Cortex-A57 system. > >> > >>> I would be interested to see the sector size information and if the > UEFI loader does also have issues. > >> > >> Understood. > >> > >>> If it does, I=E2=80=99d like to see the outputs from commands: > >> > >>> zpool status > >>> zpool import > >> > >> Independent of the UEFI test . . . > >> > >> I do have a -r331924 head version on another one > >> of the devices and can native-boot that. It still > >> has its ZFS software (but a default loader without > >> ZFS). > >> > >> Trying from that context, hand transcribed: > >> > >> # zpool status > >> ZFS filesystem version: 5 > >> ZFS storage pool version: features support (5000) > >> no pools available > >> # zpool import > >> # > >> > >> [That was based on the old (default) loader being > >> a non-ZFS one.] > > > > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > From owner-freebsd-stable@freebsd.org Mon Oct 22 17:01:22 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C47910390C8 for ; Mon, 22 Oct 2018 17:01:22 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-21.consmr.mail.bf2.yahoo.com (sonic312-21.consmr.mail.bf2.yahoo.com [74.6.128.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BEDC584F88 for ; Mon, 22 Oct 2018 17:01:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: kseHqggVM1njVTk2ZdUDlI10knkwfLuPJgMRo55EloMZKp4eOhhc4iVdLa.PH8W 5UO1DO1U.iqyEnsjhXxslnqxtfXz4DbkbRtmyVLZU.E8c_FIAxZjTWC6RXvPW0nZYXkmG9Mvhsok jv5bPFC0pqBkI_0AJjPsnZUlfrUyYS33_pfgOoZgCF.DWYvT65_Fjd6AoiDYzbMpotww6O2Pfkpb kEIPfrBEC7hn4NffOCPQ6QYC.C_7KAzNzAf8jgJx6Vyr5suLVsF06ND36nQMDXxBB_pZAeRIUh5r C7BXUrMkCGqyPt9p0Hs3qvGK1vxa41SMZa7pUQVl4adyr4jj4J0e9PxkiO2JGFaP1G4bxWY6HH8I Vjyv5b1Kr4_K3ZG26hu33S4iR7Qzrc62CKbYBuBW9EXYSZ7bkEvxp.64RsPfeclxmy1t8EEp3krj 3S6DFfr57lfu0GGTTDNVbxFeMNAnFdeVb3dFdqXZH1LJlITmE2PqHrH6oqfep2iHiWrsfcQXLSTx RCbMLLQ9FzuARO49Q5Fwb..ILZjlG.jnuwhLPvHYl7JIr6_U4Wv6_uZTF4zSR8EBCijoIUsj3E.s _JWkPcqHW4pMU6wHXnPnWi6G086eTbWTF1ltR97MpjVPPzX4vMZLeAaMlku7j1JzOj4ajSFX.dkP IBVW0BPyfTL_SPujp2x3Jh_G2avHJnZjWXTovZBA0DhPmJ3tV2QR__cE8NYrmMX0QAI6dZW_lQef h.xOTyysv2GOeaddXugQmMa4dfmnuNjGTIxsvdghA20xGzg4YXxt_oz4RMOIANQLG2Fzof38zKMC f0GmiP22q1JZfecL8dlY54oLvtpU1b1HjGQM3hc7jcNwws1Bl97OlmzOjrd9WwaCRpc__oseZDQc l4iUfmc9EXXPJDQsCovqm3scliVMHnGxFPNryS.Cmmb.ByrDf_7dW6o684aytD.N48eygQrKetcT jgT6LUcMYGtNWpQ_eq2fR0_hH6TfUhB86ZsXQqIsLXweNbaaSvd0aMQWOv0Gfd0Z73SUImEujRKh TqIpcLIuZGphzU5IZizhk8xkvxQ9K9iI67u4LLruh69KuyPaKupKfTYemESXKCEt51gqTNT9XgtJ Y0sx0obFX Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Mon, 22 Oct 2018 17:01:21 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp423.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 42bcd5d7160751ce49e2f3a1377a76b2; Mon, 22 Oct 2018 17:01:19 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated From: Mark Millard In-Reply-To: Date: Mon, 22 Oct 2018 10:01:17 -0700 Cc: Toomas Soome , FreeBSD Current , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <16BF1504-AD3B-4B5F-A728-43C2A777A082@yahoo.com> References: <79973E2B-F5C4-4E7C-B92B-1C8D4441C7D1@yahoo.com> <3CA4C94F-A062-44FE-B507-948A6F88C83D@me.com> <085BCA2B-4451-406C-9CEE-57D8B8008201@yahoo.com> <9AEF5EB3-C393-44D1-9BD4-D0E59FE97CCE@me.com> <08B26F92-F1F5-4F51-8DC4-EDDC6DD493B2@yahoo.com> To: Warner Losh , Konstantin Belousov X-Mailer: Apple Mail (2.3445.9.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: Mon, 22 Oct 2018 17:01:22 -0000 [I will note the the loader problem has been shown to not be involved in the kernel problem that this "Subject:" was originally for.] On 2018-Oct-22, at 9:26 AM, Warner Losh wrote: > On Mon, Oct 22, 2018 at 6:39 AM Mark Millard = wrote: >> On 2018-Oct-22, at 4:07 AM, Toomas Soome wrote: >>=20 >> > On 22 Oct 2018, at 13:58, Mark Millard = wrote: >> >>=20 >> >> On 2018-Oct-22, at 2:27 AM, Toomas Soome wrote: >> >>>=20 >> >>>> On 22 Oct 2018, at 06:30, Warner Losh wrote: >> >>>>=20 >> >>>> On Sun, Oct 21, 2018 at 9:28 PM Warner Losh = wrote: >> >>>>=20 >> >>>>>=20 >> >>>>>=20 >> >>>>> On Sun, Oct 21, 2018 at 8:57 PM Mark Millard via freebsd-stable = < >> >>>>> freebsd-stable@freebsd.org> wrote: >> >>>>>=20 >> >>>>>> [I built based on WITHOUT_ZFS=3D for other reasons. But, >> >>>>>> after installing the build, Hyper-V based boots are >> >>>>>> working.] >> >>>>>>=20 >> >>>>>> On 2018-Oct-20, at 2:09 AM, Mark Millard wrote: >> >>>>>>=20 >> >>>>>>> On 2018-Oct-20, at 1:39 AM, Mark Millard wrote: >> >>>>>>> . . . >> >>>>=20 >> >>>=20 >> >>> It would help to get output from loader lsdev -v command. >> >>=20 >> >> That turned out to be very interesting: The non-ZFS loader >> >> crashes during the listing, during disk8, which shows a >> >> x0 instead of a x512. >> >>=20 >> >=20 >> > Yes, thats the root cause there. The non-zfs loader does only = *read* the boot disk, thats why the issue was not revealed there.=20 >> >=20 >> > It would help to identify the sector size for that disk, at least = from OS, so we can compare with what we can get from INT13. >> >=20 >> > I have pretty good idea what to look there, but I am afraid we need = to run few tests with you to understand why that disk is reporting = sector size 0 there. >> >=20 >> >=20 >>=20 >> Looks like I guessed wrong about the device >> for "drive8". >>=20 >> So I unplugged the only other external >> storage device, so the original drives >> 0-13 become 0-11 overall. >>=20 >> The machine has a multi-LUN media card reader with >> no cards plugged in. It is built-in rather than >> one that I plugged into a port. It has 4 LUN's. >>=20 >> So 8+4=3D12 and drives 0-7 show up with media before >> it tries any of the 4 LUN's with no card in place. >>=20 >> I conclude that "drive8" is an empty LUN in a media >> card reader. >>=20 >> I conclude that there is no sector size available for >> any of the empty LUNs in the media reader. >>=20 > I think you are probably right and we're hitting some divide by 0 = error when we should just ignore the disk. In the Hyper-V context, the loader and kernel do not see the 4-LUN media reader at all: only drives with normal freebsd-* style partitions and free space. This explains why I did not see a loader problem in that context. So I conclude that the kernel crash under Hyper-V associated with -r338807 is a separate issue even though WITHOUT_ZFS=3D seems to have avoided the crash. My plan is to continue with the -r338807 investigation after the loader problem is fixed in my builds. Then I've go back to trying builds using WITH_ZFS=3D (implicit), both native boots and Hyper-V based ones. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-stable@freebsd.org Tue Oct 23 01:43:29 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 05224FF0DC3 for ; Tue, 23 Oct 2018 01:43:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-12.consmr.mail.bf2.yahoo.com (sonic304-12.consmr.mail.bf2.yahoo.com [74.6.128.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8D14B80950 for ; Tue, 23 Oct 2018 01:43:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: .FqKwM4VM1kvm6HuSbkUubvD1CfRWK8UaOtmkzZ_._EBC.ecC3.F41ytmoRRDNE iV7cpHptQ9QTx8VQYCFcSi7hKADlEvDqahE_xlzRuYd.WehjYJ387t6ohq2xaXR_XIFyJj3I.Fqz uxGAzXu2BCYgSAFAbpNaukseUcQXSmwXQAClr2itL1sDpZXCKqeCAoq_Av6u.Z3WBOKN.qEQkYI8 RObafkHbYq1xaoTpitTnqb0.FFm_vG2keRk5Tzbde0lRZ6d2qNKsiwn2mWoF5v3xIj2YKcunmWU5 0D3ShbK49fsg5lztYMtIypEEB2zPS2k04Ho1FSOnvFx3e_FQ78tCRN2l5L08KHbRqA_OrnKVOW.X dCRRRNvCd_fzO8lwUVGYFcoWknrg3ihWjkwlKq53GLlveuy3eAuOGTDVzN4Proe1xjUZs0TWPiwF bExFEsD_YtFDO.fVPbPEm0de5Ku1tx3fPU8AUSLb1JIdPjz5vsMOH3UdwkGlAuLPvjaM3FxA6yfb kv0fKr_feS3T.W3GKyOFc0tzTvkZRLNj33D.NAy9BP8bT4ex0o6LpUFT89DgRczQ_nRGmuVreV.Z tlV6B7q2VeU3L34vUmZk9xP0MdyQijq0iRP_ojiQz5Av2nMUgjpEvy5pTEc89FLrVMY7MS1HACPV _avD8k4wOP4gkoIq9jd3K81dCPb5S9X1wSKrUyWHiZBIqHFMxLO4dIzcpnmWz5906avnQNES5wxV HFfW6bBg_X0Ao7dJpBCoDhTioDlbznr8DkcXP9Pia4Oic0Q.HYzDDG8KHl5_8AP9YCTvUQRk6Hoq oOhBKIOzn4QP_yugtu78_DGYCTDW5gu7Vi_eEPDI6Tg1Wkzd7iNd.djUSc.HGNCFe5R.F.LqwdjQ hKbIf3xe_qM9ZFXcGGYAeUqOA._sPl0sOIRfE5GIJ.L1RwDAT1fQO24QnvaMUxWWDyoUbtiIzegD yrHSAAzA5sEj4RKRkfLT__D3kj4bmz41r9Vo7_XknoGbh5b9VjrdCivIXJukz7bpKTFmEaZA7Wvy bk6S1cvSr.17jAv7qAEBCshliLGKvoxpiwOvVkzrNfgozJY.itUi9Po3X5QRxfpeAYQd_TUIpepP GfKx_2j0- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Tue, 23 Oct 2018 01:43:27 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp420.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 04876bb04a8c3eb2f8320caaf7413218; Tue, 23 Oct 2018 01:43:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated From: Mark Millard In-Reply-To: <16BF1504-AD3B-4B5F-A728-43C2A777A082@yahoo.com> Date: Mon, 22 Oct 2018 18:43:21 -0700 Cc: Toomas Soome , FreeBSD Current , FreeBSD-STABLE Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <302639EA-55AA-4A41-BC03-4D48E6A09000@yahoo.com> References: <79973E2B-F5C4-4E7C-B92B-1C8D4441C7D1@yahoo.com> <3CA4C94F-A062-44FE-B507-948A6F88C83D@me.com> <085BCA2B-4451-406C-9CEE-57D8B8008201@yahoo.com> <9AEF5EB3-C393-44D1-9BD4-D0E59FE97CCE@me.com> <08B26F92-F1F5-4F51-8DC4-EDDC6DD493B2@yahoo.com> <16BF1504-AD3B-4B5F-A728-43C2A777A082@yahoo.com> To: Warner Losh , Konstantin Belousov X-Mailer: Apple Mail (2.3445.9.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: Tue, 23 Oct 2018 01:43:29 -0000 [I' unable to reproduce the under-Hyper-V early kernel crash for WITH_ZFS=3D (implicit) build that includes the for-loaders patch I was given to try.] On 2018-Oct-22, at 10:01 AM, Mark Millard wrote: > [I will note the the loader problem has been shown to > not be involved in the kernel problem that this > "Subject:" was originally for.] >=20 > On 2018-Oct-22, at 9:26 AM, Warner Losh wrote: >=20 >> On Mon, Oct 22, 2018 at 6:39 AM Mark Millard = wrote: >>> On 2018-Oct-22, at 4:07 AM, Toomas Soome wrote: >>>=20 >>>> On 22 Oct 2018, at 13:58, Mark Millard = wrote: >>>>>=20 >>>>> On 2018-Oct-22, at 2:27 AM, Toomas Soome wrote: >>>>>>=20 >>>>>>> On 22 Oct 2018, at 06:30, Warner Losh wrote: >>>>>>>=20 >>>>>>> On Sun, Oct 21, 2018 at 9:28 PM Warner Losh = wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Sun, Oct 21, 2018 at 8:57 PM Mark Millard via freebsd-stable = < >>>>>>>> freebsd-stable@freebsd.org> wrote: >>>>>>>>=20 >>>>>>>>> [I built based on WITHOUT_ZFS=3D for other reasons. But, >>>>>>>>> after installing the build, Hyper-V based boots are >>>>>>>>> working.] >>>>>>>>>=20 >>>>>>>>> On 2018-Oct-20, at 2:09 AM, Mark Millard wrote: >>>>>>>>>=20 >>>>>>>>>> On 2018-Oct-20, at 1:39 AM, Mark Millard wrote: >>>>>>>>>> . . . >>>>>>>=20 >>>>>>=20 >>>>>> It would help to get output from loader lsdev -v command. >>>>>=20 >>>>> That turned out to be very interesting: The non-ZFS loader >>>>> crashes during the listing, during disk8, which shows a >>>>> x0 instead of a x512. >>>>>=20 >>>>=20 >>>> Yes, thats the root cause there. The non-zfs loader does only = *read* the boot disk, thats why the issue was not revealed there.=20 >>>>=20 >>>> It would help to identify the sector size for that disk, at least = from OS, so we can compare with what we can get from INT13. >>>>=20 >>>> I have pretty good idea what to look there, but I am afraid we need = to run few tests with you to understand why that disk is reporting = sector size 0 there. >>>>=20 >>>>=20 >>>=20 >>> Looks like I guessed wrong about the device >>> for "drive8". >>>=20 >>> So I unplugged the only other external >>> storage device, so the original drives >>> 0-13 become 0-11 overall. >>>=20 >>> The machine has a multi-LUN media card reader with >>> no cards plugged in. It is built-in rather than >>> one that I plugged into a port. It has 4 LUN's. >>>=20 >>> So 8+4=3D12 and drives 0-7 show up with media before >>> it tries any of the 4 LUN's with no card in place. >>>=20 >>> I conclude that "drive8" is an empty LUN in a media >>> card reader. >>>=20 >>> I conclude that there is no sector size available for >>> any of the empty LUNs in the media reader. >>>=20 >> I think you are probably right and we're hitting some divide by 0 = error when we should just ignore the disk. >=20 > In the Hyper-V context, the loader and kernel do not > see the 4-LUN media reader at all: only drives with > normal freebsd-* style partitions and free space. > This explains why I did not see a loader problem > in that context. >=20 > So I conclude that the kernel crash under Hyper-V > associated with -r338807 is a separate issue even > though WITHOUT_ZFS=3D seems to have avoided the > crash. >=20 > My plan is to continue with the -r338807 investigation > after the loader problem is fixed in my builds. Then > I've go back to trying builds using WITH_ZFS=3D (implicit), > both native boots and Hyper-V based ones. So much for my ability to make that inference correctly: The WITH_ZFS=3D (implicit) build worked fine for booting natively and via Hyper-V when the patch to fix the loaders was included in what to build. I'm now unable to reproduce this kernel-time crash. The patch was from: https://reviews.freebsd.org/D11174 The empty LUN's in the media reader now get messages that look something like: disk8: Read 1 sector(s) from 0 to 0xffffe000 (0x8000): 0x31 early in the loader activity. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-stable@freebsd.org Tue Oct 23 10:53:19 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F1A201074ACA; Tue, 23 Oct 2018 10:53:18 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.not-for.work (onlyone.not-for.work [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3EAE875690; Tue, 23 Oct 2018 10:53:18 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.23.186] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.not-for.work (Postfix) with ESMTPSA id BB2ACA60; Tue, 23 Oct 2018 13:53:16 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: loader lsdev crashes loader (Was: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated) To: Toomas Soome , Mark Millard Cc: Konstantin Belousov , FreeBSD Current , FreeBSD-STABLE Mailing List , Warner Losh References: <79973E2B-F5C4-4E7C-B92B-1C8D4441C7D1@yahoo.com> <3CA4C94F-A062-44FE-B507-948A6F88C83D@me.com> From: Lev Serebryakov Openpgp: preference=signencrypt Autocrypt: addr=lev@FreeBSD.org; prefer-encrypt=mutual; keydata= xsFNBFKbGksBEADeguVs+XyJc3mL3iiOBqDd16wSk97YTJYOi4VsHsINzJr09oFvNDiaDBIi fLn2p8XcJvehcsF2GSgrfXfw+uK4O1jyNIKJmiYA0EtE+ZbRtvDrrE0w6Q8+SDeKA21SWh3Y vSQ0DJUontbgW55ER2CbEiIUTIn34uQ0kmESAaw/v5p/9ue8yPTmURvv130FqPFz8VPzltqL NxyGt54TxPfKAzAHEIwxlEZ63JOwzloKh1UDBExcsf9nJO08/TAVgR5UZ5njFBPzaaquhRoP qPJLEQQDqxPIlvMNtHKf7iIebE4BHeqgCdJA0BoiR6gpa0wlsZtdrTPK3n4wYSphLvGbhfOZ YW/hbcu7HYS/FImkVxB3iY17kcC1UTnx4ZaYeASPBGOOPbXky1lLfmDGWIFT//70yx+G17qD OZzF1SvJJhGvh6ilFYaWMX7T+nIp6Mcafc4D7AakXM+XdubNXOMlCJhzPcZ0skgAEnYV587w V7em5fDVwQccwvtfezzqKeJAU5TGiywBHSR5Svzk2FwRNf6M//hWkpq0SRR63iOhkHGOAEBi 69GfEIwH2/w24rLxP0E+Hqq8n+EWNkPatw1Mhcl5PKkdvGCjJUaGNMkpBffjyYo254JXRscR eEnwdIkJt4ErDvjb2/UrOFq31wWMOiLzJeVchAgvTHBMRfP9aQARAQABzShMZXYgU2VyZWJy eWFrb3YgPGxldkBzZXJlYnJ5YWtvdi5zcGIucnU+wsGCBBMBCAAsAhsDBwsJCAcDAgEGFQgC CQoLBBYCAwECHgECF4ACGQEFAlKbP8wFCQlmJwEACgkQ6rA8WL/cR4/6VBAAjRMyyX3PBFx/ HxyiIZ698EfwlWUua8Ft4crtrdK52m0qNkbBB9BH8xQgBHG32A1CwyzQnzxHgZuoOWMjh+Qq WJv7dmpM/q/c1GCJHhlPgewXrciTwpAamZILN071u+1GCPWwGRPzfQ/U+k63KJWx9ozf4doM WTTom6Cqcssi4J1u5kkt52a5ZRhsCK9pEVGilk36XTP9BakGrnMSIxF/NK4xeZVX2q+Nuqvf RchyofKXVgLEDLwb1cd/baLtBpDzy0PTN2Zl2lX4kOA6jwTKsqRya9A1Vui1KXwPh2XViTQ1 7Y3l5qg/M+sR73DohezP6bO6huOnLhty17jAqHPNlD6RonDo+j8uIlEg4iMSTN3MhzkBAu0Q pe3ucQ0o1767JiXN3fsNvRzSFhLVNDqPLce4uKlMogsbreXWvdgHGTN1ybOHGbybZnP77yHz uNBacbmG3vL/OLXMqwLdL2JXoiec4DmXjjCdhTBl5xLV9Hz/6VWKqElteg8QFVvHB3tHWzJ4 /rpiVEixytCIII6DS33BXZ0h2EOkK/6AYA2SJxy1vgOH4SZBtDBHoezmHV2nFnq5O0c7AuAB 7WPWgQG0sEwHQPZmg/baRGitRJnaxf/Gvf1DeD1x1VrcoVke2vwBcgDM3kugP8L9hsqic2D3 dI+gP76haeuvNNZr3y9L9zvOwU0EUpsaSwEQALRr3B+OjY/cnJPstz5CVsVWyEZtJtrNviZr tBgbkhlkPm98sEWR4+gbpyeufdYJengDjeGzMDKcLB7h5fICS/j6A8XdlJ40TlbPfNgb6OHa ebaIYKTJpXKR9sD7ZyGivYMofm0em40wGUX7BIkdkomaWj+wUiS0CdXU0FWDj9wv73+Eim+X zZyXeFgIPv97v+pET7DfwKkADOfrkW9s4OfvGVjd+wm35wc8EngQEz0qdPBxx74X7vZFAxlA SXu8gDBJGYt2Bkc3QwULnfeXrZJWgqNPR5o44gGu96yaiOFaN/C6CJtev5ZEX+0ZxbvsHHB7 Z5AtsRURKpZ4w5HFHGhzHtDtoAKgeZ/gbhTVXPHvNQR818eN+Nl5BV8BRF/8yhR6VlJb8GYw h8oKDeVGVYC34+raHZQAM9WoBnN7jlt4T9zzPwtmw5mIahGFgvw1KDr7OItN2ZgtZ20UYC5m Go602nmHq0aPbU6SwGi1xohrliNsKaaciYiMaVIGRQq8iGr9Fe2HlvaA3BpB275i/gCVlUdG y5XLAv+yQMUvn5Z7XVsMroxDk/O+ae1ElyBvKiKyfWGJXTg5XUukkkyQmfWPxWUGoNA1P/P4 GMHSu7/Rqe/7m4uPu/RyTTqsSjjKJdP9kBwEzvqPtXsVoZuShtrptRQJDYflhgE4qmKSMKen ABEBAAHCwWUEGAECAA8FAlKbGksCGwwFCRLMAwAACgkQ6rA8WL/cR48RkA//SNzeW3CI8KHx rA0aeHW6Nb5ieoqVRBGLyjBM06RX6vHB9v4dJL6Z+yV2jGN2s+XZX2HILbuTOwcTxGkI3xTT e0cDXVaF5K8R/liigUjtwuC2v/sWgoWyUmK1Cy9CPYdcXmFq6nESfkUe8DYiGOUULdHq5w63 F53yOZ72iXRBQBZgkhPtRFu4lPYIzOsMag9DIJ9CthR1r0ziqU/keb94Qt3l+aXK7CwGdY7X T4zUIMHNYsuAuyX+NJIXfsN68TT6m7QmlUwxPs13nxmoVQzm4ruV+hlQKh1MtbsjWRkNgPxF IPiqoAEhy8QoddlSvRTwL5Z7zFQiwMdiXU7toL8pfzj/zJR1jELXKMipijrt5MLrV8XX3OPN yZZvh95VIl8mv+iAqwSZUufd2EJnvj5TObB0eH+a+34NWf/XqA3fPjE6KHzmdnw9PZjPEjlx JCPECSs+6gse1+GaEfKYuXzB/ENe2ctlcfx5iQJXFc+/+zG/uU/JX/pXJHA12CUfB5g7lH6X BZIHvRo3VTCDjXgbF5xxDAe5V4exf8d4oSNjQIFLYxxN7zkvH89EN6RPfRgsWN7bYArCwfS9 MOgs9pFeCOewR6qieK150aoqNENGfKFXJup+5VVl6I0mU+j0rgVDZDht2/QgP/Tb4lGBe+ai pOGaK/GYNR+Ad6bUmokKsx4= Organization: FreeBSD Message-ID: <18e270f6-c811-3f5e-bf65-76c895782c8f@FreeBSD.org> Date: Tue, 23 Oct 2018 13:53:10 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <3CA4C94F-A062-44FE-B507-948A6F88C83D@me.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="O7ARNd9jBNRfZsJ3VM4Jo7ZbtsO6XdNev" 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, 23 Oct 2018 10:53:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --O7ARNd9jBNRfZsJ3VM4Jo7ZbtsO6XdNev Content-Type: multipart/mixed; boundary="xcEBM7iiIpxxFQd7aqLkTSuFwPGzPGsDj"; protected-headers="v1" From: Lev Serebryakov Reply-To: lev@FreeBSD.org To: Toomas Soome , Mark Millard Cc: Konstantin Belousov , FreeBSD Current , FreeBSD-STABLE Mailing List , Warner Losh Message-ID: <18e270f6-c811-3f5e-bf65-76c895782c8f@FreeBSD.org> Subject: loader lsdev crashes loader (Was: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated) References: <79973E2B-F5C4-4E7C-B92B-1C8D4441C7D1@yahoo.com> <3CA4C94F-A062-44FE-B507-948A6F88C83D@me.com> In-Reply-To: <3CA4C94F-A062-44FE-B507-948A6F88C83D@me.com> --xcEBM7iiIpxxFQd7aqLkTSuFwPGzPGsDj Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 22.10.2018 12:27, Toomas Soome wrote: > It would help to get output from loader lsdev -v command. current loader crashes on "lsdev" for me: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D232483 (it is not threadripper-related, my hardware is Intel Atom). --=20 // Lev Serebryakov --xcEBM7iiIpxxFQd7aqLkTSuFwPGzPGsDj-- --O7ARNd9jBNRfZsJ3VM4Jo7ZbtsO6XdNev Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE+W0coLX0MYtnSzMK6rA8WL/cR48FAlvO/ZdfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEY5 NkQxQ0EwQjVGNDMxOEI2NzRCMzMwQUVBQjAzQzU4QkZEQzQ3OEYACgkQ6rA8WL/c R4922hAAp//mV2M5mGHV4ZRBbTZKrHiLUUXKk1sR1DAMjZ/D5aRaH+k2S5v08/LO NZt2G1U37edc9UNGUWTRgHT1Mv5MwRqrCcdkt8/NOXLetQap5e9j685LD5cnS8q5 VKpyj7WT7uKo+lPbRRkTDVQPGFDwJcj5DE2W1jcnQpkz2W9p12i/u5RMfcawZ2Qy exHIb82AMlegnHdE807QKvxQRueJ3CS78a29M8HYQaXujaTyTrkm7pqppDwmwDhH darRK7WLDQrSePUsPgydkXHSiUl1nKAI8wdq2fOCSD9v9oQb8SuF6ykdU5dICbd1 A9/nDfXwOW8XzdOXEFPApUQCq1Hpk1eTZX6QmlKFUzO6fbZpNTx1/019iNZNPWbz hHE0tu+D1WsolDtqngvR/Qyp9Xzh9wtc8PEmYCM9VefaP1i5S9vXpasVMNUW2BRq 8eo4iVdqd+ST66mUTQzOFwe8Yy6/gPWw7LPh8mkHszkxLPRuonl9bONhcnTvV0a4 8RluUELPzBC7N75J3GYnl20JzEJgUIhJpo8d7eCDCw/R2+d99CRrkktazBy7u53U SgxQ2elcOKkLAVU5xArqnz+H7X24HvG8CDY/55kK6+hy1cNd8e+Fqaeks4slNQSe AwOatzRfGJaMJ/gmgvFJ5/Ma0Gpp0B7nafQASU29vCkFzK+SbR4= =iVab -----END PGP SIGNATURE----- --O7ARNd9jBNRfZsJ3VM4Jo7ZbtsO6XdNev-- From owner-freebsd-stable@freebsd.org Tue Oct 23 11:54:36 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 25E381076C4A; Tue, 23 Oct 2018 11:54:36 +0000 (UTC) (envelope-from tsoome@me.com) Received: from pv33p00im-asmtp001.me.com (pv33p00im-asmtp001.me.com [17.142.194.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B4BE277CA8; Tue, 23 Oct 2018 11:54:35 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.pv33p00im-asmtp001.me.com by pv33p00im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) id <0PH100N00VH87W00@pv33p00im-asmtp001.me.com>; Tue, 23 Oct 2018 11:54:21 +0000 (GMT) Received: from icloud.com ([127.0.0.1]) by pv33p00im-asmtp001.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) with ESMTPSA id <0PH1006SKVQCF130@pv33p00im-asmtp001.me.com>; Tue, 23 Oct 2018 11:54:18 +0000 (GMT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=865 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810230103 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-23_03:,, signatures=0 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Subject: Re: loader lsdev crashes loader (Was: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated) From: Toomas Soome In-reply-to: <18e270f6-c811-3f5e-bf65-76c895782c8f@FreeBSD.org> Date: Tue, 23 Oct 2018 14:54:11 +0300 Cc: Mark Millard , Konstantin Belousov , FreeBSD Current , FreeBSD-STABLE Mailing List , Warner Losh Content-transfer-encoding: quoted-printable Message-id: <7B44DEC3-9E79-46E0-BC02-E6C95680BF77@me.com> References: <79973E2B-F5C4-4E7C-B92B-1C8D4441C7D1@yahoo.com> <3CA4C94F-A062-44FE-B507-948A6F88C83D@me.com> <18e270f6-c811-3f5e-bf65-76c895782c8f@FreeBSD.org> To: lev@FreeBSD.org X-Mailer: Apple Mail (2.3445.100.39) 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, 23 Oct 2018 11:54:36 -0000 > On 23 Oct 2018, at 13:53, Lev Serebryakov wrote: >=20 > On 22.10.2018 12:27, Toomas Soome wrote: >=20 >> It would help to get output from loader lsdev -v command. > current loader crashes on "lsdev" for me: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D232483 (it is not > threadripper-related, my hardware is Intel Atom). >=20 > --=20 > // Lev Serebryakov >=20 That error means something is corrupting the memory, it is hard to guess = what exactly and debugging it is nasty - it means we would need to track = down what was allocated before this memory block (guard1 is marker = inserted in front of the allocated memory block).=20 Fortunately the code to print the partition table is in = stand/common/disk.c and the partition code is just next to it and so it = should be relatively easy to find the guilty one=E2=80=A6 I will try to = see if I can replicate the issue. rgds, toomas= From owner-freebsd-stable@freebsd.org Tue Oct 23 14:54:37 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15C75FE59E2 for ; Tue, 23 Oct 2018 14:54:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com [IPv6:2607:f8b0:4864:20::a30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8FF1C8074D for ; Tue, 23 Oct 2018 14:54:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa30.google.com with SMTP id d141so407258vke.3 for ; Tue, 23 Oct 2018 07:54:36 -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=vvQxqfuWBQciKwhpIarGU400W90ZCuhktLB/QJwN7Bo=; b=XWwAXSVSJyIsk6tvdcJQYMvSdEQbEQz7xtgbTY6N1UnlSexZcmk438mp/P22nIU4Sz 9P/qX3XVLQaWaYZFsI3thQRrQDIzpfNbSNKjGMfmj2MSNI6vcFeutarvsCfC9rAtw+VN iMmI59JhDF/cdFeXVDdHFYbp20BB61JVkT8RaLWmZxDUwXI18VqwQS3y7LxM1eE68/Wv /Ct89RXUcO6fritj0DMwmxBrg5jz8kgkqCwC3odNVfGlZQgOieGtRUJqsh/aLKriCHY/ haSf5yeVWTasm/2a05VM31OTglq7XRKHS9hmjV5lvBFYBpxdXwr0Wty1NsDDxqF//e8A 9mug== 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=vvQxqfuWBQciKwhpIarGU400W90ZCuhktLB/QJwN7Bo=; b=aHRebYYMtbkX3VzJOFLR5XY8y1B6y+pjNElY/9Y0WlusAmoNeI3YsR9RP5gl9utsae GgYpdUtlPp8yJ8WPlADUk16GU2/hFX8APu/nrnyedCWbeA9nnOezqZdgJ7394lnerzCk jChtHTvsbiIv3137dY5j7H4ZcPt7zQhsHxTmI5TvxkUi1E82f6Oz7EC3BH9ZOhAOG4n5 md7KYdthN2ej92bp3UzQga7knK0C3nQ7Lym0qh8RmjrU6gz0rrGIli1QMz6cMvnyZFQo gsHcmdb76ij+vmouQv60JTZwSQVo5bI0XTxTx0ttCOznmbmSquZRE+/9zXcP7D48Wqsi pAeg== X-Gm-Message-State: ABuFfojR2jQGplluf3+nD4f5pC3cUWdW5HcU1o3b6QwL58TPw3yw8fb/ 10GuWSlJAV/mRvCEI8Ve0yxreRrNreLJYJRj5nm79w== X-Google-Smtp-Source: ACcGV62WIfXVRIeoF3Ehkz2Q79a25KWE+L4hiGGvb5ChnhpXW7XtiikUoi7X7tzmC2YoIHsj4OlrThwPOLSZ3/FDu70= X-Received: by 2002:a1f:2d07:: with SMTP id t7mr12662343vkt.45.1540306475850; Tue, 23 Oct 2018 07:54:35 -0700 (PDT) MIME-Version: 1.0 References: <79973E2B-F5C4-4E7C-B92B-1C8D4441C7D1@yahoo.com> <3CA4C94F-A062-44FE-B507-948A6F88C83D@me.com> <18e270f6-c811-3f5e-bf65-76c895782c8f@FreeBSD.org> <7B44DEC3-9E79-46E0-BC02-E6C95680BF77@me.com> In-Reply-To: <7B44DEC3-9E79-46E0-BC02-E6C95680BF77@me.com> From: Warner Losh Date: Tue, 23 Oct 2018 08:54:24 -0600 Message-ID: Subject: Re: loader lsdev crashes loader (Was: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated) To: Toomas Soome Cc: Lev Serebryakov , Mark Millard , Konstantin Belousov , FreeBSD Current , FreeBSD-STABLE Mailing List 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: Tue, 23 Oct 2018 14:54:37 -0000 On Tue, Oct 23, 2018 at 5:54 AM Toomas Soome wrote: > > > On 23 Oct 2018, at 13:53, Lev Serebryakov wrote: > > > > On 22.10.2018 12:27, Toomas Soome wrote: > > > >> It would help to get output from loader lsdev -v command. > > current loader crashes on "lsdev" for me: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D232483 (it is not > > threadripper-related, my hardware is Intel Atom). > > > > -- > > // Lev Serebryakov > > > > That error means something is corrupting the memory, it is hard to guess > what exactly and debugging it is nasty - it means we would need to track > down what was allocated before this memory block (guard1 is marker insert= ed > in front of the allocated memory block). > > Fortunately the code to print the partition table is in > stand/common/disk.c and the partition code is just next to it and so it > should be relatively easy to find the guilty one=E2=80=A6 I will try to s= ee if I > can replicate the issue. > We've had reports of other systems mysteriously hanging on boot with the new boot loader, but not older ones. It isn't limited to new AMD boxes, but it's been seen on other Intel boxes of various flavors. When we crash, it seems like we don't have a good recovery like we do with BTX. Maybe they are related? Warner From owner-freebsd-stable@freebsd.org Tue Oct 23 15:16:51 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 13F06FE9488; Tue, 23 Oct 2018 15:16:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 9394B816BA; Tue, 23 Oct 2018 15:16:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w9NFGeIP062271 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 23 Oct 2018 18:16:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w9NFGeIP062271 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w9NFGe0A062270; Tue, 23 Oct 2018 18:16:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 23 Oct 2018 18:16:39 +0300 From: Konstantin Belousov To: Warner Losh Cc: Toomas Soome , Lev Serebryakov , Mark Millard , Konstantin Belousov , FreeBSD Current , FreeBSD-STABLE Mailing List Subject: Re: loader lsdev crashes loader (Was: head -r338804 boots threadripper 1950X fine; head -r338810+ do not; -r338807 seems implicated) Message-ID: <20181023151639.GX5335@kib.kiev.ua> References: <79973E2B-F5C4-4E7C-B92B-1C8D4441C7D1@yahoo.com> <3CA4C94F-A062-44FE-B507-948A6F88C83D@me.com> <18e270f6-c811-3f5e-bf65-76c895782c8f@FreeBSD.org> <7B44DEC3-9E79-46E0-BC02-E6C95680BF77@me.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home 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, 23 Oct 2018 15:16:51 -0000 On Tue, Oct 23, 2018 at 08:54:24AM -0600, Warner Losh wrote: > On Tue, Oct 23, 2018 at 5:54 AM Toomas Soome wrote: > > > > > > On 23 Oct 2018, at 13:53, Lev Serebryakov wrote: > > > > > > On 22.10.2018 12:27, Toomas Soome wrote: > > > > > >> It would help to get output from loader lsdev -v command. > > > current loader crashes on "lsdev" for me: > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232483 (it is not > > > threadripper-related, my hardware is Intel Atom). > > > > > > -- > > > // Lev Serebryakov > > > > > > > That error means something is corrupting the memory, it is hard to guess > > what exactly and debugging it is nasty - it means we would need to track > > down what was allocated before this memory block (guard1 is marker inserted > > in front of the allocated memory block). > > > > Fortunately the code to print the partition table is in > > stand/common/disk.c and the partition code is just next to it and so it > > should be relatively easy to find the guilty one… I will try to see if I > > can replicate the issue. > > > > We've had reports of other systems mysteriously hanging on boot with the > new boot loader, but not older ones. It isn't limited to new AMD boxes, but > it's been seen on other Intel boxes of various flavors. When we crash, it > seems like we don't have a good recovery like we do with BTX. Maybe they > are related? There is the 'grab_faults' command which might be used to get information about the fault (as in, CPU fault due to the programming mistake). You need to issue it before doing something that can cause the fault. It is not enabled by default due to the methods it uses to catch the exceptions. I recently noted that at least UEFI 2.7 provides debugging interfaces which can be used to achieve the same fault interception effect without hacks. From owner-freebsd-stable@freebsd.org Tue Oct 23 21:34:24 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 079BEFFD847; Tue, 23 Oct 2018 21:34:24 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "land.berklix.org", Issuer "land.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7FBD0714B1; Tue, 23 Oct 2018 21:34:23 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p2E52CCDC.dip0.t-ipconnect.de [46.82.204.220]) (authenticated bits=0) by land.berklix.org (8.15.2/8.15.2) with ESMTPSA id w9NLYBMr035171 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Oct 2018 21:34:19 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id w9NLY5Fb036818; Tue, 23 Oct 2018 23:34:05 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id w9NLXZXh080416; Tue, 23 Oct 2018 23:33:47 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <201810232133.w9NLXZXh080416@fire.js.berklix.net> To: Warner Losh cc: Ian Lepore , FreeBSD Net , freebsd-fcp@freebsd.org, FreeBSD-STABLE Mailing List , michelle@sorbs.net, "freebsd-arch@freebsd.org" Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers From: "Julian H. Stacey" Organization: http://berklix.eu BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.eu/free/ X-From: http://www.berklix.eu/~jhs/ In-reply-to: Your message "Thu, 04 Oct 2018 11:38:46 -0600." Date: Tue, 23 Oct 2018 23:33:35 +0200 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, 23 Oct 2018 21:34:24 -0000 > I'd also suggest that rl stands in stark contrast to the cs, wb, sn, smc, > sf, tl, tx and vr drivers, which nobody has mentioned in this thread, and > which I doubt are in use in any FreeBSD system of any age today. vr is used by my TV driver laptop: http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/ vr0: flags=8843 metric 0 mtu 1500 options=82808 ether 00:40:d0:5e:26:38 inet 192.168.91.65 netmask 0xffffff00 broadcast 192.168.91.255 media: Ethernet autoselect (100baseTX ) status: active Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade soon when I also configure it to receive from a raspberry-pi TV VPN server. Cheers, Julian -- Julian Stacey, Computer Consultant, Systems Engineer, BSD Linux Unix, Munich. Brexit referendum stole 3,700,000 Brits votes abroad, inc. 700,000 in EU. Campaign lies, criminal funding, economy & pound down. Time for an honest ref. http://exitbrexit.uk https://www.peoples-vote.uk/petition https://eci.ec.europa.eu/002/public/#/initiative From owner-freebsd-stable@freebsd.org Tue Oct 23 21:55:58 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D103FFE6E6; Tue, 23 Oct 2018 21:55:58 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "land.berklix.org", Issuer "land.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BD755727CC; Tue, 23 Oct 2018 21:55:57 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p2E52CCDC.dip0.t-ipconnect.de [46.82.204.220]) (authenticated bits=0) by land.berklix.org (8.15.2/8.15.2) with ESMTPSA id w9NLtpBd035703 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Oct 2018 21:55:56 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id w9NLtkOJ036954; Tue, 23 Oct 2018 23:55:46 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id w9NLtM4Y080783; Tue, 23 Oct 2018 23:55:40 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <201810232155.w9NLtM4Y080783@fire.js.berklix.net> To: Doug Hardie cc: Brooks Davis , freebsd-net@freebsd.org, freebsd-fcp@freebsd.org, freebsd-stable@freebsd.org, freebsd-arch@freebsd.org Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers From: "Julian H. Stacey" Organization: http://berklix.eu BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.eu/free/ X-From: http://www.berklix.eu/~jhs/ In-reply-to: Your message "Thu, 04 Oct 2018 12:54:28 -0700." <15FCEA6B-C017-40C5-8193-8C7AA3F563CC@mail.sermon-archive.info> Date: Tue, 23 Oct 2018 23:55:22 +0200 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, 23 Oct 2018 21:55:58 -0000 Doug Hardie wrote: > I have a number of production servers that only have bge and I don't see that listed in either category. None of them are running FreeBSD 12 yet as it has not been released. Also there are some with rl. Those are add-on boards so they could be changed, but would require extensive effort as the machines are about a 4 hour drive from here and would require reconfiguration (an error prone process when you are tired). bge is also used by my main laptop with current Oct 15 18:33 /boot/kernel/kernel bge0: flags=8843 metric 0 mtu 1500 options=c019b media: Ethernet autoselect (1000baseT ) Doug, I think bge must be safe as man 4 bge: "bge - Broadcom BCM57xx/BCM590x Gigabit/Fast Ethernet driver" & Brooks proposal was ... "a plan to deprecate most 10/100 Ethernet drivers" Cheers, Julian -- Julian Stacey, Computer Consultant, Systems Engineer, BSD Linux Unix, Munich. Brexit referendum stole 3,700,000 Brits votes abroad, inc. 700,000 in EU. Campaign lies, criminal funding, economy & pound down. Time for an honest ref. http://exitbrexit.uk https://www.peoples-vote.uk/petition https://eci.ec.europa.eu/002/public/#/initiative From owner-freebsd-stable@freebsd.org Tue Oct 23 22:10:39 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7591EFFED72; Tue, 23 Oct 2018 22:10:39 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 1E4E57301B; Tue, 23 Oct 2018 22:10:39 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 7D74E3C475F; Tue, 23 Oct 2018 22:10:37 +0000 (UTC) Date: Tue, 23 Oct 2018 22:10:37 +0000 From: Brooks Davis To: "Julian H. Stacey" Cc: Warner Losh , FreeBSD-STABLE Mailing List , Ian Lepore , FreeBSD Net , michelle@sorbs.net, "freebsd-arch@freebsd.org" , freebsd-fcp@freebsd.org Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers Message-ID: <20181023221037.GA14128@spindle.one-eyed-alien.net> References: <201810232133.w9NLXZXh080416@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline In-Reply-To: <201810232133.w9NLXZXh080416@fire.js.berklix.net> User-Agent: Mutt/1.9.4 (2018-02-28) 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, 23 Oct 2018 22:10:39 -0000 --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote: > > I'd also suggest that rl stands in stark contrast to the cs, wb, sn, sm= c, > > sf, tl, tx and vr drivers, which nobody has mentioned in this thread, a= nd > > which I doubt are in use in any FreeBSD system of any age today. >=20 > vr is used by my TV driver laptop: > http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/ > vr0: flags=3D8843 metric 0 mtu 15= 00 > options=3D82808 > ether 00:40:d0:5e:26:38 > inet 192.168.91.65 netmask 0xffffff00 broadcast 192.168.91.255 > media: Ethernet autoselect (100baseTX ) > status: active >=20 > Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade soon > when I also configure it to receive from a raspberry-pi TV VPN server. The above was a typo. vr is on the the STAY list. -- Brooks --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJbz5xcAAoJEKzQXbSebgfAZmgH/R214Fn1RLCeGjvi0YbYJqNV 0hO3MPfXkcH+9Jw70egbvCpbuKxnoMkzNBfiXjh7cDUHMapMpni2Av3e0X0vEm1Z 3M7TMa7nC+7oIHNNbu4zD1a9cwgQO1EnWBWPy/FiWAxpYHT32lzvpdT7PdaTcJCL Wjig4jk6qK4qQgo02z+PF1wOT2VVdXqBuZFx3HrzVsOd/QAVhYk5AhtLe/7yn3LZ mZA5e/6qqsLk1h+xMsT+I9gLA1idYXBgUzoMTLzU3OsjJhxLYWq9YGIStQPr/Tve 1avsoo+VAyNwXWhS5zYk1iW1rKeLq6M7T6m5ERvDVS0Uo0JInzAFEI3H+9mKk7Q= =Cq3G -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- From owner-freebsd-stable@freebsd.org Tue Oct 23 22:14:26 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5050FFF215; Tue, 23 Oct 2018 22:14:26 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "land.berklix.org", Issuer "land.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 607C8735C5; Tue, 23 Oct 2018 22:14:26 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p2E52CCDC.dip0.t-ipconnect.de [46.82.204.220]) (authenticated bits=0) by land.berklix.org (8.15.2/8.15.2) with ESMTPSA id w9NMEIFA036300 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Oct 2018 22:14:22 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id w9NMEDc2037173; Wed, 24 Oct 2018 00:14:13 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id w9NMDhCW081823; Wed, 24 Oct 2018 00:13:55 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <201810232213.w9NMDhCW081823@fire.js.berklix.net> To: Brooks Davis cc: Warner Losh , FreeBSD-STABLE Mailing List , Ian Lepore , FreeBSD Net , michelle@sorbs.net, "freebsd-arch@freebsd.org" , freebsd-fcp@freebsd.org Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers From: "Julian H. Stacey" Organization: http://berklix.eu BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.eu/free/ X-From: http://www.berklix.eu/~jhs/ In-reply-to: Your message "Tue, 23 Oct 2018 22:10:37 -0000." <20181023221037.GA14128@spindle.one-eyed-alien.net> Date: Wed, 24 Oct 2018 00:13:43 +0200 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, 23 Oct 2018 22:14:27 -0000 Hi, Reference: > From: Brooks Davis > Date: Tue, 23 Oct 2018 22:10:37 +0000 Brooks Davis wrote: > > --lrZ03NoBR/3+SXJZ > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote: > > > I'd also suggest that rl stands in stark contrast to the cs, wb, sn, sm= > c, > > > sf, tl, tx and vr drivers, which nobody has mentioned in this thread, a= > nd > > > which I doubt are in use in any FreeBSD system of any age today. > >=20 > > vr is used by my TV driver laptop: > > http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/ > > vr0: flags=3D8843 metric 0 mtu 15= > 00 > > options=3D82808 > > ether 00:40:d0:5e:26:38 > > inet 192.168.91.65 netmask 0xffffff00 broadcast 192.168.91.255 > > media: Ethernet autoselect (100baseTX pause,txpause>) > > status: active > >=20 > > Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade soon > > when I also configure it to receive from a raspberry-pi TV VPN server. > > The above was a typo. vr is on the the STAY list. Great, Thanks. Cheers, Julian -- Julian Stacey, Computer Consultant, Systems Engineer, BSD Linux Unix, Munich. Brexit referendum stole 3,700,000 Brits votes abroad, inc. 700,000 in EU. Campaign lies, criminal funding, economy & pound down. Time for an honest ref. http://exitbrexit.uk https://www.peoples-vote.uk/petition https://eci.ec.europa.eu/002/public/#/initiative From owner-freebsd-stable@freebsd.org Tue Oct 23 23:06:52 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ACB051008A08; Tue, 23 Oct 2018 23:06:52 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 0B236752B9; Tue, 23 Oct 2018 23:06:51 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w9NN6nsO024522; Tue, 23 Oct 2018 16:06:49 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w9NN6mG8024521; Tue, 23 Oct 2018 16:06:48 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201810232306.w9NN6mG8024521@pdx.rh.CN85.dnsmgr.net> Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers In-Reply-To: <20181023221037.GA14128@spindle.one-eyed-alien.net> To: Brooks Davis Date: Tue, 23 Oct 2018 16:06:48 -0700 (PDT) CC: "Julian H. Stacey" , FreeBSD-STABLE Mailing List , Ian Lepore , FreeBSD Net , michelle@sorbs.net, "freebsd-arch@freebsd.org" , freebsd-fcp@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII 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, 23 Oct 2018 23:06:52 -0000 > On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote: > > > I'd also suggest that rl stands in stark contrast to the cs, wb, sn, smc, > > > sf, tl, tx and vr drivers, which nobody has mentioned in this thread, and > > > which I doubt are in use in any FreeBSD system of any age today. > > > > vr is used by my TV driver laptop: > > http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/ > > vr0: flags=8843 metric 0 mtu 1500 > > options=82808 > > ether 00:40:d0:5e:26:38 > > inet 192.168.91.65 netmask 0xffffff00 broadcast 192.168.91.255 > > media: Ethernet autoselect (100baseTX ) > > status: active > > > > Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade soon > > when I also configure it to receive from a raspberry-pi TV VPN server. > > The above was a typo. vr is on the the STAY list. > > -- Brooks Brooks, Is there a public revised version of FCP-0101 that reflects the feedback which is what core is voting on? -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-stable@freebsd.org Tue Oct 23 23:10:00 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10AAA1008C75 for ; Tue, 23 Oct 2018 23:10:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 999FC754C3 for ; Tue, 23 Oct 2018 23:09:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe34.google.com with SMTP id q15so1998225vso.1 for ; Tue, 23 Oct 2018 16:09:59 -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=ZpJHsI4M/7F1nqGYsIixOnRMHRX8ACltgTe71EUAE2o=; b=gKylTv6E0BrhVUtHLWKvpgUj9eQ9jocS3DPRFfCEjCogeiuCQ/FP6B20b8vQ01bhXh jO11jWdP5J2uVOxBiwY3dyMwaYvmGUmEqKVW42oxrQgOw6ymeTMsxOmwyQOVOxXEcq+N EWY0fSAXbAPiPEyZdvnzYhvZgq4FxP0D1MrQ/Upg2YmDAnWNbKbZGVs+IyPDX7NUfwJG 0Cadmw/GMho2xDW/t7JrVfSk0oYICwrPy46nkyObTguWJd8nKKXDBgKWa+YnEIpylTY9 WgMR8s8qk210KXbN/Re/5AYypMC5DW5zH3R+cUgrNxJvxlGeMif9GqfM0KKcbRzV9XvB vRrQ== 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=ZpJHsI4M/7F1nqGYsIixOnRMHRX8ACltgTe71EUAE2o=; b=WBoEmCHHJlXvkJ+s1auxk11AkCHZL21JPVnH/0VIZWBddYXqMt5LAUv/c5f8+ww6qE XawP20bMJi7V0g24bTGHjtLect1fMUakInvFnCZs1TFNXbYFwqpInpfSyy5LIScDVd27 6mupK9dtWFxb97ymjTRSgeH8nfH1B5vC7w3sUgMbHUMHxR1cbO6lf4HH9NrpGxdXNuHj HZUqPvJar2PLoJpl0NMBQP1Xw2EPSZcq/7rwdNjdVS3nILeYv7vcM2x9Z2BKyg2QfcgA va6OTByMMmJ1o/cUKt5VDVDmenmxNhpC+rim4yzS9OEqwbAfMakPXgVKwQEpNLGlV9+D h3Nw== X-Gm-Message-State: AGRZ1gJSYEKoL5D3oQSBnGsDa7wW56lk0PwUTgm6Yj86hGx2BmVrgWSn xtnfKv24ZN2jY+/Ezk3ERdiCqtiLGt97Qlb6Z0iI9w== X-Google-Smtp-Source: AJdET5dOo8geCkuGvJNx7df3RNHP5t85xsnNR3e97/+2ic+JcQC+0GStw45an2hLhtgy04qrXeQMpSMx/U9pBpfdvpE= X-Received: by 2002:a67:4dc7:: with SMTP id i68mr128662vsg.46.1540336198661; Tue, 23 Oct 2018 16:09:58 -0700 (PDT) MIME-Version: 1.0 References: <20181023221037.GA14128@spindle.one-eyed-alien.net> <201810232306.w9NN6mG8024521@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201810232306.w9NN6mG8024521@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Tue, 23 Oct 2018 17:09:47 -0600 Message-ID: Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers To: "Rodney W. Grimes" Cc: Brooks Davis , FreeBSD-STABLE Mailing List , Ian Lepore , FreeBSD Net , "Julian H. Stacey" , Michelle Sullivan , "freebsd-arch@freebsd.org" , freebsd-fcp@freebsd.org 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: Tue, 23 Oct 2018 23:10:00 -0000 On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote: > > > > I'd also suggest that rl stands in stark contrast to the cs, wb, sn, > smc, > > > > sf, tl, tx and vr drivers, which nobody has mentioned in this > thread, and > > > > which I doubt are in use in any FreeBSD system of any age today. > > > > > > vr is used by my TV driver laptop: > > > http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/ > > > vr0: flags=8843 metric 0 mtu > 1500 > > > options=82808 > > > ether 00:40:d0:5e:26:38 > > > inet 192.168.91.65 netmask 0xffffff00 broadcast 192.168.91.255 > > > media: Ethernet autoselect (100baseTX > ) > > > status: active > > > > > > Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade soon > > > when I also configure it to receive from a raspberry-pi TV VPN server. > > > > The above was a typo. vr is on the the STAY list. > > > > -- Brooks > Brooks, > Is there a public revised version of FCP-0101 that reflects the > feedback which is what core is voting on? > Its on github, just like it's been the whole time for anybody to see, submit pull requests against and track: https://github.com/freebsd/fcp/blob/master/fcp-0101.md Warner From owner-freebsd-stable@freebsd.org Tue Oct 23 23:11:07 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 54BA21008E05 for ; Tue, 23 Oct 2018 23:11:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com [IPv6:2607:f8b0:4864:20::a30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A807175703 for ; Tue, 23 Oct 2018 23:11:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa30.google.com with SMTP id j20so789394vke.5 for ; Tue, 23 Oct 2018 16:11:06 -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=XTYvAUUeKAKgCsvrWbJ7+kLqOs8Fq1XBw7kIcWF3jEk=; b=BQBCq7TJWKtiiRHPc4i0DuHLCphru70IXgcEW+KqXtC+A7g3WfW6+jcgzE92dn3ki/ vohNgXgpgCKzNdZTw85DSw0FiTqKp+mo8oWeCnkZmsgY2Mt8mRV3loK+leuame2LB7H3 rX+j1UZpyO+7/8CBzPiCBWifbdp0UEL8+DbPnEfSTORBCBj4ihToMrp+kSaQ2dacKhFe fvhYwEnTEN9ApIGy0lTb3OgfQs81TWo6pJyS0GN3S7JLDuC1FKpAs6kAYVpqOtYHzwVb iMZdNl3x+0ub5vzfqlLxK+5t0yb/wUK+DwdSZEW8tz7lEy16QaYwA9jhQ0CJH0mA737D AoXw== 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=XTYvAUUeKAKgCsvrWbJ7+kLqOs8Fq1XBw7kIcWF3jEk=; b=m//MN4mYJhIuh8V9UzYuvEfuY5SaFTdjVAr3b76jQHBNzL8ubjEojQYt+2XI/+EOw3 XLqNO4ALm6sl9gNN3YQFRHXDEXiL3bodMDzcrz95O5Cat5k6a94vE9I3ZsYQ/W+7bNXc 5LQgMhyFS7vEXcJSF3XMhZmOJNz0ck4pGDmnE+cOCZqTfKhvMz6rdjMApPEbv9iSqDRe JFEb8dz02WBdHlXjk7BQZW+Y/L5Jq44fFrqeDJzqeKkJIYj+fWpKt6/aKC1vLap5pL29 XmETXpU3e8hW/xUyqlZbmgKJRo4voNyKvyA/OHioPVKexW3IgZdBXtKyrZh5GbtkjYj8 T3QA== X-Gm-Message-State: AGRZ1gIaOq/Z1cPtU4EZpfzN5GzRa5lB1OetgSsJOGyX+PpgSvRp7XGE zkq/nNPPFm3wStzpuvlEB1J7Bj2+He2DdRkn+i/ZZw== X-Google-Smtp-Source: AJdET5fmkXu0yxS0QqOmkMLS/zBfhZ99AzjvjMCSYZy0FY32znG5ZHH3Aawnis+F22Q/dfkkXT0RYuxRr1WuTlorljg= X-Received: by 2002:a1f:d803:: with SMTP id p3mr122934vkg.9.1540336265884; Tue, 23 Oct 2018 16:11:05 -0700 (PDT) MIME-Version: 1.0 References: <15FCEA6B-C017-40C5-8193-8C7AA3F563CC@mail.sermon-archive.info> <201810232155.w9NLtM4Y080783@fire.js.berklix.net> In-Reply-To: <201810232155.w9NLtM4Y080783@fire.js.berklix.net> From: Warner Losh Date: Tue, 23 Oct 2018 17:10:54 -0600 Message-ID: Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers To: "Julian H. Stacey" Cc: bc979@lafn.org, freebsd-fcp@freebsd.org, FreeBSD Net , Brooks Davis , FreeBSD-STABLE Mailing List , "freebsd-arch@freebsd.org" 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: Tue, 23 Oct 2018 23:11:07 -0000 On Tue, Oct 23, 2018 at 3:57 PM Julian H. Stacey wrote: > Doug Hardie wrote: > > I have a number of production servers that only have bge and I don't see > that listed in either category. None of them are running FreeBSD 12 yet as > it has not been released. Also there are some with rl. Those are add-on > boards so they could be changed, but would require extensive effort as the > machines are about a 4 hour drive from here and would require > reconfiguration (an error prone process when you are tired). > > bge is also used by my main laptop with current Oct 15 18:33 > /boot/kernel/kernel > > bge0: flags=8843 metric 0 mtu 1500 > > options=c019b > media: Ethernet autoselect (1000baseT ) > > Doug, I think bge must be safe as man 4 bge: > "bge - Broadcom BCM57xx/BCM590x Gigabit/Fast Ethernet driver" > & Brooks proposal was ... "a plan to deprecate most 10/100 Ethernet > drivers" > Indeed. https://github.com/freebsd/fcp/blob/master/fcp-0101.md shows bge is not on the list to go. Warner From owner-freebsd-stable@freebsd.org Tue Oct 23 23:11:33 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DCA3C1008EDF; Tue, 23 Oct 2018 23:11:33 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 27553757D0; Tue, 23 Oct 2018 23:11:33 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 2F5453C475F; Tue, 23 Oct 2018 23:11:32 +0000 (UTC) Date: Tue, 23 Oct 2018 23:11:32 +0000 From: Brooks Davis To: "Rodney W. Grimes" Cc: Brooks Davis , "Julian H. Stacey" , FreeBSD-STABLE Mailing List , Ian Lepore , FreeBSD Net , michelle@sorbs.net, "freebsd-arch@freebsd.org" , freebsd-fcp@freebsd.org Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers Message-ID: <20181023231132.GA14827@spindle.one-eyed-alien.net> References: <20181023221037.GA14128@spindle.one-eyed-alien.net> <201810232306.w9NN6mG8024521@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline In-Reply-To: <201810232306.w9NN6mG8024521@pdx.rh.CN85.dnsmgr.net> User-Agent: Mutt/1.9.4 (2018-02-28) 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, 23 Oct 2018 23:11:34 -0000 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 23, 2018 at 04:06:48PM -0700, Rodney W. Grimes wrote: > > On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote: > > > > I'd also suggest that rl stands in stark contrast to the cs, wb, sn= , smc, > > > > sf, tl, tx and vr drivers, which nobody has mentioned in this threa= d, and > > > > which I doubt are in use in any FreeBSD system of any age today. > > >=20 > > > vr is used by my TV driver laptop: > > > http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/ > > > vr0: flags=3D8843 metric 0 mt= u 1500 > > > options=3D82808 > > > ether 00:40:d0:5e:26:38 > > > inet 192.168.91.65 netmask 0xffffff00 broadcast 192.168.91.255 > > > media: Ethernet autoselect (100baseTX ) > > > status: active > > >=20 > > > Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade soon > > > when I also configure it to receive from a raspberry-pi TV VPN server. > >=20 > > The above was a typo. vr is on the the STAY list. > >=20 > > -- Brooks > Brooks, > Is there a public revised version of FCP-0101 that reflects the > feedback which is what core is voting on? https://github.com/freebsd/fcp/blob/master/fcp-0101.md has been updated throughout the feedback process as drivers were moved to the STAY list, errors were found, etc. It also contains a summary of responses and the hard data we have. -- Brooks --DocE+STaALJfprDB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJbz6qjAAoJEKzQXbSebgfAUUEIAJTSlTLrA81440KDSciYlMbI mBLQbmu+un/RxKmYBklC8XCnHQRSTrtgIbONEL+HxjVUMAj3x9VWfIOy5NGF2nlA uEJa4NES0Yv1vgNobhNQm3ht5Z7Z1raKBVwGyqpL775x2ZX3ZQtn44MBCk/f7N6r iTtoyjKRGxKzOrZffNf1jsF+hdO1W4Y709Fw44/XxianK5vP6qaE9wP1PaaVhW6s XxrRI2TSHrJOC1raFKO6jDvRaBssGWSVhLIa+ErSiMIL3D8OwcgRY7gxNRhDGVb9 7NvIEcKHMQHqF9B1fqoPangqdRZBfF2PnHgK/uUy1FXsDXIyLj2J6jXCzp71P2s= =XG9T -----END PGP SIGNATURE----- --DocE+STaALJfprDB-- From owner-freebsd-stable@freebsd.org Tue Oct 23 23:26:50 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 422691036A8E; Tue, 23 Oct 2018 23:26:50 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 80B927678E; Tue, 23 Oct 2018 23:26:49 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w9NNQjFQ024760; Tue, 23 Oct 2018 16:26:45 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w9NNQjtK024759; Tue, 23 Oct 2018 16:26:45 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201810232326.w9NNQjtK024759@pdx.rh.CN85.dnsmgr.net> Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers In-Reply-To: To: Warner Losh Date: Tue, 23 Oct 2018 16:26:45 -0700 (PDT) CC: Brooks Davis , FreeBSD-STABLE Mailing List , Ian Lepore , FreeBSD Net , "Julian H. Stacey" , Michelle Sullivan , "freebsd-arch@freebsd.org" , freebsd-fcp@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII 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, 23 Oct 2018 23:26:50 -0000 > On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes < > freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > > > On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote: > > > > > I'd also suggest that rl stands in stark contrast to the cs, wb, sn, > > smc, > > > > > sf, tl, tx and vr drivers, which nobody has mentioned in this > > thread, and > > > > > which I doubt are in use in any FreeBSD system of any age today. > > > > > > > > vr is used by my TV driver laptop: > > > > http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/ > > > > vr0: flags=8843 metric 0 mtu > > 1500 > > > > options=82808 > > > > ether 00:40:d0:5e:26:38 > > > > inet 192.168.91.65 netmask 0xffffff00 broadcast 192.168.91.255 > > > > media: Ethernet autoselect (100baseTX > > ) > > > > status: active > > > > > > > > Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade soon > > > > when I also configure it to receive from a raspberry-pi TV VPN server. > > > > > > The above was a typo. vr is on the the STAY list. > > > > > > -- Brooks > > Brooks, > > Is there a public revised version of FCP-0101 that reflects the > > feedback which is what core is voting on? > > > > Its on github, just like it's been the whole time for anybody to see, > submit pull requests against and track: I have no gh account, desires no gh account, so have no way to submit a change request other than through direct email to brooks or another gh user. This is fundementally flawed. > https://github.com/freebsd/fcp/blob/master/fcp-0101.md Thank you for the link, I had looked at it before MeetBSD, which did not have most of the recent changes done "a day ago". Isnt this document now in a frozen state while core reviews/votes? -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-stable@freebsd.org Wed Oct 24 00:03:02 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79F0B1037A30; Wed, 24 Oct 2018 00:03:02 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 00D42777FB; Wed, 24 Oct 2018 00:03:01 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w9O02uxp025020; Tue, 23 Oct 2018 17:02:56 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w9O02tXg025019; Tue, 23 Oct 2018 17:02:55 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201810240002.w9O02tXg025019@pdx.rh.CN85.dnsmgr.net> Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers In-Reply-To: <20181023233716.GA15106@spindle.one-eyed-alien.net> To: Brooks Davis Date: Tue, 23 Oct 2018 17:02:55 -0700 (PDT) CC: Warner Losh , FreeBSD-STABLE Mailing List , Ian Lepore , FreeBSD Net , "Julian H. Stacey" , Michelle Sullivan , "freebsd-arch@freebsd.org" , freebsd-fcp@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII 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, 24 Oct 2018 00:03:02 -0000 -- Start of PGP signed section. > On Tue, Oct 23, 2018 at 04:26:45PM -0700, Rodney W. Grimes wrote: > > > On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes < > > > freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > > > On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote: > > > > > > > I'd also suggest that rl stands in stark contrast to the cs, wb, sn, > > > > smc, > > > > > > > sf, tl, tx and vr drivers, which nobody has mentioned in this > > > > thread, and > > > > > > > which I doubt are in use in any FreeBSD system of any age today. > > > > > > > > > > > > vr is used by my TV driver laptop: > > > > > > http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/ > > > > > > vr0: flags=8843 metric 0 mtu > > > > 1500 > > > > > > options=82808 > > > > > > ether 00:40:d0:5e:26:38 > > > > > > inet 192.168.91.65 netmask 0xffffff00 broadcast 192.168.91.255 > > > > > > media: Ethernet autoselect (100baseTX > > > > ) > > > > > > status: active > > > > > > > > > > > > Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade soon > > > > > > when I also configure it to receive from a raspberry-pi TV VPN server. > > > > > > > > > > The above was a typo. vr is on the the STAY list. > > > > > > > > > > -- Brooks > > > > Brooks, > > > > Is there a public revised version of FCP-0101 that reflects the > > > > feedback which is what core is voting on? > > > > > > > > > > Its on github, just like it's been the whole time for anybody to see, > > > submit pull requests against and track: > > > > I have no gh account, desires no gh account, so have no way to > > submit a change request other than through direct email to > > brooks or another gh user. This is fundementally flawed. > > > > > https://github.com/freebsd/fcp/blob/master/fcp-0101.md > > > > Thank you for the link, I had looked at it before MeetBSD, > > which did not have most of the recent changes done "a day ago". > > > > Isnt this document now in a frozen state while core reviews/votes? > > I sent it to a vote at c224c67557297d7cba909ad008542cb60980cc6b only > to notice a bug in table rendering. I submitted a pull request fix > that and a missing word which was merged since neither was material. I > suppose they could have waited or been skipped, but there's no value in > the FCP process being bound by the sort of pointless rigidity that led > to -DPOSIX_MISTAKE in every libc compile line. The FCP process itself is unclear on this point, I think this should be clarified. It is much more clear on post approval: Changes after acceptance FCPs may need revision after they have been moved into the accepted state. In such cases, the author SHOULD update the FCP to reflect the final conclusions. If the changes are major, the FCP SHOULD be withdrawn and restarted. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-stable@freebsd.org Wed Oct 24 00:04:52 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EC3951037CDD for ; Wed, 24 Oct 2018 00:04:51 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DFF9577A36 for ; Wed, 24 Oct 2018 00:04:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2d.google.com with SMTP id l186so815051vke.0 for ; Tue, 23 Oct 2018 17:04:50 -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=HL9+HPYGeQgvgzfdIkooQvpdti3UDljW1vYu7T7v8gg=; b=ZQEsVQyt/tBqmo9KSS9Qy5GxVbWyaGO14qcFSOa+toTgHeSdckI73cZvvmrLq/SRCt Yyx8UK+4KWMhlZCF7yCQAk8bjeH0rArU+UbAWZ86lL2uBRCMZvUGOlWeL1MdJGLPaEeW jVpVnFQOiiHrjgJSvypTNU9D4/+Lcp1j8/qr0tRomm/jls/9/tl2pzxHPnL7h3fzE5ew zyYq45NbNwUl0smaHwzzQOroJrsEBRzxKXmRT8aAC0oOJZy4mtHUmoEFVEMGiUxSlrG3 OUmZ+SSCiTqWDEpe0uMtPU7rx6LjZXw1vhL0MS78Om4z1GedOw++OmRhIRxYSsniFLef 1CJg== 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=HL9+HPYGeQgvgzfdIkooQvpdti3UDljW1vYu7T7v8gg=; b=ozFGOX+1TQAudh+QH1HZNtaM5xKEApytP6oN13n0Xcsr6Jme1cRxU0Oh3rBXgjSsd9 r6a9mD66/YryzOaQpuMP9A4w0rU573JOqGUod/9zt+JPi8Yh5WZcMQvp1OgCXHg3OH2S U0Pg5mAYWqd+30UYVlarOohO/a6A3ZtMXDBEZAQBixPwqkPY6BL66YDXX6Sc7zJv6vYF DQ4h1Bna0uFcSp0QA96pXYgetHmNWrTSRvLyB2BRT6zrgPXdHfeV3xMpJbsySGTKCyb3 SALFIZGb1mY1zEcD0N1u3LlvW0haM7wNXbqI7rYQiTPoWJX0+fwtwx2AQjHK1q4LJRr5 aSPQ== X-Gm-Message-State: AGRZ1gJL425nYhekD+97yCFSh5Tkv8GtU2qVlDGEMOzDJATo3Or0c/qG sh/q6ErY7uRS4c1FxeDo8Z/Th/HdcO0IobTt+joXJw== X-Google-Smtp-Source: AJdET5fWey/EJ5M4YXEzYWaPf/lgUdOUEH6m4VIK15pRM/L89W3YDbPIGP+carkF0Toc5l81MbE7u3AYQyXve0MhxUw= X-Received: by 2002:a1f:9255:: with SMTP id u82mr166903vkd.85.1540339490149; Tue, 23 Oct 2018 17:04:50 -0700 (PDT) MIME-Version: 1.0 References: <201810232326.w9NNQjtK024759@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201810232326.w9NNQjtK024759@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Tue, 23 Oct 2018 18:04:38 -0600 Message-ID: Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers To: "Rodney W. Grimes" Cc: Brooks Davis , FreeBSD-STABLE Mailing List , Ian Lepore , FreeBSD Net , "Julian H. Stacey" , Michelle Sullivan , "freebsd-arch@freebsd.org" , freebsd-fcp@freebsd.org 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: Wed, 24 Oct 2018 00:04:52 -0000 On Tue, Oct 23, 2018 at 5:26 PM Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes < > > freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote: > > > > > > I'd also suggest that rl stands in stark contrast to the cs, wb, > sn, > > > smc, > > > > > > sf, tl, tx and vr drivers, which nobody has mentioned in this > > > thread, and > > > > > > which I doubt are in use in any FreeBSD system of any age today. > > > > > > > > > > vr is used by my TV driver laptop: > > > > > http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/ > > > > > vr0: flags=8843 metric 0 > mtu > > > 1500 > > > > > options=82808 > > > > > ether 00:40:d0:5e:26:38 > > > > > inet 192.168.91.65 netmask 0xffffff00 broadcast > 192.168.91.255 > > > > > media: Ethernet autoselect (100baseTX > > > ) > > > > > status: active > > > > > > > > > > Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade soon > > > > > when I also configure it to receive from a raspberry-pi TV VPN > server. > > > > > > > > The above was a typo. vr is on the the STAY list. > > > > > > > > -- Brooks > > > Brooks, > > > Is there a public revised version of FCP-0101 that reflects the > > > feedback which is what core is voting on? > > > > > > > Its on github, just like it's been the whole time for anybody to see, > > submit pull requests against and track: > > I have no gh account, desires no gh account, so have no way to > submit a change request other than through direct email to > brooks or another gh user. This is fundementally flawed. > The fcp process was officially approved by core.9. You can make suggestions to core for improvements to the process. Lord knows this FCP hasn't been trouble free (though we've learned some valuable lessons). Submissions to the author is always an option should you choose not to use the widely used technology we've chosen to automate this process. Some FreeBSD users don't have accounts, however, many non-developers have github accounts and I think it's a reasonable way to do outreach to the larger community w/o requiring everybody to get a freebsd account (since they are already likely to have a github account, and if not they are trivial to get). So yea, it's a flawed process, and we'd love feedback on actionable items we can do to make it better. Warner From owner-freebsd-stable@freebsd.org Wed Oct 24 00:24:07 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48365103929B for ; Wed, 24 Oct 2018 00:24:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C7B7E793A5 for ; Wed, 24 Oct 2018 00:24:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2f.google.com with SMTP id c10so2086083vsk.2 for ; Tue, 23 Oct 2018 17:24:06 -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=SS4/vRIDN3nSI7h+BewXYbgGlXMEHgS4+tsxfZcZHQo=; b=wboELGjzXBDCycqu+LGI0xcQMEOa3yknBp3GRdgC4mu4wFuI5KmWw45JUU4yOuBN79 J4uniRe3obgZ9i/b2b6GLpa2EoLjAD2IPrblIGfC79Pyq+ixNRn0UCf2LC8Hcq/Yiu+n aWE57VypU60eqUkhGAArRHCJ1FKrnA5bOwmQb1o+FXBMmpgyVPb3ZqGDgdD6oQ6gODiR 7o9/iQqsLgJfhThy0bIGnFoTlUuYcqjIWe03BCEcCU5puPqifqkLs/aBeM81SBkO97jI 09Hr+Mz0urUL/Ei8NVnakGe/ySMM5hRYBDHXf+8cTcyN0g0ylfSx0JIXOxmErHr9O+Ow M3lQ== 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=SS4/vRIDN3nSI7h+BewXYbgGlXMEHgS4+tsxfZcZHQo=; b=IdLZqLz4T9MyE7t/MgWznTlwsBN1GxM/UGKvCWO1TRxsQ9mZnHBTAePNfw4cVPg4Dx myLg6+RwIH5BBkunJ1lY2DbmbtsZpubBdeQlhRbW2RUw/ycArb01oayc9uYLBYzsWeNM iOLH4jsDFJgRsZkJsWVi4Mb5FLsIPfutIxJTnix17ICxEbb2A55qB3QxkZwnIf0pQMXc SUcBAf0itGNSn3NqeFWS9oTDu0cRvv2k9S876xfG5m4mEstJaNwremb/9BotFpC87Nho gvQhlbbownLgQyL1kgBjTIRzmMmlE270IY0xFIIZkPzVuenGlQKaFsNFBnL0ESDwWjGx Ns6Q== X-Gm-Message-State: AGRZ1gKIv0ZvSAKAUQuAEXE6Q/ZaGXRkuNPQVrUVpN/RaPAWv7bpHWdS Q2xuRTaX0Q2RBr+yD//y/JT6RuKqMbjnDoVXqjZKYzHM744= X-Google-Smtp-Source: AJdET5fSQRhJXab0fsNki2NiNyF3nK4ySn3P+mjTGaoINWRPvoURpNfTrzDMKbHdyIrJ+HKU9PkbVY6XT7Zn//wsmoo= X-Received: by 2002:a67:4988:: with SMTP id d8mr193821vsg.41.1540340645958; Tue, 23 Oct 2018 17:24:05 -0700 (PDT) MIME-Version: 1.0 References: <20181023233716.GA15106@spindle.one-eyed-alien.net> <201810240002.w9O02tXg025019@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201810240002.w9O02tXg025019@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Tue, 23 Oct 2018 18:23:54 -0600 Message-ID: Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers To: "Rodney W. Grimes" Cc: Brooks Davis , FreeBSD-STABLE Mailing List , Ian Lepore , FreeBSD Net , "Julian H. Stacey" , Michelle Sullivan , "freebsd-arch@freebsd.org" , freebsd-fcp@freebsd.org 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: Wed, 24 Oct 2018 00:24:07 -0000 On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > -- Start of PGP signed section. > > On Tue, Oct 23, 2018 at 04:26:45PM -0700, Rodney W. Grimes wrote: > > > > On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes < > > > > freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > > > > > On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote: > > > > > > > > I'd also suggest that rl stands in stark contrast to the cs, > wb, sn, > > > > > smc, > > > > > > > > sf, tl, tx and vr drivers, which nobody has mentioned in this > > > > > thread, and > > > > > > > > which I doubt are in use in any FreeBSD system of any age > today. > > > > > > > > > > > > > > vr is used by my TV driver laptop: > > > > > > > http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/ > > > > > > > vr0: flags=8843 metric > 0 mtu > > > > > 1500 > > > > > > > options=82808 > > > > > > > ether 00:40:d0:5e:26:38 > > > > > > > inet 192.168.91.65 netmask 0xffffff00 broadcast > 192.168.91.255 > > > > > > > media: Ethernet autoselect (100baseTX > > > > > ) > > > > > > > status: active > > > > > > > > > > > > > > Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade > soon > > > > > > > when I also configure it to receive from a raspberry-pi TV VPN > server. > > > > > > > > > > > > The above was a typo. vr is on the the STAY list. > > > > > > > > > > > > -- Brooks > > > > > Brooks, > > > > > Is there a public revised version of FCP-0101 that > reflects the > > > > > feedback which is what core is voting on? > > > > > > > > > > > > > Its on github, just like it's been the whole time for anybody to see, > > > > submit pull requests against and track: > > > > > > I have no gh account, desires no gh account, so have no way to > > > submit a change request other than through direct email to > > > brooks or another gh user. This is fundementally flawed. > > > > > > > https://github.com/freebsd/fcp/blob/master/fcp-0101.md > > > > > > Thank you for the link, I had looked at it before MeetBSD, > > > which did not have most of the recent changes done "a day ago". > > > > > > Isnt this document now in a frozen state while core reviews/votes? > > > > I sent it to a vote at c224c67557297d7cba909ad008542cb60980cc6b only > > to notice a bug in table rendering. I submitted a pull request fix > > that and a missing word which was merged since neither was material. I > > suppose they could have waited or been skipped, but there's no value in > > the FCP process being bound by the sort of pointless rigidity that led > > to -DPOSIX_MISTAKE in every libc compile line. > > The FCP process itself is unclear on this point, > I think this should be clarified. > > It is much more clear on post approval: > Changes after acceptance > > FCPs may need revision after they have been moved into the > accepted state. In such cases, the author SHOULD update the > FCP to reflect the final conclusions. > If the changes are major, the FCP SHOULD be withdrawn > and restarted. > Good point Rod. While common sense suggests that trivial changes during the voting should be allowed for editorial purposes (eg fix grammar mistakes, table rendering etc), it's better to spell that out so there's no confusion. diff --git a/fcp-0000.md b/fcp-0000.md index b4fe0f3..c8cc6f7 100644 --- a/fcp-0000.md +++ b/fcp-0000.md @@ -144,7 +144,10 @@ When the discussion of a change has come to a suitable and acceptable close it SHOULD be updated to the `vote` state. At this time the FreeBSD Core Team will vote on the subject of the FCP. The -result of vote moves the FCP into the `accepted` or `rejected` state. +result of vote moves the FCP into the `accepted` or `rejected` state. The +core team MAY make minor edits to the FCP to correct minor mistakes. Core +MAY return the proposal to the submitter if there are major problems that +need to be addressed. FCPs in the `accepted` state can be updated and corrected. See the "Changes after acceptance" section for more information. Normally I'd submit that as a pull request, but since I know you don't use github, I thought I'd present it here to see if this answers your concerns before doing so. Warner From owner-freebsd-stable@freebsd.org Wed Oct 24 00:33:20 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 282EF1039921; Wed, 24 Oct 2018 00:33:20 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 ABD9C79AA3; Wed, 24 Oct 2018 00:33:19 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w9O0XFXN025274; Tue, 23 Oct 2018 17:33:15 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w9O0XEep025273; Tue, 23 Oct 2018 17:33:14 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201810240033.w9O0XEep025273@pdx.rh.CN85.dnsmgr.net> Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers In-Reply-To: To: Warner Losh Date: Tue, 23 Oct 2018 17:33:14 -0700 (PDT) CC: Brooks Davis , FreeBSD-STABLE Mailing List , Ian Lepore , FreeBSD Net , "Julian H. Stacey" , Michelle Sullivan , "freebsd-arch@freebsd.org" , freebsd-fcp@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII 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, 24 Oct 2018 00:33:20 -0000 > On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes < > freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: ... deleted un relavent text ... > > > > > > Brooks, > > > > > > Is there a public revised version of FCP-0101 that > > reflects the > > > > > > feedback which is what core is voting on? > > > > > > > > > > > > > > > > Its on github, just like it's been the whole time for anybody to see, > > > > > submit pull requests against and track: > > > > > > > > I have no gh account, desires no gh account, so have no way to > > > > submit a change request other than through direct email to > > > > brooks or another gh user. This is fundementally flawed. > > > > > > > > > https://github.com/freebsd/fcp/blob/master/fcp-0101.md > > > > > > > > Thank you for the link, I had looked at it before MeetBSD, > > > > which did not have most of the recent changes done "a day ago". > > > > > > > > Isnt this document now in a frozen state while core reviews/votes? > > > > > > I sent it to a vote at c224c67557297d7cba909ad008542cb60980cc6b only > > > to notice a bug in table rendering. I submitted a pull request fix > > > that and a missing word which was merged since neither was material. I > > > suppose they could have waited or been skipped, but there's no value in > > > the FCP process being bound by the sort of pointless rigidity that led > > > to -DPOSIX_MISTAKE in every libc compile line. > > > > The FCP process itself is unclear on this point, > > I think this should be clarified. > > > > It is much more clear on post approval: > > Changes after acceptance > > > > FCPs may need revision after they have been moved into the > > accepted state. In such cases, the author SHOULD update the > > FCP to reflect the final conclusions. > > If the changes are major, the FCP SHOULD be withdrawn > > and restarted. > > > > Good point Rod. While common sense suggests that trivial changes during the > voting should be allowed for editorial purposes (eg fix grammar mistakes, > table rendering etc), it's better to spell that out so there's no confusion. Agreed. > > diff --git a/fcp-0000.md b/fcp-0000.md > index b4fe0f3..c8cc6f7 100644 > --- a/fcp-0000.md > +++ b/fcp-0000.md > @@ -144,7 +144,10 @@ When the discussion of a change has come to a suitable > and acceptable close it > SHOULD be updated to the `vote` state. > > At this time the FreeBSD Core Team will vote on the subject of the FCP. The > -result of vote moves the FCP into the `accepted` or `rejected` state. > +result of vote moves the FCP into the `accepted` or `rejected` state. The > +core team MAY make minor edits to the FCP to correct minor mistakes. Core > +MAY return the proposal to the submitter if there are major problems that > +need to be addressed. This allows and clarifies that core may modify it, it does not address if the author/submitter can modify it. > > FCPs in the `accepted` state can be updated and corrected. > See the "Changes after acceptance" section for more information. > > Normally I'd submit that as a pull request, but since I know you don't use > github, I thought I'd present it here to see if this answers your concerns > before doing so. I thank you very much for that consideration, -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-stable@freebsd.org Tue Oct 23 23:37:17 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 884611036F78; Tue, 23 Oct 2018 23:37:17 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 2230676DC5; Tue, 23 Oct 2018 23:37:17 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 3BA723C475F; Tue, 23 Oct 2018 23:37:16 +0000 (UTC) Date: Tue, 23 Oct 2018 23:37:16 +0000 From: Brooks Davis To: "Rodney W. Grimes" Cc: Warner Losh , Brooks Davis , FreeBSD-STABLE Mailing List , Ian Lepore , FreeBSD Net , "Julian H. Stacey" , Michelle Sullivan , "freebsd-arch@freebsd.org" , freebsd-fcp@freebsd.org Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers Message-ID: <20181023233716.GA15106@spindle.one-eyed-alien.net> References: <201810232326.w9NNQjtK024759@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline In-Reply-To: <201810232326.w9NNQjtK024759@pdx.rh.CN85.dnsmgr.net> User-Agent: Mutt/1.9.4 (2018-02-28) X-Mailman-Approved-At: Wed, 24 Oct 2018 00:34:03 +0000 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, 23 Oct 2018 23:37:17 -0000 --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 23, 2018 at 04:26:45PM -0700, Rodney W. Grimes wrote: > > On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes < > > freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > >=20 > > > > On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote: > > > > > > I'd also suggest that rl stands in stark contrast to the cs, wb= , sn, > > > smc, > > > > > > sf, tl, tx and vr drivers, which nobody has mentioned in this > > > thread, and > > > > > > which I doubt are in use in any FreeBSD system of any age today. > > > > > > > > > > vr is used by my TV driver laptop: > > > > > http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/ > > > > > vr0: flags=3D8843 metric = 0 mtu > > > 1500 > > > > > options=3D82808 > > > > > ether 00:40:d0:5e:26:38 > > > > > inet 192.168.91.65 netmask 0xffffff00 broadcast 192.168.9= 1.255 > > > > > media: Ethernet autoselect (100baseTX > > > ) > > > > > status: active > > > > > > > > > > Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade so= on > > > > > when I also configure it to receive from a raspberry-pi TV VPN se= rver. > > > > > > > > The above was a typo. vr is on the the STAY list. > > > > > > > > -- Brooks > > > Brooks, > > > Is there a public revised version of FCP-0101 that reflects t= he > > > feedback which is what core is voting on? > > > > >=20 > > Its on github, just like it's been the whole time for anybody to see, > > submit pull requests against and track: >=20 > I have no gh account, desires no gh account, so have no way to > submit a change request other than through direct email to > brooks or another gh user. This is fundementally flawed. >=20 > > https://github.com/freebsd/fcp/blob/master/fcp-0101.md >=20 > Thank you for the link, I had looked at it before MeetBSD, > which did not have most of the recent changes done "a day ago". >=20 > Isnt this document now in a frozen state while core reviews/votes? I sent it to a vote at c224c67557297d7cba909ad008542cb60980cc6b only to notice a bug in table rendering. I submitted a pull request fix that and a missing word which was merged since neither was material. I suppose they could have waited or been skipped, but there's no value in the FCP process being bound by the sort of pointless rigidity that led to -DPOSIX_MISTAKE in every libc compile line. -- Brooks --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJbz7CqAAoJEKzQXbSebgfAwOAH/0CWmIrkKsSqGjFGNeSFO7re C8i1rzIuZ4p589nhKWRfaIRC6h5FaAlBD6+/1PR3gsMwFebHVT8CcH34khy2voiJ 1TYDn6atuTqbJapp8pPH0xV56ZNr2iTMVwRU52jzGY9+gJU7uDqAcisI66U8Suqx S0tHsVZab+j4sNgCPTU5LnQ/+AYPUp5v5Gmgd4rlgYjZEA8F9YnMgtCv5c07tfdm ynN3l0DnTg3u2IQnExRh6OU9WTy/ggjBfQmcg7fCL9JAwrrkCukkyvXILmFmBuhn eShpFUzFR9rKAzYsJ92WSUviJLzB5DKDCYAUeXz0qozK9mAt75J5FYKUS/0hDBk= =dMkV -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J-- From owner-freebsd-stable@freebsd.org Wed Oct 24 13:06:26 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 123A81079FCD for ; Wed, 24 Oct 2018 13:06:26 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norma.perm.ru [IPv6:2a00:7540:1::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.norma.perm.ru", Issuer "Vivat-Trade UNIX Root CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7ABD087306 for ; Wed, 24 Oct 2018 13:06:25 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from bsdrookie.norma.com. (asterisk.enaza.ru [91.237.76.254] (may be forged)) by elf.hq.norma.perm.ru (8.15.2/8.15.2) with ESMTPS id w9O6Zsul064045 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 24 Oct 2018 11:35:55 +0500 (+05) (envelope-from emz@norma.perm.ru) From: "Eugene M. Zheganin" Subject: Re: ZFS: Can't find pool by guid To: freebsd-stable@freebsd.org References: Message-ID: Date: Wed, 24 Oct 2018 11:35:54 +0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spamd-Result: default: False [-996.50 / 25.00] WHITELISTED_IPS(-999.00)[91.237.76.254] HFILTER_HOSTNAME_UNKNOWN(2.50)[] RCPT_COUNT_ONE(0.00)[1] R_SPF_SOFTFAIL(0.00)[~all] ARC_NA(0.00)[] ASN(0.00)[asn:57973, ipnet:91.237.76.0/24, country:RU] ONCE_RECEIVED(0.10)[] MID_RHS_MATCH_FROM(0.00)[] R_DKIM_NA(0.00)[] TO_DN_NONE(0.00)[] FROM_HAS_DN(0.00)[] IP_SCORE(0.00)[ip: (-9.90), ipnet: 91.237.76.0/24(-7.89), asn: 57973(-4.93), country: RU(0.12)] MIME_GOOD(-0.10)[text/plain] RCVD_COUNT_TWO(0.00)[2] RCVD_TLS_ALL(0.00)[] DMARC_NA(0.00)[perm.ru] TO_MATCH_ENVRCPT_ALL(0.00)[] FROM_EQ_ENVFROM(0.00)[] X-Rspamd-Server: localhost X-Rspamd-Scan-Time: 1.33 X-Rspamd-Queue-ID: w9O6Zsul064045 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, 24 Oct 2018 13:06:26 -0000 Hello. On 28.04.2018 17:46, Willem Jan Withagen wrote: > Hi, > > I upgraded a server from 10.4 to 11.1 and now al of a sudden the > server complains about: > ZFS: Can't find pool by guid > And I end up in the boot prompt: > > lsdev gives disk0 withe on p1 the partion that the zroot is/was. > > This is an active server, so redoing install and stuf is nog going to > be real workable.... > > So how do I get this to boot? The basic scenario for this is when you have a "shadow" pool on the bootable disks with actual root pool - for example once you had a zfs pool on some disks that were in dedicated mode, then you extracted these disks without clearing the zpool labels (and 'zpool destroy' never clears the zpool labels) and installed the system onto them. This way 'zpool import' will show the old pool which has no live replicas and no live vdevs. The system on it may be bootable (and will probably be) until the data gets redistributed in some way, after that gptzfsboot will start to see the old pool remains, will try to detect if this pool has bootfs on it - but in this case there's no valid pool - so it will fall into error and stop working. Actually, the newer 11.2 gptzfsboot loader has more support of this - it clearly states the pool found and mentions the error - thanks to all the guys that did a great work on this, seriously. The way to resolve this is to detach disks sequentially from root pool (or offline them in case of raidz), making 'zpool labelclear' on them (please keep in mind that 'labelclear' is evil and ignorant, and breaks things including GPT table) and attaching them back, resilvering, and repeating this until 'zpool import' will show no old disassembled pools. Determining which disks have the old labels can be done with 'zdb -l /dev/ | grep name:'. I understand that your situation was resolved long ago, I'm writing this merely to establish a knowledge point if someone will step on this too, like I did yesterday. Eugene. From owner-freebsd-stable@freebsd.org Wed Oct 24 13:21:02 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9CE2B107C977 for ; Wed, 24 Oct 2018 13:21:02 +0000 (UTC) (envelope-from donotreplytothismail@gmx.com) Received: from SUNSTUDIO (unknown [159.89.45.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6069C8B0B3 for ; Wed, 24 Oct 2018 13:20:59 +0000 (UTC) (envelope-from donotreplytothismail@gmx.com) Message-ID: <9A28AA4A-24E0-4B33-BA70-60F0FE822CFC@SUNSTUDIO> From: "Mark Chen" (Mark Chen) To: freebsd-stable@freebsd.org Subject: RE: Satellite Broadband Internet Modem IP freebsd-stable@freebsd.org Date: 24 Oct 2018 20:09:20 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" 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, 24 Oct 2018 13:21:02 -0000 From owner-freebsd-stable@freebsd.org Wed Oct 24 13:05:21 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7129E1079D02; Wed, 24 Oct 2018 13:05:21 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 9B60286F1B; Wed, 24 Oct 2018 13:05:20 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w9OCJakm027721; Wed, 24 Oct 2018 05:19:36 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w9OCJXTd027720; Wed, 24 Oct 2018 05:19:33 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201810241219.w9OCJXTd027720@pdx.rh.CN85.dnsmgr.net> Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers In-Reply-To: <9257C84A-CA7C-42B9-9AD8-89AE33C96356@gid.co.uk> To: Bob Bishop Date: Wed, 24 Oct 2018 05:19:33 -0700 (PDT) CC: Warner Losh , Brooks Davis , FreeBSD-STABLE Mailing List , Ian Lepore , FreeBSD Net , "Julian H. Stacey" , Michelle Sullivan , "freebsd-arch@freebsd.org" , freebsd-fcp@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Wed, 24 Oct 2018 13:45:31 +0000 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, 24 Oct 2018 13:05:21 -0000 > > On 24 Oct 2018, at 01:23, Warner Losh wrote: > > > > On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes < > > freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > > >> -- Start of PGP signed section. > >>> On Tue, Oct 23, 2018 at 04:26:45PM -0700, Rodney W. Grimes wrote: > >>>>> On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes < > >>>>> freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > >>>>> > >>>>>>> On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote: > >>>>>>>>> I'd also suggest that rl stands in stark contrast to the cs, > >> wb, sn, > >>>>>> smc, > >>>>>>>>> sf, tl, tx and vr drivers, which nobody has mentioned in this > >>>>>> thread, and > >>>>>>>>> which I doubt are in use in any FreeBSD system of any age > >> today. > >>>>>>>> > >>>>>>>> vr is used by my TV driver laptop: > >>>>>>>> http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/ > >>>>>>>> vr0: flags=8843 metric > >> 0 mtu > >>>>>> 1500 > >>>>>>>> options=82808 > >>>>>>>> ether 00:40:d0:5e:26:38 > >>>>>>>> inet 192.168.91.65 netmask 0xffffff00 broadcast > >> 192.168.91.255 > >>>>>>>> media: Ethernet autoselect (100baseTX > >>>>>> ) > >>>>>>>> status: active > >>>>>>>> > >>>>>>>> Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade > >> soon > >>>>>>>> when I also configure it to receive from a raspberry-pi TV VPN > >> server. > >>>>>>> > >>>>>>> The above was a typo. vr is on the the STAY list. > >>>>>>> > >>>>>>> -- Brooks > >>>>>> Brooks, > >>>>>> Is there a public revised version of FCP-0101 that > >> reflects the > >>>>>> feedback which is what core is voting on? > >>>>>> > >>>>> > >>>>> Its on github, just like it's been the whole time for anybody to see, > >>>>> submit pull requests against and track: > >>>> > >>>> I have no gh account, desires no gh account, so have no way to > >>>> submit a change request other than through direct email to > >>>> brooks or another gh user. This is fundementally flawed. > >>>> > >>>>> https://github.com/freebsd/fcp/blob/master/fcp-0101.md > >>>> > >>>> Thank you for the link, I had looked at it before MeetBSD, > >>>> which did not have most of the recent changes done "a day ago". > >>>> > >>>> Isnt this document now in a frozen state while core reviews/votes? > >>> > >>> I sent it to a vote at c224c67557297d7cba909ad008542cb60980cc6b only > >>> to notice a bug in table rendering. I submitted a pull request fix > >>> that and a missing word which was merged since neither was material. I > >>> suppose they could have waited or been skipped, but there's no value in > >>> the FCP process being bound by the sort of pointless rigidity that led > >>> to -DPOSIX_MISTAKE in every libc compile line. > >> > >> The FCP process itself is unclear on this point, > >> I think this should be clarified. > >> > >> It is much more clear on post approval: > >> Changes after acceptance > >> > >> FCPs may need revision after they have been moved into the > >> accepted state. In such cases, the author SHOULD update the > >> FCP to reflect the final conclusions. > >> If the changes are major, the FCP SHOULD be withdrawn > >> and restarted. > >> > > > > Good point Rod. While common sense suggests that trivial changes during the > > voting should be allowed for editorial purposes (eg fix grammar mistakes, > > table rendering etc), it's better to spell that out so there's no confusion. > > > > diff --git a/fcp-0000.md b/fcp-0000.md > > index b4fe0f3..c8cc6f7 100644 > > --- a/fcp-0000.md > > +++ b/fcp-0000.md > > @@ -144,7 +144,10 @@ When the discussion of a change has come to a suitable > > and acceptable close it > > SHOULD be updated to the `vote` state. > > > > At this time the FreeBSD Core Team will vote on the subject of the FCP. The > > -result of vote moves the FCP into the `accepted` or `rejected` state. > > +result of vote moves the FCP into the `accepted` or `rejected` state. The > > +core team MAY make minor edits to the FCP to correct minor mistakes. Core > > +MAY return the proposal to the submitter if there are major problems that > > +need to be addressed. > > This is a Bad Idea, because it relies on common understanding of what is minor. I was once involved with a standards body that had a procedure for so-called clerical errors intended to deal with typos, punctuation etc; this worked just fine until somebody claimed that the omission of the word ?not? in a particular place was clearly a clerical error. And I have read case law that boiled down to the presents vs absence of a comma in an agreement that had results far beyond "minor". Use of words minor and major should be red flags unless both or explicitly defined, and even then those definitions often have issues themselves. > > FCPs in the `accepted` state can be updated and corrected. > > See the "Changes after acceptance" section for more information. > > > > Normally I'd submit that as a pull request, but since I know you don't use > > github, I thought I'd present it here to see if this answers your concerns > > before doing so. > > > > Warner > > _______________________________________________ > > 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" > > > > -- > Bob Bishop > rb@gid.co.uk -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-stable@freebsd.org Wed Oct 24 13:47:50 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A9B3FE5198 for ; Wed, 24 Oct 2018 13:47:50 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:d12:604::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 D6BA38F756 for ; Wed, 24 Oct 2018 13:47:49 +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 w9ODlfo3031698 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Oct 2018 15:47:41 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: emz@norma.perm.ru Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w9ODletl001918 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 24 Oct 2018 20:47:40 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: ZFS: Can't find pool by guid To: "Eugene M. Zheganin" , freebsd-stable@freebsd.org References: From: Eugene Grosbein Message-ID: Date: Wed, 24 Oct 2018 20:47:35 +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_PASS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net 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, 24 Oct 2018 13:47:50 -0000 24.10.2018 13:35, Eugene M. Zheganin wrote: > On 28.04.2018 17:46, Willem Jan Withagen wrote: >> Hi, >> >> I upgraded a server from 10.4 to 11.1 and now al of a sudden the server complains about: >> ZFS: Can't find pool by guid >> And I end up in the boot prompt: >> >> lsdev gives disk0 withe on p1 the partion that the zroot is/was. >> >> This is an active server, so redoing install and stuf is nog going to be real workable.... >> >> So how do I get this to boot? > The basic scenario for this is when you have a "shadow" pool on the bootable disks with actual root pool - for example once you had a zfs pool on some disks that were in dedicated mode, then you extracted these disks without clearing the zpool labels (and 'zpool destroy' never clears the zpool labels) and installed the system onto them. This way 'zpool import' will show the old pool which has no live replicas and no live vdevs. The system on it may be bootable (and will probably be) until the data gets redistributed in some way, after that gptzfsboot will start to see the old pool remains, will try to detect if this pool has bootfs on it - but in this case there's no valid pool - so it will fall into error and stop working. Actually, the newer 11.2 gptzfsboot loader has more support of this - it clearly states the pool found and mentions the error - thanks to all the guys that did a great work on this, seriously. > > The way to resolve this is to detach disks sequentially from root pool (or offline them in case of raidz), making 'zpool labelclear' on them (please keep in mind that 'labelclear' is evil and ignorant, and breaks things including GPT table) and attaching them back, resilvering, and repeating this until 'zpool import' will show no old disassembled pools. Determining which disks have the old labels can be done with 'zdb -l /dev/ | grep name:'. > > I understand that your situation was resolved long ago, I'm writing this merely to establish a knowledge point if someone will step on this too, like I did yesterday. There is quicker and easier way: just rename real pool to another name and use vfs.root.mountfrom=zfs:newpoolname/fs From owner-freebsd-stable@freebsd.org Wed Oct 24 13:59:46 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6041BFE92F9; Wed, 24 Oct 2018 13:59:46 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 C4656910C8; Wed, 24 Oct 2018 13:59:45 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w9ODxg2o028398; Wed, 24 Oct 2018 06:59:42 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w9ODxgF8028397; Wed, 24 Oct 2018 06:59:42 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201810241359.w9ODxgF8028397@pdx.rh.CN85.dnsmgr.net> Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers In-Reply-To: To: Warner Losh Date: Wed, 24 Oct 2018 06:59:42 -0700 (PDT) CC: freebsd-stable@freebsd.org, freebsd-net@freebsd.org, freebsd-arch@freebsd.org, freebsd-fcp@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII 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, 24 Oct 2018 13:59:46 -0000 ... deleted ... ... cc list trimmed, getting too many recepient gripes from mailman ... > > > > diff --git a/fcp-0000.md b/fcp-0000.md > > > > index b4fe0f3..c8cc6f7 100644 > > > > --- a/fcp-0000.md > > > > +++ b/fcp-0000.md > > > > @@ -144,7 +144,10 @@ When the discussion of a change has come to a > > suitable > > > > and acceptable close it > > > > SHOULD be updated to the `vote` state. > > > > > > > > At this time the FreeBSD Core Team will vote on the subject of the > > FCP. The > > > > -result of vote moves the FCP into the `accepted` or `rejected` state. > > > > +result of vote moves the FCP into the `accepted` or `rejected` state. > > The > > > > +core team MAY make minor edits to the FCP to correct minor mistakes. > > Core > > > > +MAY return the proposal to the submitter if there are major problems > > that > > > > +need to be addressed. > > > > > > This is a Bad Idea, because it relies on common understanding of what is > > minor. I was once involved with a standards body that had a procedure for > > so-called clerical errors intended to deal with typos, punctuation etc; > > this worked just fine until somebody claimed that the omission of the word > > ?not? in a particular place was clearly a clerical error. > > > > And I have read case law that boiled down to the presents vs absence > > of a comma in an agreement that had results far beyond "minor". > > > > Use of words minor and major should be red flags unless both > > or explicitly defined, and even then those definitions often > > have issues themselves. > > > > I'm not going to define every single word. FCP documents describe process. > They are not legal documents, nor should they be. Major and minor have > common enough meanings, and the basis of bylaws is that we trust core@. The trust isssue is not core (though in this specific case it is a core member submitting the FCP, that is not going to be the case always). The trust issue is do we allow the Author to make this minor/major change decission and how does core get informed that it has happened? -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-stable@freebsd.org Wed Oct 24 14:10:01 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D58F1FEA558; Wed, 24 Oct 2018 14:10:01 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "land.berklix.org", Issuer "land.berklix.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 58C2192ECB; Wed, 24 Oct 2018 14:10:01 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p2E52CCDC.dip0.t-ipconnect.de [46.82.204.220]) (authenticated bits=0) by land.berklix.org (8.15.2/8.15.2) with ESMTPSA id w9OE9tuA000977 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Oct 2018 14:09:59 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id w9OE9oUt043495; Wed, 24 Oct 2018 16:09:50 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id w9OE9cHH040720; Wed, 24 Oct 2018 16:09:50 +0200 (CEST) (envelope-from jhs@berklix.com) Message-Id: <201810241409.w9OE9cHH040720@fire.js.berklix.net> To: FreeBSD-STABLE Mailing List , FreeBSD Net , "freebsd-arch@freebsd.org" , freebsd-fcp@freebsd.org Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers From: "Julian H. Stacey" Organization: http://berklix.eu BSD Unix Linux Consultants, Munich Germany User-agent: EXMH on FreeBSD http://berklix.eu/free/ X-From: http://www.berklix.eu/~jhs/ In-reply-to: Your message "Wed, 24 Oct 2018 06:54:01 -0700." <201810241354.w9ODs1MD028342@pdx.rh.CN85.dnsmgr.net> Date: Wed, 24 Oct 2018 16:09:38 +0200 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, 24 Oct 2018 14:10:02 -0000 "Rodney W. Grimes" wrote: > We could add that once the document is submitted to core > any change to it between submitting and vote by core requires > core to be involved, even if it is simply an ack of a change > has been made to what was submitted. Yes ! Cheers, Julian -- Julian Stacey, Computer Consultant, Systems Engineer, BSD Linux Unix, Munich. Brexit referendum stole 3,700,000 Brits votes abroad, inc. 700,000 in EU. Campaign lies, criminal funding, economy & pound down. Time for an honest ref. http://exitbrexit.uk https://www.peoples-vote.uk/petition https://eci.ec.europa.eu/002/public/#/initiative From owner-freebsd-stable@freebsd.org Wed Oct 24 13:54:05 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 56616FE5C52; Wed, 24 Oct 2018 13:54:05 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 B6241906FD; Wed, 24 Oct 2018 13:54:04 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w9ODs2i7028343; Wed, 24 Oct 2018 06:54:02 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w9ODs1MD028342; Wed, 24 Oct 2018 06:54:01 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201810241354.w9ODs1MD028342@pdx.rh.CN85.dnsmgr.net> Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers In-Reply-To: <20181024134153.GC3125@lonesome.com> To: Mark Linimon Date: Wed, 24 Oct 2018 06:54:01 -0700 (PDT) CC: Bob Bishop , Brooks Davis , FreeBSD-STABLE Mailing List , Ian Lepore , FreeBSD Net , "Julian H. Stacey" , Michelle Sullivan , "freebsd-arch@freebsd.org" , freebsd-fcp@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Wed, 24 Oct 2018 14:11:28 +0000 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, 24 Oct 2018 13:54:05 -0000 > On Wed, Oct 24, 2018 at 05:19:33AM -0700, Rodney W. Grimes wrote: > > And I have read case law that boiled down to the presents vs absence > > of a comma > > If we are now going to evaluate all proposed changes to FreeBSD on the > same rigid principles as the US legal system, I'm done. I do not think "all" is in scope here, but I do feel should excercise care about procedure. And FYI, the case law above I am pretty sure was not US. I also believe that what is at issue here can be fixed rather easily without ever going down the minor vs major slippery slope by some rather simple changes to order of events and careful steps. Warner came very close, I think he just applied his correct "fix" to 1/2 of the problem. There is the stage where the FCP is before core being voted on, and there is the stage that the FCP has been approved. He only addressed 1 of those, and he did so by allowing core to trivially modify the document during the voting process, and I am actually fine with that idea, its good, it is what should be allowed. I trust core to know what is minor vs major. BUTT it still does not cover the issue of the author/submitter modifying the document while it is in core being reviewed and possibly modified. I have issue with that. It is very hard to vote/formally review on something that is fluid. I have not been asked to trust these people with the trust I give core, so I would like to remove that. We could add that once the document is submitted to core any change to it between submitting and vote by core requires core to be involved, even if it is simply an ack of a change has been made to what was submitted. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-stable@freebsd.org Wed Oct 24 13:44:39 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75E69FD9D02 for ; Wed, 24 Oct 2018 13:44:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x944.google.com (mail-ua1-x944.google.com [IPv6:2607:f8b0:4864:20::944]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 02F3C8EE6C for ; Wed, 24 Oct 2018 13:44:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x944.google.com with SMTP id c10so1861470uao.12 for ; Wed, 24 Oct 2018 06:44:39 -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=2DXuiWjjvcOgNMSyAZpPAN2uFGwXsKfvo59f+0Wz8a8=; b=pakNqQO+a2iHXaLpQNJT7nQWWAUlaYzNRuEnD4cw+F6Pg8NaDxOoM6yBiOY1iv2Hlj 6myGynn/mzSC4NBljs7ZuxAmxQXzj32xHmKCIGuFBqIpNRUGn/mPAsPiDhhplhb0q4GZ OcEiR8fYCc7F3R4jj+1WGsWNuW9xA4LpjN437whWF2ODtYJYbLVEzHqnHzi50Uy09mwn yWQRI1yqjA3OMyDLgfCr9vVkKfYCPsZo+zNLeixPL3lJmshz+QSedGB5jYXvMbDzzj3I I7KtN7szGN8l6uwowpAptokfPvg49gG4zFbjn3cTN5EYg3vtfedplZE6C4iENlyeqtwV uutw== 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=2DXuiWjjvcOgNMSyAZpPAN2uFGwXsKfvo59f+0Wz8a8=; b=EFifFDF2Qab+8Y8QUhbBJLsp3RIZGxlauwatXfQOBwrHF43JrsPUFxAxBfXpt3OAM4 o2BLdZnK6Ad0I1KaDRy7ziGxlfBUxK4JMUwFEE0qIu0Ix4MRlKjhSyTzmTuaPhyYy7+o YKYsHqWeIbTEz49T1qnndJQnHg9HMXwUY6ZJIhrDREBu+RoMmMLSdXd2QVWi88j+TSCm TGz7t6E6WXOpTDDDP7pAvRHGCzuSL8F+XRRnoDW4cVeVSDcGSJntuhzJCL0/s4ZwRNtH CCPi3ymCfVb8xfmXjOkf1cxwLrhaw+r7KfLuQMEfX5HyH7bt1h9M6SlAnhAILfR1fJbk oPmA== X-Gm-Message-State: AGRZ1gIg+jEpDCDDVN373RTjwMzgkAr6cDbR+JdkKJduj0XQbfEHrqj7 Jtf5OXYfizd7PVgERlnmKP+UYAf6KrPX1//46wsbCw== X-Google-Smtp-Source: AJdET5dXkqJdUZq4ZQb1kNFWEuItozQybopyAqw8QaVs+hio60L1zj0p7kVMYK7KrYehJ5NhaIkIAAZFf67lTEL9Bxc= X-Received: by 2002:ab0:14a4:: with SMTP id d33mr1115424uae.41.1540388678365; Wed, 24 Oct 2018 06:44:38 -0700 (PDT) MIME-Version: 1.0 References: <9257C84A-CA7C-42B9-9AD8-89AE33C96356@gid.co.uk> <201810241219.w9OCJXTd027720@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201810241219.w9OCJXTd027720@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Wed, 24 Oct 2018 07:44:26 -0600 Message-ID: Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers To: "Rodney W. Grimes" Cc: Bob Bishop , Brooks Davis , FreeBSD-STABLE Mailing List , Ian Lepore , FreeBSD Net , "Julian H. Stacey" , Michelle Sullivan , "freebsd-arch@freebsd.org" , freebsd-fcp@freebsd.org X-Mailman-Approved-At: Wed, 24 Oct 2018 14:11:28 +0000 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: Wed, 24 Oct 2018 13:44:39 -0000 On Wed, Oct 24, 2018 at 6:19 AM Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > > On 24 Oct 2018, at 01:23, Warner Losh wrote: > > > > > > On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes < > > > freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > >> -- Start of PGP signed section. > > >>> On Tue, Oct 23, 2018 at 04:26:45PM -0700, Rodney W. Grimes wrote: > > >>>>> On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes < > > >>>>> freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > >>>>> > > >>>>>>> On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote: > > >>>>>>>>> I'd also suggest that rl stands in stark contrast to the cs, > > >> wb, sn, > > >>>>>> smc, > > >>>>>>>>> sf, tl, tx and vr drivers, which nobody has mentioned in this > > >>>>>> thread, and > > >>>>>>>>> which I doubt are in use in any FreeBSD system of any age > > >> today. > > >>>>>>>> > > >>>>>>>> vr is used by my TV driver laptop: > > >>>>>>>> http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/ > > >>>>>>>> vr0: flags=8843 metric > > >> 0 mtu > > >>>>>> 1500 > > >>>>>>>> options=82808 > > >>>>>>>> ether 00:40:d0:5e:26:38 > > >>>>>>>> inet 192.168.91.65 netmask 0xffffff00 broadcast > > >> 192.168.91.255 > > >>>>>>>> media: Ethernet autoselect (100baseTX > > >>>>>> ) > > >>>>>>>> status: active > > >>>>>>>> > > >>>>>>>> Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade > > >> soon > > >>>>>>>> when I also configure it to receive from a raspberry-pi TV VPN > > >> server. > > >>>>>>> > > >>>>>>> The above was a typo. vr is on the the STAY list. > > >>>>>>> > > >>>>>>> -- Brooks > > >>>>>> Brooks, > > >>>>>> Is there a public revised version of FCP-0101 that > > >> reflects the > > >>>>>> feedback which is what core is voting on? > > >>>>>> > > >>>>> > > >>>>> Its on github, just like it's been the whole time for anybody to > see, > > >>>>> submit pull requests against and track: > > >>>> > > >>>> I have no gh account, desires no gh account, so have no way to > > >>>> submit a change request other than through direct email to > > >>>> brooks or another gh user. This is fundementally flawed. > > >>>> > > >>>>> https://github.com/freebsd/fcp/blob/master/fcp-0101.md > > >>>> > > >>>> Thank you for the link, I had looked at it before MeetBSD, > > >>>> which did not have most of the recent changes done "a day ago". > > >>>> > > >>>> Isnt this document now in a frozen state while core reviews/votes? > > >>> > > >>> I sent it to a vote at c224c67557297d7cba909ad008542cb60980cc6b only > > >>> to notice a bug in table rendering. I submitted a pull request fix > > >>> that and a missing word which was merged since neither was > material. I > > >>> suppose they could have waited or been skipped, but there's no value > in > > >>> the FCP process being bound by the sort of pointless rigidity that > led > > >>> to -DPOSIX_MISTAKE in every libc compile line. > > >> > > >> The FCP process itself is unclear on this point, > > >> I think this should be clarified. > > >> > > >> It is much more clear on post approval: > > >> Changes after acceptance > > >> > > >> FCPs may need revision after they have been moved into the > > >> accepted state. In such cases, the author SHOULD update the > > >> FCP to reflect the final conclusions. > > >> If the changes are major, the FCP SHOULD be withdrawn > > >> and restarted. > > >> > > > > > > Good point Rod. While common sense suggests that trivial changes > during the > > > voting should be allowed for editorial purposes (eg fix grammar > mistakes, > > > table rendering etc), it's better to spell that out so there's no > confusion. > > > > > > diff --git a/fcp-0000.md b/fcp-0000.md > > > index b4fe0f3..c8cc6f7 100644 > > > --- a/fcp-0000.md > > > +++ b/fcp-0000.md > > > @@ -144,7 +144,10 @@ When the discussion of a change has come to a > suitable > > > and acceptable close it > > > SHOULD be updated to the `vote` state. > > > > > > At this time the FreeBSD Core Team will vote on the subject of the > FCP. The > > > -result of vote moves the FCP into the `accepted` or `rejected` state. > > > +result of vote moves the FCP into the `accepted` or `rejected` state. > The > > > +core team MAY make minor edits to the FCP to correct minor mistakes. > Core > > > +MAY return the proposal to the submitter if there are major problems > that > > > +need to be addressed. > > > > This is a Bad Idea, because it relies on common understanding of what is > minor. I was once involved with a standards body that had a procedure for > so-called clerical errors intended to deal with typos, punctuation etc; > this worked just fine until somebody claimed that the omission of the word > ?not? in a particular place was clearly a clerical error. > > And I have read case law that boiled down to the presents vs absence > of a comma in an agreement that had results far beyond "minor". > > Use of words minor and major should be red flags unless both > or explicitly defined, and even then those definitions often > have issues themselves. > I'm not going to define every single word. FCP documents describe process. They are not legal documents, nor should they be. Major and minor have common enough meanings, and the basis of bylaws is that we trust core@. Warner > > > FCPs in the `accepted` state can be updated and corrected. > > > See the "Changes after acceptance" section for more information. > > > > > > Normally I'd submit that as a pull request, but since I know you don't > use > > > github, I thought I'd present it here to see if this answers your > concerns > > > before doing so. > > > > > > Warner > > > _______________________________________________ > > > 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" > > > > > > > -- > > Bob Bishop > > rb@gid.co.uk > > -- > Rod Grimes > rgrimes@freebsd.org > From owner-freebsd-stable@freebsd.org Wed Oct 24 13:09:52 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F2ECC107A88E; Wed, 24 Oct 2018 13:09:51 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) (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 6283988C3C; Wed, 24 Oct 2018 13:09:51 +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 w9OB2V7V059852; Wed, 24 Oct 2018 12:02:32 +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: FCP-0101: Deprecating most 10/100 Ethernet drivers From: Bob Bishop In-Reply-To: Date: Wed, 24 Oct 2018 12:02:29 +0100 Cc: "Rodney W. Grimes" , Brooks Davis , FreeBSD-STABLE Mailing List , Ian Lepore , FreeBSD Net , "Julian H. Stacey" , Michelle Sullivan , "freebsd-arch@freebsd.org" , freebsd-fcp@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <9257C84A-CA7C-42B9-9AD8-89AE33C96356@gid.co.uk> References: <20181023233716.GA15106@spindle.one-eyed-alien.net> <201810240002.w9O02tXg025019@pdx.rh.CN85.dnsmgr.net> To: Warner Losh X-Mailer: Apple Mail (2.3273) X-Mailman-Approved-At: Wed, 24 Oct 2018 14:11:28 +0000 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, 24 Oct 2018 13:09:52 -0000 > On 24 Oct 2018, at 01:23, Warner Losh wrote: >=20 > On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes < > freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: >=20 >> -- Start of PGP signed section. >>> On Tue, Oct 23, 2018 at 04:26:45PM -0700, Rodney W. Grimes wrote: >>>>> On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes < >>>>> freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: >>>>>=20 >>>>>>> On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey = wrote: >>>>>>>>> I'd also suggest that rl stands in stark contrast to the cs, >> wb, sn, >>>>>> smc, >>>>>>>>> sf, tl, tx and vr drivers, which nobody has mentioned in this >>>>>> thread, and >>>>>>>>> which I doubt are in use in any FreeBSD system of any age >> today. >>>>>>>>=20 >>>>>>>> vr is used by my TV driver laptop: >>>>>>>> http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/ >>>>>>>> vr0: flags=3D8843 = metric >> 0 mtu >>>>>> 1500 >>>>>>>> options=3D82808 >>>>>>>> ether 00:40:d0:5e:26:38 >>>>>>>> inet 192.168.91.65 netmask 0xffffff00 broadcast >> 192.168.91.255 >>>>>>>> media: Ethernet autoselect (100baseTX >>>>>> ) >>>>>>>> status: active >>>>>>>>=20 >>>>>>>> Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade >> soon >>>>>>>> when I also configure it to receive from a raspberry-pi TV VPN >> server. >>>>>>>=20 >>>>>>> The above was a typo. vr is on the the STAY list. >>>>>>>=20 >>>>>>> -- Brooks >>>>>> Brooks, >>>>>> Is there a public revised version of FCP-0101 that >> reflects the >>>>>> feedback which is what core is voting on? >>>>>>=20 >>>>>=20 >>>>> Its on github, just like it's been the whole time for anybody to = see, >>>>> submit pull requests against and track: >>>>=20 >>>> I have no gh account, desires no gh account, so have no way to >>>> submit a change request other than through direct email to >>>> brooks or another gh user. This is fundementally flawed. >>>>=20 >>>>> https://github.com/freebsd/fcp/blob/master/fcp-0101.md >>>>=20 >>>> Thank you for the link, I had looked at it before MeetBSD, >>>> which did not have most of the recent changes done "a day ago". >>>>=20 >>>> Isnt this document now in a frozen state while core reviews/votes? >>>=20 >>> I sent it to a vote at c224c67557297d7cba909ad008542cb60980cc6b only >>> to notice a bug in table rendering. I submitted a pull request fix >>> that and a missing word which was merged since neither was material. = I >>> suppose they could have waited or been skipped, but there's no value = in >>> the FCP process being bound by the sort of pointless rigidity that = led >>> to -DPOSIX_MISTAKE in every libc compile line. >>=20 >> The FCP process itself is unclear on this point, >> I think this should be clarified. >>=20 >> It is much more clear on post approval: >> Changes after acceptance >>=20 >> FCPs may need revision after they have been moved into the >> accepted state. In such cases, the author SHOULD update the >> FCP to reflect the final conclusions. >> If the changes are major, the FCP SHOULD be withdrawn >> and restarted. >>=20 >=20 > Good point Rod. While common sense suggests that trivial changes = during the > voting should be allowed for editorial purposes (eg fix grammar = mistakes, > table rendering etc), it's better to spell that out so there's no = confusion. >=20 > diff --git a/fcp-0000.md b/fcp-0000.md > index b4fe0f3..c8cc6f7 100644 > --- a/fcp-0000.md > +++ b/fcp-0000.md > @@ -144,7 +144,10 @@ When the discussion of a change has come to a = suitable > and acceptable close it > SHOULD be updated to the `vote` state. >=20 > At this time the FreeBSD Core Team will vote on the subject of the = FCP. The > -result of vote moves the FCP into the `accepted` or `rejected` state. > +result of vote moves the FCP into the `accepted` or `rejected` state. = The > +core team MAY make minor edits to the FCP to correct minor mistakes. = Core > +MAY return the proposal to the submitter if there are major problems = that > +need to be addressed. This is a Bad Idea, because it relies on common understanding of what is = minor. I was once involved with a standards body that had a procedure = for so-called clerical errors intended to deal with typos, punctuation = etc; this worked just fine until somebody claimed that the omission of = the word =E2=80=9Cnot=E2=80=9D in a particular place was clearly a = clerical error. > FCPs in the `accepted` state can be updated and corrected. > See the "Changes after acceptance" section for more information. >=20 > Normally I'd submit that as a pull request, but since I know you don't = use > github, I thought I'd present it here to see if this answers your = concerns > before doing so. >=20 > Warner > _______________________________________________ > 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" >=20 -- Bob Bishop rb@gid.co.uk From owner-freebsd-stable@freebsd.org Wed Oct 24 13:39:33 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45276FD95E3 for ; Wed, 24 Oct 2018 13:39:33 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CFEDA8E415 for ; Wed, 24 Oct 2018 13:39:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92e.google.com with SMTP id j38so1860628uae.6 for ; Wed, 24 Oct 2018 06:39:32 -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=Ce+lKE4X4hw50P1h1G+iDhJtzQKtDvxqDUQWTCm/zKE=; b=U+gSsvik04vqMe9Cc/8IVBPsC9F3pOozU2dAod8wjwSmYH5J/EryEqaIo+wJDRWP6M UBVdeSQOhhm1cwjVJUbAYD5IGydWBDvb8tqy1uAQM9WpKSJ+0gv5r2BR3UX64UPqn+l5 b0us1D7JlZtuxBE4Cie7oLXD+h1OxnaXVauuk8Aq1pzeKRO1bJvCXsLUMBR+r97SLR+a x39fwWRc1iI5YcHO+EYr2tbgjcKA16H0nQANlAUIJDOPu5bOqutUlIvcip8OQ/JHWXde bxXFGYkHV9pkQvuO1yLsBPWlh1f4QXfB363eApiGjLs6QPgCOLVyqwD7GzVwc7TKQ8QP 9csA== 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=Ce+lKE4X4hw50P1h1G+iDhJtzQKtDvxqDUQWTCm/zKE=; b=GTwkDlp7RREzEpRn1ZeaFTm6ZSfMiPlhzPXUN6yD6ji+IuKw9kEOIBgSZUF3rdFC2V SX/lINmFUjKys7qtIc3U9yN5HnSsMKhQK46AAgCcxDN/opGHa/PbplnEFzi/PPwWCfZx timcPpdlZAj9WXs+x4OIT6246ApczQLfDyzOXoNR41tsCuq707cPkkkPMEDmEn3dFgfA /AJ565fniAJbdxz+sdtNIOx6zuy8tDKyaEvChUVigBSG0As/osJBLuzU/S7eHB3H8h0v yNRtUsrO2vX18lXrbQZT1n71ocCBQCX9PsxaN5ZnWYEVrpREAL9RgZMyLZti0JAKkzrZ uyXA== X-Gm-Message-State: AGRZ1gJwGUZ0S4RV4PWMCkRvIXLcW2ra0KPntzR/mtTgaJUbfqaEIvfQ EhzpLzdyhYJl5zxHa/bvSBGnV2JQM1J910DMuBAUS3Uv X-Google-Smtp-Source: AJdET5dirytD25FAxg9qrHowfcJcAQMkWc1rCZbTcOiTB+772fCVD9SZwrRxVtIsVSuu2+xgSV9/oiAxNMSf6H3WmVI= X-Received: by 2002:ab0:53c3:: with SMTP id l3mr1139500uaa.16.1540388371742; Wed, 24 Oct 2018 06:39:31 -0700 (PDT) MIME-Version: 1.0 References: <20181023233716.GA15106@spindle.one-eyed-alien.net> <201810240002.w9O02tXg025019@pdx.rh.CN85.dnsmgr.net> <9257C84A-CA7C-42B9-9AD8-89AE33C96356@gid.co.uk> In-Reply-To: <9257C84A-CA7C-42B9-9AD8-89AE33C96356@gid.co.uk> From: Warner Losh Date: Wed, 24 Oct 2018 07:39:20 -0600 Message-ID: Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers To: Bob Bishop Cc: "Rodney W. Grimes" , Brooks Davis , FreeBSD-STABLE Mailing List , Ian Lepore , FreeBSD Net , "Julian H. Stacey" , Michelle Sullivan , "freebsd-arch@freebsd.org" , freebsd-fcp@freebsd.org X-Mailman-Approved-At: Wed, 24 Oct 2018 14:11:28 +0000 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: Wed, 24 Oct 2018 13:39:33 -0000 On Wed, Oct 24, 2018 at 5:02 AM Bob Bishop wrote: > > > On 24 Oct 2018, at 01:23, Warner Losh wrote: > > > > On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes < > > freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > > >> -- Start of PGP signed section. > >>> On Tue, Oct 23, 2018 at 04:26:45PM -0700, Rodney W. Grimes wrote: > >>>>> On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes < > >>>>> freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > >>>>> > >>>>>>> On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote: > >>>>>>>>> I'd also suggest that rl stands in stark contrast to the cs, > >> wb, sn, > >>>>>> smc, > >>>>>>>>> sf, tl, tx and vr drivers, which nobody has mentioned in this > >>>>>> thread, and > >>>>>>>>> which I doubt are in use in any FreeBSD system of any age > >> today. > >>>>>>>> > >>>>>>>> vr is used by my TV driver laptop: > >>>>>>>> http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/ > >>>>>>>> vr0: flags=3D8843 metric > >> 0 mtu > >>>>>> 1500 > >>>>>>>> options=3D82808 > >>>>>>>> ether 00:40:d0:5e:26:38 > >>>>>>>> inet 192.168.91.65 netmask 0xffffff00 broadcast > >> 192.168.91.255 > >>>>>>>> media: Ethernet autoselect (100baseTX > >>>>>> ) > >>>>>>>> status: active > >>>>>>>> > >>>>>>>> Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade > >> soon > >>>>>>>> when I also configure it to receive from a raspberry-pi TV VPN > >> server. > >>>>>>> > >>>>>>> The above was a typo. vr is on the the STAY list. > >>>>>>> > >>>>>>> -- Brooks > >>>>>> Brooks, > >>>>>> Is there a public revised version of FCP-0101 that > >> reflects the > >>>>>> feedback which is what core is voting on? > >>>>>> > >>>>> > >>>>> Its on github, just like it's been the whole time for anybody to se= e, > >>>>> submit pull requests against and track: > >>>> > >>>> I have no gh account, desires no gh account, so have no way to > >>>> submit a change request other than through direct email to > >>>> brooks or another gh user. This is fundementally flawed. > >>>> > >>>>> https://github.com/freebsd/fcp/blob/master/fcp-0101.md > >>>> > >>>> Thank you for the link, I had looked at it before MeetBSD, > >>>> which did not have most of the recent changes done "a day ago". > >>>> > >>>> Isnt this document now in a frozen state while core reviews/votes? > >>> > >>> I sent it to a vote at c224c67557297d7cba909ad008542cb60980cc6b only > >>> to notice a bug in table rendering. I submitted a pull request fix > >>> that and a missing word which was merged since neither was material. = I > >>> suppose they could have waited or been skipped, but there's no value = in > >>> the FCP process being bound by the sort of pointless rigidity that le= d > >>> to -DPOSIX_MISTAKE in every libc compile line. > >> > >> The FCP process itself is unclear on this point, > >> I think this should be clarified. > >> > >> It is much more clear on post approval: > >> Changes after acceptance > >> > >> FCPs may need revision after they have been moved into the > >> accepted state. In such cases, the author SHOULD update the > >> FCP to reflect the final conclusions. > >> If the changes are major, the FCP SHOULD be withdrawn > >> and restarted. > >> > > > > Good point Rod. While common sense suggests that trivial changes during > the > > voting should be allowed for editorial purposes (eg fix grammar mistake= s, > > table rendering etc), it's better to spell that out so there's no > confusion. > > > > diff --git a/fcp-0000.md b/fcp-0000.md > > index b4fe0f3..c8cc6f7 100644 > > --- a/fcp-0000.md > > +++ b/fcp-0000.md > > @@ -144,7 +144,10 @@ When the discussion of a change has come to a > suitable > > and acceptable close it > > SHOULD be updated to the `vote` state. > > > > At this time the FreeBSD Core Team will vote on the subject of the FCP. > The > > -result of vote moves the FCP into the `accepted` or `rejected` state. > > +result of vote moves the FCP into the `accepted` or `rejected` state. > The > > +core team MAY make minor edits to the FCP to correct minor mistakes. > Core > > +MAY return the proposal to the submitter if there are major problems > that > > +need to be addressed. > > This is a Bad Idea, because it relies on common understanding of what is > minor. I was once involved with a standards body that had a procedure for > so-called clerical errors intended to deal with typos, punctuation etc; > this worked just fine until somebody claimed that the omission of the wor= d > =E2=80=9Cnot=E2=80=9D in a particular place was clearly a clerical error. > This documents procedure. It's not law. Trying to read it as law is a mistake: it's written to be brief and descriptive, not through and prescriptive. And that's on purpose. Axiom 1 of the bylaws is that you can trust the core team, which is why the power grant is total and unequivocal: Core is the governing body of the project. If you can't trust the core team and need anything more, you've already list. And over the years core's biggest failing isn't some fleet of black helicopters dispatched to take out critics or other shenanigans. It's either been not doing enough for the situation (due to too little time and/or a mistaken impression that they couldn't do anything), or it's lack of clear communication either between the different 'hats' and core or between core and the rest of the project. Warner From owner-freebsd-stable@freebsd.org Wed Oct 24 13:41:56 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30436FD9A17; Wed, 24 Oct 2018 13:41:56 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [18.222.6.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D85C48EA61; Wed, 24 Oct 2018 13:41:55 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (unknown [18.188.142.31]) by mail.soaustin.net (Postfix) with ESMTPSA id 3CB622EBA8; Wed, 24 Oct 2018 13:41:55 +0000 (UTC) Date: Wed, 24 Oct 2018 13:41:54 +0000 From: Mark Linimon To: "Rodney W. Grimes" Cc: Bob Bishop , Brooks Davis , FreeBSD-STABLE Mailing List , Ian Lepore , FreeBSD Net , "Julian H. Stacey" , Michelle Sullivan , "freebsd-arch@freebsd.org" , freebsd-fcp@freebsd.org Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers Message-ID: <20181024134153.GC3125@lonesome.com> References: <9257C84A-CA7C-42B9-9AD8-89AE33C96356@gid.co.uk> <201810241219.w9OCJXTd027720@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201810241219.w9OCJXTd027720@pdx.rh.CN85.dnsmgr.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Wed, 24 Oct 2018 14:11:28 +0000 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, 24 Oct 2018 13:41:56 -0000 On Wed, Oct 24, 2018 at 05:19:33AM -0700, Rodney W. Grimes wrote: > And I have read case law that boiled down to the presents vs absence > of a comma If we are now going to evaluate all proposed changes to FreeBSD on the same rigid principles as the US legal system, I'm done. mcl From owner-freebsd-stable@freebsd.org Wed Oct 24 14:41:37 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4171EFECD4D; Wed, 24 Oct 2018 14:41:37 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 B2471958CD; Wed, 24 Oct 2018 14:41:36 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w9OEfVDq028731; Wed, 24 Oct 2018 07:41:31 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w9OEfV2B028730; Wed, 24 Oct 2018 07:41:31 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201810241441.w9OEfV2B028730@pdx.rh.CN85.dnsmgr.net> Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers In-Reply-To: <201810241409.w9OE9cHH040720@fire.js.berklix.net> To: "Julian H. Stacey" Date: Wed, 24 Oct 2018 07:41:31 -0700 (PDT) CC: FreeBSD-STABLE Mailing List , FreeBSD Net , "freebsd-arch@freebsd.org" , freebsd-fcp@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII 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, 24 Oct 2018 14:41:37 -0000 > "Rodney W. Grimes" wrote: > > We could add that once the document is submitted to core > > any change to it between submitting and vote by core requires > > core to be involved, even if it is simply an ack of a change > > has been made to what was submitted. > > Yes ! And to expand on that further since core is under a 2 week timeline to complete this process any submitted change acceptable to core resets the 2 week timer, if core rejects the change the timer continues as original. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-stable@freebsd.org Wed Oct 24 14:55:17 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E83B4FED73F; Wed, 24 Oct 2018 14:55:16 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) (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 86B0196672; Wed, 24 Oct 2018 14:55:16 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from [194.32.164.27] ([194.32.164.27]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id w9OEtD1L009610; Wed, 24 Oct 2018 15:55:13 +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: FCP-0101: Deprecating most 10/100 Ethernet drivers From: rb@gid.co.uk In-Reply-To: Date: Wed, 24 Oct 2018 15:55:13 +0100 Cc: "Rodney W. Grimes" , Brooks Davis , FreeBSD-STABLE Mailing List , Ian Lepore , FreeBSD Net , "Julian H. Stacey" , Michelle Sullivan , "freebsd-arch@freebsd.org" , freebsd-fcp@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <994430B6-A8BC-4A1F-B15A-41E71DE5D47F@gid.co.uk> References: <20181023233716.GA15106@spindle.one-eyed-alien.net> <201810240002.w9O02tXg025019@pdx.rh.CN85.dnsmgr.net> <9257C84A-CA7C-42B9-9AD8-89AE33C96356@gid.co.uk> To: Warner Losh X-Mailer: Apple Mail (2.3273) X-Mailman-Approved-At: Wed, 24 Oct 2018 15:01:08 +0000 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, 24 Oct 2018 14:55:17 -0000 > On 24 Oct 2018, at 14:39, Warner Losh wrote: >=20 > [stuff trimmed] >=20 >> >> The FCP process itself is unclear on this point, >> >> I think this should be clarified. >> >>=20 >> >> It is much more clear on post approval: >> >> Changes after acceptance >> >>=20 >> >> FCPs may need revision after they have been moved into the >> >> accepted state. In such cases, the author SHOULD update the >> >> FCP to reflect the final conclusions. >> >> If the changes are major, the FCP SHOULD be withdrawn >> >> and restarted. >> >>=20 >> >=20 >> > Good point Rod. While common sense suggests that trivial changes = during the >> > voting should be allowed for editorial purposes (eg fix grammar = mistakes, >> > table rendering etc), it's better to spell that out so there's no = confusion. >> >=20 >> > diff --git a/fcp-0000.md b/fcp-0000.md >> > index b4fe0f3..c8cc6f7 100644 >> > --- a/fcp-0000.md >> > +++ b/fcp-0000.md >> > @@ -144,7 +144,10 @@ When the discussion of a change has come to a = suitable >> > and acceptable close it >> > SHOULD be updated to the `vote` state. >> >=20 >> > At this time the FreeBSD Core Team will vote on the subject of the = FCP. The >> > -result of vote moves the FCP into the `accepted` or `rejected` = state. >> > +result of vote moves the FCP into the `accepted` or `rejected` = state. The >> > +core team MAY make minor edits to the FCP to correct minor = mistakes. Core >> > +MAY return the proposal to the submitter if there are major = problems that >> > +need to be addressed. >>=20 >> This is a Bad Idea, because it relies on common understanding of what = is minor. I was once involved with a standards body that had a procedure = for so-called clerical errors intended to deal with typos, punctuation = etc; this worked just fine until somebody claimed that the omission of = the word =E2=80=9Cnot=E2=80=9D in a particular place was clearly a = clerical error. >=20 > This documents procedure. It's not law. Trying to read it as law is a = mistake: it's written to be brief and descriptive, not through and = prescriptive. And that's on purpose. Axiom 1 of the bylaws is that you = can trust the core team, which is why the power grant is total and = unequivocal: Core is the governing body of the project. If you can't = trust the core team and need anything more, you've already list. And = over the years core's biggest failing isn't some fleet of black = helicopters dispatched to take out critics or other shenanigans. It's = either been not doing enough for the situation (due to too little time = and/or a mistaken impression that they couldn't do anything), or it's = lack of clear communication either between the different 'hats' and core = or between core and the rest of the project. >=20 > Warner=20 No problem with any of that. If the intent is that =E2=80=9Ccore MAY = make unrestricted changes to the FCP and/or MAY return the proposal to = the submitter if there are problems that need to be addressed=E2=80=9D = then say so. -- Bob Bishop t: +44 (0)118 940 1243 rb@gid.co.uk m: +44 (0)783 626 4518 From owner-freebsd-stable@freebsd.org Wed Oct 24 16:05:13 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3EDEFFA6E6 for ; Wed, 24 Oct 2018 16:05:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-10.consmr.mail.ne1.yahoo.com (sonic313-10.consmr.mail.ne1.yahoo.com [66.163.185.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7E97F6B624 for ; Wed, 24 Oct 2018 16:05:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: US1MJ0QVM1k5HBzh9vZtAHdo9lfu5VrBKableH58Ks4uSZjgPv4mO5GSIbi6nBe tWoD3YmGsVE4DM193_ji2vTZSjMXm.aZ3b_RopOCLIe_bHqSoGEKZG8YPmNuISAS8sYpRfujjGaq hf1IfVN6nhuykE5CqeZ4fZs9i5NlV6GGQgd.fTI1eORjJOemGlPU4qs6MYdIweaBs_hB3h83tNb4 LJVOUPS3JQ2QJYJeKaKJCaeQu.o.YFZ2UPSNCtwAGNENn1zDz83V_9uQjPJAViiWW56k2BtWg82j H.iTFiHS2sZgtJEO1iJ8wJIkeMczZTCAsQnJNfZSMu2iRuhAxdcU9DF_NzECaXE6HQQFRfb4tXV8 9DHvFCkRtmaXfp67W4D2zwuPPdYY9g9b7aVOlDA_bvwGjg8f2hRKJSQWEi2TmUyAkw_XdacDD2Nz qB_D_DK1UiYpTkZGoU49dAtyAqDQhAPujzPLg9r33w_g5c1UiV27e6mVctkuxYElM8q2YYm_GpDv sKOueEoNb6EhUUwYZoUvfDikF5ErwoEDYEW8Q3Lhgok7ZA9AtBQISDn8nLRe_sX2KRimXmr6EvSK y.ozsfL48QNudrI.OPgMTPKJRnwujjnKjrwOeWAD4G_lE9yjvVV8wTCoZf.nDfqg.Ccz.EHOVGQr bQmbFJVhK66894WoMSdynWBVGuxXhNFq0OUp5U82ol5OrTuW_ziJFhcz8gVSKpnbhd8FB09qbnLL 1T8FeZQKU7AbC5Jw2BA6uVGjVFMctWdy75CvFEJSESjQMAAqacmwn_dDLVZjUAqargJQEhi9T_u7 vLcJ5vDAswo46xre1qS2DPo0yqlbJnNEFvWXjdoXTOROwQPjZ8TyMRuhKnhc4ehEm5IWEGhIzGRw 6bNlh.v..d7_wizxt8o2giN0wLeIrfxDmh6dhLUBxqZHw8Uewh20sbX_NpRxl.miaqTwNik_rhoS SWoIQCRZoTKv0Dl8ys9Et3uGaRa8jnqj3FIEhEYTZn0vjzFnt1Ewc..HIiLXgrX35MrIFVvcIPlw mtoE7TireBIi8arlDCzclflGBRNR8mps- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Wed, 24 Oct 2018 16:05:05 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp418.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID bccb81049a0f896ad365db04d012617e for ; Wed, 24 Oct 2018 16:05:04 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: What will be tier 1 for 12.0-Release? Message-Id: <28598E3E-C249-4E1D-B289-8B67E5FB56AC@yahoo.com> Date: Wed, 24 Oct 2018 09:05:01 -0700 To: FreeBSD-STABLE Mailing List X-Mailer: Apple Mail (2.3445.9.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: Wed, 24 Oct 2018 16:05:13 -0000 I note that https://pkg.freebsd.org/ does not list FreeBSD:12:aarch64 under the Tier-2 support Package sets but instead on the list with i386 and amd64. But the same is true for FreeBSD:11:aarch64 . FreeBSD:12:armv7 is listed in the Tier-2 support package sets list. The same is true for FreeBSD:12:armv6 . https://www.freebsd.org/platforms/ and = https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/arch= s.html are, of course, not updated so far. (12.0 is not released yet and may be nothing is changing in the status.) It may be that the FreeBSD Core Team has not yet covered this for 12.0 or that it waits to see how the release goes for the potential status changes before declaring a status changed. (So I may be asking this too early.) Just curious. Good to see that there are pkg builds for powerpc64 these days: FreeBSD:12:powerpc64 and FreeBSD:11:powerpc64 are listed in the Tier-2 support package sets list as well. Technically the reported lists are from: pkg0.isc.freebsd.org =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-stable@freebsd.org Wed Oct 24 16:21:14 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23306FFB319 for ; Wed, 24 Oct 2018 16:21:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B2DC86C2C9 for ; Wed, 24 Oct 2018 16:21:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x935.google.com with SMTP id o17so2082045uad.8 for ; Wed, 24 Oct 2018 09:21:13 -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=S2GkuqoOcw3eXkXPv20x3JAbA/7gPML1CjsHqVTpkk8=; b=bju4fU9K+vY+MA8dSTYZICAvHHp7Jdpa0GwjX13uHbVkS5b5Vx7Pzd4qfhoPRtfx1c 1AMms+3zybWKDD/BdEgMlFxQxqebQ/Elb5VD8AtPRxN0tCTT1Ag4dYTFR6IF186s6rtP wYUcw3sPGV7gGoJaUOM0rffoOJBLoE9QY1r6495mHGV2g0DwFqWf8iSjTuMtuIhnL5bt tY4W/OwH8sRb7fza7pP98Ds8O6XBEIXeauKhBlpXACqfw6Ep7b0vCfjk9I3ZUKl0lKm3 YcQEdV0mgba/JcTzytIGnMvrDmOOe7p/6TF/CpPrZxstaeAQzUFwFAohA3MvbAuVHmuh T5uA== 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=S2GkuqoOcw3eXkXPv20x3JAbA/7gPML1CjsHqVTpkk8=; b=mXWYUM3A+h15mmeCx9cB1ONMy2T0HEOLW48msAMxuFG6+auSfInce95WWXFL+gqSzy ay2J8Oh1954qYcjkwRVT3kInwOJCpE8oRK8gx7pxj310LVltBSf7RphxOehu6brbvXPS HfmOPbWc8+O1huxz2PVEoDzwiHt3kPiNuzfdRjU7i4K5bdC3FTbOKPdFJKjlxUo7zXas Wq085P2VL9S3MgSnuZ50E8LFGT9bfQmdOJM+2NtSEthQrMroebjcHUZZkZAKrJHbPEnW gFyYeTAFFdacMjgcqlemG1baFUY0fdHnTx7l+RzH4OAvEFmhwnsAMr92N7XEni1cwAKg 7vgw== X-Gm-Message-State: AGRZ1gKLpuzE/hv/1QBSaFbJrDNqF5nSbBYGkgdiXtCaXnde4mX6Sfbu fp0rT8GmsgHiOab9v04bU/c6j1bp8NpMBNrpDK1TD44I X-Google-Smtp-Source: AJdET5fGFliXSvyXVJyobkv986YDY0zGz2u3dN9ctwXmR1v7WxjIHyNR+aoAfhIkQ9DyFlJdn68VnJjqmCDR2xatosQ= X-Received: by 2002:ab0:2086:: with SMTP id r6mr1484336uak.39.1540398072863; Wed, 24 Oct 2018 09:21:12 -0700 (PDT) MIME-Version: 1.0 References: <28598E3E-C249-4E1D-B289-8B67E5FB56AC@yahoo.com> In-Reply-To: <28598E3E-C249-4E1D-B289-8B67E5FB56AC@yahoo.com> From: Warner Losh Date: Wed, 24 Oct 2018 10:21:01 -0600 Message-ID: Subject: Re: What will be tier 1 for 12.0-Release? To: Mark Millard Cc: FreeBSD-STABLE Mailing List 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: Wed, 24 Oct 2018 16:21:14 -0000 My sense is that amd64 is tier 1. i386, armv7 and arm64 are close. armv6 and armv5 are tier2. Warner On Wed, Oct 24, 2018 at 10:06 AM Mark Millard via freebsd-stable < freebsd-stable@freebsd.org> wrote: > I note that https://pkg.freebsd.org/ does not list FreeBSD:12:aarch64 > under the Tier-2 support Package sets but instead on the list with > i386 and amd64. But the same is true for FreeBSD:11:aarch64 . > > FreeBSD:12:armv7 is listed in the Tier-2 support package sets list. > The same is true for FreeBSD:12:armv6 . > > https://www.freebsd.org/platforms/ and > > https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/archs.html > are, of course, not updated so far. (12.0 is not released yet and may be > nothing is changing in the status.) > > It may be that the FreeBSD Core Team has not yet covered this for > 12.0 or that it waits to see how the release goes for the potential > status changes before declaring a status changed. (So I may be > asking this too early.) > > Just curious. > > > Good to see that there are pkg builds for powerpc64 these > days: FreeBSD:12:powerpc64 and FreeBSD:11:powerpc64 are > listed in the Tier-2 support package sets list as well. > > > Technically the reported lists are from: pkg0.isc.freebsd.org > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > _______________________________________________ > 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 Oct 24 16:29:07 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CDFD5FFBB69 for ; Wed, 24 Oct 2018 16:29:06 +0000 (UTC) (envelope-from ciunas.bennett@intel.com) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "orsmga101.jf.intel.com", Issuer "COMODO RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3CB3D6CAB6 for ; Wed, 24 Oct 2018 16:29:06 +0000 (UTC) (envelope-from ciunas.bennett@intel.com) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2018 09:27:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,421,1534834800"; d="c'?scan'208,217";a="80598784" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by fmsmga007.fm.intel.com with ESMTP; 24 Oct 2018 09:27:53 -0700 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.4]) by IRSMSX102.ger.corp.intel.com ([169.254.2.67]) with mapi id 14.03.0319.002; Wed, 24 Oct 2018 17:27:53 +0100 From: "Bennett, Ciunas" To: "freebsd-stable@freebsd.org" Subject: Possible memory leak in the kernel (contigmalloc) Thread-Topic: Possible memory leak in the kernel (contigmalloc) Thread-Index: AdRrtbzKvvQI2iPZToSPdiaEvmHIXQ== Date: Wed, 24 Oct 2018 16:27:52 +0000 Message-ID: <770FD3608C9E864796AB46CB37B561B1BDFCF0CD@IRSMSX101.ger.corp.intel.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjYwNjRkOTQtNTcxYS00YWYyLWExM2QtNDg5MjkwZDY5MzQzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiTTB1Z1wvaXFGUnNFTTdDbGFlOVF4RWZ2ZXVrckQ1ZzFtM0ptbTNzUDlHSWpMMk5MTUpjNmJIMmRyNVhBdjI5Z0gifQ== x-originating-ip: [163.33.239.180] Content-Type: multipart/mixed; boundary="_005_770FD3608C9E864796AB46CB37B561B1BDFCF0CDIRSMSX101gercor_" MIME-Version: 1.0 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, 24 Oct 2018 16:29:07 -0000 --_005_770FD3608C9E864796AB46CB37B561B1BDFCF0CDIRSMSX101gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hello, I have encountered an issue with a kernel application that I have written, = the issue might be caused by a memory leak in the kernel. The application allocates and deallocates contiguous memory using contigma= lloc() and contigfree(). The application will fail after a period of time because there is not enoug= h free contiguous memory left. There could be an issue with the freeing of memory when using the contigfre= e() function. I have attached a simplified version of the application. The resulting kernel module just allocates contiguous memory and then frees= the memory using contigfree(); This allocation is done in a loop and the attached src code triggers the i= ssue. After a period of time when running the application multiple times, the ker= nel reports that there is no available memory and fails with allocation. I can see that the amount of free memory is decreasing in correlation to ho= w many times I run the application by using DDB and printing out freepages using "= show freepages" I run the application in a loop using a shell script where I kldload then k= ldunload multiple times (script runs up to 1000000) The application can take 20 to over 60 minutes to trigger the issue and run= out of memory but can take longer also. I am running the application on -> FreeBSD on 11.2 VM with 2 Gb of ram. Allocating one cpu core. Running on an Intel(R) Xeon(R) CPU E5-2658 v2 @ 2.40GH using Ubuntu 16.04 h= ost. I have attached the test kernel application and a Makefile. Thanks, Ciunas. -------------------------------------------------------------- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the s= ole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact = the sender and delete all copies. --_005_770FD3608C9E864796AB46CB37B561B1BDFCF0CDIRSMSX101gercor_ Content-Type: text/plain; name="k_memory_contig.c" Content-Description: k_memory_contig.c Content-Disposition: attachment; filename="k_memory_contig.c"; size=1866; creation-date="Wed, 17 Oct 2018 13:33:35 GMT"; modification-date="Wed, 17 Oct 2018 13:33:35 GMT" Content-Transfer-Encoding: base64 I2luY2x1ZGUgPHN5cy9wYXJhbS5oPgojaW5jbHVkZSA8c3lzL2NvbmYuaD4KI2luY2x1ZGUgPHN5 cy9rZXJuZWwuaD4KI2luY2x1ZGUgPHN5cy9tYWxsb2MuaD4KI2luY2x1ZGUgPHN5cy9tb2R1bGUu aD4KI2luY2x1ZGUgPHN5cy9zeXN0bS5oPgoKI2RlZmluZSBERVZfTUVNICJ0ZXN0X21lbSIKCk1B TExPQ19ERUNMQVJFKFRFU1RfTUVNKTsKTUFMTE9DX0RFRklORShURVNUX01FTSwgInRlc3RfbWVt IiwgInRlc3RfbWVtIGRyaXZlciIpOwoKLyogVGVzdCBhcHBsaWNhdGlvbiB0byBhbGxvY2F0ZSBj b250aWd1b3VzIG1lbW9yeSB0aGVuIGZyZWUgaXQgKi8Kc3RhdGljIGludCB0ZXN0X2FwcGxpY2F0 aW9uKCkKewogICAgaW50IGkgPSAwOwogICAgaW50IGFycmF5WzEwXSA9IHsyMDk3MTUyLCAxMDI0 LCAyMTAxMjQ4LCAxMDI0LCAyMDk3MTUyLCAyMTAxMjQ4LAogICAgICAgICAgICAgICAgICAgICAy MTAxMjQ4LCAyMDk3MTUyLCAyMTAxMjQ4LCAxMDI0fTsKICAgIGludCBhcnJheTFbMTBdID0gezEw MjQsIDIxMDEyNDgsIDIwOTcxNTIsIDIxMDEyNDgsIDIxMDEyNDgsIDIwOTcxNTIsCiAgICAgICAg ICAgICAgICAgICAgICAxMDI0LCAyMTAxMjQ4LCAxMDI0LCAyMDk3MTUyfTsKICAgIHZvaWQgKm1l bV9ibG9ja3NbMTBdOwoKICAgIGZvciAoaSA9IDA7IGkgPCAxMDsgaSsrKQogICAgewogICAgICAg IG1lbV9ibG9ja3NbaV0gPSBjb250aWdtYWxsb2MoYXJyYXlbaV0sIFRFU1RfTUVNLCAwLCAwLCB+ MCwgUEFHRV9TSVpFLCAwKTsKICAgICAgICBpZiAoIW1lbV9ibG9ja3NbaV0pCiAgICAgICAgewog ICAgICAgICAgICBwcmludGYoIiVzOiVkIFVuYWJsZSB0byBhbGxvY2F0ZSBjb250aWd1b3VzIG1l bW9yeSBzbGFiIFxuIiwgX19mdW5jX18sCiAgICAgICAgICAgICAgICAgICBfX0xJTkVfXyk7CiAg ICAgICAgICAgIHJldHVybiAtMTsKICAgICAgICB9CiAgICB9CgogICAgZm9yIChpID0gMDsgaSA8 IDEwOyBpKyspCiAgICAgICAgY29udGlnZnJlZShtZW1fYmxvY2tzW2ldLCBhcnJheVtpXSwgVEVT VF9NRU0pOwoKICAgIGZvciAoaSA9IDA7IGkgPCAxMDsgaSsrKQogICAgewogICAgICAgIG1lbV9i bG9ja3NbaV0gPSBjb250aWdtYWxsb2MoYXJyYXkxW2ldLCBURVNUX01FTSwgMCwgMCwgfjAsIFBB R0VfU0laRSwgMCk7CiAgICAgICAgaWYgKCFtZW1fYmxvY2tzW2ldKQogICAgICAgIHsKICAgICAg ICAgICAgcHJpbnRmKCIlczolZCBVbmFibGUgdG8gYWxsb2NhdGUgY29udGlndW91cyBtZW1vcnkg c2xhYiBcbiIsIF9fZnVuY19fLAogICAgICAgICAgICAgICAgICAgX19MSU5FX18pOwogICAgICAg ICAgICByZXR1cm4gLTE7CiAgICAgICAgfQogICAgfQoKICAgIGZvciAoaSA9IDA7IGkgPCAxMDsg aSsrKQogICAgICAgIGNvbnRpZ2ZyZWUobWVtX2Jsb2Nrc1tpXSwgYXJyYXkxW2ldLCBURVNUX01F TSk7CgogICAgcmV0dXJuIDA7Cn0KCnN0YXRpYyBpbnQgbWVtX21vZGV2ZW50KG1vZHVsZV90IG1v ZCBfX3VudXNlZCwKICAgICAgICAgICAgICAgICAgICAgICAgICAgIGludCB0eXBlLAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgdm9pZCAqZGF0YSBfX3VudXNlZCkKewoKICAgIHN3aXRjaCAo dHlwZSkKICAgIHsKICAgICAgICBjYXNlIE1PRF9MT0FEOgogICAgICAgICAgICB0ZXN0X2FwcGxp Y2F0aW9uKCk7CiAgICAgICAgICAgIHJldHVybiAoMCk7CiAgICAgICAgY2FzZSBNT0RfVU5MT0FE OgogICAgICAgICAgICByZXR1cm4gKDApOwogICAgICAgIGRlZmF1bHQ6CiAgICAgICAgICAgIHJl dHVybiAoRU9QTk9UU1VQUCk7CiAgICB9Cn0KCkRFVl9NT0RVTEUodGVzdF9tZW0sIG1lbV9tb2Rl dmVudCwgTlVMTCk7Ck1PRFVMRV9WRVJTSU9OKHRlc3RfbWVtLCAxKTsK --_005_770FD3608C9E864796AB46CB37B561B1BDFCF0CDIRSMSX101gercor_ Content-Type: application/octet-stream; name="Makefile" Content-Description: Makefile Content-Disposition: attachment; filename="Makefile"; size=67; creation-date="Wed, 17 Oct 2018 13:33:25 GMT"; modification-date="Wed, 17 Oct 2018 13:33:04 GMT" Content-Transfer-Encoding: base64 S01PRD0Ja19tZW1vcnlfYXBwClNSQ1M9CWtfbWVtb3J5X2NvbnRpZy5jCgouaW5jbHVkZSA8YnNk Lmttb2QubWs+Cg== --_005_770FD3608C9E864796AB46CB37B561B1BDFCF0CDIRSMSX101gercor_-- From owner-freebsd-stable@freebsd.org Wed Oct 24 16:39:44 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B20DFFC1E9 for ; Wed, 24 Oct 2018 16:39:44 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [18.222.6.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C976E6D336 for ; Wed, 24 Oct 2018 16:39:43 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (unknown [18.188.142.31]) by mail.soaustin.net (Postfix) with ESMTPSA id 096482EBA8; Wed, 24 Oct 2018 16:39:43 +0000 (UTC) Date: Wed, 24 Oct 2018 16:39:41 +0000 From: Mark Linimon To: Warner Losh Cc: Mark Millard , FreeBSD-STABLE Mailing List Subject: Re: What will be tier 1 for 12.0-Release? Message-ID: <20181024163940.GA11768@lonesome.com> References: <28598E3E-C249-4E1D-B289-8B67E5FB56AC@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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, 24 Oct 2018 16:39:44 -0000 > > Good to see that there are pkg builds for powerpc64 these > > days: FreeBSD:12:powerpc64 and FreeBSD:11:powerpc64 are > > listed in the Tier-2 support package sets list as well. uh ... those were probably the last ones I did. AFAIK no package building has been done at isc for years. mcl From owner-freebsd-stable@freebsd.org Wed Oct 24 16:43:51 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD411FFC535 for ; Wed, 24 Oct 2018 16:43:51 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [18.222.6.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 808026D858 for ; Wed, 24 Oct 2018 16:43:51 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (unknown [18.188.142.31]) by mail.soaustin.net (Postfix) with ESMTPSA id C8FB32EBA8; Wed, 24 Oct 2018 16:43:50 +0000 (UTC) Date: Wed, 24 Oct 2018 16:43:49 +0000 From: Mark Linimon To: Warner Losh Cc: Mark Millard , FreeBSD-STABLE Mailing List Subject: Re: What will be tier 1 for 12.0-Release? Message-ID: <20181024164349.GB11768@lonesome.com> References: <28598E3E-C249-4E1D-B289-8B67E5FB56AC@yahoo.com> <20181024163940.GA11768@lonesome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181024163940.GA11768@lonesome.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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, 24 Oct 2018 16:43:52 -0000 On Wed, Oct 24, 2018 at 04:39:41PM +0000, Mark Linimon wrote: > uh ... those were probably the last ones I did. never mind, this is a new machine under test. I missed seeing the listing even when I looked at pkg.FreeBSD.org ... earlier today. mcl From owner-freebsd-stable@freebsd.org Wed Oct 24 17:51:20 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC871FFEE93; Wed, 24 Oct 2018 17:51:20 +0000 (UTC) (envelope-from danfe@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)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8377F71306; Wed, 24 Oct 2018 17:51:20 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1033) id 554969405; Wed, 24 Oct 2018 17:51:20 +0000 (UTC) Date: Wed, 24 Oct 2018 17:51:20 +0000 From: Alexey Dokuchaev To: Warner Losh Cc: Ian Lepore , michelle@sorbs.net, FreeBSD-STABLE Mailing List , FreeBSD Net , "freebsd-arch@freebsd.org" , freebsd-fcp@freebsd.org Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers Message-ID: <20181024175120.GA9818@FreeBSD.org> References: <20181003210516.GA71565@spindle.one-eyed-alien.net> <55a44e73-60ab-e386-360a-b0a0198a0e71@zyxst.net> <8878cac1-d5d2-4224-6aa5-85516db23c14@sorbs.net> <1538673997.14264.9.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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, 24 Oct 2018 17:51:21 -0000 On Thu, Oct 04, 2018 at 11:38:46AM -0600, Warner Losh wrote: > ... > I'd also suggest that rl stands in stark contrast to the cs, wb, sn, smc, > sf, tl, tx and vr drivers, which nobody has mentioned in this thread, and > which I doubt are in use in any FreeBSD system of any age today. Warner, I had mentioned [*] that I'm using sf(4), would you please be more careful when collecting "NICs still in use" data? We really do need a wiki page and carefully relect all the feedback we've received so far and also upcoming one. ./danfe [*] Message-ID: <20181004084411.GA50348@FreeBSD.org> From owner-freebsd-stable@freebsd.org Wed Oct 24 18:12:26 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 67662FFFFB4; Wed, 24 Oct 2018 18:12:26 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E3BE672FAA; Wed, 24 Oct 2018 18:12:25 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id w9OICHVN021010 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 24 Oct 2018 11:12:18 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id w9OICHe2021009; Wed, 24 Oct 2018 11:12:17 -0700 (PDT) (envelope-from jmg) Date: Wed, 24 Oct 2018 11:12:17 -0700 From: John-Mark Gurney To: "Rodney W. Grimes" Cc: FreeBSD-STABLE Mailing List , FreeBSD Net , "freebsd-arch@freebsd.org" , freebsd-fcp@freebsd.org Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers Message-ID: <20181024181217.GC75530@funkthat.com> Mail-Followup-To: "Rodney W. Grimes" , FreeBSD-STABLE Mailing List , FreeBSD Net , "freebsd-arch@freebsd.org" , freebsd-fcp@freebsd.org References: <9257C84A-CA7C-42B9-9AD8-89AE33C96356@gid.co.uk> <201810241219.w9OCJXTd027720@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201810241219.w9OCJXTd027720@pdx.rh.CN85.dnsmgr.net> X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Wed, 24 Oct 2018 11:12:18 -0700 (PDT) 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, 24 Oct 2018 18:12:26 -0000 Rodney W. Grimes wrote this message on Wed, Oct 24, 2018 at 05:19 -0700: > And I have read case law that boiled down to the presents vs absence > of a comma in an agreement that had results far beyond "minor". For those currious about this case: https://www.bostonglobe.com/business/2017/03/16/lack-oxford-comma-costs-maine-company-millions-overtime-dispute/BIxK837fA2C06qavQMDs5J/story.html -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-stable@freebsd.org Wed Oct 24 19:04:29 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F34811036C72; Wed, 24 Oct 2018 19:04:28 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 7A0E4756A8; Wed, 24 Oct 2018 19:04:28 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w9OJ4Qcb030115; Wed, 24 Oct 2018 12:04:26 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w9OJ4Q1Z030114; Wed, 24 Oct 2018 12:04:26 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201810241904.w9OJ4Q1Z030114@pdx.rh.CN85.dnsmgr.net> Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers In-Reply-To: <20181024181217.GC75530@funkthat.com> To: John-Mark Gurney Date: Wed, 24 Oct 2018 12:04:26 -0700 (PDT) CC: FreeBSD-STABLE Mailing List , FreeBSD Net , "freebsd-arch@freebsd.org" , freebsd-fcp@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII 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, 24 Oct 2018 19:04:29 -0000 > Rodney W. Grimes wrote this message on Wed, Oct 24, 2018 at 05:19 -0700: > > And I have read case law that boiled down to the presents vs absence > > of a comma in an agreement that had results far beyond "minor". > > For those currious about this case: > https://www.bostonglobe.com/business/2017/03/16/lack-oxford-comma-costs-maine-company-millions-overtime-dispute/BIxK837fA2C06qavQMDs5J/story.html For those more interested: https://law.justia.com/cases/federal/appellate-courts/ca1/16-1901/16-1901-2017-03-13.html And I was wrong, it is a US case, though I am sure there is other similiar case law on other books. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-stable@freebsd.org Wed Oct 24 15:49:00 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF2E7FF1AC0; Wed, 24 Oct 2018 15:48:59 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (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 74BD66A814; Wed, 24 Oct 2018 15:48:59 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id CAEC53C475F; Wed, 24 Oct 2018 15:48:57 +0000 (UTC) Date: Wed, 24 Oct 2018 15:48:57 +0000 From: Brooks Davis To: "Rodney W. Grimes" Cc: Mark Linimon , Bob Bishop , FreeBSD-STABLE Mailing List , Ian Lepore , FreeBSD Net , "Julian H. Stacey" , Michelle Sullivan , "freebsd-arch@freebsd.org" , freebsd-fcp@freebsd.org Subject: Re: FCP-0101: Deprecating most 10/100 Ethernet drivers Message-ID: <20181024154857.GB15429@spindle.one-eyed-alien.net> References: <20181024134153.GC3125@lonesome.com> <201810241354.w9ODs1MD028342@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GID0FwUMdk1T2AWN" Content-Disposition: inline In-Reply-To: <201810241354.w9ODs1MD028342@pdx.rh.CN85.dnsmgr.net> User-Agent: Mutt/1.9.4 (2018-02-28) X-Mailman-Approved-At: Wed, 24 Oct 2018 19:04:35 +0000 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, 24 Oct 2018 15:49:00 -0000 --GID0FwUMdk1T2AWN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 24, 2018 at 06:54:01AM -0700, Rodney W. Grimes wrote: > > On Wed, Oct 24, 2018 at 05:19:33AM -0700, Rodney W. Grimes wrote: > > > And I have read case law that boiled down to the presents vs absence > > > of a comma > >=20 > > If we are now going to evaluate all proposed changes to FreeBSD on the > > same rigid principles as the US legal system, I'm done. >=20 > I do not think "all" is in scope here, > but I do feel should excercise care about procedure. > And FYI, the case law above I am pretty sure was not US. >=20 > I also believe that what is at issue here can be fixed > rather easily without ever going down the minor vs major > slippery slope by some rather simple changes to order > of events and careful steps. >=20 > Warner came very close, I think he just applied his correct > "fix" to 1/2 of the problem. >=20 > There is the stage where the FCP is before core being voted > on, and there is the stage that the FCP has been approved. > He only addressed 1 of those, and he did so by allowing core > to trivially modify the document during the voting process, > and I am actually fine with that idea, its good, it is what > should be allowed. I trust core to know what is minor vs > major. >=20 > BUTT it still does not cover the issue of the author/submitter > modifying the document while it is in core being reviewed and > possibly modified. I have issue with that. It is very hard > to vote/formally review on something that is fluid. > I have not been asked to trust these people with the trust I > give core, so I would like to remove that. There are technical measures in place that do much of this already. Right now, authors can't directly change the documents (unless they are repo admins which means core and former core members in practice). We require that pull requests be reviewed before they are merged and random people don't have commit access. We could make the restriction to core members or core members and fcp-editors explicit if that was desirable. > We could add that once the document is submitted to core > any change to it between submitting and vote by core requires > core to be involved, even if it is simply an ack of a change > has been made to what was submitted. I agree. We'll need to think on how best to do this. -- Brooks --GID0FwUMdk1T2AWN Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJb0JRpAAoJEKzQXbSebgfAv6EH/j7y74E12k7JrbntothAjhfl 1u1bRpib5ZoIE5nCeCS6l+ZqHvkJIxvmbqm9ksBsLG36GFbUOBHMnvY43KCHq87r NOQ4LoncmDljiDnakMALcf7qyMiWLjHBxod0AtUrBE+Wof9qB/kiJ3MWmt6ou11W nuXhhiJsxR4bTAFoBlP+91X0BgcNomUyQLX537hEzgw4jI7lfp3liw00T9enWAV+ NAU9smJhXuUPca2hAcDtcPkpQG3tVweQKLGSWrr9HDxb2FQUNZVHzwccEJwg1sc3 LgUvjJfrOArCUvaZLzopgbMBuZbx/vnJSEqQySnRihEk00JYR42mp7iqNv22DRc= =Pfsi -----END PGP SIGNATURE----- --GID0FwUMdk1T2AWN-- From owner-freebsd-stable@freebsd.org Wed Oct 24 20:04:09 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 516541039650 for ; Wed, 24 Oct 2018 20:04:09 +0000 (UTC) (envelope-from eva.randolph@asertify.com) Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D0C7277ABF for ; Wed, 24 Oct 2018 20:04:08 +0000 (UTC) (envelope-from eva.randolph@asertify.com) Received: by mail-lf1-x142.google.com with SMTP id m18-v6so4965256lfl.11 for ; Wed, 24 Oct 2018 13:04:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=asertify.com; s=google; h=mime-version:sender:from:date:message-id:subject:to; bh=OJgIWIElkzBwL/Oh47TksLCK5t8p6sI/eX7BVMV/S9M=; b=NkPiO6OuguT4yMyJVLed8jvpeq7f678By6zefvMKoryN3p/jBQnAoBYnytXKnZ1iCT m0u0209ba5+mUa2n8gYj0ITpFV2huuYekuqSM5EZ4BlDyx+9v5KcI6BCCn/bTExfQdOg wuc+pw+ZvpFELVmxgy3CtrrKsMWc5N695LgKQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=OJgIWIElkzBwL/Oh47TksLCK5t8p6sI/eX7BVMV/S9M=; b=FYmyfKe5koSeJQHZT9XhtZ2iytrVk/ubHlMwC1QGnWvoawRmsPDzBE6l9CCZL18MmH I2S9VEuXm/jLxcKqGOi265ZvBhqtehtbVXWTw/Ce6DgmRwnzY2WHa8DRmZ2bPkJVBJ11 tWjJkgm4qTCx8ymQTdD+336OgFP5ZZEf9fRIT9inC4w0ol7CmSVBJzkQwL38IZF4yOmy +YP0snEhmJUVpinhveIEEn0Va4uf0N8JLEReZhNV7KxqrsapBPKdmT5gJxa8A4GBTpK/ H9aeLA18ZXV0OwdFBHCVeED6XAftcx9uTSz3cgv7jo01pbBdkVQ9hH38dIAIW8G+LAd7 ZkzQ== X-Gm-Message-State: ABuFfoi92VQcbaRcI60+2FFjBjOCl/SpOyiYfl/Qqz9wjrd7q63la5SC or9La8O5UwVZh8hsvYmfa7oZ5igO6iKrLzKdhE8BsmWkYiU= X-Google-Smtp-Source: ACcGV61GWBUKBOa6F3T+zPqyFC/GaKeojyHIyLoehwMOwezflquQm4ZaD81DJ1mRLoDjllW9IRXQM7piTkhdzMzsy60= X-Received: by 2002:a19:8fce:: with SMTP id s75mr15442688lfk.151.1540411446927; Wed, 24 Oct 2018 13:04:06 -0700 (PDT) Received: from 168032441317 named unknown by gmailapi.google.com with HTTPREST; Wed, 24 Oct 2018 22:04:06 +0200 MIME-Version: 1.0 Sender: eva.randolph@asertify.com From: eva.randolph@asertify.com Date: Wed, 24 Oct 2018 22:04:06 +0200 X-Google-Sender-Auth: PYxxbOdc6NtSiy_VS6hW272Lb2o Message-ID: Subject: Global Companies Emails List To: 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: Wed, 24 Oct 2018 20:04:09 -0000 Hi, I just wanted to check if you would be interested in a list of Managed Service Providers (MSPs) and Managed Security Service Providers (MSSPs)? We also have the data intelligence of: =E2=80=A2 Managed Service Providers (MSP=E2=80=99s) =E2=80=93 25,000 unique= companies =E2=80=A2 Managed Security Service Providers (MSSP=E2=80=99s) =E2=80=93 7,5= 20 unique companies =E2=80=A2 IT Decision Makers =E2=80=93 6million across all industry =E2=80=A2 Business Decision Makers =E2=80=93 10 million across all industry =E2=80=A2 Value Added Resellers- VARs =E2=80=A2 Independent Software Vendors- ISVs =E2=80=A2 System Integrators- SIs =E2=80=A2 VoIP Service Providers. =E2=80=A2 Telecommunications Service Providers (TSPs) =E2=80=A2 Application Service Providers (ASPs) =E2=80=A2 IT Managed Services Providers (ITMSP) =E2=80=A2 Storage Service Providers (SSPs) Kindly review and let me know if I can share more information on this. I look forward to hearing from you. Regards, Eva Randoph Marketing Specialist If you don't want to include yourself in our mailing list, please reply back =E2=80=9CLeave Out" in a subject line From owner-freebsd-stable@freebsd.org Fri Oct 26 20:12:42 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F30E2108774C for ; Fri, 26 Oct 2018 20:12:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 6E6D9861F5 for ; Fri, 26 Oct 2018 20:12:41 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w9QKCUHi035681 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 Oct 2018 23:12:33 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w9QKCUHi035681 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w9QKCUbY035680; Fri, 26 Oct 2018 23:12:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 26 Oct 2018 23:12:30 +0300 From: Konstantin Belousov To: "Bennett, Ciunas" Cc: "freebsd-stable@freebsd.org" Subject: Re: Possible memory leak in the kernel (contigmalloc) Message-ID: <20181026201230.GV5335@kib.kiev.ua> References: <770FD3608C9E864796AB46CB37B561B1BDFCF0CD@IRSMSX101.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <770FD3608C9E864796AB46CB37B561B1BDFCF0CD@IRSMSX101.ger.corp.intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home 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, 26 Oct 2018 20:12:42 -0000 On Wed, Oct 24, 2018 at 04:27:52PM +0000, Bennett, Ciunas wrote: > Hello, > > I have encountered an issue with a kernel application that I have > written, the issue might be caused by a memory leak in the kernel. > The application allocates and deallocates contiguous memory using > contigmalloc() and contigfree(). The application will fail after a > period of time because there is not enough free contiguous memory > left. There could be an issue with the freeing of memory when using > the contigfree() function. > It is unlikely that there is an issue with a leak, but I would be not surprised if your allocation/free pattern would cause fragmentation on free lists that results in contigmalloc(9) failures after. Look at the vmstat -z/vmstat -m output to see uma and malloc stats. More interesting for your case can be the output from sysctl vm.phys_free which provides information about the free queues and order of free pages on them. From owner-freebsd-stable@freebsd.org Sat Oct 27 16:01:04 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C9ED10C9076; Sat, 27 Oct 2018 16:01:04 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (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 EA0566F8F5; Sat, 27 Oct 2018 16:01:03 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 0DDB621C1A; Sat, 27 Oct 2018 12:01:03 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 27 Oct 2018 12:01:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h=to :cc:from:subject:message-id:date:mime-version:content-type :content-transfer-encoding; s=fm3; bh=wZmO4DndcMSRSnWG/SfTzIOinf M+PCXrKNQbmz/gY8g=; b=HBcW7jt2dBezgXS3Zv+eElfprn5Re8qF1Mb1Kb4Kc8 RfFhd/UHdZzKFjQY3SGjAEzpDOlC/Sg4vI8UycTTjCstuU8CvdZvU/kRlcx079/h NHnXqAQQQDbHxYJNK7Q8AMqnCuRIYFveJ99Z9RkaxZZqb+MmrxRiZmbPBDgeV2CZ ZuEx+3pdwbT3zyUOgMPZ/qXaFGIcRtKLHHFSV+tGZjxbcUcIPNb6pk4+4a6h0DoK B+bsqr7BHvtddI2oqpVo3Ebps3ONdY0gXCy43ZnxPid1hwtFHYDXxV4nx5k5Oaxb 0f7P0Pd0XGJoZTMBDtilf0hNmB6ThuQA7AY8UQ/EQ28A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=wZmO4D ndcMSRSnWG/SfTzIOinfM+PCXrKNQbmz/gY8g=; b=PkKhOO2Gk6xkQSYlTZPVhi ccSkb/2f2fJ+VfTdAOEUTvEAn4FRg2qVtuGfedSvs15HU9kroHnLuXyoWIvg72B8 nGNHpKlkcrq4M7KEX7qdVzN9oCPMah1hLqBUaYxPBHc9v4cX8gHsIe6t0VRdZxeX OGq7LZ/PtWQwmdX2okpRO52v0jZfHGHm3sgypoXXglf1uX8Z+2S1Z/HKiEr7Cr/F wLtTf72SEmZBvEiOCRb481AZ5WJrCpyHteTAxbDa4T58FtO4yQzMQ4stp1Prtnxj tMCykSQurJK7wdq4e2vjdeYZNJ40vQP0Qf/HMTgVRK9CKjZN0o71LDiNIwSIsvLQ == X-ME-Sender: X-ME-Proxy: Received: from desktop.local (parsley.growveg.org [82.70.91.97]) by mail.messagingengine.com (Postfix) with ESMTPA id 5816AE4A44; Sat, 27 Oct 2018 12:01:02 -0400 (EDT) To: freebsd-wireless@freebsd.org Cc: freebsd-stable@freebsd.org From: tech-lists Organization: none Subject: TP-LINK TL-WN321G Message-ID: Date: Sat, 27 Oct 2018 17:01:00 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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, 27 Oct 2018 16:01:04 -0000 Hi, context: 12-stable amd64 When TP-LINK TL-WN321G usb dongle is inserted, this appears in dmesg: ugen1.3: at usbus1 run0 numa-domain 0 on uhub3 run0: <1.0> on usbus1 run0: MAC/BBP RT5390 (rev 0x0502), RF RT5370 (MIMO 1T1R), address [REDACTED] but run(4) says it supports these: TP-LINK TL-WDN3200 TP-LINK TL-WN727N v3 and run0 appears, and works, yet: rum(4) says it supports this: TP-LINK TL-WN321G but no rum0 happens either on insertion (using standard GENERIC kernel) or with rum loaded. -- J. From owner-freebsd-stable@freebsd.org Sat Oct 27 17:03:51 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24E9310CC8BD; Sat, 27 Oct 2018 17:03:51 +0000 (UTC) (envelope-from gjb@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)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CB70D72395; Sat, 27 Oct 2018 17:03:50 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 4D08110378; Sat, 27 Oct 2018 17:03:50 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Sat, 27 Oct 2018 17:03:48 +0000 From: Glen Barber To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Cc: FreeBSD Release Engineering Team Subject: FreeBSD 12.0-BETA2 Now Available Message-ID: <20181027170348.GN61572@FreeBSD.org> Reply-To: FreeBSD Release Engineering Team MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed User-Agent: Mutt/1.10.1 (2018-07-13) 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, 27 Oct 2018 17:03:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The second BETA build of the 12.0-RELEASE release cycle is now available. Please see the "SPECIAL NOTE" below regarding upgrading from FreeBSD 10.x and 11.x for important information regarding geli(4)-backed filesystems. Also note, pkg(8) builds for consumers of pre-built packages from pkg.freebsd.org are currently in progress, and are expected to be completed roughly within the next 48 hours or so. The status of the package builds for 12.0 can be monitored at: amd64: https://pkg-status.freebsd.org/builds/default:default:120amd64:483081:beefy6 i386: https://pkg-status.freebsd.org/builds/default:default:120i386:483081:beefy5 Installation images are available for: o 12.0-BETA2 amd64 GENERIC o 12.0-BETA2 i386 GENERIC o 12.0-BETA2 powerpc GENERIC o 12.0-BETA2 powerpc64 GENERIC64 o 12.0-BETA2 powerpcspe MPC85XXSPE o 12.0-BETA2 sparc64 GENERIC o 12.0-BETA2 armv6 RPI-B o 12.0-BETA2 armv7 BANANAPI o 12.0-BETA2 armv7 BEAGLEBONE o 12.0-BETA2 armv7 CUBIEBOARD o 12.0-BETA2 armv7 CUBIEBOARD2 o 12.0-BETA2 armv7 CUBOX-HUMMINGBOARD o 12.0-BETA2 armv7 RPI2 o 12.0-BETA2 armv7 PANDABOARD o 12.0-BETA2 armv7 WANDBOARD o 12.0-BETA2 armv7 GENERICSD o 12.0-BETA2 aarch64 GENERIC o 12.0-BETA2 aarch64 RPI3 o 12.0-BETA2 aarch64 PINE64 o 12.0-BETA2 aarch64 PINE64-LTS Note regarding arm SD card images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root. It is strongly recommended to change the password for both users after gaining access to the system. Installer images and memory stick images are available here: https://download.freebsd.org/ftp/releases/ISO-IMAGES/12.0/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "stable/12" branch. A summary of changes since 12.0-BETA1 includes: o A debug option during binary compilation which was missed when branching stable/12 had been turned off. o The gif_interfaces rc.conf(5) variable had been restored. (PR 204700) o The timezone database files have been updated to version 2018f. o The debug.witness.trace entry in sysctl.conf(5) on installation media had been removed. o A system panic triggered by a combination of lagg(4) and vlan(4) had been fixed. (PR 227654) o The ability to prevent interrupting the boot process without entering the password in loader.conf(5) had been fixed. (PR 207069) o Several drivers originally targeted for removal in 12.0-RELEASE had been removed from the GENERIC kernel configuration on amd64 and i386. o An off-by-one error that could lead to a system panic with the sound(4) driver had been fixed. o The mlx5(4) driver had been updated to notify when a port on ConnectX-6 network cards had been turned off due to insufficient power. o The filter_reloc() function in objcopy(1) had been restored, which fixes building GCC. o The shared library version of OpenSSL in the base system had been increased from '9' to '111' in order to prevent shared library version collisions with OpenSSL installed via pkg(8) or the Ports Collection. o Updates to the Linux compatibility layer. o The ae(4), bm(4), cs(4), de(4), dme(4), ed(4), ep(4), ex(4), fe(4), pcn(4), sf(4), sn(4), tl(4), tx(4), txp(4), vx(4), wb(4), and xe(4) drivers have been deprecated. Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 12.0-RELEASE cycle progresses. === Virtual Machine Disk Images === VM disk images are available for the amd64 and i386 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): https://download.freebsd.org/ftp/releases/VM-IMAGES/12.0-BETA2/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 135 MB and 165 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI loader file is needed for qemu-system-aarch64 to be able to boot the virtual machine images. See this page for more information: https://wiki.freebsd.org/arm64/QEMU To boot the VM image, run: % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ -bios QEMU_EFI.fd -serial telnet::4444,server -nographic \ -drive if=none,file=VMDISK,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -device virtio-net-device,netdev=net0 \ -netdev user,id=net0 Be sure to replace "VMDISK" with the path to the virtual machine image. === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: ap-south-1 region: ami-0583e82d9f9b02835 eu-west-3 region: ami-044ce5b3fd2843a38 eu-west-2 region: ami-086a9877c239380f5 eu-west-1 region: ami-0b1ca64572a572ce9 ap-northeast-2 region: ami-02c873fbf77df6121 ap-northeast-1 region: ami-0286bd92d79a033a5 sa-east-1 region: ami-0ac69a7ca63c716de ca-central-1 region: ami-0b438a859e4c53d2d ap-southeast-1 region: ami-07354987a154b009d ap-southeast-2 region: ami-0a92d4f626a93b504 eu-central-1 region: ami-02de1425eea91f842 us-east-1 region: ami-09d9338f8864dfc2b us-east-2 region: ami-00996ecb76c9f185e us-west-1 region: ami-00ca4c4ad84830c4d us-west-2 region: ami-08b7e86ee097b8a62 === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can be installed by running: % vagrant init freebsd/FreeBSD-12.0-BETA2 % vagrant up === Upgrading === === SPECIAL NOTE === This only affects systems that employ geli(4)-backed encrypted filesystems and currently running 11.x or 10.x. Upgrades from 12.0-BETA1, either via source-based upgrades or binary patches via freebsd-update(8), are unaffected. An issue affecting backwards compatibility with geli(4)-backed filesystems and an updated geli(8) binary after r332361 prevents mounting encrypted filesystems with an older geli(8) binary from 11.x and 10.x. For example, if /usr/src and /usr/obj are mount points on an encrypted filesystem, the geli(8) binary that exists from 11.x or 10.x after rebooting the system after 'installworld' will fail to attach the encrypted filesystems when performing a source-based upgrade following the documented upgrade path in UPDATING. For binary upgrades using freebsd-update(8) from 11.x and 10.x, the recommended upgrade flow is to install the kernel patches, reboot, install the userland patches, reboot, remove old libraries after rebuilding third-party software. In this case, the initial reboot after the kernel patches are applied can cause the same scenario where the old geli(8) binary cannot attach the geli(4)-backed filesystem. A fix had been committed to head as r339804, and is expected to be included in BETA3. For those without remote console access and do not wish to upgrade via sources, it is advised to wait for BETA3 to upgrade from 11.x and 10.x. === END SPECIAL NOTE === The freebsd-update(8) utility supports binary upgrades of amd64 and i386 systems running earlier FreeBSD releases. Systems running earlier FreeBSD releases can upgrade as follows: # freebsd-update upgrade -r 12.0-BETA2 During this process, freebsd-update(8) may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install It is recommended to rebuild and install all applications if possible, especially if upgrading from an earlier FreeBSD release, for example, FreeBSD 11.x. Alternatively, the user can install misc/compat11x and other compatibility libraries, afterwards the system must be rebooted into the new userland: # shutdown -r now Finally, after rebooting, freebsd-update needs to be run again to remove stale files: # freebsd-update install == ISO CHECKSUMS == o 12.0-BETA2 amd64 GENERIC: SHA512 (FreeBSD-12.0-BETA2-amd64-bootonly.iso) = 7049f1f36ca0c5d75b2e4d7b7a6737952e11c3ed8f03398abe079e3cae1cfd9076534e555c6206d2c2db1bd84f7d55abf2e9033a47f5dd3dfc1dd9543c7fba6d SHA512 (FreeBSD-12.0-BETA2-amd64-bootonly.iso.xz) = c8144f7bf9e77ffe41ce54b39318511fd78b3a3b0aed6f6035d4f1b982b4fbc3736465afa3db4f190ff772f4e2dd5d009cfcec0e047a2419ddec8ddd7c329d9e SHA512 (FreeBSD-12.0-BETA2-amd64-disc1.iso) = d5f933c0ee8b0f5275055bf8dd5f637c0c5475f7fb1965fb61c7ab8dcd69a8953721d584b2345f78ece85be23f6ad820d701cbbfc7f83eb5cf24d81cf92707e9 SHA512 (FreeBSD-12.0-BETA2-amd64-disc1.iso.xz) = 7fa0315b686e852a81330c5c043d7b75344d7a46c79fd4103cb20b27ea6ec02cb5698acf51378801f8ea67e3faf6880b283d070e9d9171a1bc90a1c25dc0b822 SHA512 (FreeBSD-12.0-BETA2-amd64-dvd1.iso) = 73910edb5920086e0651835a779327cdc859441713f8079d8ec1740fb3b3325c0e4bb91594683215301e9f6520df3cc40837bd40205800cd26e8fab6e8aa91f9 SHA512 (FreeBSD-12.0-BETA2-amd64-dvd1.iso.xz) = c59ee0898fda9250cdb42d34cf58cf97819269e624554f8224b249e6616887e4a31b0d73396cc4085f8326acf173c62ac532ad9da9d7992ee76301224fe0bf16 SHA512 (FreeBSD-12.0-BETA2-amd64-memstick.img) = c530e8aec8d3576873f1c8c49e148ced81323b664c77b32c70e74caadff352f469189497b771c7c72d301c9323206f4d8efe3b718add03d05bbab540ac2e598c SHA512 (FreeBSD-12.0-BETA2-amd64-memstick.img.xz) = 467985f4c9e68ce4524150607946296e798521fdd96417146449fbec7d500ed07a04d9d2ade1503f687389aa8526f483fcd09ebbb9d60dd8b2088a8a62593089 SHA512 (FreeBSD-12.0-BETA2-amd64-mini-memstick.img) = d7b87c89914a03a299112b9433813391158ef8717e80acd43ee2d68fc86ecfffdd1337f6adce319474ea1bb7072dedeed4a4f292b7e8a6664628f17f7c61d40b SHA512 (FreeBSD-12.0-BETA2-amd64-mini-memstick.img.xz) = 163d8cca4364c1a079513ce7109782df257566f2ed18a4560b2ccc3f8f4545f7c939e162415fcd5cd4446279a7f91a2b2bb25ef5299734e3dbd5074f70a0eab3 SHA256 (FreeBSD-12.0-BETA2-amd64-bootonly.iso) = 4cdf796166976f69fe8ad1dbab8809aed3c39ac67b6aa5a098546bd8ee648d24 SHA256 (FreeBSD-12.0-BETA2-amd64-bootonly.iso.xz) = 37961d9e36823d277967b36a41f71eb22b5b48aa7f522f6e0fcf9cfd05690f55 SHA256 (FreeBSD-12.0-BETA2-amd64-disc1.iso) = 783013e07a49dd1e52c71a6be38715068b62ba86c9b603f514aed3445184a3d9 SHA256 (FreeBSD-12.0-BETA2-amd64-disc1.iso.xz) = 6d7d903368acc786166a2fc311155346aabdfbc16e2fcf5b9b12ebf99cccd9ef SHA256 (FreeBSD-12.0-BETA2-amd64-dvd1.iso) = e975916fa7524e56287536196c1398871bec29b78fe21d17239cd89fad55b4f4 SHA256 (FreeBSD-12.0-BETA2-amd64-dvd1.iso.xz) = acec0829d75d3f40c7d0283cb07e0374dfeb34bd6e219f7ad9c54afe233ed35c SHA256 (FreeBSD-12.0-BETA2-amd64-memstick.img) = a52547bc527b109b4291e75fb3c41642b8497e3af6269dc583973eadbc57d46d SHA256 (FreeBSD-12.0-BETA2-amd64-memstick.img.xz) = 69b9b8186e8b07e27f0980d8273baa94f8d78f51b3389bd327673dca06b816f7 SHA256 (FreeBSD-12.0-BETA2-amd64-mini-memstick.img) = cfba4be1c0bced50b65f55432b8f858a63553b40b392ba3b627c12e002ed4536 SHA256 (FreeBSD-12.0-BETA2-amd64-mini-memstick.img.xz) = a542f1a1de60e10b7d42e8659796e3e530d1e386e8ae8493b07c6740a6a3ab5a o 12.0-BETA2 i386 GENERIC: SHA512 (FreeBSD-12.0-BETA2-i386-bootonly.iso) = 4e1a1d94280569a52eac77b2bb9b71920dfa5c30f203f4890f36b040e646f98c1b8e8ed092b05146ea92e9ee5e807be3b68b425037ef8c993f42ae2543da1e46 SHA512 (FreeBSD-12.0-BETA2-i386-bootonly.iso.xz) = 0295d61be8f8be66f1ceca60d35eca5e7a24263ed98023b290dc8e28469397abfa5712ba1e5e2acdb63bfeb025c6238c235cbe7bdc99d785afa24a41872ec099 SHA512 (FreeBSD-12.0-BETA2-i386-disc1.iso) = ae00ad58df05bf137872a0a4d7273088898aca5dc1efc3b19de14594bac2f56c9a33aad1dd20d674ead2cc79aa8c9f4e5f1cf91dc4c809abe98f6d3f647d01e1 SHA512 (FreeBSD-12.0-BETA2-i386-disc1.iso.xz) = d4a8e862419083b72113eaa9ccdf5935472bd0484277efa11b80322702e85506e6f3eed9dcc17168c5486a6ef58eb126443eafde579d60e2dbfee3a22a048d5f SHA512 (FreeBSD-12.0-BETA2-i386-dvd1.iso) = 96a63e831e1a4a133e0bad7d1f05cb62ac87a0f968a9f2faaf9c2dc189923445e0564f780980473e59ea150545c9bc8d5ba032984deddd7364af48712318c9f9 SHA512 (FreeBSD-12.0-BETA2-i386-dvd1.iso.xz) = 697a391e9be31cd68043a13d9b984f628c6aa9a5cb57de8a12908dc2ded6a72532e64c50e08563a059323c5c6783a8b88f5f110280309bbbcaf6fe3d3c60e611 SHA512 (FreeBSD-12.0-BETA2-i386-memstick.img) = 23bebfee595475234d1da16456b151a481f231f8a2b2d586bd2fc21ca54b262439144f129adf0de8c1359ffd096b78113e8feb5fd4ce5c9c35d77bf62cd185c4 SHA512 (FreeBSD-12.0-BETA2-i386-memstick.img.xz) = 4c314a77f70d2ae6aa5ce169ae2384c8985fbdfdae086a198eb386d0f07a6d162e2c3d9ce6e279625e71c665db10b1229e13280e8d1e1d93339cc60cf556ef76 SHA512 (FreeBSD-12.0-BETA2-i386-mini-memstick.img) = ada9820d9a1ed4c5d822a18e1ffd07b847f13bb703b601a436ba0519867d2641ad4fb41527f44e48646559ece2b51a0c7cebaec94845ff9966f330b21cc49d11 SHA512 (FreeBSD-12.0-BETA2-i386-mini-memstick.img.xz) = 65074b9a0616c96a1706b0e742db40fc736212f5e0e6ae76c45b06b809b2a78a2286cee0811c48562fbbbfd2439a7f4ddb0dc46d7348da49ecfe90e73d4a9b30 SHA256 (FreeBSD-12.0-BETA2-i386-bootonly.iso) = 1e20fd137f4e72f18faa731e01d7ce35e0959a917e83d077fe6df22d619d4426 SHA256 (FreeBSD-12.0-BETA2-i386-bootonly.iso.xz) = c93430b38fbece7fd8c9b52f2c0a2fcd9039b28dbb80fa54d63088cc77c9e2c7 SHA256 (FreeBSD-12.0-BETA2-i386-disc1.iso) = ac682be4dedb1f64a1dc43560ac5d7589f199591d5e80f21f3dfad207ddebd77 SHA256 (FreeBSD-12.0-BETA2-i386-disc1.iso.xz) = 631685fa219b19ec1d6565ee4c958523791d4df89b31091f9582185f52350d15 SHA256 (FreeBSD-12.0-BETA2-i386-dvd1.iso) = bae0b0d014238666b4ee0c45a9acd3d87d656eda6b8b98565ccac553fc062800 SHA256 (FreeBSD-12.0-BETA2-i386-dvd1.iso.xz) = f9e1da032658def2093ae1bdcf2ca4b54e1d546661d273d5d9a53f4e80e8ae11 SHA256 (FreeBSD-12.0-BETA2-i386-memstick.img) = 9289a1adcbb663b902cd302a730b8e8fa6343bdd0a62e9233cca1ac5f9fba7e9 SHA256 (FreeBSD-12.0-BETA2-i386-memstick.img.xz) = a3638be972a95cebd2fb822ea4487251d69e4cb031ef7b952e3d209cde5a601b SHA256 (FreeBSD-12.0-BETA2-i386-mini-memstick.img) = 16d5e5cf2d652d681fb01e626af4257bf9c1a0921d9000a499a636323b48146b SHA256 (FreeBSD-12.0-BETA2-i386-mini-memstick.img.xz) = a74f9464492edcff2268d17fa6fab47c2425c2c4e6950ff974acac85d1ca5b9a o 12.0-BETA2 powerpc GENERIC: SHA512 (FreeBSD-12.0-BETA2-powerpc-bootonly.iso) = 391b14d0e529538cac0fc065a560f7f69faf90672c5acff3d64003f1367e0768d8e60a1380dff13a0029a2304f4d16a2d008b4308a4d4485ec9cc8ee0ee5a90d SHA512 (FreeBSD-12.0-BETA2-powerpc-bootonly.iso.xz) = c7bd4b6e7425afc9f471bf2f6a99dfd16f25d66ab1704b3dbe96e22f818845a3dde8b4d5c79cc01bfa241bdc1ac249496de5df55114465dec5bcb49b66aab632 SHA512 (FreeBSD-12.0-BETA2-powerpc-disc1.iso) = 1cfbd7fe856b290e44f3e56a2b93292a8bf5b2cd8e151612785156b14cdbdba2400bc16aa557ba8a49a78cd390c8d1565636602e7ecfbb8cdc4ee5881665bf11 SHA512 (FreeBSD-12.0-BETA2-powerpc-disc1.iso.xz) = e95095ba7d09b6011daaf3d568f8240118a0cf2e1d806c9c83d836a2c8a9adbc5f7e13d39d415d173024c98083274f40d230e421ad9d85dce349910f3978626a SHA512 (FreeBSD-12.0-BETA2-powerpc-dvd1.iso) = b8d3c4bb97571894b4b19c44716c07df03134a81c59a7a9888e1e875999f39e57ccd42449583370c2f12163cb0b9d44f902270528920226b675cf168a1b56b00 SHA512 (FreeBSD-12.0-BETA2-powerpc-dvd1.iso.xz) = b2ba366ce704806696aa4a44696822bf6ae051ad05fbca5cc3850421bafec5e4be639444ef5e53ecfd5ba4108b3b707f099f78605d4d739b0000541935805b7f SHA512 (FreeBSD-12.0-BETA2-powerpc-memstick.img) = 8fcfdc38f219f985a0f26562f241f2c069d398c20747b72b6d30493f45b5b1c0dab8ffd992c06e70faf139fefec4dac7f6a457a8498f94005018739fb15129b6 SHA512 (FreeBSD-12.0-BETA2-powerpc-memstick.img.xz) = 2daea4ca33969a830c655aebc2b7586e159092fe2f6ac9412f6a9cb2687fa149281a82a95d02e3f2dcacb42bf7d328a652c0be59765463c6ec35a7073e33745a SHA512 (FreeBSD-12.0-BETA2-powerpc-mini-memstick.img) = a0d5a6f6ac54de97f2bb87d558ae4263ec967d8fa914c621baa971264acd3f35947cd5f4bad9f8b8dc83331646d51d7cfdedef69a83f1d8894f1b7e830dfa12f SHA512 (FreeBSD-12.0-BETA2-powerpc-mini-memstick.img.xz) = 2b75e5cc26438f3b3edcebdd3e39cb9f0a15b640d2df2849279f19797f6a030a4b911c0fe4b940bc2acec335444a15e5255cfacc5326609060e98d480d2d8afc SHA256 (FreeBSD-12.0-BETA2-powerpc-bootonly.iso) = 2fc1a9fe0f5628424a0d60fbfe01ec5087906286753668abe0d76cdb5700686d SHA256 (FreeBSD-12.0-BETA2-powerpc-bootonly.iso.xz) = d5b4ed3f172907aa261159e645423b200c226776445975004bfcba9fbfb0d204 SHA256 (FreeBSD-12.0-BETA2-powerpc-disc1.iso) = 5573fe67afe90fd24159753f2e97525ac31106449894b24fc72f0daec01d00bc SHA256 (FreeBSD-12.0-BETA2-powerpc-disc1.iso.xz) = 02eab2f4450d11e7c4348a0923b371abb314b45abf34793d805670b7f838ed10 SHA256 (FreeBSD-12.0-BETA2-powerpc-dvd1.iso) = f3635703e1e8401030d5bee6a4b698fd64f4805a7b4bff73cd9162a827eb1d83 SHA256 (FreeBSD-12.0-BETA2-powerpc-dvd1.iso.xz) = d20483cb3dc169d8b803d227ae9886d5ae8784173cf8889d9381ea8c169627b6 SHA256 (FreeBSD-12.0-BETA2-powerpc-memstick.img) = f8931aa9e369cbc3679fb0d47925934997ca37d7d7c3f18a124d7653a69787c0 SHA256 (FreeBSD-12.0-BETA2-powerpc-memstick.img.xz) = 7f71587aaa1aad1777aac4faeda586defe2ae4687b8dd9bd5c77702a9b065a84 SHA256 (FreeBSD-12.0-BETA2-powerpc-mini-memstick.img) = ba74664527a78b0c81c3232b766d55b74e59432fa6634789a0867fcc34013985 SHA256 (FreeBSD-12.0-BETA2-powerpc-mini-memstick.img.xz) = b4fa68d8fe3a970eb5ae54a2a0d31537b17cc5d1149e1da524688e6cf7d3e4e1 o 12.0-BETA2 powerpc64 GENERIC64: SHA512 (FreeBSD-12.0-BETA2-powerpc-powerpc64-bootonly.iso) = 9230d68b87aeb1537e60a85c97bb7b9afcdb568b9f1da93c9336117b127339a5fef1a93c1bf81bbe15577ccfb51d7eccdeeb63f43c0663f772faa2fe02aa45fd SHA512 (FreeBSD-12.0-BETA2-powerpc-powerpc64-bootonly.iso.xz) = 9c68f14e44e34e1bfa13b88de5f3ccb3c1f63619bee7aa80644739a74b961f1ce119c417d7d60ebd787045e783e885f67199e5d9f7c8b15435af7bf239748363 SHA512 (FreeBSD-12.0-BETA2-powerpc-powerpc64-disc1.iso) = cb86c89407d2d28b6d8542701e63567a7122010c1577bf79e3c43a198f2b11b008aad1f341d1c01347640d2dbb8752cf1f4a38301bc68d761106148e52629182 SHA512 (FreeBSD-12.0-BETA2-powerpc-powerpc64-disc1.iso.xz) = b80a2b3f2b7d16148df6b418fe4139eefe028eed4a6b9159e20570433468a6f956fc634a7043df5335dccca754d125603be3034787af793126b9c8ae37d276b2 SHA512 (FreeBSD-12.0-BETA2-powerpc-powerpc64-dvd1.iso) = da25903597615dde23b2e85c9d5e4e854df121bc8b1635034357c5aaa49b5398529a2eb790d0f05a7ab51e577c4e89c013c847d7287a7a479dac81d6a44b534a SHA512 (FreeBSD-12.0-BETA2-powerpc-powerpc64-dvd1.iso.xz) = d5b48958308aac9c1c1d0ed8d5f1cbe95c9534625429045d71abd947e3c1e228ca057e3aaf6319fa5d16291062386fd02d37bddabda192fe05aab2defeb6f180 SHA512 (FreeBSD-12.0-BETA2-powerpc-powerpc64-memstick.img) = ad6806f0eb9a5d18f88693a9ee8fb94bbda5ced5a58dc2773e89f0be9a17ac96b283c290e1e7c5dd11869994efe5bc83151c92fc72dd2f14a7c928d0631063cd SHA512 (FreeBSD-12.0-BETA2-powerpc-powerpc64-memstick.img.xz) = 619d330a614614f71c61c57a36520c8920173204b48071875d8c224c27ff515506468f740158593c36dccebf8bdc852b4e414bdc7ec7f671df9fc58decff915e SHA512 (FreeBSD-12.0-BETA2-powerpc-powerpc64-mini-memstick.img) = 38e7067636dcef434a05c901545a1d830dc631a5cfbb84c0e358d82471f7a4c20867734e26ff2683022f096899ee2f22914bbf2385ac2ad84e9c0095c5ef7484 SHA512 (FreeBSD-12.0-BETA2-powerpc-powerpc64-mini-memstick.img.xz) = 5d06db66ac5a65b8e1ff308a3580e5d6cca98e8bafda29f0c992655b26d4c2d4a1aa9d635bebc360258842f861411dc3328cae2a690d4d9a1c5d19456e06cdb4 SHA256 (FreeBSD-12.0-BETA2-powerpc-powerpc64-bootonly.iso) = e55d91b1519de522ccd83c88e03a8443c9a1cd07007a538670900d214c8be903 SHA256 (FreeBSD-12.0-BETA2-powerpc-powerpc64-bootonly.iso.xz) = 7c15ede01b92c34fd36b7159bbecfce4bb0493f4c91106acfe196a9ae4f4bf9e SHA256 (FreeBSD-12.0-BETA2-powerpc-powerpc64-disc1.iso) = eb0c776827139bdc6c9322d3a4b9cd3919a40e0ff91be2ae53f6a18356c35485 SHA256 (FreeBSD-12.0-BETA2-powerpc-powerpc64-disc1.iso.xz) = d00b67b4c6ca6c5b0eb21be5bef93aec385235df2ff1f8b52eb51d940da2beee SHA256 (FreeBSD-12.0-BETA2-powerpc-powerpc64-dvd1.iso) = 11cbd2c6d4ca588122eee63aae1eae519abef7ec171e33c05518674d5a7dd701 SHA256 (FreeBSD-12.0-BETA2-powerpc-powerpc64-dvd1.iso.xz) = ce2afa03d4a2fe1b175e27d1d22fd124439f9cd80ae0c6fadb25e7677f035b30 SHA256 (FreeBSD-12.0-BETA2-powerpc-powerpc64-memstick.img) = e631d50a4c8c8ca35f8d2d6fb5f64172ff71c52fbd23377eee20618a029c6f8f SHA256 (FreeBSD-12.0-BETA2-powerpc-powerpc64-memstick.img.xz) = 83374921b1b16f96f199ca4940bbc1695e75013e838dab01de10fbaa4befd475 SHA256 (FreeBSD-12.0-BETA2-powerpc-powerpc64-mini-memstick.img) = 1b94fca0f51f6565605fd6e5fdf6649fab0081054ebe6f547a2b88194e29f78c SHA256 (FreeBSD-12.0-BETA2-powerpc-powerpc64-mini-memstick.img.xz) = 531259a9b791e3f741d377179bd4dcae9d652586676ba595006e15e20d86a002 o 12.0-BETA2 powerpcspe MPC85XXSPE: SHA512 (FreeBSD-12.0-BETA2-powerpc-powerpcspe-bootonly.iso) = 072d9e5a3fd9e3c85368ef7fc5bf6a1f8669ab47053dfbe7e6261c1db7c95b968a99e0e841e87fb143fc91d54d96a1d0e56eae1976c1bc820fc318aabe543fd9 SHA512 (FreeBSD-12.0-BETA2-powerpc-powerpcspe-bootonly.iso.xz) = 332b61ed7ae009a90a007b092c9412ae3887237e572e30961994f012db69b222df90fa1528a0a091d653b2dbd1c53027adb05d4c9ae266934b05ec0af57346ee SHA512 (FreeBSD-12.0-BETA2-powerpc-powerpcspe-disc1.iso) = e1fd6598468d1147b395eab809c78f85d1457faea8af09b60d896cedf8029ab753a9bf9e8569ec2a709c29d67ddb64d45377384c500f3b2e318f582145ceca5e SHA512 (FreeBSD-12.0-BETA2-powerpc-powerpcspe-disc1.iso.xz) = 27b6d6ba66138b8741666ceda4c7b1f873164ba7534f4a2bb39d99f8abba7d63af5f9f7575db4c63015a813bc5748fc38c2d80b38218bb4c4450a29d7ed124b8 SHA512 (FreeBSD-12.0-BETA2-powerpc-powerpcspe-dvd1.iso) = ff66e9c77eb0b19c9dbc53b60da0ad99f320f12684572cd9dbb037d9c3e601f4b050a9422d93811263d75bf49c6491fa2945f4e4fbdd5e60a92ace086fd681e0 SHA512 (FreeBSD-12.0-BETA2-powerpc-powerpcspe-dvd1.iso.xz) = 21c690dedc4aa9dec0deec45860694c11e7f1b13bb24ba9fcf4f64c6b03dc608fc32d0bafe4598ed4523ac1293b8761062b25b0a0440c3282a8721cc7082b320 SHA512 (FreeBSD-12.0-BETA2-powerpc-powerpcspe-memstick.img) = d5de7bed2b600347d6fe79c61f811129332e08aa06ab5cb9239966615c32bf806d8adff55a0dd0ebb6e3a335c8bb5ac2adf096279f0c411ba9a25e9fa8c409d4 SHA512 (FreeBSD-12.0-BETA2-powerpc-powerpcspe-memstick.img.xz) = d4fed456257cd0053f5e2e0069962cc8dcf823d15b53486b493e6b0e15dac1b8738bfb903308b9e14df2310ce29517cc70efff0e1d3476fa7fb5926c3f5410c3 SHA512 (FreeBSD-12.0-BETA2-powerpc-powerpcspe-mini-memstick.img) = f6c343a8669977478487d778f1362e027c60aa40457343cc2385f70e73570cb03c3c33058a24953cc50fabfa23507cd73701ede322034b14aecacdb9bb70c61b SHA512 (FreeBSD-12.0-BETA2-powerpc-powerpcspe-mini-memstick.img.xz) = 8f953fccb34d151928f06ab350e11a641dae2776419ade2f52315af62f81ec8449f77c3700261f7244c1cea6b3413b1cf240a32e0254b6ea1590ac0a2949e7c0 SHA256 (FreeBSD-12.0-BETA2-powerpc-powerpcspe-bootonly.iso) = d19c08e4578456e00f077e2dc0390819264707c747eddc6b58fd131eff83a956 SHA256 (FreeBSD-12.0-BETA2-powerpc-powerpcspe-bootonly.iso.xz) = 5a4d7c358602031da7614521d749dc04be7cefee122c261ee30772ceefd4f96b SHA256 (FreeBSD-12.0-BETA2-powerpc-powerpcspe-disc1.iso) = e922ef7c0c79c498baee09c4073ff933b60f278263f60b1fbcae530dc4d5031a SHA256 (FreeBSD-12.0-BETA2-powerpc-powerpcspe-disc1.iso.xz) = 68c7f51da4f637583efe976eed15641d9bd19cf934a8907108da8849ffd39ce9 SHA256 (FreeBSD-12.0-BETA2-powerpc-powerpcspe-dvd1.iso) = 6a0f7fde3cbd9f38f30b61b6ea72484e27b7573258fe3b399b00dbc7be326011 SHA256 (FreeBSD-12.0-BETA2-powerpc-powerpcspe-dvd1.iso.xz) = 3333122e1727d31b09c5bfcb8bcc86e498df1e1cadfa0f2e2e59b9ce376a2af1 SHA256 (FreeBSD-12.0-BETA2-powerpc-powerpcspe-memstick.img) = 5fd1ff68f02d5d3886f560d76b0486358b408ea73681c1fcb30387be53099765 SHA256 (FreeBSD-12.0-BETA2-powerpc-powerpcspe-memstick.img.xz) = e5f9fb1c7aaca16fc9188d6e8154ad01f09dea888364930eec4a3497aed6a25a SHA256 (FreeBSD-12.0-BETA2-powerpc-powerpcspe-mini-memstick.img) = 49b02b39b24793925a7a42193791e335540cb6a2980affc96a3c46d854825016 SHA256 (FreeBSD-12.0-BETA2-powerpc-powerpcspe-mini-memstick.img.xz) = 26a9b4b75c2e724d01fa4622e430eb98cd266848ec9b4a42a8c38f8819c80b1e o 12.0-BETA2 sparc64 GENERIC: SHA512 (FreeBSD-12.0-BETA2-sparc64-bootonly.iso) = 07a6288686de08bc82a566d2788a80bac266d5b659a5bace400e31048871cf483135e397a574ef495a634725b867f0dafea597ed3a1885d257839305481540e8 SHA512 (FreeBSD-12.0-BETA2-sparc64-bootonly.iso.xz) = 315e29b1754359220cb5ff3106a5292d4198cc1a13c3c9b62e8b36730f83aba428a505b68a6ad99133ebf1d798809ce5b7439c787987210b52d0b1d54b97b39a SHA512 (FreeBSD-12.0-BETA2-sparc64-disc1.iso) = 7784ffd1b53d9d7177b2fb1e42c5a1883b3cdc62634230b7950ad35a57c6f37dc972e37d8e035704653a32609b37928d5a41bd0c00847e56860bc36e11e282f2 SHA512 (FreeBSD-12.0-BETA2-sparc64-disc1.iso.xz) = 048e5b90e782f6df5546ebeae6a41f17df682e237bb91a5e6613ab0558680e12c4a2d61cccec4c8996d4b5eb7f7aa4690943758b8344aecad96a4cc5c2d34e7c SHA512 (FreeBSD-12.0-BETA2-sparc64-dvd1.iso) = 026efcfe8b44045a8398bc7d53ec9de3e4bf2a08b4949a7f6f7050ff84488ff06e12aec708d123074b1136a70c038a01133a7cc03942268737030c35ca801fe5 SHA512 (FreeBSD-12.0-BETA2-sparc64-dvd1.iso.xz) = 430a89a9c8329f22f346b3086bff653bc7ac4b511bb5ee6d236ad5ecc8497ea56288357000849baddbdd153c6e81e36a85c60db2460a1d50335038996050742b SHA256 (FreeBSD-12.0-BETA2-sparc64-bootonly.iso) = 1df4fbb1d41b8830d9e072b6ff9e526d3f0613415747e3d0c537daa67b4a923e SHA256 (FreeBSD-12.0-BETA2-sparc64-bootonly.iso.xz) = 009f1f400ba60046739787b84f19ca054036638605ebc6742d25762612fbc633 SHA256 (FreeBSD-12.0-BETA2-sparc64-disc1.iso) = ad7238f0aa39714d99a8e0db2286a4f71017c217b22ec91932a0a1b57d807275 SHA256 (FreeBSD-12.0-BETA2-sparc64-disc1.iso.xz) = d54cde882e7be35e3c4beb08bf058992ab2ce8d9aab4b3d82f2a1228ff075672 SHA256 (FreeBSD-12.0-BETA2-sparc64-dvd1.iso) = c5e0f8f6843f8989165059b7c58341e2e6f6f626311d3a76fbba9b78491207de SHA256 (FreeBSD-12.0-BETA2-sparc64-dvd1.iso.xz) = cad649d008855094a7015a7c91492e147ae3c12de4b1a9b3cae856b707ec33a4 o 12.0-BETA2 armv6 RPI-B: SHA512 (FreeBSD-12.0-BETA2-arm-armv6-RPI-B.img.xz) = 5ff1542b02494b542221e367aa51de79481f6424af571c0afe9d1d6e065043628e5f21365e337a57b2a69c9b20d053866c54439e7cf10a35f7e6d21d7698bda6 SHA256 (FreeBSD-12.0-BETA2-arm-armv6-RPI-B.img.xz) = 2fe7d2050e458b3060799562001cb3051eaac219727c9939faaa4f1c6e332f8e o 12.0-BETA2 armv7 BANANAPI: SHA512 (FreeBSD-12.0-BETA2-arm-armv7-BANANAPI.img.xz) = 470d68331b0a381cb89102ae8d2f6bd75ccce62271b4a5adfe94ed429d1f6b804480258a2df86ed505b21dbd2c484a61342d53631a487de3f4bbd96ac4216081 SHA256 (FreeBSD-12.0-BETA2-arm-armv7-BANANAPI.img.xz) = 5c3d6646636e56a14879bfc04c475a1479874f654e4de4f0c7b560c7c19c6470 o 12.0-BETA2 armv7 BEAGLEBONE: SHA512 (FreeBSD-12.0-BETA2-arm-armv7-BEAGLEBONE.img.xz) = 4184beb7b5fcd8ecd9b5f113d1650aae2fa62c898b7a824bf9651a6a4ca06bc24b49dbd2415711b861677227815b521298272ee565f87c793f381cbe66531543 SHA256 (FreeBSD-12.0-BETA2-arm-armv7-BEAGLEBONE.img.xz) = fd220d37a0a59cc2aef263f17fb4e4126ab7f10c5957431597d667b267fc5f21 o 12.0-BETA2 armv7 CUBIEBOARD: SHA512 (FreeBSD-12.0-BETA2-arm-armv7-CUBIEBOARD.img.xz) = 0eaa8e4c001077631edc3894e4f4a337e868b16ddbef66601066e1d6e5ae0c9284d0875192e006f370d0a6ac657e0841deeb7459988888b559f82052dc256018 SHA256 (FreeBSD-12.0-BETA2-arm-armv7-CUBIEBOARD.img.xz) = 620d31eafb1ed2f320406fc7914907638a1331c3395a0bae1fb42fd134445db4 o 12.0-BETA2 armv7 CUBIEBOARD2: SHA512 (FreeBSD-12.0-BETA2-arm-armv7-CUBIEBOARD2.img.xz) = 01fb57a3e03416ae6a0ffff502bcd7e131e231e37fe503515dac78ff0a6f5739b72636a6dd90b060fddd1694e3b4177b93b76d1362b93cf0424f888d483cfd4d SHA256 (FreeBSD-12.0-BETA2-arm-armv7-CUBIEBOARD2.img.xz) = 64b6c5be10afda00676fece9276231e41efc37ff1de82b3fb634a02b665094ab o 12.0-BETA2 armv7 CUBOX-HUMMINGBOARD: SHA512 (FreeBSD-12.0-BETA2-arm-armv7-CUBOX-HUMMINGBOARD.img.xz) = 86ab1dc6136984109051a8bf5094ca49b23f2c57beb48647b5dfcb5d2ba0af77f7dda11e22c8fcc6e1640d4edb3f7e266939f4356349057ba393632a14d605d0 SHA256 (FreeBSD-12.0-BETA2-arm-armv7-CUBOX-HUMMINGBOARD.img.xz) = 6d95c51718febc73b97eb57e8987b21729c81fdc323399de666c984bde098e38 o 12.0-BETA2 armv7 RPI2: SHA512 (FreeBSD-12.0-BETA2-arm-armv7-RPI2.img.xz) = e75efe957a84ca8b58441784f9bde8b0efb8e8d60672f6654252267b0dd5dffb17d2c16ccb81aff494e862b89fda6ed82a8e467c5f9b5cb81b4f3acaac6d727b SHA256 (FreeBSD-12.0-BETA2-arm-armv7-RPI2.img.xz) = ecbdee268dfa184cff20d5cad8f92d88a989a74df7aee34054e52287ec54bc8a o 12.0-BETA2 armv7 PANDABOARD: SHA512 (FreeBSD-12.0-BETA2-arm-armv7-PANDABOARD.img.xz) = d1c34d8fb034500dcc809a626bf99213eb6f5fb4c7ef3bd1e92a86d0ee957da6f70b660193c2659f45ec653fb79da91088f590a4591d1c1af4b9a50586ef67d5 SHA256 (FreeBSD-12.0-BETA2-arm-armv7-PANDABOARD.img.xz) = a87f4da81fda05a1a95821a92180c5a7ada7331cad55c68c19da9ce495e66ff6 o 12.0-BETA2 armv7 WANDBOARD: SHA512 (FreeBSD-12.0-BETA2-arm-armv7-WANDBOARD.img.xz) = b6d17c62c889be8789631b9dcb9557311aa55a033ba81b9a7c6142df7c0addfce5cb8e60aae32ed455d49bd9400b96fd2e8ae75a2c3a19194db066a8806fb394 SHA256 (FreeBSD-12.0-BETA2-arm-armv7-WANDBOARD.img.xz) = 7fced8f9660593c94b089468e1a39d985b6573294a0529d0befaa7aed44eea27 o 12.0-BETA2 armv7 GENERICSD: SHA512 (FreeBSD-12.0-BETA2-arm-armv7-GENERICSD.img.xz) = cd741fcdeb84a6f286c2068c025baca9202b0d4def07471bb28b90c17a70f4e576925eb0382bd72a34b8442592054f840de8ba62b2c5c209347033675beb0a5d SHA256 (FreeBSD-12.0-BETA2-arm-armv7-GENERICSD.img.xz) = 1341712cebbe2f6de5d53cc7be8f19f00e9d93cc68b4f1113d74b0c6f5e8b094 o 12.0-BETA2 aarch64 GENERIC: SHA512 (FreeBSD-12.0-BETA2-arm64-aarch64-memstick.img) = 3b48f703bbb7021c4e81aa8e9557327466210329c99542651d417cf6a736159f6821d2d4ff496b85315a18b27fa5b0ef941bba2596d76cbf4a0395f9a6c3b375 SHA512 (FreeBSD-12.0-BETA2-arm64-aarch64-memstick.img.xz) = ae73677cedafbcd34ee15d77731959c66e41c36ed8bd540cb11783ed050c8ec97ffac8f6ca66593e672352280a370b3db5817d95f322ab0ab536c9cd78d8534e SHA512 (FreeBSD-12.0-BETA2-arm64-aarch64-mini-memstick.img) = 1040b00f4f51f7bf31509e17c8d71d557136e224f8df26752354548eb579b957c8dab7e33afa5db31efa2a0ed941052d36b0840fdc03dfc56e5c4813b1877d53 SHA512 (FreeBSD-12.0-BETA2-arm64-aarch64-mini-memstick.img.xz) = d1fa9b34069196d1ee8e7bf586c54a96f11311f48812bf6cbbf8b70d362d06f0183e735ea09a577189c87e48624b6891b5ae76dbf3fd8f9bf7b617d2a8b1abbc SHA256 (FreeBSD-12.0-BETA2-arm64-aarch64-memstick.img) = 5a3dc5eb0f77708230c758514a364f1a7c876249f9db7d9b2f28f4a9aaaa471c SHA256 (FreeBSD-12.0-BETA2-arm64-aarch64-memstick.img.xz) = e9265da7632aaedaae7522b46c070ab753fadc95c25d18f2575cc89c388ba725 SHA256 (FreeBSD-12.0-BETA2-arm64-aarch64-mini-memstick.img) = f11bcb04c5a01ac9ed1a4d52badbc219465e357b948916991cf0bfaf522adcca SHA256 (FreeBSD-12.0-BETA2-arm64-aarch64-mini-memstick.img.xz) = e8d621d81553c324db38e2b2ced882dbdcaa1cb49b992604cbdc9cdc9f170c79 o 12.0-BETA2 aarch64 RPI3: SHA512 (FreeBSD-12.0-BETA2-arm64-aarch64-RPI3.img.xz) = 4d7ca4331f9648ad5a58a4c4e8f1610dad79154259ec1b28fef916a4907f1503a1b217daa1852a1a80a3e8167db301a4a8ba701b9e8762af46a2088114450147 SHA256 (FreeBSD-12.0-BETA2-arm64-aarch64-RPI3.img.xz) = 32c30b5f147cf907c358d4cf165f89eb9c19b6efaf774382b54fc16e85c97275 o 12.0-BETA2 aarch64 PINE64: SHA512 (FreeBSD-12.0-BETA2-arm64-aarch64-PINE64.img.xz) = 7d722293cbfeb7ee8e9a7c8dcbdcc68968812c5e8e11100bec8f4b1f3ffbd2e85316ba22fdbad6069b2d1d6b9f49138cd89dab1e0e54572d9c3118b7aa7bfbe0 SHA256 (FreeBSD-12.0-BETA2-arm64-aarch64-PINE64.img.xz) = c312894aed64214445105cde247680d63a0a200519e520e29eeceec2c871e560 o 12.0-BETA2 aarch64 PINE64-LTS: SHA512 (FreeBSD-12.0-BETA2-arm64-aarch64-PINE64-LTS.img.xz) = 4fa99218ffafcba0ecd1b90e5cf45f46d1efc85eec19e0c9694b0fdc3bedbf3004ff9778113502ad7372b8da1ba836abc9ac9fe599e0e182b64e1ffab2000705 SHA256 (FreeBSD-12.0-BETA2-arm64-aarch64-PINE64-LTS.img.xz) = 2bd455b2d1240e8de242ef0508884e9b1b643777a990495e971e9dc43d81b5ec == VM IMAGE CHECKSUMS == o 12.0-BETA2 amd64: SHA512 (FreeBSD-12.0-BETA2-amd64.qcow2.xz) = 93ed99166aeed01ecf550241da220bad79b4ce9e488436436d06d9f81cbd60c41dbd8bbd0ee990dac64bd4c8d3244d4b15756aaccdad0608e484632c4a2d0bf9 SHA512 (FreeBSD-12.0-BETA2-amd64.raw.xz) = c0e7528f356ca77287250ea88183c03918878e0e475d4ff6ab85ce295320cc2d96c42534fc1b2c2b6b33cbf6373bd6ba7505198656e4bdb58d1b9009aa153c04 SHA512 (FreeBSD-12.0-BETA2-amd64.vhd.xz) = 16de137358b951b9a494411c17c5341c065c5bdaf2dc2189f3e9b991be3e9b713ca80ba8152102a3b6e52e467d745a5957f320c723920d3541605d14b2c01a24 SHA512 (FreeBSD-12.0-BETA2-amd64.vmdk.xz) = 7b89dcccf585b69f8923c1f4e3d66a415cb8f0911d358a88eb2fa4152e2caa02235eaf87424602d5cc034829a043de5723a0b7ed9dee25376697657adb1686ad SHA256 (FreeBSD-12.0-BETA2-amd64.qcow2.xz) = baacea152de96ce9e6927f62a788a9c91f5af1daaa7626c2266ea79b559f3294 SHA256 (FreeBSD-12.0-BETA2-amd64.raw.xz) = 68ca7b91b695a3cfef9d57b4748b301243eddd07014c8a11a87043df7db39c97 SHA256 (FreeBSD-12.0-BETA2-amd64.vhd.xz) = c097b26004cdc67054d81f9ee5f68c3d50fb78ea849a02eb38028ad5952221b4 SHA256 (FreeBSD-12.0-BETA2-amd64.vmdk.xz) = e3b10c2093fb8c5460735a41794100b6f742a1c7e44a04d76555e46395463452 o 12.0-BETA2 i386: SHA512 (FreeBSD-12.0-BETA2-i386.qcow2.xz) = 42181a82bbc57d3e3f77adb08b40a24383400ab6fafb0c669b47a4374e0f0f248f347edc3035dd530aa49e405994d3b2da6c2e1b52756f5fee07363d067950d7 SHA512 (FreeBSD-12.0-BETA2-i386.raw.xz) = b71d0bd84892f642e4c7a2d420571d87e3e9ea96a3e42d2f1474b7a00aa4a9ae44163bef0634683afbe0fdb3292e224cd5077ea3499c70b1c6e876a5e7fc54aa SHA512 (FreeBSD-12.0-BETA2-i386.vhd.xz) = 39f736d929cc6f9c3a60a9c125022264f0fef844a90595a4eefe1fd8992ad2193610a81fcffadc3d651b4b1130f11fef70d4ec2c8cd592a9e68a389b928dd5aa SHA512 (FreeBSD-12.0-BETA2-i386.vmdk.xz) = c634329b31376cad46c7a048ff66332021ddb44805688925ab0d6b18837bcd3025a3552c561a90a8f7b9cb8ff4d75bcc644501c3c98443ef604ff4d4ba39b5c8 SHA256 (FreeBSD-12.0-BETA2-i386.qcow2.xz) = 77441e363f2730d6894dca6fa2f5c2b75108ba343482d90c73c2891840a53ed8 SHA256 (FreeBSD-12.0-BETA2-i386.raw.xz) = 67292a382f5540e5c395b54567c23e877e5a5c9a4c0e8af22f3b66e153d355f9 SHA256 (FreeBSD-12.0-BETA2-i386.vhd.xz) = 1f6c08b99c35c010a4046644cabb6609e7a4f7179a401b920c1a7db10727d64a SHA256 (FreeBSD-12.0-BETA2-i386.vmdk.xz) = 71589c1d5fe7239358b36aba195eed23b0d39509d2cdc4a74c6b1c241b9aab1b o 12.0-BETA2 aarch64: SHA512 (FreeBSD-12.0-BETA2-arm64-aarch64.qcow2.xz) = 1f0072782c58451ec3db8ac64d7210d2bf1f123787c9cac3d11bbbe6d6ec28f3fe7b8b58c90c4c175bb95cddc97185ad176920bb476b1bcfb8002a60a4345d7d SHA512 (FreeBSD-12.0-BETA2-arm64-aarch64.raw.xz) = 767d37503cfa64a3ca8068bde8b0160c6c4e8cbadb8bddbc3208f65a37a51378f83b142a8245e4339ff628579034c5cb45adae4a5e0fa04ad3067405b9992aaa SHA512 (FreeBSD-12.0-BETA2-arm64-aarch64.vhd.xz) = b0d0f1f98351ca7c56c880f21d5ba7367a4c623aceb5264b5705428cb9a6a98a93777a45ca26e99d06fff9b8c5195fa7bb08050afcb048defdbc35bd4b7ddfd5 SHA512 (FreeBSD-12.0-BETA2-arm64-aarch64.vmdk.xz) = a5a2c4431596e1f346906a0c7b299ec56ce84857dd4853d84e272f5f29e35d046180a4245e1561b187ff44814435ae8cbcb202055f7441588357d55da6c83d72 SHA256 (FreeBSD-12.0-BETA2-arm64-aarch64.qcow2.xz) = 420d265a3e3e03296b2c2ab40d1cf425656b8ef4b6a4c345997aa820846db193 SHA256 (FreeBSD-12.0-BETA2-arm64-aarch64.raw.xz) = eed7a78a511c0004064d17f52e06c4c6af2700fd9b831ed2fb60fc0274052b53 SHA256 (FreeBSD-12.0-BETA2-arm64-aarch64.vhd.xz) = c6a3116cf29cdd270a6d4fc14c9b7ae4d745069b0bf60a7f7840201783117b58 SHA256 (FreeBSD-12.0-BETA2-arm64-aarch64.vmdk.xz) = a850248b8b798f34070fa7b317bc90a2436c086b73facac85baedf09d0db8d7c Regards, Glen Love FreeBSD? Support this and future releases with a donation to the FreeBSD Foundation! https://www.freebsdfoundation.org/donate/ -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAlvUmnQACgkQAxRYpUeP 4pPNrA//ZFGYf9Q2yLv4LoCVneNgGF/Bblw1UBHyL6kKcOzpcLfaGF1C3o563303 yZD1jgl32F6+1/q63R04RxuKQdk2+lOH9adW8tC490sywTOHNgs1ecrk3N+NwII1 XLCT56pJ1Is3rrd1Kjd9Hg45ej6oU1F5JvUj8/MgJ3THsyGirfzgcplrYRqacXdX KE4w/PNj4LeV9pWW2kcKbiB5mP/MrrZy3Clb+ASxusrx+q2pVsXenXrCXAKOTCZo /L0htS6kc5y86yDM4yR5exBWzOLbNUAx7VTCSVZoeyOES/WVeYG7oENUlHqhl1Z/ mH2k7IsqVMJwJo3Ve4RcUwSC51Im43oVhluQCWAbCIykpnxdEEeWN1U5WG/sQ+gq /RNUcuGpbezb8tKQO82PDiOoXXoLCV1OyrpEb39R6hD4q3r1TAoZ5aIAmpH8vYBT 0MkwLARu8jvyj03SWtEJlpTStiiJgI9Ux4dvM0vcovMKfYYpzTvTFxJpUXb5UeJo RKhle2pDWGqzTXJmXraA4mCX5xIL2gJKjKB+4CXHhnFBd3z0vYlNeW5h6CnBFWJN AB/Z4J7AnXhtWKWMr9YZvtPN1lcHFvSZVcsNStbtQzP9T5r1Cjqtw+z3WuoKWP2T wPRFFm+XoawbkFuxJe5MpwAdwHonskC0fBPUgSSKiGv6cV1Ip0c= =jdw/ -----END PGP SIGNATURE----- From owner-freebsd-stable@freebsd.org Sat Oct 27 17:49:16 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B0D210CDD89; Sat, 27 Oct 2018 17:49:16 +0000 (UTC) (envelope-from gjb@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)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 447C074361; Sat, 27 Oct 2018 17:49:16 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id EA3171156F; Sat, 27 Oct 2018 17:49:15 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Sat, 27 Oct 2018 17:49:13 +0000 From: Glen Barber To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Cc: FreeBSD Release Engineering Team Subject: Re: FreeBSD 12.0-BETA2 Now Available Message-ID: <20181027174913.GO61572@FreeBSD.org> Reply-To: FreeBSD Release Engineering Team References: <20181027170348.GN61572@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed In-Reply-To: <20181027170348.GN61572@FreeBSD.org> User-Agent: Mutt/1.10.1 (2018-07-13) 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, 27 Oct 2018 17:49:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 One minor correction: On Sat, Oct 27, 2018 at 05:03:48PM +0000, Glen Barber wrote: > === SPECIAL NOTE === > This only affects systems that employ geli(4)-backed encrypted > filesystems and currently running 11.x or 10.x. Upgrades from > 12.0-BETA1, either via source-based upgrades or binary patches > via freebsd-update(8), are unaffected. > > An issue affecting backwards compatibility with geli(4)-backed > filesystems and an updated geli(8) binary after r332361 prevents > mounting encrypted filesystems with an older geli(8) binary from 11.x > and 10.x. For example, if /usr/src and /usr/obj are mount points on an > encrypted filesystem, the geli(8) binary that exists from 11.x or 10.x > after rebooting the system after 'installworld' will fail to attach the ^^^^^^^^^^^^ This should have stated 'installkernel' instead of 'installworld.' > encrypted filesystems when performing a source-based upgrade following > the documented upgrade path in UPDATING. > > For binary upgrades using freebsd-update(8) from 11.x and 10.x, the > recommended upgrade flow is to install the kernel patches, reboot, > install the userland patches, reboot, remove old libraries after > rebuilding third-party software. In this case, the initial reboot after > the kernel patches are applied can cause the same scenario where the old > geli(8) binary cannot attach the geli(4)-backed filesystem. > > A fix had been committed to head as r339804, and is expected to be > included in BETA3. For those without remote console access and do not > wish to upgrade via sources, it is advised to wait for BETA3 to upgrade > from 11.x and 10.x. > === END SPECIAL NOTE === > Glen -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAlvUpRkACgkQAxRYpUeP 4pPRWA//agHzejU7vcrGfq65EcHyghnZtZI8Wl8ZRlWD6uBf34glFmqdj7GwuXeD QlqbFC+KXwjoCgR6rYU8UfPQkAD3RSXweODOGO95bRglK9zYRH53K5vvxG26fMdb 5IOgMFCRmZh8HGoJoQ6ckV8Nc83ETP7Sym+9nXDar0Dea7rhXnrZcc31HMGVWZDC 1Tj0Rm0HbESLqAUOA9HffAOl8gLO5WPnfOcYnNXGfYz0RSmjPbLKRe2wEeedZP6c hC4pspmMQeSge0KPDHgK8rf3/1mieyvfMGKFHKNzROOtw5hc0DFv+lnPQx7b8JcK S9dRKKQJWyvb7A4VgHGa9Rh/FXhf1gg/47TqQ+IrAYAf/zMBkKRgaEY1WajwAPCP QE3AE8ksGeGMImqkFVDUxrgCDTlJBKjYynfPuqe62mqhPdu3+WvlPmdEtgWEk54B Ad0RJjoSLe01usJ4p2g6HiYr9nwqDlLay+z8ZJFYeMHWcibTKKAY/pSflXv+mFhI t7U4bTzxwBBOMjUscd3UTAkEE7rfBU3DjfR6vTtvq0EfkXL13P0jdcvRRW38gAmV RsKmOhFBmzBsC+AqhDkqjIgmulnhw0dZ/IgmAEUOrRTzJUYrG6sXs7u0WSx0S79+ KIFChoa8RncTWYuM6o76MyjahPYrOhscCwAwiWMVqEFv8MQt0ic= =DEys -----END PGP SIGNATURE----- From owner-freebsd-stable@freebsd.org Sat Oct 27 17:50:37 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6358910CDF64; Sat, 27 Oct 2018 17:50:37 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F3637746A3; Sat, 27 Oct 2018 17:50:36 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 526D88D4A216; Sat, 27 Oct 2018 17:50:35 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 0A907D1F7F3; Sat, 27 Oct 2018 17:50:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 8iU0HCY508bZ; Sat, 27 Oct 2018 17:50:32 +0000 (UTC) Received: from [192.168.1.88] (fresh-ayiya.sbone.de [IPv6:fde9:577b:c1a9:f001::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 74E3CD1F7E6; Sat, 27 Oct 2018 17:50:32 +0000 (UTC) From: "Bjoern A. Zeeb" To: tech-lists Cc: freebsd-stable@freebsd.org, freebsd-wireless@freebsd.org Subject: Re: TP-LINK TL-WN321G Date: Sat, 27 Oct 2018 17:50:31 +0000 Reply-To: freebsd-wireless@freebsd.org X-Mailer: MailMate (2.0BETAr6123) Message-ID: <3D95450B-21E6-4587-B246-2345CB301834@lists.zabbadoz.net> In-Reply-To: References: 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: Sat, 27 Oct 2018 17:50:37 -0000 On 27 Oct 2018, at 16:01, tech-lists wrote: Hi, > context: 12-stable amd64 > > When TP-LINK TL-WN321G usb dongle is inserted, this appears in dmesg: > > ugen1.3: at usbus1 .. > run0: MAC/BBP RT5390 (rev 0x0502), RF RT5370 (MIMO 1T1R), address > [REDACTED] .. > and run0 appears, and works, yet: > > rum(4) says it supports this: > TP-LINK TL-WN321G > > but no rum0 happens either on insertion (using standard GENERIC > kernel) or with rum loaded. The problem with these dongles is that sometimes there’s a rev A and a rev B which use entirely different chipsets and hence are entirely different drivers. That is rarely observable from online shopping sites or even product packaging. I haven’t checked this particular case but if you can send me a usbconfig dump_device_desc for it I can go an have a look. /bz From owner-freebsd-stable@freebsd.org Sat Oct 27 18:43:57 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5A8010CFE0A; Sat, 27 Oct 2018 18:43:57 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (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 43ABC76931; Sat, 27 Oct 2018 18:43:57 +0000 (UTC) (envelope-from tech-lists@zyxst.net) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id BA9AB213B9; Sat, 27 Oct 2018 14:43:56 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 27 Oct 2018 14:43:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zyxst.net; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm3; bh=N ISaaPRf2dMXH1aX7KcyO/DXsyiZxVuYNc8xbEnelxg=; b=xiaza/W+QdN4N2L+Q N6llkesQJJefyAQ80CxiNCDfkOihpIxeLjrJNg9dmXNORktoekLZI0yG4U197Q78 YeJ7lwVh537UaO4RBeynRHXgKRwwweh6n79muOdSAR2BQ4noH/UZHxcQF6mmo1jy SbJoFmvhGjndgzHJesgpLwcX0rSrtSQR/TMWDk07YR5wT53qcrGsbLHr9sFMGuS6 Bp6O0R42mMI5DbZWV5AMexqhzi4KtcqTWB2YlayQTr2AMCO4GEvKZVaRCpK6v6OZ St12JpzyOKREUaK6/qorpDtbl6hh4Z/x173rjgXPx4DdVLWNbVszy+4r+BDDvzFw EgPQQ== 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=fm1; bh=NISaaPRf2dMXH1aX7KcyO/DXsyiZxVuYNc8xbEnel xg=; b=zZfVcH8aJ5VpV6pepOdS5vZlRVQ9VbEeRhPGtnqARb7EjS4t46oWM+dI3 Nd6pjmtLdC7oHa0X+WS7gXTlk08+wdGZLcbe70/1nAWM0gxuwf+7VqPaNLEDI+aB J3m11RyU690Qgj2q6aRDoafFxyX+bqljFDbyjTS8F0rqqvvxS/GKsx4+ALAiJ/QL UAjxOHQlaURjmiHlm5OKlvqn7wsMIEDR+a7DBI8umt3heyDnQNTA2x7zW30RLMi1 Uc+/Pe1V3qhIv9fqxZ5SC4/zfN2bVPti/vP4O7zRH38OslFMdGcbpaDjn3jrHW5P FpJXh3zIJbqCyV2GmAuysrTnPEk/Q== X-ME-Sender: X-ME-Proxy: Received: from desktop.local (parsley.growveg.org [82.70.91.97]) by mail.messagingengine.com (Postfix) with ESMTPA id C1D29E43AC; Sat, 27 Oct 2018 14:43:55 -0400 (EDT) Subject: Re: TP-LINK TL-WN321G To: freebsd-wireless@freebsd.org Cc: freebsd-stable@freebsd.org References: <3D95450B-21E6-4587-B246-2345CB301834@lists.zabbadoz.net> From: tech-lists Organization: none Message-ID: <26306759-d5ea-f6d4-7dee-9ade112f3c0a@zyxst.net> Date: Sat, 27 Oct 2018 19:43:54 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <3D95450B-21E6-4587-B246-2345CB301834@lists.zabbadoz.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US 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: Sat, 27 Oct 2018 18:43:57 -0000 On 27/10/2018 18:50, Bjoern A. Zeeb wrote: > The problem with these dongles is that sometimes there’s a rev A and a > rev B which use entirely different chipsets and hence are entirely > different drivers.  That is rarely observable from online shopping sites > or even product packaging.   I haven’t checked this particular case but > if you can send me a usbconfig dump_device_desc for it I can go an have > a look. > Sure! here it is: ugen1.3: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (450mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x0000 bDeviceSubClass = 0x0000 bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0040 idVendor = 0x148f idProduct = 0x5370 bcdDevice = 0x0101 iManufacturer = 0x0001 iProduct = 0x0002 <802.11 n WLAN> iSerialNumber = 0x0003 <1.0> bNumConfigurations = 0x0001 thanks, -- J. From owner-freebsd-stable@freebsd.org Sat Oct 27 19:02:16 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A63A710D079F for ; Sat, 27 Oct 2018 19:02:16 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id 99A5F775A4 for ; Sat, 27 Oct 2018 19:02:15 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.15.2/8.15.2) with ESMTP id w9RJ295m025117 for ; Sat, 27 Oct 2018 14:02:09 -0500 (CDT) (envelope-from mike@karels.net) Message-Id: <201810271902.w9RJ295m025117@mail.karels.net> To: freebsd-stable@freebsd.org From: Mike Karels Reply-to: mike@karels.net Subject: pkg confusion with libssl on 12.0-BETA2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25115.1540666929.1@mail.karels.net> Content-Transfer-Encoding: quoted-printable Date: Sat, 27 Oct 2018 14:02:09 -0500 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, 27 Oct 2018 19:02:17 -0000 The pkg binary that is installed via the bootstrap has problems with the libssl shared library (or libraries). The binary itself wants libssl.so.111, but /usr/local/lib/libpkg.so.4.0.0 wants libssl.so.9. I'm not sure of the path that pulls in libpkg.so, but ktrace says that it's happening. This is on a freshly installed 12.0-BETA2 (amd64 on bhyve). More details below. Mike vmguest3# pkg install bash The package management tool is not yet installed on your system. Do you want to fetch and install it now? [y/N]: y Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:12:amd64/latest,= please wait... Verifying signature with trusted certificate pkg.freebsd.org.2013102301...= done Installing pkg-1.10.5_4... Extracting pkg-1.10.5_4: 100% ld-elf.so.1: Shared object "libssl.so.9" not found, required by "pkg" vmguest3# ls -l /usr/lib/libssl* -r--r--r-- 1 root wheel 4386406 Oct 25 22:08 /usr/lib/libssl.a lrwxr-xr-x 1 root wheel 13 Oct 25 22:08 /usr/lib/libssl.so -> libs= sl.so.111 -r--r--r-- 1 root wheel 604936 Oct 25 22:08 /usr/lib/libssl.so.111 -r--r--r-- 1 root wheel 4493898 Oct 25 22:08 /usr/lib/libssl_p.a vmguest3# freebsd-version 12.0-BETA2 vmguest3# ls -l /usr/sbin/pkg -r-xr-xr-x 1 root wheel 40192 Oct 25 22:16 /usr/sbin/pkg vmguest3# which pkg /usr/sbin/pkg vmguest3# pkg ld-elf.so.1: Shared object "libssl.so.9" not found, required by "pkg" vmguest3# ldd /usr/sbin/pkg /usr/sbin/pkg: libarchive.so.7 =3D> /usr/lib/libarchive.so.7 (0x80024d000) libfetch.so.6 =3D> /usr/lib/libfetch.so.6 (0x80030f000) libprivateucl.so.1 =3D> /usr/lib/libprivateucl.so.1 (0x800324000) libsbuf.so.6 =3D> /lib/libsbuf.so.6 (0x800348000) libcrypto.so.111 =3D> /lib/libcrypto.so.111 (0x80034e000) libssl.so.111 =3D> /usr/lib/libssl.so.111 (0x80063b000) libc.so.7 =3D> /lib/libc.so.7 (0x8006d0000) libz.so.6 =3D> /lib/libz.so.6 (0x800ac3000) libbz2.so.4 =3D> /usr/lib/libbz2.so.4 (0x800add000) liblzma.so.5 =3D> /usr/lib/liblzma.so.5 (0x800af2000) libbsdxml.so.4 =3D> /lib/libbsdxml.so.4 (0x800b1d000) libm.so.5 =3D> /lib/libm.so.5 (0x800b49000) libthr.so.3 =3D> /lib/libthr.so.3 (0x800b7b000) vmguest3# strings /usr/sbin/pkg | grep libssl libssl.so.111 vmguest3# cat /etc/libmap.conf = # $FreeBSD: stable/12/libexec/rtld-elf/libmap.conf 338741 2018-09-18 00:25= :00Z brd $ includedir /usr/local/etc/libmap.d vmguest3# ls /usr/local/etc/libmap.d ls: /usr/local/etc/libmap.d: No such file or directory vmguest3# ldd /usr/local/lib/libpkg.so.4.0.0 = /usr/local/lib/libpkg.so.4.0.0: libutil.so.9 =3D> /lib/libutil.so.9 (0x800672000) libssl.so.9 =3D> not found (0) libcrypto.so.9 =3D> not found (0) libm.so.5 =3D> /lib/libm.so.5 (0x800689000) libelf.so.2 =3D> /lib/libelf.so.2 (0x8006bb000) libjail.so.1 =3D> /lib/libjail.so.1 (0x8006d5000) libarchive.so.7 =3D> /usr/lib/libarchive.so.7 (0x8006dd000) libz.so.6 =3D> /lib/libz.so.6 (0x80079f000) libbz2.so.4 =3D> /usr/lib/libbz2.so.4 (0x8007b9000) liblzma.so.5 =3D> /usr/lib/liblzma.so.5 (0x8007ce000) libc.so.7 =3D> /lib/libc.so.7 (0x800248000) libbsdxml.so.4 =3D> /lib/libbsdxml.so.4 (0x801038000) libcrypto.so.111 =3D> /lib/libcrypto.so.111 (0x801064000) libthr.so.3 =3D> /lib/libthr.so.3 (0x801351000) From owner-freebsd-stable@freebsd.org Sat Oct 27 21:00:24 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3C6E710D3111 for ; Sat, 27 Oct 2018 21:00:24 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C9FB37AA59 for ; Sat, 27 Oct 2018 21:00:23 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 86C5A10D310C; Sat, 27 Oct 2018 21:00:23 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73F7C10D3108; Sat, 27 Oct 2018 21:00:23 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2607:f740:d:20::25]) (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 11FCA7AA56; Sat, 27 Oct 2018 21:00:23 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from cid.daemonic.se (localhost [IPv6:::1]) by mail.daemonic.se (Postfix) with ESMTP id 42jCtY3sgdzDhyN; Sat, 27 Oct 2018 21:00:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mail.daemonic.se ([127.0.0.1]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256) by cid.daemonic.se (mailscanner.daemonic.se [127.0.0.1]) (amavisd-new, port 10587) with ESMTPS id qKLcVUkzsRmF; Sat, 27 Oct 2018 21:00:20 +0000 (UTC) Received: from garnet.daemonic.se (unknown [IPv6:2001:470:dca9:201:9eda:3eff:fe70:24c0]) by mail.daemonic.se (Postfix) with ESMTPSA id 42jCtX4bbZzDhyM; Sat, 27 Oct 2018 21:00:20 +0000 (UTC) From: Niclas Zeising Subject: FreeBSD x11-servers/xorg-server and CVE-2018-14665 To: current@freebsd.org, stable@freebsd.org, x11@freebsd.org, ports@freebsd.org Reply-To: x11@freebsd.org Message-ID: Date: Sat, 27 Oct 2018 23:00:19 +0200 User-Agent: Mutt/1.5.21 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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, 27 Oct 2018 21:00:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 [ cross posted to several FreeBSD lists. Please keep replies to x11@FreeBSD.org ] Hi! As some of you are aware, the X.org project posted a security advisory on October 25 regarding a vulnerability in xorg-server [1]. This has been given the identifier CVE-2018-14665 [2]. The version of xorg-server in the FreeBSD ports tree is not vulnerable. In short, there is a vulnerability in versions 1.19 through 1.20.2 of xorg-server, when installed setuid root, which allows an attacker to overwrite or create any file on the system. By using this vulnerability, a local user can gain root privileges. There are several articles about this [3] [4]. The code in question was introduced on xorg-server 1.19, and as FreeBSD is still using xorg-server 1.18.4 we are not vulnerable to this issue. If you have questions or comments regarding this, don't hesitate to contact me or to send a message to the x11@FreeBSD.org mailing list. Regards - -- Niclas Zeising FreeBSD X11/Graphics Team [1] https://lists.x.org/archives/xorg-announce/2018-October/002927.html [2] https://nvd.nist.gov/vuln/detail/CVE-2018-14665 [3] https://arstechnica.com/information-technology/2018/10/x-org-bug-that-gives-attackers-root-bites-openbsd-and-other-big-name-oses/ [4] https://www.securepatterns.com/2018/10/cve-2018-14665-xorg-x-server.html -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE+Ll/478KgNjo+JKEu41LV7uLVVEFAlvU0WMACgkQu41LV7uL VVGgBw/+O7pIgdU5IvommsSetDAHPmdq3wy2j5mnWTjZXxz4qRe6pVJ6a0hJdkLw 8eSZGvPSo05Tnzk3Vx0cFdZ0hPIxm6Yp7dDpO6sXKDlxQrqDoxjPkjGMPj0897F+ 4hw7RWW9O5EEDlBHjL8+Uektkk2N7MjrlbNc2IZ+eHnH8XjQ5yDOFHT9NKLeAZeP ReJR/kN/+tW9VtzJtolk7vnksc8OF8ortsPX7dEXzoc1uHwppEoDlwQZrVRVuyCk j6JzrOthEVEnxvdvVmcQueijhzKE/2g1Ix82gYEfcHA1172kMWJka1m9Og2mKGqW 8aqKilpCv6koPXtWACeG5P8nG9+SpDH6HMhjpjQqdKG80x+0I9dbAu5mL9fTVKjp iFcY+8EQzsUYHEkvS9qk4dgiMR7MMXPM3JtOQOQ94hjoFcIp9toqeDr9U2DuRxAS LC4EQ1heaiqEtlCOMfkX5BExpBQ3fs+JrTqcDtIHujp7Cv8p19fhmehoXc3hzL0z xco1ubCOmLmR6Yed+BUxBcguMn37vE6KXDMoW0yQ/jmYt9a4EtECh/bTun81DZwN gEaFqutcnxzX1AWrYv92VT65OnA9pFXjmb4oU9OQRAiwnP7a8Is0nc7fnSrdtO/Y CoHWnZKI3hoMMWSXsfEc67RNtJyUnnGLHVvIt1VWrkL1+/WCm6k= =xBK6 -----END PGP SIGNATURE----- From owner-freebsd-stable@freebsd.org Sat Oct 27 21:17:07 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2732410D3A20 for ; Sat, 27 Oct 2018 21:17:07 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 705437B605 for ; Sat, 27 Oct 2018 21:17:06 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 2D48E10D3A18; Sat, 27 Oct 2018 21:17:06 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1B71010D3A14; Sat, 27 Oct 2018 21:17:06 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2607:f740:d:20::25]) (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 AF0FB7B602; Sat, 27 Oct 2018 21:17:05 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from cid.daemonic.se (localhost [IPv6:::1]) by mail.daemonic.se (Postfix) with ESMTP id 42jDFr53TMzDhxn; Sat, 27 Oct 2018 21:17:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mail.daemonic.se ([IPv6:::1]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256) by cid.daemonic.se (mailscanner.daemonic.se [IPv6:::1]) (amavisd-new, port 10587) with ESMTPS id 0sUZs4-3mvln; Sat, 27 Oct 2018 21:17:04 +0000 (UTC) Received: from garnet.daemonic.se (unknown [IPv6:2001:470:dca9:201:9eda:3eff:fe70:24c0]) by mail.daemonic.se (Postfix) with ESMTPSA id 42jDFr1WDLzDhFd; Sat, 27 Oct 2018 21:17:04 +0000 (UTC) Subject: Re: FreeBSD x11-servers/xorg-server and CVE-2018-14665 From: Niclas Zeising To: current@freebsd.org, stable@freebsd.org, x11@freebsd.org, ports@freebsd.org Reply-To: x11@freebsd.org References: Message-ID: <53177232-9cce-c794-c90d-7f1eff9666aa@freebsd.org> Date: Sat, 27 Oct 2018 23:17:03 +0200 User-Agent: Mutt/1.5.21 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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, 27 Oct 2018 21:17:07 -0000 On 10/27/18 11:00 PM, Niclas Zeising wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > [ cross posted to several FreeBSD lists. > Please keep replies to x11@FreeBSD.org ] > Yes, I know the signature is BAD. GPG is as user friendly as always. I'm about to re-send this with a (hopefully) good signature. Apologies for the spam. -- Niclas Zeising From owner-freebsd-stable@freebsd.org Sat Oct 27 21:22:52 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8503410D44A0 for ; Sat, 27 Oct 2018 21:22:52 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id AC5997BF59 for ; Sat, 27 Oct 2018 21:22:51 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 68DA810D4496; Sat, 27 Oct 2018 21:22:51 +0000 (UTC) Delivered-To: stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4DB1110D4492; Sat, 27 Oct 2018 21:22:51 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2607:f740:d:20::25]) (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 D30DD7BF54; Sat, 27 Oct 2018 21:22:50 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from cid.daemonic.se (localhost [IPv6:::1]) by mail.daemonic.se (Postfix) with ESMTP id 42jDNT6ND0zDhxn; Sat, 27 Oct 2018 21:22:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mail.daemonic.se ([IPv6:::1]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256) by cid.daemonic.se (mailscanner.daemonic.se [IPv6:::1]) (amavisd-new, port 10587) with ESMTPS id IB-N7HZ4VFOY; Sat, 27 Oct 2018 21:22:49 +0000 (UTC) Received: from garnet.daemonic.se (unknown [IPv6:2001:470:dca9:201:9eda:3eff:fe70:24c0]) by mail.daemonic.se (Postfix) with ESMTPSA id 42jDNT0nLWzDhFd; Sat, 27 Oct 2018 21:22:49 +0000 (UTC) To: current@freebsd.org, stable@freebsd.org, ports@freebsd.org, x11@freebsd.org From: Niclas Zeising Subject: FreeBSD x11-servers/xorg-server and CVE-2018-14665 Message-ID: <843df95a-ae39-4fd4-9d30-9cd369776f3f@freebsd.org> Date: Sat, 27 Oct 2018 23:22:48 +0200 User-Agent: Mutt/1.5.21 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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, 27 Oct 2018 21:22:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 [ cross posted to several FreeBSD lists. Please keep replies to x11@FreeBSD.org ] Hi! As some of you are aware, the X.org project posted a security advisory on October 25 regarding a vulnerability in xorg-server [1]. This has been given the identifier CVE-2018-14665 [2]. The version of xorg-server in the FreeBSD ports tree is not vulnerable. In short, there is a vulnerability in versions 1.19 through 1.20.2 of xorg-server, when installed setuid root, which allows an attacker to overwrite or create any file on the system. By using this vulnerability, a local user can gain root privileges. There are several articles about this [3] [4]. The code in question was introduced on xorg-server 1.19, and as FreeBSD is still using xorg-server 1.18.4 we are not vulnerable to this issue. If you have questions or comments regarding this, don't hesitate to contact me or to send a message to the x11@FreeBSD.org mailing list. Regards Niclas Zeising FreeBSD X11/Graphics Team [1] https://lists.x.org/archives/xorg-announce/2018-October/002927.html [2] https://nvd.nist.gov/vuln/detail/CVE-2018-14665 [3] https://arstechnica.com/information-technology/2018/10/x-org-bug-that-gives-attackers-root-bites-openbsd-and-other-big-name-oses/ [4] https://www.securepatterns.com/2018/10/cve-2018-14665-xorg-x-server.html -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE+Ll/478KgNjo+JKEu41LV7uLVVEFAlvU1AgACgkQu41LV7uL VVEbJA//X6jZBPlBgv86w0zD2kxvBEu9wdx4Ib2MwRHAFmnhkv4vkOK37cmkNl35 PJII8TE+9+AoOdm+jybZqJJDqyl54uLh1M46BTuE4LQkvhCyHlMKUaBaQmcBMGyE 9j/hKKr4aaHXwFKZS+Cy/KhKytAOR6le1r07KlmWBTw6SPq4Bm8+KWXjceiFdlkF GvCF35PeiJ+aIBIT/5ufVJHaUqNZZF8jtuCpNEgSotLogX/HfWYvMhf/ExC6JijA OuYLjw/xZmGNKg68QM0AN1dFB83JYx/eIZMVCRWj9Rt/ypeF7ISM/qkypW1OOHMr a9uwEhO6qTr7drfb/pX4/Y+Z9/pumIWQIZgAI9aYzBY9T+op2qifKTFEqpxfXTCj wuFDKP270la3prhs2hp+q+LgsGxTv9BelodQh5NsNHuKWb6Fzro7Vsy189wg6ulK E+tQ8qNbWQLfUHVCkCthe1nfLAX2KrOEgDMxWjlgPM5BPIU8JancCjuz02wQ6AiU lBMfMCW4b5fDZZMqSNNpDW0kiAvXt+aewA23tAmhNSSmSRFXUXlV6UKw3anU3R0G xVkN8dXnkhWSVfMWXUy92aYHUr1eTZDclSEZlrgJGfLI+DY2OXWDnvsUwm2wPhIR YSYvrI2iJa31qoF05t6bpJY3USRORHg+OlrGlVnOPXK4rar/Z6M= =0NLO -----END PGP SIGNATURE-----