• Please review our updated Terms and Rules here

Weird file access problem in MS-DOS. Boot floppy works, boot HDD broken.

mR_Slug

mR_Slug

Veteran Member
Joined
Nov 28, 2006
Messages
941
Location
UK
Ok this ones got me stumped.

If I boot from the floppy and do a "copy *.* c:" everything works.

Boot from the hdd and do "a:" followed by "copy *.* c:"

I get loads of sector not found errors? reboot and try from the floppy, no issues again.

Anyone ever experienced something like this? The setup is a 486 with a combined SCSI/FDD controller.
 
Might be an issue with the disk cache. I remember there were problems with some SCSI controllers if the disk cache does not double buffer.

Could you provide information as to what system and which controller and OS are in use?
 
I seem to recall running in to similar problems a long time ago. In those cases I believe there was some mismatch in the partitioning information, perhaps caused by using a different versions of DOS or third party tool to FDISK the drive.

If there is nothing on the drive, I would suggest wiping the drive (make sure the MBR is zeroed) and re-FDISK and format making sure to use the same version of DOS.

If it is something else, a tool like Norton Disk Doctor might might help identify the problem.
 
mR_Slug said:
Ok this ones got me stumped.

If I boot from the floppy and do a "copy *.* c:" everything works.

Boot from the hdd and do "a:" followed by "copy *.* c:"

I get loads of sector not found errors? reboot and try from the floppy, no issues again.

Anyone ever experienced something like this? The setup is a 486 with a combined SCSI/FDD controller.
Click to expand...

Possibly losing track of or not finding COMMAND.COM?
 
Motherboard: ASUS EISA-486E
Disk controller: Mylex DCE376 (Rev 1F) 4MB cache.
Disk: 1GB Seagate Elite 1 ST41600N
OS: MS-DOS 4.01 (Also problem is on dos 6.22 AFAIK)

I've low-level formatted the drive twice. The drive works fine on an Adaptec AHA-2940W and AHA-1742A.

I've tried the DCD376 and drive together on another 486 EISA system, same problem. so it all points to the controller.

A weird thing about the drive is that it's on board LED flashes continuously. This usually indicates an error but, it seems to do this on every controller and works fine on them.

One other weird issue. Clean boot no config.sys or autoexec.bat. Try to copy emm386.sys from a:\ to c:, whole system locks, LED on the drive goes out. HDD LED on the controller stays on, eventually get a general failure reading drive C:. Weirdly if i move the emm386.sys to a subdir (on another system) then copy it, no problem. Kinda almost like some byte is interpreted as an escape char and befuddles it. I'll have to look into this one further.

I'm currently working out of a 32MB partition to avoid any oddities with DOS 4x. (large partitions requires share.exe to be loaded)

This is all without loading any special drivers for the caching function. The controller can see 470MB of the HDD. Anything past that requires a special type 153 partition and drivers loaded. Strangely all this complex add-on stuff works perfectly.

Answer to why MS-DOS 4.01. I'm trying to build a 1990 system.

I haven't found anything to mention this controller has issues, rave reviews in PC Mag and Infoworld well into 1992. One thing that's odd by today's standards, it emulates the WD1002 like ESDI. You set the drive type to no.1 in the BIOS and the controller re-writes the entry.

I've got a couple of angles, I'm going to retry the whole setup with DOS 6.22 tomorrow and use a seperate FDD controller. It's just all so peculiar.
 
Found the Issue. If I boot from the floppy and run 6.22's MSD the floppy is reported as a 1.44MB. Boot from the HDD and it's reported as a 360K drive. Drive is set as 1.44MB in BIOS.

The BIOS is Award BIOS v4.0. It's an early one, that looks nothing like the later one that's almost identical to the AMI. It's old enough to default to 1.2MB.

So how do you override this in DOS?
 
Ues DRIVPARM.SYS in your config.sys file to tell DOS that it is a 1.44 MB drive. I'm not sure if DOS 4.X supports it. In general, DOS 4.X has a lot of bugs. I would recommend gong to at least DOS 5.
 
DRIVPARM= /D:0 /F:7 /C

in config.sys has solved the sector error issue accessing the FDD. Now I can boot to C: and copy files from A: to C:. There's no AUTOEXEC.BAT. and that is all that's in CONFIG.SYS.

I'm now trying to work out the peculiar problem with copying emm386.sys from dos 4.01. I don't need the file, just confused why it totally kills the HDD until hard reset. I've split it up from 80KB, and got ~50kb that gives me a problem. I've tried to cut it up further but then it copies fine. There are large areas of zeros. I'll see if i can chop it down.
 
Are you certain you have the fully fixed emm386.sys from DOS 4.01? Bad buffers in EMS were a major cause of the problems with DOS 4.x.
 
I don't know if the version i have is updated from the basic v4.01. Im not trying to use it though, just copy the file. I've cut the file down and I can't really understand why it causes so much of a problem.

The offending file now consists of 1Fh followed by 00h upto 0x1001 followed by FFh upto 0x2001 followed by 00h upto 0x8ce5.

Image.jpg

There are no special drivers loaded, just the DRIVEPARM to fix the FDD to 1.44MB.

When I copy the file, as far as I can tell the controller just stops and reset's the SCSI bus. Very peculiar.
 
Anyone know where to find a manual for the Seagate Elite 1 ST-41600N? There's nothing on the seagate ftp server and the .TXT file is very short. I'm trying to work out if the continuously flashing LED indicates a problem.

The drive has a 256K cache. I'm wondering if perhaps the memory chips are faulty. The theory I'm working on is perhaps the if the cache is 50% filled there's no issue writing. OTOH, a fast transfer* that fills the drives cache runs into a bad RAM chip.

I tested the controller on another drive and it seems to work.

