Q: Firmware update and SATA II hard drive

Just here to report the same problem... (MacBook Pro 13" 5,5, EFI 1.7, Hitachi stock drive.) It's getting to the point where I'm almost able to throw my MacBook out of the Window. Sadly there isn't a Genius bar in sight since I'm in the Netherlands and I don't really feel like missing my machine for over a week for a simple firmware rollback by sending it in. Clean installs and PRAM resets only seem to work for 'so long'.

So Apple, I'd love a rollback tool or a proper firmware upgrade.

same here, in Genius Bar in France

How did you get your firmware downgraded? I've called 4 Apple Stores and none of the Apple Geniuses have heard of this tool/process.

pheh wrote:
I have the same configuration as you and would be interested to hear if you end up getting the beachballs again. I've made the switch from 9400M to 9600M but as yet haven't done an SMC reset or zapped the PRAM.

Absolutely ludicrous for Apple customers to have to troubleshoot their hardware for them. Particularly when the product line is so thin.

Well, I'm on day 3 or 4 on the 9600M after the resets, and still no beachballs. It's a long shot, but what if the 9400M is related to this somehow, through some shared memory voodoo thing? It would certainly explain why this problem is more frequent among 13" and 15" users since many of them are stuck with the 9400M only.

I'll stick with the 9600M for another week or so, if I don't get the beachball thing again I'll switch back to the 9400M and see if the problems return. Not that it would prove anything, they might have been destined to return anyway...

I agree that it's ludicrous that Apple have nothing to say about such a widespread issue, especially at a time when they're running commercials claiming that switching to Mac relieves you from "headaches"... this MBP has given me more headaches than any modern Windows PC ever did (old ones with Win95/98/ME are hard to beat in terms of generating headaches, though).

dam n it

why does Apple not simply release a tool on their website to downgrade????

it cannot harm our machines...

i am 100% sure that Apple is deliberately blocking us from upgrading our HD !!!!

The X25's can't be seen from Disk Utility nor any other utility I throw at it. Diagnostics don't show the drives either. So, I suspect it's to do with the controller. I like the laptop, but am put off by this issue. Seems like the "Pro" in MBP is just a gimmick at this point.

Jerry H. wrote:
why does Apple not simply release a tool on their website to downgrade????

it cannot harm our machines...

It can, actually.
Screwing up your firmware is a very serious problem. One that would likely require sending the machine to Apple to fix.

Does anyone know if you have to install all previous firmware updates in order to install newer ones. For example... in machines that use a BIOS... the BIOS is a full package... meaning you can install anyone you wish. Is that the same with EFI firmware? Is a firmware update a complete firmware package or does it just update the existing firmware? Just curious as I have not installed 1.7 and was wondering if I would be able to go right to 1.8 in the future. That is provided that 1.8 fixes the SATA issue with 1.7. I would hate to be stuck at 1.6 if future firmware updates come out to address other issues and either require 1.7 to be installed first... or contain full EFI installs that have the bum 1.7 SATA built into them.

Here is my update. Its kinda long. Sorry.

I have a third party drive that when installed in my MBP, is not recognized at all. The boot screen stays white. The startup cd won't even work. So, I made an appointment at the Apple Store at Easton in Columbus, OH and took my stock MBP to be looked at. In talking with the genius, he was not aware of the issue but the genius standing next to him remembered seeing something about it so they both looked and found the rollback tool. He burned it to a cd and tried several times to get it to work with no success. The machine would reboot as fast as it would read from the cd. He said they tried the cd on another MBP in the back and it worked fine so they think my firmware is corrupt but because their store is getting remodeled soon, they do not have the logic board in stock to replace and didn't know when they would get any. He suggested calling Applecare. Which I did, and explained everything that happened at the Apple store. Applecare had no solution but to drop the machine at a local authorized service center to have them look at it. So on a whim, when I got home I decided I would try the third party drive one last time and to my surprise it booted. Once in Leopard, it immediately started beachballing and freezing but its progress.
Sorry for the long post Hopefully I will get something figured out soon.

i have an appointment tomorrow at the Clinton Township MI store. i hope they have a clue and know how to search for the rollback.
i have a Seagate 7200rpm that stutters with 1.7 and a Corsair X256 SSD that can be seen, formatted but can't right large files to. I"m a Switcher too... what a joke this is.

Well I hate that this experience is your first with the Mac. This does happen but it is usually not the norm. Apple does figure these issues out. The secretive nature that makes Apple exciting at times can also be very frustrating when there is a problem. I have been using Macs from almost the very beginning and they will take care of us be it a hardware or software fix. Just keep complaining. They do listen.

Cheers, John.

My experience with My Macbook Pro (late 2009) model identifier "MacBookPro5,4"; boot rom version MBP53.00AC.B03 is as follows:

I purchased this mackbook pro on 8/12/2009. Before powering it on, I installed a working Intel X25M 80Gb SSD (G1 model, not G2) which was previously installed in a Sony Vaio laptop, which worked great. Late Thursday evening, I started to install Leopard on it, not realizing that the configuration was flawed. Installing leopard took so long, that I left it and went to bed. It had completed by Friday morning, so I started the application install, which took most of Friday. The problem with the lengthy time was, of course, a problem that has been explained here in other posts. Over the weekend, I remembered that Apple had ported in the Dtrace utility from Solaris, and I worked on discovering why certain processes simply stopped (Sympton: color wheel). A simple dtrace script like:

Sorry about the In the following code, the square-brackets around probefunc seem to be removed
when I preview the code, so put those in if you don't see them.

#!/usr/sbin/dtrace
 
syscall:::entry
/pid == $target/ 
{
  ts\[probefunc\] = timestamp;
}
 
syscall:::return
{
  @observations\[probefunc\] = max(timestamp - ts\[probefunc\])
}

allows the superuser to determine what system calls take the longest period of time (all times listed in nanoseconds). Using a command like:

dtrace -s longest-syscalls.d -c "dd if=dtrace.pdf of=dtrace.samp"

Dtrace.pdf is a file, about 2.5Mbytes in size.

My investigations showed that the longest times were taken by the system's "write()" call. On my current (and original equipment disk), this takes 95495 nanoseconds, which is about what I would expect. Although I no longer have the figures when the SSD was installed, it was upwards of 20 seconds. (i.e. 20,000,000,000 nanoseconds).

While googling around for the answer to this problem, I found two things;
1) On Linux systems, NCQ queues were limited to 0x1F (31) entries. In the comments I saw, this was due to some problem in the protocol.
2) In Germany, there were problems reported between nVidia chipsets and SATA drives related to enabling NCQ.

