Hacked my hacked 2000>4000:fixed with question

[otoc]

I've been playing around with a 2000 (ser# 38XXX hardware version 2.0) for a while now configured as a 4000.

Operating system was 3.4803 with the drives set up as M/S (mix of 40GB quantum, IBM, Maxtors of different vintages). Yeah, I know, this was just a test.

Memory boosted to 128MB, standard IDE cables, external ATX power supply for drive cage and cooling fans controlled by relay powered by the snap's 12vt line. Raid 5 was functioning well thoughout 100GB of file transfers over months of trials.

I updated to 4.0855 and again to 4.0860. I lost 2 of the drives and the raid5 array was gone.

After testing all the drives with the manufacturer's utilities and finding no problems I thought about how I hacked the 2000 into a 4000 in the first place. I only changed the model number in the bios to 2 (4 drives).

So I changed the PlatformBytes from 2.0.0 (2000) to 2.0.1 (4000) and rebooted with the array intact and functioning.

If you're hacking a 2000 into a 4000 and update from V3 to V4 watch out for the PlatformBytes.


Now the questions. I've read in several threads that there is a mod for the drive cable to allow C/S on my old hardware version. I can't find it anywhere by searching. Could someone fill me in on the process? I'd really like to keep this running as a Raid5 but I know what happens if a drive really fails with M/S.

Think I really need to have Hardware version 2.0.1?

[Phoenix32]

Sure...

[otoc]

Thanks. What's the story with 80 wire 40 pins? They should detect c/s without a mod. Is the thought that 80 wires are not compatible?

I've been running the 80 cables with M/S, btw.

Was the "sure" for the photo or the question about hardware 2.0.1?

[blue68f100]

The IDE controller on the old units do not use/support 80 cond. The IDE controller chips are to old. Remember these were design when 8 gig was considered massive, 1998-99. The reason we discovered some drives did not play well with them, EIDE issues.

Phoenix is our hardware expert, he may shine some more light on the subject.

Platformbytes are used for software upgerades. Once you change it you need to re-install the software to get every thing required for your hardware.

[otoc]

Originally Posted by blue68f100

The IDE controller on the old units do not use/support 80 cond. The IDE controller chips are to old. Remember these were design when 8 gig was considered massive, 1998-99. The reason we discovered some drives did not play well with them, EIDE issues.

Phoenix is our hardware expert, he may shine some more light on the subject.

Platformbytes are used for software upgerades. Once you change it you need to re-install the software to get every thing required for your hardware.

Thanks. This is getting interesting.

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.

Then thing of note is that the update to V4 killed the visibility of the slave drives that were functioning fine with the V3 software and the 80 cond cables with these old mismatched drives.

Changing the PlatformBytes to match a real 4000 brought the slaves back into the picture. No software update was done, though I have since reapplied the latest V4 I have.

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.

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

Warning: 80-conductor IDE/ATA cables are often said to be compatible with 40-conductor cables. That's true of normal 40-conductor cables with drives jumpered as master and slave, but not cable select cables. If you swap a regular (non-"Y-shaped") 40-conductor cable select cable with an 80-conductor IDE cable, the master and slave drives will swap logical positions. If you don't want that to happen, you'll need to change the order that the devices connect to the cable.

Drive related issues with our older chipset (same source as above):

On new systems there are few issues with running Ultra DMA, because the hardware is all new and designed to run in Ultra DMA mode. With older systems, things are a bit more complex. In theory, new drives should be backwards compatible with older controllers, and putting an Ultra DMA drive on an older PC should cause it to automatically run in a slower mode, such as PIO mode 4. Unfortunately, certain motherboards don't function well when an Ultra DMA drive is connected, and this may result in lockups or errors. A BIOS upgrade from the motherboard manufacturer is a good idea, if you are able to do this. Otherwise, you may need to use a special Ultra DMA software utility (available from the drive manufacturer) to tell the hard disk not to try to run in Ultra DMA mode. The same utility can be used to enable Ultra DMA mode on a drive that is set not to use it. You should use the utility specific to whatever make of drive you have.

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.

[blue68f100]

There are 2 4000 motherboards. 1 is the same used in a 2000, the other has a different PN.

As long as you test by failing drives. Power cycles while drive is failed, do not skip the one. Verify that it has reported the HD failure, and is running in degraded mode. If it will go into panic mode it did not like it.

These units DO NOT SUPPORT HOT SWAPING, so you must power down to replace the drive.

Phoenix is our resident hardware man. He did extensive testing in this area. What ever he says goes. So if you have something that is different you may not have found where it had the problem. He did not just fail a singel drive he tested by failing ALL, one at a time. Yes very time consuming, due to re-sync's. But it is the only proper way to test. Because he did discover if you failed some drives every thing worked, till you failed 1 specific position.

Maxtor were the drives that had EIDE problems. But who would want to use a HD's that has the highest failure rate in the industry for critical data.

[Phoenix32]

Originally Posted by otoc

What's the story with 80 wire 40 pins? They should detect c/s without a mod. Is the thought that 80 wires are not compatible?

You answered your own question here later in the thread...

Originally Posted by otoc

Was the "sure" for the photo or the question about hardware 2.0.1?

Originally Posted by otoc

Could someone fill me in on the process?

Originally Posted by Phoenix32

Sure...

Yes, someone can fill you in on the process...

[Phoenix32]

Originally Posted by blue68f100

Phoenix is our hardware expert, he may shine some more light on the subject.

