I have no idea if it would help, but I had to use Alan Stern's recent
(Jan 27) usb-storage patch to get 2.4 to work on an embedded system.
Perhaps the VT chips are causing similar problems on Intel hardware?
As far as I know, this patch hasn't made it into any of the 2.4.21-pre
kernels yet. H
On Sat, 2003-02-15 at 01:43, David Brownell wrote:
> > There must be other issues not related to the EHCI driver, but relating to
> > the VT8235 in general on 2.4. ...
>
> Interesting. I know that VIA has a bit of history with PCI problems,
> maybe it's (still) a factor here.
Not something showi
Hi David,
> > I have been testing a few boards that use the VT8235 and there have
> > been some improvements. ...
>
> Thanks for the testing results.
>
> I know of one (elusive) bug that's not VIA-specific ... if when that's
> finally found/clobbered then we still see such misbehavior on VIA,
Jonathan,
I have been testing a few boards that use the VT8235 and there have been
some improvements. ...
Thanks for the testing results.
I know of one (elusive) bug that's not VIA-specific ... if when that's
finally found/clobbered then we still see such misbehavior on VIA, I
suspect I know s
On Friday 14 February 2003 06:53 pm, you wrote:
...i apologize for the previous accedental post.
Anton
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thaw
/* Thread module */
/* Interface to Sjoerd's portable C thread library */
#include "Python.h"
#ifndef WITH_THREAD
#error "Error! The rest of Python is not compiled with thread support."
#error "Rerun configure, adding a --with-thread option."
#error "Then run `make clean' followed by `make'."
Greetings,
I have been testing a few boards that use the VT8235 and there have been
some improvements. An Epox 8K5A board would previously hang the moment
data was accessed from a USB 2.0 storage device; since the ehci24-0201 and
a VIA IRQ handler update in the more recent 2.4.21-preX-ac releases
On Fri, 2003-02-14 at 17:22, David Brownell wrote:
> Dan Parks wrote:
> > Sorry I didn't give more info I was talking about the OUT
> > transfers. We are currently transferring 64 bytes every millisecond,
> > which is the fastest speed that USB 1.0 supports in isochronous mode.
>
> Hmm? Why
On Fri, 2003-02-14 at 12:41, David Brownell wrote:
> Getting low latencies on those OUT transfers will be an issue.
> Two transfers in the queue should normally handle it, unless
> something delays reporting the first completion long enough to
> prevent it from re-issuing in time ... as you have n
> From: Dmitri <[EMAIL PROTECTED]>
> Date: 14 Feb 2003 09:03:41 -0800
> > What do others think? Should we just remove this?
>
> How many developers have time for IRC in first place? It is too
> demanding on one's attention, IMO.
>
> Dmitri
Greg is on IRC often. It can be done, with proper tools
Hi,
We only had 2 URB's, and that was the problem. The reason why we only
had 2, was because the less URB's you have, the lower delay you have. I
guess we're going to go to 3 URBs. Thanks a lot for your help.
What delay that would increase with the number of urbs queued? I'd
think toleranc
On Fri, 2003-02-14 at 08:27, Stephen J. Gowdy wrote:
> What do others think? Should we just remove this?
How many developers have time for IRC in first place? It is too
demanding on one's attention, IMO.
Dmitri
> On Fri, 14 Feb 2003, Holger Schurig wrote:
>
> > At http://www.linux-usb.org the
What do others think? Should we just remove this?
On Fri, 14 Feb 2003, Holger Schurig wrote:
> At http://www.linux-usb.org the link "Mailing Lists" brings you to a page
> where at the end it states:
>
> > Another method of discussion is an IRC channel. This is #usb and is located
> > on openpr
At http://www.linux-usb.org the link "Mailing Lists" brings you to a page
where at the end it states:
> Another method of discussion is an IRC channel. This is #usb and is located
> on openprojects.net systems (for example irc.linpeople.org).
Now, openprojects.net is nearly dead, irc.linpeople
Add some comments and debug info.
speedtouch.c | 30 --
1 files changed, 16 insertions(+), 14 deletions(-)
diff -Nru a/drivers/usb/misc/speedtouch.c b/drivers/usb/misc/speedtouch.c
--- a/drivers/usb/misc/speedtouch.c Fri Feb 14 15:15:29 2003
+++ b/drivers/usb/m
On Thu, 2003-02-13 at 19:59, David Brownell wrote:
> Dan Parks wrote:
> >
> > We only had 2 URB's, and that was the problem. The reason why we only
> > had 2, was because the less URB's you have, the lower delay you have. I
> > guess we're going to go to 3 URBs. Thanks a lot for your help.
>
>
16 matches
Mail list logo
