[git patches] libata updates - Kernel

This is a discussion on [git patches] libata updates - Kernel ; J.A. Magallón wrote: > On Thu, 08 May 2008 11:35:11 -0400, Jeff Garzik wrote: > >> Markus Trippelsdorf wrote: >>>> Tejun Heo (12): >>>> libata: improve post-reset device ready test >>> This commit (78ab88f04f44bed566d51dce0c7cbfeff6449a06) causes a long >>> boot delay ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 22 of 22

Thread: [git patches] libata updates

  1. Re: [PATCH] Re: [git patches] libata updates - (improve post-reset device ready test) regression

    J.A. Magallón wrote:
    > On Thu, 08 May 2008 11:35:11 -0400, Jeff Garzik wrote:
    >
    >> Markus Trippelsdorf wrote:
    >>>> Tejun Heo (12):
    >>>> libata: improve post-reset device ready test
    >>> This commit (78ab88f04f44bed566d51dce0c7cbfeff6449a06) causes a long
    >>> boot delay with my onboard Promise controller. It seems like libata
    >>> probes for a nonexisting PATA drive...
    >>>

    >
    > I also had this patch collected from LKML, that still applies to -git6.
    > Is it really needed ?
    > ref: http://marc.info/?l=linux-ide&m=120913178617926&w=2

    ...
    > --- upstream/drivers/ata/libata-eh.c 2008-04-30 17:35:36.000000000 -0400
    > +++ linux/drivers/ata/libata-eh.c 2008-04-30 17:35:45.000000000 -0400
    > @@ -1312,8 +1312,7 @@
    > err_mask |= AC_ERR_ATA_BUS;
    > action |= ATA_EH_RESET;
    > }
    > - if (serror &
    > - (SERR_DATA_RECOVERED | SERR_COMM_RECOVERED | SERR_DATA)) {
    > + if (serror & (SERR_DATA_RECOVERED | SERR_DATA)) {
    > err_mask |= AC_ERR_ATA_BUS;
    > action |= ATA_EH_RESET;
    > }


    ...

    The original problem I had, which prompted this patch, eventually was
    resolved in other ways. But I do think that a hw-recovered bit in SError
    is not a good reason to reset everything.

    Tejun suggested that we still want to know about such errors,
    and eventually do something if they repeat often enough.
    But doing a port/link reset every single time ?

    > @@ -1924,7 +1923,7 @@
    > }
    >
    > if (ehc->i.serror)
    > - ata_port_printk(ap, KERN_ERR,
    > + ata_link_printk(link, KERN_ERR,
    > "SError: { %s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s}\n",
    > ehc->i.serror & SERR_DATA_RECOVERED ? "RecovData " : "",
    > ehc->i.serror & SERR_COMM_RECOVERED ? "RecovComm " : "",
    >

    ...

    That portion of the patch is still a very good idea.

    Cheers
    --
    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/

  2. Re: [PATCH] Re: [git patches] libata updates - (improve post-reset device ready test) regression

    Jeff Garzik wrote:
    > Tejun Heo wrote:
    >> This means that we need to make custom readiness tests for controllers
    >> using 0x77 or 0x7f. Eeeek... Both groups of controllers are behaving
    >> in incorrect way. Controllers shouldn't use 0x77 or 0x7f for either
    >> busy or ready states - it's invalid for both, yet, some use the 77/7f
    >> for busy while others use them for ready state. Great. :-(

    >
    > I think that's assuming too much? PATA and SATA are quite different
    > here... in PATA the status is mostly the value from the device directly
    > off the wires. in SATA, it may be from the device or from the
    > controller. And "smart" or firmware-based controllers may generate
    > their own status, too, apart from the device's status.
    >
    > So that results in varied status returns, and not all the time is a
    > definite "ready" or "not ready" obvious.


    I think it's pretty safe to say that these weird ready values are from
    TF emulation on controller side. The ready/not ready distinction is
    probably too simplistic but those values aren't supposed to appear
    during post-reset readiness test.

    Sorry about the big regression. Heh... It's amazing how all the
    controllers I tested didn't show the problem and I did test a good
    number of combinations.

    I still think it would be better to have a unified readiness test
    function. The problem is subtle (device misdetection on hotplug of
    certain drives) and went unnoticed quite some time for JMB ahcis && test
    coverage over those things can't be good. I'll try to think about
    something better.

    Thanks.

    --
    tejun
    --
    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/

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2