From owner-freebsd-hackers  Tue Jul  6  4: 2:30 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3])
	by hub.freebsd.org (Postfix) with ESMTP id 4D40515223
	for <hackers@FreeBSD.ORG>; Tue,  6 Jul 1999 04:02:19 -0700 (PDT)
	(envelope-from eischen@vigrid.com)
Received: (from eischen@localhost)
	by pcnet1.pcnet.com (8.8.7/PCNet) id HAA24567;
	Tue, 6 Jul 1999 07:01:16 -0400 (EDT)
Date: Tue, 6 Jul 1999 07:01:16 -0400 (EDT)
From: Daniel Eischen <eischen@vigrid.com>
Message-Id: <199907061101.HAA24567@pcnet1.pcnet.com>
To: mjacob@feral.com, nick.hibma@jrc.it
Subject: Re: CAM: delaying new commands during reset
Cc: hackers@FreeBSD.ORG
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Nick Hibma wrote:
>  > I'm not sure what you mean by 'Busy' here, but it doesn't matter I
>  > believe- the  cam_periph_async called with
> 
> CAM actions come in and initiate one or more USB transfers. When the
> action has completed or failed, xpt_done() is called to mark the ccb as
> completed. If the command has failed, the umass driver initiates a bus
> reset that takes a while to complete.  In the meantime CAM tries to
> submit new actions that fail because the subsystem is busy. Those
> commands have to be delayed until the reset has completed.

In this case, you're suppose to use xpt_freeze_simq() or xpt_freeze_devq().
This will stop commands from being issued to the bus (simq) or device
(devq) while the bus/device reset is being processed.  After the reset,
you can then use xpt_release_simq()/xpt_release_devq() to allow commands
to be sent once again.

During a bus/device queue freeze, I think it is safe to mark pending
CCBs to be resent (the xpt layer shouldn't resend them until you
unfreeze the queue).

Dan Eischen
eischen@vigrid.com


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