small
changes, so it shouldn't be hard to see what is going on. Besides, only 3
hunks failed; you could just type in the appropriate changes by hand.
Almost all of the changes just involve replacing -ENOENT with
-ECONNRESET -- although your third failure involves replacing it with
-ENODEV.
Alan
(), and completion handlers. What do
you think is the right thing to do here?
(Incidentally, usb-skeleton.c is a good example of a driver where the
disconnect() routine can exit with urbs still in flight.)
Alan Stern
---
This SF.net email
drivers. This entry point should be called by the
core whenever a device bound to the driver is reset. The driver can then
decide what to do: maybe re-initialize the device, maybe do nothing.
Alan Stern
---
This SF.net email is sponsored
the one use -- take your choice.
Alan Stern
= usb-2.5/include/linux/usb.h 1.128 vs edited =
--- 1.128/include/linux/usb.h Tue Feb 18 19:18:58 2003
+++ edited/usb-2.5/include/linux/usb.h Mon Feb 24 10:19:25 2003
@@ -960,8 +960,8 @@
#define usb_rcvbulkpipe(dev,endpoint) ((PIPE_BULK 30
been replaced with symbolic constants.
New comments discuss the merits of different I/O styles and the
requirements for a driver's disconnect() routine.
Alan Stern
= usb-skeleton.c 1.36 vs edited =
--- 1.36/drivers/usb/usb-skeleton.c Tue Jan 14 12:00:34 2003
if that bug was the source of Oliver's problem, but it is certainly
possible. Here is a patch to fix the bug.
Alan Stern
--- usb-2.4/drivers/usb/storage/transport.c.origWed Feb 26 09:54:43 2003
+++ usb-2.4/drivers/usb/storage/transport.c Wed Feb 26 09:55:23 2003
@@ -1054,7 +1054,7
On Tue, 25 Feb 2003, David Brownell wrote:
Alan Stern wrote:
Heck, I've barely had a chance to write it, let alone test it. In fact,
it seemed clear that nobody had tried any testing recently. One of the
minor bugs I fixed was a subroutine call that passed a structure rather
than
On Wed, 26 Feb 2003, Alan Stern wrote:
As it turns out, this still generates a compiler warning. There's a
mistake in the min() and max() macros in include/linux/kernel.h. I will
post something about that on the linux kernel mailing list.
I spoke too soon (don't you just hate it when
On Wed, 26 Feb 2003, David Brownell wrote:
Alan Stern wrote:
That sounds like you're saying the macros don't belong in usb.h at all.
Shall I send in a patch that takes them out?
I think that'd be a good solution. Or maybe just put them in hcd.h.
Here you go.
Alan Stern
= include
as soon as reasonably possible.
Mea culpa,
Alan Stern
--- usb-2.5/drivers/usb/core/hcd.h.orig Sat Mar 1 12:27:21 2003
+++ usb-2.5/drivers/usb/core/hcd.h Sat Mar 1 12:30:42 2003
@@ -255,8 +255,8 @@
extern int usb_set_address(struct usb_device *dev);
/* use these only before the device's
with the erroneous routine but does work after the patch has been
applied.
Alan Stern
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
[EMAIL PROTECTED
, etc.).
I think it's probably okay to apply this patch. More testing would be
good, but I don't have any suitable hardware. And I think a
software-loopback sort of test wouldn't address many of my changes very
well.
Alan Stern
= drivers/usb/usb-skeleton.c 1.36 vs edited =
--- 1.36
to work on any reasonable Pentium II and up. You might want to turn
off SMP and PM support. You might even want to turn off USB debugging.
Alan Stern
#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_SWAP=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
#
# Code
On Wed, 5 Mar 2003, David Brownell wrote:
Alan Stern wrote:
Here is a slightly updated patch for usb-skeleton.c. It has been tested
minimally with real hardware, but David Brownell would like to see some
more tests using gadget zero.
I just did, to a 2.5.62ish system running gadget
Greg:
This patch fixes an oversight in usb-storage whereby the command length
and command buffer for an automatically-generated REQUEST-SENSE command
would not be initialized properly.
Please apply both the 2.4 and 2.5 versions.
Alan Stern
-- Forwarded message --
Date: Wed, 5
worthwhile.
Alan Stern
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major
On Thu, 6 Mar 2003, Greg KH wrote:
On Mon, Mar 03, 2003 at 02:14:54PM -0500, Alan Stern wrote:
Here is a slightly updated patch for usb-skeleton.c. It has been tested
minimally with real hardware, but David Brownell would like to see some
more tests using gadget zero.
Um
had said Wow! Your
suggestion is just great -- let's convert all our drivers first thing!
:-) But keep my idea in mind while working on your change.
Alan Stern
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
Greg:
Further testing uncovered a _very_ minor error in usb-skeleton: there
should not be a debugging log message for a successful write.
This goes on top of the previous patch.
Alan Stern
= drivers/usb/usb-skeleton.c 1.37 vs edited =
--- 1.37/drivers/usb/usb-skeleton.c Wed Mar 5
bandwidth
available in each frame. With a straightforward change to let the
allocator understand how this works, it would be possible to schedule more
interrupt transactions than currently.
Is there any point in me pursuing this?
Alan Stern
*/
Shouldn't that be:
*end = (last_urb-start_frame + last_urb-number_of_packets *
last_urb-interval) 1023;
Also, it wouldn't hurt to replace the 1023 with (UHCI_NUMFRAMES - 1).
Alan Stern
On Tue, 11 Mar 2003, David Brownell wrote:
Alan Stern wrote:
I agree about the need for synchronization. The point is that with the
only data structure available to the client being a pointer to an urb,
there _is_ no way to carry out this synchronization. Doing so would
require using
On Wed, 12 Mar 2003, David Brownell wrote:
Alan Stern wrote:
The major purpose of adding the facility to cancel synchronous messages is
to allow drivers to unlink the corresponding urbs during disconnect().
Okay, so let's keep the existing API pretty much as it is, but add
. But either way seems
about equally clean and reliable. Maybe you're just trading off the
possibility of things going haywire in the core against things going
haywire in the driver. Of course, neither will actually happen ;-)
Alan Stern
-storage
have been made since 2.4.18.
Alan Stern
---
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net
Greg:
My update for usb-skeleton seems to have gotten lost in the shuffle, so
here it is again -- all wrapped up in one nice little patch. It's been
tested by three different people and passed with flying colors. Please
apply.
Alan Stern
= usb-skeleton.c 1.37 vs edited =
--- 1.37
?
The problem is that drivers may choose to use the usb_bulk/control_msg()
functions to perform their I/O, and these sleep in TASK_UNINTERRUPTIBLE.
They don't have any support for fielding signals.
Alan Stern
---
This SF.net email
for ep
0 from the driver being unloaded while still allowing submissions from the
other driver? Or is this something that has never yet come up and will be
dealt with when it really matters?
Alan Stern
---
This SF.net email is sponsored
-storage it's true that the synchronous API is used in the
I/O error handling code paths. But those code paths always execute in the
context of a kernel thread -- the SCSI error-handler thread -- with no
semaphores held, so it's perfectly okay for them to use GFP_KERNEL.
Alan Stern
with David's proposal above; just make usb_bulk_msg() and
usb_control_msg() interruptible. But what about synchronous
usb_unlink_urb()?
Alan Stern
---
This SF.net email is sponsored by: Does your code think in ink?
You could win a Tablet PC. Get
On Tue, 18 Mar 2003, Oliver Neukum wrote:
Am Dienstag, 18. März 2003 16:12 schrieb Alan Stern:
On Tue, 18 Mar 2003, Oliver Neukum wrote:
Hi,
some part of the synchronous API is used in the block io error handling
code paths. Therefore it may use only GFP_NOIO, not GFP_KERNEL
mode,
in which the error code happens to be -EINTR. But the drivers should
treat it much like any other error. That is, unless they try to do some
sort of error recovery based on the return code -- then this would have to
fall under the default unknown error case.
Alan Stern
this?
Alan Stern
---
This SF.net email is sponsored by: Does your code think in ink?
You could win a Tablet PC. Get a free Tablet PC hat just for playing.
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
On Tue, 18 Mar 2003, Alan Stern wrote:
On Tue, 18 Mar 2003, Oliver Neukum wrote:
How can that be? The SCSI layer guarantees that no further requests are
issued while the error handler is running.
Yes. The synchronous API calls you are concerned about are made from
it and I'm stuck
until (horror!) I reboot.
Dave:
You didn't say what version of Linux you were running. Try installing
2.4.21-current and see if that makes a difference. A couple of changes
were made to the usb-storage driver fairly recently that might address the
problem you see.
Alan Stern
On Wed, 19 Mar 2003, Dave Turner wrote:
On Wed, 19 Mar 2003 at 10:05am, Alan Stern wrote:
Dave:
You didn't say what version of Linux you were running. Try installing
2.4.21-current and see if that makes a difference. A couple of changes
were made to the usb-storage driver fairly
one. All you have to do is wait for the struct completion
again after the unlink call, with no timeout. Given that this whole
matter revolves around updating the synchronous API interface, it's
probably best not to use one synchronous call within the implementation of
another.
Alan Stern
and be re-probed.
I'm not really recommending this, but at least it would mean any other
drivers bound to that same device wouldn't be forced to avoid ever waiting
on I/O.
Alan Stern
---
This SF.net email is sponsored by: Tablet PC.
Does your
, there are situations where these resets crop up
regularly -- but they are the result of some other incompatibility that a
device reset won't fix anyway.)
In the long term, as Oliver says, we will need to add a driver/core API
primitive to support device resets.
Alan Stern
On Thu, 20 Mar 2003, Matthew Dharm wrote:
On Thu, Mar 20, 2003 at 05:01:46PM -0500, Alan Stern wrote:
After inserting a 1Gb Microdrive into the card reader and attempting to
mount it (following a successful MODE-SENSE):
usb-storage: queuecommand() called
usb-storage: *** thread
On Fri, 21 Mar 2003, Dave Turner wrote:
On Fri, 21 Mar 2003 at 10:45am, Alan Stern wrote:
Dave, please try this patch, see what happens, and send another kernel
log extract. I don't think it will fix everything because it doesn't
address the root of your problem: your Microdrive isn't
there's more than 1 interface.
Alan Stern
---
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin
, thereby leaking
potentially sensitive information. The byte in question should be set to
0 before it is transmitted. Second, if this is a matter of sending a runt
USB packet, why not make it a 0-length packet instead of a 1-byte packet?
Alan Stern
/usb/devices and the /proc/scsi/scsi files!
Try compiling your kernel with usb-storage debugging turned on, and post a
copy of your kernel log with the debugging messages. That will help to
pinpoint where the problem occurs.
Alan Stern
that
command; it's a backport from 2.5. Try installing this and let us know if
it helps.
Alan Stern
--- linux-2.4.21/drivers/scsi/sd.c.orig Mon Mar 31 16:27:31 2003
+++ linux-2.4.21/drivers/scsi/sd.c Mon Mar 31 16:56:20 2003
@@ -731,15 +731,17
if it helps.
Alan Stern
--- linux-2.4.21/drivers/scsi/sd.c.orig Mon Mar 31 16:27:31 2003
+++ linux-2.4.21/drivers/scsi/sd.c Mon Mar 31 16:56:20 2003
@@ -731,15 +731,17 @@
* check_disk_change */
}
- /* Using Start/Stop enables differentiation
logging turned off!). Of course this will generate lots
and lots of logging output but only the last part will be relevant. And
we can hope that timing changes caused by the serial output delays will
not affect whatever it was you saw.
Alan Stern
help there, since
you must already be aware of that.
Alan Stern
---
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated
thought so too, and I don't know of any such problems. Maybe this is a
new one?
Alan Stern
---
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support
On Wed, 2 Apr 2003, David Brownell wrote:
Alan Stern wrote:
What sort of information would it be useful to expose in this way? A few
possibilities that would be easy to implement (stored in the per-device
data structure in usb-storage) are:
1. The current state of the driver
to mind.
In short, we should permit both types of approach with minimal hassle.
Alan Stern
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've
until you trigger the error. Then you would know
that the last URB was the straw that broke the camel's back.
Alan Stern
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed
in the
intermediate hub. Though I can't imagine how.
Alan Stern
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView
: is it possible to
write a workaround in the Linux-USB driver for this problem?
Not without some pretty specific information from the vendor explaining
the source of the problem and how to work around it. Is there any
possibility you could obtain that?
Alan Stern
writing anything to the md5sums output file?
Alan Stern
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6
tried mounting it read-only? Also, can you tell where the mount
process is hung? Try Alt-SysRq-T (and make sure you have enabled the
Magic SysRq key in your kernel).
Nothing else occurs to me, sorry.
Alan Stern
---
This SF.net email
nothing to do
with what other data is stored in the same memory block with the output
buffer. And there's nothing that indicates dma_cache_wback_inv() is less
efficient when ptr isn't aligned on a cacheline.
Alan Stern
---
This SF.net email
kernel: usb_physical_reset_device 1227
Jun 5 20:55:06 ventus kernel: usb-storage: usb_reset_device returns -19
Could you mail to me directly (offlist) your altered hub.c file, so I can
match up the line numbers in the log with the source code?
Alan Stern
is lost by incurring a
cache miss there, because the CPU would have to refill its cache anyway.
Alan Stern
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread
? Is there anything else to
try?
Alan Stern
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free
will be probed again anyway.
Alan Stern
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com
call cannot be interrupted by CTRL-C.
Can you try using your device on a regular PC? Can you try using Linux
2.5.70 to see if that helps? Can you enable OHCI_VERBOSE_DEBUG near the
start of the ohci driver source file in drivers/usb/host?
Alan Stern
message. I didn't mean
usb_reset_config(); I was thinking about drivers that want to change to a
different configuration during their probe(). How do you plan to
accomodate that?
Alan Stern
---
This SF.net email is sponsored by: Etnus
On Fri, 6 Jun 2003, David Brownell wrote:
Alan Stern wrote:
The first restriction is that some architectures (which ones? -- I don't
know) are unable to perform DMA to addresses on the stack. So all I/O
buffers _must_ be allocated using kmalloc() or something similar; they
_cannot_
David:
Did you ever come to any decision about whether to let the root hub
status URB timer continue to run during a PM suspend as opposed to
restarting it during a PM resume? Just curious...
Alan Stern
---
This SF.net email is sponsored
Until my ambitious project gets going, this patch at least fixes the
problem of assigning a device's new address following a device reset.
The only change needed to David's original suggestion was to handle the
pathway involved in registering root hubs.
Alan Stern
= drivers/usb/core/hcd.c
.
Although even that might not help with your device.
Alan Stern
---
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore
this suggestion.
Alan Stern
---
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http
put in a long time delay (schedule_timeout()) at the appropriate point in
sd.c so that the system log entries are visible and can get saved?
Alan Stern
---
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make
On Wed, 28 May 2003, David Brownell wrote:
Alan Stern wrote:
(1) We don't want connect processing
(registering interfaces in the driver model and probing device drivers,
maybe other things too) and/or disconnect processing (detaching drivers
and deregistering interfaces, etc
with usb_stor_scsiSense10to6() and related routines.
Alan Stern
---
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
___
[EMAIL
of 2.5
Would somebody like to update proc_usb_info.txt?
Alan Stern
---
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
.
Parallelization is not needed for performance reasons, only for
reliability.
Alan Stern
---
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
the completion event.
Alan Stern
---
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
___
[EMAIL PROTECTED]
To unsubscribe
On Sat, 31 May 2003, Oliver Neukum wrote:
Am Freitag, 30. Mai 2003 16:35 schrieb Alan Stern:
As discussed earlier, we need a way for a driver to inform the core that a
device's descriptors have changed (following a firmware download, for
example). Let's call this new function
On Sat, 31 May 2003, Oliver Neukum wrote:
Am Samstag, 31. Mai 2003 21:32 schrieb Alan Stern:
I don't follow your reasoning here. As far as I can see, the only errors
to be handled are problems reading the descriptors. Are you suggesting
the one version should skip reading the descriptors
() with a spinlock. However, I suspect the patch that Alan
Stern recently applied to the 2.5 series to fix issues with the
controller state probably solves the problem (it removes the wakeup_hc()
call from uhci_interrupt()). Is there any chance this patch will be
applied to the 2.4 uhci driver as well
messages. If you can change it
so that the debugging messages are included with the kernel log, it will
be easier to diagnose the source of your problem.
Alan Stern
---
This SF.net email is sponsored by: eBay
Get office equipment for less
to add non-verbose error logging to usb-storage. But
the are other things ahead of it. It'll get it there eventually.
Alan Stern
---
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad
be useful if
the driver isn't sure how big a change the new firmware will cause.
Alan Stern
---
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
of your babble error.
The bus reset occurs because the kernel has given up on your device and
reset the port.
Thank you for any help that you can provide,
Alan Stern
---
This SF.net email is sponsored by: eBay
Get office equipment for less
On Mon, 2 Jun 2003, David Brownell wrote:
Alan Stern wrote:
Some significant changes to the error recovery code were just accepted
into Greg K-H's kernel tree. They will probably show up in the main
distribution in 2.5.71, or you can get them right now by BitKeeper from
bk
On Mon, 2 Jun 2003, David Brownell wrote:
Alan Stern wrote:
Yes, maybe the original error is just a random fault, and the
usb_bulk/control_msg timeouts are the only real problem. However, the new
changes mean that usb_control_msg() is no longer called by usb-storage.
Maybe something
a bunch of new
failure modes.
I agree entirely.
Alan Stern
---
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
2.5.70 at
ftp.kernel.org, and the combined patches up to the current 2.5.71 are in
the pub/linux/kernel/v2.5/testing/cset directory.
Alan Stern
---
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http
with the situation as I can imagine.
Can you send any debugging log information? Either USB debugging or
usb-storage debugging. The little bit shown here doesn't say anything
about what went wrong or how the kernel tried to fix it.
Alan Stern
I've been told it's not a good idea to put transfer buffers on the stack,
as that's not DMA-able on some architectures. Nevertheless, it's done in
the USB core (well, I found one place in hub.c that does it -- but that's
after only 1 minute of looking).
Does this need to be cleaned up?
Alan
, in fact in the context of the khubd kernel thread.
Alan Stern
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try
with the
debug options.
Alan Stern
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free
On Tue, 3 Jun 2003, Greg KH wrote:
On Tue, Jun 03, 2003 at 04:59:31PM -0400, Alan Stern wrote:
I've been told it's not a good idea to put transfer buffers on the stack,
as that's not DMA-able on some architectures. Nevertheless, it's done in
the USB core (well, I found one place in hub.c
()
usb_hub_port_debounce()
usb_hub_port_connect_change()
usb_hub_events()
usb_hub_thread()
Shouldn't they all be changed?
Alan Stern
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger
either! Only the user can tell. In
Linux this choice is made by the user installing the proper settings in
the hotplug config files.
Alan Stern
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger
?
Is this a question of each DMA master having to write in units of entire
cachelines, thereby interfering with whatever data the CPU happens to
store in the same cachelines?
And does this also mean that it's effectively impossible to dynamically
allocate any region smaller than a cacheline?
Alan Stern
configuration files as easily as it can load driver modules.
Alan Stern
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try
-storage continue to use usb_device_reset() as an
error-recovery tool? Or should it become something used only to signal
that a device has (or may have) changed internally?
Alan Stern
---
This SF.net email is sponsored by: Etnus, makers
that buffer and have the status IRQ URB
request a 0-length transfer? Or would it be better to put that buffer
along with the status report buffers in a separate area of memory? Having
them all together shouldn't matter, because they would all be written by
the same bus master.
Alan Stern
kernels.
Good luck.
Alan Stern
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com
to point out that this new behavior of returning invalid-command
sense data instead of returning an error only applies to BBB devices.
For CB[I] devices, babble will still invoke an error return. Is it
worthwhile sending in another patch to change that too?
Alan Stern
might possibly (?) point to the source of the error.
Alan Stern
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try
a tar archive of the sysfs hierarchy. If
you check the times in the log, you'll see those timeout messages all
appear exactly 5 seconds after each snapshot was recorded.
Alan Stern
---
This SF.net email is sponsored by: Etnus, makers
1 - 100 of 6192 matches
Mail list logo
