Hervé

Check what SysInfo->Wifi reports in terms of reported connection speed and channel. It's probably worth experimenting with some of those AirportBrcmFixup boot args such as brcmfx-country=#a. https://github.com/acidanthera/AirportBrcmFixup

The Wifi part of the wireless card is PCIe based whilst the Bluetooth part is USB used. As such, slow Wifi performance cannot be linked to an issue with USB port mappings. What you see in Hackintool is normal, it's the speed of the USB devices, not the speed of the ports themselves.

I don't think it'd have any influence on Sleep/Wake but it certainly could on a boot time perspective but Samsung 970 Evo Plus was not natively supported unless firmware was updated; can't say which version but it'd be worth checking whether you run on the latest version or not: https://semiconductor.samsung.com/consumer-storage/support/tools/

Quick answer before I get the time look at your posted EFI + IOReg. Too much RAM (32GB) -> No. Slow Wifi (capped at 250Mbps) -> you're probably on a 2.4GHz network; you'll have to hook to a 5GHz network to get beyond this and reach up to 867Mbps I no longer have a 7490 but, during the time I had one, sleep/wake/restart never were a problem at all. Must be some incorrect settings or issues with the kexts you inject. I suspect ACPI patches and/or CPU power management. Start by disabling those CPUFriend kexts if you copied then from a repo rather than generate your own data (always a bad idea for the data kext, it has to match your CPU and desired power settings).

I've made many modifications related to ACPI patches, CPU PM, SIP, graphics, etc. Your posted folder shows no table in ACPI/Patched folder, yet your config called on at least 2 of them so I removed such calls. Please note that you should include tables such as SSDT-PNLF and, of course, your generated CPU PM SSDT (use Pike's good old and well-known generator script to that effect). SSDT-PNLF.aml.zip config.plist.zip You were calling on the HiRes Capri framebuffer 0x01660004 but that's for Hi Res LCD with a resolution of 1600x900 or higher. Given what I've found about your laptop, I've changed the config for the LoRes Capri framebuffer 0x01660003; that's what's needed for LoRes LCD of 1366x768. You're using MBA5,2 SMBIOS and that's fine looking at your CPU model but feel free to experiment with MBP9,2 or MBP10,2 SMBIOS if you're not entirely satisfied with CPU power management. You'll also have to do your USB ports mapping. You can look that up and do it on your own, it's not difficult. Please post your hardware specs if you need further assistance or, ideally, post them in signature like most of us do. It should be systematic if not mandatory...

@lubeats I think there are a few discrepancies in your setup. For instance, you've enabled the ACPI patch that renames _OSI to XOSI but you've no SSDT-XOSI patched table that injects the new _OSI or replacement method. As such, that patch is irrelevant and may cause issues as well... One other thing I noticed in your IOReg is the absence of battery management driver under BAT0. This could be a potential cause for the reset on wake. I use mostly Clover and FakeSMC + ACPIBatteryManager kexts and that registers a driver under BAT0 in IOReg on all my Hacks. But I'll check my Toshiba laptop which runs under OpenCore.

There's an additional parameter some people have had to use in Monterey (12.3.1 I think) for the DW1820A: brcmfx-delay. Meaning you need to inject AirportBrcmFix kext too but I think you do. https://github.com/acidanthera/AirportBrcmFixup/releases In the following post, OP set the delay to 27s, there's a good chance it'll fix your issue too: https://osxlatitude.com/forums/topic/17195-solved-e7270-freeze-trying-to-update-monterey-to-1231-opencore/?do=findComment&comment=114253 There is no firmware you can load on these cards except Bluetooth ones and that won't be of any help re: boot loops/freezes.

Remember to reset NVRAM from OC picker when you reboot after pasting that revised config file in the EFI folder.

You may donate your offered $50 to the site now rather than to me. See bottom of main page. Thank you, much appreciated.

I suggest you read the Dortania documentation because you can't expect or rely on other people to do this kind of things for you... You may edit the config with a Text Editor or Apple Xcode or ProperTree app. You need to remove the # character (highlighted above) that comments out the properties injection for your DW1820A wireless card. ProperTree.zip

Is there any particular reason why, as suggested by PM, you won't uncomment the properties injection for the DW1820A? Without this injection, you're highly likely to encounter system reset or plain freeze at startup.

