On Wed, 19 May 2004, Herbert Xu wrote:
> > OK, how about this patch?
>
> Let's fix QHs/TDs too. Plus I forgot to set the age when the current
> pending list is removed...
This looks very good. Give me some time to study and test it, and I'll
get back to you.
Alan Stern
---
On Wed, May 19, 2004 at 11:02:52PM +1000, herbert wrote:
> On Thu, May 13, 2004 at 10:26:25PM -0400, Alan Stern wrote:
> >
> > Nothing guarantees it! That's one of the other things that needs to be
> > fixed. The way I eventually want it to work is that there will be a list
> > of urbp's that ha
On Thu, May 13, 2004 at 10:26:25PM -0400, Alan Stern wrote:
>
> Nothing guarantees it! That's one of the other things that needs to be
> fixed. The way I eventually want it to work is that there will be a list
> of urbp's that have been removed from the schedule and are waiting for the
> hardwar
On Fri, 14 May 2004, Herbert Xu wrote:
> I beg to differ here. No driver should ever dead-lock just because
> the interrupts stop flowing for whatever reason.
You're right, of course. The thing is, the UHCI driver needs so many
changes, a couple of which are fairly fundamental, that I'm reluct
On Fri, May 14, 2004 at 07:52:00AM +1000, herbert wrote:
>
> > If you rewrite your patch to use a timer (with a 2 ms minimum delay)
> > instead of a tasklet, I will consider adding it as a stopgap until the
> > driver is reworked.
>
> Why is the delay necessary?
Right, I suppose you were referr
On Thu, May 13, 2004 at 12:23:22PM -0400, Alan Stern wrote:
>
> That bug report mentions kernel 2.6.4. Is the problem still present in
> 2.6.6? The best approach is to fix the problem with resume, not to try
> and clean up when it fails.
I beg to differ here. No driver should ever dead-lock ju
On Thu, 13 May 2004, Herbert Xu wrote:
> Well it is still dead-locking in the same way. Please see
> http://bugs.debian.org/239245.
That bug report mentions kernel 2.6.4. Is the problem still present in
2.6.6? The best approach is to fix the problem with resume, not to try
and clean up when it
On Mon, Dec 08, 2003 at 04:37:26PM -0500, Alan Stern wrote:
> On Tue, 9 Dec 2003, Herbert Xu wrote:
>
> > On Mon, Dec 08, 2003 at 01:04:39PM -0500, Johannes Erdfelt wrote:
> >
> > > Regardless, this patch makes things worse. We need to wait for the next
> > > frame to know the hardware is done usi
> I still think the proper approach is to fix suspend/resume. Detecting
> malfunctioning interrupts during HC startup won't help because resume is
> different from startup. Just detecting them during resume won't help
> either, because pre-existing URBs will still be linked.
Quick evil thou
This is a little bit behind-hand in the thread, but bear with me...
On Tue, 9 Dec 2003, Herbert Xu wrote:
> The problem here is the khubd is stuck in usb_set_address() waiting
> for the URB to complete, but it never finishes because the UHCI driver
> isn't getting any interrupts.
>
> Unloading U
> > I'd expect that Herbert was getting the "Unlink after no-IRQ? ..."
> > message from hcd_unlink_urb() ... I added that a while back, and
I don't get that error because the interrupts stopped working after a
suspend/resume. Since the saw_irq flag isn't reset during a
suspend/resume that message
On Mon, Dec 08, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
>
> >>I've thought that OHCI could detect this "IRQs are broken"
> >>problem earlier. I suspect UHCI could use the same kind of
> >>fix that came to mind: as the HCD starts, enable an IRQ
> >>for SOF, and wait a couple milliseconds
I've thought that OHCI could detect this "IRQs are broken"
problem earlier. I suspect UHCI could use the same kind of
fix that came to mind: as the HCD starts, enable an IRQ
for SOF, and wait a couple milliseconds to make sure it
had a chance to arrive. If it came -- continue. Else,
report IRQ
On Mon, Dec 08, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
> Herbert Xu wrote:
>
> > The problem here is the khubd is stuck in usb_set_address() waiting
> > for the URB to complete, but it never finishes because the UHCI driver
> > isn't getting any interrupts.
>
> OHCI could have the same p
Herbert Xu wrote:
The problem here is the khubd is stuck in usb_set_address() waiting
for the URB to complete, but it never finishes because the UHCI driver
isn't getting any interrupts.
OHCI could have the same problem.
EHCI doesn't, since it's had a timer interrupt ever since it
first needed on
On Mon, Dec 08, 2003 at 04:37:26PM -0500, Alan Stern wrote:
>
> That's supposed to work right now. However, there may be a problem with
> the uhci_stop() routine. While I haven't checked this in detail, it
> appears that the first calls to uhci_free_pending_qhs() and
> uhci_free_pending_tds()
On Tue, Dec 09, 2003 at 08:02:07AM +1100, herbert wrote:
>
> Sorry about that. Can you please comment on the following patch which
> no longer frees the QHs and TDs outside of the interrupt routine.
I guess this patch has the same problems as the last since the TDs
might still be active. But if
On Tue, 9 Dec 2003, Herbert Xu wrote:
> On Mon, Dec 08, 2003 at 01:04:39PM -0500, Johannes Erdfelt wrote:
> >
> > I'll echo what Alan said and say the real fix here is fixing the
> > suspend/resume case.
>
> I agree completely. However, it would be nice to have a safety net
> when things go wro
On Mon, Dec 08, 2003 at 01:04:39PM -0500, Johannes Erdfelt wrote:
>
> I'll echo what Alan said and say the real fix here is fixing the
> suspend/resume case.
I agree completely. However, it would be nice to have a safety net
when things go wrong. In particular, being able to remove the uhci-hcd
On Mon, Dec 08, 2003, Herbert Xu <[EMAIL PROTECTED]> wrote:
> The UHCI driver only cleans up removed QH/TD/URB entries in the interrupt
> routine. This means that if the interrupts aren't working for whatever
> reason (in my case it's a bug in suspend/resume), these entries will never
> be cleaned
20 matches
Mail list logo
