Re: Continuous stream of small bulk transfers hangs on OHCI-based system

[Tomas Sokorai]

On Mon, Aug 6, 2012 at 12:24 PM, Alan Stern <st...@rowland.harvard.edu> wrote:
> any lines in the dmesg log from boot-up about "enabled Compaq ZFMicro
> chipset quirks"?

BTW, I printk'ed the ohci->flags just to be sure what quirks were
enabled, and only the "do not trust power" was enabled.

> My guess is that ed_rm_list is non-NULL, but for some reason
> finish_unlinks() doesn't do anything -- in particular, it doesn't clear
> ed_rm_list.  As a result the condition in the "if" statement fails and
> OHCI_INTR_SF doesn't get written to regs->intrdisable.

Ding, Ding, Ding!, we have a winner :-)
I did an ugly check:

        if (ohci->ed_rm_list)
                finish_unlinks (ohci, ohci_frame_no(ohci));
        if ((ints & OHCI_INTR_SF) != 0
                        && !ohci->ed_rm_list
                        && !ohci->ed_to_check
                        && ohci->rh_state == OHCI_RH_RUNNING)
                ohci_writel (ohci, OHCI_INTR_SF, &regs->intrdisable);
        else if ((ints & OHCI_INTR_SF) != 0
                        && ohci->ed_rm_list
                        && !ohci->ed_to_check
                        && ohci->rh_state == OHCI_RH_RUNNING)
                ohci_warn(ohci,"SF intr should have been disabled, but 
ed_rm_list is
not empty\n");
        spin_unlock (&ohci->lock);

Result: The ed_rm_list definitely stays not null forever after the hang.

This non-empty ed_rm_list condition is raised even when not hung at
quite a rate, but after its hung, this lovely message does a while(1)
dmesg benchmark :-)

-- 
Tomas J. Sokorai Sch.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html