On Sat, 12 Jul 2014 03:13:07 +0000
"Elliott, Robert (Server Storage)" <elli...@hp.com> wrote:

> 
> 
> > -----Original Message-----
> > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> > ow...@vger.kernel.org] On Behalf Of Joe Lawrence
> ...
> > In your crash stack trace, the scsi error handler has issued a host
> > reset, but then crashed in mpt2sas_base_get_iocstate.  Reading through
> > _scsih_shutdown, I don't believe that the mpt2sas .shutdown path takes
> > any precaution before heading down mpt2sas_base_detach to free adapter
> > resources.  The ordinary .remove path looks similar, though it does
> > call sas_remove_host before freeing resources, *then* scsi_remove_host
> > and scsi_host_put.
> > 
> > I wonder if this ordering needs to be reversed (and added to
> > _scsih_shutdown) to properly de-register from the SCSI midlayer prior
> > to removing the controller instance.
> > 
> > Regards,
> > 
> > -- Joe
> 
> Nagalakshmi was working on an mpt3sas patch for the scsi-mq tree 
> to do just that.  I don't recall if the patch has made it into the 
> scsi-mq tree yet. Apparently it's also needed for non-mq and mpt2sas.
> 
> It is making this change:
> >     sas_remove_host(shost);
> > +   scsi_remove_host(shost);
> >     mpt3sas_base_detach(ioc);
> >     list_del(&ioc->list);
> > -   scsi_remove_host(shost);
> >     scsi_host_put(shost);
> 
> We are making a similar change in hpsa.  Doing so led to a general 
> protection fault, which unveiled that we also needed to change 
> cancel_delayed_work() calls to cancel_delayed_work_sync() to 
> ensure there are no worker functions still active after the 
> scsi_host structure is unregistered.

It looks like Sreekanth posted those patches today -- the new ordering
seems correct, but is there any reason why _scsih_shutdown skips
{sas,scsi}_remove_host calls?

Regards,

-- Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to