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@xxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
