CPU: AMD Ryzen 5 2500U Bios: latest Kernel hang. Try 12 stable, 12 release (memstick) from freebsd.org.
Created attachment 203257 [details] screenshot
Created attachment 203260 [details] hint.apic.0.disabled="1" Panic with: hint.apic.0.disabled="1"
I try also hw.mca.enabled=0, but it panic on cpu_initclocks_bsp(). - "No usable event timer found!"
With hw.pci.mcfg=0 - boot ok.
Can you try adding debug printfs to see which PCI config accesses are occurring just before it hangs as well as was done in the other bug? Also, can you provide the output of 'acpidump -dt' as an attachment?
Created attachment 203759 [details] acpidump -dt
(In reply to John Baldwin from comment #5) Do I need apply this patch https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231760#c7 to get debug printfs?
I just looked at your acpidump and you have the same exact issue I recently debugged in 231760, namely your _PIC method invokes a \_SB_.PCI0.NAPE method that accesses the PCI MCFG window directly. *** This bug has been marked as a duplicate of bug 231760 ***
A commit references this bug: Author: jhb Date: Sat Aug 3 01:36:07 UTC 2019 New revision: 350551 URL: https://svnweb.freebsd.org/changeset/base/350551 Log: Don't reset memory attributes when mapping physical addresses for ACPI. Previously, AcpiOsMemory was using pmap_mapbios which would always map the requested address Write-Back (WB). For several AMD Ryzen laptops, the BIOS uses AcpiOsMemory to directly access the PCI MCFG region in order to access PCI config registers. This has the side effect of remapping the MCFG region in the direct map as WB instead of UC hanging the laptops during boot. On the one laptop I examined in detail, the _PIC global method used to switch from 8259A PICs to I/O APICs uses a pair of PCI config space registers at offset 0x84 in the device at 0:0:0 to as a pair of address/data registers to access an indirect register in the chipset and clear a single bit to switch modes. To fix, alter the semantics of pmap_mapbios() such that it does not modify the attributes of any existing mappings and instead uses the existing attributes. If a new mapping is created, this new mapping uses WB (the default memory attribute). Special thanks to the gentleman whose name I don't have who brought two affected laptops to the hacker lounge at BSDCan. Direct access to the affected systems permitted finding the root cause within an hour or so. PR: 231760, 236899 Reviewed by: kib, alc MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D20327 Changes: head/sys/amd64/amd64/pmap.c head/sys/i386/i386/pmap.c head/sys/i386/i386/pmap_base.c head/sys/i386/include/pmap_base.h
A commit references this bug: Author: jhb Date: Sat Aug 24 00:36:01 UTC 2019 New revision: 351449 URL: https://svnweb.freebsd.org/changeset/base/351449 Log: MFC 350551: Don't reset memory attributes when mapping physical addresses for ACPI. Previously, AcpiOsMemory was using pmap_mapbios which would always map the requested address Write-Back (WB). For several AMD Ryzen laptops, the BIOS uses AcpiOsMemory to directly access the PCI MCFG region in order to access PCI config registers. This has the side effect of remapping the MCFG region in the direct map as WB instead of UC hanging the laptops during boot. On the one laptop I examined in detail, the _PIC global method used to switch from 8259A PICs to I/O APICs uses a pair of PCI config space registers at offset 0x84 in the device at 0:0:0 to as a pair of address/data registers to access an indirect register in the chipset and clear a single bit to switch modes. To fix, alter the semantics of pmap_mapbios() such that it does not modify the attributes of any existing mappings and instead uses the existing attributes. If a new mapping is created, this new mapping uses WB (the default memory attribute). Special thanks to the gentleman whose name I don't have who brought two affected laptops to the hacker lounge at BSDCan. Direct access to the affected systems permitted finding the root cause within an hour or so. PR: 231760, 236899 Changes: _U stable/11/ stable/11/sys/amd64/amd64/pmap.c stable/11/sys/i386/i386/pmap.c _U stable/12/ stable/12/sys/amd64/amd64/pmap.c stable/12/sys/i386/i386/pmap.c