On Sun, Sep 24, 2006 at 10:01:39AM +0530, Rupesh Kumar wrote:
> > It is possible that an earlier error in the device left the bulk-in
> > endpoint in a STALL condition (which is persistent). What was the result
> > of last transaction to the bulk-in endpoint before this exchange you
> > describe b
> It is possible that an earlier error in the device left the bulk-in
> endpoint in a STALL condition (which is persistent). What was the result
> of last transaction to the bulk-in endpoint before this exchange you
> describe below?
>
> Matt
Thanks for the response.
There were BULK IN Transacti
>
> > Using the libusb library to bypass all software layers, I issue READ_10
> > commands for 8KB blocks. Sequential access gives me 7.8 MB/sec and
random
> > access gives me 3.1 MB/sec. I use libusb with usb-storage.c found here:
> > http://svn.navi.cx/misc/trunk/grumpydisk/usb-storage.c
>
> Okay
On Sun, 24 Sep 2006 01:54:55 +0530, "Rupesh Kumar" <[EMAIL PROTECTED]> wrote:
> The following scenario is observed on the USB BUS Analyzer.
>
> 1. Bulk Out Transaction with (31 Bytes USBC Command) for some
> endpoint. I am requesting 4K Data from device.
> 2. Then There are lot
On Sat, 23 Sep 2006, Frederick Shotton wrote:
> Using the libusb library to bypass all software layers, I issue READ_10
> commands for 8KB blocks. Sequential access gives me 7.8 MB/sec and random
> access gives me 3.1 MB/sec. I use libusb with usb-storage.c found here:
> http://svn.navi.cx/misc/tr
I forgot to mention -- once a phase error is detected, the USB
specification requires the host to issue a RESET to the device.
Matt
On Sat, Sep 23, 2006 at 02:53:05PM -0700, Matthew Dharm wrote:
> This sounds like the device is getting out of sync (commonly known as
> "phase error"). The host se
This sounds like the device is getting out of sync (commonly known as
"phase error"). The host sent a command, but the device was not prepared
to send data at the proper time, and indicated an error with a STALL.
The proper response to a STALL at this point is to attempt to retrieve
status, which
Hi All,
I am having an embedded EHCI USB host controller on which i am using
linux-2.6.14
When i am doing bulk file copys between many devices i am facing the
following problem.
The following scenario is observed on the USB BUS Analyzer.
1. Bulk Out Transaction with (31 Bytes USBC Com
On Sat, Sep 02, 2006 at 06:39:10PM +0300, you [Ville Herva] wrote:
>
> I found the following addition to unusual_devs.h necessary to use E70 with
> 2.6 usb-storage:
>
>
> UNUSUAL_DEV( 0x0421, 0x0433, 0x0100, 0x0100,
>
> > Using async brought the performance of random access 8KB reads up 26% to
> > about 4.3 MB/sec. Still a long way off the Windows speed.
> >
> > -fred
> >
> >
> > > Frederick Shotton wrote:
> > > > In conducting tests on a 4GB USB 200x memory stick, I find that
using
> > Linux
> > > > 2.6.17 re
On Sat, 23 Sep 2006, Frederick Shotton wrote:
> Using async brought the performance of random access 8KB reads up 26% to
> about 4.3 MB/sec. Still a long way off the Windows speed.
>
> -fred
>
>
> > Frederick Shotton wrote:
> > > In conducting tests on a 4GB USB 200x memory stick, I find that u
Using async brought the performance of random access 8KB reads up 26% to
about 4.3 MB/sec. Still a long way off the Windows speed.
-fred
> Frederick Shotton wrote:
> > In conducting tests on a 4GB USB 200x memory stick, I find that using
Linux
> > 2.6.17 reading 8KB blocks I get 12MB/sec for seq
Frederick Shotton wrote:
> In conducting tests on a 4GB USB 200x memory stick, I find that using Linux
> 2.6.17 reading 8KB blocks I get 12MB/sec for sequential access and 3MB/sec
> for random access. The interesting thing is that under Windows with the same
> memory stick I get 10MB/sec for both s
13 matches
Mail list logo
