Damnation

@Andalu So it seems more than 1 ACPI table has the compiler date 20160527 attached to it. Unfortunately since there is more than 1 table with this date We'll need to run a windbg session to find out exactly which one it is.

@Andalu can you download the latest iasl tools - https://acpica.org/sites/acpica/files/iasl-win-20220331.zip then run acpidump -b from inside an empty folder, then upload the ACPI .dat files it outputs. I want to see what we're dealing with. edit: does deep translator still works - yeah it still works.

@Andalu Can you boot into Vista or 7? or do you run into the A5 DDB error there too like I do?

I'm uploading my ACPI tables here. @Mov AX, 0xDEAD I think the table named BIXBY (ssdt4) might be causing the problem since it has no closing } bracket - what do you think? acpidump -sz ACPI: MCFG 0x006845CA02D5F8D8 00003C (v01 AMD A M I 03242016 MSFT 00010013) ACPI: FACP 0x006845CA02D5F8D8 000114 (v06 AMD A M I 03242016 AMI 00010013) ACPI: APIC 0x006845CA02D5F8D8 000482 (v03 AMD A M I 03242016 AMI 00010013) ACPI: IVRS 0x006845CA02D5F8D8 0001F0 (v02 AMD AmdTable 00000001 AMD 00000000) ACPI: HPET 0x006845CA02D5F8D8 000038 (v01 AMD A M I 03242016 AMI 00000005) ACPI: FPDT 0x006845CA02D5F8D8 000044 (v01 AMD A M I 01072009 AMI 01000013) ACPI: SSDT 0x0000000000000000 00C034 (v01 GBT GSWApp 00000001 INTL 20160930) ACPI: SSDT 0x0000000000000000 008C98 (v02 AMD AmdTable 00000002 MSFT 04000000) ACPI: SSDT 0x0000000000000000 003918 (v01 AMD AMD AOD 00000001 INTL 20160930) ACPI: FIDT 0x0000000000000000 00009C (v01 AMD A M I 03242016 AMI 00010013) ACPI: SSDT 0x0000000000000000 000164 (v02 AMD CPUSSDT 03242016 AMI 03242016) ACPI: SSDT 0x0000000000000000 000024 (v01 AMD BIXBY 00001000 INTL 20160930) ACPI: PCCT 0x0000000000000000 00006E (v02 AMD AmdTable 00000001 AMD 00000000) ACPI: SSDT 0x0000000000000000 005AC1 (v01 AMD AmdTable 00000001 AMD 00000001) ACPI: CRAT 0x0000000000000000 002CD0 (v01 AMD AmdTable 00000001 AMD 00000001) ACPI: CDIT 0x0000000000000000 000029 (v01 AMD AmdTable 00000001 AMD 00000001) ACPI: SSDT 0x0000000000000000 002D5B (v01 AMD SHAKTOOH 00000001 INTL 20160930) ACPI: WSMT 0x0000000000000000 000028 (v01 AMD A M I 03242016 AMI 00010013) ACPI: SSDT 0x0000000000000000 0013FE (v01 AMD SHAKTOOH 00000001 INTL 20160930) ACPI: XSDT 0x0000000000000000 0000BC (v01 AMD A M I 03242016 AMI 01000013) ACPI: DSDT 0x0000000000000000 00ED30 (v02 AMD A M I 03242016 INTL 20160930) BIXBY is first table in memory at 000024 if I'm reading this right? TRX40_DESIGNARE_ACPI_DUMP.7z

@Dietmar@Mov AX, 0xDEAD@daniel_k I tested acpi v22 with and without DDB hack on my AMD Threadripper system. acpi v22 without DDB hack: A5 0x11 0x08 0x20160930 acpi v22 with DDB hack: works (minus USB 3.0) no BSOD Seems I don't quite get the same the A5 0x03 BSOD that @Andalu gets. . @Mov AX, 0xDEAD Windows 8.1 (not 8.0 or earlier) has a working LoadDDB function for TRX4 - can you copy that in assembly to use for XP?

@Dietmar I will test these acpi.sys on my Ryzen Threadripper system when I have time tomorrow.

@Dietmar I use razzle free offline and to build I just do bcz

@Dietmar awesome! @Mov AX, 0xDEAD Besides that unresolved unknown AMLILoadDDB BSOD have we resolved all known ACPI BSODs?

