Date: Sat, 20 Oct 2018 12:44:50 -0700 From: Mark Millard <marklmi@yahoo.com> To: Warner Losh <imp@bsdimp.com>, FreeBSD Current <freebsd-current@freebsd.org>, freebsd-stable@freebsd.org Subject: Re: head -r339076's boot loader fails to boot threadripper 1950X system (BTX halted); an earlier version works Message-ID: <2A425DE4-2B5B-474D-8B95-81890DE4D8A1@yahoo.com> In-Reply-To: <D99F88D8-91CF-4BAD-A7F1-3D93D947BD46@yahoo.com> References: <D99F88D8-91CF-4BAD-A7F1-3D93D947BD46@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[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 === 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?2A425DE4-2B5B-474D-8B95-81890DE4D8A1>