lkml.org 
[lkml]   [2003]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: PATCH: Fixes for ide-disk.c
    Date


    > -----Original Message-----
    > From: Andre Hedrick [mailto:andre@linux-ide.org]
    > Sent: Saturday, April 05, 2003 12:52 PM
    > To: Mudama, Eric
    > Subject: RE: PATCH: Fixes for ide-disk.c
    >
    > 6-10 seconds is a nice idea, the reality as we both know it is up to 30
    > seconds to return because of OOB seeks to write on reallocations.

    Of course, 6-10 is the non-error case. Depending on how hard one has been
    pounding the drive with writes, there is no reason that error recovery can't
    creep up into the multiple-minute domain in some cases if you happen to have
    excessively high temperature, vibrations, and be working on an old drive
    with ratty servo bursts in a certain location or something.

    > FLUSH CACHE/FLUSH CACHE EXT ...
    >
    > If you have a drive that is not larger than 28-bit in geometry
    > regardless if it supports the 48-bit feature set, if it fails
    > to comply with 28-bit flush cache it is a "BAD DEVICE", period.

    Agreed. They're different opcodes, E7 and EA.

    In either case, according to the spec, when a FLUSH CACHE (normal or EXT,
    doesn't matter) completes with "good" status (0x50) all the write cache has
    been successfully flushed to the disk.

    A 48-bit sized drive should still commit dirty data when issued the 28-bit
    FLUSH CACHE command, it will simply have problems reporting potential error
    locations if it gets a fatal error on the write.

    > You will not be allowed to push off the 48-bit feature set rules.
    > Regardless if the new smart data is set the the GPL and not Smart
    > Logs.

    I don't understand what you mean. I am looking at the ATA7 r1a spec now,
    and don't see the 48-bit specific feature set rules that you're referring to
    being "pushed off".

    >If you are suggesting a pole for completion on the FLUSH, say so.
    >Otherwise, standard non-data INTQ completion is default.

    Clearing of the busy bit with a status of 0x50 is what to look for. Polled
    or INTQ doesn't matter.

    If the drive reports 0x50 without a completely clean write cache, it is
    broken.


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:34    [W:0.155 / U:0.128 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site