Matthew Jacob wrote:
I want:
LLDD to SCSI: device is gone
SCSI to LLDD: Ok. I'll handle from here on.
LLDD: OK. I am gone. And won't have any contact until the next device is
plugged in.
...
Could this time limit be fixed (or parameterized) known to all LLDDs?
This would allow one to try and a
I'm working on getting the USB subsystem running
directly inside of UML. By doing this you can use
gdb/ddd on all of the USB driver code. You can also
run 2.5.xxx on a 2.4 host system. My UML is using
spare USB hardware in the host.
When I exit UML I need to be sure that the USB
hardware is gettin
On Thu, Jan 23, 2003 at 05:54:57PM -0700, Steven Dake wrote:
> >I want:
> >LLDD to SCSI: device is gone
> >SCSI to LLDD: Ok. I'll handle from here on.
> >LLDD: OK. I am gone. And won't have any contact until the next device is
> >plugged in.
> >
> >
> The downside of this approach is that the LLD
I want:
LLDD to SCSI: device is gone
SCSI to LLDD: Ok. I'll handle from here on.
LLDD: OK. I am gone. And won't have any contact until the next device is
plugged in.
The downside of this approach is that the LLDD must now be able to
detect insertions and removals when it may not be able to d
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
> I want:
> LLDD to SCSI: device is gone
> SCSI to LLDD: Ok. I'll handle from here on.
> LLDD: OK. I am gone. And won't have any contact until the next device is
> plugged in.
>
> The process can be somewhat more complicated, under some conditions:
> - it never fails
> - it is done within a finite,
Am Donnerstag, 23. Januar 2003 21:41 schrieb Steven Dake:
> Oliver and others,
>
> In regards to hotswap, any real operating system should be _told_ that a
> block device is going to be removed from the top. There are several
> reasons.
Users don't do what they should. It is as simple as that.
Th
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
>
Dear guys, I see that usb_unlink_urb may fail, and not just for
trivial reasons (trivial = urb was NULL, etc). What should one
do if it fails?
Thanks for your help,
Duncan.
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition
On Wed, 22 Jan 2003, Oliver Neukum wrote:
> Am Mittwoch, 22. Januar 2003 22:32 schrieb Alan Stern:
> > Here is my patch to implement proper timing of synchronous unlinks.
> > Basically it just uses a spinlock to cause unlink requests during a
> > completion handler to wait until the handler has re
Oh, well. I've pulled my camera in the middle of reads and just got the
usual whininess.
I think I was reacting to your "get what they deserve" comment. The end
goal of USB should probably *be* an alert that said "oh, dear, that
wasn't helpful- please put that memory stick back so I can finish
wr
I cant speak about OS/X, but I have crashed windows several times (BSOD)
while hot removing a USB SCSI CDROM. As you will notice, when you run
windows and attach a device, there is a program that is started that
allows you to notify the os of the removal so that it may properly
remove the devi
>
> The key is that the removal request should come from the top, not the
> bottom. If someone is stupid enough to surprise remove a device (ie:
> unplug their USB SCSI device while the device is in use by the OS), they
> get what they deserve (I/O errors, dirty OS data, queued up requests
> which
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
>
Oliver and others,
In regards to hotswap, any real operating system should be _told_ that a
block device is going to be removed from the top. There are several
reasons.
1) File mounts should be removed from the filesystem layer
2) files accessing block devices directly should be terminated
3)
speedtouch: recycle the receive urb's buffer. Currently, every time a receive urb
completes, its old buffer is thrown away and replaced with a new one. This patch
performs the minor changes needed to reuse the old buffer. We need a copy of the
sk_buff on the stack because atmsar_decode_r
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
Well, it's stored in my local tree as a large series of deltas. But I'd
settle for just being able to boot the kernel with debugging enabled and
try it myself.
The problem is, it doesn't make any sense if split up into smaller pieces.
The change from old hotplug system to new hotplug system reall
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
Am Donnerstag, 23. Januar 2003 17:59 schrieb David Brownell:
> Oliver Neukum wrote:
> > Am Donnerstag, 23. Januar 2003 07:12 schrieb David Brownell:
> >>Oliver Neukum wrote:
> >>>Like this version better?
> >>
> >>No, it still has that "arbitrary timeout" pessimization. The only
> >>difference is
The support for non-dma HCDs is likely the most interesting bit here.
- makes dma calls behave sensibly when used with host controllers
that don't use dma (including sl811). usb_buffer_map() is a nop
while scatterlist dma mappings fail (as they must).
- make usb_sg_init() behave
Oliver Neukum wrote:
Am Donnerstag, 23. Januar 2003 07:12 schrieb David Brownell:
Oliver Neukum wrote:
Like this version better?
No, it still has that "arbitrary timeout" pessimization. The only
difference is a bigger timeout.
An infinite loop is never
acceptable.
That's because the
Turlarŭmŭz:
SAFRANBOLU-ABANT 8-12 ŜUBAT VE 12-16 ŜUBAT 59.975.000 TL x 4 TAKSŬT
KAPADOKYA 9-13 ŜUBAT VE 12-16 ŜUBAT 47.450.000 TL x 4 TAKSŬT
KAPADOKYA 7-10 ŜUBAT 38.725.000 TL X 4 TAKSŬT
ANTALYA 11-16 ŜUBAT 64.975.000 TL x 4 TAKSŬT
ASSOS-KAZDAÐLARI-AYVALIK-ÇANAKKALE 9-13 ŜUBAT VE 12-16 ŜUBAT 59.97
Hi Tom,
Here is a patch to lsusb.c (usbutils-0.11) to include the
language ID in a get string request, rather than using zero.
Hope this helps,
jim.
> <>
--- usbutils-0.11-backup/lsusb.cTue Aug 6 15:35:21 2002
+++ usbutils-0.11-new/lsusb.c Thu Jan 23 15:06:49 2003
@@ -134,7 +134,7
speedtouch: move all processing of receive urbs to udsl_atm_processqueue. This has
several advantages, as will be seen in the next few patches. The most important is
that it makes it easy to reuse of the urb's buffer (right now a new buffer is
allocated every time the urb completes). By
Am Donnerstag, 23. Januar 2003 01:53 schrieb Rom M:
> I think I have already made the virtual root hub connect to the usbcore,
> but after that,when I attach a device,I don't know what function(interrupt
> handler?) is triggered. I've look at ohci_irq, but there is no case there
> where it checks f
Am Donnerstag, 23. Januar 2003 07:12 schrieb David Brownell:
> Oliver Neukum wrote:
> > Like this version better?
>
> No, it still has that "arbitrary timeout" pessimization. The only
> difference is a bigger timeout.
>
> > If progress in the typical case is clearly forward, the call will very
> >
30 matches
Mail list logo
