Date: Wed, 2 Apr 1997 08:40:04 -0700 (MST) From: Don Yuniskis <dgy@rtd.com> To: bde@zeta.org.au (Bruce Evans) Cc: freebsd-hackers@freefall.FreeBSD.org (FreeBSD hackers), terry@lambert.org Subject: Re: wd driver questions Message-ID: <199704021540.IAA07901@seagull.rtd.com> In-Reply-To: <199703171835.FAA22959@godzilla.zeta.org.au> from "Bruce Evans" at Mar 18, 97 05:35:57 am
next in thread | previous in thread | raw e-mail | index | archive | help
It seems that Bruce Evans said: > > >> 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. Ah, OK... I had assumed :-( they were just the IDE drives since I was looking through the wd driver... > >> 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. But the wd probe shouldn't (?) need to reINIT the drive regardless of which BIOS drive it is, should it? Why does it even *care* which BIOS drive it is? > >> 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. I guess this is the IDE/EIDE issue? > >> 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 :-). Um, yes. But, the 300M drives are internal and allow the system to run nicely in the event the external drives are not attached, broke or SCSI failures, etc. > >> 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. I'm working on an "easier" solution: patch the ROMs to support the "correct" geometries! :> > >> 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). Ah, OK. But, why does the probe even *care* what the drive's geometry happens to be? *If* you assume that the drive is already INITted, is there any real need to "guess" at the correct geometry and reINIT the drive? > >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. Again, *why*? --don
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704021540.IAA07901>