Bug 238729 - head -r347549 on aorus gaming 7 F12e BIOS (Threadripper 1950X): boot attempts hang (but boots for fedora/Windows 10 Pro)
Summary: head -r347549 on aorus gaming 7 F12e BIOS (Threadripper 1950X): boot attempts...
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-20 23:05 UTC by Mark Millard
Modified: 2019-12-08 01:43 UTC (History)
0 users

See Also:


Attachments
dsdt.dat to .asl conversion (zipped) (31.56 KB, application/zip)
2019-06-20 23:11 UTC, Mark Millard
no flags Details
gzip holding *.dsl files from iasl -d (not including dsdt) (81.71 KB, application/x-gzip)
2019-06-21 21:23 UTC, Mark Millard
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Millard 2019-06-20 23:05:24 UTC
[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 .)
Comment 1 Mark Millard 2019-06-20 23:11:41 UTC
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.
Comment 2 Conrad Meyer freebsd_committer 2019-06-20 23:46:46 UTC
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.
Comment 3 Conrad Meyer freebsd_committer 2019-06-20 23:50:24 UTC
(This dump doesn't have an APIC section.)
Comment 4 Mark Millard 2019-06-21 00:46:01 UTC
(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.
Comment 5 Mark Millard 2019-06-21 00:51:42 UTC
(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.
Comment 6 Mark Millard 2019-06-21 05:59:19 UTC
(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".)
Comment 7 Mark Millard 2019-06-21 06:13:13 UTC
(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.
Comment 8 Andriy Gapon freebsd_committer 2019-06-21 06:35:20 UTC
(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.
Comment 9 Mark Millard 2019-06-21 21:23:02 UTC
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).
Comment 10 Mark Millard 2019-06-21 21:42:31 UTC
(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 .
Comment 11 Mark Millard 2019-06-22 03:55:14 UTC
(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.
Comment 12 Mark Millard 2019-06-22 07:36:36 UTC
(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.)
Comment 13 Mark Millard 2019-06-24 01:00:00 UTC
(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.
Comment 14 Mark Millard 2019-07-06 21:50:58 UTC
(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.
Comment 15 Mark Millard 2019-12-08 01:43:56 UTC
(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.)