SG_FLAG_LUN_INHIBIT broken?

SG_FLAG_LUN_INHIBIT broken?

[Timothy Thelin]

Can anyone confirm that this flag actually works when doing SG_IO? (I'm
testing on a 2.6.13-rc6 kernel)

I'm attempting to do an ata-pt command on a cypress board:
http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommu
nity&CommunityID=209&PageID=259&fid=14&rpn=CY7C68320

It involves a 16-byte cdb with cdb[ 1 ] = 0x24 as a signature byte (Page 13
of the datasheet).  So when the scsi stack adds lun info, it kills the
signature byte.

I've tried adding SG_FLAG_LUN_INHIBIT to the SG_IO header, but neither sd or
sg seem to obey it. After looking at the source neither driver seems to make
any reference to SG_FLAG_LUN_INHIBIT.

Eventually all the commands seemed to be funneled to
scsi.c:532:scsi_dispatch_cmd which does this:
	if (cmd->device->scsi_level <= SCSI_2) {
		cmd->cmnd[1] = (cmd->cmnd[1] & 0x1f) |
			       (cmd->device->lun << 5 & 0xe0);
	}
So basically this is an unconditional "add lun info" if the scsi spec is
<=2, which is what usb-storage devices end up being.

Is SG_FLAG_LUN_INHIBIT supposed to be supported still or is it deprecated or
something?

Thanks,
Tim Thelin

Re: SG_FLAG_LUN_INHIBIT broken?

[Douglas Gilbert]

Timothy Thelin wrote:
> Can anyone confirm that this flag actually works when doing SG_IO? (I'm
> testing on a 2.6.13-rc6 kernel)

Timothy,
No it doesn't work. It hasn't worked since the lk 2.2
series. It has been renamed to:
SG_FLAG_UNUSED_LUN_INHIBIT

Notice that addition of the _UNUSED_ . It is pretty old
stuff, SCSI-2 commands reserved the 3 top bits in byte
one for the lun. Nowadays luns are 64 bit quantities that
are sent to the target outside the cdb which carries the
SCSI command.

I thought it had been removed from the mid level, but ...

> I'm attempting to do an ata-pt command on a cypress board:
> http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommu
> nity&CommunityID=209&PageID=259&fid=14&rpn=CY7C68320
> 
> It involves a 16-byte cdb with cdb[ 1 ] = 0x24 as a signature byte (Page 13
> of the datasheet).  So when the scsi stack adds lun info, it kills the
> signature byte.
> 
> I've tried adding SG_FLAG_LUN_INHIBIT to the SG_IO header, but neither sd or
> sg seem to obey it. After looking at the source neither driver seems to make
> any reference to SG_FLAG_LUN_INHIBIT.
> 
> Eventually all the commands seemed to be funneled to
> scsi.c:532:scsi_dispatch_cmd which does this:
> 	if (cmd->device->scsi_level <= SCSI_2) {
> 		cmd->cmnd[1] = (cmd->cmnd[1] & 0x1f) |
> 			       (cmd->device->lun << 5 & 0xe0);
> 	}
> So basically this is an unconditional "add lun info" if the scsi spec is
> <=2, which is what usb-storage devices end up being.
> 
> Is SG_FLAG_LUN_INHIBIT supposed to be supported still or is it deprecated or
> something?

The above code is a worry because a lot of devices
just place 0 in the version (byte 2 of an INQUIRY
response). Perhaps scsi_level in sysfs
(/sys/class/scsi_device/<h:c:i:l>/device/scsi_level)
should be writable.

Doug Gilbert

RE: SG_FLAG_LUN_INHIBIT broken?

[Timothy Thelin]

> 
> Timothy,
> No it doesn't work. It hasn't worked since the lk 2.2
> series. It has been renamed to:
> SG_FLAG_UNUSED_LUN_INHIBIT
> 
> Notice that addition of the _UNUSED_ . It is pretty old
> stuff, SCSI-2 commands reserved the 3 top bits in byte
> one for the lun. Nowadays luns are 64 bit quantities that
> are sent to the target outside the cdb which carries the
> SCSI command.
> 
> I thought it had been removed from the mid level, but ...
> 
> <...snip...>
> 
> The above code is a worry because a lot of devices
> just place 0 in the version (byte 2 of an INQUIRY
> response). Perhaps scsi_level in sysfs
> (/sys/class/scsi_device/<h:c:i:l>/device/scsi_level)
> should be writable.

The kernel makes no mention of it that I found, but it's
in a header and the original SG_IO docs so it makes it
seem like it exists.  In addition someone on the USB mailing
list pointed me to it a couple of days ago to solve the issue
I discussed in the original mail.

The USB devs don't seem to have interest in treating USB
devices as entities other than SCSI-2 because the devices tend
to lie about their revision and really only work with scsi-2
commands (according to them). So that knocks
/sys/class/scsi_device/<h:c:i:l>/device/scsi_level out of
the water since they want the device to stay scsi2.

If SG_FLAG_LUN_INHIBIT worked, this wouldn't be an issue
because even though these are seen as scsi2 devices,
for raw commands the LUN issue could be stopped.  However,
I'm still open to other solutions if SG_FLAG_LUN_INHIBIT
can't come back.

Regards,
Tim Thelin