Hervé
-
Posts
10013 -
Joined
-
Last visited
-
Days Won
560
Content Type
Profiles
Articles, News and Tips
Forums
Everything posted by Hervé
-
Don't! You won't get anywhere with MBP3,1; try the MBP5,1 instead.
-
Hmm, not exactly... Earlier today, I ran some tests and found that a DW1390 would work perfectly under all network conditions with 10.8.4 whereas a DW1395 would not support AES encryption (trying to connect led to "Connection times out" error message). Bronxteck experienced same problem with a DW1395. So: DW1390 is based on BCM4311 chip (Ven id-Dev id: 14e4-4311) -> Ok in 10.8.4 DW1490 is based on BCM4311 chip (Ven id-Dev id: 14e4-4312) -> Ok in 10.8.4 DW1395 is based on BCM4312 chip (Ven id-Dev id: 14e4-4315) -> NOk in 10.8.4 (only clear wifi or WEP wifi) Maybe rebranding the cards would fix the issues...
-
That's difficult to answer. Hackintoshing a laptop is a rather opportunistic method in the sense that, unlike a desktop, you don't usually buy (and can't build) a laptop to turn it to Mac OS X. One can only try and run Mac OS X on the basis of would-be compatible hardware specifications. As such, you'll find it hard to find a definitive "ideal" platform that act and run like a real MacBook. Browse our forum for Asus/Acer/HP/Latitude E Series models and see how that goes. There are other sites that provide good lists too.
-
Ok, did some quick tests: AR5B91 - AR9281 chip - works OOB -> Ok with AES wifi encryption (& clear wifi of course) DW1390 - BCM4311 chip - works OOB -> Ok with AES wifi encryption (& clear wifi of course) DW1490 - BCM4311 chip - works OOB -> Ok with AES wifi encryption (& clear wifi of course) DW1395 - BCM4312 chip - works with patched kext -> NOk with AES wifi encryption ("connection timed out" error message), only Ok with Clear wifi (basic WEP encryption not tested due to unavailability on my wifi gateway) I therefore confirm what Bronxteck said: 10.8.4 no longer seems to support higher wifi encryption for Broadcom cards that require a patched kext.
-
Hi, follow the process documented in R&D -> Other research -> DSDT section https://osxlatitude.com/index.php?/topic/1945-dsdtssdt-patching/
-
!!! WARNING !!! 10.8.4 seems to break network connection for some Wireless setups. Several users have now reported problems with Broadcom-based cards. Bronxteck confirmed this and indicated that 10.8.4 can break connectivity to secured network. However, open or low-secured networks (WEP) retain ability to connect. I'll try and test things with DW1390 and DW1395 cards tonight. Atheros-based cards listed as "Airport Extreme" (i.e. as fitted to real-Macs) appear unaffected by the above issue. As such, update with caution and be ready to change to WEP or Open-encryption with MAC @-filtering...
-
In that case, I can confirm that Atheros cards, as used in Apple Macs, appear unaffected by the 10.8.4 update. I switched from a Broadcom-based DW1395 'G' card to an ex-Apple Mac Atheros 9281 'N' card a couple of weeks ago in my D630 nVidia and no side affect to wifi after updating to 10.8.4.
-
No, SMC 2.3f35 translates to 02030F00 0035. Correct, the Apple link does not list and specific SMC value for the MBP9,2; as such, you're gonna have to experiment with other SMC values and corresponding SMBIOS plist. Just make sure both match, i.e. SMC & SMBIOS plist that match the same Mac model. In your particular case, look for Ivy Bridge models: MBP9.1, MBP9.2, MPBRet10.1 or MBA5.2
-
If you upgraded from 10.7.3 or lower to 10.7.5, you need to do/redo an EDP system build or you will indeed experience KP. -
That's perfectly normal. T9300's Tjmax is 105°C, so you're well within the expected operating T°. My own T9300 runs at similar temperatures. I myself upgraded from a T7500 and you're right: the performance improvement is quite noticeable.
-
All nVidia D620 and D630 can suffer from the GPU defect. No motherboard can be defect-free. If you're certain it's the GPU, not your LCD wire, then you can try to bake your motherboard to reflow the GPU. https://osxlatitude.com/index.php?/topic/2054-my-d620-nvidia-based-laptop-has-gone-belly-up/?hl=bake&do=findComment&comment=15386
-
I'm really sorry, I thought the article mentioned the default SMC value and how/where to get different SMC values clearly enough... Looking at the SMC values mentioned in the article, I also thought the correspondance was obvious enough: 6bytes, eh? 01 | 30 | 0F | 00 | 00 | 03 -> 1.30 f 3 01 | 33 | 0F | 00 | 00 | 08 -> 1.33 f 8 Now try and establish what could it be for 1.68f98 or 1.69f4 (hint hint). Remember: no matter what SMBIOS profile you choose or make, if you do not modify the default SMC value of FakeSMC.kext (which, I repeat, is 1.30f3), well that's what you'll always see in your System Profile...
-
It would please me that you read the article properly! it clearly explains how to edit the FakeSMC plist it clearly explains what to do to determine the Mac model/SMBIOS/SMC that best matches your own Hack illustrations are provided How much more could one need??? And, where did you get that SMC 1.30f3 corresponds to the MPB9,2 ?
-
EDP installs a battery manager kext in /E/E and it appears you need that on your laptop...
-
Yes, I guess you would. Pre-release 10.8.4 versions were known to break wifi but I don't have the details. We need to look into that. I was fortunate enough to purchase and install an Atheros 9281-based 802.11n Apple Mac card in my D630n just a couple of weeks ago and that works OOB, regardless of the version. Consequently, I retained full wifi services after updating to 10.8.4.
-
No idea, no; but, again, I would not even run ML without graphics acceleration so, to me, you're wasting your time here.
-
No, just follow the OSXL installation procedure with myHack + retail OS X installer + boot pack, then EDP system build. It really is very straight forward on those laptops.
-
10.8.4 pre-release versions were known to break Wifi, but until you say more about your own specs, there's little we can do or say. If you're not intending to use MLPF on that D630, don't even think of running ML; there's really no point at all. However, since you're able to install an earlier ML release properly, I recommend that you make a new SL or Lion USB installer from that ML installation. This will get rid of all the trouble you encountered with your virtual machine.
-
D830 ML 10.8.3 sound reverts back to internal speakers after sleep
Hervé replied to ktazn2k's topic in The Archive
1st remove the ACPIPlatform kext from S/L/E and re-run myFix (full). -
You've installed ML with MLPF hack on a D630 with X3100 graphics. Did you read the McRumors thread at all? The MLPF hack does not support upgrading ML in the standard way, at least not without re-running MLPF! The procedure listed in the guides covered ML 10.8.0 to 10.8.3. You need to go back to the updated MLPF web site for the procedure that supports 10.8.4. You'll probably have to start all over again.
-
I would suggest you redo an EDP system build after your update to 10.8.4. With the reintroduction of AppleACPIPlatorm v1.7 in /S/L/E folder, you're likely to experience kext cache issues. The EDP system rebuild should take care of this. If not, try to manually remove the offending kext from /S/L/E and re-run myFix (full).
-
I can't remember if I coded MBP5,1 in that FakeSMC version, so check it! Disable PStateMenu to verify native SpeedStep operation. There's also a good chance that you can run without NullCPUPowerManagement (or maybe you do already), in which case, ensure your Chameleon boot plist has P & C States checked. Are you using a D830 or D630 nVidia DSDT?
-
Can you please provide the specs and OS X version you're running (including the SMBIOS id used)? One possible way to improve this is to try and apply SMC fine-tuning: http://www.osxlatitude.com/tuning-performance-with-fakesmc-smbios-plist/
-
Updated my D630 nVidia 135M successfully using Combo Update 10.8.4. On 1st reboot, I had no keyboard and noticed the CPU reported as a 1.2GHz C2D only. All was Ok after subsequent 2nd reboot. The update installs AppleACPIPlatform kext v1.7 in S/L/E. Like Bronxteck, I strongly recommend to delete that kext to only retain EDP's v1.3.5 in /E/E to avoid cache issues and rebuild permissions & caches with myFix. Nothing else to report. Looks pretty safe to update. EDIT: Oups! 'just realised I had updated my FakeSMC kext to v5.1.67 and made a mistake when modifying the SMC keys. That would explain the strange CPU speed report I was getting on occasion!
