From owner-freebsd-scsi Thu Nov 14 8:30:42 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0065437B401 for ; Thu, 14 Nov 2002 08:30:41 -0800 (PST) Received: from ida.interface-business.de (ida.interface-business.de [193.101.57.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBDA943E42 for ; Thu, 14 Nov 2002 08:30:39 -0800 (PST) (envelope-from j@ida.interface-business.de) Received: from ida.interface-business.de (localhost [127.0.0.1]) by ida.interface-business.de (8.12.5/8.12.5/ifb) with ESMTP id gAEGUbc6011458; Thu, 14 Nov 2002 17:30:37 +0100 (MET) (envelope-from j@ida.interface-business.de) Received: (from j@localhost) by ida.interface-business.de (8.12.5/8.12.5/Submit) id gAEGUari011457; Thu, 14 Nov 2002 17:30:36 +0100 (MET) (envelope-from j) Date: Thu, 14 Nov 2002 17:30:36 +0100 From: Joerg Wunsch To: "Matthew N. Dodd" Cc: scsi@FreeBSD.ORG Subject: Re: How to recover an invalidated device? Message-ID: <20021114173036.M8753@ida.interface-business.de> Reply-To: Joerg Wunsch Mail-Followup-To: "Matthew N. Dodd" , scsi@FreeBSD.ORG References: <20021114143642.I8753@ida.interface-business.de> <20021114104650.T69283-100000@sasami.jurai.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20021114104650.T69283-100000@sasami.jurai.net>; from winter@jurai.net on Thu, Nov 14, 2002 at 10:51:04AM -0500 X-Phone: +49-351-31809-14 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Organization: interface systems GmbH, Dresden Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org As Matthew N. Dodd wrote: > > Right now, the only way i know to get out of this dilemma is to unplug > > the drive again, "camcontrol rescan" so it will be removed completely, > > replug it, "camcontrol rescan" so it's known again. I think this is not > > quite optimal... Isn't there another way to get the da driver back to > > live? IMHO there should be one. > > Like 'camcontrol detach' or something? > > ftp://ftp.jurai.net/users/winter/camcontrol-detach.patch Well, i backported it to RELENG_4 (which isn't much of a problem after also MFCing the changes for camcontrol load and the split of cam_cmd/ cam_arg), and it might /almost/ be what i'm looking for, yes. Anyway: xcd6# camcontrol detach da1 (da1:ahc0:0:6:0): lost device Device detached. xcd6# camcontrol rescan 0:6:0 Re-scan of 0:6:0 was successful xcd6# camcontrol devlist at scbus0 target 0 lun 0 (pass0,da0) at scbus0 target 6 lun 0 (pass1,da1) xcd6# hd /dev/da1h hd: /dev/da1h: Device not configured I think the problem is: cam_periph_alloc: attempt to re-allocate valid device da1 rejected daasync: Unable to attach to new device due to status 0x6 vinum still holds /dev/da1h open, and there's no easy way to tell it to give up about that without either destroying its complete configuration, or unloading vinum, which is both an unreasonable thing to do in a running configuration. So we also need a way to convince CAM that the newly arrived da1 is basically the very same da1 it used to have previously, and it's completely OK to re-use that device. I wish there'd at least be a "force" option or something like that that simply tells CAM "I'm the system administrator, and I tell you to do this since I know what happened, and what I'm doing." -- J"org Wunsch Unix support engineer joerg_wunsch@interface-systems.de http://www.interface-systems.de/~j/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message