Thank you blue68f100. I covered this subject at length a while back in another thread, but I will try to give the basics here...

[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.

[Phoenix32]

Originally Posted by blue68f100

There are 2 4000 motherboards. 1 is the same used in a 2000, the other has a different PN.

As long as you test by failing drives. Power cycles while drive is failed, do not skip the one. Verify that it has reported the HD failure, and is running in degraded mode. If it will go into panic mode it did not like it.

These units DO NOT SUPPORT HOT SWAPING, so you must power down to replace the drive.

Phoenix is our resident hardware man. He did extensive testing in this area. What ever he says goes. So if you have something that is different you may not have found where it had the problem. He did not just fail a singel drive he tested by failing ALL, one at a time. Yes very time consuming, due to re-sync's. But it is the only proper way to test. Because he did discover if you failed some drives every thing worked, till you failed 1 specific position.

Maxtor were the drives that had EIDE problems. But who would want to use a HD's that has the highest failure rate in the industry for critical data.

Correct, with one exception. The drives I had EIDE issues with were the Seagates. I did not use any Maxtors for the testing at all. The Seagate drives, at least the models I was using, had drive interface issues with C/S and proper adjustment to the controller.

Before someone says it is just the controller. NO! I have had this same issue with Seagates on a Motherboard with an Intel i875 chipset and updated BIOS etc in C/S. When running various utilities, they like to lock up, throw errors, and cause random problems (they are flakey at best).

[otoc]

Thanks to both for your input. The tests are progressing nicely.

I'll respond with more depth later in the week. My apologies, I have company visiting.

Just so you guys know, I didn't base my cabling thoughts on a few paragraphs, nor have I just jumped into this. My 2000 has been operating as a 4000 since 2005 according to my logs. I have much respect for the contributions made here on the forums, have followed intently since Joe's first post, and have a systems integration- project/program management background. My intent is only to give back to the knowledge base here that I have taken from.

Initial findings are:
Software version change from 3 to 4 made the need for PlatformBytes to be set for the model. Once that was done, V4 correctly identified all drives without issue and the raid5 array was intact.

80 conductor running as M/S does in fact work on V4 with this 2000 and these older drives.

I've taken out 3 drives so far, (pulling the power plug on the drive when shut down, lol) starting up, finding the Raid 5 operating in degraded mode, bringing the broken drive back on line, finding it correctly identified as an orphan (by correct drive number), formating the drive, and setting it up as a spare. So far all data has been intact, and transfers without error to and from macs, PCs, and other snaps.

I'm rebuilding the 3rd trial "failure" right now. If this continues, I'll get some WD 250's that I can manually set the drive speed on and take it to the next level of testing.

[otoc]

All trials with the old drives came out fine.

PATA 80 conductor with drives set as M/S.

Never did I see a problem with the OS recognizing a failed drive, nor was there a problem in bringing the orphan back as a spare. Nor have there been any issues in file transfers to and from the hacked snap 2000 from PCs, Macs, and other snaps.

The new WD 250's came in and are now building into a Raid 5. Thanks for the heads up on the 1TB issues. The 700GB Raid 5 will be fine.

IDE cable
My opinion about the issue of 80 vs 40 is that the 80 was designed to be backward compatible and is preferred for reasons of signal integrity over the 40. The chipset in the 2000/4000, which is capable of UDMA 33 (still trying to find a debug command that shows the pci setting) is not going to be bothered by the additional ground wires as the pin outs are the same.

What is different is the "special" cable in the 4000's, which is nothing more than a standard 40 conductor cable sense ribbon. These CS 40s put the master at the middle and the slave at the end when the drive is in CS mode. The 80 conductor puts the master at the end when in CS. I imagine this would cause the OS to loose track of the array since the drive numbering routine is based on primary/secondary- master slave designations as set by the hard drive if a cable swap was made without taking the cable drive placement into consideration.

2000/4000 Drive config
Primary master-drive 1 (drive slot 0)
Primary slave-drive 2 (drive slot 1)
Secondary master-drive 3 (drive slot 2)
Secondary slave- drive 4 (drive slot 3)

The cable is overridden by the drive when in M/S and it is the drive that communicates with the chipset via the bios (which we don't really know about even with its FreeBSD base).

In my case with the hacked 2000, I saw a change in how the OS/bios read slaves when the hardware was still set at 2.0.0 (no slaves seen after the upgrade). When I upgraded to the version 4 snap os both master and slave were seen. Version 3 only needed the model change to work as a 4000 with 4 drives.

Aside from drive firmware issues or cables that don't introduce interference, there's power and heat issues for drives when hacking the 2000. Lot's of variables can cause the system from not working correctly.

Here's my setup. It's not pretty, but it functions fine it seems, so far.



256MB ram, shielded 80 conductor PATA cables, drives set as master and slave by jumpers, fan cooling and external power for the drives controlled by a relay pulling off of the snap 12 volt line.

Round 2 of testing to begin once the raid builds with these WD 250s. Let's hope my little home server continues acting like a champ. But we all know what hacking can bring: wasted time and doorstops

[otoc]

Just a quick update as the system has been online for sometime now...

This config has been running fine with no issues after doing a verification of whether or not a disconnected drive (all 4 drives pulled one at a time with a successful Raid 5 rebuild done when the missing drive was reconnected).

I've synced the data from 5 other snap 2000s with no issue.

This is not a bad alternative to upgrading to a 4000 series in order to get Raid5. It's as slow as anyone would expect, but Raid5 breathes new life into the Snap 2000 hardware.