Date: Sat, 26 Oct 1996 20:00:02 -0700 (PDT) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs Subject: Re: i386/1893: partition tables not processed correctly to guess geometry Message-ID: <199610270300.UAA29867@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610270300.UAA29867>