JDubU

Bronxteck:

 

I do have a BT module that, as a test, disabled in the BIOS and confirmed that it was not seen by OSX.

It did not change the wake-after-sleep behavior of the Ethernet adapter.

 

I'm not complaining about this at all.  I just could not figure out why some people with exactly the same hardware, BIOS settings, OS, etc.  were not seeing the same behavior. 

 

I assume that it is an issue with the hacked BCM5722D.kext Ethernet driver and wanted to pin down a way to reproduce the behavior.

After a series of test setups, the problem only occurs when the wired Ethernet adapter of the D630 is connected to a Gigabit switch.  When connected to a 100Mb switch, the wired Ethernet adapter reconnects reliably after waking from sleep.  I tested this with three different Gigabit switches and three different 100Mb switches.

 

Can anyone confirm these test results?

D630 NVidia

Mountain Lion 10.8.3

 

I have always had the problem with wired Ethernet consistently being disconnected after waking up from sleep.  It would only come back after reboot.  I know that others have also reported this.

 

Windows 7 installed on the same D630 (by replacing the boot drive) never has this problem.

 

Today I discovered that if, instead of connecting to my local network (D630 --> Ethernet switch --> Zyxel router --> DSL modem),  I connect the D630 directly to the DSL modem, the problem goes away.  The wired Ethernet connectivity consistently returns on wake up from sleep!

 

I will have to do some more experimentation to see if can isolate this further...

I've done it on my D630.  Pretty amazing that it really does work.

 

I used the aluminum foil ball standoff method to keep the bottom side components from touching the pan and possibly getting hotter than everything else.

I also used a (portable) convection toaster oven preheated to 400 degrees and then baked for exactly 10 minutes.  The convection oven provides more even heating and let me do the whole thing in the garage so I didn't stink up the house with potentially harmful out gassing.

 

FYI, the solder bonds that fail are not the ones between the Nvidia GPU package and the circuit board.  They are actually the ones between the silicon chip's pads and their matching (flip chip) pads inside the package itself.  

Anyone tried connecting a projector to D630's video out? Is it working? Thanks

 

I don't have a projector but a monitor on the video out (VGA) connector works on my D630 Nvidia.

That refers to installing Mountain Lion, not Snow Leopard...

 

 

Oops!

My mistake, never mind.

ohh, sorry i forget, thx Herve.

 

...but now after create extra with myhack and Dell_Latitude_D630-nvidia-sl,

i became boot-menue from myhack and i start with option -v

but after 1-2 minutes my notebook is stopping and i must push the power-on button

to putt in off modus.

 

here are the screen shots .. pls help me with another idea what can i do

 

THX & greets Alex

 

 

These step by step instructions worked smoothly for me:

https://osxlatitude.com/index.php?/topic/1643-dell-d630-mountain-lion-install-guide-new/

 

You won't need to do the keyboard and trackpad kext replacement (step 5 in section "Getting it to work:") since the latest version of EDP already includes the proper kexts for them).

I wasn't really concerned about Bluetooth not showing up in the Network Pref Pane. It was just something that I noticed had changed after modifying the Chameleon parameters and curious as to why those parameters would cause the change.

 

What I would really like to figure out is why your D630 wakes up from sleep with wired Ethernet still working while mine consistently doesn't, even though we have identical Chameleon, BIOS, and kext configuations.

Thanks Hervé!

 

There were several differences.

 

org.hameleon.boot.plist:

In my "CPU" section no items at all were checked.

My "USB bus fix" was checked.

 

SMBIOS:

My model was set to MacBook3,1 instead of MacBookPro3,1.

 

I changed the above features to match yours and I also updated to the latest svn release of Chamelion (r2069).

After restarting:

 

"Network" system preferences pane shows WiFi(connected), Ethernet(connected) and Firewire(not connected). Before the changes, it also listed Bluetooth (not connected). The Bluetooth Icon appears in the menu bar but now does not show in system preferences.

 

Closing the lid to put the computer to sleep and then opening it again to wake it up, Network pane now shows WiFi(connected), Ethernet(not connected), Firewire(not connected).

 

So it did not fix the Ethernet wakeup problem.

I wonder if there are Ethernet hardware differences between our two D630's?

Very interesting!

 

