FW: [t13] Hello Microsoft...


It appears that Microsoft doesn’t lurk on the t13 list, but I know they lurk
here. Can anybody address Hale’s issues?

Unfortunately, the t13 reflector doesn’t keep any archives. Follow up email
with…more succinctly stated complaints…is right behind this one.



-----Original Message-----
From: Hale Landis [mailto:xxxxx@indra.com]
Sent: Monday, February 03, 2003 2:19 PM
To: T13 List Server
Subject: [t13] Hello Microsoft…

This message is from the T13 list server.

Last week there were several messages here describing problems in the
way various Microsoft Windows OS device drivers handle ATAPI data
transfer commands. The most basic problem seemed to be that these OS
drivers do not conform to the published SFF/INF-8020 and ATA/ATAPI-x
documents describing the ATAPI PACKET command protocol and the
handling of odd length data transfers and odd Byte Count values.

I asked last week and I am asking again: Will someone at Microsoft
explain this apparent bug in the OS driver stack, or provide the
“service pack” number where these problem has been fixed, or indicate
that you think SFF-8020 and ATA/ATAPI-x are wrong and you will be
bringing a proposal to T13 ASAP addressing this issue.


*** Hale Landis *** www.ata-atapi.com ***

Appologies for the length.


-----Original Message-----
From: Hale Landis [mailto:xxxxx@indra.com]
Sent: Tuesday, February 04, 2003 10:42 AM

On Tue, 4 Feb 2003 10:40:56 -0800, Christine Ames wrote:

Where are the t13 reflector archives stored so that Microsoft, should they
choose to accept, can review last week’s discussion regarding ATAPI PACKET
command protocol?

No, T13 does not keep an archive but many T13 members keep all the
messages. I didn’t save all the messages but here is a description
that I sent to Nathan Obr at Microsoft yesterday…


I think there may be three problems in some or all Windows
(9x/NT/2K/XP) all related to how PACKET commands that transfer data
are executed in PIO mode:

For each PIO DRQ data block there is Byte Count (BC). Before
executing the x86 REP INSW or REP OUTSW instruction to transfer the
DRQ data block this BC must be converted to a “word count” or REP
count. The correct way to do this is:

WC = ( BC + 1 ) / 2

But there are versions of Windows that use

WC = BC / 2

The latter will most likely cause a “device hung” condition. This
hang condition would normally require a reset to clear.

When an application program passes a SCSI CDB to the OS driver stack
(via IOCTRL or ASPI?) and that CDB should transfer an odd number of
bytes, for example, an INQUIRY command with the Allocation Length set
to 5, it is not clear what happens. It appears that this will provoke
the problem described in #1. It is not clear if the OS driver stack
can handle odd length data transfers. If it does it is not clear what
becomes of the “pad byte” that is required as the last byte of the
ATA data transfer?

There seems to be a concern that if a data transfer command transfers
an odd number of bytes (plus that “pad byte”) executing that command
using PIO will transfer a different number of bytes to/from the
application program than executing that same command using DMA - this
is a special problem if the application program is unable to force
either PIO or DMA for the command. At the ATA/ATAPI interface using
PIO or DMA does not change the number of bytes a command should
transfer or the ordering of the bytes a command should transfer. If
there is any difference in the data stream it would be something the
OS driver stack is doing incorrectly.

[You can think of the PIO BC being replaced by the DMA PRD entry’s
length field - DMA supports only even length data transfers, PIO
really only supports even length data transfers - that is why there
is a possible pad byte at the end of the transfer.]



*** Hale Landis *** www.ata-atapi.com ***