From owner-freebsd-scsi  Tue Apr 13 23:48:48 1999
Delivered-To: freebsd-scsi@freebsd.org
Received: from stampede.cs.berkeley.edu (stampede.CS.Berkeley.EDU [128.32.45.124])
	by hub.freebsd.org (Postfix) with ESMTP id DE8E514D85
	for <scsi@FreeBSD.ORG>; Tue, 13 Apr 1999 23:48:46 -0700 (PDT)
	(envelope-from asami@cs.berkeley.edu)
Received: from silvia.hip.berkeley.edu (sji-ca14-50.ix.netcom.com [205.186.215.50]) by stampede.cs.berkeley.edu (8.8.7/8.7.3) with ESMTP id XAA15856; Tue, 13 Apr 1999 23:46:52 -0700 (PDT)
Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.9.2/8.6.9) id XAA56124; Tue, 13 Apr 1999 23:46:22 -0700 (PDT)
Date: Tue, 13 Apr 1999 23:46:22 -0700 (PDT)
Message-Id: <199904140646.XAA56124@silvia.hip.berkeley.edu>
X-Authentication-Warning: silvia.hip.berkeley.edu: asami set sender to asami@cs.berkeley.edu using -f
To: ken@plutotech.com
Cc: scsi@FreeBSD.ORG
In-reply-to: <199904140231.UAA07250@panzer.plutotech.com> (ken@plutotech.com)
Subject: Re: timed out while idle?
From: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami)
References:  <199904140231.UAA07250@panzer.plutotech.com>
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

 * From: "Kenneth D. Merry" <ken@plutotech.com>

 * Yeah, I think you can safely do that.  You may be able to get away with
 * cranking it down to 10 seconds or so.

Ok.  DA_DEFAULT_TIMEOUT, right?

 * Right, it's hard to say how the rest of the system will respond.
 * Sometimes, if it happens on your swap drive, you'll see something that goes
 * like "swap_pager:  indefinite wait buffer" or something like that.

Well, our system disks are IDE at the moment so that won't happen.
(Although I've seen that particular message for IDE disk failures.)
It's usually just the "timed out" messages follewed by a panic.

By the way, looking at aic7xxx.c, in this code snippet:

===
	printf("SCB 0x%x - timed out ", scb->hscb->tag);
	/*
	 * Take a snapshot of the bus state and print out
	 * some information so we can track down driver bugs.
	 */
	bus_state = ahc_inb(ahc, LASTPHASE);

	switch(bus_state)
	{
	case P_DATAOUT:
 :
	case P_BUSFREE:
		printf("while idle, LASTPHASE == 0x%x",
			bus_state);
		break;
===

Since the switch statement is on bus_state, isn't it kinda redundant
to print it out again as "LASTPHASE"?  (Of course it's ok if that's
what you intended, I was just wondering if it's a typo of something
else.)

 * 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.

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.

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?

Satoshi


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message