Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!sgiblab!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!hamblin.math.byu.edu!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: DOS and 386BSD (and NT and OS2)
Message-ID: <1992Oct15.171833.25427@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <1992Oct15.025722.15943@fcom.cc.utah.edu> <1992Oct15.081904.20697@ntuix.ntu.ac.sg>
Date: Thu, 15 Oct 92 17:18:33 GMT
Lines: 126
In article <1992Oct15.081904.20697@ntuix.ntu.ac.sg> eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:
>A Wizard of Earth C (terry@cs.weber.edu) wrote:
>: |>
>: |> I am somewhat confused now. Should the DOS primary partition be put first
>: |> (avoiding the problem that you can't run past cyl. 1023) or second, to
>: |> keep asboot, disklabel, family happy?
>:
>: I believe that the confusion here lies with the fact that Othman's procedure
>: will not work on a geometry translated drive.
>:
>
>I may be wrong but I recall being told that the translation is not done by
>bios, rather by the controller.
The translation is done by the disk BIOS *on* the controller, or it may be
done by the drive itself. You don't use the BIOS for access, you don't
get translation.
The limited case of 386BSD working on a drive without translation "turned
off" is based on the assumption that the translation is linear -- ie:
sector offset 321 is sector offset 321 regardless of translation, where
n=321, and being valid for all n.
There is a probe request (which not all controllers support!) that is done
to ask the controller the disk's geometry. This is because the raw driver
used in 386BSD doesn't use the BIOS (for reasons which should be obvious)
and talks to the controller directly -- thus there is no such thing as a
translated geometry as far as 386BSD (or any other non-BIOS OS) is
concerned. Without this, instructions to the controller for "translated"
addresses not going through the "lookup" code (the BIOS) would fail.
> The real geometry of the IDE disk is that of variable number of
>sectors for each cyclinder, to get the maximum number of bytes.
What you are talking about is a uniform rotational bit density as you go
out from the hub. Many, many SCSI drives do this as well. This type of
harsware translation is acceptable, as the only thing it messes up is
seek latency calculation; this is not the same as a 4 head disk saying
it has 64 heads.
>I do not think that there is any OS that can handle varaible sector number so
>the disk controller must convert the variable sector number to a linear number.
AmigaDOS, the MAC "Finder", and VMS aren't OS's, then. 8-). In general,
you are correct that there is "translation" going on. The difference is
that it is in hardware, not the BIOS on the controller. Thus the translation
is "invisible" to the software (although it does cause UNIX to mis-guess
the inter-cylinder seek latency, underestimating it closer to the hub and
overestimating it further away. It also causes the sector-to-sector seek time
to be erratic, since now a seek is potentially involved. This can cost the
time for one rotational latency on a read of two "adjacent" sectors). Usually
the controller will take seek latency into account to precompute the
rotational latency delay of a sector-sector read crossing a cylinder boundry
doesn't cause a missed rotation; thus you only pay for the seek itself. At
a maximum, this should cause about a 6% performance degradation.
>The input parameters are the number of sectors per head, and number of heads
>per cylinder.
Right, and the number of cylinders. As long as this agrees between BIOS and
direct access to the controller hardware, there isn't a problem. IDE generally
uses the BIOS routines to perform "soft" translation, and this breaks the model.
>Theoretically, we can just choose any geometry on the bios, and it will work.
>Provided your bios/software know the geometry that you store your data in.
>I did this on a Western Digital 40Mbyte hard disk.
This is a good point: If you have translation enabled, and it isn't linear
(a sequential increase in head/cylinder increment yields adjacent sectors),
the "mtools" on 386BSD will never be able to access your DOS partition, no
matter what contortions are involved.
One of the major points here is that 386BSD only *sometimes* uses the BIOS;
this during initial boot stages only.
>However the IDE controller may allow software to read a recommended geometry,
>which may be different from the BIOS setting(in CMOS RAM). DOS still works
>because of the above reason.
It does. This is the 386BSD problem: the translation is "soft". The reason
DOS still works is it only uses the BIOS to access the disk.
>The problems come because of the mismatch between BIOS and disklabel
>geometries.
Exactly right. The "disklabel" program runs under 386BSD, which uses the
"real" (potentially hardware translated but *not* software translated)
geometry, since it accesses the disk through a 386BSD device (/dev/wd0d).
>However DOS and 386bsd can still co-exist in this circumstances. Just instruct
>the OS boot manager to load the appropriate partitions calculated using the
>BIOS informations, converted from the disklabel info.
Now *I'm* confused; are you saying this will allow the second stage boot to
know where the physical 386BSD partition starts from the translated data in
the partition table? I would still think the second stage of booting would
fail on a soft-translated drive, since the partition table is recorded in
the soft geometry.
>I have worked with 200Mbyte Conner, 200Mbyte Maxtor, 120 Mbyte Maxtor.
>
>I have another 240mbyte quantum pro IDE, but I believe I can install the DOS
>as well, but I must have the OS-BS software. Otherwise, it will surely fail.
I *really* question the assumption that loading the first half of the boot
code is sufficient here. You should actually be able to do this same thing
with the Julian's code, which reads the kernel in using BIOS routines; I
*still* think there would be a problem reconciling the physical location of
the 386BSD partition for the 386BSD kernel; so even with Julian's code, a
hard-coded location would be required for 386bsd to find and mount /.
Once we get this hammered out, we should have a "the way things work"
document that will be useful to everyone.
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------