[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d9def9db0711210642h23db950vdc0fe1b9802e3e8b@mail.gmail.com>
Date: Wed, 21 Nov 2007 15:42:43 +0100
From: "Markus Rechberger" <mrechberger@...il.com>
To: "Oliver Neukum" <oliver@...kum.org>
Cc: "Mark Lord" <lkml@....ca>, linux-kernel@...r.kernel.org,
linux-usb-devel@...ts.sourceforge.net,
"Laurent Pinchart" <laurentp@...-semaphore.com>
Subject: Re: USB deadlock after resume
On 11/21/07, Markus Rechberger <mrechberger@...il.com> wrote:
> On 11/21/07, Oliver Neukum <oliver@...kum.org> wrote:
> > Am Mittwoch 21 November 2007 schrieb Markus Rechberger:
> > > On 11/21/07, Markus Rechberger <mrechberger@...il.com> wrote:
> > > > On 11/21/07, Mark Lord <lkml@....ca> wrote:
> > > > > Markus Rechberger wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I'm looking at the linux uvc driver, and noticed after resuming my
> > > > > ..
> > > > >
> > > > > Pardon me.. what is the "uvc" driver? Which module/source file is
> > that?
> > > > >
> > > >
> > > > http://linux-uvc.berlios.de/ it's not yet included in the kernel
> > > > sources although many distributions already ship it.
> > > > A "dry" run putting the device into sleep mode works fine (I added a
> > > > proc interface for calling those suspend/resume function).
> > > >
> > >
> > > it's not just usb_set_interface that hangs actually.
> > > It seems to hang at
> > >
> > > wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0);
> > >
> > > in drivers/usb/core/urb.c after resuming. I disabled access to the usb
> > > subsystem in the uvc driver, although connecting any other usb storage
> > > fails too, just at the same point.
> >
> > Which URB is usb_kill_urb() called for?
> >
>
> it's the usb_control_message which calls usb_kill_urb if I haven't got
> it wrong. (if you're looking for some other information please let me
> know)
> Although, I got a bit further with it. The error seems to happen
> earlier already.
> If I load the driver, and do not access the device after suspending
> all usb_control commands fail with -71 eproto.
>
> Reloading the driver doesn't help at tht point, only reconnecting the
> device does.
>
> The data is transfered using bulk transfer.
>
Do you know any good way for performing a softreset within the driver?
The video application should get a continuous datastream after
resuming the notebook, so the driver shouldn't be unloaded.
The driver also keeps a list of previous camera settings which should
be set up again after resuming. Stopping the video application and
reattaching the device using ACPI (this board supports reconnecting
the device using ACPI) should be avoided.
Markus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists