From: Luben Tuikov <luben_tuikov@adaptec.com>
To: dougg@torque.net
Cc: James Bottomley <James.Bottomley@SteelEye.com>,
SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH] add SCSI reset ioctls to scsi_ioctl.c (and sd and sr)
Date: Mon, 20 Sep 2004 10:53:59 -0400 [thread overview]
Message-ID: <414EEF07.5010701@adaptec.com> (raw)
In-Reply-To: <414E6F3E.4070502@torque.net>
> Perhaps there should be a new reset called:
> ...RESET_LOGICAL_UNIT
>
> as this is now defined as a task management function in SAM-3.
> If so ...RESET_DEVICE might get a synonym: ...RESET_TARGET.
> Most transports support a RESET_TARGET while RESET_BUS is
> SPI specific (is there an FCP equivalent?).
Very good idea. Most likely TMF LU Reset should be
directly addressable to the LLDD, either via a separate
LLDD stub or through a common LLDD::int do_tmf(int tmf, void *data)
stub, so that the LLDD knows LU Reset is wanted.
The point is that the LLDD (and the target on the other end)
would know best how to do this (and other) TMFs. (More so
for newer protocols/transports.)
As to FCP, why not just do I_T Nexus loss or Transport
Reset (best). Ref. SAM3r13, sec 6 and FCP3r3c (4.9, 4.11, 4.12).
And possibly have the SCSI events into SCSI Core, for
all types of transports.
So, recovery would resolve to issuing a TMF (or two)
and if this doesn't work _and_ we haven't gotten a SCSI event,
we can _force_ an event, else we just act on the
event gotten.
Luben
P.S. We have to allow LLDDs, to mask out
"forcing" of those events, as the recovery thread
in SCSI Core shouldn't be so "trigger happy".
prev parent reply other threads:[~2004-09-20 14:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-18 16:57 [PATCH] add SCSI reset ioctls to scsi_ioctl.c (and sd and sr) James Bottomley
2004-09-18 19:49 ` Kai Makisara
2004-09-19 2:39 ` James Bottomley
2004-09-20 5:48 ` Douglas Gilbert
2004-09-20 13:49 ` James Bottomley
2004-09-20 14:53 ` Luben Tuikov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=414EEF07.5010701@adaptec.com \
--to=luben_tuikov@adaptec.com \
--cc=James.Bottomley@SteelEye.com \
--cc=dougg@torque.net \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox