On 07/24/2012 11:44 PM, ronnie sahlberg wrote:
Rob,
This sounds like a bug in linux kernel/initiator.
scsi: host 14 channel 0 id 0 lun16640 has a LUN larger than allowed by
the host adapter
LUN 16640 is in hex 0x4100 or split into addressing mode and lun
Addressing mode is 01b and the lun is 100h
LUNs are specified as two bytes that is split into two parts.
The two most significant bits is the addressing mode, and the lower
14 bits have a different meaning depending on the mode.
See SAM for more details.
There are three different ways that luns> 256 can be represented :
00b : single lun level structure where the next 6 bits would be
the bus number, and the lowest 8 bits would be the lun 0-255 on that
bus.
11b : extended logical unit addressing, which is very complex and really weird.
Or the one that TGTD uses :
01b : flat space addressing mode where the low 14 bits are the lun
number 0-8191
So, 0x4100 does not mean lun 16640, it means LUN 256 (using flat
space addressing mode).
Seems linux is a little buggy here and should be taught about
addressing space modes.
You could try to change TGTD to use the single lun level structure and
see if linux can handle that better,
but that would basically mean that every 256 LUNs, you break off to a
completely different SCSI bus, and there might be other things that
start acting up instead.
Best is probably to fix linux so it can handle "flat space addressing
mode" correctly.
It appears so.
Thanks for the info.
Rob
regards
ronnie sahlberg
On Wed, Jul 25, 2012 at 3:51 AM, Rob Evers<revers@xxxxxxxxxx> wrote:
On 07/16/2012 05:32 PM, ronnie sahlberg wrote:
Can you verify that the tgtd target is running properly ?
Just try to start it manually as root as :
killall -9 tgtd
tgtd
and verify it is running by netstat -tapn | grep 3260
Thanks, that worked.
I'm currently running into an issue where I try to configure
in over 256 virtual tapes via iscsi and on the initiator I see:
st 14:0:0:255: Attached scsi tape st254
st 14:0:0:255: st254: try direct i/o: yes (alignment 1 B)
st 14:0:0:255: Attached scsi generic sg256 type 1
scsi: host 14 channel 0 id 0 lun16640 has a LUN larger than allowed by
the host adapter
scsi: host 14 channel 0 id 0 lun16641 has a LUN larger than allowed by
the host adapter
Any idea why I would be seeing this?
The first 256 (0-255) tape devices look like they are configured
into the initiator correctly, and repeating this with the target
having 256 tapes appears to work.
Looks like is due to the report_luns command not returning
the correct data from what I can tell on the host in
scsi_report_lun_scan:
result = scsi_execute_req(sdev, scsi_cmd, DMA_FROM_DEVICE,
lun_data, length,&sshdr,
SCSI_TIMEOUT + 4 * HZ, 3, NULL);
.
.
.
/*
* Scan the luns in lun_data. The entry at offset 0 is really
* the header, so start at 1 and go up to and including num_luns.
*/
for (lunp =&lun_data[1]; lunp<=&lun_data[num_luns]; lunp++) {
lun = scsilun_to_int(lunp);
.
.
.
} else if (lun> sdev->host->max_lun) {
printk(KERN_WARNING "scsi: %s lun%d has a LUN
larger"
" than allowed by the host adapter\n",
devname, lun);
I poked around a bit and found a fairly stale report of an identical
problem:
http://old.nabble.com/-PATCH--Allow-more-than-255-LUNs-to-be-reported.-td19448136.html
On Tue, Jul 17, 2012 at 5:25 AM, Rob Evers<revers@xxxxxxxxxx> wrote:
On 07/13/2012 07:08 PM, ronnie sahlberg wrote:
Hi,
If you just want to create a tape drive with a tape loaded, these
commands should work :
# create a blank tape
tgtimg --op new --device-type tape --barcode 12345 --size 100 --type
data --file /data/tape001.img
# create a target
tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.ronnie.test
# create a SSC LUN for with the blank tape above loaded into the device
tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 1 -b
/data/tape001.img --device-type=tape
I get 'tgtadm: invalid request when trying to create the LU
# tgtimg --op new --device-type tape --barcode 12345 --size 100 --type
data
--file /data/tape001.img
blk_sz: 100, next 1152, 1152
Sizeof(mam): 1104, sizeof(h): 48
# tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.ronnie.test
tgtadm: can't send the request to the tgt daemon, Transport endpoint is
not
connected
At this, I did 'service tgtd restart'
# tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.ronnie.test
# tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 1 -b
/data/tape001.img --device-type=tape
tgtadm: invalid request
#
# tgtimg --help
Usage: tgtimg [OPTION]
Linux SCSI Target Framework Image File Utility, version 1.0.24
[root@rhel-storage-03 ~]# tgtadm --help
Usage: tgtadm [OPTION]
Linux SCSI Target Framework Administration Utility, version 1.0.24
This is all after a fresh reboot.
Am I still missing something?
Rob
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
