On Sat, 12 Jul 2014 03:13:07 +0000 "Elliott, Robert (Server Storage)" <Elliott@xxxxxx> wrote: > > > > -----Original Message----- > > From: linux-scsi-owner@xxxxxxxxxxxxxxx [mailto:linux-scsi- > > owner@xxxxxxxxxxxxxxx] 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-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
