I have fixed up wireshark to decode the luns properly in iscsi and scsi layers. It too did not understand the addressing modes :-) On Thu, Jul 26, 2012 at 11:13 PM, Rob Evers <revers@xxxxxxxxxx> wrote: > On 07/25/2012 05:48 PM, Rob Evers wrote: >> >> 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 > > > One last note on this is that TGTD changes from single lun level structure, > addressing mode 00b, to flat addressing mode 01b, when the lun number > goes above 255. This explains why the linux initiator code worked for the > lower lun numbers. > > 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
