On Saturday 18 June 2005 12:26 pm, Matthias Urlichs wrote:
> Hi,
>
> (I don't know if my earlier mail went through, I had a full disk)
>
> David Brownell:
> > But there are some OHCI implementations (OPTi comes to mind, and SiS)
> > that won't issue UE ... in /sys/class/usb_host/usbN/registers, t
Hi,
(I don't know if my earlier mail went through, I had a full disk)
David Brownell:
> But there are some OHCI implementations (OPTi comes to mind, and SiS)
> that won't issue UE ... in /sys/class/usb_host/usbN/registers, there
No such file exists on my system (2.6.11, mostly). Has that been ad
Hi,
David Brownell:
> > I am not sure how to recover from that. Apparently the chip has wedged
> > itself into a corner..?
>
> Or someone's wedged it. What drivers did you say were active at
> the time?
>
The new Option driver (mine, incidentally), though it also happens with
the standard Seria
On Friday 17 June 2005 5:12 pm, Matthias Urlichs wrote:
> Hi,
>
> > > The question in this case would seem to be why the donelist processing
> > > wasn't catching the TD at the list head. You might add a debug check
> > > calling ohci_dump_td() on the TD triggering that skip_ed branch; or
> > > m
Hi,
> > The question in this case would seem to be why the donelist processing
> > wasn't catching the TD at the list head. You might add a debug check
> > calling ohci_dump_td() on the TD triggering that skip_ed branch; or
> > maybe even ohci_dump_ed(verbose) to see the whole queue there. If
>
Hi,
David Brownell:
> Clearly a tricky combination of events, there could be a bug lurking,
Seems like there is, otherwise I wouldn't see this problem. :-/
> The question in this case would seem to be why the donelist processing
> wasn't catching the TD at the list head. You might add a debug c
On Sunday 12 June 2005 7:49 am, Matthias Urlichs wrote:
> Hi,
>
> I am seeing this problem with the OHCI driver:
>
> Occasionally, this test in finish_unlinks() ...
>
> > /* INTR_WDH may need to clean up first */
> > if (td->td_dma != head)
Hi,
Alan Stern:
> Not to disparage the point of your original posting, control and bulk URBs
> should always have timeouts of one form or another.
... which just tells you that sometimes I'm stupid -- the URB in
question _did_ have a timeout.
(Its status was -ECONNRESET, if that matters.)
--
M
On Sun, 12 Jun 2005, Matthias Urlichs wrote:
> Worse: If the URB is a control request with no timeout, the only way
> to un-wedge the program in question is to remove the OHCI module -- or
> the physical OHCI, if it happens to be hot-swappable.
Not to disparage the point of your original posting,
