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.

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

Oops! My mistake, never mind.

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.

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

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.