RE: SCSI_OWNER_LOWLEVEL, scsicmd->owner & scsicmd->state visibility in the LLD

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Answer was not forthcoming regarding deprecation of scsicmd->owner and
scsicmd->state, thus no API to determine if the command is currently
owned by the low level driver. Need to move this functionality into the
driver, so can I count on scsicmd->SCp.phase sticking around?

For example:

static int aac_queuecommand(struct scsi_cmnd *cmd, void (*done)(struct
scsi_cmnd *))
{
	cmd->scsi_done = done;
	. . .
	cmd->SCp.phase = 1;

And every interrupt callback handler:
	. . .
	cmd->SCp.phase = 2;
	. . .
	cmd->scsi_done(scsicmd);

And in the reset handler that returns commands to the host:

__shost_for_each_device(dev, host) {
      	spin_lock_irqsave(&dev->list_lock, flags);
      	list_for_each_entry(command, &dev->cmd_list, list)
			if (command->SCp.phase == 1)

Sincerely -- Mark Salyzyn


-----Original Message-----
From: linux-scsi-owner@xxxxxxxxxxxxxxx
[mailto:linux-scsi-owner@xxxxxxxxxxxxxxx] On Behalf Of Salyzyn, Mark
Sent: Thursday, August 25, 2005 4:20 PM
To: linux-scsi
Subject: SCSI_OWNER_LOWLEVEL, scsicmd->owner & scsicmd->state visibility
in the LLD


The aacraid driver does not maintain a list of outstanding commands to
the controller. The 'active' list is effectively maintained by the
controller Firmware state that reports back an index upon completion to
the 'active FIB' so that it may be placed back into the free list.

I want to add a means to reset the adapter (typically when it faults),
late model firmware offers an IOP_RESET command. I will be resetting the
adapter in the eh_handler context, ioctl context (for legacy kernels),
sysfs context and in a background kernel watchdog thread observing
adapter health indicators.

The problem is I must complete all outstanding commands in the
controller ala:

	command->result = DID_OK << 16 | COMMAND_COMPLETE << 8 |
SAM_STAT_TASK_SET_FULL;
	command->scsi_done(command);

In the name of performance (not maintaining two active lists, the one in
the scsi layer, and another in the driver) I noticed that I can discern
the commands that should be completed at Adapter Reset as:

	__shost_for_each_device(dev, host) {
      	spin_lock_irqsave(&dev->list_lock, flags);
      	list_for_each_entry(command, &dev->cmd_list, list)
			if (command->request &&
			  command->request->rq_status != RQ_INACTIVE &&
/* All commands that are active */
			  command->owner == SCSI_OWNER_LOWLEVEL &&
/* All commands owned by the driver */
			  command->state != SCSI_STATE_FAILED)
/* Remove any commands that have made it into the error handler */

But I am *sure* this is misplaced since command->state usage is
deprecated in recent cleanup patches, and command->owner's manifests are
maintained in .../drivers/scsi/scsi_priv.h probably (?) to obscure them
from the driver's view. (NOTE: 2.4 kernels 'command->request &&
command->request->rq_status != RQ_INACTIVE' with
'command->serial_number')

Is there an 'approved' API to acquire the low level driver outstanding
list, subtracting the commands that are already on the road to
completion but are tied up in the error handler? Is there an 'approved'
style to complete commands safely *within* the above loop, or must I do
it outside the loop?

Sincerely -- Mark Salyzyn
-
: 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
-
: 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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux