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
... not too bad? that is probably just limited by the disk speed.....
#hdparm -T /dev/sda1
/dev/sda1:
Timing buffer-cache reads: 128 MB in 2.84 seconds = 45.07 MB/sec
This brings my cpu (AMD K6/2 300 Mhz) to full load (100%). so the CPU seems to be the
limit.
# bonnie
File './Bonnie.7746', size: 104857600
Writing with putc()...done
Rewriting...done
Writing intelligently...done
Reading with getc()...done
Reading intelligently...done
Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
100 5092 44.5 12174 33.4 4502 17.5 9156 66.7 15867 28.8 2822.1 43.0
this isn't slow either.....
----------------------------------------------
So in effect, I use "rsync" to copy mp3-files from my Linux box to the ARCHOS at a
rather interesting
speed.
If you watch it, its approx 1-2 seconds per title really copied, plus the time for
checking the
already transferred ones.
For a "rsync" with no copy actions I need 23 seconds on approx 4000 files on both
sides. When copying
191 Megs (4 complete CDs) via rsync (including the file compare) this is about 65
seconds.
So its really usable!
Christian
..............................
David Brownell wrote:
> 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 ...
>
> I'm glad that with the patch, you can use another USB 2.0
> device with Linux!
>
> - Dave
>
> > >>> Proposed workaround:
> >
> > set us->notify also in cases where the urb returns status DID_ERROR, not
> > only DID_ABORT:
> >
> > patch:
> >
>-----------------------------------------------------------------------------------------------
> >
> > --- usb.c Tue Apr 16 21:17:56 2002
> > +++ usb.c-cm Tue Apr 16 21:16:56 2002
> > @@ -465,7 +465,12 @@
> > US_DEBUGP("scsi cmd done,
> > result=0x%x\n",
> > us->srb->result);
> > set_current_state(TASK_INTERRUPTIBLE);
> > - us->srb->scsi_done(us->srb);
> > +/*05-Apr-02 cm*/
> > + if (us->srb->scsi_done)
> > + us->srb->scsi_done(us->srb);
> > + US_DEBUGP("scsi_done() called\n");
> > + if (us->srb->result == DID_ERROR <<
> > 16) /* scsi_abort may wait here */
> > + complete(&(us->notify));
> > } else {
> > US_DEBUGP("scsi command aborted\n");
> > set_current_state(TASK_INTERRUPTIBLE);
> >
>------------------------------------------------------------------------------------------------
> >
> > Any Comments?
> >
> > I can come around the problem with the patch, but I feel not strong
> > enough to correct this problem the "proper" way.
> >
> > On the other hand I feel that the SCSI command abortion procedure may be
> > broken anyhow when perfomed in the presence of lower layer errors
> > (which may be the cause for the abortion in the first place)
> >
> > What shall we do?
> >
> > Christian
> >
> >
> > PS: I want to keep this neat device "archos jukebox", snice this bug is
> > perfectly reproducible.............
> >
> >
> >
> > --
> > Christian Mahr (privat) [EMAIL PROTECTED]
> >
> >
> >
>
> _______________________________________________
> [EMAIL PROTECTED]
> To unsubscribe, use the last form field at:
> https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
--
Christian Mahr (privat) [EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
