Jump to content

tonyx86

Just Joined
  • Content Count

    95
  • Joined

  • Last visited

About tonyx86

  • Rank
    InsanelyMac Protégé

Recent Profile Visitors

1,644 profile views
  1. tonyx86

    Mojave on Dell Latitude E6410

    There are new versions of the following kexts that I have not yet tested. Has anyone tested these to confirm that they work with the Latitude E6410? AirportBrcmFixup (v2.0.3 as of this post: https://github.com/acidanthera/AirportBrcmFixup/releases) Lilu.kext (v1.3.8 as of this post: https://github.com/acidanthera/Lilu/releases)
  2. tonyx86

    Mojave on Dell Latitude E6410

    @vbmota After a quick scan of your debug files, here's what I see: Your CLOVER/kexts folder has kexts in CLOVER/kexts and CLOVER/kexts/Other. You only want kexts in CLOVER/kexts/Other Too many kexts in CLOVER/kext/other. Just follow the example I attached to post #1 and install other kexts in /Library/Extensions as I have indicated in my instructions in Post #1. This is my preference (others have differing opinions). It appears that you may have selected the SIP Manager option in DosDude's Mojave patcher. Properly remove SIP Manager.kext from /Library/Extensions It appears that you have have NullCPUPowerManagement.kext installed. Why? It appears that you have both USBInjectAll.kext (Rehabman) and LegacyUSBInjector.kext (DosDude) installed Why do you have CLOVER boot option 'nvda_drv=1'? I'm going to stop there. Please re-read Post #1 and follow it exactly for your Mojave installation. You cannot start with a previous installation of Mojave that was not working and then start with the instructions in this thread. This thread assumes that you are starting your Mojave installation from scratch. Good luck!
  3. tonyx86

    Mojave on Dell Latitude E6410

    @vbmota It may take me a while to post an updated config.plist. Did you have any specific questions about something that's not working for you? Did you get sleep working?
  4. tonyx86

    Mojave on Dell Latitude E6410

    @Malu I've tinkered with CLOVER just enough to be dangerous, but still prefer manually patching my DSDT. Currently, my E6410 config.plist renames EHCx to EH0x, Fixes USB, Injects NVidia, enables TRIM, adds the -no_compat_check boot flag and configures SMBIOS. All other patches are manually applied to my DSDT using Rehabman's version 1.31 of MacIsl. I wouldn't be the right person to start with the original DSDT and fix everything with a CLOVER config.plist, but I'd love to see it if anyone has it. Also, now that your system is stable, could you post your Geekbench results? I'm curious to see the performance difference between the I7-820QM and the I7-620M. My I7-620m Geekbench score is attached to the first post in this thread.
  5. tonyx86

    Mojave on Dell Latitude E6410

    @Malu When/if you decide to revisit Mojave issues specific to the i7-820qm, please start another thread that is specific to your issue and post the link for it here. That way, we're not clobbering this thread with a topic that now appears to be unrelated. Thanks! Also, the CPU and heatpipe don't make solid contact without a shim or thermal pad. I tried, but my CPU temps started to climb which was because there's a fine gap between the heatpipe and CPU. The gap was initially bridged by AS5, but as the AS5 settled, the thermal contact began to fail. I'm not sure how much tolerances vary from one E6410 to another, but for my laptop, I have to use a thermal pad (low thermal conductivity) or a copper shim (high thermal conductivity) in order to ensure thermal conductivity from the CPU die to the heatpipe.
  6. tonyx86

    Mojave on Dell Latitude E6410

    @Malu "Suddenly turns off" could be thermal (which wouldn't surprise me). You mentioned that you have modified the cooling to compensate for the higher power dissipation. Have you installed copper shims or are you still relying on the original thermal pads for the CPU and GPU? I'm not advising you to install the shims (I don't want to suggest anything that you're not comfortable with), but the E6410 heatpipe (with the original thermal pads) is barely sufficient to conduct the heat from the 3100m and the recommended 35W CPU (which I'm sure is by design). I have installed .3mm copper shims on both my CPU and GPU. For the CPU, I have no thermal pad - just the lapped copper shim with AS5 on both sides of the shim which is seated between the heatpipe and the CPU die. For the GPU, I installed the copper shim on the GPU die (with AS5) and have a fujipoly thermal pad on the heatpipe. The reasoning for the CPU shim is self-explanatory. The reason for the GPU shim is that I have changed the heatpipe spacing by inserting a CPU shim, so I need to add the same shim to the GPU. In addition, the copper shim I used is larger than the GPU die (and the same dimension as the thermal pad), so it acts as a heatspreader so the thermal pad has more surface area to work with. My CPU and GPU temps reach a max of 20C less under load than they did without the copper shims. That's significantly better thermal conductivity. EDIT: One other observation that might help you - when I installed the copper shims, I noticed that my northbridge chip did not have a thermal pad. There was NOTHING conducting heat away from the northbridge chip since it made no contact with the heatpipe assembly. For the 35W 2-core CPUs, that may be ok. For your 45W 4-core CPU, maybe that's not ok? I don't know. In any event, I installed a 2mm thermal pad on my northbridge chip so the heatpipe assembly conducts heat from it as well. At a minimum, I would recommend that you add the 2mm thermal pad to your northbridge if you don't have it.
  7. tonyx86

    Mojave on Dell Latitude E6410

    @Malu All DSDTs that I've seen have code branches that execute differently depending on the operating system. I'm flying blind without seeing your DSDT (you said it's different with your CPU), so search your DSDT for "Windows" and hopefully you'll see what I mean. There are two variables in the Latitude E6410 DSDT that assume values that depend on the Operating System: OSYS and ACOS. Method _OSI() is used to identify the currently running OS. For example, if _OSI("Linux") returns TRUE, your system is currently running Linux. Since the original Latitude E6410 DSDT was never coded to recognize MacOS ( which is detected by checking _OSI("Darwin") ), you may want to add the "Darwin" condition to your DSDT to see if this resolves any issues. If you look closely at the DSDT that I attached a couple of posts ago, you'll notice that I have hard-coded OSYS and ACOS to specific values. The hard-coded values I chose are those that would have been assigned for the condition _OSI("Linux") = TRUE (so I am telling my DSDT to pretend that Linux is running when I am running macOS). Read Post #1 of this thread and you will see that I mention this in my "known issues" section. I owe credit for this "OS Equivalency" to Rehabman from whom I first learned about this in one of his many posts. I have not "completely rewritten DSDT for macOS." I started making changes after I found the Dell bug in Method (GNOT) and realized that quality assurance for the Latitude DSDT must be bad if this bug remains in the DSDT at revision A17. I noticed this same bug in other Latitude DSDTs, so someone's not paying attention. There are always bugs in code, but the GNOT bug is so obvious, that I stopped trusting any of the Latitude DSDT code and did a thorough code review. I was hoping that the sleep issue was simply a DSDT bug, but so far, none of my changes have fixed sleep. I would suggest that you try creating two conditions for _OSI("Darwin") in your DSDT (one for OSYS and one for ACOS) such that you make them equivalent to "Linux" to see if this helps. There are multiple ways to do this. The brute-force way is to replace instances of _OSI("Linux") with "LOr(_OSI("Darwin"), _OSI("Linux"))" so that the "Linux" code branch executes if the OS is Linux or Darwin. If that doesn't help, experiment with Windows 7 by replacing instances of _OSI("Windows 2009") with LOr(_OSI("Darwin"),_OSI("Windows 2009")). Note that "LOr" is logical OR of two conditions, so it returns TRUE if either condition is TRUE. Another way to achieve this is to create an SSDT that overrides _OSI() so that you don't have to modify the DSDT. My hard-coded method (directly assigning values to OSYS and ACOS) is one I chose because my DSDT only needs to support macOS, so I don't care about the other conditions. EDIT: If you choose to implement my hard-coded method (assigning values to ACOS and OSYS), note that you can't simply set OSYS and ACOS. The DSDT also make calls to OSID(). You'll notice in that last DSDT that I posted that I have replaced calls to OSID() with ACOS. EDIT 2: You'll notice 2 different coding styles in the Latitude DSDT that result in different ways to handle the _OSI() condition checks. In Method (OSID), the OS strings (e.g. "Linux") are assigned to variables (e.g. "LINX") and these variables are referenced in the _OSI() condition statements. In Method (IINI), there are no variables used for the OS strings, so the _OSI() condition statements reference the OS string. I don't know why this inconsistency is present, but you'll need to edit Method IINI and Method OSID differently. Most (if not all) DSDT patches that you find for the Latitude E6410 will ignore the ACOS and OSYS assignment (the DSDT defaults to a value if the OS is unrecognized) or they completely miss the assignment of ACOS.
  8. tonyx86

    Mojave on Dell Latitude E6410

    @Malu - could you post your DSDT? What OS are you emulating in your DSDT (Linux, Win7...)? My E6410 seems to work best when emulating Linux. Attached is my current DSDT.aml. I haven't attached it to the first post of this thread, because it's still a work in progress. Differences between this attached DSDT and the one in Post #1 include: Removed PNLF (I'm content with adjusting brightness with the keys and the DSDT does not need to be patched for this) Added Mutex Release (WMIX) at end of Method (WSVP) and Method (WVCU) Fixed Dell bug in Method (GNOT) (replaced LOr with LAnd) Removed duduclx "Intel Ready" patch for Intel HD Graphics (not necessary with NVidia 3100m) Hard-coded ACOS and OSYS variables to emulate Linux (eliminated method OSID) Changed IFs to ELSEIFs to eliminate unnecessary code execution in ECW and ECR methods Added EC cases for all EC registers in Method ECW Partially restored code execution conditional on OSYS in Device (HPET)::Method (_STA) Other minor changes My laptop currently runs perfectly with the exception of non-working sleep. DSDT.zip
  9. tonyx86

    Mojave on Dell Latitude E6410

    I've had good experience with USBInjectAll and Mojave, but my systems are all old, so I can't speak to systems newer than 1st Gen / Series 5. In my experience (again, older systems), Series 5 Chipset / Lynnfield, Clarkedale, Arrandale, Nehalem does much better without Generate C / Generate P states as long as the correct MacModel is selected (MacBookPro 6,2 in this case) and the correct IONameMatch is injected in LPCB._DSM ("3b09" in this case). Adding CLOVER CPU options (like Generate C / Generate P States) limits the peak multiplier and reduces the number of P-States. I have similar experience with a Series 5 Chipset / Xeon X3450 (Using MacModel MacPro5,1 with IOName "3b09").
  10. tonyx86

    Mojave on Dell Latitude E6410

    If you can post a quick how-to on ssdtPRGen with the specific command line that you used, I have another system where I could try it and report back. I don't have experience with patching graphics drivers - sorry I won't be any help there. Sounds like you're really pushing the envelope with the E6410. My only remaining issue at this point is sleep. I tinker with it and continue to learn. Please continue to share your progress and any lessons you've learned. Thanks!
  11. tonyx86

    Mojave on Dell Latitude E6410

    @Malu The IOName patch is in the DSDT that I attached to Post #1 in this thread. Search for it and apply the same to your DSDT. My latest custom SSDT-UIAC (for USBInjectAll.kext) is attached to one of my posts earlier in this thread. You'll find it as either the first post on Page 3 of this thread or about 14 posts ago. I7-820QM eh? Very cool. Do you also run with 16GB RAM? I read about it and decided against it when I saw that no one had speedstep working. You could try to create an SSDT for your CPU using ssdtPRGen. I'm not going to be much help with that, because I couldn't get it to work for custom Gen 1 CPUs. There is an L3426 (Lynnfield, Xeon) CPU in the ssdtPRGen examples that should be a close match and a good starting point for you. That's about all I can offer for your CPU.
  12. tonyx86

    Mojave on Dell Latitude E6410

    I noticed items in your config.plist that look different to me, but I didn't make a thorough comparison. What specifically are the differences between your config.plist and the one I posted? Also, is your BIOS A17? I would recommend removing all but the 'other' folder in the CLOVER/kext folder. Looking at just the 'other' folder, how did you decide on which kexts to put in your CLOVER/kext/other folder (some that I don't recognize)?
  13. @rongu I don't work on the ThinkPad T61 very often (only updated to Mojave to see if it worked and it works well for a 2008 laptop). If I remember to get the DSDT the next time I'm on that system, I'll post here. In all honesty, the DSDT does not add any value to this thread. Everything that I required to implement onejay09's brightness fix for the Thinkpad T61 is in my previous post. I hope that helps. I think the biggest revelation for me was that the GFX0._DSM doesn't require much if you use CLOVER's "Inject NVidia" option. It significantly simplifies this brightness fix on the Thinkpad T61 and maybe other laptops as well (likely with different values for pwm-info and NVCAP). .
  14. tonyx86

    Mojave on Dell Latitude E6410

    @hazem3ly At first glance, your DSDT looks like it's missing patches. Did you first follow duduclx's link at the beginning of Post #1 in this thread and then follow my recommendations in Post #1? I looked for NVidia patches and PNLF as my first two searches and didn't find either. I would recommend that you read Post #1 of this thread very carefully and then check back here with what I suspect will be a working system.
  15. tonyx86

    Mojave on Dell Latitude E6410

    Just upgraded my Dell Latitude E6410 to Mojave 10.14.6 (from 10.14.5). Everything works perfectly. Upgrade process was simple: Backup! Apply 10.14.6 update from AppStore Before rebooting into 10.14.6, boot from DosDude-patched Mojave Installer USB and apply Legacy Graphics Patch
×