From nemesis!uhclem@fw.ast.com  Tue Nov 28 21:20:04 1995
Received: from ast.com (irvine.ast.com [165.164.128.2])
          by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id VAA11181
          for <FreeBSD-gnats-submit@freebsd.org>; Tue, 28 Nov 1995 21:20:02 -0800
Received: from fw.ast.com by ast.com with SMTP id AA04943
  (5.67b/IDA-1.5 for <FreeBSD-gnats-submit@freebsd.org>); Tue, 28 Nov 1995 21:21:18 -0800
Received: from nemesis by fw.ast.com with uucp
	(Smail3.1.29.1 #4) id m0tKeYB-00008DC; Tue, 28 Nov 95 22:55 CST
Received: by nemesis.lonestar.org (Smail3.1.27.1 #20)
	id m0tKdxR-000CQlC; Tue, 28 Nov 95 22:17 WET
Message-Id: <m0tKdxR-000CQlC@nemesis.lonestar.org>
Date: Tue, 28 Nov 95 22:17 WET
From: uhclem%nemesis@fw.ast.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: Inst gripes about geometry but won't accept true values FDIV040
X-Send-Pr-Version: 3.2

>Number:         848
>Category:       misc
>Synopsis:       Inst gripes about geometry but won't accept true values FDIV040
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    jkh
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Nov 28 21:30:03 PST 1995
>Closed-Date:    Mon Oct 14 12:06:04 PDT 1996
>Last-Modified:  Mon Oct 14 12:07:12 PDT 1996
>Originator:     Frank Durda IV
>Release:        FreeBSD 2.1-STABLE i386
>Organization:
That costs extra
>Environment:

2.1.0-RELEASE (or STABLE?)
System consists of a 540Meg IDE and 2.0GB SCSI.  Boots from IDE.
SCSI Adapter is a Adaptec 1540B, latest firmware and microcode.
BIOS boots from the IDE and has no CMOS settings for the SCSI devices.

>Description:

During the installation, the SCSI drive was partitioned.
The partition software complains that the geometry is not correct
and that it should be corrected or terrible things will happen.

Using the "G" command, the correct values are entered, ie  2707 cylinders,
19 heads, 81 sectors (per manufacturers data sheet for a Seagate ST12550N).
After the data is entered, the partition software again says that the
geometry is not correct and the same values that were there before
reappear (2039/64/32), along with messages warning of woe and disaster
somewhere down the road should you not use the "G"eometry command to set
the correct values.  Trying again gets you the same result and the data
you enter is discarded.

Interestingly, the internally computed values 2039x64x32 equal 4,175,872
blocks,  which is greater than 2707x19x81==4,166,073.  This looks (on
the surface) like a really bad thing, as we may have computed a block count
greater than the true size of the media, and then later the system will
attempt to write who-knows-what out there.  In the case of this particular
drive, the 81 sectors per track is the average rounded-down (according to
the data sheet), so there is some slop and the true user sector count was
4,177,781 so even the "bogus" numbers still work. 

In reality, I suspect the drive returns the true block count and
it is divided against the hardwired 64 and 32, yielding 2039 as the
closest number that fits.   It would be nice if the user could give the
system the vendor recommended numbers, particularly when the software
currently encourages the user to do this.  On some types of drives, the
user could end up with less usable space on the drive because of these
hardwired values.  I got lucky.


>How-To-Repeat:

Try to set the settings to the true dimensions of a drive where these
are different than the %d/64/32 that the partition program seems to be
stuck on.

>Fix:
	
Choose:
   1.	Fix the partition software (also disklabel utility) to accept
	the real values for that drive.

or 2.	Change the warnings to say the system is substituting these values
	and they are close and might give you a bit more space or might
	give you less, and everything will be fine, rather than implying
	that something bad will happen if you can't cram the real settings
	into the software (which apparently you can't).   It would
	also be nice if the system explained what magical hat these various
	numbers (64 & 32) were being pulled from as well.
	If input to the "G" command can't be accepted even when it is valid,
	you might as well pull the command.

or 3.	Both 1 and 2.

This step in the installation could really throw a lot of people trying
to install for the first time, and it only seems to do this to people with
SCSI drives, which are supposed to be the drives of choice for FreeBSD.
We need to make this more friendly in a big way.

*END*

>Release-Note:
>Audit-Trail:

From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org>
To: uhclem%nemesis@fw.ast.com
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: misc/848: Inst gripes about geometry but won't accept true values FDIV040 
Date: Wed, 29 Nov 1995 07:34:00 -0800

 >2.1.0-RELEASE (or STABLE?)
 >System consists of a 540Meg IDE and 2.0GB SCSI.  Boots from IDE.
 >SCSI Adapter is a Adaptec 1540B, latest firmware and microcode.
 >BIOS boots from the IDE and has no CMOS settings for the SCSI devices.
 >
 >>Description:
 >
 >During the installation, the SCSI drive was partitioned.
 >The partition software complains that the geometry is not correct
 >and that it should be corrected or terrible things will happen.
 >
 >Using the "G" command, the correct values are entered, ie  2707 cylinders,
 >19 heads, 81 sectors (per manufacturers data sheet for a Seagate
 ST12550N).
 
 This is not the geometry you should be entering.  For any Adaptec
 controller in standard translation mode (<= 1 gig drive or "support
 DOS drives greater than 1 gig" disabled), the geometry exported by
 the card is 64heads, 32sec/track, #MB reported by the probe for the
 drive cylinders.  The capacity of the drive, your controller, and
 your controller settings determine the correct geometry, not the
 real geometry of the drive.
 
 >After the data is entered, the partition software again says that the
 >geometry is not correct and the same values that were there before
 >reappear (2039/64/32), along with messages warning of woe and disaster
 >somewhere down the road should you not use the "G"eometry command to set
 >the correct values.  Trying again gets you the same result and the data
 >you enter is discarded.
 
 I don't rememeber the order for values in that dialog, but I thought that
 the number of heads came first.  If you use the huristic I mention above,
 you should get the correct geometry.
 
 >>Fix:
 >	
 >Choose:
 >   1.	Fix the partition software (also disklabel utility) to accept
 >	the real values for that drive.
 
 You didn't supply the correct geometry.  If it had accepted your values,
 you wouldn't be able to boot off of that drive.
 
 >or 2.	Change the warnings to say the system is substituting these values
 >	and they are close and might give you a bit more space or might
 >	give you less, and everything will be fine, rather than implying
 >	that something bad will happen if you can't cram the real settings
 >	into the software (which apparently you can't).   It would
 >	also be nice if the system explained what magical hat these various
 >	numbers (64 & 32) were being pulled from as well.
 >	If input to the "G" command can't be accepted even when it is valid,
 >	you might as well pull the command.
 
 I have no idea where 2.1 gets its numbers from, but the real solution is
 to beef up our boot sequence so we can properly save the BIOS values
 for all drives and use a "drive marking scheme" compatible with NT so
 that we can do an acurate mapping of geometry to device.
 
 >or 3.	Both 1 and 2.
 >
 >This step in the installation could really throw a lot of people trying
 >to install for the first time, and it only seems to do this to people with
 >SCSI drives, which are supposed to be the drives of choice for FreeBSD.
 >We need to make this more friendly in a big way.
 
 Agreed.  Its been a long standing problem.
 
 --
 Justin T. Gibbs
 ===========================================
   FreeBSD: Turning PCs into workstations
 ===========================================

From: J Wunsch <j@uriah.heep.sax.de>
To: uhclem%nemesis@fw.ast.com
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: misc/848: Inst gripes about geometry but won't accept true values FDIV040
Date: Thu, 30 Nov 1995 01:10:24 +0100 (MET)

 As uhclem%nemesis@fw.ast.com wrote:
 > 
 > 
 > Interestingly, the internally computed values 2039x64x32 equal 4,175,872
 > blocks,  which is greater than 2707x19x81==4,166,073.  This looks (on
 > the surface) like a really bad thing, as we may have computed a block count
 > greater than the true size of the media, and then later the system will
 > attempt to write who-knows-what out there.  In the case of this particular
 > drive, the 81 sectors per track is the average rounded-down (according to
 > the data sheet), so there is some slop and the true user sector count was
 > 4,177,781 so even the "bogus" numbers still work. 
 
 For SCSI disk, libdisk rounds the true disk size (as obtained from the
 disk) down to what it thinks is the closest cylinder boundary below.
 No harm can happen for non-bootable drives.
 
 (For FreeBSD-only disks, you can even use the entire disk capacity
 with the ``dangerously dedicated'' option.  C/H/S is effectively
 ignored then.)
 
 However, i agree that the warning is bogus and confuses the users.
 
 -- 
 cheers, J"org
 
 joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
 Never trust an operating system you don't have sources for. ;-)
Responsible-Changed-From-To: freebsd-bugs->jkh 
Responsible-Changed-By: scrappy 
Responsible-Changed-When: Sun Jun 2 13:31:20 PDT 1996 
Responsible-Changed-Why:  
sysinstall bug? 
State-Changed-From-To: open->closed 
State-Changed-By: jkh 
State-Changed-When: Mon Oct 14 12:06:04 PDT 1996 
State-Changed-Why:  
This is fixed now, at least as well as I can fix it in sysinstall. 
>Unformatted:
