Date: Wed, 14 Apr 1999 14:37:53 -0600 (MDT) From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> To: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) Cc: scsi@FreeBSD.ORG Subject: Re: timed out while idle? Message-ID: <199904142037.OAA13777@narnia.plutotech.com> In-Reply-To: <199904140231.UAA07250@panzer.plutotech.com> <199904140646.XAA56124@silvia.hip.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <199904140646.XAA56124@silvia.hip.berkeley.edu> you wrote: > * There's no way to get it back without rebooting. Rescanning won't help > * you, since that finds devices that have appeared, changed or gone away. > * Your device hasn't done that, it has stopped responding. It's dead. If > * you think it should be done otherwise, talk to the author of the da(4) > * driver. :) (no, it's not me) > > * Copyright (c) 1997 Justin T. Gibbs. That's not entirely true. The device will come back if it transitions through final close (e.g you umount -f all filesystems referencing it). Further, the code that usually causes the disk pack to be invalidated is in cam_periph.c:cam_periph_error() where a selection timeout causes us to receive an ENXIO error. I believe that invalidating the pack is the correct thing to do since we have no way of determining if the media or device are the same, but that we should be retrying things like selection timeouts in a more sane fashion so that invalidations are a rarity. > Oh, ok. ;) > > Well, all I know is that when pack is invalidated, most of the times > it will come back with a reboot of the PC. Since our disks are in > external enclosures, this means the SCSI bus reset (possibly several > of them) woke them up. Many devices will be slow to acknowledge a selection after they've been bullied about by the recovery code. This is probably what caused the device to be invalidated. > I'm wondering if it makes a sense to add an option to camcontrol to > revalidate it explicitly when the operator is confident that the disk > is back. What do you think, Justin? Its not CAM behavior, its da behavior. It would be a da(4) ioctl. If you'd like to add such and ioctl and a utility to toggle it, be my guest. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904142037.OAA13777>