From: Hannes Reinecke <hare@suse.de>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: SCSI Mailing List <linux-scsi@vger.kernel.org>,
"Tarte, Robert" <Robert_Tarte@adaptec.com>
Subject: Re: [PATCH 1/4] aic79xx: Fixup external device reset
Date: Wed, 25 Oct 2006 09:01:10 +0200 [thread overview]
Message-ID: <453F0BB6.2020508@suse.de> (raw)
In-Reply-To: <1161733051.7104.37.camel@mulgrave.il.steeleye.com>
James Bottomley wrote:
> On Mon, 2006-10-23 at 15:22 +0200, Hannes Reinecke wrote:
>> + /* Hand-craft TUR command */
>> + ahd_outb(ahd, SCB_CDB_STORE, 0);
>> + ahd_outb(ahd, SCB_CDB_STORE+1, 0);
>> + ahd_outb(ahd, SCB_CDB_STORE+2, 0);
>> + ahd_outb(ahd, SCB_CDB_STORE+3, 0);
>> + ahd_outb(ahd, SCB_CDB_STORE+4, 0);
>> + ahd_outb(ahd, SCB_CDB_STORE+5, 0);
>> + ahd_outb(ahd, SCB_CDB_LEN, 6);
>> + scb->hscb->control &= ~(TAG_ENB|SCB_TAG_TYPE);
>> + scb->hscb->control |= MK_MESSAGE;
>> + ahd_outb(ahd, SCB_CONTROL, scb->hscb->control);
>> + ahd_outb(ahd, MSG_OUT, HOST_MSG);
>> + ahd_outb(ahd, SAVED_SCSIID, scb->hscb->scsiid);
>
> What's the reason for having to have this hand crafted test unit ready?
>
I asked myself the same question. It's actually from the original
adaptec sources, and i couldn't figure out why it was need, either.
That's why I removed it initially when doing the first round of external
device reset patches.
Thing is whenever we send a SCB with the MK_MESSAGE flag set the
sequencer will interrupt normal SCB delivery and ensure that the
MK_MESSAGE SCB is sent immediately. Plus we can force the connection to
non-packetized transfer as the resetted target will start out with
normal transfers, too. And as we already have invalidated the
negotiation settings for all targets a renegotiation will happen when
this TUR is completed.
So the normal flow of operation can continue and only one command will
have to be requeued from the midlayer.
I think. Or that's what I've glanced from the sequencer code. Maybe Rob
can give some more insight here.
Admittedly, this is really a nasty tweaking. In theory we should have a
proper error handler which handles this sort of thing. But the entire
code is littered with such tweakings so that's quite a vain hope.
Unless someone passes me a theory of operation document for it.
Having a register description is quite pointless.
Cheers,
Hannes
--
Dr. Hannes Reinecke hare@suse.de
SuSE Linux Products GmbH S390 & zSeries
Maxfeldstraße 5 +49 911 74053 688
90409 Nürnberg http://www.suse.de
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2006-10-25 7:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-23 13:22 [PATCH 1/4] aic79xx: Fixup external device reset Hannes Reinecke
2006-10-24 23:37 ` James Bottomley
2006-10-25 2:49 ` Sean Bruno
2006-10-25 7:01 ` Hannes Reinecke [this message]
2006-10-25 15:14 ` James Bottomley
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=453F0BB6.2020508@suse.de \
--to=hare@suse.de \
--cc=James.Bottomley@SteelEye.com \
--cc=Robert_Tarte@adaptec.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.