Re: [linux-usb-devel] USB deadlock after resume

[Markus Rechberger]

On 11/21/07, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, 21 Nov 2007, Markus Rechberger wrote:
>
> > > > 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.
>
> That's very strange.  Getting -71 errors is understandable; it
> indicates that the device can't handle being suspended.  But the
> wait_event() line still shouldn't hang.  If it does, it indicates that
> there's something wrong with the USB host controller, not just the
> device.
>
> Can you try testing this on a different sort of computer?
>

Not really, suspending doesn't work at all on my other notebook it
just freezes..
I'm basically trying to get that driver work on my eee PC [1], it's
cheap and tiny so I don't expect anything special in there..
The system is preloaded with Xandros (it's debian etch with a few
custom applications) and linux 2.6.21.4.

The system still locks up, although only if I leave the video
application running during suspending. I don't have to reload the
driver anymore after resuming if the video node doesn't get accessed
(I'm looking for races in the uvc driver at the moment).

thanks,
Markus

[1] http://eeepc.asus.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/