After conversing with Mike some more, there is a deadlock problem. I need
to hold the host_lock to walk the device list, but I can't hold the
host_lock when I call scsi_set_device_offline().
Mike's looking into this. Until he finds a good answer, no patch for
usb-storage.
Matt
On Thu, Feb 27,
This was discussed, but I didn't recall a firm decision.
I'll keep my eyes open for the patch that uses release().
Matt
On Wed, Feb 26, 2003 at 10:37:37PM -0800, Mike Anderson wrote:
> Matthew Dharm [EMAIL PROTECTED] wrote:
> > Right... but I removed the release() function because that was marke
Matthew Dharm [EMAIL PROTECTED] wrote:
> Right... but I removed the release() function because that was marked (in
> the documentation) as only for the old-style drivers. So I'll need to
> re-introduce it -- but it looks like all it has to do is free some memory.
> Does that sound about right?
Ye
On Wed, Feb 26, 2003 at 03:37:02PM -0800, Mike Anderson wrote:
> There still are a few things on the to do list, but should not effect the
> LLDD interface (at least this is the goal).
> - scsi_request_fn needs a fix for device offline that will
> handle all request types.
> - s
Matthew,
Sorry for the delay in replying (non coding activities are
consuming to many hours).
Matthew Dharm [EMAIL PROTECTED] wrote:
> Okay, I see Linus has now accepted this into his tree. It should propagate
> to the USB development trees soon.
>
> One question: What else is ne
Okay, I see Linus has now accepted this into his tree. It should propagate
to the USB development trees soon.
One question: What else is needed? We set the device offline,
error/complete all pending commands, and the need to (somehow) make certain
we're in a good state for calling scsi_remove_ho
On Mon, Feb 17, 2003 at 11:37:37AM -0800, Mike Anderson wrote:
>
> The scsi_set_device_offline interface is part of the last patch (scsi
> error) I sent to linux-scsi. I updated my patch post some comments from
> the list, but I am working on issue with the patch before I resend.
>
> -andmike
> -
Matthew Dharm [[EMAIL PROTECTED]] wrote:
> Any updates on this? I saw some patches, but they don't seem to be in my
> tree (the usb tree, which is synced from Linus' tree).
>
> People are starting to reports OOPSes to me because of this being
> missing
>
> Matt
>
The scsi_set_device_offlin
Any updates on this? I saw some patches, but they don't seem to be in my
tree (the usb tree, which is synced from Linus' tree).
People are starting to reports OOPSes to me because of this being
missing
Matt
On Mon, Feb 03, 2003 at 09:17:26AM -0800, Mike Anderson wrote:
> Sorry Matthew I got
Sorry Matthew I got side tracked on some issues for the last week. The
scsi_set_device_offline(); function has not been added to any of James
linux-scsi trees. You could add a ifndef in your code until we get the
interface in the tree.
Would scsi_set_device_offline() do more than sdev->online = 0
Willem Riede <[EMAIL PROTECTED]> suggested to me that I simply set
sdev->online = 0 for scsi_set_device_offline()
Any reason that isn't good enough?
On Sun, Feb 02, 2003 at 10:13:17AM -0800, Matthew Dharm wrote:
> So, was any of this ever implemented? As far as I can tell, the required
> changes
So, was any of this ever implemented? As far as I can tell, the required
changes were:
(o) addition of scsi_schedule_host_removal() (possibly optional)
(o) implementation of scsi_set_device_offline() (possibly optional)
(o) change the behavior of the 'hotplug initialization model' to call my
rele
So, I was trying to implement this bit of logic in usb-storage, when I
discovered that scsi_set_device_offline() doesn't exist.
Okay, what did I miss? I'm sure it's obvious, but for the life of me I
don't see it.
Matt
On Fri, Jan 24, 2003 at 07:05:29PM -0500, Doug Ledford wrote:
> > (i) Doesn't
Luben Tuikov [[EMAIL PROTECTED]] wrote:
> Mike Anderson wrote:
> >Doug,
> > I started writing the interface you put forth in your email.
>
> Do you mind clarifying? Either it was a private email, or
> one posted here, in which case there was an interpretation.
It was posted here at the botto
Matthew Dharm wrote:
So, if I read this correctly, you're saying that the correct sequence is:
(1) get disconnect notification from USB
(2) Call scsi_set_device_offline() (must hold host lock for this)
(3) call scsi_done() for all command in queue (max: 1)
Right. LLDD does (2) and (3), though,
Ah... the sweet feeling of progress.
On Fri, Jan 24, 2003 at 07:05:29PM -0500, Doug Ledford wrote:
> On Fri, Jan 24, 2003 at 03:25:40PM -0800, Matthew Dharm wrote:
> > So, if I read this correctly, you're saying that the correct sequence is:
> >
> > (1) get disconnect notification from USB
> > (2
Mike Anderson wrote:
Doug,
I started writing the interface you put forth in your email.
Do you mind clarifying? Either it was a private email, or
one posted here, in which case there was an interpretation.
--
Luben
---
This SF.NET email
So, if I read this correctly, you're saying that the correct sequence is:
(1) get disconnect notification from USB
(2) Call scsi_set_device_offline() (must hold host lock for this)
(3) call scsi_done() for all command in queue (max: 1)
(4) Call scsi_remove_host(), which should now work because no
Alan Stern [[EMAIL PROTECTED]] wrote:
> On Fri, 24 Jan 2003, Luben Tuikov wrote:
>
> > >>A LLDD should and must *not* call scsi_unregister_host(). This brakes
> > >>all hierarchy.
> > >
> >
> > What I probably meant is the detect()/release() pair; release() itself
> > normally calls scsi_unregi
Doug,
I started writing the interface you put forth in your email. I
am currently debugging it in UML so I can generate the error
conditions in a control manner. I still have some stuff to look
at in the error handler with it running in this mode as it
previo
On Fri, 24 Jan 2003, Luben Tuikov wrote:
> Alan Stern wrote:
> >
> > Matt's current proposed patch has the USB LLDD calling
> > scsi_unregister_host() (because the device is respresented as an emulated
>
> A LLDD should and must *not* call scsi_unregister_host(). This brakes
> all hierarchy.
W
Alan Stern wrote:
Apparently it can't. I don't mean to say that this was the right thing to
do; I just meant that this is what Matt's currently-proposed patch does.
Personally, I'm not very familiar with the details of the SCSI subsystem,
and I don't know what preconditions are required for
On Fri, 24 Jan 2003, Luben Tuikov wrote:
> >>A LLDD should and must *not* call scsi_unregister_host(). This brakes
> >>all hierarchy.
> >
>
> What I probably meant is the detect()/release() pair; release() itself
> normally calls scsi_unregister(host); the point is that it got nudged
> from ``a
Alan Stern wrote:
Are you aware that you are contradicting yourself?
On Fri, 24 Jan 2003, Luben Tuikov wrote:
A LLDD should and must *not* call scsi_unregister_host(). This brakes
all hierarchy.
What I probably meant is the detect()/release() pair; release() itself
normally calls scsi_unr
Are you aware that you are contradicting yourself?
On Fri, 24 Jan 2003, Luben Tuikov wrote:
> A LLDD should and must *not* call scsi_unregister_host(). This brakes
> all hierarchy.
On Fri, 24 Jan 2003, Luben Tuikov wrote:
> Oh, I forgot to mention in my previous by date letter:
> The entity wh
Matthew Dharm wrote:
It would be nice if the SCSI mid-layer kept track of what commands were in
what stages in who's queues.
My mini-scsi-core does exactly that. Moving commands between queues is atomic.
The whole thing is completely reentrant and multithreaded capable, etc, etc.
It has a simp
Alan Stern wrote:
>
Matt's current proposed patch has the USB LLDD calling
scsi_unregister_host() (because the device is respresented as an emulated
A LLDD should and must *not* call scsi_unregister_host(). This brakes
all hierarchy.
Let's not make a distinction between a USB LLDD and any LLD
> Matt's current proposed patch has the USB LLDD calling
> scsi_unregister_host() (because the device is respresented as an emulated
> host adapter) when it learns that the device is gone. Provided that
> routine doesn't block for very long, provided it handles all the details
> of hotplug notif
On Thu, 23 Jan 2003, Matthew Dharm wrote:
> What I want:
>
> I want to be able to free resources associated with a device within a
> finite (and well bounded) amount of time after I am notified that the
> device is gone.
>
> I want to be able to inform the SCSI mid-layer, which will then inform
Doug Ledford wrote:
Once all the commands are gone and no more are arriving, then if, and only
if, someone actually removes the device from the scsi subsystem (maybe
hotplug manager or something) then you will get the typical
slave_destroy() call to tell you that it is safe to release all reso
On Thu, Jan 23, 2003 at 03:28:36PM -0500, Doug Ledford wrote:
> On Thu, Jan 23, 2003 at 08:40:41PM +0100, Oliver Neukum wrote:
>
> No, scsi_set_device_offline() schedules the error handler thread for that
> host to be woken up.
>
Doug -
Why would the error handler need to run?
If the LLDD fai
Well, I've been watching this go on for days. I hate to weigh in now, but
I think someone needs to understand what the guy writing the code that is
facing this problem really wants.
First, let me say that a USB storage device shows up as a HBA. That's
because some devices are actually USB/SCSI b
> No. You might be in a kernel thread context when you decode an interrupt
> down to determining that a device was removed, but somewhere along the
> line you took an interrupt that told you the device was removed (or else
> the command simply timed out and you are in the error handler for the
>
Hi Doug
> Actually, I would have both complicated and simple transports call
> scsi_set_device_offline() and for two reasons. 1) you have to provide
> that function for simple drivers so duplicating other detection code in
> the scsi completion handler is a waste. 2) pretty much all transports
>
Am Donnerstag, 23. Januar 2003 20:07 schrieb Luben Tuikov:
> Oliver Neukum wrote:
> > Very well, so you agree that the SCSI layer should export to the LLDD
> > a function to set devices offline?
>
> I've never really disagreed -- simpler transports will make use
> of such a function. The important
Oliver Neukum wrote:
Very well, so you agree that the SCSI layer should export to the LLDD
a function to set devices offline?
I've never really disagreed -- simpler transports will make use
of such a function. The important point to note is that the error
return value for simpler and more comp
Am Donnerstag, 23. Januar 2003 18:46 schrieb Luben Tuikov:
> Oliver Neukum wrote:
> > Not all the world is a SAN. USB has no possibility to even try an
> > interaction after the device is gone. We have to handle this flexibly.
>
> Thus the example in the original post. I.e. for simple transports w
Oliver Neukum wrote:
Not all the world is a SAN. USB has no possibility to even try an interaction
after the device is gone. We have to handle this flexibly.
Thus the example in the original post. I.e. for simple transports whose
portals get notified when a device is plugged off (USB), the LLD
> > Whose responsibility is it to fail these interactions?
>
> The transport.
>
> When a device is plugged to the SAN/fabric (wlg) it may not be the case
> that all initiators will know about it. For this reason the transport
> itself, not SCSI Core, not LLDD*, will decide if the CDB is deliverab
Luben Tuikov wrote:
When the Low Level Device Driver (LLDD), being the transport portal,
notices that the device is going away or has gone away from the
``fabric'' (wlg), it will fire a device-gone event with the kernel.
*Not* necessarily with SCSI Core, in fact I'd rather it didn't,
but with a w
Alan Stern wrote:
Here's another question to add to your discussion.
When a device is unplugged, the system's representation of that device
can't be removed immediately; there may be open fd's, mounts, pointers,
and so on. Until the time comes when all these handles are released, all
interaction
Here's another question to add to your discussion.
When a device is unplugged, the system's representation of that device
can't be removed immediately; there may be open fd's, mounts, pointers,
and so on. Until the time comes when all these handles are released, all
interaction with the device ha
Oliver Neukum wrote:
Am Dienstag, 21. Januar 2003 19:16 schrieb Luben Tuikov:
When the Low Level Device Driver (LLDD), being the transport portal,
notices that the device is going away or has gone away from the
``fabric'' (wlg), it will fire a device-gone event with the kernel.
*Not* necessaril
Am Dienstag, 21. Januar 2003 19:16 schrieb Luben Tuikov:
> Oliver Neukum wrote:
> > Disconnect is not really a callback. There's a distinct lack of a back
> > movement here. khubd -> usbcore -> disconnect() in driver -> [layer on
> > top]
> >
> > The proposed API in SCSI looks like:
> > -> LLD ->
Oliver Neukum wrote:
>
So a disconnection would look like this:
1.
scsi_set_offline_host(...);
2.
synchronize_kernel();
3.
error_queied_commands(...);
4.
scsi_remove_host();
Not quite. You want to do 3 before 2, to get 2 going as soon
as possible. Futhermore, 3 is partly in LLDD. 1 w
Oliver Neukum wrote:
Disconnect is not really a callback. There's a distinct lack of a back movement here.
khubd -> usbcore -> disconnect() in driver -> [layer on top]
The proposed API in SCSI looks like:
-> LLD -> midlayer -> top layer -> midlayer -> LLD with destroy_slave()
and that's not OK.
Am Dienstag, 21. Januar 2003 12:57 schrieb Douglas Gilbert:
> Oliver Neukum wrote:
> >
> >
> > I simply don't trust the SCSI layer. I've had to much trouble with it
> > already.
>
> Hopefully we have some better building blocks and
> clearer code in 2.5 to look at this problem in the SCSI
> subsy
[EMAIL PROTECTED] said:
> Providing you refcount objects and defer freeing of resources its not
> normally too terrible
We already have a struct device, which is a ref counted object precisely for
this purpose, embedded inside Scsi_Device.
One of the issues doing this is fast reattachment: the
Oliver Neukum wrote:
>
>
I simply don't trust the SCSI layer. I've had to much trouble with it
already.
Hopefully we have some better building blocks and
clearer code in 2.5 to look at this problem in the SCSI
subsystem again.
The first thing a LLDD should do when it _knows_ the device
is gone
> That model cannot be applied to SCSI as it is much more diverse
> in the number of bus types it supports.
> USB can do it, because it knows about hubs. SCSI cannot,
> as there are no hubs in SCSI.
Not entirely true - there are devices known as bridges that bridge parallel SCSI to
parallel SCSI
Am Dienstag, 21. Januar 2003 04:31 schrieb Alan:
> On Mon, 2003-01-20 at 18:23, Oliver Neukum wrote:
> > > The transport can notify that the device is gone, but an ULP entity
> > > will call scsi_remove_device() not the other way around.
> >
> > NO!
> >
> > This is an insanely complicated scheme.
>
On Mon, 2003-01-20 at 18:23, Oliver Neukum wrote:
> > The transport can notify that the device is gone, but an ULP entity will
> > call scsi_remove_device() not the other way around.
>
> NO!
>
> This is an insanely complicated scheme.
> We have no notification beforehand. User yanks out cable.
>
Am Dienstag, 21. Januar 2003 01:44 schrieb David Brownell:
> Oliver Neukum wrote:
> >>So you were talking past what I said about notifying that highest level,
> >>not disagreeing with it.
> >
> > I was trying to make the point that callbacks have no place in that
> > process.
>
> If so, you didn't
Oliver Neukum wrote:
So you were talking past what I said about notifying that highest level,
not disagreeing with it.
I was trying to make the point that callbacks have no place in that process.
If so, you didn't persuade me ...
It must go bottom to top and that's it.
... because those
> > By transport I mean USB, FC, SPI, etc; LLDD is the transport portal
> > and the initiator (aka the initiator port). This terminology is not
> > really that new, but still not that old, and described in SAM-3.
>
> I was hoping for something described in the 2.5.58 kernel docs,
> which only tal
> So the SCSI stack needs to support more than one model for
> device/bus detection. This can't be news. And some of them
> have to handle "conventional" busses, like USB and PCI; maybe
> even handle booting off them...
Until very recently it was news. And they still haven't fully
comprehended
Luben Tuikov wrote:
David, when I said ``... the transport will tell the LLDD that the
device ...'' this is *exactly* what I meant. You're just repeating
it here in a more broken-down way.
OK
By transport I mean USB, FC, SPI, etc; LLDD is the transport portal
and the initiator (aka the init
Oliver Neukum wrote:
I should be more specific.
Yes...
The SCSI is different for several reasons:
- we are talking about bus as well as device detection
- there's no common way to probe for devices
(the probing of LUNs works only on conventional busses)
So the SCSI stack needs to support
David Brownell wrote:
Luben Tuikov wrote:
The way this should work is that the LLD calls scsi_remove_device(), and
that cuts off the flow of commands. The LLD can promise to error-out
any
pending commands in the device command queue.
I take it you mean that the transport will tell the LLDD
Am Montag, 20. Januar 2003 22:24 schrieb David Brownell:
> Oliver Neukum wrote:
> > That model cannot be applied to SCSI as it is much more diverse
> > in the number of bus types it supports.
> > USB can do it, because it knows about hubs. SCSI cannot,
> > as there are no hubs in SCSI.
>
> Hubs are
Oliver Neukum wrote:
That model cannot be applied to SCSI as it is much more diverse
in the number of bus types it supports.
USB can do it, because it knows about hubs. SCSI cannot,
as there are no hubs in SCSI.
Hubs are irrelevant here, the key functionality is noticing
hardware addition/disco
Am Montag, 20. Januar 2003 21:08 schrieb David Brownell:
> Luben Tuikov wrote:
> >> The way this should work is that the LLD calls scsi_remove_device(), and
> >> that cuts off the flow of commands. The LLD can promise to error-out
> >> any pending commands in the device command queue.
> >
> > I ta
Luben Tuikov wrote:
The way this should work is that the LLD calls scsi_remove_device(), and
that cuts off the flow of commands. The LLD can promise to error-out any
pending commands in the device command queue.
I take it you mean that the transport will tell the LLDD that the device
is gone
Luben Tuikov wrote:
But a removal of a device would probably have to start in top-down
approach, to free/release/etc resources/etc, rather than a bottom-up
approach (I just cannot see how this would work...)
Well, the driver model core covers key parts of that. Or it was
at least intended to .
> > We as the writers of device drivers need a way to get rid of the device
> > as we are notified of the physical disconnect.
>
> Yes, and as I explained earlier: you *may* get notified by the transport.
That exactly is the point. There must be no maybe. Gone is gone.
Failure is not an option he
Oliver Neukum wrote:
I take it you mean that the transport will tell the LLDD that the device
is gone and it (LLDD) call the one above, SCSI Core to remove the device.
Hmm, more thinking needs to be done here, as shouldn't this be handled
by hotplugging? I.e. Targets do not *initiate* events.
Th
> I take it you mean that the transport will tell the LLDD that the device
> is gone and it (LLDD) call the one above, SCSI Core to remove the device.
>
> Hmm, more thinking needs to be done here, as shouldn't this be handled
> by hotplugging? I.e. Targets do not *initiate* events.
>
> The transpo
Matthew Dharm wrote:
In a separate discussion with Mike, he mentioned that you can't
scsi_remove_device() unless there are no pending commands.
How the hell is an LLD supposed to assure that!?!?
ABORT TASK/ABORT TASK SET.
For a year now I've been trying to get something of the sort
scsi_cancel
> > The way this should work is that the LLD calls scsi_remove_device(), and
> > that cuts off the flow of commands. The LLD can promise to error-out any
> > pending commands in the device command queue.
> >
> > That is, unless scsi_block_requests() and scsi_unblock_requests() are
> > more useful
Oliver Neukum [[EMAIL PROTECTED]] wrote:
>
> > In a separate discussion with Mike, he mentioned that you can't
> > scsi_remove_device() unless there are no pending commands.
> >
> > How the hell is an LLD supposed to assure that!?!?
> >
> > The minute I error a command and call scsi_done(), I can
> In a separate discussion with Mike, he mentioned that you can't
> scsi_remove_device() unless there are no pending commands.
>
> How the hell is an LLD supposed to assure that!?!?
>
> The minute I error a command and call scsi_done(), I can get a new one.
> Unless I lock out requests with scsi_b
Oliver and Alan I am trying to catch up on this thread so I did not
reply directly to your concerns, but I think they are covered below.
Matthew Dharm [[EMAIL PROTECTED]] wrote:
> On Fri, Jan 17, 2003 at 11:55:36AM +0100, Oliver Neukum wrote:
> > That is simply wrong. Reporting somebody having pul
On Fri, Jan 17, 2003 at 11:55:36AM +0100, Oliver Neukum wrote:
> That is simply wrong. Reporting somebody having pulled a plug must
> not fail. What are you supposed to do with an error here?
>
> There must be a way for a LLD to report that reliably.
> If the answer is, take that lock, call that f
On Fri, 17 Jan 2003, Oliver Neukum wrote:
> Am Freitag, 17. Januar 2003 09:50 schrieb Mike Anderson:
> >
> > If the device disappears the host needs to return all IOs in flight with
> > an error, and we need to ensure new ones do not start ( setting the
> > device offline and maybe host_self_bloc
Am Freitag, 17. Januar 2003 09:50 schrieb Mike Anderson:
> Oliver Neukum [[EMAIL PROTECTED]] wrote:
> > Am Donnerstag, 16. Januar 2003 21:48 schrieb Mike Anderson:
> > > David Brownell [[EMAIL PROTECTED]] wrote:
> > > > Have any of the SCSI people been looking much at SCSI hotplug on 2.5?
> > > > I
Oliver Neukum [[EMAIL PROTECTED]] wrote:
> Am Donnerstag, 16. Januar 2003 21:48 schrieb Mike Anderson:
> > David Brownell [[EMAIL PROTECTED]] wrote:
> > > Have any of the SCSI people been looking much at SCSI hotplug on 2.5?
> > > I attach "/etc/hotplug/scsi.agent" from one of my desktops; all it
>
Am Donnerstag, 16. Januar 2003 21:48 schrieb Mike Anderson:
> David Brownell [[EMAIL PROTECTED]] wrote:
> > Have any of the SCSI people been looking much at SCSI hotplug on 2.5?
> > I attach "/etc/hotplug/scsi.agent" from one of my desktops; all it
> > does is make sure the right drivers are loaded
Copied to linux-usb-devel, as they should also see this...
On Thu, 16 Jan 2003 12:10:18 -0800, Linus Torvalds wrote:
> In article <[EMAIL PROTECTED]>, Greg KH <[EMAIL PROTECTED]>
> wrote:
>>On Thu, Jan 16, 2003 at 11:43:23AM -0800, Matthew Dharm wrote:
>>> Well, we only create the host when the
David Brownell [[EMAIL PROTECTED]] wrote:
> Have any of the SCSI people been looking much at SCSI hotplug on 2.5?
> I attach "/etc/hotplug/scsi.agent" from one of my desktops; all it
> does is make sure the right drivers are loaded, it doesn't have a
> clue yet about whether/how/where to mount disk
Greg KH wrote:
On Thu, Jan 16, 2003 at 11:43:23AM -0800, Matthew Dharm wrote:
Well, we only create the host when the device is first attached. After
that, if it goes away and comes back, we re-connect it to the old SCSI
host.
Ick, so when the device is gone, where does the SCSI host go? Is
On Thu, Jan 16, 2003 at 11:43:23AM -0800, Matthew Dharm wrote:
> Well, we only create the host when the device is first attached. After
> that, if it goes away and comes back, we re-connect it to the old SCSI
> host.
Ick, so when the device is gone, where does the SCSI host go? Is it
still repre
Well, we only create the host when the device is first attached. After
that, if it goes away and comes back, we re-connect it to the old SCSI
host.
But, while the device is gone, you've created an association between a SCSI
node that exists and a non-existant USB device. Basically, you've got a
On Thu, Jan 16, 2003 at 09:31:12AM -0800, Matthew Dharm wrote:
> Hrm... doesn't this all fall to pot when the device is unplugged and
> repluged?
Um, how? This seems to work for me, but I don't have a lot of devices
here. And if there is a problem, you might want to tell the scsi
people, as they
Hrm... doesn't this all fall to pot when the device is unplugged and
repluged?
Matt
On Wed, Jan 15, 2003 at 03:27:00PM -0800, Greg KH wrote:
> ChangeSet 1.879.76.2, 2003/01/13 17:31:46-08:00, [EMAIL PROTECTED]
>
> [PATCH] USB: put the usb storage's SCSI device in the proper place in sysfs.
>
>
84 matches
Mail list logo