I thought that this was a known problem with the BCM5722d kext. I know that Seb reported that his did not work after waking from sleep and a Google search has others (on other forums) reporting it as well (for example: http://www.osx86.net/downloads.php?do=file&id=3074&page=2).

 

My EDP install and BIOS settings are the same as yours (I used your setting based on our discussion in: https://osxlatitude.com/index.php?/topic/1827-slow-shutdown/page__st__20).

 

Any ideas on why yours does not have the problem? Did you do something special to make it work?

Does AppleBCM5751Ethernet.kext still work after waking from sleep?

BCM5722d.kext causes the wired network adapter to stay asleep -- a reboot being required to bring it back to life.

My kernel panics were definitely not due to file permission problems. I fixed all file permissions using both MyFix (Full) and Disk Utility multiple times but was still getting random KP's no matter where AppleACPIPlatform.kext was located.

I think that I've narrowed the problem down to either VoodooHDA.kext or, possibly, kernelcache corruption.

 

After deleting the entire com.apple.kext.caches folder from S/L/Caches, I did a custom EDP 4r12 rebuild using AppleHDA #2 instead of VoodooHDA #3, leaving the AppleACPIPlatform.kext that EDP installed in both E/E and S/L/E. The system has since been totally stable with normal shutdown/restart times.

 

I wanted to try to install AppleHDA again because it doesn't mess up input/output volume levels after every restart like VoodooHDA does. Previously, I could not use AppleHDA because it had linking errors that prevented kernel caching.

 

Thinking that the KP's and cache linking problems may have been caused by a corrupted kernelcache, I had previously tried to delete only the 'kernelcache' file in S/L/Caches/com.apple.kext.caches/Startup, not knowing what the other files in S/L/Caches/com.apple.kext.caches did. After deleting the entire com.apple.kext.caches folder, the kernelcache now rebuilds quickly and reliably (no linking errors with AppleHDA or AppleACPIPlatform). I don't know if those other files in S/L/Caches/com.apple.kext.caches where contributing to the caching problem from the very beginning.

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

 

Could be.

As verification, I will try putting it back into both folders, fix all permissions and see what happens.

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?

Just got another kernel panic while it was just sitting there at the desktop.

 

I think I will temporarily remove AppleACPIPlatform.kext from E/E, rebuild the cache and see what happens to the stability.

.. and the 4th. reboot ?

 

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).

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).

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.

Hi,

 

Thanx for testing - good that we got one thing resolved

 

Audio = VoodooHDA is buggy.. i think you can get a seperate pref. pane for voodooHDA

Sleep = Sleep have allways been buggy as hell :-/

 

 

Good to know about the separate voodooHDA preference pane.

 

I do know that auto sleep used to work in my initial install of 10.8.0 and I think it still worked with 10.8.1. I did a Google search on this and there are some people reporting that it broke when they updated to 10.8.2 on their Apple Macbook Pro. So it may be an Apple OS X problem. Have you heard if others are having the same problem with auto sleep in 10.8.2?

 

If EDP is now placing AppleACPIPlatform.kext directly into S/L/E, does that mean that an EDP rebuild may be required after any future OS update that might replace that patched kext with the official Apple version? I am just wondering if there is a chance that a future OS update could cause the computer to be unbootable?

Hey mate,

 

I'v added a fix to EDP so that it will replace AppleACPIPlatform.kext in sle instead of trusting on version bumping, that should resolve your problem permanent.. would you mind updating your EDP (using option 5 in edptool) and do a new build to see if it works ?

 

 

