Help_Seeker

Well, you may be *looking* at the actual problem but not *seeing* it--Mustang has said he had experience with this problem, and if I followed--it was a compatibility issue between the controller and HDD--the OS, per se, had nothing to do with the issue.

WinXP is constantly accessing the HDD while Win98 does not.  WinXP may be using access and I/O's that are different than how Win98 utilizes the HDD and its controller--which might explain why WinXP only has the problem.

As you have stated, the jumper only limits the HDD size, but it does not change the *nature* of the large HDD--the timings, etc. remain the same--so if the controller is the problem, as Mustang suggested--then you still have the variable that has remained constant--just as the problem has!

I doubt its a HDD *brand* problem as much as a HDD communication *standard* that is probably causing some sort of *glitch*. 

I understand you are trying to avoid spending more $, but unless you try a different HDD controller, and/or a different HDD with perhaps reduced operational specs, i.e. smaller size, smaller cache, and/or slower spindle speed,--you are not finding out if the root cause is what Mustang suggested.  Maybe you could get the newer controller card from a source that will let you return it if it proves not to solve the problem--i.e. is not compatible with your system!

Quote:


NightOwl,

Exactly, but with the same controller there was no problem with XP when it was used with the smaller 30gb disk.

Quote:


Remember though, the root of the problem has to be the replacement disk.  My intention was to get the machine running reliably, not to upgrade to a larger (200gb) disk.  I purchased the 200gb only because is was less expensive than any of the smaller drives at the time I bought it, not because I needed 170gb of new disk space.  However, at that time I had no idea what I would be in for regarding large disk support.  In fact, I thought I had the needed support from the Promise Ultra100 or I wouldn't have purchased the disk.  But as it turned out the combination of the Promise Ultra100 and the 200gb does have problems; whereas the combination of the same controller with the 30gb disk didn't have problems.  That's why I say the 200gb disk is the root of the problem.  The controller would only be a problem if I needed the 170gb of extra disk space, but that isn't the case.

My intention right now is to replace the hard disk while keeping the specs as close as possible to the former hard disk.

proposed new disk - Seagate 40gb, 2mb cache, 7200rpm
former disk - Maxtor 30gb, 2mb cache, 7200rpm
problem disk - Seagate 200gb jumpered to 32gb, 8mb cache, 7200rpm

Quote:


I see the controller being the issue with the 200gb disk for the same reasons you listed.  They are the ONLY THINGS that changed in the machine's configuration once the size of the disk (one variable) was eliminated with the jumper.  But I don't see the controller being an issue with a smaller drive, as long as the drive possesses, as you say, the *nature* of the small 30gb HDD I used to have in the machine.

Mustang suggested that I either replace the controller *or* the hard disk (with a smaller one).  I am approaching this from the hard disk side of his suggestion first, for several reasons.  1st, except for 10gb, the proposed disk's specs are virtually identical to the old drive.  That's practically zero variables.  2nd, although #1 should work, I still have the controller to turn to as a last resort.  3rd, I already have a Promise Ultra 133 TX2 in my other machine, but have issues with it when creating backup images with Ghost, issues=equal=variables and I don't want to introduce any more than I already have.

I also don't want to fiddle around with the controller inside my only working machine, because having the extra 178gb of disk space isn't important enough for me to risk the added aggravation of having both pc's down.  And since the highest likelihood for success is putting in a small disk just like the one that used to work, why bother futzing with the controller at all at this point in time.  Furthermore, the 200gb disk wouldn't go to waste gathering dust.  It could possibly be used in my other machine, the one that already has a Promise 133 TX2, but that's something for another day, first things first.  I hope you can see why I'm reluctant to work with the controller first.  That is, the aggravation and/or cost may never be necessary should the smaller drive pan out, and the large drive could still be put to use elsewhere.

