Date: Tue, 18 Mar 1997 05:35:57 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, dgy@rtd.com Cc: hackers@freebsd.org, helbig@MX.BA-Stuttgart.De, terry@lambert.org Subject: Re: wd driver questions Message-ID: <199703171835.FAA22959@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> The ROMs are completely inaccessible, but that isn't the problem since
>> the geometry of all drives known to the BIOS (actually, only the first
>> 10) is passed from boot.c to the kernel. The problems are:
>
>Hmmm... I thought only the drives *configured* were passed along
>(i.e. two drives on each of two controllers)?
10 always. Some might be SCSI drives.
>> 1. some drives may not be known to the BIOS
>
>Hmmm... perhaps I'm thinking too much of DOS compatibility, etc. I
>guess one *could* hang a drive on a machine that DOS could NEVER access
>(i.e. not "*would*" but "*could*"). Lately I'm more focussed on getting
>DOS and FBSD to coexist so that's where my head is at...
It used to be normal for the BIOS to support more than 1 IDE controllers.
FreeBSD has always supported any number of IDE controllers, and systems
with 2 IDE controllers are now common.
>> 2. the kernel has no way of knowing to correspondence between BIOS drive
>> numbers and FreeBSD drive names. It could do the same thing as boot.c,
>
>Huh? I thought wd0 was the first drive (i.e. the IDE "master") on the first
>controller, wd1 was the "slave" on that controller, etc.
>
>Ahhhh... this isn't *guaranteed* to be the case?
Yes, but BIOS drive 0 is just the first drive found. It may be wd2 if there
is nothing on the first controller. Then there are SCSI drives.
>> I don't see any problem. The BIOS geometry is 611/16/63 for some reason
>> (probably the BIOS is old and can't translate to > 16 heads). You must
>
>[if you look at the actual geometry -- 790/15/57 -- it has nothing to
>do with translating for > 16 heads or "EIDE" stuff. Rather, the BIOS
>just doesn't support a "user configurable" disk type so I'm stuck with
>whatever was hardcoded into the ROMs -- hence the reason I'm reburning
>the system ROMs! :>]
OK. The BIOS's lack of translation is only a problem when the 16/63
translation gives more than 1024 (translated) cylinders.
>> use the BIOS geometry in fdisk. The geometry used elsewhere is almost
>> arbitrary. The driver uses 790/15/57 for simplicity. It prints 790/15/57
>> because that's the only one that it knows about. Don't use this in fdisk
>> if it differs from the BIOS geometry. OTOH, you may note that the BIOS
>> goemetry wastes about 30MB:
>>
>> 790*15*57 = 675450
>> 611*16*63 = 615888
>> wasted = 59562
>
>Yes, I have been aware of that for far too long :-( Each machine has a pair
>of 4G SCSI drives so the 30M I lose on the IDE drives is pretty insignificant.
So is the 2*300MB on the drives :-).
>> You can probably use these sectors for a non-DOS non-bootable partition
>> by telling fdisk that the geometry is 612/16/63 and being careful not
>> to use the nonexistent part of the last "cylinder".
Oops, there is more than one "cylinder" past the last, and only a small
amount of the wastage is on the partial cylinder.
790*15*57 / (16*63) = 670
so you have 670 full "cylinders" to use. You can probably use all these
cylinders, perhaps even for DOS and bootable partitions by telling fdisk
that the geometry is 670/16/63 and not using the partial cylinder. This
depends on the softare being either stupid enough to not check cylinder
numbers against the 612 limit or smart enough to know that this limit
is wrong.
>> Your probably may actually be that the drive is jumpered to force
problem
>> 611/16/63 and broken so that it still reports 790/15/57. Some ESDI
>
>No, the native drive geometry is 790/15/57. It is INITed by the
>BIOS to 611/16/63. This is the geometry that it actually *uses*.
>The IDENTIFY command returns the *default* geometry **AND** the
>*apparent* geometry. The existing code ignores the apparent
>geometry in favor of the default geometry (in fact, the wdparams
>struct doesn't even acknowledge the presence of the apparent geometry
>parameters).
This is because the driver only knows about old standards where the
apparent geometry parameters didn't exist. Using these parameters
would either break the support for old drives or complicate the driver
(it's not easy to determine drive capabilities, because old standards
didn't have reliable capability bits).
>As such, the drive is doing exactly what it is supposed
>to do -- reporting it's *default* geometry even though it is configured
>with a different geometry.
And the driver is doing exactly what it is supposed to do - ignoring
the current geometry.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703171835.FAA22959>