The further investigation I have done today shows that the SATA driver for OS X is located in the file /System/Library/Extensions/IOAHCIFamily.kext/Contents/PlugIns/IOAHCIBlockStorag e.kext/Contents/MacOS/IOAHCIBlockStorage

At least I'm think it is. Now, using a very old technique, and the command line utility "strings", you can extract all of the strings from this binary file. You can then grep through them for ones containing NCQ. Here's the results of that grep on my system:

AHCI Port NCQ
disabling NCQ ... controller does not support it!
disabling NCQ ... drive does not support it!
disabling NCQ ... user boot-arg requested it!
NCQ support survived all obstacles ... will be enabled!
AHCI: non-NCQ error... trigger resend.
NCQ error state caused by queued command = %d
NCQ error state caused by non-queued command

So, it appears that on some Macs, there is a method using the boot-args to disable NCQ. Otherwise there wouldn't be a need for a string saying that was why it was disabled. The question now, is how to do this on a (late 2009) Macbook Pro? I will contact Apple in the morning to see if they know how.

In the meantime, the utility /usr/bin/otool can be used to disassemble the code in the file using a command like:

otool -tvV IOAHCIBlockStorage

The extracted assembly is unfortunately difficult to understand without access to the header files that define the classes that are being used.

If you have the development tools installed (I think these are called Xcode sometimes), you can use a program they supply called IORegistryExplorer. Starting this up, and then typing 'AHCI' in the search box, you can find the AHCI entry which on my computer reads AppleMCP79AHCI. 3 lines below that, you will see an entry named 'AppleAHCIDiskDriver'. If you select that, in the right-hand pane, you will see "NCQ Boolean True", and "Queue Depth Number 0x20".

Now, while I have not yet figured out how to modify these values, it may be that setting NCQ to false; or Queue Depth to (0 or 1 or 0x1f) might make things work. Or perhaps disabling NCQ from the boot arguments might work too.

PitchBlank wrote:

pheh wrote:
I have the same configuration as you and would be interested to hear if you end up getting the beachballs again. I've made the switch from 9400M to 9600M but as yet haven't done an SMC reset or zapped the PRAM.

Absolutely ludicrous for Apple customers to have to troubleshoot their hardware for them. Particularly when the product line is so thin.

Well, I'm on day 3 or 4 on the 9600M after the resets, and still no beachballs. It's a long shot, but what if the 9400M is related to this somehow, through some shared memory voodoo thing? It would certainly explain why this problem is more frequent among 13" and 15" users since many of them are stuck with the 9400M only.

I'll stick with the 9600M for another week or so, if I don't get the beachball thing again I'll switch back to the 9400M and see if the problems return. Not that it would prove anything, they might have been destined to return anyway...

I agree that it's ludicrous that Apple have nothing to say about such a widespread issue, especially at a time when they're running commercials claiming that switching to Mac relieves you from "headaches"... this MBP has given me more headaches than any modern Windows PC ever did (old ones with Win95/98/ME are hard to beat in terms of generating headaches, though).

Sadly I am not experiencing the same level of stability as you. This disheartens me for two reasons... 1) I'm still being killed by this bug and 2) I've since also reset the SMC and zapped the PRAM (I had already switched to the 9600) - which means our similar configurations aren't acting similar.

I'll fight with a bit longer. Though I am rapidly reaching my tipping point. I had to live through 10.5.6 killing my digital camera's remote view function (a bug created in 10.5.6 that affected any digital camera software that supported the function (Nikon, Canon, etc..) for six months. Now here I am trying to processs photos on a "newer, faster, better machine" that stalls two to four times an hour for 30 seconds at a time.

The 840av->6100/7100/8100 were the culprits last time I had to go through multiple rounds of Apple hardware/software screwing with my livelyhood. Took a long time for Apple to lure me back after that. Yet here I am again... Sitting in the dark... With no answers... But plenty of companany.

Hi Kim.Toms,

Thanks to your useful contribution here.
You are on to something I tried to figure out as well!

There got to be some kernel boot parms to either disable NCQ or force the driver into SATA 1 mode. I am stuck as much as you on trying to figure out the parameter though.

Ollie.

I filed the bug to Apple. For people who know what Apple's Radar is, here's the URL to dup: rdar://7186333

I also posted on OpenRadar my bug report: http://openradar.appspot.com/7186333

Admittedly not the most comprehensive bug report as I have limited experience, but I can say that what's happening to many people here in the thread also happens to me.

I think it should be helpful and constructive if more of us file such a bug to Apple via that communication channel.