[T10] SBP 1394 hard drives hang with Windows XP (rare)

[Mike Berhan]

* From the T10 Reflector (t10 at t10.org), posted by:
* "Mike Berhan" <mikeb at bidali.com>
*
Thank you Pat and Peter for your thoughts.  Here is some additional
information.  When you issue an IOCTL_STORAGE_QUERY_PROPERTY to a 1394 hard
drive/controller, you get this structure returned:

typedef struct_STORAGE_ADAPTER_DESCRIPTOR {
    ULONG Version;                 00000020h
    ULONG Size;                    00000020h
    ULONG MaximumTransferLength;   001FF000h (2044 Kbytes)
    ULONG MaximumPhysicalPages;    000001FFh
    ULONG AlignmentMask;           00000003h
    BOOLEAN AdapterUsesPio;        00h (FALSE)
    BOOLEAN AdapterScansDown;      00h (FALSE)
    BOOLEAN CommandQueueing;       01h (TRUE)
    BOOLEAN AcceleratedTransfer;   01h (TRUE)
    STORAGE_BUS_TYPE BusType;      BusType1394
    USHORT BusMajorVersion;        0001h
    USHORT BusMinorVersion;        0000h
} STORAGE_ADAPTER_DESCRIPTOR, *PSTORAGE_ADAPTER_DESCRIPTOR;

What this indicates is that the software/hardware can handle I/O requests up
to ~2MB and has FILE_LONG_ALIGNMENT constraints.  I have not checked to see
if SBP2PORT.SYS is setting the alignment constraint or the vendor's filter
driver.

Windows is humming along just fine, with no I/O larger than 64K, until this
CDB is sent down:

2A 00 02 47 A7 D7 00 03 FF 00

This is the 3FFh sector count write request.  This IRP hangs for 10 seconds
but eventually fails with "The request was aborted. (C0000240h)".  You might
think that the port driver would reset the 1394 bus and clear itself of this
state but that doesn't happen.  The 1394 drive is hung hard and inaccessible
(drive light is stuck on).  If I recall correctly, other 1394 devices on the
bus are also inaccessible (though I would need to double-check that).

A search of the newsgroups shows that others are seeing these "delayed write
failure" errors with 1394 drives under Windows, though it seems infrequent.
I would think that some of the 1394 bridge vendors on this reflector have
been seeing similar problems.  I'd be glad to work with any of them to help
isolate this further.

> I have heard rumours of a coordinated Apple/ Microsoft effort to let a
> 1394 device declare that it works best with a four-byte-aligned physical
> address, but I don't know anything more specific than that.

That may very well be (as seen from the IOCTL information above).  The
problem is that it is up to the app to honor that constraint and I can tell
you that the vast majority of apps out there don't bother to check.  So
while it is very unlikely to get an odd aligned buffer, it can happen.  I've
verified data corruption scenarios when creating a test app with odd aligned
buffers.  There is no indication of any failure at all from anyone.  Just
corrupted data. (NOTE that this was with a prototype 1394 bridge chip that
may very well have never made it out to the market).

Regards,

-------
Mike Berhan
busTRACE Technologies
807 Douglas Blvd., Suite 130
Roseville, CA  95678
Phone 916-782-6341
Fax 916-773-2056
http://www.bustrace.com


*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org