Hi,
the new OHCI-HCD driver is completely broken on my G3:
May 25 03:29:13 enzo kernel: usb_control/bulk_msg: timeout
May 25 03:29:13 enzo kernel: usb.c: USB device not accepting new address=3
(error=-110)
May 25 03:29:13 enzo kernel: hub.c: new USB device 01:06.0-1, assigned address
4
May 25
On Sat, May 25, 2002 at 01:00:28AM +0200, Georg Acher wrote:
> Hm, can't see that there is any change in the usb-uhci root hub code but a
> lot in the general hub code, so the problem seems IMO more likely there ;-)
> The eax-register contains a value that looks like a part of an ASCII string
> ("
>>>usb_control_msg() is probably what he wants. It waits.
>>
>>Yes. But still we should probably have control queueing for
>>the uhci's (possibly at the HCD level?)
Queuing in the HCD seems most natural to me, in part because
all HCDs do it already for bulk and iso transfers ... and since
control
Franz Sirl wrote:
> Hi,
>
> the new OHCI-HCD driver is completely broken on my G3:
>
> May 25 03:29:13 enzo kernel: usb_control/bulk_msg: timeout
> May 25 03:29:13 enzo kernel: usb.c: USB device not accepting new address=3
> (error=-110)
What does "lspci" say for this OHCI hardware? Does /pro
On Saturday 25 May 2002 18:48, David Brownell wrote:
> Franz Sirl wrote:
> > Hi,
> >
> > the new OHCI-HCD driver is completely broken on my G3:
> >
> > May 25 03:29:13 enzo kernel: usb_control/bulk_msg: timeout
> > May 25 03:29:13 enzo kernel: usb.c: USB device not accepting new
> > address=3 (err
> 01:06.0 USB Controller: OPTi Inc. 82C861 (rev 10) (prog-if 10 [OHCI])
That was going to be my guess ... OPTi seems to give more than its
fair share of problems, in my experience! :(
I have an OPTi which had that same symptom, but 2.5.13 has the patch that
made it go away for me.
>>And did t
Thomas Sailer wrote:
> Yes. But still we should probably have control queueing for
> the uhci's (possibly at the HCD level?)
Yes!
You will also need it if you have to send control requests from interrupt
context.
best regards
Wolfgang
_
On Saturday 25 May 2002 19:21, David Brownell wrote:
> > 01:06.0 USB Controller: OPTi Inc. 82C861 (rev 10) (prog-if 10 [OHCI])
>
> That was going to be my guess ... OPTi seems to give more than its
> fair share of problems, in my experience! :(
>
> I have an OPTi which had that same symptom, but
Hi,
It seems to me that code and comments disagree in drivers/usr/core/usb.c.
I attached a patch fixing the comments. Hopefully the code is right :)
This patch is against 2.5.16
--
Johann Deneux
--- drivers/usb/core/usb.c~ Mon May 20 11:38:18 2002
+++ drivers/usb/core/usb.c Sat May
On Sat, May 25, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> >>>usb_control_msg() is probably what he wants. It waits.
> >>
> >>Yes. But still we should probably have control queueing for
> >>the uhci's (possibly at the HCD level?)
>
> Queuing in the HCD seems most natural to me, in part bec
Hi,
the attached patch for usb-uhci-hcd includes the possibility to specify the
FSBR-mode and depth-first-search-modes via module parameters. Thanks go to
Kevin ([EMAIL PROTECTED]) for this nice idea. He had problems with
stv0680-based cameras when using the default (breadth first) methods.
The
> There's the much discussed USB storage bulk/control problem
> which is a slightly different, but still related locking issue.
Can you tell me all about it? Or give pointers?
[2.5.18 hangs, 2.5.18 with 2.5.15 usr/storage fails with uhci
but works with alternate uhci; it smells a bit like a lock
On Sat, May 25, 2002, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > There's the much discussed USB storage bulk/control problem
> > which is a slightly different, but still related locking issue.
>
> Can you tell me all about it? Or give pointers?
>
> [2.5.18 hangs, 2.5.18 with 2.5.15 usr/sto
No, it's not in the specs. But it's in the field. Some devices are even
more delicate than that, hence the customized clear_halt code in
usb-storage.
Matt
On Sat, May 25, 2002 at 05:53:21PM -0400, Johannes Erdfelt wrote:
> On Sat, May 25, 2002, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
>> Andries, what kind of USB problems did you have with 2.5.16?
Obscure problems. However, this patch fixes things.
--- /linux/2.5/linux-2.5.18/linux/drivers/usb/storage/transport.c Tue May 21
07:07:37 2002
+++ /linux/2.5/linux-2.5.18a/linux/drivers/usb/storage/transport.c Sun May 26
> Some devices are even more delicate than that,
> hence the customized clear_halt code in usb-storage.
Yes. Could you perhaps add a comment in transport.c?
Right now it says something like
"some devices crash their internal firmware
when the status is requested after a halt"
but "some devices"
Will do. Right now I'm fighting with BK to do what I want. I have to say,
this thing (BK) could use some more documentation.
For example, do a 'bk edit ', then remove the file, then try to do a
'bk get '. You get a wonderfully cryptic error, with no indication
of how the hell you should fix th
So, my first BK patch. Once you figure out these tools, it's really not
that bad... but the problem is the initial learning curve and the high
shoot-yourself-in-the-foot potential.
Greg, this won't compile without the next changeset (which I'm about to
send). I figured that sending this via e-m
Second ChangeSet. Here goes nothing...
# This is a BitKeeper generated patch for the following project:
# Project Name: greg k-h's linux 2.5 USB kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#
Hi Matt,
I've just added both sets of patches to CVS.
regards,
Stephen.
[antonia] ~/unix/linux-usb/storage > patch -p4 <~/temp
patching file scsiglue.c
Hunk #1 succeeded at 4 with fuzz 1.
pat
20 matches
Mail list logo
