[lkml]   [2010]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [git patches] libata updates for 2.6.34
    On Mon, Mar 15, 2010 at 2:06 PM, Jeff Garzik <> wrote:
    > On 03/15/2010 03:33 AM, Zeno Davatz wrote:
    >> On Mon, Mar 15, 2010 at 3:55 AM, Jeff Garzik<>  wrote:
    >>> On 03/09/2010 11:26 PM, Tejun Heo wrote:
    >>>> Hello, Linus, Jeff.
    >>>> On 03/10/2010 07:12 AM, Jeff Garzik wrote:
    >>>>> Coincedentally, it looks like someone else just reported the same
    >>>>> problem, with 2.6.34-rc1.
    >>>>> It definitely sounds like a race.  READ DMA is a DMA command as the
    >>>>> name
    >>>>> implies, so that eliminates the possibility of polling-related paths in
    >>>>> ata_sff_interrupt (libata-sff.c).
    >>>>> I'll flip some of my machines to the icky slow boring piix mode, rather
    >>>>> than sexy AHCI mode :) to see if I can reproduce.  I have had a feeling
    >>>>> that we needed a more sophisticated IRQ handling setup, this may be
    >>>>> what
    >>>>> was needed.  Lost interrupt recovery should occur faster than 30
    >>>>> seconds
    >>>>> in any case, and should not require a hard reset if the hardware
    >>>>> functions just fine outside of the lost-interrupt / race that just
    >>>>> occurred.
    >>>> Yeap, there is a race condition with clearing which I don't think we
    >>>> can solve completely but with some modification I think we can at
    >>>> least cover known failure cases.
    >>>> For longer term, I don't think we can solve this by diddling with the
    >>>> SFF registers.  The interface is just way too ancient and horrid to
    >>>> build anything reliable on top of.  I'm planning on implementing
    >>>> smarter IRQ storm handling and stepped timeouts for ATA commands.
    >>> A tester on this bug
    >>> seemed to find success with the patch.
    >> Thanks for the Update!
    >> I will wait some more and then test rc-2.
    > Can you test the patch, please?

    Sure. I done:

    /usr/src/linux> sudo patch -p1 < teo
    patching file drivers/ata/libata-sff.c
    Hunk #1 FAILED at 1667.
    Hunk #2 FAILED at 1700.
    Hunk #3 FAILED at 1718.
    Hunk #4 FAILED at 1770.
    Hunk #5 FAILED at 1792.
    Hunk #6 FAILED at 1801.
    Hunk #7 FAILED at 1818.
    7 out of 7 hunks FAILED -- saving rejects to file drivers/ata/libata-sff.c.rej

    Is that the expected outcome? Can I ignore the "failed" output?

    Now I guess I still need to do "make", lilo and reboot.

    Let me know.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2010-03-15 14:25    [W:0.024 / U:37.216 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site