2.6.25-rc7: Ugh. - Kernel

This is a discussion on 2.6.25-rc7: Ugh. - Kernel ; Mark Lord wrote: > (CCing linux-usb again) > (CCing Alan Stern on this sub-thread) > > Oliver Neukum wrote: >> Am Montag, 31. März 2008 21:21:45 schrieb Mark Lord: >>> Oliver Neukum wrote: >>>> But if power is cut with ...

+ Reply to Thread
Page 4 of 5 FirstFirst ... 2 3 4 5 LastLast
Results 61 to 80 of 84

Thread: 2.6.25-rc7: Ugh.

  1. 2.6.25-rc7/rc8 USB dead on resume

    Mark Lord wrote:
    > (CCing linux-usb again)
    > (CCing Alan Stern on this sub-thread)
    >
    > Oliver Neukum wrote:
    >> Am Montag, 31. März 2008 21:21:45 schrieb Mark Lord:
    >>> Oliver Neukum wrote:
    >>>> But if power is cut with newer kernels and older kernels retain it,
    >>>> something
    >>>> must have changed. Can you undo the ACPI changes since the last working
    >>>> kernel?
    >>> ..
    >>>
    >>> No, that's no different.
    >>> This notebook always cuts +5V from USB on suspend or poweroff.
    >>> Regardless of kernel version. I don't know how common this is,
    >>> but all of my notebooks here have always behaved this way,
    >>> as have most (but not all) of the larger systems.
    >>>
    >>> The two most recent PCIe motherboards I have here
    >>> do provide +5V standby power to USB, even when "OFF",
    >>> much to my annoyance and to the detriment of this planet.

    >>
    >> Very well.
    >>
    >> Mark, can you get a sysrq-t trace of your whole system when USB goes
    >> dead? And please enable CONFIG_USB_DEBUG. We need to do whether
    >> khubd and ksuspend_usbd are in state D.

    > ..
    >
    > Both of those things were already done, and results from the last time
    > are attached to the bugzilla report:
    > http://bugzilla.kernel.org/show_bug.cgi?id=10345
    >
    > I'll be installing -rc8 today, and see what happens there.

    ...

    No change in -rc8. I've uploaded new syslog (with alt-sysrq-T) and .config
    as attachements to the bugzilla entry:

    http://bugzilla.kernel.org/show_bug.cgi?id=10345

    --
    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: 2.6.25-rc7: Ugh.

    On Wed, 2 Apr 2008, Mark Lord wrote:

    > I'll be installing -rc8 today, and see what happens there.


    Have you tried testing with all the USB drivers present except
    ehci-hcd? So far all the indicators are that it is the source of the
    problem.

    Also, check out the thread on LKML started by Tino Keitel. He had
    similar problems and found that reverting commit
    e82cc1288fa57857c6af8c57f3d07096d4bcd9d9 fixed them.

    Alan Stern

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

  3. Re: 2.6.25-rc7/rc8 USB dead on resume

    Am Mittwoch, 2. April 2008 17:05:21 schrieb Mark Lord:
    > Mark Lord wrote:


    > No change in -rc8. I've uploaded new syslog (with alt-sysrq-T) and .config
    > as attachements to the bugzilla entry:
    >
    > http://bugzilla.kernel.org/show_bug.cgi?id=10345
    >
    >


    Same analysis. ehci_endpoint_disable() is spinning and ksuspend_usb
    is waiting for it.

    Regards
    Oliver

    PS: Sorry for not looking at the full bugzilla entry

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

  4. Re: 2.6.25-rc7: Ugh. ---> PATCH

    Mark Lord wrote:
    > Mark Lord wrote:
    >> This patch seems to fix it.
    >> Could you guys look this over some more,
    >> as I really am not familiar with the USB code.

    >
    > Here it is again, with more lines of context, for easier review:

    ...

    Nope. Nevermind.

    Just got lucky once, without the resistor installed on USB power.

    The patch doesn't fix it. But that code still looks strange to me.

    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/

  5. Re: 2.6.25-rc7: Ugh. ---> PATCH

    This patch seems to fix it.
    Could you guys look this over some more,
    as I really am not familiar with the USB code.

    * * * *

    When comparing 2.6.24 against 2.6.25, this line of code
    stood out as not looking entirely correct, given the new
    uses of QH_STATE_UNLINK_WAIT in 2.6.25.

    Applying this patch seems to fix the USB suspend/resume deaths
    on my machine here. More testing is needed to be sure.

    Signed-off-by: Mark Lord


    --- linux-2.6.25-rc8/drivers/usb/host/ehci-hcd.c 2008-03-11 11:18:40.000000000 -0400
    +++ linux/drivers/usb/host/ehci-hcd.c 2008-04-02 11:36:13.000000000 -0400
    @@ -815,7 +815,7 @@
    end_unlink_async(ehci);

    /* if it's not linked then there's nothing to do */
    - if (qh->qh_state != QH_STATE_LINKED)
    + if (qh->qh_state != QH_STATE_LINKED && qh->qh_state != QH_STATE_UNLINK_WAIT)
    ;

    /* defer till later if busy */
    --
    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/

  6. Re: 2.6.25-rc7: Ugh. ---> PATCH

    Mark Lord wrote:
    > This patch seems to fix it.
    > Could you guys look this over some more,
    > as I really am not familiar with the USB code.


    Here it is again, with more lines of context, for easier review:

    * * *

    When comparing 2.6.24 against 2.6.25, this line of code
    stood out as not looking entirely correct, given the new
    uses of QH_STATE_UNLINK_WAIT in 2.6.25.

    Applying this patch seems to fix the USB suspend/resume deaths
    on my machine here. More testing is needed to be sure.

    Signed-off-by: Mark Lord
    ---

    Regenerated with more context in diff, for easier review.

    --- linux/drivers/usb/host/ehci-hcd.c.orig 2008-03-11 11:18:40.000000000 -0400
    +++ linux/drivers/usb/host/ehci-hcd.c 2008-04-02 11:36:13.000000000 -0400
    @@ -801,35 +801,35 @@
    return intr_submit(ehci, urb, &qtd_list, mem_flags);

    case PIPE_ISOCHRONOUS:
    if (urb->dev->speed == USB_SPEED_HIGH)
    return itd_submit (ehci, urb, mem_flags);
    else
    return sitd_submit (ehci, urb, mem_flags);
    }
    }

    static void unlink_async (struct ehci_hcd *ehci, struct ehci_qh *qh)
    {
    /* failfast */
    if (!HC_IS_RUNNING(ehci_to_hcd(ehci)->state) && ehci->reclaim)
    end_unlink_async(ehci);

    /* if it's not linked then there's nothing to do */
    - if (qh->qh_state != QH_STATE_LINKED)
    + if (qh->qh_state != QH_STATE_LINKED && qh->qh_state != QH_STATE_UNLINK_WAIT)
    ;

    /* defer till later if busy */
    else if (ehci->reclaim) {
    struct ehci_qh *last;

    for (last = ehci->reclaim;
    last->reclaim;
    last = last->reclaim)
    continue;
    qh->qh_state = QH_STATE_UNLINK_WAIT;
    last->reclaim = qh;

    /* start IAA cycle */
    } else
    start_unlink_async (ehci, qh);
    }
    --
    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/

  7. Re: 2.6.25-rc7: Ugh.

    > Also, check out the thread on LKML started by Tino Keitel. He had
    > similar problems and found that reverting commit
    > e82cc1288fa57857c6af8c57f3d07096d4bcd9d9 fixed them.


    And try the change I suggested there: taking the
    HC_IS_RUNNING test out of ehci_iaa_watchdog().

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

  8. Re: 2.6.25-rc7: Ugh.

    David Brownell wrote:
    >> Also, check out the thread on LKML started by Tino Keitel. He had
    >> similar problems and found that reverting commit
    >> e82cc1288fa57857c6af8c57f3d07096d4bcd9d9 fixed them.

    >
    > And try the change I suggested there: taking the
    > HC_IS_RUNNING test out of ehci_iaa_watchdog().

    ...

    Will do, thanks. And there's a similar one in ehci_work(). ??
    --
    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/

  9. [PATCH] usb ehci_iaa_watchdog fix

    David Brownell wrote:
    >> Also, check out the thread on LKML started by Tino Keitel. He had
    >> similar problems and found that reverting commit
    >> e82cc1288fa57857c6af8c57f3d07096d4bcd9d9 fixed them.

    >
    > And try the change I suggested there: taking the
    > HC_IS_RUNNING test out of ehci_iaa_watchdog().

    ...

    Yup, that does indeed cure it.
    Here's a patch, in case you didn't already generate one:

    Signed-off-by: Mark Lord

    --- rc8/drivers/usb/host/ehci-hcd.c 2008-03-11 11:18:40.000000000 -0400
    +++ linux/drivers/usb/host/ehci-hcd.c 2008-04-02 12:16:40.000000000 -0400
    @@ -289,9 +289,7 @@
    * (a) SMP races against real IAA firing and retriggering, and
    * (b) clean HC shutdown, when IAA watchdog was pending.
    */
    - if (ehci->reclaim
    - && !timer_pending(&ehci->iaa_watchdog)
    - && HC_IS_RUNNING(ehci_to_hcd(ehci)->state)) {
    + if (ehci->reclaim && !timer_pending(&ehci->iaa_watchdog)) {
    u32 cmd, status;

    /* If we get here, IAA is *REALLY* late. It's barely
    --
    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/

  10. Re: [PATCH] usb ehci_iaa_watchdog fix

    On Wed, 2 Apr 2008, Mark Lord wrote:

    > Yup, that does indeed cure it.
    > Here's a patch, in case you didn't already generate one:
    >
    > Signed-off-by: Mark Lord
    >
    > --- rc8/drivers/usb/host/ehci-hcd.c 2008-03-11 11:18:40.000000000 -0400
    > +++ linux/drivers/usb/host/ehci-hcd.c 2008-04-02 12:16:40.000000000 -0400
    > @@ -289,9 +289,7 @@
    > * (a) SMP races against real IAA firing and retriggering, and
    > * (b) clean HC shutdown, when IAA watchdog was pending.
    > */
    > - if (ehci->reclaim
    > - && !timer_pending(&ehci->iaa_watchdog)
    > - && HC_IS_RUNNING(ehci_to_hcd(ehci)->state)) {
    > + if (ehci->reclaim && !timer_pending(&ehci->iaa_watchdog)) {
    > u32 cmd, status;
    >
    > /* If we get here, IAA is *REALLY* late. It's barely


    Okay, I'm puzzled. How could this make any difference?
    ehci_bus_suspend() calls end_unlink_async() anyway, whenever reclaim is
    set.

    Is the real problem that it does so before calling ehci_work() instead
    of after calling ehci_halt()?

    Mark, if you want to experiment some more, try reverting your patch
    above and moving:

    if (ehci->reclaim)
    end_unlink_async(ehci);

    in ehci-hub.c:ehci_bus_suspend() to just after the line saying:

    hcd->state = HC_STATE_SUSPENDED;

    Alan Stern

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

  11. Re: [PATCH] usb ehci_iaa_watchdog fix

    On Wednesday 02 April 2008, Mark Lord wrote:
    > David Brownell wrote:
    > >> Also, check out the thread on LKML started by Tino Keitel. He had
    > >> similar problems and found that reverting commit
    > >> e82cc1288fa57857c6af8c57f3d07096d4bcd9d9 fixed them.

    > >
    > > And try the change I suggested there: taking the
    > > HC_IS_RUNNING test out of ehci_iaa_watchdog().

    > ..
    >
    > Yup, that does indeed cure it.


    Given your immediately-preceding experience, I'll wait for a
    bit more confirmation ... but this seems like a candidate to
    merge while 2.6.25 still hasn't frozen!!


    > Here's a patch, in case you didn't already generate one:


    I hadn't; thanks.


    > Signed-off-by: Mark Lord
    >
    > --- rc8/drivers/usb/host/ehci-hcd.c 2008-03-11 11:18:40.000000000 -0400
    > +++ linux/drivers/usb/host/ehci-hcd.c 2008-04-02 12:16:40.000000000 -0400
    > @@ -289,9 +289,7 @@
    > * (a) SMP races against real IAA firing and retriggering, and
    > * (b) clean HC shutdown, when IAA watchdog was pending.
    > */
    > - if (ehci->reclaim
    > - && !timer_pending(&ehci->iaa_watchdog)
    > - && HC_IS_RUNNING(ehci_to_hcd(ehci)->state)) {
    > + if (ehci->reclaim && !timer_pending(&ehci->iaa_watchdog)) {
    > u32 cmd, status;
    >
    > /* If we get here, IAA is *REALLY* late. It's barely
    >



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

  12. Re: [PATCH] usb ehci_iaa_watchdog fix

    Alan Stern wrote:
    > On Wed, 2 Apr 2008, Mark Lord wrote:
    >
    >> Yup, that does indeed cure it.
    >> Here's a patch, in case you didn't already generate one:
    >>
    >> Signed-off-by: Mark Lord
    >>
    >> --- rc8/drivers/usb/host/ehci-hcd.c 2008-03-11 11:18:40.000000000 -0400
    >> +++ linux/drivers/usb/host/ehci-hcd.c 2008-04-02 12:16:40.000000000 -0400
    >> @@ -289,9 +289,7 @@
    >> * (a) SMP races against real IAA firing and retriggering, and
    >> * (b) clean HC shutdown, when IAA watchdog was pending.
    >> */
    >> - if (ehci->reclaim
    >> - && !timer_pending(&ehci->iaa_watchdog)
    >> - && HC_IS_RUNNING(ehci_to_hcd(ehci)->state)) {
    >> + if (ehci->reclaim && !timer_pending(&ehci->iaa_watchdog)) {
    >> u32 cmd, status;
    >>
    >> /* If we get here, IAA is *REALLY* late. It's barely

    >
    > Okay, I'm puzzled. How could this make any difference?
    > ehci_bus_suspend() calls end_unlink_async() anyway, whenever reclaim is
    > set.
    >
    > Is the real problem that it does so before calling ehci_work() instead
    > of after calling ehci_halt()?
    >
    > Mark, if you want to experiment some more, try reverting your patch
    > above and moving:

    ...

    Here's what I did, and yes, this also works. Pick one.

    This patch, suggested by Alan Stern, fixes the hung USB issues
    on my notebook from suspend/resume cycles.

    Signed-off-by: Mark Lord

    --- rc8/drivers/usb/host/ehci-hub.c 2008-03-11 11:18:40.000000000 -0400
    +++ linux/drivers/usb/host/ehci-hub.c 2008-04-02 13:28:50.000000000 -0400
    @@ -135,8 +135,6 @@
    hcd->state = HC_STATE_QUIESCING;
    }
    ehci->command = ehci_readl(ehci, &ehci->regs->command);
    - if (ehci->reclaim)
    - end_unlink_async(ehci);
    ehci_work(ehci);

    /* Unlike other USB host controller types, EHCI doesn't have
    @@ -180,6 +178,9 @@
    ehci_halt (ehci);
    hcd->state = HC_STATE_SUSPENDED;

    + if (ehci->reclaim)
    + end_unlink_async(ehci);
    +
    /* allow remote wakeup */
    mask = INTR_MASK;
    if (!device_may_wakeup(&hcd->self.root_hub->dev))
    --
    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/

  13. Re: [PATCH] usb ehci_iaa_watchdog fix

    Mark Lord wrote:
    > Alan Stern wrote:
    >> On Wed, 2 Apr 2008, Mark Lord wrote:
    >>
    >>> Yup, that does indeed cure it.
    >>> Here's a patch, in case you didn't already generate one:
    >>>
    >>> Signed-off-by: Mark Lord
    >>>
    >>> --- rc8/drivers/usb/host/ehci-hcd.c 2008-03-11 11:18:40.000000000
    >>> -0400
    >>> +++ linux/drivers/usb/host/ehci-hcd.c 2008-04-02
    >>> 12:16:40.000000000 -0400
    >>> @@ -289,9 +289,7 @@
    >>> * (a) SMP races against real IAA firing and retriggering, and
    >>> * (b) clean HC shutdown, when IAA watchdog was pending.
    >>> */
    >>> - if (ehci->reclaim
    >>> - && !timer_pending(&ehci->iaa_watchdog)
    >>> - && HC_IS_RUNNING(ehci_to_hcd(ehci)->state)) {
    >>> + if (ehci->reclaim && !timer_pending(&ehci->iaa_watchdog)) {
    >>> u32 cmd, status;
    >>>
    >>> /* If we get here, IAA is *REALLY* late. It's barely

    >>
    >> Okay, I'm puzzled. How could this make any difference?
    >> ehci_bus_suspend() calls end_unlink_async() anyway, whenever reclaim
    >> is set.
    >>
    >> Is the real problem that it does so before calling ehci_work() instead
    >> of after calling ehci_halt()?
    >>
    >> Mark, if you want to experiment some more, try reverting your patch
    >> above and moving:

    > ..
    >
    > Here's what I did, and yes, this also works. Pick one.
    >
    > This patch, suggested by Alan Stern, fixes the hung USB issues
    > on my notebook from suspend/resume cycles.
    >
    > Signed-off-by: Mark Lord
    >
    > --- rc8/drivers/usb/host/ehci-hub.c 2008-03-11 11:18:40.000000000 -0400
    > +++ linux/drivers/usb/host/ehci-hub.c 2008-04-02 13:28:50.000000000
    > -0400
    > @@ -135,8 +135,6 @@
    > hcd->state = HC_STATE_QUIESCING;
    > }
    > ehci->command = ehci_readl(ehci, &ehci->regs->command);
    > - if (ehci->reclaim)
    > - end_unlink_async(ehci);
    > ehci_work(ehci);
    >
    > /* Unlike other USB host controller types, EHCI doesn't have
    > @@ -180,6 +178,9 @@
    > ehci_halt (ehci);
    > hcd->state = HC_STATE_SUSPENDED;
    >
    > + if (ehci->reclaim)
    > + end_unlink_async(ehci);
    > +
    > /* allow remote wakeup */
    > mask = INTR_MASK;
    > if (!device_may_wakeup(&hcd->self.root_hub->dev))

    ...

    Either patch is stable here, and have survived reboots and suspend/resumes,
    with and without the 2.2Kohm resistor to drain residual USB voltage.

    Which one should Andrew/Linus take?

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

  14. Re: [PATCH] usb ehci_iaa_watchdog fix

    On Wed, 2 Apr 2008, Mark Lord wrote:

    > Either patch is stable here, and have survived reboots and suspend/resumes,
    > with and without the 2.2Kohm resistor to drain residual USB voltage.


    Great! Thanks for testing.

    > Which one should Andrew/Linus take?


    It's up to David, of course. My preference is for the patch I
    proposed, naturally enough. It fixes the cause rather than the
    symptom.

    Alan Stern

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

  15. Re: 2.6.25-rc7: Ugh. ---> PATCH

    On Wed, 2 Apr 2008, Mark Lord wrote:

    > When comparing 2.6.24 against 2.6.25, this line of code
    > stood out as not looking entirely correct, given the new
    > uses of QH_STATE_UNLINK_WAIT in 2.6.25.


    > --- linux-2.6.25-rc8/drivers/usb/host/ehci-hcd.c 2008-03-11 11:18:40.000000000 -0400
    > +++ linux/drivers/usb/host/ehci-hcd.c 2008-04-02 11:36:13.000000000 -0400
    > @@ -815,7 +815,7 @@
    > end_unlink_async(ehci);
    >
    > /* if it's not linked then there's nothing to do */
    > - if (qh->qh_state != QH_STATE_LINKED)
    > + if (qh->qh_state != QH_STATE_LINKED && qh->qh_state != QH_STATE_UNLINK_WAIT)
    > ;
    >
    > /* defer till later if busy */


    To answer your implied question...

    QH_STATE_UNLINK_WAIT doesn't have a new meaning in 2.6.25. Just as
    before, it means that qh is on a queue waiting to be unlinked.

    qh->qh_state can never be equal to QH_STATE_UNLINK_WAIT at this point.
    If it were, it would mean that some part of the driver had tried to
    unlink qh twice. But even then, the correct move would be to follow
    the "nothing to do" path -- since qh is already waiting to be unlinked,
    there's no point trying to do any more.

    Alan Stern

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

  16. Re: [PATCH] usb ehci_iaa_watchdog fix

    On Wednesday 02 April 2008, Alan Stern wrote:
    > > Which one should Andrew/Linus take?

    >
    > It's up to David, of course. *My preference is for the patch I
    > proposed, naturally enough.


    Mine was for the one that got two "it works" confirmations.


    > It fixes the cause rather than the symptom.


    I'm not sure I'd agree with that.

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

  17. Re: 2.6.25-rc7: Ugh.

    On Wednesday 02 April 2008, Mark Lord wrote:
    >
    > > And try the change I suggested there: *taking the
    > > HC_IS_RUNNING test out of ehci_iaa_watchdog().

    > ..
    >
    > Will do, thanks. *And there's a similar one in ehci_work(). *??


    Don't see why that should matter. In any case, that
    test hasn't changed recently.

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

  18. Re: [PATCH] usb ehci_iaa_watchdog fix

    On Wednesday 02 April 2008, Alan Stern wrote:
    > > -*****if (ehci->reclaim
    > > -*********************&& !timer_pending(&ehci->iaa_watchdog)
    > > -*********************&& HC_IS_RUNNING(ehci_to_hcd(ehci)->state)) {
    > > +*****if (ehci->reclaim && !timer_pending(&ehci->iaa_watchdog)) {
    > > **************u32 cmd, status;
    > > *
    > > **************/* If we get here, IAA is *REALLY* late. *It's barely

    >
    > Okay, I'm puzzled. *How could this make any difference?


    It's more like: what else in that patch could have had
    any such effect? That HC_IS_RUNNING test was the only
    candidate.

    Those hcd->state tests have been getting more and more
    dodgey as time goes by. At this point I hardly trust
    any of them. There *IS* no clear state machine which
    governs the usbcore/HCD interaction.

    - Dave


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

  19. Re: [PATCH] usb ehci_iaa_watchdog fix

    On Wed, 2 Apr 2008, David Brownell wrote:

    > Those hcd->state tests have been getting more and more
    > dodgey as time goes by. At this point I hardly trust
    > any of them. There *IS* no clear state machine which
    > governs the usbcore/HCD interaction.


    ISTR trying to make that same point a few times over the past two or
    three years... :-)

    It would make more sense for each HCD to keep its own private "state"
    variable. The interaction with usbcore can be broken down into a few
    simple tests, such as:

    Is the HC dead?
    Is the HC (i.e., the PCI or platform device) suspended?
    Is the HC running?
    Is it okay to submit an URB?

    There's plenty of redundancy in this list, and some of the information
    may already be available in hcd->self.root_hub->state. In many or most
    cases, these questions can't be answered in a race-free manner anyhow,
    which limits their usefulness.

    Alan Stern

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

  20. Re: [PATCH] usb ehci_iaa_watchdog fix

    On Wed, 2 Apr 2008, David Brownell wrote:

    > > It fixes the cause rather than the symptom.

    >
    > I'm not sure I'd agree with that.


    Really? The logic seemed clear enough to me.

    1. Evidently the ehci_iaa_watchdog routine was getting called at a
    time when the host controller wasn't running -- which had to
    have been after it was suspended.

    2. But ehci_bus_suspend() calls end_unlink_async(), which turns
    off the IAA watchdog timer.

    3. Hence the timer must have been restarted later on while
    ehci_bus_suspend() was still running. The call to ehci_work()
    appeared to be the only place that could have happened.

    4. Thus moving the end_unlink_async() call to after ehci_work()
    (or just to be doubly safe, after ehci_halt() and the change
    to HC_STATE_SUSPENDED) should take care of all pending QH
    unlinks and leave none of them unfinished.

    Strictly speaking, it would be best to move the del_timer_sync() calls
    to after ehci_lock is released. But it doesn't really matter if the
    timer routines get invoked after the controller is suspended.

    Alan Stern

    --
    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 4 of 5 FirstFirst ... 2 3 4 5 LastLast