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.
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
