Date: Wed, 13 Nov 1996 03:47:09 +1100 From: Bruce Evans <bde@zeta.org.au> To: darrylo@hpnmhjw.sr.hp.com, michaelv@MindBender.serv.net Cc: BRETT_GLASS@infoworld.com, freebsd-hardware@FreeBSD.ORG, Harlan.Stenn@pfcs.com, rschof@mccomm.nl Subject: Re: After changing to an AHA2940 I can't boot the kernel. Message-ID: <199611121647.DAA32444@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> >Most likely problem: the sector mapping on one controller is different from >> >that on the other. >> >> This is theoretically possible. But in the Real World, I have never >> seen this happen, juggling drives between a BusLogic BT747s, a BT956c, >> an Adaptec 2940UW, and an NCR 53c810. I think I mixed a 1542 in there >> a few times, too, but I'm not positive. At least Buslogics (I've only used a 445c) and NCRs (I've only used an SC200 with an ASUS P55TP4XE) seem to adapt to the geometry in the partition table. They seem to use essentially the same algorithm as FreeBSD to choose a geometry that is consistent with the partition table. I just checked this for the NCR. Initially, the partition table was garbage (the default FreeBSD partition table) and the geometry was garbage: Nov 13 01:57:57 alphplex /kernel: 1:03f7413f 0..1015=1016 cylinders, 0..65=66 heads, 1..63=63 sectors I then changed the partition table to a valid one by telling fdisk that the geometry was 9999/255/63 and entering one partition starting and ending on a cylinder boundary and covering slightly more than the whole disk (999 is not used). Then the NCR BIOS correctly decided that the geometry was 263/255/63: Nov 13 02:16:26 alphplex /kernel: 1:0106fe3f 0..262=263 cylinders, 0..254=255 heads, 1..63=63 sectors 263 is ((disk size in sectors = 4226725) / 255 / 63) rounded down. Next I did the same with 256 heads instead of 255. The NCR BIOS correctly decided that the geometry was 262:256:63: Nov 13 02:31:10 alphplex /kernel: 1:0105ff3f 0..261=262 cylinders, 0..255=256 heads, 1..63=63 sectors ISTR that the Buslogic couldn't handle this case (the Buslogic handled smaller powers of 2 OK). Next I tried a weird 9999/159/47 geometry. The NCR BIOS had no problems: Nov 13 02:42:09 alphplex /kernel: 1:02349e2f 0..564=565 cylinders, 0..158=159 heads, 1..47=47 sectors Next I tried a weird 9999/159/47 geometry with the partition ending at the end of the disk (so it doesn't end on a cylinder boundary). The NCR BIOS was confused again: Nov 13 02:48:49 alphplex /kernel: 1:03f7413f 0..1015=1016 cylinders, 0..65=66 heads, 1..63=63 sectors > I've seen it between a 1542CF and an NCR815. The Adaptec used a >C/H/S geometry like C/64/32 or C/255/63 (I forget which -- perhaps it >depends on the "support disks >1GB" setting?). My NCR815-based >controller (a DTC 3130B) appears to use a very different geometry: > > C1/H1/63, where: > H1 = int((disk_size / 63 + 1023) / 1024) > C1 = int(disk_size / (63 * H1)) > disk_size = total size of disk in sectors It seems to do this when there is garbage (or zeros) in the partition table. H1 is the smallest value that keeps C1 <= the magic 1024 limit. The formula is probably actually H1 = min(above H1, 63). > Do the NCR geometries vary from controller to controller? They vary from disk to disk :-). I usually use C/64/32 up to 1GB and C/255/63 for larger disk. C/255/63 should be used for all new disks. See the Linux large disk howto for several worse rules for determining the geometry. Some Linux drivers apparently try to duplicate what the controller's BIOS would do. All FreeBSD drivers use the same method to determine what the controller's BIOS and/or partition table installperson has done. This works better iff the partition table is nonempty. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611121647.DAA32444>