I'm still none the wiser why that particular file causes such an issue.

*Yes it's from a floppy, but the cache controller probably just bursts the data to the drive.
 
mR_Slug said:
This is all without loading any special drivers for the caching function. The controller can see 470MB of the HDD. Anything past that requires a special type 153 partition and drivers loaded. Strangely all this complex add-on stuff works perfectly.
Click to expand...

Based on your issues, maybe it doesn't work perfectly?

Answer to why MS-DOS 4.01. I'm trying to build a 1990 system.
Click to expand...

There is no reason whatsoever to run MS-DOS 4. It has so, so many bugs, from EMM386, to SHARE, to FASTOPEN... just don't run it. If you want to be 1990-period-correct, run DR-DOS 5 which supports large drives. Alternately, run Compaq DOS 3.31 which also supports large drives.

I'm now trying to work out the peculiar problem with copying emm386.sys from dos 4.01. I don't need the file, just confused why it totally kills the HDD until hard reset. I've split it up from 80KB, and got ~50kb that gives me a problem. I've tried to cut it up further but then it copies fine. There are large areas of zeros. I'll see if i can chop it down.
Click to expand...

I'm strongly suspecting your controller, or some other hardware issue. I don't think it's related to the file, the disk, or the floppy drive. Have you tried a minimum configuration, such as removing everything except the floppy controller, disk controller, and video card?
 
Trixter said:
Based on your issues, maybe it doesn't work perfectly?
Click to expand...

Yes, I've been playing with DOS 6.22 on another drive, same controller and it's all fine. So it's pointing to the drive.


Trixter said:
There is no reason whatsoever to run MS-DOS 4. It has so, so many bugs, from EMM386, to SHARE, to FASTOPEN... just don't run it. If you want to be 1990-period-correct, run DR-DOS 5 which supports large drives. Alternately, run Compaq DOS 3.31 which also supports large drives.
Click to expand...

Yeah your right. I thought I would see just *how* bad it is. Though the FDD issue is a BIOS problem, and I think the drive is at fault. Still starting with DOS 4.01 was asking for problems. I thought most of the issues were solved in the .01 version. OS2 museum, goes into a lot detail on 4.x, but last time I checked there was an issue with the site.

Trixter said:
I'm strongly suspecting your controller, or some other hardware issue. I don't think it's related to the file, the disk, or the floppy drive. Have you tried a minimum configuration, such as removing everything except the floppy controller, disk controller, and video card?
Click to expand...

Yep it's min config, the only other thing apart from the HDD controller is a spare FDD controller to eliminate the issue with the FDD controller on the HDD controller, that I now know is a BIOS issue. It's a multi-io but everything else is disabled with jumpers. And everything else is definitely disabled, had 2 others that have a jumper to disable the IDE but don't.

I think its the drive. When I got it it required a low-level format. I'm guessing the thing wasn't tested properly. A charitable explanation would be that it may have been in a system with a non 512K sector size (or something) and appeared to work. I'll try it in another system again.
 
mR_Slug said:
I think its the drive. When I got it it required a low-level format. I'm guessing the thing wasn't tested properly. A charitable explanation would be that it may have been in a system with a non 512K sector size (or something) and appeared to work. I'll try it in another system again.
Click to expand...

I've found Speedstor (available on modem7's site) to be very good at LLF'ing and verifying MFM drives, so I'd give that a shot. Any bad sectors it finds can go into the hard drive bad sector table, which they'll always return bad for DOS (ie. spinrite won't be able to try to force them as usable again).
 
I'll have a look at speedstor, I didn't know it works with SCSI drives.

I've been testing the drive in a more modern system with linux and I can't find any issues with it. BTW the constant flashing LED is a "heartbeat LED" (if it works like the Elite 3). I've been trying to use the sg_utils to see if there is anything odd about the drive. One thing I don't seem to be able to do is set the write caching:

sginfo -c -6 /dev/sdb
Code: 
Caching mode page (0x8)
-----------------------
Initiator Control                  1
ABPF                               0
CAP                                0
DISC                               1
SIZE                               0
Write Cache Enabled                0     <------
MF                                 0
Read Cache Disabled                0
Demand Read Retention Priority     0
Demand Write Retention Priority    0
Disable Pre-fetch Transfer Length  0
Minimum Pre-fetch                  0
Maximum Pre-fetch                  96
Maximum Pre-fetch Ceiling          0
FSW                                0
LBCSS                              0
DRA                                0
NV_DIS                             0
Number of Cache Segments           4
Cache Segment size                 0
Non-Cache Segment size             0
The output of:
sdparm -6 -a /dev/sdb
WCE 0 [cha: n, def: 0, sav: 0]
Indicates that write caching cannot be enabled, so I guess it's just a read cache.

I tried setting the RCD (Read Cache Disabled) to 1 and saving it:
sdparm -6 -a /dev/sdb
RCD 1 [cha: y, def: 0, sav: 1]
Setup the drive in the 486 system and still get the same problem.

I can't figure why this controller wont work with this drive. Controller works with other drives, drive works with other controllers. Both are 5MB/s SCSI-2.

Does anyone know what could be causing the incompatibility?
 
Nailed It. Turned out the controller was not providing term power. There's no setting for termination on the controller at all. I'm not sure if this is a function of the controller or the NCR53C90A chip it uses. Evidently when the large block of 0s followed by a large block of 1s were sent over the bus the controller gave up. Got the drive to provide term power to the separate terminator and bingo.


I did decide to go with your recommendation on DR-DOS 5 eventually. Never used it before, very impressed. Seems to work fine with the controllers TSR's despite the manual stating DR-DOS was unsupported.

Thanks for everyone help.
 
You must log in or register to reply here.
Back
Top