Matthew Dharm wrote:
> My previous observations are that URBs for disconnected devices are
> completed very quickly (i.e. <1 sec). There has been some suggestion that
> there might be a case where this is not true... I have not seen it, and
> would like to know where it might exist.
>
> And yes,
Matthew Dharm wrote:
> The issue is the word 'often', which implies 'sometimes not'.
>
> If the urb completes via unlink or transfer failure, that's fine. I chose
> not to unlink and let them fail. But if there is a condition under which
> they won't fail, I'd like to know about it.
That condi
>>Test case: user pulls out the usb cable while a transfer is in progress.
>>urb submitted to the device, reply not yet received.
>>Result: storage_disconnect() would hang for 20 seconds until
>>command_abort() is called.
>
>
> No, not quite. The HCD accelerates the URBs to completion if the
On Thu, Jul 04, 2002 at 04:54:32PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Jul 04, 2002 at 12:50:12PM -0700, Matthew Dharm escreveu:
> > > > Because relying on a pointer has caused problems in the past, especially
> > > > when there are concerns that the pointer might be invalid.
>
> > >
On Thu, Jul 04, 2002 at 07:12:40PM +0200, Manfred Spraul wrote:
> Matthew Dharm wrote:
> >
> >>E.g. queue_command stored new commands in ->queue_srb. The worker thread
> >>then moved it from queue_srb to srb and set sm_state to RUNNING.
> >>
> >>But what if command_abort() is called before the w
Matthew Dharm wrote:
>
>>E.g. queue_command stored new commands in ->queue_srb. The worker thread
>>then moved it from queue_srb to srb and set sm_state to RUNNING.
>>
>>But what if command_abort() is called before the worker thread is scheduled?
>
>
> Then we have a serious problem, because t
On Thu, Jul 04, 2002 at 12:19:28AM +0200, Manfred Spraul wrote:
> Matthew Dharm wrote:
> > I don't understand what this patch is trying to do...
> >
> > You're reverting our new state machine changes... why?
> >
>
> Because the state machine doesn't work. I've degraded it into a
> debugging st
Matthew Dharm wrote:
> I don't understand what this patch is trying to do...
>
> You're reverting our new state machine changes... why?
>
Because the state machine doesn't work. I've degraded it into a
debugging state.
I've described it in a mail I send to you and linux-usb-devel a few
weeks
I don't understand what this patch is trying to do...
You're reverting our new state machine changes... why?
You're reverting the new mechanism to determine device state... why?
You're removing the entire bus_reset() logic... why?
This patch undoes most of the work done in the last few months.
