HDAT2 forum

Hello from Detroit, MI, U.S.A. suburb!

FIrst off, your little toy is pretty cool. Thank you for the heartbeats you've put intio it. I"ve spent 1 1/2 weeks investigating, diagnosiing & researching this problem. At this point I believe I'm sufficieently qualified to ask a qwexion (or two) and most likely even understand the answer given. My problem is part of the reason why I failed to pass VB, VBScript, JavaScript & C++ at the local college.

I passed Java with a 3.0 prior to all of my problems (so stupidity is not the problem). Prior to then I was a structured/sequential application programmer developing Business BASIC applications in various Unix environments. Without any doubt, you should understand that all of this hardware stuff is quite cryptic; I muddle through it though. The last twelve months has taught me so much about the intraciies & nuances of WinXP Pro installation / configuration I can't even begin to tell you how valuable this experience has been. I keep a NotePad with all the things I discover so that if I ever have to reinstall from "scratch" I iknow how to get to the goal the quickest.

I have two refurbished Fujitsu SCSI drives, i.e., MAN3367 and I believe to be a MAN3735 (???). They show as ModusLnk in WInXP Pro SP3 device manager. This is what HDAT2 v4.53 shows also in the details. The lables on the HDD are either Qualitas or WorldDisk (or perhaps both).

Anyways, my problem is that Norton Ghost image application results in FAT mismatch when the image from HDD to HDD is made. Norton Disk Doc resolves such FAT mismatch. The mismatch resolved is ALWAYS in FAT1. When I perdform integrity check on Norton Ghost image (Ghost 2003 version), CRC errors are revealed. The verification would otherwise abort if but for setting "ignore" CRC error. Norton Ghost Explorer will NOT restore files I.D.'d as being corrupt on Ghost image.

[placeholder for paragraph deleted - 08 09 28 0700 GMT - due to even MORE irrelevancy than the 3rd paragraph]

Anywys, I discovered your wonderful program (and apparently work in progress) that has caused me some consternation concerning diagnosis of my problem.

I've run all the tests on the HDD's multiple times. There are NO bad sectors to be found; neither in HDAT2 v4.53 or SCSI EzSelect application (ctrl-A).

D: is my ARCHIIVE HDD for Ghost image & other archiveal purposes. D: is the primary boot partition (36GB) of the SECOND HDD (what I believe to be a MAN3735 - 73GB - HDD). D: was partiioned & formatted within WinXP Pro SP2. This drive is configured as SCSI ID 5. C: is the primary boot partition of SCSI ID 6.

My Asus P3V4X BIOS (1006 v4) is configured to boot from SCSI (primary: floopy, secondary: CD-ROM). My CPU is PIII 1000 SEC, and I have 3x256 PC133 ECC SDRAM (Crucial). Sys / Mem ratio is 3/4, and SDRAM is configured SPD.

When I run HDAT v4.53 tests, no test results in erros except: R/W/R/C. Then I get about 100 erorrs over 36GB on D:. Extensive MemTestest v3.3 reveals NO errors whatsoever. HDAT v4.53 R/R/C reveals not errors whatsoever.

When I do the file check I get the following:

End of cylinder partition = 1023 but actual is 4142 (FDISK w/large drive over 1024 cylinder)

# of reserved sectors = 36 but typically 32

last known free cluster cont unknown

