rosmaniac

How did you install Mint? I'll have to do some digging to see how an MBR disk would be detected (and it seems like, from you fdisk output, that it is MBR). On my CentOS multi-boot system fdisk sees this: [root@localhost ~]# fdisk -ul /dev/sda WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted. Disk /dev/sda: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sda1 1 1953525167 976762583+ ee GPT Partition 1 does not start on physical sector boundary. [root@localhost ~]# But gdisk sees: GPT fdisk (gdisk) version 0.8.10 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/sda: 1953525168 sectors, 931.5 GiB Logical sector size: 512 bytes Disk identifier (GUID): VVVVVVVV-WWWW-ZZZZ-YYY-XXXXXXXXXXXX Partition table holds up to 128 entries First usable sector is 34, last usable sector is 1953525134 Partitions will be aligned on 8-sector boundaries Total free space is 263990 sectors (128.9 MiB) Number Start (sector) End (sector) Size Code Name 1 40 409639 200.0 MiB EF00 EFI System Partition 2 409640 587833295 280.1 GiB AF00 MixBusM4300 3 588095440 1113159887 250.4 GiB AF00 MixBusSL 4 1113161728 1317961727 97.7 GiB 0700 CentOS6-root 5 1317961728 1334738943 8.0 GiB 8200 CentOS6-swap 6 1334738944 1953525134 295.1 GiB 0700 [root@localhost ~]# I've not done a mult-drive setup like yours, but it should prove to be interesting. It may take me a few days before I can look through the code; someone else might be a bit quicker with seeing what Chameleon expects from the second and third drive, especially when used with MBR partitioning.

Please see the instructions on setting the proper partition type for the linux boot partition in the thread: https://osxlatitude.com/index.php?/topic/5902-dualboot-installing-linux-after-mavericks/ EDIT: And please note that that only applies if Linux is installed to a GPT-formatted disk. If it's MBR, I haven't tried that one, but the correct type for Chameleon to chain boot is in the same source tree that I note in a post in the referenced thread; you'd just have to look through the MBR equivalent to diskScanGPTBootVolumes.

I have seen this with my M4300 as well, when booting the install USB and before installing EDP. But I haven't seen (with the rev 762 EDP and associated bootpack) the keyboard and mouse issue.

On my Precision M4300, very similar to your D830, I had serious audio issues (including the audio not recognizing at all on some boots) until I did the performance optimizations mentioned in the thread https://osxlatitude.com/index.php?/topic/3078-m4300-no-ethernet/ I found that audio would skip and sputter even on those instances when it would load properly; this was with EDP rev 762 on 10.9. And I found it would not load at all (even to the point of not showing the volume control) at least one out of every four boots. Some audio programs triggered worse sputtering than others. When I applied the performance optimizations all of that went away and audio now works well and works consistently. When I reboot into OSX I'll look and see which version of the VoodooHDA I'm using (it's probably the same one as posted above).

Excellent. You're very welcome, glad it worked!

You need to have Ubuntu install the bootloader on the partition containing /boot (either the / partition or the separate /boot). You then need to use a tool like GPT fdisk (gdisk) to change the 'type' of that partition to '0700' See https://osxlatitude.com/index.php?/topic/5902-dualboot-installing-linux-after-mavericks/ for more information and a success story.

Glad that worked, and you're very welcome.

devilotx, can you provide the output of 'sudo gpt show /dev/disk0' please? Here's what I get with a working triple boot, where one of the OS's in CentOS Linux: dhcp-pool132:bin lowen$ sudo gpt show /dev/disk0 Password: start size index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 34 6 40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B 409640 587423656 2 GPT part - 48465300-0000-11AA-AA11-00306543ECAC 587833296 262144 588095440 525064448 3 GPT part - 48465300-0000-11AA-AA11-00306543ECAC 1113159888 1840 1113161728 204800000 4 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 1317961728 16777216 5 GPT part - 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F 1334738944 618786191 6 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 1953525135 32 Sec GPT table 1953525167 1 Sec GPT header dhcp-pool132:bin lowen$ I've booted into Mav, and am looking at what is available to deal with this.... but it looks like the best solution is going to be installing the OS X version of GPT fdisk ( http://www.rodsbooks.com/gdisk/ ) which can do what you need. Since i have always used the Linux version from a boot USB, I really don't know if gdisk will allow you to edit the boot drive's partition types or not. UPDATE: The author's documentation seems to indicate that only under FreeBSD will you be locked out of editing the partition table of a disk with a mounted volume. YMMV, etc. Hope that helps. The OSX built-in gpt and diskutil commands seem to be pretty weak on making changes to existing partitions, but I would love to be proven wrong.

