Compiling ACPI v2.0 driver for Windows XP SP3 and Windows 2003 SP2 (x32/x64)

[Dietmar]

@Mov AX, 0xDEAD

Nono, this Bsod was not random.

After dirty hack against this Bsod 0x000000A5 (0x00000002, xxx, 0x00000001, yyy) via jmp

I get Bsod

0x000000A5 (0x00000002, xxx, 0x00000000, yyy)

and after dirty hack via jmp against this,

the bootdevice cant be found any longer.

ALL those problems are gone at once (only(!)) with correct CreateQWordField

Dietmar

 

 

[Damnation]

@Dietmar

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

[Dietmar]

@Damnation

Yepp )

Dietmar

[George King]

1 hour ago, Mov AX, 0xDEAD said:

1) 0xA5 (0x0000000D, ..., ..., ...) duplicated _HID method for AMD boards

2) 0xA5 (0x11, 0x08, ..., ...) unknow error in _AMLILoadDDB

 

I think we need to add support for mentioned H argument, but I have no idea what object type it is.

 

Edited April 10, 2022 by George King

[Dietmar]

@George King

We solved this problem in full with ULONG64 for CreateQWordField

Dietmar

[Damnation]

@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?

[Mov AX, 0xDEAD]

@Dietmar

Check PM for custom acpi.sys if you still interested what wrong on amd board

1)
ed Kd_ACPI_Mask 0xFFFFFFFF

2)
AcpiArbCrackPRT() has additional output, look for "Adding allocation for IRQ" string:

....
Adding allocation for IRQ b for device 81B7F7E0
0x81b7f560 0x69635030 0xf99afb98 0x0
`ї╖Б 0Pci Ш√Ъ∙
PCI Device 81B7F7E0 had _ADR of 5
...
Adding allocation for IRQ f for device 81B82170
0x0 0x0 0x81bacf38 0x81b82170
8╧║Б p!╕Б
Referencing vector f : 0 0


3)
get details of devices:

!devobj 81B7F7E0
Device object (81b7f7e0) is for:
 NTPNP_PCI0005 \Driver\PCI DriverObject 81b69900
Current Irp 00000000 RefCount 0 Type 00000022 Flags 00001040
Dacl e140fd5c DevExt 81b7f898 DevObjExt 81b7f960 DevNode 81b85a68
ExtensionFlags (0000000000)  
Characteristics (0x00000100)  FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) 81adc3e8 \Driver\HDAudBus


!devobj 81B82170
Device object (81b82170) is for:
 PciIde0Channel1-1 \Driver\PCIIde DriverObject 81bacf38
Current Irp 00000000 RefCount 0 Type 00000004 Flags 00001040
Dacl e140fd5c DevExt 81b82228 DevObjExt 81b822e0 DevNode 81bd6dc8
ExtensionFlags (0000000000)  
Characteristics (0x00000100)  FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) 81bd0030 \Driver\atapi

[Damnation]

@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]

@Mov AX, 0xDEAD

I am happy, that you take a deeper look in the problem of Ryzen cpu with XP!

And for sure this helps you also for better understanding XP ).

With this acpi.sys the compi boots to desktop in about 10min on the same AMD board as before.

Loong txt output.

During the whole session with Windbg over Lan, no error message at all.

Here is the log file, hope that it helps you

Dietmar

ottocrack.7z

ottoPCI.7z

Edited April 11, 2022 by Dietmar

[Mov AX, 0xDEAD]

3 hours ago, Dietmar said:

@Mov AX, 0xDEAD

With this acpi.sys the compi boots to desktop in about 10min on the same AMD board as before.

Loong txt output.

During the whole session with Windbg over Lan, no error message at all.

First record about calling AcpiArbCrackPRT():

Quote

8A4BE008 ACPI\AMDI0030-0 (0x8a4bba58): IRP_MN_QUERY_INTERFACE - Res 3 Type = {6c154a...
Adding allocation for IRQ 7 for device 8A545038
0x20 0x5606000 0x5f534750 0x0
 PGS_ Referencing vector 7 : 0 0

PGS_ - internal ACPI device object

you did't !devobj 8A545038

end of log tell about devnodes:

Quote

      DevNode 0x8a499c78 for PDO 0x8a545038
        InstancePath is "ACPI\AMDI0030\0"
        State = DeviceNodeInitialized (0x302)
        Previous State = DeviceNodeUninitialized (0x301)
        Problem = CM_PROB_DISABLED

so AcpiArbCrackPRT was called for AMDI0030 (GPIO) before loading pci.sys as Daniel said before

after quick analyzing DSDT i see this:

Quote

 

    Scope (_SB)
    {
     ....

      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,
                    }

}

 

GPIO connected to SystemBus directly and have _CRS method to inform about claimed IRQ

GPIO is not under usual _SB.PCI0. path - i think this is problem

description of AcpiArbCrackPRT():

Quote

 

Return Value:

If this isn't a PCI device, STATUS_DEVICE_NOT_FOUND.

 

but inside AcpiArbCrackPRT no check for non-pci device *facepalm*

only strange check:

Quote

        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;

 

[daniel_k]

@Mov AX, 0xDEAD

With my patched DSDT table, XP runs with original files, but cannot get C3 working.
Somehow intelppm.sys or acpi.sys goes crazy.

Managed to get C1E working by "skipping" some code.

Can I use debugging to help me to fix the DSDT table?

Edited April 11, 2022 by daniel_k

[daniel_k]

@Mov AX, 0xDEAD

I have a Gigabyte H310 board that crashes XP if Port 60/64 emulation is enabled, so add another problematic device to the list.

[Mov AX, 0xDEAD]

2 minutes ago, daniel_k said:

@Mov AX, 0xDEAD

I have a Gigabyte H310 board that crashes XP if Port 60/64 emulation is enabled, so add another problematic device to the list.

@daniel_k

no BSOD description/log - no workaround

port 60 emulation is bios SMM hack, i think problem in bios code

Edited April 11, 2022 by Mov AX, 0xDEAD

[Mov AX, 0xDEAD]

6 minutes ago, daniel_k said:

@Mov AX, 0xDEAD

With my patched DSDT table, XP runs with original files, but cannot get C3 working.
Somehow intelppm.sys or acpi.sys goes crazy.

Managed to get C1E working by "skipping" some code.

Can I use debugging to help me to fix the DSDT table?

@daniel_k

Sorry, i don't understand DSDT enough, only INTEL knows how this crap works

C3 is ACPI hardware, as i remember anything after 110 chipset has disabled acpi's power-saving part

[Dietmar]

@Mov AX, 0xDEAD

Nice, that you find the reason for this loong standing Bsod!

Do you have an idea, how to forbid a call to AcpiArbCrackPRT() from GPIO (connected to SystemBus directly)

before pci.sys has started? This can be used in general for other "ISA" like devices under XP also.

Of course we can disable AMDI0030 (GPIO) in DSDT for XP,

but maybe some programs (near to hardware) make use of GPIO connected to SystemBus directly.

I think the hack before in acpi.sys comes very close to this idea because Bsod via AcpiArbCrackPRT() without pci.sys is meaningless

Dietmar

Edited April 11, 2022 by Dietmar