Hi,
Aside from experiencing a lockup, which is being handled in a separate
thread, I'd like to raise the issue of the general chattiness of the LIO
stack.
This makes it a little more difficult to separate real issues from just
informational messages. Especially if one isn't experienced with LIO yet.
For example I see a lot of these:
[81302.645459] qla2xxx/xx:xx:xx:xx:xx:xx:xx:xx: Unsupported SCSI Opcode
0x85, sending CHECK_CONDITION.
It's my understanding that these are harmless, in which case wouldn't it
make sense to change:
drivers/target/target_core_transport.c: pr_warn_ratelimited("%s/%s:
Unsupported SCSI Opcode 0x%02x, sending CHECK_CONDITION.\n",
to:
drivers/target/target_core_transport.c: pr_debug_ratelimited("%s/%s:
Unsupported SCSI Opcode 0x%02x, sending CHECK_CONDITION.\n",
or not display them at all, unless a debugging flag in LIO is set?
We see these in flurries too:
[173549.807828] TARGET_CORE[qla2xxx]: Detected NON_EXISTENT_LUN Access
for 0x00000001
[173663.169379] TARGET_CORE[qla2xxx]: Detected NON_EXISTENT_LUN Access
for 0x000000ff
drivers/target/target_core_device.c
if (unpacked_lun != 0) {
pr_err("TARGET_CORE[%s]: Detected NON_EXISTENT_LUN"
" Access for 0x%08llx\n",
se_cmd->se_tfo->get_fabric_name(),
unpacked_lun);
return TCM_NON_EXISTENT_LUN;
}
if (!se_lun) {
pr_debug("TARGET_CORE[%s]: Detected NON_EXISTENT_LUN"
" Access for 0x%08llx\n",
se_cmd->se_tfo->get_fabric_name(),
unpacked_lun);
return -ENODEV;
}
Apparently there are two variants which log at two different levels? Is
this intentional?
[83130.921217] ABORT_TASK: Found referenced qla2xxx task_tag: 1248532
drivers/target/target_core_tmr.c: printk("ABORT_TASK: Found
referenced %s task_tag: %llu\n",
drivers/target/target_core_tmr.c: printk("ABORT_TASK: Sending
TMR_TASK_DOES_NOT_EXIST for ref_tag: %lld\n",
In general I would consider it quite helpful if kernel messages
generated by LIO would be more consistently prefixed by TARGET_CORE (or
whatever the relevant source file is) for example, so it's easier to
determine the origin of a particular kernel message.
Regards,
Pascal de Bruijn
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
