From owner-freebsd-bugs  Sat Oct 26 20:00:04 1996
Return-Path: owner-bugs
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id UAA29877
          for bugs-outgoing; Sat, 26 Oct 1996 20:00:04 -0700 (PDT)
Received: (from gnats@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id UAA29867;
          Sat, 26 Oct 1996 20:00:02 -0700 (PDT)
Date: Sat, 26 Oct 1996 20:00:02 -0700 (PDT)
Message-Id: <199610270300.UAA29867@freefall.freebsd.org>
To: freebsd-bugs
Cc: 
From: Bruce Evans <bde@zeta.org.au>
Subject: Re: i386/1893: partition tables not processed correctly to guess geometry
Reply-To: Bruce Evans <bde@zeta.org.au>
Sender: owner-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

The following reply was made to PR i386/1893; it has been noted by GNATS.

From: Bruce Evans <bde@zeta.org.au>
To: barry@scottb.demon.co.uk, FreeBSD-gnats-submit@freebsd.org
Cc:  Subject: Re: i386/1893: partition tables not processed correctly to guess geometry
Date: Sun, 27 Oct 1996 13:46:33 +1100

 >>Synopsis:       partition tables not processed correctly to guess geometry
 >>Confidential:   no
 >>Severity:       critical
 >>Priority:       high
 
 I fixed this in my own version a month or two ago, but assigned it a lower
 priority :-).
 
 >>Description:
 >
 >	John Gumb and myself are experimenting with supporting the Fujitsu
 >	640MB MO drives at the 2048 sector size. We found that FreeBSD does
 >	not process partition tables correctly to size a disk. The following
 >	code at line 253 in diskslice_machdep.c is badly broken. It is 
 >	supposed to calculate the max number of cylinders but infact reports
 >	the number of cylinders in the 4th slot.
 >...
 >>How-To-Repeat:
 >
 >	Make partition slot 4 describe a small part of the whole disk.
 >	Then the orginal code will get the size of the disk wrong.
 
 Also: use a drive that doesn't report it size.  Such drives aren't very
 common.  The include:
 
 	old MFM
 	some ESDI?
 	other ESDI that report the wrong size
 	SCSI Zip
 	Fuljitsu 640MB MO (apparently :-)
 
 It's common for slot 4 to be empty, giving max_ncyls = 0, but this is
 normally corrected later by ignoring max_ncyls and keeping the old
 value of lp->d_secperunit.
 
 >	We do not know what the full impact of this bug is. Is this
 
 It's fairly small.  max_ncyls is always wrong for drives with more
 than 1024 cylinders, so you have to enter the number of cylinders
 manually in sysinstall etc. if the drive doesn't report its size.
 In any case, the number of cylinders isn't critical.  One good way
 to handle it is to enter a huge value for it to defeat any bounds
 checking related to it and then enter all sizes in sectors, being
 careful not to use more sectors than the disk has.  (The calculation
 of it could be improved to something like (ending_absolute_sector +
 1) / max_nsectors / max_ntracks in some cases.)
 
 >	related to the "random" MSDOS problems some people see?
 
 Probably not.
 
 There is a more serious problem: the results of check_part()
 are essentially never used unless the system is booted with -v.
 The checks found too many previously botched installations so they
 were made non-fatal.  You were supposed to read the error messages and
 decide what to do.  Then someone turned off the error messages :-(.
 The results of check_part() should be used at least for guessing
 the geometry.
 
 Bruce