> just to let you know what the ARCHOS jukebox does when connected properly per USB
>2.0:
Sounds like it'd be a nice product to have ... :)
> ---
> I measured the following:
>
> #hdparm -t /dev/sda1
>
> /dev/sda1:
> Timin
David,
just to let you know what the ARCHOS jukebox does when connected properly per USB 2.0:
---
I measured the following:
#hdparm -t /dev/sda1
/dev/sda1:
Timing buffered disk reads: 64 MB in 8.71 seconds = 7.35 MB/sec
Well, the larger overhaul is scheduled for "as soon as I get around to it".
Which means it should have been done long ago.
I actually want to separate completely away from urb->status and
srb->status. Neither does what we want, so I plan to introduce an atomic_t
to give us the current state of a
Hi Matt,
sorry I didn't recognize that the situation was already clear to you. It isn't to me
completely, even
today.
What about a suggestion to separate the urb->status from tsome SCSI-command-> status?
Would this help?
which other directions you want to go?
In any case, feel free to ask me
The usb/error-codes.txt document says -ECONNRESET is
for async unlink, which is what I saw happening. What HCD
is passing -ENOENT (synchronous unlink) there?
Actually, that distinction is something I'd like to rip out in 2.5
on the grounds that the completion function really has no
reason to car
It's expecting -ENOENT
This is a long-standing problem with various HCDs not all doing the same
thing.
Matt
On Thu, Apr 18, 2002 at 03:59:38PM -0700, David Brownell wrote:
> > The basic problem here is that the abort isn't recognized as an abort
> > because of the URB status code.
>
> The last
> The basic problem here is that the abort isn't recognized as an abort
> because of the URB status code.
The last I remember was a question about -ECONNRESET, and
so far as I can tell the EHCI driver obeys usb/error-codes.txt in
that area ... what status was usb-storage expecting instead?
- Dav
The basic problem here is that the abort isn't recognized as an abort
because of the URB status code.
In other words, it's a bug which is attributable to the error-recovery
code in usb-storage. I'm working on a much bigger fix which overhauls the
entire architecture, but Greg KH has indicated th
I forget, didn't you verify that this problem repeated just
as cleanly using this device in USB 1.1 mode?
I'm recalling this as an issue where the usb-storage
driver needed to update its error handling, and there
was no particular "USB 2.0" issue. And at any rate
the patch is to usb-storage ...
