Hacked my hacked 2000>4000:fixed with question
 

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?

Re: Hacked my hacked 2000>4000:fixed with question
 

Sure...

Re: Hacked my hacked 2000>4000:fixed with question
 

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?

Re: Hacked my hacked 2000>4000:fixed with question
 

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.

Re: Hacked my hacked 2000>4000:fixed with question
 

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
Drive related issues with our older chipset (same source as above):
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.

Re: Hacked my hacked 2000>4000:fixed with question
 

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.

Re: Hacked my hacked 2000>4000:fixed with question
 

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



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

Re: Hacked my hacked 2000>4000:fixed with question
 

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

Re: Hacked my hacked 2000>4000:fixed with question
 

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


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


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.


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


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.

Re: Hacked my hacked 2000>4000:fixed with question
 

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

Re: Hacked my hacked 2000>4000:fixed with question
 

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.

Hacked 2000>4000:continues...
 

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.

http://home.comcast.net/~otoc/display/snap224000.jpg

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 :doh:

Re: Hacked my hacked 2000>4000:fixed with question
 

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.