Autosense requirement

Autosense requirement

[Luben Tuikov]

How safe am I to assume that SCSI LLDD will return
autosense for a failed/incomplete command, as per
SCSI core (mid-layer) error handling requrement?
(e.g. ide-scsi doesn't return autosense)

In drafts I'm more and more seeing 
``targets MUST support and enable autosense.''

If indeed we put a ``MUST'' requirement on SCSI LLDD
to support and enable autosense, which will indeed
streamline things, then this will save me a an _irq_
spin lock over a simple spin lock...

What is the future of this requrement?

-- 
Luben

Re: Autosense requirement

[Douglas Gilbert]

Luben Tuikov wrote:
> 
> How safe am I to assume that SCSI LLDD will return
> autosense for a failed/incomplete command, as per
> SCSI core (mid-layer) error handling requrement?
> (e.g. ide-scsi doesn't return autosense)
> 
> In drafts I'm more and more seeing
> ``targets MUST support and enable autosense.''
> 
> If indeed we put a ``MUST'' requirement on SCSI LLDD
> to support and enable autosense, which will indeed
> streamline things, then this will save me a an _irq_
> spin lock over a simple spin lock...
> 
> What is the future of this requrement?

Luben,
In the lk 2.4 series we have both older "non-eh" lower
level drivers and a few, newer "eh" drivers. In the lk
2.5 series the mid level interface to the older "non-eh"
drivers was dropped.

Hence in the development lk 2.5 series there are many stranded
drivers, including ide-scsi, some of which have been converted "on
the fly". His is an incomplete list of issues to be addressed
in lower level (HBA) driver conversions:
  - "eh" interface [mandatory]
  - io_request_lock displaced by host_lock [mandatory]
  - PCI memory/DMA interface
  - driverfs aware
  - autosense for high performance drivers (perhaps all)

As you point out autosense support (at the device level)
is now mandatory in recent scsi drafts/standards. For
simplicity of queueing logic, the sense buffer should not
be left for the mid level to fetch (with a REQUEST SENSE).

I have attempted the conversion on several HBA drivers
(of which scsi_debug is the only one I maintain). As Ben
LaHaise has pointed out, I have skipped addressing the
"PCI memory/DMA interface" so far.

Until Doug Ledford pointed out recently what lower level 
drivers should do with regard to autosense, I was unaware
what to do. Since that time I have converted scsi_debug
to do autosense properly and submitted a patch for the
drivers/scsi/scsi_mid_low_api.txt documentation file.

Now would someone else like to step up to the plate
(or "wicket" to use the cricket metaphor) and try and
get the ide-scsi driver in lk 2.5 to do autosense?


If kernel people think that a ide-scsi "like" driver is 
going away then perhaps they should consider the new SAS
(SCSI over Serial ATA infrastructure) draft. They have
one mode illustrated in that document where the initiator
is a SCSI host and it talks to multiple serial ATA
disks via an "expander". Could be interesting.

Doug Gilbert

Re: Autosense requirement

[Doug Ledford]

On Mon, Jul 29, 2002 at 01:48:35PM -0400, Douglas Gilbert wrote:
> Hence in the development lk 2.5 series there are many stranded
> drivers, including ide-scsi, some of which have been converted "on
> the fly". His is an incomplete list of issues to be addressed
> in lower level (HBA) driver conversions:
>   - "eh" interface [mandatory]
>   - io_request_lock displaced by host_lock [mandatory]
>   - PCI memory/DMA interface
>   - driverfs aware
>   - autosense for high performance drivers (perhaps all)
> 
> As you point out autosense support (at the device level)
> is now mandatory in recent scsi drafts/standards. For
> simplicity of queueing logic, the sense buffer should not
> be left for the mid level to fetch (with a REQUEST SENSE).

It will be mandatory for the LLDD to do autosense.  All remnants of code 
to perform a follow up request sense operation *will* dissappear from the 
mid layer.  OTOH, the sense command and sense buffer will be pre-set for 
each device so at least the LLDD won't have to build their own command any 
longer, they can just change the command pointer from the original command 
to the sense command and the data buffer to the sense buffer and reissue 
the request.

> I have attempted the conversion on several HBA drivers
> (of which scsi_debug is the only one I maintain). As Ben
> LaHaise has pointed out, I have skipped addressing the
> "PCI memory/DMA interface" so far.

Feel lucky.  It's currently pissing me off and I'm thinking of changing 
it.


-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606
  

Re: Autosense requirement

[Mike Anderson]

Doug Ledford [dledford@redhat.com] wrote:
> It will be mandatory for the LLDD to do autosense.  All remnants of code 
> to perform a follow up request sense operation *will* dissappear from the 
> mid layer.  OTOH, the sense command and sense buffer will be pre-set for 
> each device so at least the LLDD won't have to build their own command any 
> longer, they can just change the command pointer from the original command 
> to the sense command and the data buffer to the sense buffer and reissue 
> the request.

Doug,
	I assume from your message that you are removing the call from
	scsi_unjam_host to do request sense (which is good). 
	
	Does this imply that your reworking all of the eh handling in
	scsi_error.c?

	I was doing some rework in this area, but it sounds like it might
	be counter to your work.

-Mike
-- 
Michael Anderson
andmike@us.ibm.com

Re: Autosense requirement

[Doug Ledford]

On Mon, Jul 29, 2002 at 02:53:26PM -0700, Mike Anderson wrote:
> Doug,
> 	I assume from your message that you are removing the call from
> 	scsi_unjam_host to do request sense (which is good). 
> 	
> 	Does this imply that your reworking all of the eh handling in
> 	scsi_error.c?

Yeah, I had some stuff I want to do there.  However, I'm currently working 
on other things right now.  I was saving this for later :-/

> 	I was doing some rework in this area, but it sounds like it might
> 	be counter to your work.

Go ahead.  I'm not into that section yet.

-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606
  

Re: Autosense requirement

[Patrick Mansfield]

On Mon, Jul 29, 2002 at 05:58:27PM -0400, Doug Ledford wrote:
> On Mon, Jul 29, 2002 at 02:53:26PM -0700, Mike Anderson wrote:
> > Doug,
> > 	I assume from your message that you are removing the call from
> > 	scsi_unjam_host to do request sense (which is good). 
> > 	
> > 	Does this imply that your reworking all of the eh handling in
> > 	scsi_error.c?
> 
> Yeah, I had some stuff I want to do there.  However, I'm currently working 
> on other things right now.  I was saving this for later :-/
> 
> > 	I was doing some rework in this area, but it sounds like it might
> > 	be counter to your work.
> 
> Go ahead.  I'm not into that section yet.

Doug -

I'm also doing some scsi changes - scsi_scan.c cleanup, and
multi-path IO support.

Are you doing work that affects scsi_scan.c?

Do you have a tree or such that we can sync up with?

Any moderate changes to scsi will likely affect the multi-path changes.

-- Patrick Mansfield

RE: Autosense requirement

[Ravi Anand]

Does this also mean low level driver will be responsible for taking action on the basis of the sense data coming back from the device ?

Ravi
-----Original Message-----
From: Mike Anderson [mailto:andmike@us.ibm.com]
Sent: Monday, July 29, 2002 2:53 PM
To: Doug Ledford
Cc: linux-scsi@vger.kernel.org
Subject: Re: Autosense requirement


Doug Ledford [dledford@redhat.com] wrote:
> It will be mandatory for the LLDD to do autosense.  All remnants of code 
> to perform a follow up request sense operation *will* dissappear from the 
> mid layer.  OTOH, the sense command and sense buffer will be pre-set for 
> each device so at least the LLDD won't have to build their own command any 
> longer, they can just change the command pointer from the original command 
> to the sense command and the data buffer to the sense buffer and reissue 
> the request.

Doug,
	I assume from your message that you are removing the call from
	scsi_unjam_host to do request sense (which is good). 
	
	Does this imply that your reworking all of the eh handling in
	scsi_error.c?

	I was doing some rework in this area, but it sounds like it might
	be counter to your work.

-Mike
-- 
Michael Anderson
andmike@us.ibm.com

-
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

Re: Autosense requirement

[Doug Ledford]

On Mon, Jul 29, 2002 at 03:28:14PM -0700, Ravi Anand wrote:
> Does this also mean low level driver will be responsible for taking action on the basis of the sense data coming back from the device ?

No, it just has to get the data and then complete the command to the mid 
layer.  The mid layer will handle doing the "Right Thing" based upon the 
sense data.

-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606
  

Re: Autosense requirement

[Doug Ledford]

On Mon, Jul 29, 2002 at 03:10:27PM -0700, Patrick Mansfield wrote:
> Doug -
> 
> I'm also doing some scsi changes - scsi_scan.c cleanup, and
> multi-path IO support.

I saw the posts you made on this.  I was just getting ready to look 
at/integrate your scsi_scan.c changes then add on the additional stuff I 
had in mind.  I thought I saw you say you were forward porting the changes 
to 2.5.28 so it will apply cleanly.  Once I saw that patch come out I was 
going to grab it.

> Do you have a tree or such that we can sync up with?

Not anything available yet (it's too broken right now).

> Any moderate changes to scsi will likely affect the multi-path changes.

Yep, that I can see for sure...

-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606
  

Re: Autosense requirement

[Patrick Mansfield]

On Mon, Jul 29, 2002 at 07:00:48PM -0400, Doug Ledford wrote:
> On Mon, Jul 29, 2002 at 03:10:27PM -0700, Patrick Mansfield wrote:

> I saw the posts you made on this.  I was just getting ready to look 
> at/integrate your scsi_scan.c changes then add on the additional stuff I 
> had in mind.  I thought I saw you say you were forward porting the changes 
> to 2.5.28 so it will apply cleanly.  Once I saw that patch come out I was 
> going to grab it.

I had some 2.5.28/29 problems (I didn't set the new CONFIG_XXX_SERIAL
options, and it took me a bit to realize the system was really booting
even though I didn't see any serial line output), I hope to post the
patch (against 2.5.29, but it will apply to 2.5.28) by Wednesday. 

> > Do you have a tree or such that we can sync up with?
> 
> Not anything available yet (it's too broken right now).
> 
> > Any moderate changes to scsi will likely affect the multi-path changes.
> 
> Yep, that I can see for sure...

I have some patches from the multi-path that I could break out, especially
some list iterators -  multi-path needs the Scsi_Device separated from
Scsi_Host. Iterators were added so the underlying structures are not
visible - that is, so host_queue is not directly referenced, and I can
put any type of data structure in its place. This is one of the broadest
changes (potentially affects all adapter drivers) in the multi-path patch.

Having Scsi_Device on its own list could also help in hot-replacement
of single pathed devices (Scsi_Host can be removed without having to
remove a Scsi_Device off of its host_queue).

If you make changes in the host/device list(s) please consider that I need
to have the Scsi_Devices on their own list separate from the Scsi_host list.

Thanks.

-- Patrick Mansfield

Re: Autosense requirement

[Luben Tuikov]

Doug Ledford wrote:
> 
> It will be mandatory for the LLDD to do autosense.  All remnants of code
> to perform a follow up request sense operation *will* dissappear from the
> mid layer.  OTOH, the sense command and sense buffer will be pre-set for
> each device so at least the LLDD won't have to build their own command any
> longer, they can just change the command pointer from the original command
> to the sense command and the data buffer to the sense buffer and reissue
> the request.

Oh, this is soooo nice to hear.

-- 
Luben

Re: Autosense requirement

[James Bottomley]

patmans@us.ibm.com said:
> I have some patches from the multi-path that I could break out,
> especially some list iterators -  multi-path needs the Scsi_Device
> separated from Scsi_Host. Iterators were added so the underlying
> structures are not visible - that is, so host_queue is not directly
> referenced, and I can put any type of data structure in its place.
> This is one of the broadest changes (potentially affects all adapter
> drivers) in the multi-path patch.

I was planning to introduce the Scsi_[Host,Device,Cmnd] structures to the 
concept of struct list_head as part of the error handler re-write.  The error 
handler needs lists for the concept of reset locality (i.e. dump all commands 
for all LUNS of this target, dump all commands for all devices on this bus), 
although its a non time critical section, so it wouldn't necessarily matter 
having to have it loop over every device to find only the ones it's interested 
in.

> Having Scsi_Device on its own list could also help in hot-replacement
> of single pathed devices (Scsi_Host can be removed without having to
> remove a Scsi_Device off of its host_queue).

Isn't this going to cause serious problems for the driverfs stuff?  
Effectively you're changing the parent pointer under the device which alters 
the layout of the device tree.

> If you make changes in the host/device list(s) please consider that I
> need to have the Scsi_Devices on their own list separate from the
> Scsi_host list. 

Could you post some of the details of this (separated from the multi-path 
patch if possible)?  Thanks,

James
 

Re: Autosense requirement

[Patrick Mansfield]

James -

On Wed, Jul 31, 2002 at 11:04:13AM -0500, James Bottomley wrote:
> patmans@us.ibm.com said:
> > Having Scsi_Device on its own list could also help in hot-replacement
> > of single pathed devices (Scsi_Host can be removed without having to
> > remove a Scsi_Device off of its host_queue).
> 
> Isn't this going to cause serious problems for the driverfs stuff?  
> Effectively you're changing the parent pointer under the device which alters 
> the layout of the device tree.

Yes, for any multi-path implementation, driverfs needs changes so that a
child can have multiple parents, or something along those lines.

For the next version of the patch, I'm planning on merging with the current
identifier code - the value put into the driverfs "name", and then I plan
on looking into driverfs changes.

Perhaps driverfs could seperate device registration (or creation) from link
(or path) registration.

> > If you make changes in the host/device list(s) please consider that I
> > need to have the Scsi_Devices on their own list separate from the
> > Scsi_host list. 
> 
> Could you post some of the details of this (separated from the multi-path 
> patch if possible)?  Thanks,
> 
> James

There is a document here:

http://www-124.ibm.com/storageio/multipath/scsi-multipath/docs/index.html

It describes the current host_queue list (I think you had similiar
slides at OLS), and the new list introduced by the multi-path patch,
mainly to show the path structures, not the Scsi_Device list.

Generally, if we want one Scsi_Device per actual LUN, and a LUN is connected
to multiple adapters, the Scsi_Device can't easily be linked off of
Scsi_Host - there is no longer one Scsi_Host for a given Scsi_Device.

So, I added a list of Scsi_Devices; on each Scsi_Device there is a list
of paths, where each path includes a pointer back to Scsi_Host.

On removal of a single Scsi_Host (if there was such code), all paths
pointing to the host must first be removed, and Scsi_Device can remain
(even with no left paths).

If I linked off of Scsi_Host, there would have to be a separate list
structure so that a Scsi_Device could be on multiple Scsi_Host lists.
This could still be done even with a separate Scsi_Device list, but is
only usefull if we need a fast way to lookup all Scsi_Devices on a host.

-- Patrick Mansfield