> ... Zip 250s die if you send a command to a LUN other than 0.
> I don't know why, but they just refuse to take a command or
> return status after the first non-zero LUN command. Zip 100s
> seem to have no problem with this ...
Truly?
I'm inclined to think that absolute any device response is compliant - but that
provoking such a response makes the host in question non-compliant.
To let the device do what it pleases, I'd quote BBB 6.2.2 "The device shall consider
the contents of a valid CBW meaningful when ... the bCBWLUN contains a valid LUN
supported by the device" and 6.4 "The response of a device to a CBW that is not
meaningful is not specified."
I've been told that idProduct x0001 Zip 100 respond to invalid LUN with some obsolete
bCSWStatus value. I've been told that Zip 250 and later Zip 100 respond to invalid
LUN as if a phase error had occurred i.e. require a BBB 5.3.4 Reset Recovery to
continue.
To say a host provoking such a response is non-compliant, I'd quote BBB 5.1 bCBWLUN:
"The device Logical Unit Number (LUN) to which the command block is being sent. For
devices that support multiple LUNs, the host shall place into this field the LUN to
which this command block is addressed. Otherwise, the host shall set this field to
zero."
Hmmm. My reading of this last quote presupposes everyone agrees that a device cannot
be said to support multiple lines until something nonzero comes back from Get Max LUN
... I wonder if everyone does?
x4402 Pat LaVarre of iOmega [EMAIL PROTECTED] http://members.aol.com/ppaatt/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
