Dell Inspiron 1420/1520/1720, Vostro 1400/1500/1700, XPS M1330 NVIDIA GPU Shutdown fix

[hidematu5]

Hi everyone,

I've discovered a potential workaround for the long-standing shutdown issue on the Dell Inspiron 1520 (ICH8M + NVIDIA GPU).

It appears that a substantial delay (sleep) is required for the system to shut down properly. By disabling SMI generation (writing 0 to SLP_SMI_EN) followed by a long sleep command—specifically Sleep(0xFFFF) or at least Sleep(0x2710)—I successfully managed to shut down the system on macOS 10.4 to 10.7, as well as Ventura (13), Sonoma (14), and Sequoia (15). Short delays like Sleep(0x10) or Sleep(0x16) invariably fail.

 

Example 1: Standard Sleep Method

OperationRegion (PMRS, SystemIO, 0x1030, One)
Field (PMRS, ByteAcc, NoLock, Preserve)
{
    ,   4, 
    SLPE,   1
}

Method (_PTS, 1, NotSerialized)
{
    If (LEqual (Arg0, 0x05))
    {
        Store (Zero, SLPE)
        Sleep (0x2710) // 10sec
        // or
        // Sleep (0x2710) // 10sec
        // Sleep (0x2710) // 10sec total 20sec
        // or
        // Sleep (0x2710) // 10sec
        // Sleep (0x2710) // 10sec
        // Sleep (0x24B8) // 9.4sec total 29.4sec [Recommended]
        // or
        // Sleep (0xFFFF) // 65.5sec
    }
}

 

Behavior by macOS version (Example 1):

• 10.4 – 10.7: Mostly successful. However, it takes about 30 seconds to 1 minute for the machine to power off after the display goes black. (Note: 10.4 has NVDAResman disabled and shuts down normally even without the SLPE method).

• 10.8 – 10.10: Unstable. It sometimes succeeds, but often results in a black screen with fans spinning continuously or triggers a system reboot.

• 10.11 – 10.12: Always results in a reboot.

• 10.13 – macOS 12: The screen goes black, but the fans keep spinning indefinitely.

• 13 – 15: Mostly successful, though reboots still occur occasionally.

Example 2: Stall Method (Higher Success Rate)

There is an alternative method with a significantly higher success rate using Stall:

Method (_PTS, 1, NotSerialized)
{
    If (LEqual (Arg0, 0x05))
    {
        Store (Zero, SLPE)
        Local0 = 0x4268
        While ((Local0 > Zero))
        {
            Local0--
            Stall (0x64)
        }
    }
}

Behavior by macOS version (Example 2):

• 10.4: NVDAResman disabled; shuts down fine without this method.

• 10.5 – 10.7: Mostly successful, but takes 30 seconds to 1 minute to power off after the screen goes dark.

• 10.8 – 10.10: Unstable. Mostly results in a black screen with running fans or a reboot.

• 10.11 – 10.12: Results in a black screen with running fans or a reboot.

• 10.13 – macOS 12: Screen turns off, but fans spin indefinitely.

• 13 – 15: 100% successful. Furthermore, the system shuts down in less than 10 seconds.

Example 3: While Loop + Short Sleep Method

I also tested another approach using a While loop with shorter sleep increments:

Method (_PTS, 1, NotSerialized)
{
    If (LEqual (Arg0, 0x05))
    {
        Store (Zero, SLPE)
        Local0 = 0x2710
        While ((Local0 > Zero))
        {
            Local0--
            Sleep (0x10)
        }
    }
}

Behavior by macOS version (Example 3):

• 10.4: Works fine without this method (NVDAResman disabled).

• 10.5 – 10.6: Mostly successful, but takes 30 seconds to 1 minute to power off after the screen goes dark.

• 10.7: Unstable. Mostly results in a black screen with running fans or a reboot.

• 10.8 – 15: Always results in a reboot.

Observations & Analysis

It remains unclear why the success rate is high on very old and very new macOS versions, yet highly unstable on mid-generation OS versions. Additionally, the fact that the hardware takes about 30 seconds to a minute to complete the shutdown sequence suggests that it requires a significantly longer preparation time to power off compared to other machines of the same generation. This is almost certainly due to a firmware bug.

While this is an unconventional workaround, it is encouraging to find a viable method for these models, which were previously thought to have no consistent solution for their shutdown issues.

This fix might also apply to the following models:

• Inspiron 1420 / 1520 / 1720

• Vostro 1400 / 1500 / 1700

• XPS M1330

(Note: Rebooting on these models is also unstable—sometimes working, sometimes failing—which likely stems from the same root cause).

 

What I've Tested So Far:

• USB Power: Investigated USB power behavior, but it doesn't seem to be the culprit.

• OSID: Tested with 0x10 (Windows XP) and 0x20 (Windows Vista), but saw no significant change.

• BIOS Settings: Disabled LAN, Wi-Fi, Bluetooth, SDHC, and the module bay in the BIOS, but the issue persists.

For context, this older thread might be relevant: https://www.insanelymac.com/forum/topic/266803-dsdt-shutdown-nvidia-dells-not-zero-slpe-trick-alternate-ich8-method/

If anyone has any insights, suggestions, or ideas for a more fundamental/cleaner fix, I would love to hear them. Any feedback is highly appreciated!

[hidematu5]

[Info] Fixing Slow POST and Boot Loop issues after Shutdown/Reboot (macOS 11+)

 some ACPI/DSDT fixes regarding shutdown, reboot, and POST issues that occur on macOS 11 (Big Sur) and later.

1. Fixing Extremely Slow POST after Shutdown

In macOS 11 and later, there is a known issue where the POST process becomes extremely slow when powering on the machine after a proper shutdown. This can be bypassed by modifying the ACPI RTC device as follows (adjusting the IO length/alignment):

