From barry@scottb.demon.co.uk  Sat Oct 26 08:06:41 1996
Received: from scottb.demon.co.uk (scottb.demon.co.uk [158.152.42.64])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA00743
          for <FreeBSD-gnats-submit@freebsd.org>; Sat, 26 Oct 1996 08:06:38 -0700 (PDT)
Received: (from barry@localhost) by scottb.demon.co.uk (8.7.5/8.7.3) id QAA00610; Sat, 26 Oct 1996 16:06:08 +0100 (BST)
Message-Id: <199610261506.QAA00610@scottb.demon.co.uk>
Date: Sat, 26 Oct 1996 16:06:08 +0100 (BST)
From: Barry Alan Scott <barry@scottb.demon.co.uk>
Reply-To: barry@scottb.demon.co.uk
To: FreeBSD-gnats-submit@freebsd.org
Subject: partition tables not processed correctly to guess geometry
X-Send-Pr-Version: 3.2

>Number:         1893
>Category:       i386
>Synopsis:       partition tables not processed correctly to guess geometry
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Oct 26 08:10:01 PDT 1996
>Closed-Date:    Mon Nov 4 09:41:32 PST 1996
>Last-Modified:  Mon Nov  4 09:42:24 PST 1996
>Originator:     Barry Alan Scott
>Release:        FreeBSD 2.1-STABLE i386 and all SNAP's to date
>Organization:
None
>Environment:

	Bug is all FreeBSB since 2.1.5 atleast.

>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.

	Old code from diskslice_machdep.c around line 253:

	/* Guess the geometry. */
	/*
	 * TODO:
	 * Perhaps skip entries with 0 size.
	 * Perhaps only look at entries of type DOSPTYP_386BSD.
	 */
	max_ncyls = 0;
	max_nsectors = 0;
	max_ntracks = 0;
	for (dospart = 0, dp = dp0; dospart < NDOSPART; dospart++, dp++) {
		int	nsectors;
		int	ntracks;

>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.
	

>Fix:
	
	See above.
>Release-Note:
>Audit-Trail:

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

From: J Wunsch <j@uriah.heep.sax.de>
To: barry@scottb.demon.co.uk
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: i386/1893: partition tables not processed correctly to guess geometry
Date: Sun, 27 Oct 1996 14:21:07 +0100 (MET)

 As Barry Alan Scott wrote:
 
 > 	John Gumb and myself are experimenting with supporting the Fujitsu
 > 	640MB MO drives at the 2048 sector size. We found that FreeBSD does
 
 2 KB sectors are likely to be unsupported anyways.
 
 -- 
 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. ;-)
State-Changed-From-To: open->closed 
State-Changed-By: bde 
State-Changed-When: Mon Nov 4 09:41:32 PST 1996 
State-Changed-Why:  
Fixed in rev.1.22 of diskslice_machdep.c. 
>Unformatted:
 >bug>		max_ncyls = DPCYL(dp->dp_ecyl, dp->dp_esect);
 >bug>		if (max_ncyls < max_ncyls)
 >bug>			max_ncyls = max_ncyls;
 		nsectors = DPSECT(dp->dp_esect);
 		if (max_nsectors < nsectors)
 			max_nsectors = nsectors;
 		ntracks = dp->dp_ehd + 1;
 		if (max_ntracks < ntracks)
 			max_ntracks = ntracks;
 	}
 
 	The lines maked ">bug>" are clearly intended to read
 
 		int	ncyls;
 
 		ncyls = DPCYL(dp->dp_ecyl, dp->dp_esect);
 		if (max_ncyls < ncyls)
 			max_ncyls = ncyls;
 
 	We do not know what the full impact of this bug is. Is this
 	related to the "random" MSDOS problems some people see?
 
 	John Gumb can be contacted as john@talisker.demon.co.uk
 	Barry Scott can be contacted as barry@scottb.demon.co.uk
 	and as tsbarry@nortel.ca (atleast till 31-dec)
 
 
 
