Re: 32M ATA Read command
From: roman ziak (news1_at_MYLASTNAME.com)
Date: 08/27/04
- Next message: Jerry Pisk: "Re: How to retrieve serial number of OS or CPU for copy protection?"
- Previous message: Gary Chanson: "Re: ReadFile blocks awaiting input from stdin"
- In reply to: Phil Barila: "Re: 32M ATA Read command"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 27 Aug 2004 14:25:06 -0400
Here is my communication with Phil w/o confidential content in the hope
that someone may find useful info there. Some of the questions and
answers may apear not to follow the context, this is because they are
from several emails:
>>Then I am stuck with what miniport gives me.
>>It seems to me that I have several options should my customer
>>insist on 48-bit LBA: try to use the PIO method with direct I/O
>>access, write custom miniport (assuming that I will have SI3112
>>programming model) or try to talk to SI to upgrade their driver
>>for 48-bit LBA using SCSI_PASS_THROUGH below 137G and full
>>possible TransferLength.
>
> Yep. If the miniport won't give you what you need, you'll need
> to write your own, or persuade the HBA vendor to do it for you.
> E-mail me and we can compare notes.
Comparing notes:
Have you talked with any HBA vendors or driver suppliers, such as
Microsoft and/or Intel, about enhancing ATA_PASS_THROUGH to fully
support the ATA spec?
32MB is possible in the drives. I don't know if the HBAs really work in
real world conditions, although the bench testing works. The problem is
that none of the common OS drivers support long transfers, so it's kind
of moot until that changes.
Your lock-up problem is exactly what I was suggesting might happen.
That's the most common failure mode when the host and device transfer
modes get out of sync.
PIO is slow. And that's just the nature of PIO. You aren't really
doing a full validation, either, since the DMA EXT commands are a
different animal than the PIO commands.
Intermingled DMA and PIO is fine. The only restriction is that the host
and device modes match, DMA mode -> DMA mode, and PIO mode -> PIO mode.
> PIO is done in user mode by modifying Process I/O Access Map
> by small kernel code (something similar to WinIO, but more secure).
> I also ported Hale Landis (http://www.ata-atapi.com/advdrvr.htm)
> code to Win32 (PIO part only) and run both ATA and ATAPI commands
> using PIO, but this was more for my education rather than to put
> it into project.
PIO isn't hard. DMA isn't hard if you have the chip spec. It's hard
doing this when another driver thinks it has exclusive use of the
hardware, and doesn't have any synchronization in place to ensure that
you don't conflict with it.
>>> > 32MB is possible in the drives. I don't know if the HBAs really
>>> > work in real world conditions, although the bench testing works.
>>> > The problem is that none of the common OS drivers support long
>>> > transfers, so it's kind of moot until that changes.
>>
>> Do you have any experience with http://www.bushound.com/ ?
It's just a SCSI bus filter, sitting on top of the pseudo-SCSI ATA port
driver. Similar to Mark Roddy's Hollistech scsi view, except a bit more
polished, and you get the source code to scsi view, you don't get it for
bushound. There is no way of really tracing an ATA bus in software,
unless you have an undocumented API into the ATA driver, or you put a
hook on the various Hal{Read,Write}{Port,Register}{Uchar,Ushort,Ulong}
set of routines, and only catch the registers that drive the HBA/device.
>>> > PIO is slow. And that's just the nature of PIO. You aren't
>>> > really doing a full validation, either, since the DMA EXT
>>> > commands are a different animal than the PIO commands.
>
>> I have slightly different theory. PIO is bottlenecked by either CPU
>> or the path to HBA. CPU is 2.6+ GHz, so no bottleneck here. In case
>> of SI3112 the bottleneck is 33MHz PCI bus. In case of SiS965
>> nortbridge the conditions should be even more favorable for PIO.
>>
>> What do you think ?
PIO mode timing is defined in ATA spec. Even if you had an 800 MHz FSB
bridged to PCI Express, you are still limited to byte or word read
writes no more frequently than 120 nSec, in the case of PIO mode 4.
I've never seen Windows do that, though, it's normally ~480 nSec between
register accesses.
>>> > Intermingled DMA and PIO is fine. The only restriction is that
>>> > the host and device modes match, DMA mode -> DMA mode, and PIO
>>> > mode -> PIO mode.
>>
>> In most cases they do match, unless we test the actual SET FEATURES
>> -> SET TRANSFER MODE command.
That's what I meant. You have to sync the HBA transfer mode to the SET
TRANSFER MODE or you can hang things. If you have the API, you can just
tell the HBA to change modes, and it will set the mode on the device for
you.
> Right now we use Adaptec with Silicon Image and I found out
> that their PHY uses legacy mode with 4 I/O ranges in Device
> Manager. 8 byte I/O ranges are IDE command control registers
> and the 3rd byte in 4byte I/O ranges is alternate status.
> Hale Landis' code was working fine with this setup, my code
> does not use alternate status at the moment.
Sounds about right for legacy mode.
> So far I was successful to run my software on Intel HBA,
> SiS965 and SI3112.
> I was not successful on SIS180 (RAID) and Promise card. I use
> SCSI_PASS_THROUGH_DIRECT for ATAPI + ATA READ/WRITE and PIO
> for DEVICE RESET, IDENTIFY DEVICE, DEVICE RESET etc.
Are you saying that you are doing a SCSI_PASS_THROUGH with a READ (6,
20, 12) cdb, or are you using the SCSIOP_ATA_PASS_THROUGH as the cdb
opcode, and really doing a READ SECTORS?
> This surprised me as well at first. I noticed that Windows
> shows SATA harddrives as SCSI devices, so I thought: let's
> try to send SCSI commands Read(10), Write(10), Read(12) and
> Write(12). Data Transit analyser shows READ/WRITE DMA and
> above 137G READ/WRITE DMA EXT, so there must be a translation
> to ATA somewhere in driver stack, probably in the miniport.
Depends on the HBA whether the SATA drives are driven by a miniport or
if ATAPI drives them.
Did you do this as SPT, or do direct LBA access with a handle to
\\.\PhysicalDriveN and do unbuffered READ/WRITE with offset and length
that are integer multiples of SECTOR_SIZE (currently 512 bytes, but soon
to be variable)? If you did it as SPT, I'm not surprised that it maps
the same CDBs that it uses for ordinary READ/WRITE activity from the
disk class driver. Less common ones and vendor unique commands are much
harder.
> I started using ATA_PASS_THROUGH, but it was not implemented
> in SI3112.SYS, so it was dropped and I started using direct I/O.
> Do not understand the second part of your answer -
> SCSIOP_ATA_PASS_THROUG - this is functionality in kernel mode,
> or you can do this from DeviceIoControl ?
That was the NT4 version of ATA_PASS_THROUGH.
> I was disassembling miniports and seen some of them using HAL
> and some of them using x86 IN and OUT instructions. I can
> understand why driver > writers do that, since in my opinion
> HAL does not have any advantage over C/C++ preprocessor for
> portability and performance hit for extra function call.
That's probably different DDK revisions and compilers, more than
anything else. I think you'll find that as more are built with newer
DDKs, the divergence will go down. Miniports should be calling
ScsiportXXX, rather than HalXXX directly, but it's usually OK to macro
it down to IN and OUT.
> Then this method will not work for me. I only tried it with
> CD/DVD drives and their transfer rates are average 2-6M/sec.
> However, with harddrives we have measured around 60M/s on
> outer diameter and around half of it on inner on 3.5" units.
> According to what you are saying, 120ns will give me 8.3mil
> writes/sec if CPU will not do anything else.
That's ~16MB/sec burst, since it's words, not bytes. That's the same
speed as MW DMA, but not UDMA. But PIO isn't expected to be fast. It's
expected to support legacy hardware that doesn't do DMA. UDMA100 is
more than 6x faster than PIO, both theoretically, and in most real-world
situations. There are some pathological circumstances where the delta
isn't so large, but PIO is never faster than DMA, AFAIK.
> Unfortunately we do not have the HBA programming model.
> I thought ATAPI.SYS needs to restart in order to change
> the mode ?
No, it can change mode with a soft reset. If you do something that
causes ATAPI.sys to time-out a command, it will issue an SRST, followed
by several SET MODE commands. If the condition happens frequently
enough, the mode sets will start ratcheting down to slower DMA, then it
will stop enabling DMA at all, then it will set slower PIO modes, trying
to slow it down enough that the errors don't occur. It used to be that
this was a one way ratchet. Now ScsiPort will ratchet back up over
time, but I don't know if ATAPI.sys is that smart yet. I think it may
not be until Longhorn's AtaPort appears.
- Next message: Jerry Pisk: "Re: How to retrieve serial number of OS or CPU for copy protection?"
- Previous message: Gary Chanson: "Re: ReadFile blocks awaiting input from stdin"
- In reply to: Phil Barila: "Re: 32M ATA Read command"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