@daniel_k@Mov AX, 0xDEAD I asked @Dietmar to test this code else if (! ((PDEVICE_EXTENSION)Pdo->DeviceExtension)->Flags & DEV_CAP_PCI_DEVICE ) { // return STATUS_NOT_FOUND; } he reported that he still got a 7E BSOD, so this did not work. edit: I see now @Mov AX, 0xDEAD posted an update with an extra ( bracket, that might be why the above code didn't work.

@Dietmar odd, I commented out line 3526 yet it still says assert failed for // ASSERT(PciInterfacesInstantiated) ? I'm tired, I'll try something else tomorrow. Thanks for testing.

@Dietmar I commented out ASSERT(PciInterfacesInstantiated) still BSOD? https://anonfiles.com/34u6daW9x3/acpi_checked_crackprt_test5_7z

@Dietmar hopefully this one is different~ https://anonfiles.com/raZ1cfW1x5/acpi_checked_crackprt_test3_7z

@Dietmar and this one? https://anonfiles.com/73gdc4W8x6/acpi_checked_crackprt_test2_7z

@Dietmar Can you test this checked acpi.sys to see if 7E BSOD still happens? https://anonfiles.com/V2A4b2Wex5/acpi_checked_crackprt_test1_7z

Other than not needing to apply your hack to acpi.sys every time we build it I'm not sure, I don't recall ever making use of the GPIO.

@Mov AX, 0xDEAD @daniel_k Could we use code from reactos for unsupported opcodes?

@Dietmar I downloaded the BIOS for the ASRock B550 Steel Legend (board I chose for a build, still waiting for it on backorder) checked it's DSDT, it also has Device (GPIO) { Name (_HID, "AMDI0030") // _HID: Hardware ID Name (_CID, "AMDI0030") // _CID: Compatible ID Name (_UID, Zero) // _UID: Unique ID Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (RBUF, ResourceTemplate () { Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, ) { 0x00000007, } Memory32Fixed (ReadWrite, 0xFED81500, // Address Base 0x00000400, // Address Length ) }) Return (RBUF) /* \_SB_.GPIO._CRS.RBUF */ } I think perhaps all AMD Ryzen boards use this DSDT code.

@Dietmar maybe try this? if (((PDEVICE_EXTENSION)Pdo->DeviceExtension)->Flags & DEV_CAP_PCI) { // // It's a PCI PDO, which means a root PCI bus, // which means that we should just handle this // as an ISA device. // return STATUS_NOT_FOUND; } elseif (((PDEVICE_EXTENSION)Pdo->DeviceExtension)->Flags & DEV_CAP_ISA) { // return STATUS_NOT_FOUND; }

@Mov AX, 0xDEAD For the unknown error in _AMLILoadDDB could we feasibly use the version from windows 8.1? . psuedocode of AMLILoadDDB 8.1 generated by relyze int __fastcall _AMLILoadDDB( int p1, int p2 ) { unsigned short local_0x2C; // [esp-44] unsigned short local_0x2A; // [esp-42] unsigned short local_0x26; // [esp-38] unsigned int local_0x24; // [esp-36] int v1; // [esp-30] int v2; // [esp-26] int v3; // [esp-22] void * local_0xC; // [esp-12] unsigned int local_0x8; // [esp-8] int v4; // eax local_0x2C = 0; local_0xC = 0; local_0x2A = 0; local_0x8 = 0; local_0x26 = 0; local_0x24 = 0; v1 = 0; v2 = 0; v3 = 0; if( _ghQueryDLMSupportHandler != 0 ) { _ghQueryDLMSupportHandler( &local_0x8 ); } else { local_0x8 = 0; } _gDeviceLockMutexSupported = local_0x8; v4 = _NewContext( &local_0xC ); if( v4 == 0 ) { *((unsigned char *)local_0xC + 176) = _gpheapGlobal; v4 = LoadDDB( _gpnsNameSpaceRoot, &local_0x2C ); if( v4 == 0 ) { v4 = SyncLoadDDB( local_0xC ); } } if( p2 != 0 ) { *p2 = local_0x24; } return v4; }

@Dietmar Just an idea - for ACPIArbCrackPRT can you try this out? // if (((PDEVICE_EXTENSION)Pdo->DeviceExtension)->Flags & DEV_CAP_PCI) { if (!((PDEVICE_EXTENSION)Pdo->DeviceExtension)->Flags & DEV_CAP_PCI) { // // It's a PCI PDO, which means a root PCI bus, // which means that we should just handle this // as an ISA device. // return STATUS_NOT_FOUND; } } ASSERT(PciInterfacesInstantiated); still 7E BSOD? or something else?

@Dietmar do you mean having ULONG64 for CreateQWordField instead of ULONG? after this is changed A5 0x02 is gone?

@Mov AX, 0xDEAD Maybe try comparing nonworking ACPIArbCrackPRT to working LinkNodeCrackPrt to try and find what LinkNodeCrackPrt does differently to avoid the BSOD?

@Mov AX, 0xDEAD So is acpi.sys expecting DEV_CAP_PCI to be a PDO but it is something else?

@WinWord2000 I'm taking a break from working on it for now.

@Dietmar Looking at the logs there, I'm a bit more confident that if (((PDEVICE_EXTENSION)Pdo->DeviceExtension)->Flags & DEV_CAP_PCI) is the cause I think try commenting it out, compile and test.