SBP 1394 hard drives hang with Windows XP (rare)

[Pat LaVarre]

* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <LAVARRE at iomega.com>
*
> Discussions in Nashua ...
 
Thanks for sharing.
 
> > > the conclusion that the problem is likely
> > > caused by a bridge chip failure
> > > to split > 128 KiB RBC operations
> > > into more than one ATA command for the attached
> > > device. ATA can't transfer more than 128 KiB in
> > > a single command.
> >
> > I would also guess that this problem is not only
> > limited to hard drives, but perhaps to optical
> > drives and other ATA/ATAPI device types as well.
>
> I would agree.
 
Why?
 
This ATA limit is decided by opcode.  Same for SCSI.
 
SCSI invented new opcodes to raise its 21 bit LBA
limit to 32, and its 8 bit block TransferLength limit
to 16.
 
ATA invented new opcodes to raise its 28 bit LBA limit
to 48, and its 8 bit block TransferLength limit to 16.
 
To find a compliant ATAPI device that chokes over more
than 128 / 0.5 blocks per op, we have to find one that
chokes over more than 21 bits per LBA.
 
That's hard to do now, especially in the optical
space.
 
No?
 
Are we just saying it's easy to find a bridge that
copies only one byte of TransferLength to IDE from
ORB, rather than two, no matter the op?
 
Help?  I'm lost.
 
> ATA can't transfer more than
> 128 KiB in a single command.
 
That is, not with any of its 28-bit LBA ops.

Also Microsoft's penchant for choking off data per CDB
down below 1 MiB means Windows doesn't much test lots
of blocks per ATA command.

Also I wonder about across how many bytes the IDE UDma
CRC stretches comfortably.  I think I remember T13
folk had an answer, last time I asked.

Pat LaVarre

	-----Original Message----- 
	From: Peter Johansson [mailto:PJohansson at ACM.org] 
	Sent: Fri 5/9/2003 8:18 AM 
	To: SBP-3 
	Cc: NCITS T10 
	Subject: RE: SBP 1394 hard drives hang with Windows XP (rare)
	
	

	At 01:18 PM 5/5/2003 -0700, Mike Berhan wrote:
	
	>The program worked on both computers; both drives could read up to the
	>full 512K in a single I/O.
	>
	>I then modified the app to write back the data from the previously read
	>location.  Both drives hung the same way when the sector count reached
	>257. That matches with your 128K per ORB limitation.
	
	Discussions in Nashua led to the conclusion that the problem is likely
	caused by a bridge chip failure to split > 128 KiB RBC operations into more
	than one ATA command for the attached device. ATA can't transfer more than
	128 KiB in a single command.
	
	>It appears to only be on writes though, at least from what I've seen so far.
	
	It's difficult to understand why a bridge chip should be handling reads
	correctly but tripping up on writes ...
	
	>Perhaps that piece of core logic is used in bridge chips by multiple vendors?
	
	Based on anecdotal experience, I think this is unlikely.
	
	>I would also guess that this problem is not only limited to hard drives,
	>but perhaps to optical drives and other ATA/ATAPI device types as well.
	
	I would agree.
	
	
	Regards,
	
	Peter Johansson
	
	Congruent Software, Inc.
	98 Colorado Avenue
	Berkeley, CA  94707
	
	(510) 527-3926
	(510) 527-3856 FAX
	
	PJohansson at ACM.org
	
	
	******************************************************
	SBP-3 protocol for FireWire Mailing List
	Unsubscribing:
	send email to requests at isg.apple.com with subject "unsubscribe sbp3"
	
	Set to Digest Mode:
	send email to requests at isg.apple.com with subject "subscribe digest sbp3"
	
	Help?:
	send email to requests at isg.apple.com with subject "help"
	******************************************************
	

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