Hervé

RTC-related CMOS reset maybe. There is an OC NVRAM parameter that was developed to that effect after Catalina 10.15.4 was released. You may want to give it a try... Or check any RTC-related parameter you may have in your current config.

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- /!\ Big Sur, Monterey and Ventura /!\ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Big Sur dropped support for Broadcom BCM4331 and BCM43324 which results in the disappearance of AirPortBrcm4360 kext! This basically extended death to DW1820A when using the solution detailed above. A 1st workaround is to call on a patched version of Catalina's IO80211Family kext where only AirPortBrcm4360 has been retained as PlugIn. See here for details. With OpenCore, the patched kext can be placed in the OC kexts folder and added to the list of add-on kexts in the OC config. Add minimum kernel set to 20 if the config is also used for previous macOS version(s). IO80211Catalina.kext.zip A 2nd workaround is to call on Acidanthera's AirportBrcmFixup kext (its injectors are not required/used) + injecting compatibility with pci14e4,43ba (BCM43602) or pci14e4,43a0 (BCM4360). This was tested and verified under OpenCore by enabling only the parent kext of the fixup kext v2.1.2 and leaving both of its injector PlugIns disabled. The adjusted IOProbeScore value of the Fixup kext seems to be the key here. Others (it was my case) will find that, in Big Sur and later, injecting compatibility with pci14e4,43a0 (Broadcom BCM4360) + disabling ASPM does suffice.

Be happy: no dGPU listed so it'd be fair to say it's properly disabled.

In IORegistryExplorer, do File->SaveAs and save the IOREg output to a file. Zip it and post it; we'll look at it. In a laptop, the dGPU is normally located at IO address 0x00010000 on the PCIe bus, so you'd have a device looking like <XXXX@1> in the tree (eg: GFX0@1).

Check dGPU status in IOReg with IORegistryExplorer app; maybe it's still enabled, in which case, it'll eat up battery.

In theory, yes. In my own experience, the bootpack remains the same for both macOS versions. Just make sure to use the latest versions of the add-on kexts (eg: Lilu, WEG, etc.).

Re: brightness control, you should have it as long as you inject the SSDT-PNLF ACPI table. By default, the expected keyboard shortcuts won't work (but other key combinations will) until you add the SSDT-BRT6 ACPI table that was developed by Jake Lo as an alternative to DSDT patching (as described in my E6230 or 7490 guide for instance). You can look it up through a forum Search. Re: wireless, it all depends on the card fitted to your laptop. We've no crystall ball... Consult our R&D->Wireless section and its inventories for guidance.

Pentium G4560 is fitted with unsupported HD 610 iGPU; as such, you can forget about it and you should remove your properties injection trying to get the iGPU supported as HD 630. It's useless. It looks like you're mixing Clover drivers with OC drivers (eg: SMCHelper, used for FakeSMC). Why? This is most likely incorrect and I can only suggest you refrain from doing this. You're injecting NullCPUPowerManagement; not sure you need this. No Booter quirks at all, that's definitely wrong. I suggest you start at the beginning and read Dortania's OpenCore documentation! https://dortania.github.io/OpenCore-Install-Guide/

No. Yes.

Quite a challenge to understand what you're trying to say or provide a suitable answer with such vagueness but I can tell you this: Location Services utility needs wireless to be working because, in the absence of a built-in GPS in a Mac, the IP@ of the wireless interface is used to locate the host. It does not use the IP@ assigned to the LAN interface. Afaik, there is no workaround.

Split to own thread to avoid further polluting of @tanya's Mouse/TouchPad topic.

You may also revert SMBIOS to MBP9,2 or MBP10,2 and use -no_compat_check boot arg.

As announced a few days ago, we've now upgraded our site and deployed a new Theme. We hope you'll all like it. Not only does it give a nice refresh to the site, it also fixes a few bugs we'd been suffering from for some months. Site should also run a little quicker. Many thanks to @Leon, @Syonagar and @Bronxteck for a job well done! OSXL Crew

Specs and zipped EFI folder please. Laptop going to sleep at login screen is typical result of running with a CPU PM SSDT meant for a different CPU that fitted to the hosting laptop.

If you used a bootpack labelled "Optiplex9020_A20", it was meant for a model running BIOS A20 or above. Start by updating your BIOS to the latest version. If you want further assistance, you'll have to post your system's specs and a zipped copy of the pack you used or a link to it since it existing stuff.

System going to sleep at login is typical when CPU power management is not in place as is the case here: no CPU-specific generated SSDT, incorrect kernel quirks, incorrect SMBIOS. So: generate your CPU-specific power management SSDT using good old Pike R Alpha's generator script remove XCPM and Lapic kernel quirks, they don't apply to an Ivy Bridge platform change SMBIOS from Haswell MBP11,2 to Ivy Bridge MBP9,2 or MBP10,2 remove vsmcgen and -lilubeta boot arg/flag, I don't believe you need the former and latter is totally irrelevant now (Lilu fully supports Big Sur) And post your system's specs of course so we don't remain in the dark...

Yes, you can enable the debugging/debug files and/or look into macOS log files; but if your system is fully working, I would not worry about ACPI warnings or errors and just ignore them.

Dec. 2010-Dec. 2020 It's hard to believe that it's been 10 years already! What a road since the early days of Snow Leopard on the Latitude D430! To celebrate this, we've undertaken a small forum clean-up, implemented some optimisation on the hosting server side, upgraded the community board and splashed out on a new forum Theme. We hope you'll all enjoy it and thank you for your loyalty to OSXLatitude. OSXL Crew View full article

Indeed, all looking good. The only thing I notice is that your display is detected as an external screen rather than a built-in LCD as you can probably see in "About this Mac". But it's probably without consequence whatsoever. Replace that slow 5400rpm mechanical HDD by an SSD and this laptop should be a joy to use.

What about card reader or Webcam (USB internal devices)? According to your previous IOReg extract, it looks like they're fully working too, right? Maybe you can post a new zipped IOReg output + a zipped SysInfo output.

Please note that the iGPU properties injection in this OC config are arguable. I guess they derived from the initial settings used for HiRes Capri FB 0x01660004 that only natively supports 1 x LVDS display output (for built-in LCD) and for which additional display outputs, taken from the LoRes layout, were injected. Given their origin, these properties don't really do any harm to FB 0x01660003 but they're not required at all. One noticeable item is the absence of property injection for the Capri FB memory size (to reduce it from 16MB to 8MB). Only 2 x properties should be used for patching the Capri LoRes framebuffer: 1 x for FB memory size and 1 x for HDMI audio. The properties injection should therefore look like: AAPL,ig-platform-id 03006601 DATA framebuffer-patch-enable 1 NUMBER framebuffer-fbmem 00008000 DATA framebuffer-con1-enable 1 NUMBER framebuffer-con1-type 00080000 DATA A few other things look irrelevant, like the -lilubeta boot arg; but these things are probably inherited from a time where Big Sur was beta and not fully supported by our well-known add-on kexts. Things can however be cleaned up now.

More likely the card than the adapter... Anyway, you clearly have defective hardware, so nothing to do on the Hackintosh side so to speak.

You can seek inspiration in existing Latitude 7490/7400 guides and threads. But as usual, post your hardware specs (CPU, chipset, LAN, wireless, audio, USB, card reader, etc.); we actually recommend to add those in signature... Good luck!

For your Atheros AR8121/AR8113/AR8114 Fast or Gigabit Ethernet LAN card (1969:1026), try this kext: AttansicL1eEthernet.kext.zip