[Phoenix32]

Originally Posted by otoc

Thanks. This is getting interesting.

LOL, well, it was 6 months ago at least when we covered this before. But a second look never hurts...

Originally Posted by otoc

So far the hacked 2000 is functioning fine with the 80 cond cable using M/S and not C/S. It's rebuilding the Raid 5 array after I took a drive off line to see if it recognized a single drive failure or a total loss of the 2 drives on that channel.

Sometimes it will, sometimes it won't. It is the "sometimes it won't" part that is the problem. Keep going, you'll see...

Originally Posted by otoc

I'm not convinced that this hacked 2000 will operate with the security I expect and I'm going to pull the master off a channel to see if the proper process is repeated without error again.

While I do not recommend the hack to anyone (it's risky and you could end up with a doorstop), -IF- you get it operating as a 4000 and identifying itself as a 4000, then you should get the security of a 4000.

Originally Posted by otoc

The issues I've seen referenced and what I'm looking for (loss of full channel in M/S, ability to C/S, ATA 100/133 compatability) may be drive related or cable related:

40 and 80 cond Cables should be interchangable with the 80 preferred for signal integrity and ability to C/s out of the box,

http://www.pcguide.com/ref/hdd/if/ide/conf_CS.htm

The issues are more controller related than cable or drive, but all three play their part in this.

The material you posed is correct, but the problem here is you are only working from a few tidbits of information from a subject. This subject (PATA interfacing) is a lot more complex than just a couple paragraphs of information.

As David already pointed out, this is about an IDE controller from a time period before 80 conductor cables and ATA100/133 interfacing. In this case, the controller is not designed for 80 conductor cables, and thus will do little if anything good for you.

The problem here is about what happens when a drive fails on a PATA channel when in M/S mode with this particular controller and software, and how this controller handles C/S mode. When in M/S mode, this controller has a bad habit of failing both drives if one fails in this configuration of software/firmware. The remedy for this situation is to use C/S mode. The problem is, now with the controller and the drives. When in C/S mode, some drives do not downshift as required, and the controller does not work with all drives in C/S mode without the proper cable modification for C/S mode.

Thus, the overall remedy is to use C/S mode with cables prepared for that operation and drives that will downshift properly (or can be manualy set).

Originally Posted by otoc

If this configuration passes the test with my old drives, my next step is to test with new faster, bigger ones and see if the M/S still works and if not, if C/S works or if the drives need to be forced to step down their transfer rates.

Any thoughts as I test this out will be greatly appreciated.

Well, been there, done that... I did all of this months ago, but if you want to spend the hundreds of hours required to redo it all, go for it. A second backup of the testing is always nice to have around. BUT, it has already been done and proved, so your call. Be sure to;

1) Use drives from different manufacturers
2) Use drives of different sizes (say 30 GB to 250 GB)
3) Use M/S and C/S modes
4) with and without C/S cables
5) Power the unit on and off several times and in several methods each test
6) All the various combinations of the above

This is what I did with 3 different brand drives, in 3 different sizes (30, 120, 250), with 2 sets of cables, and tested on a revision-001 and verified on a -004. It took about 20 hours a day for about 3 weeks (7 days a week) to complete.