On Mon, 6 Aug 2012, Tomas Sokorai wrote: > 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, ®s->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 :-) It's normal to see this happen during ordinary use, although perhaps your rate is higher than it should be. Anyway, the next step is to look inside finish_unlinks() in ohci-q.c to figure out what's going wrong. I don't have time today to look further into this, but I'll get back to you later. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
