Very disappointed with IOCTL_ATA_PASS_THROUGH

Discussion in 'Windows Vista Drivers' started by 440gtx, Nov 8, 2003.

  1. 440gtx

    440gtx Guest

    New for Windows 2003, IOCTL_ATA_PASS_THROUGH and
    IOCTL_ATA_PASS_THROUGH_DIRECT mark the 5th API from Microsoft for
    something as simple as sending an IDENTIFY command. Compared to
    previous methods, there is one new feature (48-bit LBA protocol) and
    numerous new problems. Pass through direct can't be issued by kernel
    mode drivers, atapi.sys interprets the data returned in the task file
    causing numerous issues, timeouts are artificial, dma protocols are
    absent, overlap is prohibited, part of the drive/head register is off
    limits, there is no way to know if the ioctl's exist, and most of this
    is not documented. It seems the people involved on providing this are
    as confused as ever. I will go into detail on each problem:

    1. IOCTL_ATA_PASS_THROUGH_DIRECT cannot be submitted from a kernel
    mode driver. This is because atapi.sys hardcodes UserMode when PNL'ing
    the DataBuffer. It's a real shame they hard coded this instead of
    parameterizing it using IRP->RequestorMode like one expects from other
    ioctl's like SCSI pass through which can be sent from applications or
    drivers.

    2. atapi.sys interprets the task file reported by the device. One must
    ask why is atapi sticking its nose in here? The spirit of a pass
    through command is just that—pass it through and don't try to
    interpret things. Atapi sent the command, atapi read back the
    registers at the end, please stop there. But instead it will report
    STATUS_IO_DEVICE_ERROR if it sees the error bit set. This creates
    several problems. The first thing is sometimes the error bit means a
    normal, GOOD STATUS such as sending an IDENTIFY command to an ATAPI
    device to verify the atapi signature. This in fact won't work at all
    with these ioctl's due to #3 below.

    3. Neither IOCTL returns the task file when a device sets the error
    bit in the task file. Because STATUS_DEVICE_IO_ERROR is reported AND
    the IOCTL is METHOD_BUFFERED, it means even though ATAPI tries to
    report the task file in CurrentTaskFile, it never gets double buffered
    back to the caller and is dropped!!! That makes returning the task
    file "feature" a moot point because you pretty much only need it when
    there is an error which is the time you are assured of never getting
    it.

    3. Timeout must be between 1 second and 30 hours. Please document
    timeout restrictions so those wishing to disable timeouts don't trip
    over them not knowing why their ioctl is being rejected. Better yet,
    let the caller establish whatever timeout they feel is
    appropriate--the hardware spec does not have a 30 hour maximum
    timeout, so why add an artificial undocumented value pulled out of a
    hat? (repeat again: please pass through, stop having the mind set "oh,
    we can't think of a command taking that long, therefore...") On the
    minimum side, please report STATUS_TIMEOUT for a value of 0 seconds
    instead of invalid command so the caller will have an idea why the
    ioctl is being rejected.

    4. It is not possible to send dma and dma queued protocol commands
    (again). This means these ioctl's are inappropriate for a variety of
    device test tools because the most common commands protocols are left
    out.

    5. Cannot overlap the IOCTL's (again). One has to wonder why? Why not
    just do it right and not make everyone deal with such things as
    knowledge base articles like on SCSI pass through and endless
    discussions by engineers out on the net.

    6. Overrides 3 bits in the drive/head register. Again, another
    violation of the spirit of a pass through command. It is
    incomprehensible why two of these bits are masked off from use. If the
    drive select bit is overridden to prevent one device object's IRP from
    interacting with another device object on the channel, I sure hope the
    execute device diagnostic command is blocked out too (oops). Perhaps
    allowing one to open the IDE channel device object to have full access
    to the task file would be a solution if this is the concern.

    7. Since these IOCTL's are being backported to Windows XP and 2000, it
    would be nice if there is a way to detect whether they are present or
    not. I suspect right now a lot of code is being shipped that says "if
    windows 2003 or later..." and then later modified to "...or if windows
    xp with sp2", etc. Please provide and document a reliable way to know
    whether these are present that can preferably be determined from user
    mode (eg: installers) as well as from kernel mode drivers.
     
    440gtx, Nov 8, 2003
    #1
    1. Advertisements

  2. New for Windows 2003, IOCTL_ATA_PASS_THROUGH and
    SMART_RCV_DRIVE_DATA is there for years, and does the same - well, it returns
    the IDENTIFY data gathered at driver init to memory area, but this is the same.

    SMART support is not necessary for this IOCTL, it is misnamed.
    Oh, great! This is like NT4 FASTFAT used for FSCTL_GET_VOLUME_BITMAP. Been
    there, knowing this.

    Solution: allocate memory in the user space of the system process
    (NtCreateSection/NtMapViewOfSection) and then submit the IOCTL from a work
    item.
    Workaround:
    - filter the PnP START IRP on its way down, remember the port addresses
    - access them on your own in the filter later :)

    Be sure to block the request delivery queue of ATAPI by some mean during this.
     
    Maxim S. Shatskih, Nov 8, 2003
    #2
    1. Advertisements

  3. 440gtx

    Phil Barila Guest

    This has been fixed in the XP release. I don't know for sure whether they
    have fixed the Server 2003 for XP1, but I expect it to get fixed.
    Hmm. I should check this and the next one out when I get back to the
    office. If it's really this way, I'll ask for it to get fixed.
    I've only tried 24 hours, myself. What's the appropriate definition of a
    zero timeout? Infinity?
    Because there isn't any clean definition of overlapping on ATA, with a few
    kludgy exceptions?
    The devsel bit is overridden by the driver so that if you open a handle to
    the master, your command is always going to the master.
    That could be nice. You might find Microsoft a bit more favorable if you
    were to ask instead of demand.

    Phil
    --
    Philip D. Barila Windows DDK MVP
    Seagate Technology, LLC
    (720) 684-1842
    As if I need to say it: Not speaking for Seagate.
    E-mail address is pointed at a domain squatter. Use reply-to instead.
     
    Phil Barila, Nov 11, 2003
    #3
  4. Thanks to you all for raising the issues or answering the questions. The
    effort in better supporting IOCTL_ATA_PASS_THROUGH in Windows 2003 is still
    going on, so is the effort in backporting it to XP and 2000. I will pass on
    the voice here to the developers and get them taken care of. Thanks again.

    Wendy
    --


    This posting is provided "AS IS" with no warranties, and confers no rights.
     
    Wendy Shi [MS], Nov 12, 2003
    #4
  5. 440gtx

    440gtx Guest

    What's the appropriate definition of a zero timeout? Infinity?

    0 would be a useful value to disable timeouts as in my case, the
    engineer determines the timeout. They can choose to cancel the command
    through a UI at any time or let it go as long as they want. The
    undocumented timeout lower and upper bounds create an unnecessary
    barrier for developers to get up and running with these ioctl's. For
    instance, I thought a nice portable way would be to set a long timeout
    would be to assign MAXULONG, but then had to debug why my ioctl was
    being rejected and found the 1 second to 30 hour issue.
    Overlap has been in the spec and in firmware for many years. Can you
    find a hard drive made in this decade without it? Because Microsoft
    hasn't yet implemented overlap for ATAPI devices and won't implement
    it for parallel ATA devices (they are doing it for SATA only), it
    makes it all the more important to give a way for us to do it using
    pass through.
    Right, but two other bits (5 & 7) are overridden and hard coded to 1.
    For many years now, these bits have been defined as "obsolete" and way
    back in the mid 90's, ATA-3 said "set to 1 for compatibility". In my
    opinion, that shouldn't mean pass through PROHIBITS access to these
    bits. If atapi wants to set them for its own internal commands, that's
    reasonable. I just think it is unnecessary to hard code pass through
    because in the future they may be redefined for a new purpose, but be
    off limits. Even today it would be nice for firmware development to
    have access to these bits.
    We got our first IDE pass through command set in Windows 95 with
    IOR_IDE_PASS_THROUGH. After all these years of waiting for the same
    thing on the NT side, we deserved more than what is being offered.
    It's not a demand, just a disappointment. And there are other problems
    with these ioctl's; my list is by no means comprehensive and I even
    held back other issues whose importance won't be evident until the
    future.
     
    440gtx, Nov 13, 2003
    #5
  6. 440gtx

    Phil Barila Guest

    Well, yes, that could be useful. I'm conveying these to the developers at
    Microsoft, and they really do want to hear about it.
    You might be surprised at how little use ATA tagged queuing is. Because it
    only allows for a 32 deep queue, and because that's about where queue
    ordering really starts to improve things. Additionally there are very few
    real world workloads that run on ATA disks that benefit from it. Workloads
    that put that much load on a disk *usually* run on SCSI disks.

    All that aside, that's the only ATA queued stuff defined in ATA 6,
    everything else would be vendor-unique. And ATAPI.sys has no way of knowing
    whether the vendor-unique command you just sent is setup correctly or is
    going to hang the bus.
    I'll pass that along.
    Win 95 allowed mostly any dumb system corruption, so there wasn't as much
    thought put into it. These are not trivial facilities, as they have to make
    sure that Alice Malice can't hang the system from an unprivileged user-mode
    app.

    Do share other issues, if you want to ensure that they get looked at. I'll
    make sure that they get delivered to the developers. But keep in mind, APTI
    is not intended to give you as many degrees of freedom as DOS gives you.
    There are some things that you just aren't going to get.

    Phil
    --
    Philip D. Barila Windows DDK MVP
    Seagate Technology, LLC
    (720) 684-1842
    As if I need to say it: Not speaking for Seagate.
    E-mail address is pointed at a domain squatter. Use reply-to instead.
     
    Phil Barila, Nov 13, 2003
    #6
  7. 440gtx

    the veloper Guest

    "Backporting it to XP and 2000"???
    I was told (5/2003) by Microsoft's CPR team that the problems in
    IOCTL_IDE_PASS_THROUGH were not going to be fixed for 2000/XP.
    Instead, they would work on them for future Windows version. Has it
    been decided now that the new IOCTL_ATA_PASS_THROUGH will be supported
    on 2000/XP to replace/work along IOCTL_IDE_PASS_THROUGH?
     
    the veloper, Nov 13, 2003
    #7
  8. 440gtx

    Phil Barila Guest

    Let's get one thing clear right now: IOCTL_IDE_PASS_THROUGH !=
    IOCTL_ATA_PASS_THROUGH. IOCTL_IDE_PASS_THROUGH is undocumented and broken.
    IOCTL_ATA_PASS_THROUGH is documented, and not known to be broken beyond the
    designed-in limitations. The XP port of APTI is available from Microsoft
    PSS, if you know the magic words (I don't, I got it directly from a PSS
    rep.) The Windows 2000 port is planned, though I haven't been told when it
    will be done.

    Anyone who's interested in APTI would do well to get the XP port and beat on
    it, so that any bugs or limitations that don't really need to be there can
    be identified and fixed.

    Phil
    --
    Philip D. Barila Windows DDK MVP
    Seagate Technology, LLC
    (720) 684-1842
    As if I need to say it: Not speaking for Seagate.
    E-mail address is pointed at a domain squatter. Use reply-to instead.
     
    Phil Barila, Nov 14, 2003
    #8
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.