Am Donnerstag, 24. Juli 2003 05:00 schrieb Matthew Dharm:
Many people, including myself, have observed system stalls when using
usb-storage. It happens when copying large amounts of data to a USB device
-- everything (except the USB access) just stops for a little while. My
best guess is
On Sun, Jul 27, 2003 at 08:24:44AM +0200, Oliver Neukum wrote:
Am Donnerstag, 24. Juli 2003 05:00 schrieb Matthew Dharm:
Many people, including myself, have observed system stalls when using
usb-storage. It happens when copying large amounts of data to a USB device
-- everything (except
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If I pull the USB mouse out on a running 2.6.0-test1-ac3 kernel, I
get the following debug:
usb 1-2: USB disconnect, address 3
Debug: sleeping function called from invalid context at drivers/usb/core/hcd.c:1350
Call Trace:
[c011c61e]
Mode sense page length is 1536.
/var/log/messages:
Jul 27 10:01:59 lapp31000 kernel: hub 1-0:0: debounce: port 1: delay 100ms stable 4
status 0x101
Jul 27 10:01:59 lapp31000 kernel: hub 1-0:0: new USB device on port 1, assigned
address 2
Jul 27 10:01:59 lapp31000 kernel: Initializing USB Mass
Matthew Dharm [EMAIL PROTECTED] writes:
On Sun, Jul 27, 2003 at 08:24:44AM +0200, Oliver Neukum wrote:
Am Donnerstag, 24. Juli 2003 05:00 schrieb Matthew Dharm:
The question is, what is the best way to handle this. I'm guessing that
increasing the priority of the usb-storage control
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 21 Jul 2003 20:26 pm, McGivern, Damien wrote:
I've search through the list archives and the web but still haven't been
able to find a suitable example for what I need to do. Douglas Roberts had
sort of the same problem as myself last year
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 22 Jul 2003 00:32 am, McGivern, Damien wrote:
Is there a reason why this function has not been implemented?
How would you implement it? What would the arguments be?
Brad
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Hi!
I'm not sure how the design is intended to work, but either way something
needs to be fixed.
Yes, it seems like all the HCDs (and the hub driver) need attention.
Why the hub driver?
For basic functionality, you simply power it down (doing virtual
unplug), and power it back up on
On Fri, 25 Jul 2003, Matthias Fuchs wrote:
Hi,
it seems that our problem with the USB-pendrive is easy to explain,
but not difficult to solve:
We are using a ohci controller on a cache-incoherent system (IBM PowerPC 405).
This causes a lot of problems in the USB system during DMA'ing to
Brad Hards wrote:
Debug: sleeping function called from invalid context at drivers/usb/core/hcd.c:1350
Call Trace:
[c011c61e] __might_sleep+0x5e/0x62
[c03529db] hcd_endpoint_disable+0xeb/0x260
[c03528f0] hcd_endpoint_disable+0x0/0x260
[c034cd1a] nuke_urbs+0x4a/0x60
[c034da12]
Hi,
I've read some older discussions in this list about USB problems
on cache incoherent systems (e.g. ARM, PPC).
What is the status on this? We are using the 2.4.21 linuxppc_2_4_devel tree from the
bitkeeper repository. This kernel still has problems with USB. At least some device
drivers
habe
On Sat, 26 Jul 2003, Pavel Machek wrote:
Hi!
I'm not sure how the design is intended to work, but either way something
needs to be fixed.
Yes, it seems like all the HCDs (and the hub driver) need attention.
Why the hub driver?
For basic functionality, you simply power it down
On Sun, 27 Jul 2003, David Brownell wrote:
Brad Hards wrote:
Debug: sleeping function called from invalid context at drivers/usb/core/hcd.c:1350
Call Trace:
[c011c61e] __might_sleep+0x5e/0x62
[c03529db] hcd_endpoint_disable+0xeb/0x260
[c03528f0] hcd_endpoint_disable+0x0/0x260
On Fri, 25 Jul 2003, Matthias Fuchs wrote:
Hi,
I've read some older discussions in this list about USB problems
on cache incoherent systems (e.g. ARM, PPC).
What is the status on this? We are using the 2.4.21 linuxppc_2_4_devel tree from the
bitkeeper repository. This kernel still has
Alan Stern wrote:
I'd go for something like this patch. It resolves a FIXME and
makes a small behavior change: if the period is too big, it no
longer automagically limits it except for the case of full speed
interrupt transfers. (Which continue with the current behavior,
making a lot of
Hi,
Alan, does this fix the race you saw in usblp_write concerning
urb-status?
Regards
Oliver
You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.
trivial patch, the Sharp Zaurus SL-C760 is also pxa based.
sincerly yours
Malte Doersam
--- linux-2.4.21.org/drivers/usb/usbnet.c 2003-07-27 23:28:58.0 +0200
+++ linux-2.4.21/drivers/usb/usbnet.c 2003-07-27 23:55:26.0 +0200
@@ -1426,8 +1426,18 @@
.in = 1, .out = 2,
Greg:
This revised patch includes the change that David Brownell asked for. It
renames usb_connect() to usb_choose_address(), no longer exports the
function, and adds equivalent functionality to usb_register_root_hub().
It also removes the unnecessary (and incorrect) assignment to
On Mon, 28 Jul 2003 01:08:40 +0200
Nemosoft Unv. [EMAIL PROTECTED] wrote:
Hi Nemosoft,
Attached are two patches, one for 2.4.21 and 2.5.75 for the PWC driver. I
assume the 2.5.75 patch will go into 2.6.0-test* without problems (I hope
this driver can make it into the kernel before the
19 matches
Mail list logo
