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 marked
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.
-
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
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?
Yes
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
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_offline
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
--
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 =
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
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, 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
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
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
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
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
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
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 which
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.
What then
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
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_unregister(host); the
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
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
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) Call
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),
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 bottom of
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
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 whose
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
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 fails
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
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
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 deliverable.
*
Oliver Neukum wrote:
snip/
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
[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
Am Dienstag, 21. Januar 2003 12:57 schrieb Douglas Gilbert:
Oliver Neukum wrote:
snip/
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
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
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:
bus system - LLD -
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*
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
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 transport can
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.
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 here.
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
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
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 take it you
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
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
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
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
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 the
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 talks about
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
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 persuade me
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.
That's
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 and
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.
We have no
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_blocked).
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
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
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
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.
Also
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
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
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
ChangeSet 1.942, 2003/01/15 14:50:56-08:00, [EMAIL PROTECTED]
USB: added .owner for USB drivers that have a struct tty_driver
diff -Nru a/drivers/usb/class/bluetty.c b/drivers/usb/class/bluetty.c
--- a/drivers/usb/class/bluetty.c Wed Jan 15 14:57:45 2003
+++ b/drivers/usb/class/bluetty.c
ChangeSet 1.879.84.6, 2003/01/15 13:23:22-08:00, [EMAIL PROTECTED]
[PATCH] USB: make more speedtouch functions static
speedtouch: make more functions static.
diff -Nru a/drivers/usb/misc/speedtouch.c b/drivers/usb/misc/speedtouch.c
--- a/drivers/usb/misc/speedtouch.c Wed Jan 15 14:58:21
ChangeSet 1.879.84.7, 2003/01/15 13:23:54-08:00, [EMAIL PROTECTED]
[PATCH] USB: SpeedTouch not Speed Touch
speedtouch: use SpeedTouch everywhere (was sometimes Speed Touch).
diff -Nru a/drivers/usb/misc/speedtouch.c b/drivers/usb/misc/speedtouch.c
--- a/drivers/usb/misc/speedtouch.c Wed
ChangeSet 1.879.84.4, 2003/01/15 13:22:21-08:00, [EMAIL PROTECTED]
[PATCH] maintain hcd_dev queue in FIFO order
Current uses of the urb_list have all been to make
sure we have some list of pending urbs, so we can
clean them all up after HCs die, and avoid trying
to unlink something that's not
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.
Also makes usb_ifnum_to_if() a public function
diff -Nru a/drivers/usb/core/hcd.h b/drivers/usb/core/hcd.h
--- a/drivers/usb/core/hcd.hWed Jan 15
ChangeSet 1.879.84.3, 2003/01/15 12:48:26-08:00, [EMAIL PROTECTED]
[PATCH] Change maintainership of USB scanner driver
diff -Nru a/MAINTAINERS b/MAINTAINERS
--- a/MAINTAINERS Wed Jan 15 14:59:16 2003
+++ b/MAINTAINERS Wed Jan 15 14:59:16 2003
@@ -1901,11 +1901,11 @@
S:
ChangeSet 1.879.84.2, 2003/01/14 17:49:55-08:00, [EMAIL PROTECTED]
[PATCH] USB: add dev attribute for usb-serial devices in sysfs
diff -Nru a/drivers/usb/serial/bus.c b/drivers/usb/serial/bus.c
--- a/drivers/usb/serial/bus.c Wed Jan 15 14:59:34 2003
+++ b/drivers/usb/serial/bus.c Wed Jan 15
73 matches
Mail list logo
