Hello Oliver,
I have no simple way to reproduce it at the moment, but I observed both:
Hang of the webcam (one observation after 3 days of working)
Hang of the kernel (one observation after 2 days of working)
This observation is done with my advantech SOM on the original develoment
board,
any wir
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
Hello,
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 'real' 2.6.0).
>From the ChangeLog:
* 20 dev_hints (per request)
* Hot unplugging should
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
bMaxPacket
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,
.
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.
===
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 drivers
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
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:
> > [] __might_sleep+0x5e/0x62
> > [] hcd_endpoint_disable+0xeb/0x260
> > [] hcd_endpoint_disable+0x0/0x260
> > [] nuke_urbs+0x
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 simpl
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 p
Brad Hards wrote:
Debug: sleeping function called from invalid context at drivers/usb/core/hcd.c:1350
Call Trace:
[] __might_sleep+0x5e/0x62
[] hcd_endpoint_disable+0xeb/0x260
[] hcd_endpoint_disable+0x0/0x260
[] nuke_urbs+0x4a/0x60
[] usb_disconnect+0xa2/0x140
A small oversight, try this:
--
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'i
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 o
-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)
iD8DBQ
-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
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 c
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 S
-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:
[] __might_sleep+0x5e/0x62
19 matches
Mail list logo
