Date: Tue, 27 Feb 1996 08:43:12 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, ghudson@mit.edu Cc: darrenr@cyber.com.au, etheisen@ozzy.MIT.EDU, etheisen@teclink.net, freebsd-bugs@FreeBSD.org, port-i386@NetBSD.ORG Subject: Re: Incompatible slices. Message-ID: <199602262143.IAA24553@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> No, only the FreeBSD sysinstall, fdisk and boot programs use the
>> BIOS geometry. The drivers don't use it, but they attempt to
>> determine it (so that they can reporte it to sysinstall and fdisk)
>> by looking at the contents of the DOS partition table.
>I think you're confused, or perhaps only talking about SCSI disks.
No, I know too much about this problem.
>From sys/i386/boot/biosboot:
> /* Pick up the story from the Bios on geometry of disks */
> for(ret = 0; ret < N_BIOS_GEOM; ret ++)
> bootinfo.bi_bios_geom[ret] = get_diskinfo(ret + 0x80);
This gives you the BIOS geometries indexed by the BIOS drive numbers.
It can only be used if the mapping from the BIOS drive numbers to
BSD device names or numbers are known. The mapping isn't known.
>and then from sys/i386/isa/wd.c, in wdgetctlr():
> if (du->dk_unit == bootinfo.bi_n_bios_used) {
> du->dk_dd.d_secsize = DEV_BSIZE;
> du->dk_dd.d_nsectors =
> bootinfo.bi_bios_geom[du->dk_unit] & 0xff;
> [etc.]
> bootinfo.bi_n_bios_used ++;
> return 0;
> }
This code only works in the usual case of one controller with one
(master) drive or 2 drives attached to it. It probably fails for 2
controllers with one (master) drive on each and some mixture of cdroms
on the slave channels, because the BIOS numbers the drives 0 and 1 while
BSD numbers them 0 and 2. Fortunately, this code is only used for
drives that don't report their default geometry (probably never for
modern drives). There's another bug there if the first drive reports
its geometry and the others don't - bi_n_bios_used isn't incremented
for the first drive.
>> Of course, this can only work if the partition table is nonempty,
>I added code to the NetBSD fdisk to do this kind of heuristic
>calculation, and it does not rely on any de facto partition table
>conventions. It treats each partition table entry as an equation, and
>attempts to find non-degenerate equations in the partition table which
>will yield the number of sectors per track and the number of heads.
I had forgotten about this method. I think it works well iff there
is more than one partition.
>> # The following self-referential step is required
>> # because many modern SCSI BIOSes attempt to determine
>> # the geometry by looking at the partition table.
>So what do they do if there's no partition table? They have to return
>something; as long as it's a valid geometry for the disk, you should
>be able to use it and the next time the BIOS is queried for the disk
>geometry, it should return the same thing.
I'm most familiar with the BT445C controller. I think it chooses a 64
head, 32 sector geometry for empty disks even when its '> 1GB' option is
enabled, even though that is poor geometry for drives larger than 1GB.
It returned 255H 63S as soon as I repartitioned a drive from 64H 32S to
255H 63S (without changing the partition offsets or the OS's) and the
changed geometry continued to work when I moved the drive to an SC200
controller on another system. This makes sense: the geometry is a
property of the drive and the controller should handle geometries that
were defaulted to on other controllers.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602262143.IAA24553>