Mac OS X 10.5.x Special Report: FireWire device problems
Mac OS X 10.5.x Special Report: FireWire device problems
We've received a couple of comments about using many FireWire devices at once. A recent note from reader Peter says:
I have a G5 2G and five external drives and two internal. One of the external drive chains has 3 firewire 400 drives on it. The other has two Firewire 800 drives. Both of these chains are off the back firewire ports. When I connect an additional firewire 400 drive to either of these chains everything is fine. When I connect a drive to the Firewire 400 port on the front, the first drive on firewire 800 chain unmounts and I get a warning dialogue.
And you may recall that earlier we published a note from someone who was getting dropped frames from a DV camcorder when importing from the end of a chain of FireWire devices.
Now, several people wrote back about the camcorder problem. The consensus seems to be that camcorders like to be the only FireWire device on the bus. Daisy-chaining just isn't the way to go.
This is hardly my area of expertise, but all of this got me interested so I did a little checking around on the Internet to see what I could learn.
In theory, FireWire daisy chains can be very long and FireWire device clusters can be very large; the nominal limits are up to 63 devices and up to 16 cable lengths.
In real life, however, it is possible to bang up against various narrower limitations and misbehaviors. For example, I've already discovered by experimentation that, on my first-generation iMac, which has no built-in iSight camera, if I attach an external iSight one port on my computer, and there is already an external FireWire hard drive attached to the computer on the other port, the external FireWire hard drive will simply stop working properly (copies of large files will start to fail, for example). This seems to show that something about the way things are powered and the way buses are arranged can be quite touchy.
Digital video cameras (DV), it turns out, are a particularly notorious problem. According to the 2ndWave site, having any other FireWire devices attached when you're transferring DV can affect the quality of the transfer, and merely turning on a DV camera can stop a FireWire hard disk from working. Apparently the reason for this is that you're transferring both audio and video and you have to transfer them at speed. In other words, your system (including the hard drive you're writing to) have to keep up with the transfer rate; it isn't like copying a file from one hard drive to another, where the data just flows at any old speed, but rather is more like burning a CD, where the data supply must keep up with the burning rate (only here it's the other way around, the writing rate must keep up with the data supply).
A really useful article on this topic describes some of the specifications involved: your target hard drive needs to be fast, to have an 8MB cache, and it needs an Oxford 911 chip for FW400 or an Oxford 922 chip for FW800. Also, this article says, part of the reason that cameras are special is that many of them operate at a special speed (FW100) which can slow down the whole FireWire bus, meaning that if you put a camera on the end of a chain of drives, the drives can misbehave.
Furthermore, the same article says that FireWire drive chaining just doesn't work as advertised: "G5s seem to have a problem when they talk to more than 4 FireWire drives." That seems to accord with what Peter is seeing.
Now, there seems to be little doubt that FireWire can behave quite unpredictably. On my own machine, I've seen the FireWire ports just stop working altogether. Luckily, a Knowledge Base article from Apple told me the cure - turn the computer off and pull the power cord out of the back, and wait a couple of minutes - but that cure is astonishingly similar to recommending that I sprinkle the fairy dust over the machine. And here's a salutary tale from a reader who says that merely having a FireWire cable plugged into one port caused his internal disk to vanish while trying to install Leopard:
Before beginning the install, I hooked my iMac to my wife's G5 system in Firewire target mode, and did a full backup to her USB drive, after doing a repair using Disk Utility on her system. After the backup was done I successfully booted with the USB directly connected to my iMac. I carried the computer back to my office, hooked it back up, and booted there. Worked fine. Popped in the Leopard disk, clicked to install and rebooted. The Leopard disk couldn't find my internal hard drive! I tried disk utility from the Leopard disk, and it saw the drive, but no partitions. I tried a couple of reboots to the internal drive (no problem) and to the Leopard disk (same result).
The problem turned out to be that I still had the short Firewire cable plugged into the computer, even though it wasn't plugged into anything! I actually plugged the cable into my MacBook Pro, intending to reboot the iMac in target disk mode to run diagnostics. But when I plugged it in, the primary (only) partition on the disk showed up in the Leopard Disk Utility, and I was able to run the installer.
So evidently, this protocol that was supposed to be the savior of storage and rescue us from the SCSI voodoo we were living with every day (remember?) has some voodoo of its own and can't be pressed anywhere near the limits. That isn't a very technical response to Peter's issue, but it's easy to imagine that maybe having a lot of stuff plugged into the two rear FireWire ports and then plugging something into the front port might trigger problems. The cluster can be made more robust, perhaps, by the use of hubs and/or repeaters. But the answer mostly seems to be: Be conservative. (Why does anyone need five external FireDrives anyhow? One big drive or some kind of RAID would surely be better.)
On the other hand, the response, "So don't do that," is neither helpful nor polite, and besides, Peter is quite clear that he regards the issue as an operating system thing (software), not a bus thing (hardware). This is new behavior, he says; he never had a firewire problem before Leopard. He's clearly an experienced computer user (plus he's got more RAM in this one machine than I've got in all my computers put together!), so this evidence is worthy of attention. So, does Leopard introduce new FireWire issues?
Well, we've some evidence that it does. Reader Charlie tells us that his FireWire 800 doesn't work under Leopard, but works just fine under Tiger:
I seem to have uncovered an issue with a new LaCie d2 Quadra (500 GB) external drive connected via Firewire 800 to my second generation 15" MacBook Pro (2.16 GHz Core 2 Duo, 2 GB RAM, 160 GB internal drive) under Leopard. Connecting the drive causes an unrecognized disk message to pop up in the Finder. Attempts to reformat/partition the drive (GUID partition scheme) hang forever and do not complete. Attaching via FW400 or USB 2 works perfectly. If I boot up using the Tiger install DVD that came with the MBP, it recognizes the d2 Quadra connected via FW800 with no problem at all (recognized both at the firmware level using an "Option Key" boot) and after the install DVD loads (as seen in either the installable volumes list or in Disk Utility). However, if I boot up off of the Leopard install DVD, it doesn't work (firmware level does still see the drive as you would expect but subsequent boot into the installer ends up with the disk being unrecognized again). I also found that the drive works properly with FW800 on an older G5 (1.6 GHz) system running Leopard so it looks like this is an Intel system issue and may be only with the second gen. MBP's.
And reader DK also reported FireWire trouble that started only with Leopard:
Ever since installing Leopard on my Quicksilver 867, I've been having trouble with my Firewire connections. System Profiler gives the message "Warning: Unable to list Firewire devices". Sometimes the Profiler will show some information about a connected device (after a reboot or a PRAM zap) but the drive wont mount or show up in the Disk Utility. I have tried many different manufacturers and types of Firewire devices and keep running into the same problems. Booting back into Tiger produces none of the anomalies so I have to assume it's a Leopard specific problem.
We also have several reports of Leopard treating RAID drives incorrectly. One reader told us that he could not install Leopard at all on a machine whose two internal disks were arranged as a striped RAID set - the installer simply fails. Another reader, Brian, told us that Leopard's treatment of a mirrored SoftRAID set verged on the downright dangerous:
Having received my mail order of Leopard this afternoon, I booted to the Leopard (10.5) install disk with the goal of installing it on my PPC G5 Dual 2Ghz with a mirrored SoftRAID boot volume. But the 10.5 installer reported my SoftRAID mirrored volume "could not boot this Macintosh". Clearly not true as I can boot into 10.4.x just fine. I had read previously that SoftRAID 3.6.4 claimed (or referenced) 10.5 compatibility so I went back to the site and confirmed. (http://www.softraid.com/news.html) The article isn't 100% clear (and several months old) so something striked me as awry.
But it GETS WORSE. After deciding to install 10.5 on my external Firewire disk instead, I later ran the 10.5 (Apple) Disk Utility just to take a look at the devices list/interface. I DID NOT attempt to make ANY changes. Upon booting back to 10.4 on my SoftRAID volume, SoftRAID reported that my mirror was now out of sync and proceeded to rebuild it. There is NO WAY this is a coincidence and I have never had these disks fall out of sync before.
Still another report, from reader Daniel, tells us that Time Machine is apparently confused by a RAID setup, evidently thinking that the two drives constitute double the data:
my boot drive is setup as raid one - a pair of 750 gb drives. my external drive is 500 gb. my home folder is 280 gb. when i run time machine to back up my home folder to my external drive, time machine warns me that the destination drive does have enough disk space because the total backup size is 560 gb. this is twice the size of my home folder. it appears that time machine is treating my my files on raid 1 as twice the files to backup.
Nor are the problems confined to FireWire. A reader reports that copying a mildly large file across an eSATA connection is failing under Leopard:
When I am running Leopard and I try to copy a large file (I am using an 800MB MP4 file) to the Seagate drive via eSATA connection, the copy will fail with a message saying "The Finder cannot complete the operation because some data in "XXXXX.mp4" could not be read or written (Error code -36). The drive will remain mounted, however I can not browse the drive, nor can I eject it (it say's it's use by something). If I re-seate the cable, it will mount again just fine and I can resume browsing the contents of the drive. This only happens when connected via eSATA, it does not occur when I have the same drive plugged to the USB port. Using a different 750GB drive in a "roll your own" eSATA/USB2 combo case connected via eSATA works fine. The same copy works fine in Tiger in all scenarios. So... a compatibility issue between Leopard/Sonnet and the Seagate drive perhaps?
So, what's going on here? Is FireWire a bit dodgier than the advertising would have us believe, or does Leopard introduce a software problem that makes FireWire hardware (and perhaps some eSATA hardware) less reliable than under previous systems? From the evidence, one is tempted to conclude: Maybe both.
Resources