Date: Tue, 16 Jan 1996 06:05:21 +1100 From: Bruce Evans <bde@zeta.org.au> To: miff@spam.frisbee.net.au, phk@critter.tfs.com Cc: hackers@freebsd.org Subject: Re: location of bad144 table Message-ID: <199601151905.GAA05923@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601151905.GAA05923>