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 at redhat.com> 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 at redhat.com> 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 at 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 at vger.kernel.org >>> 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 at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html |