On 2018-Oct-20, at 10:32 PM, Warner Losh <imp at bsdimp.com> wrote: > On Sat, Oct 20, 2018 at 11:04 PM Mark Millard <marklmi at yahoo.com> wrote: > [I found what change lead to the 1950X boot crashing > with BTX halted.] > >> On 2018-Oct-20, at 12:44 PM, Mark Millard <marklmi at yahoo.com> wrote: >> >> > [Adding some vintage information for a loader >> > that allowed a native boot.] >> > >> > On 2018-Oct-20, at 4:00 AM, Mark Millard <marklmi at yahoo.com> 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? No zfs in use at all. It has been years since I experimented with ZFS and reverted back to UFS. # gpart show -l => 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.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)Received on Sun Oct 21 2018 - 05:05:21 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:18 UTC