On Thu, Apr 09, 2009 at 12:47:23PM -0700, per...@pluto.rain.com wrote:
> Roland Smith <rsm...@xs4all.nl> wrote:
> > Are you sure that the drive isn't partitioned? In other words,
> > if you plug in the drive, and you give the command 'ls /dev/da0*',
> > do you only get /dev/da0 or perhaps also /dev/da0s1? If it is
> > partitioned, try /dev/da0s? instead.
> It's an SD card, not a "drive", so I had not expected it to be
> partitioned; but yes, it is:
> $ ls -l /dev/da0*
> crw-r-----  1 root  operator    0, 244 Feb 14 15:09 /dev/da0
> crw-r-----  1 root  operator    0, 245 Feb 14 15:09 /dev/da0s1

That would suggest that there is a filesystem on there, doesn't it?
> > Second, does the user running mtools have read and write access
> > to the device?
> Read-only, which should be sufficient for mdir.  The card is,
> deliberately, write-protected.
> After reconfiguring mtools to read from /dev/da0s1, I started
> getting those umass0: BBB bulk-in clear stall failed, TIMEOUT
> messages again, but I can read it a sector at a time using dd:

Try running unplugging the device, run 'camcontrol rescan all' and plug
it in again. Then wait until the devices show up.

> $ dd if=/dev/da0 of=~/sd bs=1b
> That's been running for something like 45 minutes now, and based on
> the size of the output file it has read about a tenth of the card.

Reading one byte at a time is bound to be slow.

It could be that this USB chipset needs some "quirks" to work correctly.

There are some really crappy USB chipsets out there. E.g. I've had trouble
with prolific controllers, especially on older (single core) machines.

If you are in a position to do so, you could try the new USB stack in

> > Have you tried just mounting the card reader?
> No, because I'd expect to panic the system if it is not in fact a
> valid (and readable) FAT filesystem.  Mtools seems much safer.

I can't recall mount_msdosfs ever panicing the kernel on me in that
case. It usually just fails.

R.F.Smith                                   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)

Attachment: pgp3Yy0a0mNdt.pgp
Description: PGP signature

Reply via email to