This situation makes absolutely no sense, and there's all sorts of confusion being induced here by other people and even yourself. Let's start over with some hard facts:
- The Asus P8P67 Deluxe board has 3 SATA controllers on it, all of which serve completely different purposes:
* Intel P67 Southbridge: 2 SATA-600 ports (gray colour)
* Intel P67 Southbridge: 4 SATA-300 ports (blue colour)
* Marvell 9128: 2 SATA-600 ports (navy blue colour)
* JMicron JMB362: 2 SATA-300 ports, eSATA only, and one of those ports is labelled "Power eSATA" (I have absolutely no idea what that means)
- The JMicron JMB362 controller does not use the Intel iaStor.sys drivers. It uses its own drivers.
- Intel iaStor.sys is what's used if the Intel P67 is configured for RAID mode or AHCI mode. RAID mode uses AHCI, but not the other way around. Which mode you're in is controlled by the system/PC BIOS.
- If you went into the Intel controller Option ROM ("BIOS") and started configuring drives in a RAID 1 array there, then that isn't "hardware RAID 1" at all, that's BIOS-level RAID and would also need iaStor.sys.
So, what operating mode for the Intel controller is your PC/system BIOS set to?
- You're stating you're seeing errors in ioStor.sys, which would indicate something hooked up to the Intel ports -- none of which offer eSATA capability. Keep reading before answering this however.
- Generally speaking the JMicron controllers are quite crummy, and that includes their driver set. If you have a choice between Intel and JMicron, go with Intel. If you have a choice between Marvell and Intel, go with Intel. If you have a choice between Marvell and JMicron, go with Marvell.
- Regarding Intel drivers: if you're using AHCI or RAID mode only: if you're using the drivers referred to as "Intel Storage Matrix Manager" or "Intel MatrixRAID", please stop and use Intel's Rapid Storage Technology drivers instead. Intel has renamed the driver numerous times, as well as the BIOS-level RAID feature itself numerous times -- no I am not happy about that -- and the non-RST driver is known to have serious problems (other forum users can confirm that, as can Intel's own forums). Random I/O problems and weird errors are the #1 cause.
You should almost certainly be using the driver from Intel's site and not whatever Asus provides. Period.
- You state you're using a Startech hardware RAID enclosure, whose RAID mode is controlled by DIP switches on the back of the enclosure.
This means the RAID capability is controlled absolutely 100% by the drive itself -- no drivers are needed for such an enclosure, as far as I know. By "no drivers" I mean "no Startech drivers" -- the drive itself does cheap RAID-1.
Given that the enclosure is hooked up via eSATA, and the only eSATA ports on the system are provided via the JMicron controller, you shouldn't be seeing errors in ioStor.sys unless something hooked up to the on-board Intel SATA ports is having issues (e.g. your main OS drive). Since you didn't provide a full topology diagram of what's connected to what (disk to SATA connector), we have no idea what could be going on. Keep reading.
- Is your Startech enclosure powered from an AC adapter or is it powered via eSATA natively?
- Be aware that external enclosures like that Startech drive use what I call "vendor lock-in". If the enclosure has problems, goes belly-up, or has issues, your data is basically lost (unless you do regular backups). Replacing the enclosure (but keeping the disks) will not guarantee you can regain access to your data. It's 100% proprietary. I tend to recommend avoiding these sorts of devices.
- How long is your eSATA cable, and what exactly is it connected to (similar to the question above)? Measure the cable for starters and provide its length here.
- Is the eSATA cable connected to the actual eSATA port on the motherboard backplane (that hooks up to the JMicron controller), or are you using
something like this to hook it to the Intel ports? If the latter: stop using that bracket immediately, as it's almost certainly the cause of your problems. These brackets are known to cause CRC errors, drives falling off the bus, and all *sorts* of other problems. They violate SATA specification, and in addition often cause the maximum eSATA cable length to be exceeded.
- The issue may only manifest itself when using eSATA, in worst-case situation, given the immense speed difference between USB 2.0 and eSATA. I've known tons and tons of people who have total success with USB while see weird timeouts and drive issues with eSATA, simply because the added bandwidth/throughput puts stress on literally everything involved (much more than USB does). Meaning: the Startech enclosure you bought could, simply put, be a piece of junk and not able to actually handle high-end throughput that eSATA offers (this would be caused by a low-end/crummy SATA controller that's inside of the enclosure itself). There's literally nothing you can do about this situation other than buy a different product. Lots of enclosures on the market are crap -- they do things like use USB-to-SATA adapters (e.g. not even a dedicated SATA chip!) or they do wonky things like use eSATA-to-SATA adapter brackets (see above). It's hard to say without seeing the actual internals.
And don't dismiss the possibility of the enclosure simply having hardware/manufacturing defects. That's just as likely as everything else.
- There's also the possibility that one of your drives inside of the enclosure has problems that the enclosure itself cannot detect. This is incredibly common. With such enclosures you lose visibility to determine what's wrong with the disk (e.g. you lose the ability to monitor the disks via SMART, or run SMART tests or block scans on the drives). You literally put all of your data, its integrity, and lots of faith into the enclosure to do everything "magically". The lack of visibility is why I do not use such devices and instead invest in desktop chassis which provide a native hot-swap SATA backplanes and drive bays, connected directly via internal SATA cabling to the on-board SATA controller. The OS sees the disks individually, etc. and can therefore speak SMART to them directly -- therefore retaining the ability to monitor the disks themselves.
I think that does it for my questions and comments. Without all the answers it will be very difficult to help you.
)
