Re: [PATCH 0/4] scsi: 64-bit LUN support
On 03/29/2013 05:32 PM, Tomas Henzl wrote: On 03/27/2013 08:37 AM, Hannes Reinecke wrote: On 03/26/2013 07:00 PM, Chad Dupuis wrote: On Tue, 19 Feb 2013, Hannes Reinecke wrote: This patchset updates the SCSI midlayer to use 64-bit LUNs internally. It eliminates the need to limit the number of LUNs artificially to avoid aliasing issues; the SCSI midlayer can now accept any LUN presented to it. The LLDD specific settings for 'max_lun' have been left untouched; it should be raised to '~0' if the HBA supports 64-bit LUNs internally. However, it is up to the driver maintainer to raise that limit. Hannes Reinecke (4): scsi_scan: Fixup scsilun_to_int() scsi: use 64-bit LUNs scsi: use 64-bit value for 'max_luns' scsi: Remove CONFIG_SCSI_MULTI_LUN Hannes, As we've reviewed these patches internally, the one question that keeps coming up is how do we handle hardware that cannot handle a 64-bit LUN address? For example, some of our older 2G/bps hardware can only handle a 16-bit LUN address. Currently we convert the u32 value to u16. > Do we do the same for the 64-bit conversion? Can a way be devised to "opt-out" of receiving a 64-bit address in the first place (IIRC this > was an option in the v1 patch set)? Yes, you can. The idea here is to let 'max_luns' control this behaviour; 'max_luns' is the highest LUN number the host can support. So for 16-bit LUN you would set max_luns to '0x', and for 32-bit LUN addresses you would be setting max_luns to '0x'. Hi all, in scsi_report_lun_scan is max_lun compared with the result of scsilun_to_int, but in that value is also stored the address method. This means, that we compare the max_lun to a LUN 'handle' which doesn't seem to make much sense. This makes that test dependent on which address method is used and not only to the LUN number which is I think expected. The solution is to have a new function 'scsilun_to_num', (I can send a patch) or let the individual drivers set the max_lun to -1 and test for the allowed LUNs in the driver. You sure this is necessary? I would like to avoid having to parse the LUN number for validity as we cannot guarantee this check has any meaning for the target. The only authoritative check can be made by the target. In the 64-bit context the max_luns should rather be interpreted as a 'max bits' setting, ie the number of _bits_ per LUN number the HBA is able to transport. But renaming 'max_luns' to 'max_bits' is a bit pointless, as it would break backwards compability for no real gain. So with my patchset we have a two-step LUN validation: - max_luns controls the max LUN number (read: max number of bits per LUN) which can be transported to the target - The target validates the transported LUN number. Hence I don't think we would need an additional function here. But yes, we need to update scsi_debug as this should validate the incoming LUN number. As should the target mode drivers. But this can be left for later once the 64-bit changes are in. Cheers, Hannes -- 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
[GIT PULL] target fixes for v3.9-rc5
Hi Linus, Here are two more target-pending fixes for v3.9-rc5 code. Please go ahead and pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git master This includes the bug-fix for a >= v3.8-rc1 regression specific to iscsi-target persistent reservation conflict handling (CC'ed to stable), and a tcm_vhost patch to drop VIRTIO_RING_F_EVENT_IDX usage so that in-flight qemu vhost-scsi-pci device code can detect the proper vhost feature bits. Also, there are two more tcm_vhost patches still being discussed by MST and Asias for v3.9 that will be required for the in-flight qemu vhost-scsi-pci device patch to function properly, and that should (hopefully) be the last target fixes for this round. Thank you, --nab Nicholas Bellinger (2): tcm_vhost: Avoid VIRTIO_RING_F_EVENT_IDX feature bit target: Fix RESERVATION_CONFLICT status regression for iscsi-target special case drivers/target/target_core_transport.c |4 +++- drivers/vhost/tcm_vhost.c | 13 +++-- 2 files changed, 14 insertions(+), 3 deletions(-) -- 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
Re: qla2xxx: issues when creating a new target port
On 08/03/2013 21:25, Chris Boot wrote: On 05/03/13 22:15, Chris Boot wrote: I'll see if I can get enough hardware and time together to test this over the weekend to confirm everything I said above and gather the logs with the error logging enabled. I'll keep you posted. I have run some tests against 3.8.2, and attached the logs. I can only replicate the problems I ran into with the following sequence of events: 1. Link on the qla246x target must be down to start with (tested with QLA2460 and QLA2464). 2. /qla2xxx create 21:00:00:1b:32:11:a8:24 3. disable 4. luns/ create /backstores/iblock/test 5. acls/ create 10:00:00:06:2b:11:3f:a1 6. enable 7. Plug in the link to an initiator. Even with 'set global auto_enable_tpgt=false', at step 3 the port comes up enabled. It seems I remembered wrongly that disabling the target port does not successfully disable it: jones-hdd bootc # cat /sys/kernel/config/target/qla2xxx/21\:00\:00\:1b\:32\:11\:a8\:24/tpgt_1/enable 1 jones-hdd bootc # echo 0 > /sys/kernel/config/target/qla2xxx/21\:00\:00\:1b\:32\:11\:a8\:24/tpgt_1/enable jones-hdd bootc # cat /sys/kernel/config/target/qla2xxx/21\:00\:00\:1b\:32\:11\:a8\:24/tpgt_1/enable 0 Once the target is configured with a LUN and ACL, enabled, and the link brought up by an initiator, the initiator fails to see any LUNs and eventually times out. The debug logging shows interesting lines such as: Mar 8 21:06:59 jones-hdd kernel: [ 183.441093] qla2xxx [:01:00.0]-f821:4: New command while device 8801a1b51400 is shutting down Mar 8 21:06:59 jones-hdd kernel: [ 183.441096] qla2xxx [:01:00.0]-e859:4: qla_target: Unable to send command to target for req, ignoring. I definitely think there is a bug in there, and it feels like it's triggered by disabling the target port with the link down - but I'm only guessing at this point. Hi folks, Has anyone had a chance to look at the above? Cheers, Chris -- Chris Boot bo...@bootc.net -- 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
