"DIR A:", divide by zero

[shidel]

For whatever reason, when I stuck this floppy in my Mac, it said it was not initialized. So, I had it do that. Then I copied a couple files onto it to test under DOS. Then, I booted the DOS machine and simply stuck the floppy in and tried to get a directory listing. The above occurred. (I did press R to retry).

Out of curiosity, I then rebooted the DOS machine. The launched a sub-shell by running an additional COMMAND.COM in non-permanent mode. It did the same thing but with two duplicate Divide by zero messages.

I then rebooted again and ran "format a: /u /q". It displayed a message about bad information and continued with formatting the diskette anyway. Once actually formatting was complete, it generated a BIOS error before displaying the format summary. However, subsequent DIR's performed on the Diskette no longer halted the system.

I suspect the Mac did something weird to the boot sector on the diskette. It probably wrote a partition table or something similar.

But regardless, an invalid boot sector on a floppy should not cause a divide by zero and the system to halt.

[PerditionC]

any chance you can attach or email me a disk image?

[shidel]

I had reformatted that floppy. But, I was able to make another that does the same thing. I also tested it on two different DOS machines and got the same error with the exact same stack contents.

macflop.tar.gz

When I had the Mac initialize the diskette. This was it's output....

Starting secure erase…
Unmounting disk
Creating the partition map
Waiting for partitions to activate
Formatting disk4s1 as MS-DOS (FAT) with name BLANK
512 bytes per physical sector
/dev/rdisk4s1: 2723 sectors in 2723 FAT12 clusters (512 bytes/cluster)
bps=512 spc=1 res=1 nft=2 rde=512 sec=2772 mid=0xf8 spf=8 spt=32 hds=16 hid=63 drv=0x80

Mounting disk
Operation successful.

Before I imaged it, I listed the drives attached to the machine...

So as you can see, it really did stick a partition table on there for some reason. Which works fine on the Mac. But, it really should not be there and caused the DIR command to generate the divide by zero error and halt the machine.

[shidel]

As a reminder...

After receiving the "error reading from drive a:", I pressed R to retry. I did not see what happens when any other option is selected.

[boeckmann]

If you pressed "R" for retry, this should not even reach FreeCOM at this point, doesn't it? I think you should get another critical error message. So to me it looks more like a kernel thing. Coincidentally we hat similar problems with the EDR kernel failing to block access to a non-initialized floppies. And we found out that the FreeDOS kernel also allows access to floppys containing a zero-filled boot sector. This might or might not be a related issue.

SvarDOS/edrdos#90 (comment)

[shidel]

If you pressed "R" for retry, this should not even reach FreeCOM at this point, doesn't it? I think you should get another critical error message. So to me it looks more like a kernel thing.

That is a good possibility and there are definitely similarities to that EDR kernel issue. Guess it all depends on what happens on Retry and how the error is being handled.

The kernel can read the sector. However, it makes no sense to it. That probably triggers a critical error. Which is most likely not trapped by the DIR command. So far, so good. Selecting Retry then causes a divide by zero.

[susi]

Since the critical error handler is in FreeCOM, so one way to definitely test whether this is an issue in FreeCOM v/s the kernel is to use another shell, e.g. DOG, SvarCOM or 4DOS etc.

[boeckmann]

@shidel forget my last two messages, I had a short in my brain.

I tested your image with the EDR COMMAND.COM. It shows a similar behaviour under the FreeDOS kernel (do not let the VER output confuse you, it is indeed running the FreeDOS kernel):

This is how it looks under the EDR kernel + command combo:

[shidel]

@boeckmann I had reformatted the original floppy with the test files under FreeDOS. Format complained about invalid data. However, it proceeded anyway. Then, just before format displayed its end summary, it displayed a BIOS error and exited. But after that, the DIR command no longer halted the system. Just displayed “no files”

since @PerditionC asked for a disk image that caused the divide by zero error, I duplicated the process used to make the diskette. However, I did not copy any new files onto it.

The second floppy creates the divide by zero and halts the system exactly like the original. I just doesn’t contain any files.

One nice thing about the second image is it was zero wiped during creation. So, it compresses down to about 2kb.

[shidel]

@boeckmann, I also tested it under PC-DOS 7.1, MS-6.22. No problem. Just disk error, over and over until I have it Fail and it returns to the prompt.

testing under “MS-DOS 7.1” (Windows 98 Command line only) is a little interesting. The drive letter was garbled. But, it did not halt the system.

[boeckmann]

"Good" result under EDR kernel + FreeCOM combo, critical error handler is "re-armed" after pressing R:

[shidel]

@boeckmann “unknown media type” is a much better error message than “general failure”.

[boeckmann]

@boeckmann “unknown media type” is a much better error message than “general failure”.

I changed that with one of my last EDR commits, as MS-DOS also returns a bad / unknown media type in this situation. I do not yet understand the exact code path the FreeDOS kernel is taking in this situation, but it most often seems to return the "general failure" condition. Definitely an area that could be improved.

[boeckmann]

as MS-DOS also returns a bad / unknown media type in this situation

Well, at least in the "boot sector filled with zeros" scenario, not sure if MS-DOS returns "bad media" in your specific situation.