Further note: it appears that gpt might do the same thing as gdisk, under OS X. I have not tried it, and will at my earliest opportunity reboot into OS X to see if that is indeed the case. I'll update this post if a reply isn't posted before..... (Updated to remove pdisk reference, instead it appears gpt is the command to use). Issue 'man gpt' at a terminal command line to get arguments and such, or use the online manpages on the Apple Developer site. EDIT: The technical info: Chameleon (as of SVN 2283 from voodooproject svn) will recognize one of two GUID's for chain booting a foreign OS: BasicData {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7} or BasicData2 (reserved partition, {E3C9E316-0B5C-4DB8-817D-F92DF00215AE}) as selected in the function diskScanGPTBootVolumes in i386/libsaio/disk.c in the Chameleon source tree. This corresponds to a gdisk 'type' of 0700. In order to detect a 'native' Linux (8300 type) Chameleon would need to be patched to recognize GUID {0FC63DAF-8483-4772-8E79-3D69D8477DE4} as well. But CentOS 6 at least uses the reserved EFI type of EF00 {C12A7328-F81F-11D2-BA4B-00A0C93EC93B} for the booting partition. You can find the list of gdisk's 'types' to actual GUID's along with comments in the gdisk source tree; through-the-web svn: http://sourceforge.net/p/gptfdisk/code/ci/master/tree/parttypes.cc Hope this is helpful to someone.... it was fun spelunking in the Chameleon source to find it.

devilotx, I'm assuming first that you installed to GPT instead of MBR. If that's not the case, then this probably won't work for you. Also, note that while I dual-boot Linux, I'm using CentOS, not Ubuntu. So, as the saying goes, your mileage may vary (YMMV). You need to change the partition type of the Linux boot partition to '0700' for Chameleon to recognize it, in my experience. This can be done most easily with a program called 'gdisk' which is available for Linux and OSX. By default, CentOS at least will set the boot partition's type to EF00 (as that's correct when booting from a 'normal' EFI). Here's the output of 'gdisk -l /dev/sda' for my triple-boot system: [root@dhcp-pool121 ~]# gdisk -l /dev/sda GPT fdisk (gdisk) version 0.8.8 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/sda: 1953525168 sectors, 931.5 GiB Logical sector size: 512 bytes Disk identifier (GUID): 195C6419-B7BC-4938-A6EE-123456789012 Partition table holds up to 128 entries First usable sector is 34, last usable sector is 1953525134 Partitions will be aligned on 8-sector boundaries Total free space is 263990 sectors (128.9 MiB) Number Start (sector) End (sector) Size Code Name 1 40 409639 200.0 MiB EF00 EFI System Partition 2 409640 587833295 280.1 GiB AF00 MixBusM4300 3 588095440 1113159887 250.4 GiB AF00 MixBusSL 4 1113161728 1317961727 97.7 GiB 0700 CentOS6-root 5 1317961728 1334738943 8.0 GiB 8200 CentOS6-swap 6 1334738944 1953525134 295.1 GiB 0700 [root@dhcp-pool121 ~]# The way I use it is a bit convoluted. When I go to install a CentOS installation to a system booting with Chameleon, I have a couple of boot USB drives available. One is a boot USB of the installer, and the other is a 'live' USB, both using CentOS. I don't install from the 'live' USB because I don't like the default preferences that brings across, and, well, I like to select lots of packages out of the gate off the install media and go away for a while during the actual install. Anyway, the 'live' USB is set up using the Fedora liveUSB tools to have a persistence overlay; i then add the 'EPEL' repositories to the live USB and install gdisk there. I boot the install media, do the install, shut down, boot the live USB, and change the partition type of the CentOS boot partition with gdisk from the live USB media. With Ubuntu, I know you can do very similar things, including the persistence overlay and custom live USB spins, but since I've not done that with Ubuntu I can't give a step-by-step. Since Ubuntu installs most easily from the live media, a custom spin of the live media with the gdisk package will do what you need. What you'll have to do then is launch a command line terminal and run gdisk on your hard disk, and change the partition type with the 't' command. You can also assign descriptive names within gdisk. When done, use the 'w' (write) command to write the changes back to disk. The '?' at the gdisk prompt with give you help. Do be careful that you have the correct disk, as gdisk, being a disk partitioner, can potentially cause data loss. So, back up your OS X stuff beforehand, if you have anything important to back up. Hope that helps. EDIT: While I'm sure this could be done inside OS X, I am first and foremost a Linux freak, and so I tend to use Linux tools to do things. A 'pure' OSX recipe for doing the same thing would be interesting.

