Bug 235509

Summary: BTX Freezes during boot on Supermicro H8DGi-F after update to 12.0
Product: Base System Reporter: Zachary Sandberg <zachary.sandberg>
Component: miscAssignee: freebsd-bugs mailing list <bugs>
Status: New ---    
Severity: Affects Only Me CC: grahamperrin, john, nelson4088, pi
Priority: --- Keywords: regression
Version: 12.0-RELEASE   
Hardware: amd64   
OS: Any   

Description Zachary Sandberg 2019-02-05 05:39:06 UTC
I recently performed an in-place upgrade of my 11.2 system to 12.0, and upon reboot the machine freezes at the BTX loader screen after twirling the little loading cursor for a few seconds.  I get the same result with a fresh download of version 12 booting off a USB stick as well.

I've tried booting a USB of 11.2 (works!) and also disabling the WHEA ACPI feature in the BIOS (as reported by another user who reported that that setting was a workaround for a 10.0 BTX issue).

My hardware is a Supermicro H8DGi-F motherboard with two Opteron 6300s, 64GB of RAM, Intel i350-T4, and a Broadcom SAS 9207-8i HBA.  It's been working wonderfully on FreeBSD 11.1 and 11.2 for a while now.

Anyone have a suggestion on what to do?
Comment 1 Andriy Gapon freebsd_committer 2019-02-05 06:45:23 UTC
It could matter what boot fileystem you use, how your boot disk(s) are partitioned, etc.
Comment 2 Zachary Sandberg 2019-02-06 05:48:57 UTC
(In reply to Andriy Gapon from comment #1)

I'm not quite sure what you mean.  The boot filesystem is the live USB, and (correct me if I'm wrong) but I don't suspect that my physical disks are read from or even seen at this point in the boot process if off a USB stick.

I will unplug the HBA and see if that makes a difference.  I have no disks hooked up to any of the SATA ports on the motherboard, so this should be easy to test.
Comment 3 Graham Perrin 2019-02-08 07:13:58 UTC
Cross reference https://redd.it/aod9py
Comment 4 john 2019-03-26 15:50:35 UTC
The unified ufs / zfs loader probes all the drives.
Details and a patch are in PR 236585.
Comment 5 john 2019-03-26 16:21:11 UTC
If the patch doesn't help, then what you can do is add print statements
to find out where the loader is going splat.  The PR I mentioned lists
some of the routines of interest.  To debug I built the loader, copied
to /boot/loader.new, and then during boot manually choose loader.new
(this way the system would still boot normally while chasing down the
issue with the newer loader).
Comment 6 Nelson Leung 2019-06-29 10:29:20 UTC
(In reply to john from comment #4)

I just upgraded my system from 11.2p9 to 12.0 and ran into the same issue and would like to try the patch. 
Could you mind giving some pointers on how to build the loader only. Or do I have to follow the handbook to compile the kernel?

FYI I have a system with only zfs drive. One simple pool for system and another raidz2 pool for data.
I noticed previously in the boot log on 11.2, there are message complaining some of the disks in raidz2 have some inconsistent (? Sorry I can't recall) GPT headers. These were probably because the drives were pre-formatted but the disks were attached to the pool without properly destroying the GPT

Thanks.