Re: Bad tag value in scsi-mq.4

Re: Bad tag value in scsi-mq.4

[hch]

On Tue, Aug 05, 2014 at 06:04:07PM +0000, Handzik, Joe wrote:
> Hey Christoph,
> 
> Using the scsi-mq.4 branch from git://git.infradead.org/users/hch/scsi.git, I'm getting a -1 returned from from scsi_cmnd->request->tag...very unsure why that would be. It happens without any drives attached to the controller, not sure if that's relevant in any way.

You're using the non-mq code path, in which tagging needs to be enabled,
does your driver call scsi_activate_tcq?

RE: Bad tag value in scsi-mq.4

[Handzik, Joe]

Yeah, we thought about that one. We call scsi_activate_tcq if our scsi_device has tagged_supported set within hpsa_change_queue_type (our .change_queue_type entry into the scsi_host_template). Also made sure I was booting with the "scsi_mod.use_blk_mq=Y" option, which makes no difference either way.

-----Original Message-----
From: hch@infradead.org [mailto:hch@infradead.org] 
Sent: Tuesday, August 05, 2014 2:28 PM
To: Handzik, Joe
Cc: hch@infradead.org; linux-scsi@vger.kernel.org; scameron@beardog.cce.hp.com; Scales, Webb; Teel, Scott Stacy
Subject: Re: Bad tag value in scsi-mq.4

On Tue, Aug 05, 2014 at 06:04:07PM +0000, Handzik, Joe wrote:
> Hey Christoph,
> 
> Using the scsi-mq.4 branch from git://git.infradead.org/users/hch/scsi.git, I'm getting a -1 returned from from scsi_cmnd->request->tag...very unsure why that would be. It happens without any drives attached to the controller, not sure if that's relevant in any way.

You're using the non-mq code path, in which tagging needs to be enabled,
does your driver call scsi_activate_tcq?

Re: Bad tag value in scsi-mq.4

[hch]

On Tue, Aug 05, 2014 at 07:47:12PM +0000, Handzik, Joe wrote:
> Yeah, we thought about that one. We call scsi_activate_tcq if our scsi_device has tagged_supported set within hpsa_change_queue_type (our .change_queue_type entry into the scsi_host_template). Also made sure I was booting with the "scsi_mod.use_blk_mq=Y" option, which makes no difference either way.

Can you add some tracing to catch this?  On the non-mq path requests
start out with ->tag set to -1 and blk_queue_start_tag, which is called
from scsi_request_fn sets it up.  Adding printks in that area should
help you to find the culprit.

RE: Bad tag value in scsi-mq.4

[Handzik, Joe]

I may take a look again, but was able to get this working on my Rhel7 box (with the kernel boot parameter present). So I either consistently used an earlier version of GRUB incorrectly (possible, maybe when I double checked my boot parameters in the earlier version I somehow reset to defaults?) or found some strange bug. I'm not too concerned, since other members of the team haven't had problems and have been using the SCSI mq code more than I have. Sorry for the false alarm!

Joe

-----Original Message-----
From: hch@infradead.org [mailto:hch@infradead.org] 
Sent: Tuesday, August 19, 2014 1:05 PM
To: Handzik, Joe
Cc: hch@infradead.org; linux-scsi@vger.kernel.org; scameron@beardog.cce.hp.com; Scales, Webb; Teel, Scott Stacy
Subject: Re: Bad tag value in scsi-mq.4

On Tue, Aug 05, 2014 at 07:47:12PM +0000, Handzik, Joe wrote:
> Yeah, we thought about that one. We call scsi_activate_tcq if our scsi_device has tagged_supported set within hpsa_change_queue_type (our .change_queue_type entry into the scsi_host_template). Also made sure I was booting with the "scsi_mod.use_blk_mq=Y" option, which makes no difference either way.

Can you add some tracing to catch this?  On the non-mq path requests
start out with ->tag set to -1 and blk_queue_start_tag, which is called
from scsi_request_fn sets it up.  Adding printks in that area should
help you to find the culprit.