Xref: utzoo comp.sys.att:12069 comp.os.msdos.programmer:4266 comp.unix.internals:2443 comp.unix.sysv386:6372
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!ucsd!nosc!crash!nusdecs!rwhite
From: rwhite@nusdecs.uucp (Robert White)
Newsgroups: comp.sys.att,comp.os.msdos.programmer,comp.unix.internals,comp.unix.sysv386
Subject: Re: Dos and unix on same Disk
Message-ID: <1991Mar26.195038.1038@nusdecs.uucp>
Date: 26 Mar 91 19:50:38 GMT
References: <13719@ccncsu.ColoState.EDU>
Distribution: na
Organization: National University, San Diego
Lines: 80

In article <13719@ccncsu.ColoState.EDU> justicec@handel.cs.colostate.edu (Christopher Justice) writes:
>Is using Dos and unix on the same drive common?  Can you do this?  I'd like
>to hear about your experience with doing this.


Hi,

I have a 6386E at home on which I run DOS 3.3a and SVR3.2.1.  I
also use the bootmenu program to select which partition to run
durring bootup.  I also adminstrate several systems here and have
found the following to be true:

  1) Yes, you can run DOS and UNIX on the same system, but if you
     use Simultask you will need the latest release for it to handle
     4.01.

  2) 4.0 and 4.01 DOS will write to the last sector of the disk when
     you run fdisk (not true on all releases, aparently AT&Ts 4.01
     no longer does this, or so they claim) I am not shure if this
     is one of those things that went away with 4.01 universally or not
     but it can be annoying.

  3) Soft reboots (<ctl><alt><delete>) are insufficent for changing
     between operating systems.  The reset and test routines for the
     hardware as found in the operating systems and BIOS are not up
     to the task of properly resetting all the options on all the
     controllers.  "Internal serial port Failed" messages from the
     diagnostics are a symptom, but certianly not the only one.  SCSI
     (and perhaps ESDI) drives with intelegent controllers will
     sometimes have remnants of outstanding requests on them and you
     will get "unexpected harddrive interrupt"s especially on the
     "really smart" controllers.  The entire problem is releived if
     you *ALWAYS* use the hardware reset button to reset the system
     when you change between DOS and UNIX as this will either (I dont
     remember which it is off the top of my head) use the reset line
     on the bus, or actually power-down the CPU (which also then
     causes the hardware reset line to be triggered)  I have expanded
     the habbit to simply never use <ctrl><alt><del> to reset my system.

  4) The older versions of DOS require that the bootable DOS partition
     be the first partition (or at least lie compleetly within the
     first 33.2 or something like that 8-).  4.0 aledged to relax this
     requirement, but was buggy.  4.01 supposedly fixes the huge number
     of bugs and indeed does allow the partition to be any size and
     anyware on the disk.

  5) The IBM brain-damage used to define the partition table puts
     a limit of 1024 partitionable cylinders on the hard disk.
     Many controllers "spoof" the operating system into beleiving
     that there are a legal number of cylinders by lowering the
     cylinder count and raising the head count.  This can impact
     the perfromance of the SVR3 disk scheduler (bdsched), but worse yet
     the controler has to store the spoofing information on the
     hard disk so that it is available durring the option-rom part
     of a reboot.  (another good reason to always use hardware reset)
     Sometimes this conflicts with real data on the drive.  I have
     one system that, whenever you do the controller setup you then
     have to go in and use the UNIX System Foundation Set Disk 1
     and the mkpart to reload the boot tracks into the UNIX partition.
     Some device drivers are available to combat the spoofing performance
     problem under both UNIX and DOS.  If either of these environments
     uses a special driver for your disk (may be even a builtin in
     4.01 or something?) you *MUST* use the hardware reset if you
     expect your data to survive.

I know I keep harping on the hardware reset button, but that technique
has made more than one round of finger-pointing-by-manufacturers go
away here.  To date the technique has helped with 2 brands of cartredge
tape drives, one brand of disk controller, PCOX cards, and every
kind of serial communications card imaginable.  Had I my dream,
standardized software reset methodoligies would be set and adheared to;
but until that day I know I will be seeing problems that come and
go because of the particular order of programs run under one
OS followed by the loading of another OS.  Not a terminal (haha) flaw,
but it can suprise you.
-- 
Robert C. White Jr.    |  The degree to which a language may be
Network Administrator  |   classified as a "living" language
National University    |  is best expressed as the basic ratio
crash!nusdecs!rwhite   |   of its speakers to its linguists.