test at Target mode

Justin T. Gibbs gibbs at scsiguy.com
Fri Sep 7 08:55:59 PDT 2001


>> The kernel driver should handle the abort message and simply reset the
>> sequencer.  This will cause the bus to go free and program execution
>> to start from the top.
>
>When a target communicates with multilpe initiators and receive abort message,
>the target should not reset the sequencer,I think.

No state, other than that affecting the current (and aborted) transaction,
is cleared by a sequencer restart.  A restart in effect, clears all current
transaction state, goes to bus free, and enters the idle loop to look for
new transactions to process.  It matters little whether there are multiple
initiators talking to the device.

>> >If it gose to host_message_loop,
>> >it invokes an INTSTAT interrupt with HOST_MSG_LOOP.
>> >Then the driver can change the registers but cannot change the route.
>>
>> The only alternate route is bus free which can be achieved by resetting
>> the sequencer (ahc_reset()).
>
>See above.

I don't understand your concern.

>Futhermore,
>I have 2 changes in my AIC7xxx driver code.
>
>1)In rare case, the following sequence occurred.
>    RSL MI=C020XX MO=0d BF
>
>    This means that initiator rejects the TAG=XX.
>    Then the driver dose not get correct TAG id.
>
> Added:  INITIATOR_TAG    ->SCB_TARGET_INFO+SCB_INITIATOR_TAG

Have you been following the example in the FreeBSD aic7xxx driver
front end for target mode?  Complete setup, including this step,
is outlined there.  Again, the Linux driver, as shipped, only has
the core support for target mode.  The setup of the transaction
is in the OSM layer.

>2) ahc_intr handler cannot get continuous CMDCMPLT interrupts.

The code was supposed to look like this:

#ifdef AHC_TARGET_MODE
                if ((ahc->flags & AHC_INITIATORROLE) != 0) {
#endif
                        ahc_run_qoutfifo(ahc);
#ifdef AHC_TARGET_MODE
                if ((ahc->flags & AHC_TARGETROLE) != 0) {
                        ahc_run_tqinfifo(ahc, /*paused*/FALSE);
#endif

but it seems I had only updated the check_cmdcmpltqueus function.
In other words, we already know that we need to service a queue.
Once we know that it is a command complete interrupt is pending,
checking the queue state again is more expensive than just calling
the function we are likely to call anyway.

--
Justin

To Unsubscribe: send mail to majordomo at FreeBSD.org
with "unsubscribe aic7xxx" in the body of the message




More information about the aic7xxx mailing list