Ok, can do. And, yes, the 690 is on my list. That will need a complete set of new model data, and will be a fun project. Separate threads; I would assume posting results and such in the R&D section......

Bronxtech, I'll do what I can. I understand the time issues, since I've been involved in some open source projects before, including one stint over a period of five years that, when I did step down, a number of people expressed surprise that I had done it all as a volunteer. I also have several children and a full time job, and I understand the pressures, particularly in terms of support (it's amazing to me how pushy people can get for support of a free-to-them nature! I still get e-mail 'demands' for fixes, and I haven't maintained that one package for several years!). Within the four unique systems I have (all listed in my sig), what do you think needs the most attention? I'm going to put forth the most effort into just looking and seeing what set of modules, within the normal EDP framework, produces the best out-of-the-box performance on M4300, and I'm working towards that first by setting up a multiinstall rig over the next few weeks. I'll record my selections as I go, and then update my local edp.sqlite3 database and make sure the default on my system then matches what works. Anyway, I'll find it fun to learn some of this that is new to me, and I hope I'm able to provide some positive contributions back to the project.

Hervé, I appreciate the additional information and your great work in these forums. I've only put in the details that I have in order to support my initial assertion: the M4300 with Mavericks felt sluggish with the out of the box EDP build (as of SVN rev 762). It felt slower than my previous D820. And that's the bottom line. It's great that there are customizations that can be done outside EDP, and I thank you for the pre-baked M4300 files. But it does mean I've left EDP behind for anything in the future, as an EDP model build will wipe out what is working so wonderfully right now. (Yeah, I know how to put it back....). But the ordinary EDP user is not getting the performance that they could get; and, yeah, I see the difficulties with how to go about implementing that on the developer side, especially in light of the rapid updates to FakeSMC. And I thoroughly understand the stability question (that's why my choice of Linux is CentOS, based on RHEL). Please understand that I'm not complaining for myself by any means; I'm just trying to advocate for the newbie; even the seasoned PC user, Windows or Linux or other, is going to find OS X to be a bit arcane for a while (I certainly did, and I've been using, administering, and programming Unix systems for 26 years). I'd like to help solve this in some way, and one thing I can do is set up a testbed for regression testing the default EDP builds for M4300 for each supported version of Mac OS. Because, as you mentioned, testing is critical. Much of the infrastructure for doing the customizations is already in place; EDP is already database-driven and highly configurable (I'm looking forward to seeing the latest developments, too, particularly any changes made in edp.sqlite3). If you know what you need to modify and have the values for the appropriate places in FakeSMC and smbios.plist those can be database-driven. No, that's not a small task. Barring the customizations, there has to be something else going on; it just doesn't make any sense that the substantially faster M4300 would feel slower than the D820, with both systems running the 'stock' EDP builds, and both on Lion (which is where I started with the M4300). But I reserve the right to be wrong. And if you and the rest of the OSXL crew just want me to shut up about it, well, I can do that too. But I'd like to help improve the performance situation for the user who just uses the stock EDP build for M4300, if I can.

The point is to illustrate that the EDP default is pretty poorly tuned, at least for M4300. And I'm glad to see change in that on the horizon, and I want to be able to confirm improved performance in the default EDP. After all, one of the draws of EDP over the rest is that there is model data that is supposed to be somewhat tuned for each supported model, no? Incidentally, this isn't meant as a criticism of the project, just a desire to make it better. And when I have my test rig built and in hand, I will be able to hopefully help confirm that what EDP builds for each model really is tuned. Perhaps I'm odd, but I tend to think that a newer model with a faster processor should perform better in real world tasks than the older model with a slower processor. I'll go the next step and state that I think it's a bug in the current model data that the performance isn't at least somewhat tuned. I am willing to help check out different combinations, too, to try to find sane default model data for at least the M4300 (and maybe the D820, too, since it may not be running optimally). And I'll again be looking forward to seeing the SVN commits come down. EDIT. Upon reading that, I see that I really didn't explain what I consider to be a 'default' EDP setup. I consider a default EDP setup to be what an EDP build made by just selecting the model the normal way, and then doing the build without any customizations of any kind. I'm not talking about bootpacks, here.

