Date: Sun, 21 Oct 2018 00:05:07 -0700 From: Mark Millard <marklmi@yahoo.com> To: Warner Losh <imp@bsdimp.com> Cc: FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org> Subject: Re: head -r339076's boot loader fails to boot threadripper 1950X system (BTX halted); an earlier version works [ -r336532 broke it ] Message-ID: <30DD2F47-C8CB-4CEC-8563-C7083D0EAEEF@yahoo.com> In-Reply-To: <CANCZdfq3376cb8df_D_feJZzCFzkX=3p_=2mggpOHiaZ95uEKw@mail.gmail.com> References: <D99F88D8-91CF-4BAD-A7F1-3D93D947BD46@yahoo.com> <2A425DE4-2B5B-474D-8B95-81890DE4D8A1@yahoo.com> <9D2A6528-F888-4833-A52B-8F9B4D66592C@yahoo.com> <CANCZdfq3376cb8df_D_feJZzCFzkX=3p_=2mggpOHiaZ95uEKw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.] >=20 >> On 2018-Oct-20, at 12:44 PM, Mark Millard <marklmi at yahoo.com> = 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 <marklmi at yahoo.com> = 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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?30DD2F47-C8CB-4CEC-8563-C7083D0EAEEF>