I understand you already found the thread posted back in March with the same unresolved issue on exact same platform. Your IOReg shows that you've patched both con1 and con2 connectors to HDMI type but you also changed their Pipe : Did you get anywhere with default values, just changing the connector type and nothing else (knowing that this is usually only required to gain HDMI audio)? You would need to monitor your iGPU connectors' behaviour in IOReg as you plug and unplug your HMI cable on/off the laptop. If you see absolutely nothing, you probably have to experiment with different SMBIOS and/or CFL framebuffer layouts. https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md You use ig-platform-id 3EA50009 which is the expected one: ID: 3EA50009, STOLEN: 57 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00830B0A TOTAL STOLEN: 58 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 172 MB, MAX OVERALL: 173 MB (181940224 bytes) Model name: Intel HD Graphics CFL CRB Camellia: CamelliaV3 (3), Freq: 0 Hz, FreqMax: 0 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000098 - ConnectorLVDS [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x000001C7 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x000001C7 - ConnectorDP 00000800 02000000 98000000 01050900 00040000 C7010000 02040A00 00040000 C7010000 You may have to experiment with different combinations of SMBIOS/CFL framebuffer layouts or even patch the connectors further, HDMI usually being attached to connector con1. Did you experiment with WEG igfxonln=1 boot arg at all? https://github.com/acidanthera/WhateverGreen

Touchscreens usually are USB based and require no specific kext for support. Big Sur dropped support for some ancient/older USB stuff and that can prevent items such as Touchscreens to work. I experienced this on my Skylake laptop and only fixed this by applying the USB HID fix.

What if you simply re-open the Bluetooth Prefpane instead after wake and wait a few seconds? Specifying the type of wireless card/bluetooth module/chipset you have would be most useful of course...

Moving to Precision M section where you'll find fairly recent threads about M4800 Hackintosh. Do look those up. Kepler dGPUs are last natively/officially supported in Big Sur. In Monterey, they require specific patching since support was dropped.

That's the spirit; well done.

BCM4352 chipset is not supported OOB; it requires patching. Did you do that? Lookup the existing threads about DW1560, there are several in which you'll find all that needs to be done.

@Lin_25 Before anything else, please post your system's hardware specs (exact CPU model, iGPU model, audio codec, LAN, wireless, card reader, etc.). Latitude 5480 can be Skylake with HD5x0 graphics or Kaby Lake with HD6x0 graphics so settings would differ. Do also consult the numerous threads about the Latitude 5480 that are available in this very section.

Start here maybe: https://www.insanelymac.com/forum/782-opencore-releases/ Careful as you may not manage to get your BCM43224 wireless card working underMonterey... So proceed with the understanding that you're highly likely to require a change of wifi card.

No, as stated before, you need the SMBIOS of an Ivy Bridge model to obtain proper power management on an Ivy Bridge laptop. You may only use the MBP of a more recent model such as Broadwell MBP12,1 at initial installation (not mandatory thanks to -no_compat_check boot arg) and update (mandatory unless you apply tricks to your SMBIOS) for compatibility reasons with Monterey. Given the likely trouble you're likely to experience, I recommend sticking to Big Sur, the last macOS version too fully and natively support HD4000 graphics.

Make sure you reset NVRAM at next reboot after making your config changes.

I've just tried to boot Monterey 12.3.1 on my E7270 after re-instaling a DW1820A and all was Ok with Clover and the usual properties injection (same as you currently have in your OC config). As such, there's no issue using a DW1820A in 12.3.1 but it's your properties injection that must be the issue. I'm not 100% certain of this but I was somehow led to believe not that long ago that OC had changed and required DATA type device property injections only. Don't know if this is true but, if it were, the compatible and pci-aspm-default properties you currently inject for your DW1820A would need to be revised. Try and put your config through the OC checker/validator or convert all properties to DATA type. Try this: compatible 706369313465342c34336130 DATA pci-aspm-default 00000000 DATA

As a test, disable WLAN in BIOS; in case it's the DW1820A that causes the issue.

No KP on your screenshot, looks more like it's hanging. Why don't you post a zipped copy of your EFI folder. I has no issue on updating to 12.3.1 on my own E7270 but then again, I'm using Clover, not OpenCore.