Ok, in the thread https://osxlatitude.com/index.php?/topic/3078-m4300-no-ethernet/ a set of files are posted, and a bit of discussion occurred about M4300 performance relative to D820 with default EDP, and the extreme performance boost presented by the use of the MBP5,1 SMC and SMBios, along with some other kext changes. Please see that thread for the files, context, and such. Also see the article on performance tuning with FakeSMC and SMBios, http://www.osxlatitude.com/tuning-performance-with-fakesmc-smbios-plist/ Now, I'm getting ready to build my second M4300 into a benchmarking rig, but before I put out the effort to do so I wanted to see if it was worth it to get a completely apples-to-apples comparison. So I ran XBench 1.3 in three different scenarios: 1.) On my D820 at home running Lion; 2.) On my M4300 running ML and the default EDP kext set/SMBios setting (MBP3,1) 3.) On that same M4300 running Mav and the MBP5,1 SMBios and kext set with native speedstep. Now, I know that those benchmarks are not exactly apples-to-apples, but they give me enough information that I'll post the composite numbers here, and then I'm going to build my benchmarking rig over the next weeks. I have a spare Seagate Momentus 7200RPM 500GB drive, and I'm going to either create seven or nine partitions: 1.) MavE (EDP default) 2.) MavC (MBP5,1 custom Extra) 3.) MLE (EDP default) 4.) MLC (MBP5,1 custom Extra if I can make that work with ML) 5.) LionE (EDP default) 6.) LionC (MBP5,1 custom Extra if possible) 7.) SLE (EDP default) (if doing this with 10.6 is even important) 8.) SLC (Custom MBP5,1 if at all possible) 9.) Data. Yep, either a sextuple or octuple-booting system. It will be interesting to see how Chameleon handles that. Of course, I will have to be exceedingly careful doing the installs in the right order, and I've also gotta figure out that order..... And I may only do quad boot, with just Mav and Lion, but I haven't decided. I do have hardware that works only up to 10.6.8, and I have other hardware that only works up to ML (Tascam US-224 and 428 up to 10.6.8; Tascam US-144 for up to ML, although Tascam might possibly release for Mav, since their entire US-xxx line is out of commission on Mav right now (32-bit kexts.....)). Anyway, the numbers that to me make this worthwhile to get true apples-to-apples (and the reason that I want Lion on the M4300, both EDP default and the MBP5,1 custom) is the comparison between the D820 (limited to Lion unless you want to go to great lengths and do odd things) with a T7400 CPU and the M4300 with the much much faster T9300 CPU. Xbench produces a composite result of 51.32 on the D820, with a CPU composite of 69.44, a Quartz composite of 94.21, an OpenGL composite of 28.25 (35.83 FPS), and a User Interface composite of 57.05 (261.83 refreshes/second). Ok, on ML on the M4300 with a 2.5GHz T9300 and the default EDP, Xbench composite is 86.71, CPU 158.37, Quartz 191.03, OpenGL 87.25, but a User Interface composite of 43.26 (198.53 refreshes per second). That last number exposes just how slow the system feels, which for many things is noticeably slower than the D820 at a 433MHz slower clock and a Merom CPU versus the Penryn. It's impressive that even when held back a bit the Penryn manages over twice the performance of the not-that-much-slower-clocked Merom. On the tuned Mav install (MBP5,1) the M4300 really shows its speed potential, with a composite of nearly twice that of the default EDP on ML of 166.9, a CPU of 180.05, a Quartz test of 187.94, an OpenGL of 111.89, and a User Interface Test of a blistering 240.67 (1K refreshes per second). Now that's more like it, with the Penryn really shining at 2.5 times the speed of the Merom and the interface responsiveness clocking at a nearly five times the speed of the ML with default EDP on the same M4300 hardware, and four times the speed of the D820 (and it really is that noticeable in real use). And I agree that perceived performance under real world use is more important than artificial benchmark numbers, but in this case the almost totally unusable performance (with programs that I use daily) of ML or Mav with the default EDP contrasted with the several times more responsive Mav with the MBP5,1 mod is a real eye-opener where the true magnitude of the difference is completely reflected by the benchmarks. While I don't have the Mav with EDP default numbers (and I really don't want to change anything with my main M4300 to test that!) at least the merit of having such a benchmarking/test rig is apparent. Now, I use the ML numbers for the default EDP on the M4300, but Mav with the EDP default install felt slower than the ML with default EDP. At least I'm not using the Win7 in a VM on OSX on a PC numbers.....

