Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

steffi

macrumors 6502a
Original poster
Jun 7, 2003
866
12
I recently added

NewerTech MaxPower 6G PCIe eSATA 2-Port

to my Hexacore Mac Pro

I currently have an 200GB OWC Mercury Extreme RE SSD 200GB Mercury Extreme Pro RE SSD sitting on optical port

it seems whenever I added this to my machine recognise the boot drive upon startup seems to be a lot slower now.

anybody else see this?
 
Hello,

Do you have a drive connected to your eSATA card?

If you remove the card, is your start-up faster?

Loa
 
I've also noticed the same thing with my 09 Mac Pro as soon as I added the esata card my boot time went from 14 seconds to 21. Interesting.
 
It is scanning the eSata for bootable drives. Needs to initialise some additional resources in the NVRAM to access. Apparently it takes a while.
 
Yes, that Newertech card takes quite some time to boot up with, it also won't let you hot swap drives, it emits a shrilling alarm if you try. Additionally it adds an ugly text bios screen for Windows bootcamp. I wasn't a fan..mine is sitting on a shelf.

I'm now using a Highpoint SATA card right now that doesn't add any delay if no drives are attached (unlike the Newertech) and adds a much shorter delay when drives are attached. Hot swap is also possible. (I have an external power supply for the drives)

That was my first attempt with eSATA and I didn't enjoy the experience !
 
Last edited:
Are you sure about that? I was under the impression that this card didn't support booting. This card uses the snow leopard drivers.

Yes, but that Newertech card lets you boot your mac from a eSATA drive. Most other cards (don't know about highpoint) won't let you do this.

Loa
 
Are you sure about that? I was under the impression that this card didn't support booting. This card uses the snow leopard drivers.

You were right. Somehow I misremember the xlr8yourmac.com review about this card. I removed the info from my last post. Only boots in windows.

In this case, I have no idea why it adds time to your boot time! :)

Loa
 
