On Wed, Nov 27, 2002 at 03:49:59PM +0100, Nick Hibma wrote: > > This is the debug output of > > #dd if=/dev/da0s1c of=/tmp/data bs=65536 count=3 > > > > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense > > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/512b data/32b sense > > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/512b data/32b sense > > The 3 64k blocks you asked for are below. > > > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/65536b data/32b sense > > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/65536b data/32b sense > > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/65536b data/32b sense > > > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x35, flags: 0xc0, 10b cmd/0b data/32b sense > > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense > > So, the blocks are fetched in 64k blocks. Two options: Either the USB > stack does not chain the transfers in such a way that the device can run > at full performance or otherwise the device chokes on the transfers and > forces the chain of transfers to be delayed till the next frame. There > is a 'bandwidth reclamation' feature in the NetBSD stack in the UHCI > driver of which I do not know whether they made it into the USB stack. >
It did make it into -current, but it's not in -stable yet I believe. Joe -- Josef Karthauser ([EMAIL PROTECTED]) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ ================ An eclectic mix of fact and theory. =================
msg38541/pgp00000.pgp
Description: PGP signature
