[This extracts notes from bugzilla 237063 for a different issue with the F11e BIOS.] Windows 10 Pro and Fedora 27/28/29/30 still boot fine with the F12e BIOS update. But FreeBSD hangs, including the older 12-current copies I still had around, not ust the 13-current that I've been using. This might be some form of "quality of error handling" issue. (The only reason for the fedora 27/.../30 is that I did the upgrade sequence under F12e and they all worked.) I can still boot all the FreeBSD's under Hyper-V (same media plugged in the same places either way). Boot verbose for a debug kernel with BIOS F12e reported (typed from screen picture): . . . crypto: cryptsoft0 registers alg ?? flags 0 maxoplen 0 ... acpi0: <AMD> on motherboard ACPI: 8 ACPI AML tables successfully acquired and loaded PCIe: Memory mapped configuration base @ 0xf0000000 ioacpi0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: Power Button (fixed) acpi0: wakeup code va 0xfffffe0005dff000 pa 0x98000 And that was all that was output. With Verbose SYSINIT instead it reported: (the 3 hpt_init(0)'s are not typos) . . . module_register_init(&nvd_mod)... done. subsystem 3800000 hpt_init(0)... done. hpt_init(0)... done. configure_first(0)... done. hpt_init(0)... done. module_register_init(&cam_moduledata)... done. fbd_evh_init(0)... done. module_register_init(&ata_moduledata)... done. configure(0)... nexus0 vtvga0: <VT VGA driver> on motherboard cryptosoft0: <software crypto> on motherboard acpi0: <AMD> on motherboard acpi0: Power Button (fixed) And that was all that was output for this context. (Mixing in boot verbose scrolls the SYSINIT information off screen and so does not show anything new.) I got a dsdt.dat from fedora and decoded it using FreeBSD's acpidump -f so I'll upload that. (So less information than what freebsd would show for acpiudump -dt .)
Created attachment 205242 [details] dsdt.dat to .asl conversion (zipped) I got a dsdt.dat from fedora 27 (that does boot the configuration) and used FreeBSD's acpidump -f to decode it. This has less information that a FreeBSD acpidump -dt would report but it might be useful.
The next lines that show up in boot for me with 1950x are: cpu0: <ACPI CPU> on acpi0 hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 So I guess cpu0 is stuck in probe.
(This dump doesn't have an APIC section.)
(In reply to Conrad Meyer from comment #3) I'm unsure just what comment 3 is indicating. The FreeBSD acpidump either uses /dev/mem or uses a dsdt input file (via -f). Quoting: Since only the DSDT is stored in the file, the -t flag may not be used with this option. /dev/mem is not available because of lack of booting. That left me with only dsdt as an option via that tool. (Running under Hyper-V does not have a matching acpi context in its /dev/mem and so is not useful. As stands I'm unable to native-boot using FreeBSD.) So all I got from FreeBSD's acpidump was dsdt decoding from the dsdt.dat that I manged to get from fedora. I've not yet figured out what all I can get from fedora's tools. acpidump is definitely not the same as FreeBSD's and there is a acpixtract as well.
(In reply to Mark Millard from comment #4) I should note that fedora produced a bunch of *.dat files but FreeBSD's acpidump only has an option for the dsdt.dat file, none of the rest.
(In reply to Mark Millard from comment #5) fwts (a batch run) on fedora may have reported some interesting material. (I've no prior use so I'd not know if some of this is the tool itself.) QUOTE klog: Scan kernel log for errors and warnings. -------------------------------------------------------------------------------- Test 1 of 1: Kernel log error check. FAILED [CRITICAL] KlogAmdIommuNoIVRS: Test 1, CRITICAL Kernel message: [ 0.999781] AMD-Vi: [Firmware Bug]: : IOAPIC[130] not in IVRS table ADVICE: BIOS setup is configured to enable IOMMU, but BIOS lacks IVRS table that is describing which is the address of IOMMU FAILED [HIGH] KlogAcpiBadAmlCode: Test 1, HIGH Kernel message: [ 9.142618] ACPI Warning: SystemIO range 0x0000000000000B00-0x0000000000000B08 conflicts with OpRegion 0x0000000000000B00-0x0000000000000B0F (\GSA1.SMBI) (20190215 /utaddress-204) END QUOTE (I ignore examples of DMISerialNumber being 'Unknown'.) There are examples like: FAILED [LOW] DMIStringIndexOutOfRange: Test 2, Out of range string index 0x0c while accessing entry 'BIOS Language Information (Type 13)' @ 0x000eb1da, field 'BIOS Language String 12', offset 0x04 There are: cpufreq: CPU frequency scaling tests. -------------------------------------------------------------------------------- Can't access cpufreq info for CPU 0 Failed to parse cpufreq for CPU 0 Aborted test, initialisation failed. . . . apicedge: APIC edge/level test. -------------------------------------------------------------------------------- Test 1 of 1: Legacy and PCI Interrupt Edge/Level trigger tests. FAILED [MEDIUM] LegacyIRQLevelTrig: Test 1, Legacy interrupt 7 is incorrectly level triggered. There are various examples reported of: Missing ACPI table 'FACP' and the FACP points to it. Cannot initialise ACPI. Aborted test, initialisation failed. There is: rsdp: RSDP Root System Description Pointer test. -------------------------------------------------------------------------------- Test 1 of 1: RSDP Root System Description Pointer test. PASSED: Test 1, RSDP first checksum is correct FAILED [LOW] RSDPBadOEMId: Test 1, RSDP: oem_id contains non-printable characters. and: osilinux: Disassemble DSDT to check for _OSI("Linux"). -------------------------------------------------------------------------------- Test 1 of 1: Disassemble DSDT to check for _OSI("Linux"). FAILED [MEDIUM] NoDSDT: Test 1, Could not read ACPI DSDT table. and: madt: MADT Multiple APIC Description Table (spec compliant). -------------------------------------------------------------------------------- Cannot read ACPI MADT tables. Aborted test, initialisation failed. and: Test 2 of 4: Test HPET base in HPET table. ACPI table HPET does not exist! Test 3 of 4: Test HPET base in DSDT and/or SSDT. WARNING: Test 3, Test skipped because HPET Device address was not found in DSDT /SSDT. (But I've generally ignored reports of "ACPI ??? table does not exist, skipping test".)
(In reply to Mark Millard from comment #6) There is also: . . . Command: "fwts acpidump -". Running tests: acpidump. acpidump: Dump ACPI tables. -------------------------------------------------------------------------------- Test 1 of 1: Dump ACPI tables. RSDP @ f05b0 (36 bytes) ---- [000h 0000 8] Signature : "RSD PTR " [008h 0008 1] Checksum : 41 [009h 0009 6] Oem ID : " AMD" [00fh 0015 1] Revision : 02 [010h 0016 4] RSDT Address : 76de5028 [014h 0020 4] Table Length : 00000024 [018h 0024 8] XSDT Address : 0000000076de50a8 [020h 0032 1] Extended Checksum : 90 [021h 0033 3] Reserved : 00 00 00 And that is where "fwts acpidump -" stops.
(In reply to Mark Millard from comment #5) I think that you can use iasl -d to decompile most, if not all, of those .dat files.
Created attachment 205272 [details] gzip holding *.dsl files from iasl -d (not including dsdt) The *.dat files were from fedora (which boots the machine). I used the FreeBSD iasl command (via Hyper-V use).
(In reply to Mark Millard from comment #9) Among other things, ssddt5.dsl seems odd (truncated). But ssdt5.dat was only 36 bytes long in the first place, much shorter than any other ssdt*.dat .
(In reply to Mark Millard from comment #10) Using: options ACPI_DEBUG and: hw.acpi.verbose=1 debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS" debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" The output stopped with (typed from a screen picture): exregion-0323 ExSystemMemorySpaceHan: System-Memory (width 8) R/W 0 Address=00000000771ED01F The earlier part of the screen was similar, with Address varying.
(In reply to Mark Millard from comment #11) Trying: hw.acpi.verbose=1 debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS" debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS ACPI_LV_OPREGION ACPI_LV_TABLES ACPI_LV_VALUES ACPI_LV_OBJECTS ACPI_LV_RESOURCES ACPI_LV_USER_REQUESTS ACPI_LV_PACKAGE" showed a few more lines before stopping all output: utownerid-0254 UtAllocateOwnerId : Allocated OwnerId: 92 evrgnini-0739 EvInitializeRegion : Found handler 0xfffff80c850ebf00 for region 0xfffff80100c8b200 in obj 0xfffff80100abc000 evregion-0654 EvAttachRegion : Adding Region [VARM] 0xfffff80100c8b200 to address handler 0xfffff80c850ebf00 [SystemMemory] evregion-0400 EvAddressSpaceDispatch: Handler 0xfffff80c850ebf00 (@0xffffffff803f6d30) Address 000000000F0002044 [SystemMemory] (And no more was output.)
(In reply to Mark Millard from comment #12) Well adding ACPI_LV_DISPATCH ACPI_LV_NAMES still gets the same last line, although it had more lines output before that: hw.acpi.verbose=1 debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS" debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS ACPI_LV_DISPATCH ACPI_LV_NAMES ACPI_LV_OPREGION ACPI_LV_TABLES ACPI_LV_VALUES ACPI_LV_OBJECTS ACPI_LV_RESOURCES ACPI_LV_USER_REQUESTS ACPI_LV_PACKAGE" The other additions that I've tried, such as ACPI_LV_EXEC , kept going longer then I waited. I've no if it had got past that previously-last-line or not. (I only see about 30 lines on screen and it goes by too fast to read.) I've not figured out a way to further narrow the range for what the boot hangs up on --so I'm not trying anything new any more. The above levels are not reporting anything once the boot is hung up (relative to seeing messages). The hang up seems to be too early to allow normal ddb use via the keyboard.
(In reply to Mark Millard from comment #13) I have reverted to BIOS F11e in order to allow native booting of FreeBSD as it currently is. F11e has an oddity of one CPU of 32 not showing up in various places in FreeBSD but FreeBSD is generally operable with F11e.
(In reply to Mark Millard from comment #14) I finally tried BIOS F12h (with head -r355027). This booted fine as native FreeBSD. (I've not tested for the likes of F11e's causing some places to show 31 cpus instead of 32.)