Hervé

https://osxlatitude.com/forums/forum/161-faqs-tutorials/

Is this a distro installation?

Here, promoted in Our Picks list on home page.

Indeed, those devices are clearly disabled in BIOS. Not visible in either IOReg extracts.

It's exactly as we suspected: your wireless card IS NOT located @1D,0; you got that completely wrong. That location is that of your Realtek LAN card! As such, your property injection is useless. Once you temporarily remove your IO80211Family kext and boot with the card fully enabled in BIOS, we'll be able to identify its correct location in IOREg. And it'll probably be one of the locations Jake Lo mentioned in his 1st reply...

Please post a zipped IOReg extract; I too suspect an incorrect IO address for your card. If you're unable to boot with the card enabled or use your Hack long enough to take the IOReg extract, make a backup of /S/L/E/IO80211Family kext somewhere safe and remove the kext from /S/L/E. Then repair permissions and reboot.

I don't think you understood what I suggested, so let me try and clarify... Context: your Clover config renames Embedded Controller ACPI device EC0 to EC (as is required for Catalina) your laptop boots Catalina Ok with BIOS 01.09.01 your laptop hangs whilst booting Catalina with BIOS 01.11.01 My suspicion: BIOS 01.11.01 may use a different name than EC0 for the Embedded Controller Further tests: revert to BIOS 01.09.01 and temporarily disable EC0 to EC renaming reboot and see if laptop hangs at same place as with BIOS 01.11.01 if it does, upgrade to BIOS 01.11.01 and dump your ACPI tables by pressing F4 at Clover main menu check the name of the Embedded Controller device in dumped tables of BIOS 01.11.01 adjust your Clover renaming patch as/if necessary

Your config did not contained the correct compatibility statement: you specified pci14e4,43a0 when our guide (on which daliansky's blog is actually based) clearly stated to use pci14e4,4353 or pci14e4,4331 in order to bypass AirPortBrcmNIC kext. This does not match what you actually posted above... By declaring compatibility with pci14e4,43a0, you actually totally annuled the desired bypass objective and, instead, returned macOS to load AirPortBrcmNIC since that's where 14e4:43a0 is declared alongside DW1820A's own id 14e4:43a3... Try this revised version: config.plist.zip

Did you check your Embedded Controller device in ACPI/DSDT? You apply EC0 to EC renaming but since you updated your BIOS, did you check if the device name remained the same? You could easily verify the behaviour by disabling the EC0 to EC renaming from Clover main screen Options menu with BIOS 01.09.01 and check if it hangs at the same place...

KP on AirPortBrcmNIC -> clearly the device properties injected in Clover are not used. They're either incorrectly applied (eg: wrong PCI target as suggested by Jake Lo) or conflict with AirportBrcmFixup which I clearly recommended NOT to use in our BCM4350 guide.

KP on KBL graphics framebuffer. Try -disablegfxfirmware boot arg during installation/upgrade.

Basically, you're trying to cache VirtualSMC and it appears unsupported/incompatible with your Hack for whatever reasons (kext version, bootloader config, applied patches, etc.). I'd switch to FakeSMC instead (and ACPIBatteryManager of course). And you appear to have the same with WEG. You really need to update your add-on kexts to latest versions before you upgrade to Catalina! You're right to cache your kexts from /L/E.

And don't forget the Embedded Controller patch as detailed in our promoted thread (see Our Picks column). Imperative for Catalina.

@bluedogmike, please post your debug files.

Indeed, your Clover config injected properties to avoid the system freeze/CPU hogging with the DW1820A. Now that you've replaced the DW1820A by a fully natively supported card, you can removed those injected properties from your Clover config.

You could try the hard way and follow the same process as detailed in my Latitude D630 guides for High Sierra, Mojave or Catalina: Obviously, some of the files won't be re-usable (like the DSDT or kexts related to specific hardware like LAN card) but the overall process can be applied. Or there is the easy way where you just follow the recent guides posted at InsanelyMac. A simple forum search on E6410 threads or a basic Google search will lead you there. Of course, High Sierra is the last macOs version that supports your Tesla graphics natively and to the full. Mojave and Catalina require the specific tricks detailed on the guides to support Tesla graphics in OpenGL-only mode (no support for Metal). NB: as per our published rules, no references to distros please; stay away from them, they're full of crap.

Incorrect settings, you should: remove Generate C States and Generate P States (these are for C2D, C2Q, 1st gen Core CPUs) enable PlugInType and that's it, nothing else. No need to enable NoOemTableId or NoDynamicExtract afaik.

Well, it would seem that there is something missing or incorrect with regards to your Sapphire RX580 graphics card config then, not the HD4600 iGPU. I'm afraid I won't be of much help on that front since my hands-on experience with AMD cards is most limited. I only ever kept the old ATI Radeon HD X1300 of my old C2D Vostro 200 desktop Hackintosh for a short time back in 2012/2013 given that it was last supported in Snow Leopard. I then replaced the card by an nVidia model for subsequent OS X/macOS versions.

We recently posted an article about Realktek PCIe card readers (click on Home to get there) and there is also a dedicated thread about them in the Card Readers section. Please refer to that. Of course, without an SD card, you won't be able to do/test much thereafter... NB: quoting messages as a reply facility is not appropriate nor desired. Please use the Reply box available at the bottom of each thread. Thank you.

Did you setup your config correctly for HD4600 iGPU? Because the hanging at gIOScreenLockState messages usually means that graphics are not initialising and system keeps retrying.

Check your BIOS settings against the posted recommended ones and adjust as/if necessary.

Up until this time last year, I had a Latitude E6440, a Haswell laptop fitted with HD4600 iGPU and AMD dGPU. The AMD dGPU was not supported and therefore disabled via DSDT/SSDT patching. There never was anything to be done on the iGPU front regarding performance per sé. Booting off the mSATA SSD was just about the same as with any other of my Hacks: ~20s from start to finish. I'm a little surprised to read that, on your Haswell desktop, enabling the HD4600 iGPU increases your boot time by almost 20s. I can't say ever heard of such an impact before. Did you try and analyse what happens at boot time through verbose mode when iGPU is on? Other than my Sandy Bridge Latitude E6220 and it's crappy HD3000, I find no particular performance issue on my other laptops running iGPU: whether it'd be my Ivy Bridge Latitude E6230 and its HD4000 iGPU or my Kaby Lake R Latitude 7490 and its UHD620 iGPU. Same applied to the Broadwell Latitude E7250 + HD5500 iGPU I had for a brief spell.

Hi @arsradu, yes we're aware of this recent issue and we're trying to solve this.

Please consult the FAQ section. I'm sure you can do it without assistance.

We have a dedicated thread on the matter in our FAQ section.