From owner-freebsd-hardware Mon Apr 1 09:41:56 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA09588 for hardware-outgoing; Mon, 1 Apr 1996 09:41:56 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA09577 for ; Mon, 1 Apr 1996 09:41:54 -0800 (PST) Received: from ccgate.infoworld.com by lserver.infoworld.com with smtp (Smail3.1.29.1 #12) id m0u3nxr-000wzLC; Mon, 1 Apr 96 10:04 PST Received: from cc:Mail by ccgate.infoworld.com id AA828380442; Mon, 01 Apr 96 10:33:58 PST Date: Mon, 01 Apr 96 10:33:58 PST From: "Brett Glass" Message-Id: <9603018283.AA828380442@ccgate.infoworld.com> To: "Justin T. Gibbs" , bde@zeta.org.au Cc: freebsd-hardware@FreeBSD.ORG, heric@aug.com Subject: Re: ASUS ncr scsi controller question Sender: owner-hardware@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The only time they are not is with boot devices where the BIOS geometry > may change. Exactly. When you change controllers, you are -- in effect -- changing BIOSes. This, in turn, can change the supported BIOS geometries and the translation scheme. Incompatibilities are most likely to occur if the controller reserves blocks for itself at the beginning or end of the drive. (This is not uncommon; it's a good way to store feature information in a nonvolatile way.) The CAM spec describes a way in which a controller can figure out what another controller was doing when it set up the drive. But as far as I know, controller vendors -- not really caring about the possibility of customers switching brands -- did not implement it widely. --Brett