Updated EDP to 4r11 and ran it with the same custom kext selection (same as default but with VoodooHDA #3 instead of AppleHDA #1). Also ran EDP fixes (hibernation fix, touch S/L/E, and sound delay) Lost my chamelion.boot.plist customizations so I had to redo those. It did not do a backup to the Extra folder -- just replaced its contents. System seems to be working the same as before this rebuild.

 

There are a couple of things that I have noticed (so far):

 

After every system startup, the microphone and speaker volume levels don't match the slider settings in system preferences. Mic starts at full and speaker is low no matter what the volume sliders are set at. Making even the smallest change to each slider gets them to match until the next system boot. Must be a VoodooHDA problem.

 

Auto sleep no longer works at all. Sleep works perfectly via command or lid closing. I tried setting "Computer sleep" to 2 minutes and "Display sleep" to 1 minute in the Energy Saver system preferences. The display sleeps on schedule but the computer never goes to sleep. I don't think that this began with our recent EDP kext changes since my previous backup disk image has the same behaviour. It might be a 10.8.x update issue that I only just noticed.

Removed AppleACPIPlatform.kext from /s/l/e and ran MyFix.

 

Solved the kernelcache rebuild problem. Kernelcache is built successfully with no errors. Shutdown time is now back to normal (~20 seconds). Had one initial instance of sleep command freezing the OS but, after restart, seems to be working now.

 

Thank you Leon!!!!!!! Brilliant!!

 

Do you think that there might be a way to go back to AppleHDA if I end up have trouble with voodooHDA?

Can you navigate to /s/l/e/myhack.kext/contents/plugins and copy/paste what you have in there..

 

Also, remove your AppleACPIPlatform.kext in /s/l/e

 

Here they are:

 

/System/Library/Extensions/myHack.kext/Contents/PlugIns/AppleACPIButtons.kext

/System/Library/Extensions/myHack.kext/Contents/PlugIns/AppleACPIEC.kext

/System/Library/Extensions/myHack.kext/Contents/PlugIns/AppleACPIPlatform.kext

/System/Library/Extensions/myHack.kext/Contents/PlugIns/AppleACPIPS2Nub.kext

/System/Library/Extensions/myHack.kext/Contents/PlugIns/AppleHDADisabler.kext

/System/Library/Extensions/myHack.kext/Contents/PlugIns/AppleIntelPIIXATA.kext

/System/Library/Extensions/myHack.kext/Contents/PlugIns/ApplePS2Controller.kext

/System/Library/Extensions/myHack.kext/Contents/PlugIns/ApplePS2Keyboard.kext

/System/Library/Extensions/myHack.kext/Contents/PlugIns/ApplePS2Mouse.kext

/System/Library/Extensions/myHack.kext/Contents/PlugIns/BCM5722D.kext

/System/Library/Extensions/myHack.kext/Contents/PlugIns/FakeSMC.kext

/System/Library/Extensions/myHack.kext/Contents/PlugIns/IntelCPUMonitor.kext

/System/Library/Extensions/myHack.kext/Contents/PlugIns/IOATABlockStorage.kext

/System/Library/Extensions/myHack.kext/Contents/PlugIns/IOATAFamily.kext

/System/Library/Extensions/myHack.kext/Contents/PlugIns/IOATAPIProtocolTransport.kext

/System/Library/Extensions/myHack.kext/Contents/PlugIns/lspcidrv.kext

/System/Library/Extensions/myHack.kext/Contents/PlugIns/NullCPUPowerManagement.kext

/System/Library/Extensions/myHack.kext/Contents/PlugIns/Patched_10.7_AppleRTC.kext

/System/Library/Extensions/myHack.kext/Contents/PlugIns/SleepEnabler.kext

/System/Library/Extensions/myHack.kext/Contents/PlugIns/VoodooBattery.kext

/System/Library/Extensions/myHack.kext/Contents/PlugIns/VoodooHDA2-7-4.kext

/System/Library/Extensions/myHack.kext/Contents/PlugIns/VoodooPS2Trackpad.kext

/System/Library/Extensions/myHack.kext/Contents/PlugIns/VoodooPState.kext

/System/Library/Extensions/myHack.kext/Contents/PlugIns/VoodooTSCSync.kext

 

 

 

Running MyFix after removing AppleACPIPlatform.kext in /s/l/e...

When you boot into chameleon, then type:

 

-x -v -f -s and hint enter..

 

I asked the question wrong. I was in single user console mode but could not get EDP to run using open or exec commands. I ended up logging out and ran EDP in single user mode in the GUI. Finally got voodooHDA installed (after one, recoverable kernel panic in MyHack).

 

I still have the slow shutdown problem due to failed kernel cache rebuild but there has been some progress due to voodooHDA vs AppleHDA. Now the cache rebuild failure is only due to the AppleACPIPlatform kext. There are no linking errors caused by voodooHDA.

 

Here is the new log during shutdown:

 

10/5/12 1:57:32.991 PM com.apple.usbmuxd[54]: stopping.

10/5/12 1:57:33.153 PM com.apple.usbmuxd[778]: usbmuxd-296.3 on Jul 25 2012 at 00:28:37, running 64 bit

10/5/12 1:57:42.770 PM com.apple.kextcache[774]: kxld[com.apple.driver.AppleACPIEC]: The following symbols are unresolved for this kext:

10/5/12 1:57:42.772 PM com.apple.kextcache[774]: kxld[com.apple.driver.AppleACPIEC]: _AcpiHwRead

10/5/12 1:57:42.772 PM com.apple.kextcache[774]: kxld[com.apple.driver.AppleACPIEC]: _AcpiHwWrite

10/5/12 1:57:42.789 PM com.apple.kextcache[774]: Link failed (error code 5).

10/5/12 1:57:42.790 PM com.apple.kextcache[774]: Prelink failed for com.apple.driver.AppleACPIEC; aborting prelink.

10/5/12 1:57:42.812 PM com.apple.kextcache[774]: Failed to generate prelinked kernel.

10/5/12 1:57:42.849 PM com.apple.kextcache[773]: Child process /usr/sbin/kextcache[774] exited with status 71.

10/5/12 1:57:42.850 PM com.apple.kextcache[773]: Error 107 rebuilding /System/Library/Caches/com.apple.kext.caches/Startup/kernelcache.

10/5/12 1:57:42.851 PM com.apple.kextd[14]: kextcache error while updating / (error count: 3)

10/5/12 1:57:42.851 PM com.apple.kextd[14]: / is still busy, delaying reboot.

10/5/12 1:57:42.852 PM com.apple.kextcache[772]: Lock acquired; proceeding.

10/5/12 1:57:42.858 PM com.apple.kextcache[772]: rebuilding /System/Library/Caches/com.apple.kext.caches/Startup/kernelcache

10/5/12 1:57:42.860 PM com.apple.kextd[14]: async child pid 773 exited with status 71

10/5/12 1:58:21.263 PM com.apple.kextcache[779]: kxld[com.apple.driver.AppleACPIEC]: The following symbols are unresolved for this kext:

10/5/12 1:58:21.264 PM com.apple.kextcache[779]: kxld[com.apple.driver.AppleACPIEC]: _AcpiHwRead

10/5/12 1:58:21.265 PM com.apple.kextcache[779]: kxld[com.apple.driver.AppleACPIEC]: _AcpiHwWrite

10/5/12 1:58:21.282 PM com.apple.kextcache[779]: Link failed (error code 5).

10/5/12 1:58:21.283 PM com.apple.kextcache[779]: Prelink failed for com.apple.driver.AppleACPIEC; aborting prelink.

10/5/12 1:58:21.305 PM com.apple.kextcache[779]: Failed to generate prelinked kernel.

10/5/12 1:58:21.342 PM com.apple.kextcache[772]: Child process /usr/sbin/kextcache[779] exited with status 71.

10/5/12 1:58:21.342 PM com.apple.kextcache[772]: Error 107 rebuilding /System/Library/Caches/com.apple.kext.caches/Startup/kernelcache.

10/5/12 1:58:21.343 PM com.apple.kextd[14]: kextcache error while updating / (error count: 4)

10/5/12 1:58:21.345 PM com.apple.kextd[14]: / is still busy, delaying reboot.

10/5/12 1:58:21.354 PM com.apple.kextd[14]: async child pid 772 exited with status 71

10/5/12 1:58:21.458 PM com.apple.kextcache[780]: rebuilding /System/Library/Caches/com.apple.kext.caches/Startup/kernelcache

10/5/12 1:59:00.044 PM com.apple.kextcache[781]: kxld[com.apple.driver.AppleACPIEC]: The following symbols are unresolved for this kext:

10/5/12 1:59:00.046 PM com.apple.kextcache[781]: kxld[com.apple.driver.AppleACPIEC]: _AcpiHwRead

10/5/12 1:59:00.046 PM com.apple.kextcache[781]: kxld[com.apple.driver.AppleACPIEC]: _AcpiHwWrite

10/5/12 1:59:00.064 PM com.apple.kextcache[781]: Link failed (error code 5).

10/5/12 1:59:00.065 PM com.apple.kextcache[781]: Prelink failed for com.apple.driver.AppleACPIEC; aborting prelink.

10/5/12 1:59:00.087 PM com.apple.kextcache[781]: Failed to generate prelinked kernel.

10/5/12 1:59:00.123 PM com.apple.kextcache[780]: Child process /usr/sbin/kextcache[781] exited with status 71.

10/5/12 1:59:00.124 PM com.apple.kextcache[780]: Error 107 rebuilding /System/Library/Caches/com.apple.kext.caches/Startup/kernelcache.

10/5/12 1:59:00.125 PM com.apple.kextd[14]: kextcache error while updating / (error count: 5)

10/5/12 1:59:00.125 PM com.apple.kextd[14]: /: giving up; kextcache hit max failures

10/5/12 1:59:00.126 PM com.apple.kextd[14]: up to date;

 

 

I am still wondering why Seb and I are seeing this problem while Hervé is not. Could there be a difference between app store update vs combo update from 10.8.0 -> 10.8.1 -> 10.8.2 that is causing the kext linking to fail?

i know.. the problem is that osx dynamicly loads kexts and kps when voodoohda is dynamicly loaded.. try booting in single user mode (console only) via -x -s -f -v

 

then do a build there where you choose voodooHDA.. it wont be able to build kernel cache, so the next time you come into osx run:

 

myfix -q -t /

 

.. and see where it leads...

 

 

What command(s) do I use to run EDP in single user mode?

and try using vodooHDA when you do the build...

 

 

I tried using vodooHDA instead of AppleHDA #2 yesterday but I got a kernel panic while EDP was still executing (possibly during cache rebuild but not sure). I did a hard reset but then OSX would not boot. It got stuck at the spinning gear that normally appears just before the desktop comes up.