Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


bikinifarm last won the day on October 15 2013

bikinifarm had the most liked content!

About bikinifarm

  • Rank
    InsanelyMac Geek

Profile Information

  • Gender
  • Location
    Chicago, Illinois
  1. Agreed. The number I provided (65.5Mbytes) was obtained from SSD to SSD. HD to HD I was getting around 52Mbytes.
  2. The numbers I quoted are sustained copy rates, using a Finder copy of 17 gig sparseimage documents. Burst rates may very well be far higher than the sustained rates I got, which include Finder overhead.
  3. Working fine here on a matching pair of Intel DH87MC's for over a week now, each with i217V. No issues observed, wake not tested. Casual testing moving a 17 gig file in respect to hnak's 1000e shows over 25% performance improvement, i217v <-> i217v. Looks and works fine. The highest speed I have seen copying large files is around 65.5 Mbytes per second, which I believe is a good number considering packet overhead etc. Thanks for the good work.
  4. If you care to test, you can easily prove that swapping the buried kext does not trigger a proper rebuild of the cache, because Apple does not expect you to do that. As to the location of the kext, I put it where Apple puts it, also as recommended at the beginning of this discussion. Enough said.
  5. That would be "two directory levels down", spelled out for your convenience. The file in question sits in: /System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/AppleIntelE1000e.kext As it should be painfully obvious that AppleIntelE1000e.kext sits two directory levels below IONetworkingFamily.kext and your touching /System/Library/Extensions does not do zip. Jeez.
  6. Not same at all. Since AppleIntelE1000e.kext is buried two levels down, swapping it and doing what you suggest does not rebuild the kext cache reflecting the swapping of the new version. Hence, this is why people install this kext and don't see its effects unless they happen to do something a bit more drastic to kick it into gear. However, when you move it out and back in, it rebuilds the kext wholesale including the bits two levels down. There are multiple and repeated occurrences of this happening in this very discussion if one cares to read.
  7. I usually do the following, and the cache is built properly: mv /System/Library/Extensions/IONetworkingFamily.kext ~/Desktop/ mv ~/Desktop/IONetworkingFamily.kext /System/Library/Extensions/
  8. I can also confirm that 3.1.0 with the NETIF_F_TSO set to no indeed works and replaces 2.4.14, for the first time.
  9. You have to click on "Snow and Above".
  10. Unfortunately, it is a no-go. The console log starts spitting out: failed to getphysicalsegment in outputPacket. once you start a big copy. Craps out around the 8.5 Gig copied mark, just as any version after 2.4.14. So, back to 2.4.14. Thanks for the effort anyway, hnak, much appreciated.
  11. Thanks hnak. We'll give it a test and report back...
  12. bikinifarm

    [UEFIPatch] UEFI patching utility

    ctroncosor: I went through this with my Haswell (Intel) motherboard. I was successful as I documented here but it is definitely not the easiest thing to do.
  13. This happens with subsequent versions, but not with 2.4.14. Make sure you have installed this kext in IONetworkingFamily.kext under Contents/Plugins and you have rebuilt the cache. Since this file is buried deep inside a kext, the cache typically does not get rebuilt unless you do a: sudo touch /System/Library/Extensions If unsure, boot without cache. All of this behavior has been reported here on this very forum a number of times, and nothing new. Please read previous posts.
  14. I am running 2.4.14 on Mavericks for over a week now with zero problems. I have had issues with anything later.
  15. I have just successfully patched my Intel Haswell motherboard's (DH87MC) UEFI BIOS using a RaspberryPi Model B as an SPI programmer based on CodeRush's recommendations. Posting how I did here for other people who may have no option but to go down this path. Warning, this is not for the faint hearted, or people who have no experience in soldering. Unless you know what you are doing, you are very likely to mess up your board. Make sure your motherboard has the BIOS you want to patch. I followed Pacman's instructions from here (or here) very closely. I deviated from his instructions when installing pciutils required a manual download, and make, sudo make install, and sudo make install-lib. flashrom also requires manual downloading, make, and sudo make install. I did not remove the BIOS (SPI) chip, instead I soldered very thin wires to it in place. This is not necessarily good practice, but worked for me. I did not remove the motherboard cables (also not necessarily good practice), but I disconnected my computer from all external connections, especially power. With the main computer unplugged and disconnected from everything external, except the soldered wires from the raspberrypi, I booted the raspberrypi, and executed a "sudo flashrom -p linux_spi:dev=/dev/spidev0.0 -r biosbackup.rom". Took at least 5 minutes. Now we have the BIOS in a file named 'biosbackup.rom'. I copied the file biosbackup.rom from the raspberrypi to a Windows 7 VM, and ran PMPatch.exe, naming the output file biosbackup_patched.rom. (I was not able to run on OSX due to Segmentation fault: 11.) After I brought the patched file back to the raspberrypi, and I executed "sudo flashrom -p linux_spi:dev=/dev/spidev0.0 -w biosbackup_patched.rom -V". It also took at least 5 minutes. It came back verified, but before I removed the wires, I ran a second test by executing "sudo flashrom -p linux_spi:dev=/dev/spidev0.0 -r biosbackup_patched_reread.rom". I compared the files biosbackup_patched.rom and biosbackup_patched_reread.rom in OSX using Hex Fiend. They were identical. I reset the CMOS by removing the motherboard battery to be on the safe side. Removed the wires from the BIOS SPI chip. Reassembled the computer, and booted successfully. Tested with 10.8.5 and 10.9 DP8 successfully. Once again, this is your last resort, and is not recommended unless you absolutely know what you are doing. CodeRush and Fix It Felix Jr, thanks for all the support. Much appreciated. EDIT: If you are going this way, you may want to consider investing in a SOIC8 / SOP8 (or whatever matches your SPI chip) in circuit test clip instead of soldering on to your motherboard. Look for "SOIC8 in circuit" on ebay. They go for about $10.