Subject: Re: Can't partition and format Sun3 disk
To: None <>
From: Perry Hutchison <>
List: port-sun3
Date: 12/30/1995 12:07:24
> Well, since I couldn't use NetBSD to format the disk, I finally got a SunOS
> boot tape and tried to use the "format" utility on that. Unfortunately, the
> Emulex bridge board kept reporting errors when trying to write the defect
> list. The reason, it appears, is an off-by-one error in the Sun formatting
> software: it numbers the cylinders starting from zero, while Emulex and the
> disk drive manufacturer number them from 1. Thus, the software tries to
> write things to the wrong places and fails.

I have not yet got around to doing anything with NetBSD, but I can help
with this one.  There are two or perhaps three workarounds:

1. If your drive's geometry matches one of the Sun-supplied built-ins,
   tell format to use the built-in type.  AFAIK the built-ins work.

2. When low-level formatting for the first time, lie to format about
   the size of the drive:  tell it several more cylinders than actually
   exist.  This will cause the low-level to run until it reaches the
   physical cylinder limit, whereupon it will fail but the disk will
   have been formatted.  At this point you "should" be able to switch
   to the NetBSD install tape.

3. Related to #1, did you construct a format.dat entry for your drive,
   or just enter its parameters under type "other"?  If the latter, try
   the former as the bug may be related to the handling of "other".

> It's also off by one cylinder when it records the positions of
> defects during surface analysis.

This is more worrisome.  NetBSD "should" include a surface analysis
utility along with other components of bad block handling (including
grown defects), since the PC port needs to support such things as MFM
and ESDI controllers.  For that matter, the PC port "should" have a
low-level format program.

> > I don't believe that there is any bad block information in the BSD
> > disklabel. On EDSI drives, bad block information is written by the
> > manufacturer in cylinder 4095 (or cylinder 65535 if you're using
> > extended addressing), but I'd gathered that the SCSI controller
> > was supposed to compensate for this sort of thing automatically.

SunOS writes its bad list (which may include defects that were not in
the manufacturer's list) on the "alternate" tracks.  The sun3 and sparc
ports of NetBSD need to support this if disks are to be interchangeable
between SunOS and NetBSD.