PC Hoarder Patrol wrote on 2022-01-31, 06:42:

Kampfkoloss wrote on 2022-01-30, 19:18:

Is it still possible this area is broken, when the drive is being detected again be the mainboard and the promise controller's bios? If so, I think it wouldn't be reliable as a system disk anymore.

I'd suggest you try running WDs Data Lifeguard Diagnostics / Tools from DOS to check on the drives health - https://web.archive.org/web/20050413004116/ht … downloadxml.asp

This won't work however, if the Drive is not seen in BIOS... Thanks for the suggestion anyway 😀

rasz_pl wrote on 2022-01-31, 05:40:

No, hyoenmadan post would only make sense if drive stopped working altogether, or was working intermittently. Working in USB enc […]
Show full quote

Kampfkoloss wrote on 2022-01-30, 19:18:

hyoenmadan wrote on 2022-01-30, 00:59:

Your drive "service area" cylinder got corrupted. You may give on it, as the only reliable way to fix this is rebuilding the SA with some specialized HDD analysis software like the ACELabs PC3000 (yes, you have to rebuild it, a simple copy from a donor will destroy the drive), and then reuploading the rebuilt cylinder dump to its corresponding place. And yeah, you may hope the SA doesn't contain bad sectors, or then all this still will not work.

Is it still possible this area is broken, when the drive is being detected again be the mainboard and the promise controller's bios? If so, I think it wouldn't be reliable as a system disk anymore.

No, hyoenmadan post would only make sense if drive stopped working altogether, or was working intermittently. Working in USB enclosure is a clear sign drive is ok, but there is problem with detection. Detecting IDE drives is a mess because for historical reasons. You often couldnt even use more than one drive from different manufacturer on same cable back in early nineties

http://www.os2museum.com/wp/the-dual-drive-ide-hell/
>To behave correctly, Device 0 has to act differently depending on whether Device 1 is present; if Device 1 is present, Device 0 has to let it respond to register accesses directed to it, but if there is no Device 1, then Device 0 has to respond to simulate a two-drive controller with no second drive attached.

USB enclosure doesnt care and doesnt even try accessing second device, therefore bypasses all potential problems.

hyoenmadan wrote on 2022-01-30, 21:23:

Yes, is possible if the SA has weak bits...
There is also a possibility on the head amplifiers being on their last.

A lot of things are possible. This drive could be possessed by ghosts, developed AI, or contain contents of whole Library of Congress. What makes you think its storage mechanism is defective?

Thanks for the history lesson! That sounds really messy 😁

What about my suspicion of a resource conflict? I'll try again with less cards in the system and drive hooked up to MoBo directly and post the results. Thanks for bearing with me 😀

hyoenmadan wrote on 2022-02-01, 02:38:

rasz_pl wrote on 2022-01-31, 05:40:

A lot of things are possible. This drive could be possessed by ghosts, developed AI, or contain contents of whole Library of Congress. What makes you think its storage mechanism is defective?

Experience with the WD4xx and WD8xx drive series. Back then was noted the erratic behavior described by OP, and this detail about being recognized only on certain USB enclosures (back then were trascend usb ide bridges the best ones for the work) and apparently working well with them for some time, until the platter data wasn't longer accessible (on BIOS you would see a 10MB or 0MB drive, with the drive internal "nickname" as drive identifier string, and a random generated serial number). Autopsy on these drives revealed one physical cause (dead head amplifier chips), and multiple software causes (SA data corrupted (common with certain nvidia, ALi, and the dreaded VIA KT133 chipset), or SA weak bits (which in turn was a sign something was wrong with the head amplifier chip).

That's some interesting info there. When working (and not freezing the entire system) the drive is seen with full capacity (38k... MB) but with internal nickname (serial no thingie). So an internal defect is still on the table...

Update for everybody still interested: Drive is working again with full capacity (38.45...something MB). Either BIOS autodetect or detection by Promise BIOS, setting up partitions, formating and scanning with scandisk went through without any issue and quickly. What I did was set the jumper to neutral/single position as shown in PDF, removed the via usb2 controller and booted up the system. No lockup, no detection issue.

Case closed I think?