Ok, here’s what I was able to find. I won’t mention the brand/model of this particular device, but let it be stated for the record that the below issue is not the only one we’ve found with this particular device…
The LUN field was required back in the earlier SCSI days, because there was only a few bits to indicate the target in the transport layer (i.e. Target 0-7). Therefore an additional mechanism was required in order to support multiple devices with only one connectionto the wire (transport). This launched the LUN bits inside the CDBs.
As you know, 1394 storage is handled by the sb2port driver. Each LUN is exposed on the 1394 bus as a separate device (address) to which to send commands. Thus, the use of the LUN field within the CDB should never be required, as each exposed device (at the 1394 level) is independently addressable. This means that, for all intents and purposes, there is no technical need for a host to know if the device on the far side of the bridge is device0/device1 (ATAPI), if the device is a given lun, etc. – the mapping from the 1394 transport to the ATAPI transport must be managed by the 1394 bridge chipset.
Thus it can be strongly argued that if a 1394-ATAPI bridge chipset decides to support exposing multiple LUNs, then this same chipset is then responsible for also force-feeding the LUN bits into the CDBs(*). There is a “powerful file changer” (cough) that seems to have, without foreknowledge, chosen to use a 1394-ATAPI chipset which has multiple problems. While you will undboutably experience the others over your time using this device, it is clear that this chipset is not force-feeding the LUN bits into the CDB.
In general, it’s a very rare consumer-level product nowadays that uses one device with multiple LUNs. It is therefore not unexpected that the bridge chipsets didn’t test this scenario, and that we’ve not seen this problem ourselves.
(I’m still going to have to look at changer.sys, just to be 100% sure that it’s not sending irps to the wrong PDO, but I’d be absolutely amazed if that were the case.)
Summary:
(A) It should be perfectly normal for CDBs on 1394 busses to have zero LUNs at all times.
(B) Some 1394/ATAPI bridge chipsets have issues.
(C) The device in question is likely one of these “powerful” devices.
The owner of this issue is going to look at it, but not soon. If you need a fix, I can only suggest going through PSS, creating an SR, and pushing for a workaround that way.
.
(*) For compatibility, this would only occur for LUNs != 0, of course.
-----Original Message-----
From: Valeriy Glushkov [mailto:gvvua@ua.fm]
Sent: Wednesday, March 15, 2006 12:55 AM
Subject: Re: RE:A SPTI bug in 1394 storage port?
Hi Henry,
The device is an external DVD changer connected via the 1394 interface.
Both the DVD and the changer devices are opened from my usermode application with links like ‘\.\Cdrom0’ and ‘\.\Changer0’.
After that my application sends IOCTL_SCSI_PASS_THROUGH_DIRECT requests to the devices on behalf of a remote client.
As the devices are opened via their class driver interfaces, it should be up to the storage port driver to fill in the Bus/Target/LUN for the requests.
But sbp2port.sys seems to have problems with this.
Is it a bug or a known issue of the port driver?
Thank you.
Best regards,
Valeriy Glushkov
----- ??? ??? -----
??: “Henry Gabryjelski”
???: “Windows System Software Devs Interest List”
???: 15 ??? 2006 ?. 1:24
???: RE:[ntdev] A SPTI bug in 1394 storage port?
Hi Valeriy,
Can you provide more details? Are you opening a handle to the CDROM
device, the CHANGER device, or perhaps directly to the 1394 storage
adapter directly?
-----Original Message-----
From: Valeriy Glushkov [mailto:gvvua@ua.fm]
Sent: Monday, March 13, 2006 2:27 PM
Subject: A SPTI bug in 1394 storage port?
Hi Guys,
I found a strange behavior of the 1934 storage port driver
(sbp2port.sys) in
Windows XP Media Center (I guess the same problem is in other XP version
too).
When 2 storage devices (a CD-ROM and its changer) are connected to the
1394
bus, the storage port assigns LUN 0 to one of them and LUN 2 to the
other
(as reported in the Device Manager).
From the DDK docs:
“If the handle was obtained for a claimed device, then the PathId,
TargetId
and Lun as defined in this structure will be ignored and the appropriate
class driver will provide this SCSI address information.”
It seems the rule does not work for 1394 port. If I send a
SCSI_PASS_THROUGH
with Lun = 0, all the requests are directed to the CD-ROM device, ever
when
the request is sent to the handle for ‘\.\Changer0’ device!
A work around that I found is to specify Lun = 2 for all requests to the
changer device.
But the other bad thing with 1394 port is it does not implement
IOCTL_GET_SCSI_ADDRESS API, so there is no way to know the LUN value for
a
particular device…
Is this a known bug of sbp2port.sys driver?
Are there any ways to know LUNs for 1394 storage devices from a Win32
application?
Thank you in advance.
Best regards,
Valeriy Glushkov
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer