Date: Mon, 17 Mar 1997 08:48:28 -0700 (MST) From: Don Yuniskis <dgy@rtd.com> To: bde@zeta.org.au (Bruce Evans) Cc: dgy@rtd.com, terry@lambert.org, bde@zeta.org.au, hackers@freebsd.org, helbig@MX.BA-Stuttgart.De Subject: Re: wd driver questions Message-ID: <199703171548.IAA11675@seagull.rtd.com> In-Reply-To: <199703171311.AAA12416@godzilla.zeta.org.au> from "Bruce Evans" at Mar 18, 97 00:11:03 am
next in thread | previous in thread | raw e-mail | index | archive | help
It seems that Bruce Evans said: > > >Yes, I don't understand why FBSD can't just use the same geometry > >settings that boot.c deduces? Are the BIOS ROMs no longer accessible > >once boot() has completed (sorry, my ignorance is showing...)? > > 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)? > 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... > 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? > which is to guess, and if the guess doesn't work then require the user > to type in the correspondence, e.g., > > 1:sd(0,a) > ^ ^^^^ (BIOS drive number 1 = FreeBSD drive name sd0) > > boot.c could pass the mapping for the boot drive, but the kernel would > have to do it for the other drives. This is not much simpler for users > than just typing in the correct geometry. > > >> equal, it doesn't matter. Where it seems to matter, you can look > >> for the FreeBSD partition, the DOS boot block to find the boot device, > >> or, if all else fails, ask the user (instead of asking by default). > > > >Why *should* there be a difference? I would assume that you would > >err on the side of adhering to the BIOS geometry -- wouldn't > >adopting some *other* geometry make it tough (impossible?) > >to have a DOS partition on the same drive as FBSD and be able to > >*access* that DOS partition from FBSD? > > The driver just uses the geometry reported by the drive. This is simple > and works in all known cases where the drive reports it geometry. There > is no reason to use the same geometry as the BIOS and many reasons not > to (e.g., the BIOS can't handle more than 1024 cylinders and some BIOSes > can't translate so that there are <= 1024 cylineders, and some translations > waste a lot of disk space, and translation is impossible for disks larger > than about 8GB (except by wasting everything above 8GB)). > > >> Also if it is writing C/H/S values for use by the DOS MBR to get to > >> the BSD second stage boot, since the DOS MBR (incorrectly) looks at > >> the C/H/S values instead of the LBA values (since the DOS MBR has the > >> DOS geometry available, factoring an LBA to a C/H/S value is easy for > >> it to do, but it is too badly designed to do that). > > > >I think this is the problem I've currently been having -- DOS thinks > >the drive is 611/16/63 but FBSD reINITs it to 790/15/57. It's been > >tough trying to get DOS and FBSD to fit onto the same drive... > > 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! :>] > 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. > 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". > > Your probably may actually be that the drive is jumpered to force > 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). 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. > drives had this problem. I hope they are dead now (one I bought in > 1990 cost 4 times as much as a modern IDE drive for 1/12 as much space, > 1/10 as much performance, and 1/10 as much reliability). Yes. I guess if you *really* want the best deal, you should *never* buy anything -- since it will always get better and cheaper! :> I think I paid the same for my 4G SCSI drives as I did for the 300M IDE drives! :-( I wasn't suggesting anything other than using the *apparent* device geometry figures to determine the drive's geometry. My thinking was that the current geometry of the drive would be reflected therein. --don
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703171548.IAA11675>