At 03:29 PM 7/23/2005 +0100, Gerry Hickman wrote:
Biggest mitigating factors are that if your hard drive behaves without
errors, is reasonably standard with expected parameters, and there is no
corruption of the program, the MBR write on startup won't occur.
Ah, so this bug only happens with
On Sat, 23 Jul 2005 15:29:04 +0100, you wrote:
Hi Gerry,
It's just I have to build 30 PCs in coming weeks, plus some production
servers, and plan to use FreeDOS FDISK to partition them. I was a bit
worried reading about this bug, but all my hard drives are brand new, so
should be OK.
If you
This may be a side effect of memory corruption with EMM386. In
fact, it appears to be a result of some interaction with EMM386.
I do not believe the hard disk in question is faulty and I do not
believe that it has non-standard parameters.
I do not believe the memory corruption is due to the hard
Michael Devore wrote:
At 04:01 PM 7/21/2005 -0500, I wrote:
When you invoke FDISK without arguments, it goes into the
Interactive_User_Interface() routine. That, in turn, asks about FAT32
support, via Ask_User_About_FAT32_Support() function. OK so far.
After that call -- without any
At 11:33 PM 7/23/2005 +, you wrote:
This may be a side effect of memory corruption with EMM386. In
fact, it appears to be a result of some interaction with EMM386.
I do not believe the hard disk in question is faulty and I do not
believe that it has non-standard parameters.
Doubtful.
Anyone know if Brian is on fd-user list? or otherwise been notified of
these issues?
I don't think it will be too difficult to correct (warn/abort at least)
so maybe if I get time after work tommorrow I'll make a patch available
to make fdisk safer to use.
Thanks for reviewing the code,
[EMAIL PROTECTED] wrote:
By the way, I consider this bug extremely serious.
I agree, and Michael's post would appear to confirm that FDISK is far
from read-only, but has this bug always been there, or is it only in
recent development builds?
If it's always been there, why have more people
At 08:36 PM 7/22/2005 +0100, Gerry Hickman wrote:
[EMAIL PROTECTED] wrote:
By the way, I consider this bug extremely serious.
I agree, and Michael's post would appear to confirm that FDISK is far from
read-only, but has this bug always been there, or is it only in recent
development
[EMAIL PROTECTED] schreef:
Ok, I just added edit.exe to my boot floppy! :-)
First, modifying config.sys to:
a:\device=himem.exe
a:\device=emm386.exe noems X=a000-efff memcheck vds
EMM386 reports no suitable UMB memory block found :-)
FDISK shows a bunch of garbage after Do you want to use
Hi Bernd:
I'll try that. I'm only willing to run this on the one computer...too
risky for any others. I'm not blaming fdisk, but do not consider
running it safe. If I do not run fdisk, the disk partition table does
not get destroyed!
Mark
[EMAIL PROTECTED] schreef:
Ok, I just added
Hi,
It seems to me there are three possible reasons for the corruption:
1. Something is up with FDISK
2. Some config is corrupting the memory (e.g. EMM386)
3. Something is a big different with the BIOS or hardware in this machine
Before switching to FreeDOS, I was experiencing similar problems
At 03:11 PM 7/21/2005 +, Mark wrote:
I'll try that. I'm only willing to run this on the one computer...too
risky for any others. I'm not blaming fdisk, but do not consider
running it safe. If I do not run fdisk, the disk partition table does
not get destroyed!
Well, maybe I'm wrong and
At 04:01 PM 7/21/2005 -0500, I wrote:
When you invoke FDISK without arguments, it goes into the
Interactive_User_Interface() routine. That, in turn, asks about FAT32
support, via Ask_User_About_FAT32_Support() function. OK so far. After
that call -- without any further prompting -- FDISK
At 11:40 PM 7/21/2005 +, Mark wrote:
Are any of the tests that have been suggested (other kernels,
MS-DOS, ommitting VDS, trying UDMA2, older versions of
FDISK, etc.) going to help in getting this problem fixed? I have
a repeatable problem (always a good thing) and have, I think,
done a
I agree. It is far too risky to run the FreeDOS FDISK under any
circumstances - just based on the limited tests I have done.
I will run it ONLY on this test computer. It becomes even
more of an adventure given your analysis of the source code! :-)
Mark
At 11:40 PM 7/21/2005 +, Mark
On Thu, 21 Jul 2005 16:21:46 +0200, you wrote:
Hi,
DEVICE=HIMEM.EXE
DEVICE=UDMA2.SYS
DEVICE=EMM386.EXE NOEMS X=A000-EFFF MEMCHECK VDS
-or-
DEVICE=HIMEM.EXE
DEVICE=EMM386.EXE NOEMS X=A000-EFFF MEMCHECK
I'm not searching for to blame a component, too many factors involved.
Better remove
OK. Back to the standard development kernel.
config.sys still has himem.exe and emm386.exe. No
autoexec.bat.
Boot floppy without running FDISK. Reboot Linux. Partition table normal.
Copy it to the floppy this time! :-)
Reboot FreeDOS from floppy.
enter
enter
A: fdisk
Displays a bunch
[EMAIL PROTECTED] schreef:
Meanwhile, personally, I don't recommend using FreeDOS FDISK! :-(
Mark
I hope you have the option of using FreeDOS FDISK running under as many
MS components as you can (kernel, shell, himem, emm386). A Win98
bootdisk for example.
Just to be absolutely sure it's
Hi Bernd:
I don't believe it is just FDISK. It appears to be FDISK + EMM386,
maybe plus the development kernel. However, until this is
isolated and the cause understood, I do not recommend
using it. There are other tools which do the same thing! :-)
Mark
[EMAIL PROTECTED] schreef:
At 12:37 AM 7/21/2005 +0200, Bernd Blaauw wrote:
[EMAIL PROTECTED] schreef:
Meanwhile, personally, I don't recommend using FreeDOS FDISK! :-(
Mark
I hope you have the option of using FreeDOS FDISK running under as many MS
components as you can (kernel, shell, himem, emm386). A Win98
Ok, I just added edit.exe to my boot floppy! :-)
First, modifying config.sys to:
a:\device=himem.exe
a:\device=emm386.exe noems X=a000-efff memcheck vds
EMM386 reports no suitable UMB memory block found :-)
FDISK shows a bunch of garbage after Do you want to use
large disk (FAT32) support
At 12:05 AM 7/21/2005 +, Mark wrote:
Make config.sys
a:\device=himem.exe
Reboot.
The DIR commands now work. Reboot again.
Kernel still recognizes the partitions. emm386.exe not run.
FDISK did NOT trash my MBR. Bare himem.
Doesn't make much sense. EMM386 is effectively out of the
22 matches
Mail list logo
