Moore, Eric wrote:
You already figured out the problem, I don't understand why your asking if the kernel verison is behaving properly. You said between those driver versions the device queue depth increased from 32 to 64, and that is exactly what happened. The reason for the increase is some customer ask for the increase queue_depth which helps with performance. We are not going to decrease it back.
My impression is that the per-device queue is supposed to be decreased at runtime to match the actual size that the hardware can handle. In the earlier version we're seeing the queue set to 7 at runtime, while the more recent version is showing a queue depth of 32 or 64 and is giving QUEUE_FULL errors to the userspace apps.
I just wanted to make sure that 2.6.14 was working correctly (ie, this wasn't a bug that has been fixed in a more recent version).
SAM_STAT_TASK_SET_FULL in /usr/src/linux/scsi/scsi.h, is the same as QUEUE_FULL. If you look in scsi_error.c searching for QUEUE_FULL, you will see that it will translate to ADD_TO_MLQUEUE, which means it will reposted to the request queue.
I don't know the scsi code very well, so maybe I'm missing something obvious here. If so, I apologize.
Our userspace apps are getting a status of TASK_SET_FULL on completion of an ioctl() call.
Does this status mean that the command needs to be retried by the userspace app, that it has already been retried by the lower levels and is now completed, or something else entirely?
Thanks, Chris - 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