FAT[1] EOC mark = FFFFFFFF (should be 0FFFFFFF

bad checksum DIR:

windows~1.exe/WindowsXP_SP3.exe
ServicePackFiles
ntservicepackuninstall

Now, when I scan SCSI ID 6 (C:), I come up with other issues. Its complaining 'bout partition chaining and other things similar to above.

Furthermore, there are several DIR entries on both drives with illegal / bad checksum entries. I've expended many heartbeats trying to fix just THAT (to no avail). I established the remaining space on SCSI ID 5 as an extended partition and created a logical drive in that partion (H:) and tried copying the bad CRC DIR endtries from D: to H: (sasme HDD) and re-ran HDAT v4.53. Both partions on SCSCI ID 6 (D: & H: had the same bad DIR CRC entries). I've tried to FDISK /MBR from Win98SE boot floopy to no avail.

I have a suspicion that my problem may be related to SCSI termination. BOTH HDD's have SCA connectors. I've been using an AHA-2940U/W with a SCA 68 to 80 pin adapter as stub connection for each HDD (I have two). Termination is esablished auto at the host. Both SCSI devices are on the internal bus (there is no external bus). The host is the one ond of the buss.

The HDD at the extent of the bus had an SCA with a TERM PWR jumper. I thought that was the TERMINATION jumper. I understand now that it is not and that by having it set I probably messed things up.

Feel free to jump in here at any time. The WinXP Pro SP3 portion of my box runs fiine (unless I get a power failure). I can copy GB of files around and delete them and there is NO FAT table mismatch. But whenever I try to do the same with in113h routed through Aspi8Dos.Sys at DOS 7.0 level I get issues (predominantly FAT mistmatches & CRC erros in Ghost images). As far as I can tell, there's ONE Aspi8Dos.Sys and that's pretty much it; I've utilized all the different copies I have.

So this brings me to my qwexion:

Did I screew up my HDD's by running them for as long as I did w/out proper termination?

I'll tell you this: most of the time ARCHIVE (SCSI 5) should be sitting there doing NOTING); I have the drives configured to spin down after 30 min. inactivity. So I don't konw if SCSI bus "reflection" will kill the spon-down drive or not. If anything, lack of prope4r terminatikon should kill the "root" drive in my case? However, HDAT2 shows that R/W/R/C results in just about every OTHER "block" failing (a BLOCK being defined in accordance to how HDAT2 sees the media).

And what 'bout those cylinder errors in File System MBR read. I tried FDISK /MBR at the command prompt with first one and then the other HDD removed from the SCSI bus.

Of course, hopefully, if my bus isn't terminated correctly none of that will work according to spec will it? I pray that you won't have to tell me that I could've messed up the drive's controllers because of my lack of termination comprehension.

Hello,

so it is a long post...

1. All file system tests are for informative purpose only.

E.g. There are not any exactly defined rules, guidelines etc.
of all correct contents of master boot record (MBR) etc.
Yes, for file system FAT I made all checks according to
MS White Paper FAT32 File System Specification (fatgen103.pdf)
and any available information (DOS/Windows/Unix).

So if you see message

"End of cylinder partition = 1023 but actual is 4142
(FDISK with large drive over 1024 cylinder)"

- in MBR you can store 1023 cylinder only
- the number 4142 is number of cylinders of physical geometry of hard drive
(too many 'of'...)
- you have used FDISK which supported large drive over 1024 cylinder
I mean this is "information" only, not error.
The same is for EOC mark (see fatgen103.pdf on Google).

2. Bad checksum DIR:
Sorry, I found a bug in program, it was removed in beta version 4.6b2.

3. I suppose that you have FAT32 on your hard drive.
The reason for your problems with FAT mismatch could be
- bad sector (you said there is not)
- first copy of FAT is different from second copy of FAT
you can run SCANDISK from WIN98 to correct that (or test FAT only)

4. SCSI termination: this is very important for data transmission.
The SCSI bus must have termination power for clean data transmission.
Data will be dropped, and some SCSI devices won't be visible to the system.

The rule about terminators is this:
All SCSI busses must be terminated at both ends and nowhere else.

Without termination the reflected signals will interfere with
the "real" data on the bus and cause signal loss and data corruption.
It could be another reason for your bad FAT (CRC error) also.
Finally, the problem could be with cabling, termination or other hardware issue.

Good BIOS should show a warming message about bad termination.
E.g. SCSI BIOS Error: "SCSI Termination NOT FOUND".

Termination cannot screw up your drive on HW level, only on SW (data) level.

SCSI Termination Tutorial
http://www.scsita.org/aboutscsi/SCSI_Te ... orial.html

I hope you got all answers.
I am sorry, my english is poor...

[edit: 081001 0500 UDT to correcttion applied to immediatly following paragraph, i.e., incorrect usage of the contraction You're when it should read Your. My bad.]

Nope, did not get all the answers from you, but that's o.k. Your English is MUCH better than my German. When I came to the U.S.A. when I was 5, I knew only German. I'm very embarrassed to admit that at 46 yoa any second or third grader can speak, read and write better than this naturalized U.S. citzen former German foreign national.

Anyways, I JUST fingered out what my problem has been. And I am SO happy with both my success AND your nifty tool.

It was either [ (delayed transaction) AND (PCI to DRAM prefetch) ] OR [ (delayed transaction) OR (PCI to DRAM prefetch) ].



Those are settings in the motherboard BIOS. And yes the above is a complicated Boolean "OR" truth value. I don't care which ONE it may be, or if it IS both, all I know is that my machine (and hard drives) are working FLAWLESSLY now. I am SO happy. In fact I am ecstatic.

The problem continued even after I replaced the SCA card for the HDD at the end of the SCSI bus with a LVD active terminating SCA card.



The major clue to the source of the problem was revealed by meditating on the results obtained of experiments I performed with Norton (a Symantec brand) Ghost. Through the use of the -CRC32 switch, I established that CRC codes of the partition were constant, and that CRC codes from a Ghost image were constant (regardless of repetitions of the expiriment). However, a static partition that was imaged repeatedly showed CRC errors in DIFFERENT files in each successive image

If I compared the one to the other, the results were ALWAYS the same: identical errors between partion to image CRC mismatch, and image CRC to partiion CRC mismatch. Never the same files within an image would be CRC mismatched, and often the files with CRC mismatch would often extract and execute. But sometimes they'd not extract, or if they did, they'd be broken.

Your tool agreed with Norton Disk Doctor (a component of Symantec's Norton System Works), that no bad sectors existed on either HDD. But your tool told me that the RWRC test failed miserably on the COMPARE (never on read nor write), always compare. Futhermore, I could perform defreg in Windows that took HOURS, and no FAT mismatch, or errors in free-space. But making Ghost image in virtual DOS partition caused problems in HDD FAT often, allocation errors, and incorrect free-space errors often, but CRC errors within Ghost image file ALWAYS (each and EVERY time).

Many times in WinXP, EXE installables would crash, or files within good ZIP files would be bad (???). Many times just doing the extract again would fix problems. Sometimes downloading the file a second time would be good enough the first time around.

I ran DocMem & MemTest for hours and hours (never an errors). NEVER. EVER. Problem seemed marginally worser when SCSI write-buffer was enabled after replacing the dead battery in my APC Back-UPS Pro 1400.



DISABLE "delayed transaction" AND "PCI to DRAM prefetch". Ghost image verifies clean, HDAT2 RWRC test shows NO errors across 10GB of 512B sectors when I stopped the test. WHOOO HOOO! Until then, I could never get passed more than several hundred to thousands sectors before RWRC error on compare.

I very much felt compelled to share this with you.

I will pay you $10 or $20 when I can. It may be a year, as I am a student and unemployed, but I WILL pay you for your HDAT tool.

Don't stop working on this tool. Make it better. Make the File System diagnostics work better.

Now, lets see, is that Fujitsu MAM3184MC 18GB 15k HDD REALLY failed, or is only a PORTION of it that is actually bad? Remapping of any bad sectors should fix that, eh? Your tool will help me very much. Now that I know everthing is good to go, I can assess whether or not the drive is junk, or salvageable.

I hope my $10 or $20 one day will make you as happy as I am right now, but I'm sorry to say that they are still far away.

Thank you for your (a little bit) long story

These BIOS options (delayed transaction and PCI to DRAM prefetch) are (maybe) related to SCSI controller card settings.
It could be a faulty cache memory on controller/disk also. It is hard to say exactly what is wrong.

Disabling PCI prefetch buffers also prevents errors with faulty PCI interface chips
that can corrupt data on the hard disk.

Remapping of bad sectors should fix the bad sectors only.

I am working on my tool but it is not easy to find a playtime for that now.
So the work continues very slowly...

Don't worry about money, if you get some you can pay

I'm a stinkin' sequential / structured legacy-programmer after 18 years in the field lost their job in 2000. I've been a student since Fall 2006 learning OOP, i.e., Java, C++ & Visual Basic (not forgetting JavaScript, VBScript & ASP.NET). I'm not a hardware guru , so I don't know for certain how any of the stuff I use works. When I was working, there ALWAYS was a guy to call who dealt with the hardware stuff.

I pray to Jesus that nothing's wrong with my system board. Nevertheless, and that notwithstanding, the ancient brontosaur Asus P3V4x, slot 1 PIIII1000 and 3x256MB PC133 ECC SDRAM, LeadTek GF2 64MB, AHA-2940UW with the aforementioned Fujitsu "refurbished" HDD's, platform running WinXP SP3 that I'm presently using MUST run for another year so I can get my junior college degrees & quals from Sun Systems, etc.

It is my prayer that the new battery in my APC BackUPS Pro 1400, the new SCSI LVD SCA w/active termination and the BIOS settings seemingly attributable to my problems will allow me to complete my junior college degree(s) & quals over the course of the next year.