I have a ssd boot drive too so I am very aware of any slowdowns in boot time, particularly for some reason when I see the booting "pinwheel" taking more revolutions than it usually does. In my case the average number of revolutions is about 3 (and I think it's about one revolution per second). So this weekend, when I installed the drivers for a Sonnet E2P eSata card I just got from OWC (and coincidentally as a replacement for a NewerTech MaxPower 6G PCIe card I returned) I was not happy about a 4x slowdown (12 revolutions of the "pinwheel").

I removed the installation and was surprised that I continued to have the longer boot time. I also had removed the card too. This got me curious. To make a long(er) story short, after some experimentation, I discovered that simply the process of installing the kext was the cause of my slowdown. It's related to how the system caches kext's.

It's interesting that the Sonnet installer tried to address the kext installation's cache effect in their installer (in the preflight script which is part of the package installer) but the instruction to handle it was commented out. And there is no such attempt in the MaxPower 6G installer (I saved the installer for some reason).

So all of the above was just to give the context of how I cured my boot time problem (I got my 3-revolution "pinwheel" again) and a possible suggestion on how to remove the slowdown after installing these eSata drivers.

In Terminal execute the following command:

sudo kextcache -e

You will get a prompt for the administrator password (from sudo) and the kextcache -e will start executing. This command may take a minute or two (I'm guessing that's why it was removed from the E2P installer) and a few messages may be displayed.

Next reboot. This reboot will take longer and that is expected since the kext caches are being fixed (rebuilt I think).

All following reboots should now be "normal" and hopefully back to your original boot speed (in my case the 3-revolution "pinwheel").

Now I am not saying this is guaranteed to address the boot slowdowns mentioned in this thread. I'm only describing my situation. But it can't hurt to give it a try. And if anyone does please report back whether it fixed the problem.
 
I have a ssd boot drive too so I am very aware of any slowdowns in boot time, particularly for some reason when I see the booting "pinwheel" taking more revolutions than it usually does. In my case the average number of revolutions is about 3 (and I think it's about one revolution per second). So this weekend, when I installed the drivers for a Sonnet E2P eSata card I just got from OWC (and coincidentally as a replacement for a NewerTech MaxPower 6G PCIe card I returned) I was not happy about a 4x slowdown (12 revolutions of the "pinwheel").

I removed the installation and was surprised that I continued to have the longer boot time. I also had removed the card too. This got me curious. To make a long(er) story short, after some experimentation, I discovered that simply the process of installing the kext was the cause of my slowdown. It's related to how the system caches kext's.

It's interesting that the Sonnet installer tried to address the kext installation's cache effect in their installer (in the preflight script which is part of the package installer) but the instruction to handle it was commented out. And there is no such attempt in the MaxPower 6G installer (I saved the installer for some reason).

So all of the above was just to give the context of how I cured my boot time problem (I got my 3-revolution "pinwheel" again) and a possible suggestion on how to remove the slowdown after installing these eSata drivers.

In Terminal execute the following command:

sudo kextcache -e

You will get a prompt for the administrator password (from sudo) and the kextcache -e will start executing. This command may take a minute or two (I'm guessing that's why it was removed from the E2P installer) and a few messages may be displayed.

Next reboot. This reboot will take longer and that is expected since the kext caches are being fixed (rebuilt I think).

All following reboots should now be "normal" and hopefully back to your original boot speed (in my case the 3-revolution "pinwheel").

Now I am not saying this is guaranteed to address the boot slowdowns mentioned in this thread. I'm only describing my situation. But it can't hurt to give it a try. And if anyone does please report back whether it fixed the problem.

Thanks for the tip. probably a good idea to run a permissions repair just before running this command.
 
Thanks for the tip. probably a good idea to run a permissions repair just before running this command.

Why would you expect kext cache, which is set as 'root', be changed to anything else? The installer wouldn't change any permissions to anything other than root either.
 
Too many people recommend repair permissions and don't understand why.

Some people probably think you can fix hardware problems with repair permissions.

Why would you expect kext cache, which is set as 'root', be changed to anything else? The installer wouldn't change any permissions to anything other than root either.
 
I have a ssd boot drive too so I am very aware of any slowdowns in boot time, particularly for some reason when I see the booting "pinwheel" taking more revolutions than it usually does. In my case the average number of revolutions is about 3 (and I think it's about one revolution per second). So this weekend, when I installed the drivers for a Sonnet E2P eSata card I just got from OWC (and coincidentally as a replacement for a NewerTech MaxPower 6G PCIe card I returned) I was not happy about a 4x slowdown (12 revolutions of the "pinwheel").

I removed the installation and was surprised that I continued to have the longer boot time. I also had removed the card too. This got me curious. To make a long(er) story short, after some experimentation, I discovered that simply the process of installing the kext was the cause of my slowdown. It's related to how the system caches kext's.

It's interesting that the Sonnet installer tried to address the kext installation's cache effect in their installer (in the preflight script which is part of the package installer) but the instruction to handle it was commented out. And there is no such attempt in the MaxPower 6G installer (I saved the installer for some reason).

So all of the above was just to give the context of how I cured my boot time problem (I got my 3-revolution "pinwheel" again) and a possible suggestion on how to remove the slowdown after installing these eSata drivers.

In Terminal execute the following command:

sudo kextcache -e

You will get a prompt for the administrator password (from sudo) and the kextcache -e will start executing. This command may take a minute or two (I'm guessing that's why it was removed from the E2P installer) and a few messages may be displayed.

Next reboot. This reboot will take longer and that is expected since the kext caches are being fixed (rebuilt I think).

All following reboots should now be "normal" and hopefully back to your original boot speed (in my case the 3-revolution "pinwheel").

Now I am not saying this is guaranteed to address the boot slowdowns mentioned in this thread. I'm only describing my situation. But it can't hurt to give it a try. And if anyone does please report back whether it fixed the problem.

Running
sudo touch /System/Library/Extensions/
also forces their updating with slightly less risk than using kextcache.
 
Why would you expect kext cache, which is set as 'root', be changed to anything else? The installer wouldn't change any permissions to anything other than root either.


Just a habit. Trying to make sure I don't have some other problem that may hang something, but like you say probably doesn't matter. I ran your script to get rid of any old pcie card cache I may have had after removal of the atto card for the heck for it, rebooted and everything was fine. 3 rotations like you said.
 
Just to chime back in here about the repair permissions thing. I rarely ever do that and in the forced-cache rebuilding process I described I didn't do it then either. There are situations, I suppose, where some permissions could go so far south that it might slow the system down but I don't recall any case in recent history in my systems. As for installers screwing up permissions I can say "yes", there are poorly written installers out there that do screw up permissions of selected items. But I haven't seen too many of them in recent years and it's certainly not the case with these driver installers.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.