• Please review our updated Terms and Rules here

"General failure reading drive A" persists until reboot

VileR

VileR

Veteran Member
Joined
Jul 21, 2011
Messages
656
Location
Israel
The system is a 5160 (third revision BIOS, XTIDE Universal BIOS v2.0.0b3), with a half-height 5.25" floppy drive and the IBM Diskette Drive Adapter (w/Intel P8272A), running MS-DOS 6.22.

Been reading quite a lot of data off some floppies. Every once in a while, a perfectly good disk would give me a "General failure reading drive A:". No matter what I choose at this prompt - from that point on every attempt to access drive A: will give the same error - the drive light doesn't even light up, it just barfs immediately every time until I warm-boot. *Then*, the same disk will often read just fine.

That only happens with this particular error: I've gotten other critical stops with disks that are actually bad ("Sector not found", "Data error", "Invalid media", and so on so forth) but they behave as you'd expect.

Any ideas? I don't see anything that could cause a DMA or IRQ conflict. It's just an annoyance, since a restart does fix things, but I'd be happier if it stops happening...
 
Unfortunately, "General Failure" is a catchall for several problems. It could be a controller failure or simply a bad boot sector.

Try using a better diagnostic.
 
In the disk dumping utility I wrote -- which uses only INT 13h commands -- I found sometimes that aborting at what I thought was a "clean" place to do so (after a command had finished and returned control) would bork the controller and I had to warm-boot as well to get it back on track. I chalked it up at the time to me doing something wrong, somehow.
 
Well, that's one reason that the 765 features a software reset line. :)

But if you look at the MSDOS code, "General Failure" can come from a variety of places. For example, if the layout of the boot sector doesn't make sense, "General Failure". If the controller hangs, "General Failure"....you get the idea.
 
I know it's not related to the boot sector or anything else about the diskette itself, because it reads fine all the way after a warm boot.

Sounds like the controller *is* hanging, like Trixter describes... although in my case it happens with DOS's own copy/xcopy. Wouldn't be surprised if it's yet another bug introduced with DOS versions past 3.x running on older hardware, like the MODE.COM CGA crash.
 
Can't test with 3.x for now, unfortunately; I only said it wouldn't surprise me ;) (the partition I'm copying to is too large for 3.x).
 
I run DOS 6.22 on my 5160, XUB, HH 360k 5.25" and 3.5" floppy drive and stock floppy controller, Can't say i've had that happen using good 360k or 720k floppy disks.
 
It does sounds like some kind of very intermittent hardware failure, but it could be a lot of different things. You would have to narrow the issue down quite a bit.

Since it happens while copying files, you could set up a batch file to repeatedly copy all files to NUL. That way you would not need a hard drive on DOS 3.3 and might rule out XTIDE issues under DOS 6.22.

I don't know if there are any good tools for stress-testing the FDC chip directly. But I would try testing with tools like ImageDisk that bypass the BIOS and talk directly the the FDC hardware.

Of course, trying with a different FDC card would be a simple thing to do to rule out the card itself. But issues with the motherboard, ISA bus, or XT-IDE would remain.

Does this only happen right after changing disks? That could actually point to a software problem. MS-DOS is a little goofy about switching between 160k, 180k, 320k, 360k, and oddball formats. It could be that the previous disk was some odd format and it didn't figure out that the disk was changed.
 
Try reading or writing a bunch of disks using IMD (use the disk-to-file and file-to-disk function) If there's a hardware problem, it should show up.

On the off-chance, you don't have any other hardware configured to use IRQ6 or DMA2 or parts 3f2-3f7 do you? It's unlikely, but it's worth asking.
 
Last edited:
VileR said:
Been reading quite a lot of data off some floppies. Every once in a while, a perfectly good disk would give me a "General failure reading drive A:"...
Click to expand...

VileR said:
Can't test with 3.x for now, unfortunately; I only said it wouldn't surprise me ;) (the partition I'm copying to is too large for 3.x).
Click to expand...
What does a floppy error have to do with a partition on the HD? You can run DOS 3.3 and ignore the HD. Floppy reads and writes are independent of any HD and can be done floppy to floppy for testing purposes.
 
Chuck(G) said:
Try reading or writing a bunch of disks using IMD (use the disk-to-file and file-to-disk function) If there's a hardware problem, it should show up.

On the off-chance, you don't have any other hardware configured to use IRQ6 or DMA2 or parts 3f2-3f7 do you? It's unlikely, but it's worth asking.
Click to expand...

No IRQ/DMA/port conflicts as far as I can tell (and CheckIt corroborates).

I forgot to mention that - in addition to copying the files in DOS - I've been reading each disk with IMD, and IMD itself never triggered the issue. Now that I had another look, I can add that IMD is unaffected even after DOS triggers it (more below).

SomeGuy said:
Since it happens while copying files, you could set up a batch file to repeatedly copy all files to NUL. That way you would not need a hard drive on DOS 3.3 and might rule out XTIDE issues under DOS 6.22.

I don't know if there are any good tools for stress-testing the FDC chip directly. But I would try testing with tools like ImageDisk that bypass the BIOS and talk directly the the FDC hardware.

Of course, trying with a different FDC card would be a simple thing to do to rule out the card itself. But issues with the motherboard, ISA bus, or XT-IDE would remain.

Does this only happen right after changing disks? That could actually point to a software problem. MS-DOS is a little goofy about switching between 160k, 180k, 320k, 360k, and oddball formats. It could be that the previous disk was some odd format and it didn't figure out that the disk was changed.
Click to expand...

It always seems to happen in the middle of a COPY/XCOPY operation, after it has gone through a few files... so nay on the disk-change thing.

Thank you both for the pointers. Did some more testing with a pile of known good disks; I booted three different DOS versions and cycled through the disks with "copy *.* NUL".

- DOS 6.22: reproduced, 6 disks into the pile. Again, once it happened, every subsequent access to A: failed immediately (drive light stayed off).
- DOS 5.00: didn't reproduce (gave up after 20 disks).
- DOS 3.30: didn't reproduce (gave up after 20 disks).

Under 6.22, once Gen. Failure took over, I checked a few more things before rebooting:

- Norton DiskEdit: failed to initiate any access to A: - threw up a "disk read error" immediately.
- The floppy drive tests in CheckIt 2.1 & 3.0: failed similarly.
- CheckIt's System Board test (incl. DMA/Interrupt controller tests): passed.
- ImageDisk, AnaDisk and DiskCopy-Fast all continued to happily access A: and read data successfully.

That last point tells me it's probably not the FDC. Perhaps some obscure bug with the combination of DOS 6.22 and my version of XUB.
It's a shame that tracing into DOS functions with DEBUGX is such a reentrancy minefield... now I'm rather curious to see what exactly triggers DOS's critical error handler.
 
Trixter said:
I've never heard of this specific crash; where can I read more info about it?
Click to expand...

If you go "mode co80,r" in DOS 6.22, which leaves MODE resident, certain sequences of video mode sets (or perhaps other INT 10h operations) will corrupt the CGA display/make it lose sync. IIRC quitting Keen 4 would do that, and also starting AcidDraw I believe.

That was one of my reasons for making the TVCGAFIX thing... it seemed like the pointer to MODE.COM's resident video parameter table was getting corrupted, which made it send garbage to the CRTC. Haven't really investigated it further, other than determining that the same command in DOS 3.3 didn't have that effect.
 
You must log in or register to reply here.
Back
Top