Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Finding untranslated params for IDE drives (w/ pgm)
Message-ID: <1992Oct19.173418.10490@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <1992Oct18.153007.28120@crash> <1992Oct19.053131.11296@tfs.com>
Date: Mon, 19 Oct 92 17:34:18 GMT
Lines: 143
In article <1992Oct19.053131.11296@tfs.com> julian@tfs.com (Julian Elischer) writes:
>this [IDE data] is great, Terry and I were trying to work out the translation
>mechanism, so we could better understand the boot.
>Terry feels that the translation in IDE drives is done by the BIOS
>support routines, though I was dubious about this (but hey
>I don't have an IDE drive so what do I know)
>This however is the second confirmation of the drive doing it itself,
>so it loks as if at least SOME of them do it on the drive.
I guess this then raises the question: why the heck are the 0xec/0x91's
used at all? Turning off translation makes no sense, then, since the only
apparent effect is to screw up installation for 2/3's of the people with
IDE drives. Why does the WD driver screw with it?
The only potential explanation is non-IDE drives (like the 9 head MFM
Micropolis, 130M). Getting the drive geometry would give you more disk
space to use.
>Terry, I spoke at length with Bill Jolitz on this and he tells
>me that he had to talk to several IDE manufacturers to understand
>what was going on, and they all told him that they do translation
>on the drive.
>He also said that some of the drives do not map 1:1
>i.e. in translated mode the may not use all the sectors in
>a cylinder or similar horrible kludges.
This also means a non-native geometry steals some of your disk space, then.
>My thought is that with an IDE drive, if this is true, then the
>safest thing to do would be to leave it in translated mode all the
>time. (of course this is only feasible if the drive translates itself
>but that point of view is gaining a lot of support at trhe moment 8-)
I have to agree with you now, after running Frank's program. The thing
that confused me was that BIOS calls to the controller apparently changed
the translation; in reality, the controller tells the disk whether or not
to do translation.
Is there any way to find out if the original intent of "turning translation
off" was simply to get more usable disk? If so, perhaps we should support
this only in the "USE ENTIRE DISK FOR 386BSD?" case. I suspect we will
end up with a two disk "basic install" following this path to it's logical
outcome.
We might provide a "working without a net" option for those lucky enough
to have IDE drives with 1:1 mappings or the other two highly unlikely but
possible scenarios where a linear non-1:1 mapping can still work with two
OSs.
One question we should be able to answer with Frank's code, slightly changed,
is "is this a translated drive?". I think we still need a way to "restore"
translation. We can provide an ioctl() in the driver to get the information,
and run the modified code to get the information during the probe. I would
definitely say "screw it" if they are using DOS-partitioning to get more than
one OS on the disk, and *not* disable translation.
This would rely heavily on being able to reset translation without:
>>5. Asks user to reboot system since translation may have changed.
An alternate mechanism to getting translation "turned back on" would be to
disallow the "without a net" option and not try to probe (which would turn
it off) and not explictly disable it by examining the boot track for DOS
style partitioning. This would lose us the disk space we would get from
non-translated drives as well, but eliminate the "turn on translation"
problem.
>>Also, data transfers from this drive averaged about 300 kb/sec when
>>the drive was set up in translated mode and about 660 kb/sec when
>>set up in its "default" mode. This was probably partially caused
>>by the use of 17 secs/trk rather than the native 33 secs/trk; the
>>80C31 microprocessor has to work harder to translate addresses.
Ah, here's the rub! If you don't turn off translation, your performance
is halved (at least for this drive). Well, I knew it was disgusting to
install DOS on my drives, but I didn't know it was *that* bad! ;-). I
think we will have to just eat this if DOS partitioning is on the drive,
just like we may have to eat a loss of space on MFM and RLL drives
because we can't determine from the controller if it's IDE or not (if we
have to make pessimistic assumptions for IDE, like leaving translation
on to avoid buggering it, then we will lose the benefits of knowing the
real geometry on other drive types that are software indistinguishable from
IDE).
>>For those IDE drive users with a modern BIOS supporting user configurable
>>drive types (type 47 on an AMI BIOS), I suggest configuring the drive
>>or drives to the default geometry given by step 4 above. This results
>>in the geometry remaining constant throughout the 386BSD's handling of
>>an IDE drive and possibly better performance.
>>
>This is very good news.
>
>Terry, If this is true then we must go back to the original of my two
>articles.. (The one assuming translation on the drive)
>If this is true, then my guess is to use fdisk
>to set all figures as if calculated using the 'default' figures.
>I still feel this should work. Your drive may be different
>of course. have you done any experiments with it?
I have experimented... and setting the 'default' values still makes my IDE
drives die when I have DOS partitioning on them... I am luck to have 17,
a nice prime number, as the number of sectors per track, so I can't even
make an optimistic assumption and get either of the two workarounds to
work for me (they depend on finding an LCF for a cylinder boundry, and the
only one I can calculate for it occurs way beyond the end of the drive).
I *have* been able to get an second stage boot that knows the physical
location of the partition start to work, but this was prety hairy without
Frank's program. Even with it (modified) to spit out usable cylinder
boundries and untranslated partition information, I could only find 3
usable places for a partition boundry on my disk (this is one more than
I arrived at by hand).
I disagree that we should be turning translation off at all, unless, as
detailed above, we can turn it back on or we aren't using DOS partitioning.
Any ideas on how to turn translation back on so I can provide an ioctl()
interface and modified probe routine for the wd driver to get the drive
set up from user space and set/unset translation?
Also: What about the two IDE problem, when you only have one drive type 47
available? It would seem to me that translation wouldn't want to be on on
an all-386BSD drive, and that the first drive is more likely to boot both
DOS (or some other OS) and 386BSD. It's be a shame to pay half the disk
performance and part of the disk space if we didn't have to.
I think we are coming close to something that can work every time for
everybody, which is what I feel this whole thing has been about anyway...
a few more hammer blows, and we should have it.
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
-------------------------------------------------------------------------------