From owner-freebsd-hackers Mon Jan 15 11:09:38 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA01075 for hackers-outgoing; Mon, 15 Jan 1996 11:09:38 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA01070 for ; Mon, 15 Jan 1996 11:09:33 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id GAA05923; Tue, 16 Jan 1996 06:05:21 +1100 Date: Tue, 16 Jan 1996 06:05:21 +1100 From: Bruce Evans Message-Id: <199601151905.GAA05923@godzilla.zeta.org.au> To: miff@spam.frisbee.net.au, phk@critter.tfs.com Subject: Re: location of bad144 table Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org Precedence: bulk >> > Currently, the bad144 code in kern/subr_dkbad.c looks for the replacement >> > table on the last track of the unit, as specified by the disklabel, to wit: >> s/unit/slice/ >Oops. I wasn't using a slice table, so the difference was hidden (but >relevant) >> > Unfortunately I have a disk controller here (Adaptec 2320D) that lies about >> > how big the disk is (advertises one more cylinder than there is), and so >> > this dies in a heap. >> This is the dreaded "diagnostic cylinder" >Yah. Pain in the ass 8( >> > I suspect that I'm at a bit of a disadvantage in that I can't have these >> > disks visible to the BIOS because I'm booting from a SCSI disk. >> Just make your slice 1 (or to be safe: 2) cylinders less than the disk. >Hmm, that mandates a slice table. Oh well 8) Unfortunately, the value of d_secperunit in labels is overridden by the "known" size of the containing slice or disk. This is OK for slices (you can just reduce the size in the slice table) but not good for disks that report their size incorrectly. The size of the C partition isn't overridden unless it is too large (the compatibility code knows that certain too-large values are normal for 1.x, 2.0 and foreign disks). Perhaps d_secperunit could be handled in the same way. This is a bit dangerous because there might be garbage (small) values of d_secperunit out there. Bruce