From owner-freebsd-current@freebsd.org Sun Oct 21 05:33:07 2018 Return-Path: Delivered-To: freebsd-current@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 37685FCECA5 for ; Sun, 21 Oct 2018 05:33:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 AB37C7C66B for ; Sun, 21 Oct 2018 05:33:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2c.google.com with SMTP id y195so11899433vsc.7 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=hokl2JPfwSb+/ce01lptXGwT+DfCodKtoK0mncjFg2ezMkhpQaT51YXpbJd3YbahUx pGaMvkEzjqMUg8RKtjr6J85NBS0KPdIEft4rxEklou8adky6+nAIa9UbYL8kmhRb67x/ +csJ9LPj9Dr+wmKZCIJnGyJQya7rga4qV/uYAYKjVamaeybipSLUNdLXF1H7o2I41ly6 ZoIByYXtoCOxiqiw+cNgjsdCDtLudhSUvl/Lt2uGhgx4QtaENShWRdTPJ+35dvGsuEYF dzUerTttTk8BKuIauurzMDlD+ie2KE6fAI4OoK0/yEIg+kps0Z0hEAswi1K4GjZKnSdj wZGg== X-Gm-Message-State: ABuFfojBqRBfpOxyyArPiJ/6kXe/t7WlI61ZeNMA7sbdI8Ae7WWx9r7O yJGnLmuRR8CbCH3WKVSgEfl7ecZWj1g2C2BLxXEyuQ== 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-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 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