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 running
real-mode MS-DOS, Win95, Win98 on recent server hardware with >4GB RAM
and with Microsoft's EMM386 loaded. It was very random and excluding
memory blocks didn't help. I'd get garbage DIR output and I seem to
remember an FDISK screen with garbage too.
Now I run FreeDOS (latest non-development build) with UMBPCI and these
problems have gone away.
Can you clarify whether you've experienced the same issue with the NON
development kernel and associated non-development files?
Although you're seeing the problem after FDISK, I'm wondering if there's
something more basic going wrong here, and FDISK is just acting as a
catalyst, bringing the problem into full view?
[EMAIL PROTECTED] wrote:
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 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 (Y/N). I hit <ESC> <ESC> and rebooted.
The kernel no longer sees the partitions on boot. So, that still failed,
trashing my partition table.
load UDMA2.SYS before EMM386, or get rid of the VDS parameter for
EMM386. Disk isn't found then in VMware, so I'm not even trying a real
computer as I'm not sure if it actually harms the harddisk data or only
corrupts access to the harddisk.
I should probably try HIMEM/EMM386 with VDS parameter on a partition
running MSDOS kernel, to see if disk is still accessible.
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.
Bernd
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
--
Gerry Hickman (London UK)
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
