Skip site navigation (1)Skip section navigation (2)
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>