Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!uunet!wupost!sdd.hp.com!caen!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: <1992Oct25.234147.3649@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: University of Utah Computer Center
References: <1992Oct15.171833.25427@fcom.cc.utah.edu> <1992Oct17.060946.25764@ntuix.ntu.ac.sg>
Date: Sun, 25 Oct 92 23:41:47 GMT
Lines: 142
In article <1992Oct17.060946.25764@ntuix.ntu.ac.sg>, eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:
|> A Wizard of Earth C (terry@cs.weber.edu) wrote:
|> :
|> : 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.
|>
|> I believe this is the crux of the problem.
|> The question is: where is the translation done?
|> Options are:
|>
|> i) controller;
|> ii)bios on controller;
|>
|> 386BSD does not use bios interrupts except during boot-time.
|> 386BSD cannot handle variable no of sector.
|>
|> Therefor option ii) does not make sense, if the harddisk can work at all.
|> Most of the problems are not due to inability of 386BSD to work, rather, its
|> problem when co-existing with DOS.
On the contrary, there are several ways ii) can work. One of them is linear translation, where sector 0 translated is still sector 0.
Bringing in variable numbers of sectors (which I agree *is* hardware translated
-- it's commonly referred to as "zone recording") simply muddies the issue.
The fact is that the majority os SCSI devices do zone recording but work fine
with 386BSD; if IDE were simply doing the same translation SCSI (and some ESDI)
drives do, there wouldn't be people having problems. The translation that is
killing us is the reduced number of cylinders and increased number of heads,
not the translation for zone recording.
|> Putting the translation inside the controller is not at all difficult. The
|> manufacturer of the IDE controller may be very stupid indeed if he uses bios
|> to do the translation. The main processing power will be disturbed.
First of all, you don't end up with $30 controllers this way; controller
pricing is the major reason US buyers go IDE instead of SCSI. Outside the
US is fuzzier, since it appears (from postings here) that the price of non-IDE
drives outside the US is artificially inflated. This may be a result of
volume, since the US is a larger market for computer equipment, and thus can
take things like SCSI to commodity volume faster. Personnally, I think it's
a conspiricy by DOS users to make UNIX disk access at least as ineffective
as DOS disk access.
Second, it's not stupid from a technical standpoint, since some processor has
to do the translation, and it might as well be the better processor. You never
"offload" something when the bus is locked up. This is why a lot of disk
controllers don't support DMA. What's the point of kicking the main processor
off the bus so that an inferior processor can access buffers in main memory?
|> Since my 386BSD works with Maxtor, Conner and Western Digital, these
|> manufacturers most probably uses IDE controllers that can do translation them
|> selves without resorting to BIOS ROM inside it.
This is just as easily the result of you using the whole disk or getting lucky
with the cylinder boundries. Not everyone is lucky. Another possibility is
that you have drives which don't report their real geometry when asked, but
instead report their "translated" geometry. I know of at least two Maxtor
drives which do this; there's no reason to believe yours is any different.
|> : 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
|>
|> There is a control register that can give the default translation for that
|> IDE controller.
|> There is no reason to doubt that that figure can be changed. Maybe most
|> BIOS should do that.
|>
|> Read the article in Byte March 1991, page 321:
|> There the tables on register definitions, and commands.
|> It is not complete though.
The problem here is distinguishing an IDE drive from some other drive; this
isn't done in the current wd driver (which mistakenly identifies my WD7000 as
a wd controller instead of a SCSI controller during the probe. If you can
figure a way to make the probe routine more exacting without killing it's
ability to identify some drives, then reading the control register would be
more practical (plus mean I don't have to get rid of my wd driver for my SCSI
driver to operate correctly). Until then the better soloution is to not turn
off translation, or to identify the translation being done.
|>
|> : 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.
|> :
|> :
|> : >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
|> You are making the assumption that you can turn off the translation.
|> Most probably you can't.
Most of the problems which are occuring with 386BSD and IDE drives are the
result of 386BSD ignoring the translation and doing it's disk I/O to the real
disk geometry. Translation on the controller is turned off; whether it's soft
or hard is irrelevant (with the caveat that soft translation can never be
"left on" to avoid the problem). Please see Frank MacLaughlin's code.
|> : 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 2nd stage boot only loads the first sector in a partition to the
|> standard address. OS-boot duplicates the first stage boot of floppy disks. In
|> hard-disks, the boot block(first stage) must load another boot-block for the
|> 2nd stage bootstrap.
|>
|> Therefor the 1st sector in a hard-disk is not the boot-block, rather a
|> boot-manager.
|>
|> OS-BS uses DOS conventions, i.e. using BIOS for its operations, so must
|> translate information from DOS partition table.
OK, if you count the MBR (and things like OS-BS which act like an MBR) as the
first stage boot, then it's the third stage boot which fails (the kernels
attempt to mount /). The problem is that the geometry the kernel uses to find
the disk label is not the same as the geometry used by the BIOS-based kernel
loader loaded by the MBR (or OS-BS). Therefore the disk label is not seen
where it's supposed to be. I've only seen the code that the MBR loads (wdboot
or asboot) fail when the translated geometry didn't match the BIOS geometry
and 386BSD wasn't on the first of the disk -- and then only with some BIOS's.
This is the "infinite reboot without copyright notice problem", which I can
only get one of my IDE boxes to fail with.
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
-------------------------------------------------------------------------------