There is a bit of difference between D630 and D630C; I would imagine a different DSDT due to the different chipset components. D630C indeed has an Intel ethernet chip, according to Dell's information, and not a Broadcom chip. EDP keeps backup copies of replaced /Extra in /ExtraBackups; you should be able to use myHack to reinstall your previous /Extra from the backup copy. The model data includes DSDT and SMBIOS files specific for each model, and this is what likely broke your ethernet. You'll need a D630C DSDT, not a D630 DSDT.

Which benchmarks did you use to do this? Searching the forum brought up a link to a benchmarks page, but this page gets a 'not found' (cute to use a kernel panic to describe this!). The link is http://www.osxlatitude.com/benchmarks/ Indications are GeekBench and Xbench; is this still correct?

Would this be a good time to see about any interest in a separate set of model data for Penryn CPU's? Looking forward to seeing things show up in svn....

T7400 is of course what I meant.... Touché. I know, I know, cross-comparing things is a bit baroque. Particularly using VMware to run Win 7 on OS X on a PC (yes, I thought about the irony....). The only way I'll run any Windows is in a VM; I also run Win7 under CentOS 6 Linux as a KVM guest. Snapshots and rollback are a virus's worst nightmares. The point that I'm at least attempting to make is that the M4300 felt slower than the D820. Significantly slower. The closest to an apples-to-apples test I could do is the Win 7 VM, since VMware presents the same abstraction layer regardless of version of OS X or the underlying hardware. So I could take an exact bit-for-bit clone and run on the newer hardware without triggering any device driver installs or other things that would make things not "equal." FWIW, I ran the 'Windows Experience' thing multiple times and got consistent results. Also FWIW Lion felt slow on the M4300, too. I actually did the M4300 EDP build with the drive in the D820; then I moved the drive to the M4300 and it booted right up. I then did an EDP update and another build, and I immediately noticed the audio had begun stuttering and the performance felt sluggish. I unfortunately didn't try the audio apps before doing the initial EDP update, though. I used the default M4300 EDP builds. I then did the upgrade to ML, which didn't go exactly smoothly (but that was my fault for not using the migration app). Thinking that the issue might be the way I just moved the drive over with the M4300 build prebuilt on the D820, and not being a scratch install, I then bought an HGST 1TB drive (inexpensive, fast, cool, quiet, and works well in the M4300) and did a scratch install of Mav on it, leaving a lot of room to SuperDuper! clone the ML install over to it and to have CentOS 6 as the third boot option. I got all that done, installed my audio apps in Mav (Harrison Consoles Mixbus and AudioFile Engineering's Triumph, to mention two), and immediately ran into the same performance and audio stuttering issues I have on the ML partition (Mixbus, which I use heavily, is basically totally unusable with the default EDP build for M4300, but works great with the default EDP build for D820). Out of a bit of desperation, since I had already given my wife the D820 to use in place of an ancient Sony Vaio Athlon XP laptop that had blown sparks the week before, I then purchased the T9300 and swapped for the T7700 that was in the M4300, but that didn't help either. That is, until I applied the fixes above that you provided, using the newer FakeSMC, etc. Now the audio apps work fine, and they feel as responsive as they used to on the D820. But the VM graphics performance is underwhelming, whereas the D820's VM performance wasn't bad at all. Perhaps it's VMware's abstraction layer not mapping as well to the FX 360M as it did to the NVS120M in the D820. More to look at there. And I need to do a direct comparison of something that would be OS-independent but intensive, like exporting a 2 hour long 16 track audio file from Mixbus, with iZotope Ozone displaying all the neat things that Ozone can display, and then timing the export over ten rounds or so. Export does seem to be faster on the M4300. Oh, and for the OP of this thread; my M4300 while docked right now is using the Ethernet port just fine, using the BCM5722D.kext that the default EDP build placed there. I have run into a few failed ethernet ports on several of the D-series laptops before; look at the contents of /Extra/Extensions and make sure that BCM5722D.kext is there. Sorry for the length of the post; I'm just trying to get across just how severe the performance problem was for me until using the fixes posted above.

