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: h...@infradead.org [mailto:h...@infradead.org] Sent: Tuesday, August 19, 2014 1:05 PM To: Handzik, Joe Cc: h...@infradead.org; linux-scsi@vger.kernel.org; scame...@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. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
