On Oct 18 Andy Grover wrote:
> Now that there's a kernel that supports it for Fedora 17 (kernel 3.6.1
> needed for is_local), I've been trying out the kernel target's 1394
> target support against Windows 7.
I haven't run-time tested sbp-target myself yet and it can be a while
until I get the spare time. Plus I don't have a Windows 7 initiator
within reach of a cable for the time being, but I could check with Linux,
OS X 10.4, and Windows XP initiators.
> - Windows device manager lists the device as "Linux Firewire UNKNOWN
> MODEL IEEE 1394 SBP2 device", I'm not sure if that's what we want or
> something more descriptive, or where it's getting this from, but that's
> what it's showing right now.
The "UNKNOWN MODEL" string could apparently be replaced if
sbp_update_unit_directory() was extended to provide
- a model ID entry in the unit directory, holding a numeric model
version identifier which can be chosen arbitrarily,
- a descriptor leaf pointer, located in the unit directory immediately
after the model entry, pointing to
- a textual descriptor leaf, containing a human-readable name of the
logical unit model in ASCII (or to be precise, in the "minimal ASCII"
subset of 7-bit ASCII as defined by IEEE 1212)
to the Linux node's Configuration ROM.
drivers/firewire/net.c::rfc2374_unit_directory shows how textual
descriptors can be added along with a unit directory.
sbp_update_unit_directory() itself does already provide another kind of
extra descriptor after the actual unit directory. (It populates a Unit
Unique ID descriptor.) In the same vain, a textual descriptor can be
appended.
Does the Linux target framework provide a nice string which could be taken
as contents of the model name instead of this "UNKNOWN MODEL"?
> - Behavior is strange when more than one LUN is exported. Drives may
> show up as cdrom when they're not, or as unwritable "RAW" partitions, or
> not all exported luns may appear. All further testing was with one lun.
Hard to tell whether this is a bug in sbp-target or in Windows 7. Could
be easily the latter, because the SBP-2 and SBP-3 specs allow some
alternatives how multiple logical units are announced to initiators. As
it happens, sbp-target does not implement it in the way how all of the
embedded SBP-2/3 multi-LUN targets that I have seen myself do it.
With SBP-2/3, initiators don't figure out logical units by means of SPC's
REPORT LUN command but by what is present in the IEEE 1394/ IEEE 1212
Configuration ROM register. The three ways to organize SCSI logical units
descriptions within the Configuration ROM can be combined, i.e. there are
actually 3*(3-1) = 6 ways to do this... The Linux initiator driver
supports all of these ways, at least in theory.
The specification of this is SBP-2/3 chapter 7.
The way in which I have it encountered in multi LUN devices to which I
have access to or which I have seen in end user reports, which thereby
seems to be the by far most common way, is to feature one IEEE 1212 unit
directory per SCSI logical unit, and therefore have just one
Logical_Unit_Number entry in the unit directory. So in effect, this does
not actually describe an IEEE 1394 node with an SBP target with multiple
logical units, but rather an IEEE 1394 node with multiple SBP targets,
each of which have got one logical unit.
This is somewhat against the SCSI architecture because the higher SBP
units do not support LUN 0, but again that's how the apparent majority of
embedded SBP devices do it.
The next way --- and this is how sbp_update_unit_directory() does it as far
as I understand the code --- is to carry one Logical_Unit_Number entry per
logical unit in the same unit directory.
Each Logical_Unit_Number entry contains fields which specify
- the LUN,
- the PDT,
- whether the logical unit performs tasks in ordered or unordered manner.
The third way involves another level of indirection: The unit directory
contains Logical_Unit_Directory pointers, and these subdirectories finally
contain Logical_Unit_Number entries.
As a side note, this third way and the first way --- but not the second
way --- allow for mixtures of SCSI and non-SCSI logical units on the same
SBP target. I have never seen an SBP target which is not a SCSI target
though. SBP-2 fully specifies only SCSI targets anyway; and while SBP-3
also added specifications for AV/C targets, AV/C over SBP has not been
adopted in practice as far as I know.
So, to summarize, one direction to investigate the multi-LUN troubles
would be to change how sbp-target organizes the unit directory, i.e. let
it provide multiple unit directories each with a single LUN, and see
whether this is more to the liking of Windows 7.
I once used a dual LUN HDD enclosure with Windows 7, and this at
least worked.
> - Tried ramdisk, fileio, and tried the pscsi backstore with a cdrom, no
> issues.
>
> - Reading and writing performance seemed not-so-hot, and the file copy
> progress bar would stall for long periods, and then jump forward.
First of all, I suspect that an OHCI-1394 based implementation (which the
Linux sbp-target necessarily is) is at a certain disadvantage compared to
dedicated SBP-2/3 to ATA/SATA bridge devices due to how OHCI-1394 DMA
works and due to having to deal with a more generic backend. But I guess
there are still quite a few possibilities to optimize sbp-target for
throughput. With present FireWire 400 and 800 interconnects and typical PC
hardware, the primary bottleneck should be the interconnect rather than
e.g. CPU power or backend I/O throughput, and the FireWire part of the
software stack should of course attempt to keep the OHCI-1394 DMA engine
as busy as possible during command execution.
> - Windows didn't see the lun after I enabled the tpg on the target until
> after a reboot. (I didn't do any cable plugging/unplugging.) I seem to
> recall it showing up immediately when I tested this a few months ago,
> but maybe not.
>
> - When rebooting for the previous issue, Windows boot would get stuck at
> the logo screen - resetting a second time would let it boot all the way
> and see the exported lun. Maybe Windows is trying to optimize reboot or
> something and then having issues with the new device?
>
> Anyways, not like we can be responsible for Windows 1394 issues, but
> wanted to report this stuff in case there's stuff we need to fix on our
> side, or just document so users don't get tripped up.
>
> Thanks -- Regards -- Andy
I don't know what's up with the latter two items.
--
Stefan Richter
-=====-===-- =-== ==--=
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
