linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Christie <michaelc@cs.wisc.edu>
To: "Moore, Eric" <Eric.Moore@lsi.com>
Cc: linux-scsi@vger.kernel.org, james.smart@emulex.com,
	andrew.vasquez@qlogic.com, christof.schmitt@de.ibm.com,
	mp3@de.ibm.com, rmk@arm.linux.org.uk, matthew@wil.cx
Subject: Re: scsi: fix target reset handling
Date: Tue, 04 Mar 2008 09:21:29 -0600	[thread overview]
Message-ID: <47CD68F9.5060108@cs.wisc.edu> (raw)
In-Reply-To: <664A4EBB07F29743873A87CF62C26D70D55122@NAMAIL4.ad.lsil.com>

Moore, Eric wrote:
> On Friday, February 29, 2008 5:25 PM,  Mike Christie wrote:
>> This patchset fixes the problem where scsi-ml will call the 
>> device reset
>> handler for each logical unit, but some drivers are sending a target
>> reset. Because we do not need to send a target reset multiple times,
>> this patchset creates a new target reset callout which of course is
>> called once per target instead of once per lu. It also cleans up
>> the all the commands sent to the target when SUCCESS is returned.
>>
>> qla4xxx, qla2xxx and lpfc were test with a hacked up sg_reset. I also
>> sent lots of commands to the target and decreased the cmd timeout to
>> 1 second so the scsi would run (turned off the eh abort callout too).
>>
>> The arm scsi, mpt fusion, sym53c8xx_2, and a100u2w, and qla1280
>> drivers were only compile tested, but looked like the only needed
>> a rename of the scsi eh handler.
>>
>> The zfcp driver is also only compile tested. It was doing a lun
>> reset and possibly target reset, so I split that up to use
>> the device and target reset handlers. scsi-ml will escalate from
>> the device to the target reset for the driver.
>>
>>
> 
> The fusion firmware supports Logical Unit Reset, so why not fix
> mptscsih_dev_reset so its passing
> MPI_SCSITASKMGMT_TASKTYPE_LOGICAL_UNIT_RESET, and lun number to
> mptscsih_TMHandler, and create the new function mptscsih_target_reset as
> you've done?
> 

I did not do this because I was not trying to add new functionality. I 
was just trying to fix what was there.

How about I add the LU reset support in a separate patch, so git revert 
will be kinder to me?

There was also some side discussion about side affects of doing a lu 
reset and if we need to be doing something more than what we do today 
from the device reset handler, so I did not want to dig into that in 
this patchset. I am just trying to get target reset done in the proper 
place on this pass. In later patches I want to tackle TMFs like lu 
reset, abort task set, etc.

  reply	other threads:[~2008-03-04 15:24 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-01  0:25 scsi: fix target reset handling michaelc
2008-03-01  0:25 ` [PATCH 1/5] scsi_error: add target reset handler michaelc
2008-03-01  0:25   ` [PATCH 2/5] qla4xxx: Add target reset functionality michaelc
2008-03-01  0:25     ` [PATCH 3/5] Convert qla2xxx, mpt, arm, sym, a100u2w, qla1280 to target reset handler michaelc
2008-03-01  0:25       ` [PATCH 4/5] lpfc: convert lpfc to use " michaelc
2008-03-01  0:25         ` [PATCH 5/5] zfcp: convert zfcp to use target reset and device " michaelc
2008-03-01 13:34           ` Christof Schmitt
2008-03-01 13:36           ` [PATCH] " Christof Schmitt
2008-03-02  9:09             ` Mike Christie
2008-03-03  9:39             ` Heiko Carstens
2008-03-03 10:12               ` Christof Schmitt
2008-03-03 10:19                 ` Christof Schmitt
2008-03-03 10:40                   ` Russell King
2008-03-03 11:18                     ` Christof Schmitt
2008-03-03 11:19                     ` Christof Schmitt
2008-04-21 20:43         ` [PATCH 4/5] lpfc: convert lpfc to use target " James Smart
2008-03-05  5:08       ` [PATCH 3/5] Convert qla2xxx, mpt, arm, sym, a100u2w, qla1280 to " Andrew Vasquez
2008-03-05 17:11         ` Mike Christie
2008-03-01  0:27 ` scsi: fix target reset handling Mike Christie
2008-03-03 17:06 ` Moore, Eric
2008-03-04 15:21   ` Mike Christie [this message]
2008-03-04 17:34     ` Moore, Eric
2008-03-04 17:40       ` Hagan, Steve
2008-03-04 18:00         ` James Bottomley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47CD68F9.5060108@cs.wisc.edu \
    --to=michaelc@cs.wisc.edu \
    --cc=Eric.Moore@lsi.com \
    --cc=andrew.vasquez@qlogic.com \
    --cc=christof.schmitt@de.ibm.com \
    --cc=james.smart@emulex.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=mp3@de.ibm.com \
    --cc=rmk@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).