Skip to contentSkip to conversation

scsi_eh updates

LSF/MM TOPIC Hannes Reinecke 5 participants 6 messages Dec 20, 2013 – Jan 21, 2014 SCSI

lore
Share & tools
lore
#0 lore raw

Hi all,

(before leaving for holiday ...)

I'd like to attend LSF 2014.

During that I'd like to discuss the current status of the SCSI EH and the future planned updates.

As discussed during last year's LSF the SCSI error handler should be updated to handle modern SCSI transports better.
While some patchsets are already merged, there are some issues which are still open:
- Handling of requests during host reset:
Do we need to keep hold of outstanding requests during host reset? Or is it save to return them prior to host reset?
- Check for transport status prior to sending TMFs.
Task management functions typically need a working I_T nexus, so it does make sense to first check the transport status prior to attempting any TMFs
- Further steps for updating SCSI EH
As these are tricky issues which have possible repercussions on the entire subsystem and LLDDs it'd be good to have a broader discussion here.

Happy X-mas,

Hannes

Signature · 8 lines
Dr. Hannes Reinecke		      zSeries & Storage
[email protected]			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#1 lore raw
Quoted 9 lines · Hannes Reinecke

Hi all,

(before leaving for holiday ...)

I'd like to attend LSF 2014.

During that I'd like to discuss the current status of the SCSI EH and the future planned updates.

Quoted 15 lines

As discussed during last year's LSF the SCSI error handler should be updated to handle modern SCSI transports better.
While some patchsets are already merged, there are some issues which are still open:
- Handling of requests during host reset:
Do we need to keep hold of outstanding requests during host reset? Or is it save to return them prior to host reset?
- Check for transport status prior to sending TMFs.
Task management functions typically need a working I_T nexus, so it does make sense to first check the transport status prior to attempting any TMFs
- Further steps for updating SCSI EH
As these are tricky issues which have possible repercussions on the entire subsystem and LLDDs it'd be good to have a broader discussion here.

+1 on this too.

Without upstream movement on scsi_eh, it's going to be a long and painful road for scsi-mq.

--nab

#2 lore raw
In reply to Hannes Reinecke
Quoted 5 lines · Hannes Reinecke

I'd like to attend LSF 2014.

During that I'd like to discuss the current status of the SCSI EH and the future planned updates.

Quoted 15 lines

As discussed during last year's LSF the SCSI error handler should be updated to handle modern SCSI transports better.
While some patchsets are already merged, there are some issues which are still open:
- Handling of requests during host reset:
Do we need to keep hold of outstanding requests during host reset? Or is it save to return them prior to host reset?
- Check for transport status prior to sending TMFs.
Task management functions typically need a working I_T nexus, so it does make sense to first check the transport status prior to attempting any TMFs
- Further steps for updating SCSI EH
As these are tricky issues which have possible repercussions on the entire subsystem and LLDDs it'd be good to have a broader discussion here.

+1 for this topic.

Given my recent contributions to the error detection and recovery code in the SRP initiator driver I think I can provide valuable inputs for this discussion.

Bart.

#3 lore raw
In reply to Hannes Reinecke
Quoted 9 lines · Hannes Reinecke

Hi all,

(before leaving for holiday ...)

I'd like to attend LSF 2014.

During that I'd like to discuss the current status of the SCSI EH and the future planned updates.

Quoted 15 lines

As discussed during last year's LSF the SCSI error handler should be updated to handle modern SCSI transports better.
While some patchsets are already merged, there are some issues which are still open:
- Handling of requests during host reset:
Do we need to keep hold of outstanding requests during host reset? Or is it save to return them prior to host reset?
- Check for transport status prior to sending TMFs.
Task management functions typically need a working I_T nexus, so it does make sense to first check the transport status prior to attempting any TMFs
- Further steps for updating SCSI EH
As these are tricky issues which have possible repercussions on the entire subsystem and LLDDs it'd be good to have a broader discussion here.

+1

I would like to participate in this discussion to provide inputs from LLDDs.

-- Giri

Quoted 13 lines

Happy X-mas,

Hannes

Signature · 8 lines
Dr. Hannes Reinecke		      zSeries & Storage
[email protected]			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
maintainer
#4 lore raw
Quoted 28 lines · Giridhar Malavali
Quoted 9 lines · Hannes Reinecke

Hi all,

(before leaving for holiday ...)

I'd like to attend LSF 2014.

During that I'd like to discuss the current status of the SCSI EH and the future planned updates.

Quoted 15 lines

As discussed during last year's LSF the SCSI error handler should be updated to handle modern SCSI transports better.
While some patchsets are already merged, there are some issues which are still open:
- Handling of requests during host reset:
Do we need to keep hold of outstanding requests during host reset? Or is it save to return them prior to host reset?
- Check for transport status prior to sending TMFs.
Task management functions typically need a working I_T nexus, so it does make sense to first check the transport status prior to attempting any TMFs
- Further steps for updating SCSI EH
As these are tricky issues which have possible repercussions on the entire subsystem and LLDDs it'd be good to have a broader discussion here.

Quoted 4 lines

+1

I would like to participate in this discussion to provide inputs from LLDDs.

For the last time, this isn't the way to ask for a place. You need to send in an ATTEND request according to the CFP.

http://marc.info/?l=linux-scsi&m=138753185305739

Thanks,

James

#5 lore raw
In reply to Giridhar Malavali
Quoted 4 lines · Giridhar Malavali

On 12/20/13 6:54 AM, "Hannes Reinecke" <[email protected]> wrote:

[ .. ]

Quoted 17 lines
Quoted 16 lines

As discussed during last year's LSF the SCSI error handler should be updated to handle modern SCSI transports better.
While some patchsets are already merged, there are some issues which are still open:
- Handling of requests during host reset:
Do we need to keep hold of outstanding requests during host reset? Or is it save to return them prior to host reset?
- Check for transport status prior to sending TMFs.
Task management functions typically need a working I_T nexus, so it does make sense to first check the transport status prior to attempting any TMFs
- Further steps for updating SCSI EH
As these are tricky issues which have possible repercussions on the entire subsystem and LLDDs it'd be good to have a broader discussion here.

Quoted 5 lines

+1

I would like to participate in this discussion to provide inputs from LLDDs.

And I would _very_ much like to have participation from LLDD vendors/providers; as part of the scsi_eh update I plan to introduce a new callback 'eh_transport_reset'.
Which need to be implemented at the LLDD level.

Cheers,

Hannes

Signature · 8 lines
Dr. Hannes Reinecke		      zSeries & Storage
[email protected]			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html