Have you tried entering, on the chameleon boot command line, PCIRoot=1 ? I have noticed for a long time that you sometimes have to boot the USB key on nVidia D820 (and D830/M4300, for that matter) multiple times before you get a display. Once EDP is installed and a build is done this behavior stops; but I see it on the USB keys for Lion on D820 and D830/M4300 and for ML and Mav on D830/M4300. And, for virtually every install I've done recently, the first boot after install but before EDP install will do the black screen thing. When you get the black screen, wait a few minutes; if it doesn't come up within say five minutes hard power off the box, and power it on again. I've seen it take four boots before displaying the GUI, even with PCIRoot=1.

How much a difference I didn't realize, and in what area, until I refreshed my Windows 7 VM's Experience index. I run Windows 7 in VMware Fusion 6, the latest version. On Lion, on Fusion 6, and on the D820 with a T7500, the scores were: CPU: 4.3; RAM: 4.5; Graphics: 5.9; Gaming Graphics: 3.0; Hard Disk: 5.9. On Mav, on Fusion 6, and on the M4300 with a T9300, the scores for the same exact VM are: CPU: 4.5; RAM: 4.5; Graphics: 2.0; Gaming Graphics: 2.2; Hard Disk: 6.2. Those graphics numbers speak volumes; and the VM feels sluggish compared to the D820. It doesn't feel as sluggish with the native speedstep (MBP5,1) kexts and plists, but it still doesn't feel as snappy as the D820 with the slower T7500 CPU did, at least under VMware. The native OS X apps feel ok now, but I have to wonder what a graphics benchmark would show, D820 versus D830/M4300.

Alright, a bit more info. Do understand that I'm doing this on a Precision M4300, which is more similar to a D830 than to a D630, but they're all fairly close. GeekBench 3 scores: Mountain Lion with default bone-stock EDP, T9300 CPU (2.5GHz Penryn): Single core 1309, Dual core 2195. Mavericks with the MBP5,1 mods as mentioned above, same hardware: Single core 1353, Dual core 2459. Not spectacular for the single core benchmark (3.3% increase), but the multicore benchmark's 12.5% speed increase (and this is a processor, not a system, benchmark!) shows that the bone-stock EDP on ML is slower than Mav on the same exact hardware (and I mean exact; ML is one one partition and Mav is on another, and I'm selecting which one I boot from Chameleon).

Which C2D CPU do you have exactly? The quick upgrade for performance is to get a Penryn CPU (assuming the D630 can take one, and I think it can) and do the mods found in the thread https://osxlatitude.com/index.php?/topic/3078-m4300-no-ethernet/ (yes, that's for an M4300, but with some modifications should work fine with the 630). I found the default EDP installed kexts caused significantly less performance than I had with my previous generation D820. I cannot understate just how much of a performance improvement getting the Penryn CPU and the right kexts in place was; it was not a small improvement, and in my specific instance was the difference between a totally unusably slow system and a snappy system. But you need a Penryn CPU to take advantage of native SpeedStep it seems. A T9300 on eBay should only cost $50 or so, and the increase in performance is very significant over the Merom CPU even at the same clock speed (most bechmarks show a 25-30% improvement from the T7700 at 2.4GHz to the T9300 at 2.5GHz; yes, 100MHz faster clock but nearly 30% better performance. Something is amiss with the default EDP for M4300 at least; I've not looked at the exact diffs between the M4300 EDP and the D630 nVidia but they should be close, with the biggest difference being the LCD resolution and the video chip's RAM size, to the best of my knowledge. Herve, what do you think? Going to 4GB of RAM is also a good thing, and if you can swing it will help things along, too. But not as much as the Penryn CPU with the right kexts, org.chameleon.boot.plist and smbios.plist was, at least for me!

Madmax, Have you gotten this to work as yet? I just did tonight; man, what a difference! I do multitrack, DSP-intensive, audio processing. My M65/D820 with the T7500 was considerably and noticeably more responsive than my M4300 which has the 2.5GHz T9300. In particular, the audio stuttered badly on the M4300. With this /Extra, things are snappy on the M4300 now. The difference is night and day; before, mixing was basically impossible, and everything felt sluggish, but not now.

Since my /Extra was for 10.6.0, it has, if I remember correctly, a specialized IOATAFamily for PIIX support (I don't have access to the tree at the moment to give details on that, but will update here when I do). The need (and advisability) to have this (to support the PATA DVD drives) goes away in 10.6.3, and so I would think this kext would cause such an issue as you see. But I reserve the right to be wrong. I really need to get you a copy of what i have for 10.6.8; that will be closer than what works for 10.6.0.