One of my PCs includes a Serial ATA (SATA) controller (Silicon Image SiI3112A SATALink – BIOS v4.2.83 and 32-bit Windows driver v18.104.22.168) together with a Seagate ST3500641AS (500GB SATA) disk. Both these devices were added in preparation for installing Windows Home Server (so I haven’t tried them with any other operating system, although I suspect the results would be similar) and I’ve been having trouble with the system’s stability – suffering occasional crashes (sometimes followed by an inability to find the disk) and frequently seeing the following errors in the event log:
Event Type: Error
Event Source: si3112
Event Category: None
Event ID: 9
The device, \Device\Scsi\si31121, did not respond within the timeout period.
Event Type: Error
Event Source: Disk
Event Category: None
Event ID: 11
The driver detected a controller error on \Device\Harddisk0.
The first message doesn’t mean much but following the link from Event Viewer to the Windows Help and Support Center indicated that the disk event ID 11 means IO_ERR_CONTROLLER_ERROR and can be caused by a loose cable. The controller card (bought last week) was supplied with a power cable but not an interface (data) cable, so I bought one at Maplin for Â£4.99. When I got home I found that the data cable connector housing made the connection too tight against the power cable, making it a slightly incorrect fit (although probably good enough). Armed with this new advice, I set off to buy another cable – this time for Â£2.99 from a local computer services company… a perfect fit, with a latching connection and less expensive (that’s why it pays to shop locally!). Unfortunately though, this new cable didn’t resolve my disk errors.
Googling the error messages hadn’t turned up much; however searching for the disk model number told me that my disk is actually 3Gbps-capable and that, even though SATA/300 devices should be compatible with SATA/150 controllers, there can be issues with legacy controllers when a technology called spread spectrum clocking (SSC) is enabled. Seagate supplies a utility to enable/disable SSC on their SATA drives bit it won’t run under Windows, so I created an MS-DOS 6.22 boot floppy disk (thanks to bootdisk.com) and ran the utility from MS-DOS. As it happens, SSC was already disabled on my disk but it was worth checking out. Another potential issue is the autonegotiation between SATA/300 and SATA/150 and, following the Seagate SATA troubleshooter, I found this advice:
“Some older 1.5Gbits/sec SATA cards do not support auto negotiation with newer 3.0Gbits/sec drives… Seagate Barracuda 3.0Gbit/sec drives can be forced to 1.5Gbits/sec to allow support with these older SATA cards.
To force the Seagate Barracuda 7200.9 drive to 1.5Gbits/sec mode, apply a jumper to the outer most pins of the jumper block…
This jumper block uses a 2mm jumper. This is the smaller of the standard jumper sizes.”
After digging around in my “box of PC bits and bobs”, I found a suitable jumper and applied it; however I followed the diagram in Seagate knowledge base article 2850 (which relates to certain Maxtor SATA drives):
Instead of this, subtley different one (which I found afterwards in the ST3500641AS Product Manual):
After having applied the jumper to the wrong pins, there were no more disk event ID 11 errors and, as it seems that those pins are for factory use only, I have no idea what they meant; however, after a few hours, I saw the si3112 event ID 9 errors return, so I decided to switch the jumper to the location in the second diagram. I won’t go into the details of what heppened next, suffice to say it resulted in a blue screen of death, followed by a hard disk that no longer spun up and a warranty call… oops!
After receiving a replacement disk, I rebuilt the system (without any jumpers on the hard drive) and confirmed that the errors still occurred with a new disk (ruling out a faulty component as the cause). Then, I shut down the system (always a good idea before performing hardware maintenance) and fitted the jumper to the outermost two pins. Since powering on the computer, there have been no errors, so (fingers crossed), it looks as though the problem was down to a SATA/300 drive and a SATA/150 controller.
I’ve since come across a low-cost SATA controller with an eSATA port, based on a VIA VT6421A chipset (which could actually provide me with some more flexibility – and I can still return the first controller for a refund); however, having got a working driver and hardware combination, I’m reluctant to switch to another chipset (and another set of problems)… maybe that’s something to consider if I experience any more problems later.