On Thu, Mar 18, 2004 at 09:14:36AM -0800, Torrey Hoffman wrote:
> On Thu, 2004-03-18 at 07:44, Oliver Neukum wrote:
> > Hi,
> >
> > you must use set_current_state() only after usb_submit_urb() with GFP_KERNEL
> > as second argument, because it may sleep to allocate memory and is woken up
> > reset
On Thu, Mar 18, 2004 at 06:49:01PM +0100, Oliver Neukum wrote:
>
> > So, the attached patch against 2.6.5-rc1-mm1 includes a mutex to lock
> > the open/disconnect paths, modelled after the usb-skeleton driver. It
> > includes Oliver Neukum's fixes and other cleanups as well.
> >
> > Greg, if Oliv
Am Thursday 18 March 2004 19:57 schrieb Juergen Stuber:
> Hi,
>
> Oliver Neukum <[EMAIL PROTECTED]> writes:
> > Am Thursday 18 March 2004 17:27 schrieb Stephen Hemminger:
> >>
> >> Wouldn't this be a good place to use wait_event_interruptible macro?
> >
> > If you find a way to use it with a time
Hi,
Oliver Neukum <[EMAIL PROTECTED]> writes:
> Am Thursday 18 March 2004 17:27 schrieb Stephen Hemminger:
>>
>> Wouldn't this be a good place to use wait_event_interruptible macro?
>
> If you find a way to use it with a timeout, yes it would.
what's wrong with wait_event_interruptible_timeout()
> So, the attached patch against 2.6.5-rc1-mm1 includes a mutex to lock
> the open/disconnect paths, modelled after the usb-skeleton driver. It
> includes Oliver Neukum's fixes and other cleanups as well.
>
> Greg, if Oliver's patches have already been applied I can send along a
> smaller patch w
On Thu, 2004-03-18 at 07:44, Oliver Neukum wrote:
> Hi,
>
> you must use set_current_state() only after usb_submit_urb() with GFP_KERNEL
> as second argument, because it may sleep to allocate memory and is woken up
> resetting the state to TASK_RUNNING. In that case you had a busy polling loop.
>