For what it's worth, I was about to post here last month about the Ghost issue with the 133 TX2 but then I got sidetracked with the problem I have now.  Perhaps I'll start a new thread about that later, but in the meantime if you know of any good threads about "ultra" warnings appearing in XP's System Event Viewer, but ONLY while creating Ghost images from XP, I'd appreciate you pointing me to them.  I get 62 of those warnings every time I make backups with Ghost, that's the only time I see them.

Now please don't mistake that machine for the one I'm having the more serious problems with, I have NEVER had any Ultra warnings from the Ultra 100 controller.

Quote:


I doubt it's a brand name issue too, but thought I'd ask.  Thanks for reinforcing my suspicions.  I think the proposed Seagate disk matches the old disk's specs well enough to give it a shot.  What do you think?

Just a followup to let you all know the problem has been resolved.  It was not a hardware issue, nor was it entirely a Ghost issue.  However, Ghost did drop the ball when it came to restoring the MBR as well as the boot.ini file.

As it turned out, Ghost changed the ARC path in the boot.ini file on every restoration.  In my opinion, Ghost has no place doing that.  Restore a file, yes; but altering its content is simply not acceptable.  As well, Ghost did not restore the MBR in a manner that allowed Boot Magic to work as it had on the original disk.  While these are additional issues, they were not in and of themselves responsible for the looping progress bar problem.

At the end of the day, what ended up fixing the looping progress bar problem was a defragmentation of both the WXPBOOT partition (which contains XP's boot files), and the WXP partition (which contains XP's OS files).  The defrag operation was performed on the copied version of the partitions, not the partitions on the original disk.  On the original disk XP reported that none of the partitions needed to be defragmented.

These discoveries came about as a result of performing two copy operations from the original hard disk (not performing "restore" operations from backed up image files as had previously been done).  The first copy, using Ghost.  The second, using BING.  Details can be found in this page of my thread at AumHa forums.  Please page down to my post dated 1/4/07 where I continued troubleshooting since last posting here, and referenced this Radified forum thread.

The 200gb disk was put to use as a secondary removable hard disk used for storing backup image files, as well as image (picture) files, and sound files.  It is working fine with the Promise Ultra 100 controller.

I have since transitioned this machine from Ghost to BING, and am doing the same with my other machine.  Given the alarming revelation that Ghost altered the content of at least one restored file, and given the fact that Ghost fell flat on its face restoring the MBR (which by the way was created by another Symantec product, Partition Magic), I no longer have faith in Ghost nor Symantec.

While I have many other reasons to migrate from these two Symantec programs, particularly Ghost, economics is one I couldn't overlook.  With MS Vista looming on the horizon I would likely be looking forward to upgrading Ghost 9 in order to gain Vista support, that would be at least $50 paid to Symantec.  And given that I needed to upgrade to Partition Magic 8 to gain XP support, that's a second Symantec program I would likely have to upgrade as well... another $50.  I have never known Symantec to offer free major upgrades meant to support new MS OS's.  BootIt Next Generation (BING) can do for me what both of those programs do, and it costs only $35, and it's already Vista compatible.  But what I like most about it is that it's completely OS independent.  Unlike Ghost 9, backups can be performed by either running the backup program at boot time from the hard disk, or booting from a floppy disk.

I didn't buy Ghost because of its hot imaging capability, but rather had to contend with it for what I thought would be a clear and simple means to create and restore backup images.  I've never used my pc while imaging is in progress, I'm simply not in that much of a rush to risk compromising the integrity of my backups.  However, I can appreciate why others may have a need for such features.  But for me at least, Ghost's advanced imaging features seemed to unbearably complicate its ability to perform simple restorations.  Not to mention altering file content, and the apparent lack of support for a MBR created by another Symantec program.  In my opinion, Symantec's left hand (Ghost) should at least know what its right hand (Partition Magic/Boot Magic) is doing, especially when both programs are installed on the same computer but lack the handshaking necessary to have Ghost perform an uneventful restoration.