On 09/09/05 13:08, Stefan Richter wrote:
> Luben Tuikov wrote:
>
>>Think about this:
>> EH is function of scsi_host.
>
>
> The host does not use the EH. The EH uses the host.
That's exactly what my statement above means:
F(scsi_host) = EH
>> You can define YOUR OWN EH! in us
Luben Tuikov wrote:
Think about this:
EH is function of scsi_host.
The host does not use the EH. The EH uses the host.
You can define YOUR OWN EH! in usb storage, which you control!
There are a few hotpluggable low-level providers besides usb-storage.
--
Stefan Richter
-
Alan Stern <[EMAIL PROTECTED]> wrote:
> The conundrum I'm facing is how to make sure that when scsi_remove_host
> returns, the mid-layer is no longer sending anything to the host. Sure,
> no new commands will be issued once the state is set to DEL (or
> DEL_RECOVERY). But what about commands/rese
On Fri, 9 Sep 2005, James Bottomley wrote:
> On Fri, 2005-09-09 at 11:16 -0400, Alan Stern wrote:
> > > So which way do you want to go? Either we wait in recovery for the
> > > error handler to finish and transition the host state to RUNNING or we
> > > introduce the parallel states for the error
On Fri, 2005-09-09 at 11:16 -0400, Alan Stern wrote:
> > So which way do you want to go? Either we wait in recovery for the
> > error handler to finish and transition the host state to RUNNING or we
> > introduce the parallel states for the error handler.
>
> For usb-storage it won't make any dif
On Fri, 9 Sep 2005, James Bottomley wrote:
> So which way do you want to go? Either we wait in recovery for the
> error handler to finish and transition the host state to RUNNING or we
> introduce the parallel states for the error handler.
For usb-storage it won't make any difference on the whol
On Fri, 2005-09-09 at 10:16 -0400, Alan Stern wrote:
> I see. You must be making an unstated assumption, something along the
> lines of "If the error handler is running then the host is in a *RECOVERY
> state." Given that, there definitely is a need for a separate
> CANCEL_RECOVERY and DEL_RECOV
On Thu, 8 Sep 2005, Luben Tuikov wrote:
> >>So as far as I can see it sends a reset on the wire to the device?
> >
> >
> > Sort of. It's not a low-level hardware reset, it's rather high-level.
> > If the device's firmware is busy doing something else, or is hung, or
> > doesn't implement rese
On Thu, 8 Sep 2005, James Bottomley wrote:
> Yes, a state machine like I've shown can only be in one state at any
> given time. The problem is what happens if the error handler is running
> when you try to remove the device. We can reach in and try to stop it,
> but under a state model we'd have
On 09/08/05 16:15, James Bottomley wrote:
> On Thu, 2005-09-08 at 14:58 -0400, Alan Stern wrote:
>
>>On Thu, 8 Sep 2005, James Bottomley wrote:
>>
>>>Actually, no, that's why we have the parallel EH states ... let me put
>>>in the events that trigger state transitions so you can see what
>>>happen
On 09/08/05 14:36, Alan Stern wrote:
> On Thu, 8 Sep 2005, Luben Tuikov wrote:
>
>
>>>No. There are only two reset mechanisms available for USB Mass Storage.
>>
>>I see.
>>
>>
>>>One is a class-specific reset command (which usb-storage issues when asked
>>>to do a device reset),
>>
>>So as fa
On Thu, 2005-09-08 at 14:58 -0400, Alan Stern wrote:
> On Thu, 8 Sep 2005, James Bottomley wrote:
> > Actually, no, that's why we have the parallel EH states ... let me put
> > in the events that trigger state transitions so you can see what
> > happens:
> >
> >
> > EH thread finishes
> >
On Thu, 8 Sep 2005, James Bottomley wrote:
> Actually, no, that's why we have the parallel EH states ... let me put
> in the events that trigger state transitions so you can see what
> happens:
>
>
> EH thread finishes
> <---
>
> EH thread begins
>
On Thu, 8 Sep 2005, Luben Tuikov wrote:
> > No. There are only two reset mechanisms available for USB Mass Storage.
>
> I see.
>
> > One is a class-specific reset command (which usb-storage issues when asked
> > to do a device reset),
>
> So as far as I can see it sends a reset on the wire
On Thu, 2005-09-08 at 11:59 -0400, Alan Stern wrote:
> I don't understand your reasoning. With your new system, you end up with
> two threads doing this:
>
> Removal thread Error handler thread
> - ---
>
On Wed, 7 Sep 2005, James Bottomley wrote:
> Actually, alloc_target is properly guarded so it doesn't need the scan
> mutex. It might be nice to update the SDEV_ state model to include a
> "scanning" state, that way we could properly guard the sdev_alloc as
> well and dump the scan mutex ... that
On 09/08/05 11:19, Alan Stern wrote:
> On Wed, 7 Sep 2005, Luben Tuikov wrote:
>
>
>>Is it possible to implement LU Reset TMF for USB storage devices?
>>If so, then you do not need to do a "bus reset".
>
>
> Sorry, I don't know that acronym. What is TMF?
Good morning Alan,
I meant Task Manag
On Wed, 7 Sep 2005, James Bottomley wrote:
> I agree (about the deadlocks). However, as things stand RECOVERY is a
> state in the model and the model can only be in a single state. If you
> permit the transition, and recovery is going on in parallel with
> removal, they'll race to set the final
On Wed, 7 Sep 2005, Stefan Richter wrote:
> usb-storage implements scsi_mod bus reset as USB port reset. This
> affects only the failing device.
Correct, but you're forgetting that in USB a single device can contain
more than one "interface", and drivers bind to interfaces, not devices.
Doing a
On Wed, 2005-09-07 at 14:58 -0500, James Bottomley wrote:
> On Wed, 2005-09-07 at 14:27 -0400, Alan Stern wrote:
> > I'm going to argue strongly about this. scsi_remove_host should _not_
> > wait for error recovery to complete -- to do so will invite deadlocks.
> > (Suppose the error handler is
Luben Tuikov wrote:
It is very bad to have to punish all devices on the
"bus" just because one device failed. Isn't there a better way
to recover(*) a failed USB Storage device?
usb-storage implements scsi_mod bus reset as USB port reset. This
affects only the failing device.
There is one s
On 09/07/05 15:31, Alan Stern wrote:
>
> As for layering violations and deadlocks... Unfortunately the violation
> is unavoidable. It's related to the way the error handler sometimes tries
> to fix a non-working device by doing a bus reset, which will also affect
> all the other devices on the s
Alan Stern <[EMAIL PROTECTED]> wrote:
> On Wed, 7 Sep 2005, Luben Tuikov wrote:
>
> > On 09/07/05 14:27, Alan Stern wrote:
>
> > > I'm going to argue strongly about this. scsi_remove_host should _not_
> > > wait for error recovery to complete -- to do so will invite deadlocks.
> > > (Suppose t
On Wed, 2005-09-07 at 14:27 -0400, Alan Stern wrote:
> > The second (allow RECOVERY->CANCEL) isn't really an answer. The correct
> > thing, I suppose, is to have scsi_remove_host() wait for the error
> > handler to finish if the state transition cannot be accomodated
> > (otherwise the error handl
On Wed, 7 Sep 2005, Luben Tuikov wrote:
> On 09/07/05 14:27, Alan Stern wrote:
> > I'm going to argue strongly about this. scsi_remove_host should _not_
> > wait for error recovery to complete -- to do so will invite deadlocks.
> > (Suppose the error handler is waiting for a bus reset, but the
On 09/07/05 14:27, Alan Stern wrote:
> On Wed, 7 Sep 2005, James Bottomley wrote:
>
>
>>On Tue, 2005-07-26 at 10:12 -0400, Alan Stern wrote:
>>
>>>This patch (as542) fixes a few loose ends left by Mike's patches. It adds
>>>a declaration for the new scsi_host_set_state routine, adds an allowed
On 09/07/05 14:27, Alan Stern wrote:
> On Wed, 7 Sep 2005, James Bottomley wrote:
>
>
>>On Tue, 2005-07-26 at 10:12 -0400, Alan Stern wrote:
>>
>>>This patch (as542) fixes a few loose ends left by Mike's patches. It adds
>>>a declaration for the new scsi_host_set_state routine, adds an allowed
On Wed, 7 Sep 2005, James Bottomley wrote:
> On Tue, 2005-07-26 at 10:12 -0400, Alan Stern wrote:
> > This patch (as542) fixes a few loose ends left by Mike's patches. It adds
> > a declaration for the new scsi_host_set_state routine, adds an allowed
> > transition from the SHOST_RECOVERY state
On Tue, 2005-07-26 at 10:12 -0400, Alan Stern wrote:
> This patch (as542) fixes a few loose ends left by Mike's patches. It adds
> a declaration for the new scsi_host_set_state routine, adds an allowed
> transition from the SHOST_RECOVERY state to the SHOST_CANCEL state, and
> avoids returning
James:
This patch (as542) fixes a few loose ends left by Mike's patches. It adds
a declaration for the new scsi_host_set_state routine, adds an allowed
transition from the SHOST_RECOVERY state to the SHOST_CANCEL state, and
avoids returning an uninitialized value in __scsi_add_device.
Alan St
30 matches
Mail list logo
