Jump to content

Slow Shutdown


JDubU

Recommended Posts

Sleep: Could very well be.. wouldent be the first time apple have f*cked up :-)

AppleACPIPlatform.kext: Yes, you should ALLWAYS do a new build after update anyway - and yes.. there is a that risk.

 

However, i just did an update where we copy AppleACPIPlatform.kext to /e/e like we did before also.. seeing that its the same kext it should work without cache issues.

 

Mind updating edp and testing doing a new build ?

 

 

Updated EDP 4r12 and ran it to do a rebuild plus fixes. AppleACPIPlatform.kext is now in E/E as well as S/L/E.

System seems to be working the same as it did before this latest update -- no cache issues.

Link to comment
Share on other sites

  • Replies 54
  • Created
  • Last Reply

Top Posters In This Topic

Sleep: Could very well be.. wouldent be the first time apple have f*cked up :-)

AppleACPIPlatform.kext: Yes, you should ALLWAYS do a new build after update anyway - and yes.. there is a that risk.

 

However, i just did an update where we copy AppleACPIPlatform.kext to /e/e like we did before also.. seeing that its the same kext it should work without cache issues.

 

Mind updating edp and testing doing a new build ?

 

Whoops, spoke too soon.

Just did several restarts. One had a kernel panic on boot. Next came up but no cursor. Third came up normally.

 

Update:

Did five more restarts. All came up normally except the BIOS is loading slowly implying that a CMOS reset occurred (I think touching S/L/E can cause this).

Link to comment
Share on other sites

yep.. do that and report back..

 

I tried the 3 combinations of AppleACPIPlatform.kext in E/E only, S/L/E only, and in both.

Kept getting random kernel panics in all of them. Finally, with the kext in E/E only, I did a "Repair Permissions" on the whole boot drive using Disk Utility (I had only been running MyFix after each change) and it fixed a whole list of permissions in files that were not in E/E or S/L/E. Since then, the system has been stable.

 

I am trying to understand what is happening here. It looks like MyHack copies the kexts from the Extra folder and places them as plugins to MyHack.kext in S/L/E. It also bumps all the version numbers of these plugins up to '1111', presumably to force the OS to use these over any other ones of the same name in S/L/E since they will always appear to be the latest versions. Is that how it works or does the OS try to merge the different version together somehow? If the OS just used the ones in MyHack.kext (based on higher version numbers), why would I have gotten linking errors in the kernelcache operation that disappeared when I took out the original kext of the same name in S/L/E?

 

Is there a reason why EDP shouldn't (or can't) put AppleACPIPlatform.kext in E/E and also delete (archive) the original Apple one that was in S/L/E since the one in E/E should always take precedence anyway?

Link to comment
Share on other sites

  • Administrators

Hi,

 

You got the myfix part correctly :-)

 

EDP copies all its kexts to /e/e, if AppleACPIfix is enabled in modeldb.inc.php for that specific model, it will remove the existing AppleACPIplatform.kext from sle, copy in a new one and copy it to ee also.

 

sounds more like your issues was permissions to begin with..

Link to comment
Share on other sites

  • Administrators

For info, here's what I have on my D630 nVidia when reading file info:

- in /S/L/E: AppleACPIPlatform.kext, version 1.6, size 569 757 bytes

- in /E/E: AppleACPIPlatform.kext, version 1.3.5, size 2 280 797 bytes

 

The loaded kext is indeed loaded as version 1111 from /SL/E myHack kext plugins folder (size 1 806 582bytes).

 

Does this mean that the kexts in /E/E and /S/L/E could both be removed?

Link to comment
Share on other sites


×
×
  • Create New...