On Fri, 2016-06-10 at 14:33 -0700, James Bottomley wrote:
> On Fri, 2016-06-10 at 14:01 -0700, James Bottomley wrote:
> > On Fri, 2016-06-10 at 16:58 -0400, Ewan D. Milne wrote:
> > > I'm not sure if this is the problem, but the tagging changes to
> > > scsi_tcq.h may have altered the 53c700 driver's assumptions.
> > > In one case it sets sdev->current_cmnd and then some of the
> > > tagging calls would return it if the tag was SCSI_NO_TAG.
> > >
> > > NCR_700_queuecommand_lck() does:
> > >
> > > if ((hostdata->tag_negotiated & (1<<scmd_id(SCp))) &&
> > > SCp->device->simple_tags) {
> > > slot->tag = SCp->request->tag;
> > > CDEBUG(KERN_DEBUG, SCp, "sending out tag %d, slot
> > > %p\n",
> > > slot->tag, slot);
> > > } else {
> > > slot->tag = SCSI_NO_TAG;
> > > /* must populate current_cmnd for
> > > scsi_host_find_tag
> > > to
> > > work */
> > > SCp->device->current_cmnd = SCp;
> > > }
> >
> > Thanks ... I was just about to look for something this. I'd got to
> > interpreting the script as reselected with tag information present
> > and then trying to look the command up with no tag present, hence
> > the
> > BUG().
>
> Yes, you're right, it's
>
> commit 64d513ac31bd02a3c9b69ef04444f36c196f9a9d
> Author: Christoph Hellwig <[email protected]>
> Date: Thu Oct 8 09:28:04 2015 +0100
>
> scsi: use host wide tags by default
>
> Again. This time because it's transformation of the handling of
> SCSI_NO_TAG is wrong. You can't replace the return sdev
> ->current_cmnd
> original in scsi_find_tag with the NULL return in scsi_find_host_tag.
>
> I think this changesets wins the prize for the greatest number of
> generated faults.
>
> Does this fix 53c700.c?
>
> I suppose we'd better look for other places where no tag fell through
> ...
OK, I checked: snic and fnic use SCSI_NO_TAG but they don't save
anything in current_cmnd, so they can't rely on the original behaviour.
I think we'll be safe with a local change in 53c700.c
James
--
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
