From owner-freebsd-fs@FreeBSD.ORG Sat Mar 26 13:40:35 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B5F4106566B for ; Sat, 26 Mar 2011 13:40:35 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id D26E38FC0A for ; Sat, 26 Mar 2011 13:40:34 +0000 (UTC) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p2QDOD76002877 for ; Sun, 27 Mar 2011 00:24:13 +1100 Received: from c122-107-125-80.carlnfd1.nsw.optusnet.com.au (c122-107-125-80.carlnfd1.nsw.optusnet.com.au [122.107.125.80]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p2QDO3IE009676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Mar 2011 00:24:04 +1100 Date: Sun, 27 Mar 2011 00:24:03 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Kostik Belousov In-Reply-To: <20110326003818.GT78089@deviant.kiev.zoral.com.ua> Message-ID: <20110327000956.U1316@besplex.bde.org> References: <20110326003818.GT78089@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org Subject: Re: tying down adaX to physical interfaces X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 13:40:35 -0000 On Sat, 26 Mar 2011, Kostik Belousov wrote: > On Fri, Mar 25, 2011 at 05:21:50PM -0700, Michael DeMan wrote: >> Hi All, >> >> I seem to recall that there is a way to do this, but can no longer google it. >> >> Basically, for NCQ support with SATA devices we are using the 'ada' driver, which of course has SCSI like behavior. >> ... > I use the following stanza in /boot/device.hints for machine with intel > on-board ahci and siis in pcie: > hint.scbus.0.at="ahcich0" > hint.ada.0.at="scbus0" > hint.scbus.1.at="ahcich1" > hint.ada.1.at="scbus1" > hint.scbus.2.at="ahcich2" > hint.ada.2.at="scbus2" > hint.scbus.3.at="ahcich3" > hint.ada.3.at="scbus3" > hint.scbus.4.at="ahcich4" > hint.ada.4.at="scbus4" > hint.scbus.5.at="siisch0" > hint.ada.5.at="scbus5" > hint.scbus.6.at="siisch1" > hint.ada.6.at="scbus6" To hijack this thread a little, I'll ask how people handle removable media changing the addresses of non-removable media. I use the following to prevent USB drives stealing da0 from my 1 real SCSI disk on 1 machine: hint.scbus.0.at="sym0" hint.da.0.at="scbus0" This works OK and is easy to manage with only 1 SCSI disk. But 1 of my USB drives also steals cd0 from a not-so-real ATAPI drive under atapicam, depending on whether the USB drive is present at boot time: USB drive not present at boot time: ad* (no SCSI disks on this machine) cd0 = acd0 (but no further ATAPI drives on this machine) insert USB drive: da1 (da0 was reserved by above) cd1 (phantom ATAPI drive on the USB drive. Accessing this hangs parts of the ata system but it doesn't get used since various places only point cd0) USB drive present at boot time: ad* da1 on USB cd0 phantom on USB cd1 = acd[0 or 1] (normal cd0). Accessing cd0 now hangs parts of the ata system and this happens too easily since various places point to cd0. How do people defend agains random USB drives present or not at boot time? Bruce