Before:

Device (RTC)
            {
                Name (_HID, EisaId ("PNP0B00") /* AT Real-Time Clock */)  // _HID: Hardware ID
                Name (RT, ResourceTemplate ()
                {
                    IO (Decode16,
                        0x0070,             // Range Minimum
                        0x0070,             // Range Maximum
                        0x10,               // Alignment
                        0x02,               // Length
                        )
                    IO (Decode16,
                        0x0072,             // Range Minimum
                        0x0072,             // Range Maximum
                        0x02,               // Alignment
                        0x06,               // Length
                        )
                })
                Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
                {
                    Return (RT)
                }
            }

After:

Device (RTC)
            {
                Name (_HID, EisaId ("PNP0B00") /* AT Real-Time Clock */)  // _HID: Hardware ID
                Name (RT, ResourceTemplate ()
                {
                    IO (Decode16,
                        0x0070,             // Range Minimum
                        0x0070,             // Range Maximum
                        0x01,               // Alignment
                        0x02,               // Length
                        )
                })
                Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
                {
                    Return (RT)
                }
            }

2. Fixing Boot Loops / Multiple Restarts Before OpenCore Loads

Another common symptom is when the machine is powered on after a shutdown or reboot, it repeatedly restarts a few times right before OpenCore manages to load. This is likely caused by certain power/sleep states not being cleared properly during the shutdown or reboot sequence.

To prevent this, you can define the following operation regions and fields, and explicitly clear the statuses in _PTS:

OperationRegion (PMCR, SystemIO, 0x1004, 0x02)
    Field (PMCR, ByteAcc, NoLock, Preserve)
    {
        SCEN,   1, //SCI_EN
            ,   9, 
        SLPT,   3, // SLP_TYP
        SLPN,   1 //SLP_EN
    }

    OperationRegion (PMRS, SystemIO, 0x1030, 0x08)
    Field (PMRS, ByteAcc, NoLock, Preserve)
    {
            ,   4, 
        SLPE,   1, // SLP_SMI_EN
            ,   31, 
        SLPX,   1 // SLP_SMI_STS
    }

    OperationRegion (PMCB, SystemIO, 0x1000, 0x10)
    Field (PMCB, ByteAcc, NoLock, Preserve)
    {
        P1ST,   16, // PM1A status
        Offset (0x04), 
        P1CN,   16 // PM1A_CNT
    }

    Method (_PTS, 1, NotSerialized)  // _PTS: Prepare To Sleep
    {
        If ((Arg0 == 0x05))
        {
            \_SB.PCI0.EHC1.PMEE = Zero
            \_SB.PCI0.EHC2.PMEE = Zero
            \_SB.PCI0.LPCB.AG3E = One
            P1ST = 0x0800
            P1CN = 0x4900
            SLPX = Zero
            SLPE = Zero
            Local0 = 0x4268
            While ((Local0 > Zero))
            {
                Local0--
                Stall (0x64)
            }
        }
    }

You should also append the status clearing logic to Method (_WAK) and Method (_INI) inside Device (PCI0) as shown below:

Method (_WAK, 1, NotSerialized)  // _WAK: Wake
    {
        P1ST = 0x0800
        P1CN = 0x4900
        SLPX = Zero
        SLPE = Zero
        Sleep (0x10)
        SCEN = One
        Sleep (0x10)
        SMI (0x9A, Arg0)
        Local0 = SMI (0x6D, Zero)
        If ((Local0 == 0x03))
        {
            Local0 = SMI (0x46, Zero)
            \_SB.PCI0.VID.CLID = Local0
            If ((Arg0 == 0x03))
            {
                If (((MIS1 != Local0) || (Local0 == Zero)))
                {
                    If ((OSID () >= 0x20))
                    {
                        \_SB.PCI0.VID.GLID (Local0)
                    }
                    Else
                    {
                        LIDE ()
                    }
                }
            }
        }

        If ((Arg0 == 0x04))
        {
            Notify (\_SB.PWRB, 0x02) // Device Wake
            MIS4 = One
            SOST ()
        }

        MIS0 = SMI (0x98, Zero)
        Notify (\_SB.ADP1, 0x80) // Status Change
        \_SB.PCI0.WKHP ()
        Local0 = HSCO (One)
        If (Local0)
        {
            If ((OSID () >= 0x20))
            {
                Notify (\_SB.MBTN, 0x02) // Device Wake
                HSCO (0x02)
            }
        }

        Return (Package (0x02)
        {
            Zero, 
            Zero
        })
    }

Method (_INI, 0, NotSerialized)  // _INI: Initialize
            {
                P1ST = 0x0800
                P1CN = 0x4900
                SLPX = Zero
                SLPE = Zero
                Sleep (0x10)
                SCEN = One
                Sleep (0x10)
                MIS0 = SMI (0x98, Zero)
                MIS0 &= 0x13
                MIS4 = One
                Local0 = SMI (0x46, Zero)
                Local6 = SMI (0x6D, Zero)
                If ((Local6 == 0x03))
                {
                    ^VID.GLID (Local0)
                }

                SOST ()
            }

add Device (LPCB) or ISAB

		OperationRegion (LPC0, PCI_Config, 0xA4, One)
                Field (LPC0, ByteAcc, NoLock, Preserve)
                {
                    AG3E,   1
                }

Note: For machines that experience issues when waking up from a second consecutive sleep cycle, writing 0 to SLP_SMI_EN inside _WAK might potentially resolve the issue.

By explicitly clearing the statuses like this, the boot loop issue has completely disappeared on my end so far. Hope this helps anyone facing similar ACPI power state headachesOC.zipOC.zip

ACPI_original.zip

DSDT.aml.zip config.plist.zip

Edited 1 hour ago by hidematu5