Re: head -r339076's boot loader fails to boot threadripper 1950X system (BTX halted); an earlier version works [ -r336532 broke it ]
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= err= efl=00010246 eip=96fd > >> eax=74d48000 ebx=74d4e5e0 ecx=0011 edx= > >> esi=74d4e380 edi=74d4e5b0 ebp=00091da0 esp=00091d60 > >> cs=002b ds=0033 es=0033fs=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 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head -r339076's boot loader fails to boot threadripper 1950X system (BTX halted); an earlier version works [ -r336532 broke it ]
On 2018-Oct-20, at 10:32 PM, Warner Losh wrote: > 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= err= efl=00010246 eip=96fd >> >> eax=74d48000 ebx=74d4e5e0 ecx=0011 edx= >> >> esi=74d4e380 edi=74d4e5b0 ebp=00091da0 esp=00091d60 >> >> cs=002b ds=0033 es=0033fs=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 10241 FBSDFSSDboot (512K) 1064 7465861122 FBSDFSSDroot (356G) 746587176 314572803 FBSDFSSDswap (15G) 778044456 1593835524 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
Re: head -r339076's boot loader fails to boot threadripper 1950X system (BTX halted); an earlier version works [ -r336532 broke it ]
[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= err= efl=00010246 eip=96fd >> eax=74d48000 ebx=74d4e5e0 ecx=0011 edx= >> esi=74d4e380 edi=74d4e5b0 ebp=00091da0 esp=00091d60 >> cs=002b ds=0033 es=0033fs=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. . . . === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
