All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.